機能が完成したからといって、それが正しいとは限りません。ソフトウェア開発において、「動作する」ことと「バグがない」ことの間には大きな隔たりがあります。この記事では、私がどのように自動化ツールを使ってウェブサイトの機能を検証し、問題を見つけ出し、コードの品質を確保しているかについて解説します。
Playwright MCP：ブラウザ内での自動化操作
Playwright MCPは、このプロジェクトで最も頻繁に使用されているテストツールの一つです。これを使えば、ブラウザをプログラムで制御できます——ページの移動、ボタンのクリック、フォームへの入力、スクリーンショットの取得、DOM構造の確認など、すべてを自動化できます。
従来のE2Eテストフレームワークとは異なり、Playwright MCPはMCPサーバーとして動作し、Claude Codeのワークフローに直接統合されています。テストスクリプトを書く必要はなく、テストしたい内容を自然言語で記述するだけで、ツールがブラウザを操作して実行してくれます。
私が最もよく使う操作は以下の通りです：
browser_navigate：指定したURLを開き、ページが正しく読み込まれているかを確認
browser_snapshot：ページのアクセシビリティスナップショットを取得します。スクリーンショットよりも構造化されており、すべての要素のrole、ref、テキストコンテンツを確認できます
browser_click + browser_fill_form：ユーザーの操作をシミュレートし、インタラクティブな機能をテストします
browser_evaluate：ページ上でJavaScriptを実行し、標準操作では不可能な処理（例えばcontenteditable属性を持つTipTapエディタの操作など）を処理します
具体的な例を挙げると、管理画面での記事公開フローのテストです。Playwright MCP を使用すれば、新規記事作成ページの自動起動、タイトルと本文の入力、カテゴリとシリーズの選択、翻訳ボタンのクリック、翻訳完了の待機、そして最終的な保存までを自動化できます。この一連のフローは手動操作と全く同じですが、どのステップも漏れなく実行されます。
QA Skill：体系化されたバグ発見プロセス
QA Skillは、体系化された品質検査プロセスを提供します。ランダムにクリックするのではなく、各機能モジュールを構造的に検査します。
その動作は以下の通りです：まず、検査が必要なすべての機能項目をリストアップし、それらを順次実行します。各機能項目に対して、以下の処理を行います：
期待される動作を記述
実際の操作を実行（通常はPlaywright MCPと連携）
実際の結果と期待される結果を比較する
差異がある場合は、スクリーンショットやスナップショットを添付してバグとして記録する
このプロセスの最大の利点はカバレッジです。手動テストでは境界条件（空の状態、多言語切り替え、長いテキストのオーバーフローなど）を見落としがちですが、体系化されたプロセスであれば、これらすべてをチェックリストに含めることができます。
このプロジェクトでは、QAチームのおかげで、発見が難しいバグをいくつか見つけることができました：
EN/JAのシリーズページに記事が0件と表示される（シリーズIDの言語間関連ロジックに誤りがあったため）
記事詳細ページのシリーズ・ブレッドクラムに、現在の言語設定ではなくzh-TWのシリーズ名が表示されていた
一部のページで、モバイル端末の画面幅においてレイアウトが崩れている
レビューとコードレビュー：コード品質の管理
バグを見つけて修正した後も、修正自体の品質を確認する必要があります。ここでは、2つの異なるレベルのレビューツールを使用します。
review skill は機能レベルのレビューを行います——修正によって問題が完全に解決されたか、新たな問題を引き起こしていないか、境界条件はすべて考慮されているか。
code-reviewスキルは、コード品質の観点からのレビューを行います。コードスタイルが統一されているか、潜在的なパフォーマンスの問題がないか、エラー処理が適切か、プロジェクトの規約に従っているかなどを確認します。
両者の違いは、reviewが「正しく機能しているか」に注目するのに対し、code-reviewは「適切に記述されているか」に注目する点にあります。このプロジェクトでは、機能を1つ完成させるか、バグを1つ修正するたびに、これら2つのレベルのレビューを経ます。
具体的な例を挙げると、シリーズ横断的な記事検索のバグを修正した際、レビューではEN/JAページで記事リストとシリーズ名が正しく表示されることを確認し、コードレビューでは追加されたtranslationGroupIdの検索ロジックが効率的か、適切なフォールバック処理が施されているかをチェックしました。
検証のリズム
検証プロセス全体を振り返ると、明確なリズムが形成されています：
Playwright MCPによる自動化操作で、基本機能を迅速に検証
QAスキルを活用してすべての機能ポイントを体系的に検査し、問題点を特定する
問題を修正した後、レビューで機能が正しく動作することを確認
最後にコードレビューでコード品質を確保する
このプロセスは一度実行すれば終わりというわけではなく、大きな変更があるたびに実行されます。面倒に聞こえるかもしれませんが、大部分が自動化されているため、実際に費やす時間は想像よりもずっと少なくて済みます。
次回は本シリーズの最終回となり、デプロイと運用について解説します。完成したものをローカルから本番環境へ移行する方法、および本番環境での保守戦略についてお話しします。