E2Eテスト設計・自動化のリアル ─ Playwrightでの実践と MCPの試み （＋AIによるテスト観点作成） 株式会社アルダグラム 千葉 紘路 

自己紹介 ちばこうじ 
 千葉紘路 株式会社アルダグラム 役職：QAエンジニア 2022年5月~SESの会社にてITエンジニアとして入社。 ダッシュボード開発や決済システムのテスト自動化、社内システムの QAな どの案件で業務。 2024年11月に株式会社アルダグラムに QAエンジニアとして入社。 プロジェクト管理アプリの「 KANNA」のシステム開発のテスト設計 /実施と PlaywrightによるE2Eテストコードの拡充を主に担当 。 

アジェンダ • アルダグラムの事業とQAプロセス • AI×QAのアプローチについて • AI×Playwright • Playwright MCPとは • Playwright MCPの評価 • Playwright MCP活用事例 • コーディングルールの設定 • AI×テスト設計 • 今後の展望 

version : 2025-06-01 13 KANNAは工事・製造・メンテナンスなどの現場で 日常的に使われる “インフラ”プロダクト群 進捗の工程管理し、現場の写真共有、チャットによる報告など、
 現場向けのSlackやGoogle Work Placeのような存在 プロジェクト 現場で発生するあらゆる帳票をスマホ上から現場にいながら
 入力できるレポート業務のDXプロダクト レポート アルダグラムの事業と QAプロセス 

version : 2025-06-01 15 プロジェクトの進捗管理をデジタル化し、生産性を向上 プロジェクト アルダグラムの事業と QAプロセス 

version : 2025-06-01 16 あらゆる業種の帳票をデジタル化し、ペーパーレス化に貢献 レポート 現場で入力すると、帳票データにすぐに格納！
 帳票作成時のデータを正確に入力！
 いつも使っている紙の帳票の見た目で入力できる！ 現場での帳票作成も、正確に入力できるようアシストします アルダグラムの事業と QAプロセス 

version : 2025-06-01 06 アジア、北米、南米、欧州、アフリカなど 100カ国以上で利用されているプロダクト 2022年7月 　英語版 
 2022年11月　タイ語版 
 2022年12月　スペイン語版 
 2023年10月　ベトナム語版 2025年7月　 インドネシア語版 多言語対応 アルダグラムの事業と QAプロセス 

スクラムのワンチームとして QAエンジニアが入ることで、品質を担保する 38 課 題 定 義
 サ イ ク
 ル 開 発 サ イ
 ク ル 課題定義からエンジニアも参画し、顧客 の真のニーズを把握 要件定義時点ではエンジニアが必ず 入り、一次情報をとりにいく 実装と同時にQAが入り、エンジニア と一緒にテスト設計を策定 負債返済も含めた開発リソースの 投下はエンジニアが決定 課題定義と 
 課題優先順位 実装方法の 
 詳細設計 要件定義 実装
 ＋
 テスト設計 開発優先順位策定 QA 3ヶ月単位の 
 開発イシュー決定 リリース 開発プロセスにおける “アルダグラムらしさ ” 開発スプリントでは、QAエンジニアがスクラムチームに加わり、開発と並行してテスト設計、テスト項目作成、テス ト実施を行います。 日常的につかわれるインフラプロダクトだからこそ高い品質に徹底的にこだわるために、開発工程からQAを組み 込むことで、品質にこだわりを持ったプロダクト開発に臨むことができます。 実装と同時に QAが入り、エンジニアと一緒にテスト設計を策定 テスト自動化ツールなど生産性を最大化するためのツールを活用 アルダグラムでは、実装段階から QAエンジニアが参画 一般的には実装してから、QA業務を実施するが・・・ アルダグラムの場合・・・ 実装 テスト 開発プロセス 実装 実装 実装 テスト設計 テスト アルダグラムの事業と QAプロセス 

AI×QAのアプローチ AI×QAのアプローチ 

AI×QAのアプローチ 要件定義 テスト観点作成 設計 　開発 テスト項目作成 　テスト実施 　リリース 一般的なシステムの開発プロセス 

AI×QAのアプローチ AI×QAで改善が可能なフェーズ 要件定義 テスト観点作成 設計 　開発 テスト項目作成 　テスト実施 　リリース 

