注文金額の組み合わせテストを、Confluenceに書かれた自然言語の手順のままClaude CodeとPlaywright CLIに実行させた事例がある。テストケースをコードに翻訳する工程を丸ごと外し、UI変更への追従コストとプログラミングスキル依存を同時に解こうとした設計を読み解く。
自然言語のテスト手順をAIエージェントがそのまま実行する仕組みの全体像と、「AIが作った実行計画をレビューして解釈ミスを防ぐ」という検品ポイント、個人開発の検証ツールにも移植できる応用の仕方。
題材は注文フローの金額計算テスト。条件の組み合わせが膨大になり、1件ずつ人間が正確性を確認するには大きなコストがかかっていたという（ZOZO TECH BLOG）。
ここで従来型の解決策として使われてきたコード記述型のE2E自動テストにも、別の弱点がある。プログラミングスキルへの依存、UI変更に追従するための修正コスト、そして書いた人にしか直せなくなるテストコードの属人化だ。「網羅性を上げるほど、保守できる人が減る」というジレンマが背景にある。
コードを書く代わりに、自然言語のテスト手順をAIエージェントがそのまま実行する経路を組んでいる。
Confluenceに自然言語で書いたテスト手順を、Claude Codeエージェントが読み取り、Agent Skillsを参照しながら操作手順を標準化する。人間が読むための手順書と、AIが実行する指示が同じ1つの文書になる。
要素の特定と操作にはPlaywright CLIのスナップショット機能を使い、その場で取得したref番号で要素を指定する。セレクタをテストコードに書き込まないため、DOM構造が変わっても直す箇所が発生しにくい。PC/SPの切り替えは設定ファイルで行い、別セッションでの並列実行にも対応する。
金額の期待値はTypeScriptの独立した計算サービスで事前に算出する。本番の計算ロジックをそのままコピーせずシステム側とテスト側の独立性を保つのが要点で、検証結果はSQL実行CLIで画像化し、Confluence操作CLIで結果を自動記載するところまでが一連の流れになっている。
ここが核心。テストケースを「コードで書く」のをやめ、「自然言語の手順をそのまま実行可能な指示に変える」という発想の転換。プログラミングスキル依存とUI変更への追従コストという、コード型E2Eテストの弱点を両方外している。
実際に扱われたテストケース数は、案件Aでおよそ20件、案件Bでおよそ50件。注文フローの各画面をPC/SP双方で確認する規模で運用されている。
以前この場で書いた「AIの『できました』を信じない｜3段階で検品する運用」と同じ構図がここにもある。自然言語でテストの敷居が下がるほど、実行前の計画レビューという検品ステップの比重はむしろ増える。
個人開発では注文フローほどの規模もMCP連携もないが、発想だけを抜き出せば移植できる部分がある。以下はまだ自分の環境で試していない、当てはめの仮案として書く。