E2EテストがAI時代に果たす役割
AIがコードを書く開発では、実装差分だけを見ても「ユーザーから見た振る舞い」が守られているか判断しにくくなります。E2Eテストは、画面操作や業務フローを外側から確認するため、生成されたコードの内部構造に依存せずに仕様を固定できます。
📑目次
Loglassの事例では、E2Eテストをただ実行するだけでなく、振る舞いをMarkdownカタログとして読める形にしています。これはAIに文脈を渡すときにも有効です。テストコードそのものよりも、入力、操作、期待結果が整理されたカタログの方が、AIにも人間にも仕様として伝わりやすいためです。
Playwright公式ドキュメントでも、ユーザーに見えるlocatorや期待値を中心にテストを書くことが推奨されています。この考え方は、E2Eを実装確認だけでなく、仕様説明として再利用する運用と相性が良いです。
コードに埋もれた振る舞いの問題点
E2Eテストが増えると、テストコードの中に重要な仕様が埋もれます。たとえば、どの条件でエラーが出るのか、欠損値をどう扱うのか、複数項目の計算結果がどう変わるのかは、コードを読まないと分からなくなりがちです。
この状態では、PRレビューも難しくなります。レビュー担当者は実装差分、テスト差分、業務仕様を同時に追う必要があります。AIが生成したコードをレビューする場面では、さらに「AIが前提を取り違えていないか」まで確認しなければなりません。
Markdownカタログは、この負担を分離します。テストの実装詳細ではなく、振る舞いの一覧をレビューできるため、仕様変更があったのか、単なるリファクタリングなのかを判断しやすくなります。
Kotlin DSLでテストとカタログを同時に生成
Loglassのアプローチで重要なのは、Markdownを手で別管理しない点です。Kotlin DSLでテストケースを宣言し、そこからE2EテストとMarkdownカタログを同時に生成します。これにより、テストとドキュメントがずれるリスクを抑えられます。
宣言する要素は、振る舞い契約、入力データ、初期状態、期待値です。これらを構造化しておけば、テスト実行にもドキュメント生成にも使えます。生成物はlefthookなどのpre-commitフックやCIで検証し、更新漏れがあれば失敗させます。
この仕組みは、AIコーディングにも効きます。AIに「この画面の期待挙動はカタログにある」と伝えられれば、コード生成時の前提が安定します。人間が都度プロンプトで仕様を説明するよりも、機械的に更新される一次情報を渡す方が再現性があります。
生成されたMarkdownカタログの実例と効果
Markdownカタログでは、テストケースごとに入力、操作、期待結果を表にできます。数値計算や集計ロジックのように、条件が増えるほど読みづらくなる領域では特に効果があります。
| 観点 | テストコードだけの場合 | Markdownカタログ併用の場合 |
|---|---|---|
| 振る舞い一覧 | ファイルを横断して読む | 表で俯瞰できる |
| PRレビュー | 実装差分中心 | 仕様差分も確認しやすい |
| AIへの共有 | コード全文が必要 | 入力と期待値を渡せる |
| 更新漏れ | 手動確認に依存 | CIで検知できる |
GitHub上でMarkdownがそのまま読める点も実務上は大きいです。レビュー時に、テストが何を保証しているかを非エンジニアにも説明しやすくなります。PdMやQAとの認識合わせにも使えるため、E2Eテストがチーム共通の仕様資産になります。
Playwright公式ベストプラクティスとの親和性
Playwrightは、ユーザーが見るラベルやロールに近いlocatorを使うことを推奨しています。これは、テストを実装詳細ではなくユーザー体験に寄せるための考え方です。Markdownカタログ化も同じ方向を向いています。
また、Playwrightのauto-waitingやweb-first assertionは、テストの読みやすさを保ちながら安定性を上げるための機能です。テストが安定すれば、カタログ生成の信頼性も上がります。逆に flaky なE2Eから生成されたカタログは、仕様として使いにくくなります。
つまり、カタログ運用はE2Eツールを置き換えるものではありません。Playwrightのような実行基盤の上に、仕様を読みやすく共有する層を追加する設計です。
運用ルールと副次効果
この運用を成立させるには、カタログを人手で編集しないルールが必要です。生成元のDSLを変更し、生成物はCIで一致を確認します。Markdownだけを直せる状態にすると、すぐにテストと仕様が分岐します。
副次効果として、AIへのプロンプト資産が自然に増えます。振る舞いカタログをAIに渡せば、既存仕様を踏まえたコード生成やリファクタリングがしやすくなります。特に大きなコードベースでは、AIに全コードを読ませるより、整理された振る舞い一覧を渡す方が効率的です。
導入は、全E2Eを一度に変換する必要はありません。まずは仕様変更が多い画面や、数値計算のように期待値の確認が重要な領域から始めるのが現実的です。
よくある質問
関連記事:
- AI予約サービス「オートリザーブ」トラブル｜飲食店に鳴り止まない電話と無断掲載
- 個人のプロンプト術卒業！チームで回すAI駆動開発ループの作り方
- 「AIがSQLを書いてくれる」で終わらせない — 分析基盤の育て方【dbt活用】
まとめ
E2EテストをMarkdownカタログ化する目的は、テストをきれいに見せることではありません。AIと人間が同じ振る舞い仕様を参照できる状態を作ることです。
Kotlin DSLやCIによってテストとカタログを同時に生成すれば、二重管理を避けながら仕様の可視性を上げられます。AIコーディングが増えるほど、こうした外側の振る舞い保証は重要になります。
関連する新しい記事:
- ナウシカの巨神兵が予見した生成AIのリスク 1984年の警告を現代に活かす – This published update adds current operational context for E2EテストをMarkdownカタログに変換する方法 ― AIコーディング時代の振る舞い管理.
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す