AI×QAのアプローチ 開発 ● ユニットテスト雛形生成 ● 改修による影響範囲の推測 ● 開発中のセルフQAの支援 テスト観点作成 ● 要件/仕様書のテキストから観点抽出 ● フォーマットへの落とし込み ● PRのコードから観点抽出 ● 因子水準表の作成 ● AI観点レビュー テスト項目作成 ● テスト観点 → 前提条件/手順/期待結果の生成 ● フォーマットへの落とし込み ● AI項目レビュー テスト実施（自動テスト） ● E2Eテスト自動化支援 ● AIコードレビュー ● ロケータ自己修復 フェーズ別 AI×QAのアプローチ 

AI×QAのアプローチ - AI×Playwright AI×Playwright 

AI×QAのアプローチ - AI×Playwright E2Eテスト自動化ツール 弊社ではMagicPodとPlaywrightを併用してE2Eテストの自動化を行なっています MagicPod ● ノーコードで作成/保守が可能 ● Web + モバイル対応 ● 有償 CRUDベースのシナリオ実装に利用 Playwright ● 実行速度が速い ● WebUI特化 ● 無償 ロールベースアクセス制御（ RBAC）の シナリオ実装に利用 

AI×Playwright - Playwright MCPとは Playwright MCPとは 概要 ● LLM（大規模言語モデル）が Webブラウザの操作を自然言語で行えるようにするための技術 ● PlaywrightとModel Context Protocol (MCP) を連携させ、自然言語で対話しながら、テストコードの自動生成やブラウザ操作を直接 行える ● 簡単な指示でブラウザ自動化タスクを実行できるようになり、テスト自動化や Webデモ作成などの効率が飛躍的に向上 利用方法 ● CursorやClaudeなどのAIコーディングツールの設定ファイルに以下の JSONを設定する { "mcpServers": { "playwright-mcp": { "command": "npx", "args": ["@playwright/mcp@latest"] } } } 

AI×Playwright - Playwright MCPの評価 Playwright MCPの実用性はどこまである？ 

AI×Playwright - Playwright MCPの評価 現時点では、特定の場面においては効果を実感できる が、全てを AIに任せられるほどではない 

(1) POM(Page Object Model)の雛形作成 　→体感50%コーディング時間の短縮 ● MCP経由でのブラウザで表示しているページ内のロケーターの定義 ● クリックやテキスト入力などの簡易なメソッドの定義 (2) テストケース実装時のエラー原因の改修 　→体感20%コーディング時間を短縮 ● エラー原因をDOM構造から解析して原因を特定→該当箇所の修正 AI×Playwright - Playwright MCPの評価 💡Playwrightの実装を一部AIに任せることでコーディング時間を短縮できる！ 

AI×Playwright - Playwright MCPの評価 😔実運用が難しいと感じた点 (1) フレークテスト化しやすい ● 画面描画の待機が考慮されない (2) プロンプト作成に時間がかかる ● テスト手順が複雑になると、手順を AIに正確に伝えるために対象のロケーターや待機処理の必要性なども 含めてプロンプトで説明する必要があり、プロンプト作成に時間がかかってしまう 

画面描画の待機が考慮されない ● 特定の要素の表示を待機するといった画面描画を待機する処理が生成されにくい AI×Playwright - Playwright MCPの評価 await page.goto('/projects'); await page.waitForLoadState('networkidle'); // たまたま通る await expect(page.getByText('閲覧権限のない案件 ')).toBeHidden(); 例：閲覧権限のない案件が表示されないことを expectしたい場合 ● 画面読み込みの待機が甘く、画面描画中に toBeHiddenの チェックが入る →意図せずテストが通ってしまう懸念がある 🤔安定性に懸念 (1) フレークテスト化しやすい 😔 

コーディングアシスタントのコード補完 (Cursor・GitHub Copilotなど) AI×Playwright - Playwright MCPの評価 Playwright Test for VSCode Recording機能 + 複雑なテストケースの場合、 ↓のような手動での作成の方が速い場合もある (2) プロンプト作成に時間がかかる 😔 

AI×Playwright - Playwright MCPの評価 どういった人におすすめか？ 特におすすめな人 ● Playwrightのコーディングに不慣れな人 ● E2Eテストコードの整備が進んでいないプロダクト ● セルフQAしたい開発者 MCPと連携できる環境があれば効果の大小はあれど、 使わない理由はない！ 

AI×Playwright - Playwright MCPの評価 Playwright MCPの今と未来 現状 ● テストコード実装時のエラー原因の改修 ● POMの雛形作成 ● 自然言語ベースでの簡単なテストケースの 実装 期待する未来 一部において利便性の向上を実感 より自動化された QAプロセスへの期待 テストコードの整備 ● 処理できるコンテキストの増加 ● システムに対する理解度向上 ● より複雑なテストケースの半自動整備 ● 開発と同時にE2Eテスト整備 テストプロセスの自動化 ● 開発コードのPR/マージ時に、差分と影響 範囲を特定したスモークテストの自動実行 

AI×Playwright - Playwright MCP活用事例 ①POM単位のロケーター抽出とメソッド雛形作成（例：設定画面） ②既存コードの改修 + 動作検証 Playwright MCPの活用事例としてこの2点についてご紹介します 

AI×Playwright - Playwright MCP活用事例 ①POM単位のロケーター抽出とメソッド雛形作成（例：設定画面） KANNAの設定画面 DOMを解析 

AI×Playwright - Playwright MCP活用事例 ①POM単位のロケーター抽出とメソッド雛形作成（例：設定画面） ロケーター ロケーター初期化 メソッド 

AI×Playwright - Playwright MCP活用事例 ①POM単位のロケーター抽出とメソッド雛形作成（例：プロフィール設定画面） プロフィール設定画面 DOMを解析 

AI×Playwright - Playwright MCP活用事例 ①POM単位のロケーター抽出とメソッド雛形作成（例：プロフィール設定画面） ロケーター ロケーター初期化 メソッド 

AI×Playwright - Playwright MCP活用事例 ②既存コードの改修 + 動作検証 【改修内容】 特定のテスト環境（QA2）での実行時のみ対象のテス トをスキップする MCPありとMCPなしで改修依頼し、比較検証しました 【改修後】 改修後、→のようなスキップ処理を追加実装しました 【改修理由】 テストに影響する機能が対象のテスト環境では構築され ていないため、テストが必ず失敗する 

AI×Playwright - Playwright MCP活用事例 ②既存コードの改修 + 動作検証 MCPなし (1) 静的推測に寄りがち ● process.env.~の環境変数を参照する実装に流れやすく、実装にそぐわない方法を選択していた。 (2) 過度な抽象化の誘発 ● environmentHelper.ts など 自前ヘルパ を量産 → 負債となる無駄なコードが生成された。 結局、目的であるスキップ処理も実装できず ...🥺 

AI×Playwright - Playwright MCP活用事例 ②既存コードの改修 + 動作検証 MCPあり (1) 実行 & 観測まで一気通貫 ● 実際に対象のテスト環境でテストを動かし、skip が効いているか、環境変数の誤解がないかを即時 に検証。 (2) 最小実装に収束 ● test.info().project.nameによる 1行の条件付き skip で十分と判断。 PlaywrightのAPIを利用した簡潔なコーディングが行われた！ 

AI×Playwright - Playwright MCP活用事例 ②既存コードの改修 + 動作検証 MCPありで改修した結果 このコードをそのまま採用！ 

AI×Playwright - コーディングルールの設定 コーディングルールの設定 .cursor/rules.mdc や copilot-instructions.md にコーディングルールを設定 セレクターの優先順位 ● アクセシビリティ要素を優先する ● class属性は最終手段とする など 待機処理 ● waitForTimeout()の使用制限 ● 要素の状態変化を待機する場合は、waitFor()を 優先する など 

AI×Playwright - コーディングルールの設定 コーディングルールの設定 .cursor/rules.mdc や copilot-instructions.md にコーディングルールを設定 テストファイルの基本構造 JSDocとしてテストケースの冒頭にコメントを記載 ● テスト名 ● テスト概要 ● テスト手順 ● 期待結果 など サンプル 

AI×Playwright - コーディングルールの設定 コーディングルールの設定 [Playwright]E2Eテスト自動化におけるAIコーディングルールの作り方 こちらの記事でコーディングルールの全貌を載せています 

(1) AIのコード補完精度向上 ● ルールに沿ったロケーターのコード補完 ● 既存のコードとの一貫性の担保 (2) AIのレビュー精度向上 ● エビデンスのあるコードレビュー ● リポジトリの特性に合わせたコードレビュー (1) 可読性向上 ● 一貫性の保たれた読みやすいコード ● 手順・期待結果の説明コメント (2) 実装・レビュー指針の策定 ● エビデンスのあるコードレビュー ● レビュイー・レビュアー間でのコーディングルールの 共通化 AI×Playwright - コーディングルールの設定 コーディングルールの設定による効果 AI エンジニア 

AI×QAのアプローチ - AI×テスト設計 AI×テスト設計 

AI×QAのアプローチ - AI×テスト設計 今までのテスト観点作成 インプット資料 機能仕様書/ 設計仕様書 要件定義書 テスト観点表 （テンプレート） QAエンジニア テスト観点表（完成品） 作成 

AI×QAのアプローチ - AI×テスト設計 生成AIを利用したテスト観点作成 インプット資料 機能仕様書/ 設計仕様書 要件定義書 テスト観点の フォーマット プロンプト AI （ChatGPT） QAエンジニア テスト観点表（完成品） レビュー ブラッシュアップ JSTQBシラバス AIチューニング プロンプトを受けて作成 

AI×QAのアプローチ - AI×テスト設計 生成AIを利用したテスト設計のコツ AI （ChatGPT） 生成AIでのテスト設計はこの「勘所 3つ」を押さえれば大丈夫 こちらの記事で詳しく解説しています（参画いただいている業務委託の方の記事です） (1) チューニングは必須 ● GPTsを作成し、事前に共通の指示を入れる (2) プロンプトは明確に ● ソースとなるドキュメントを添付 ● してほしいこと・してはいけないことを明記 (3) 依頼するタスク量を調整 ● コンテキスト量に限りがあるため、一度のタスク量は極力減らす 

AI×QAのアプローチ - AI×テスト設計 生成AIを利用したテスト観点作成事例（タスク管理機能） AIが作成した観点表 プロンプト 今回、タスク管理機能のシステムテスト設計を担当することになりました。 テスト設計は、「仕様」のマークダウンと、「テスト戦略」マークダウンを基に、スコープ を区切りながら行っていきます。 まずは、「タスク作成」に関するテスト設計を行っていきます。 最初に、以下の項目の入力バリデーションについてのテスト観点を提案してください。 ・タスク名 ・タスク内容 ・期日 フォーマットは、事前に指定しているテスト観点表のフォーマットでお願いします。 インプット資料 機能仕様書/ 設計仕様書 要件定義書 

案件一覧ビュー機能Phase2 ● テストケース数：1491件 ● 作成工数：92h = 16.21件/h 部署単位のユーザー管理Phase1 ● テストケース数：2285件 ● 作成工数：87h = 26.26件/h AI×QAのアプローチ - AI×テスト設計 生成AIでのテスト観点作成による工数削減効果 AI使用前 AI使用後 写真/資料フォルダのメンバーごとの閲覧制限 ● テストケース数：1999件 ● 作成工数：63h = 31.73件/h タスク管理 ● テストケース数：2822件 ● 作成工数：92.5h = 30.51件/h AI利用で約46%効率UP テスト戦略・設計工数 2施策平均：31.12件/h テスト戦略・設計工数 2施策平均：21.24件/h 

今後の展望 今後の展望 

開発プロセス (1) 開発のリポジトリで、テストケース読込 →自動実行の検証 • 開発のリポジトリを参照したPlaywright MCPによるE2E自動テストの精度を検証する (2) Playwright MCPを利用したプロンプトベースでの E2E自動テストのスコープ拡充 • 開発ローカル段階でのセルフQAとしてPlaywright MCPを利用を提案する QAプロセス (1) AIを利用した QAプロセスの改善によるプロダクト品質の向上 • テスト観点作成→テスト項目作成→テスト実施においてAIをフル活用し、QA工数を削減する (2) Playwright MCPによる高品質な自動テストの整備 • 削減したQA工数をテスト自動化に当て、テスト自動化の整備を促進させる 今後の展望 

Aldagramからのご案内 アルダグラムでは、QAマネージャーを募集しています！ QAチームでは、Playwright MCPやMagicPod MCP、その他生成AIを活用したQAプロセスの改善などを行なっており、AIに触れる 機会が非常に多く新たな取り組みにチャレンジすることができます。 興味がある方はぜひ、カジュアルなところからお話ししましょう！ アルダグラムの開発組織について知りたい方はぜひこちらをご覧ください！ エンジニア向け会社説明資料（アルダグラム） - Speaker Deck