この記事は 食べログアドベントカレンダー2025 の10日目の記事です🎅🎄
はじめに
こんにちは。食べログ開発本部 QA職域リーダーの池田です。
私は現在、飲食店向けのモバイルオーダーシステム「食べログオーダー」のQA業務を担当しています。プロダクトの規模拡大と社内全体のAI活用推進により開発プロセスが高速化する中、私たちQAチームには、高い品質を維持しながらスピーディに案件を回すことが求められています。
現状、毎月平均20件以上の案件をリリースしていますが、私たちは「テスト観点の品質が、少数のリーダーの経験則に依存してしまっている」という課題に直面していました。 QA業務において、仕様書には現れない「異常系の考慮」や「既存機能への影響」といった観点は、どうしても経験年数やドメイン知識の深さに左右されます。そのため、リーダーはメンバーが作成したテスト観点のレビューにおいて、「経験による知識のギャップ」を埋めるためのフィードバックに多くの時間を割いていました。1案件あたり平均1.5時間かかるレビューの多くは、本来ならばチーム全体の知見として共有されているべき「暗黙知」を、個別の案件ごとに伝承する時間となっていたのです。
そこで私たちは、「AIを、チーム全体の知見をメンバーに共有するメンター」として導入することにしました。メンバーがリーダーにレビューを依頼する前に、AIと対話して観点の抜け漏れを自己解決できれば、提出されるアウトプットの質が向上し、メンバー自身の成長にも繋がるはずです。 この記事では、AIを頼れるメンターにするために私たちが乗り越えた「プロンプトの壁」と、セルフレビューの質を劇的に高めた「Context Engineering」というアプローチについてお伝えします。
- はじめに
- 第1章：AIレビューで直面した2つの壁
- 第2章：Context Engineering：段階的な対話で知識を蓄積する「5層レビュー」
- 第3章：TestSmellの構造：暗黙知を形式知に変えるフレームワーク
- 第4章：実践投入：セルフレビューの質向上と、その成果
- おわりに
第1章：AIレビューで直面した2つの壁
私たちが目指したのは、AIに「ベテランQAと同じ視点」を持たせることでした。しかし、最初の取り組みは再現率0%という絶望的なスタートでした。
試行錯誤を重ねる中で、問題はプロンプトの「書き方」ではなく、プロンプトエンジニアリングというアプローチそのものに構造的な限界があることに気づきました。私たちが直面した課題は、以下の2つの壁に集約されます。
壁1：情報過多と一発勝負の限界
初期のプロンプト設計では、人間のQAエンジニアが段階的に処理するタスク（要件理解、観点比較、知識適用、出力）を、1回のプロンプトでAIにすべて実行させようとしていました。
初期設計の全体像：
- プロンプト本体: シンプルな指示（約500文字）
- インプットファイル: 大量の専門知識を詰め込んだ複数のファイル（合計11,500文字超）
- 要件定義書
- テスト観点表
- レビュー観点パターン定義
- レビュアー思考プロセス
一見、プロンプト本体は整理されているように見えました。しかし、問題はインプットファイルに大量の情報を詰め込んでいたことでした。人間のQAエンジニアが段階的に処理する内容を、AIには一気にやらせていたのです。
プロンプトは「与えられたインプットに基づき」と書かれており、実際には11,500文字超の情報を一気に読み込ませていました。
📊 図1：初期プロンプトの全体像
┌─────────────────────────────────────────────────┐
│ プロンプト本体 │
│ 「与えられたインプットに基づき、レビューを │
│ 効率的かつ効果的に実施してください」 │
└─────────────────────────────────────────────────┘
↓ インプットファイルを一気に読み込み
┌─────────────────────────────────────────────────┐
│ AIが1回で処理していた情報量 │
├─────────────────────────────────────────────────┤
│ │
│ ① 要件定義書（5,000文字） │
│ ② テスト観点表（3,000文字） │
│ ③ レビュー観点パターン定義（2,000文字） │
│ ④ レビュアー思考プロセス（1,500文字） │
│ ⑤ 出力フォーマットの指定 │
│ │
└─────────────────────────────────────────────────┘
合計11,500文字超 × 複数の専門知識
これを1回のプロンプトで処理させていた
AIの失敗：情報過多による要件の読み飛ばし
この膨大な情報を1回で処理させた結果、AIは要件定義書内の重要な要件を、観点表との比較時に読み飛ばしてしまいました。情報を詳しく与えれば与えるほど、AIの再現率が下がるという、直感に反する現象が起きたのです。
壁2：暗黙知の壁
AIが指摘できなかった最も手強いパターンは「要件には書かれていないが必要な観点」、つまりベテランQAエンジニアの経験則からくる暗黙知の領域でした。
失敗の実例：領収書送付機能のレビュー
要件定義書には、基本的な機能が明記されていましたが、人間のQAは以下の観点を追加で指摘しました：
- ❌ 領収書を「表示しない」設定時に、URLへの直接アクセスをブロックすべき
- ❌ メール送信設定が無効な場合のエラーハンドリング
これらはすべて、要件には書かれていません。AIはこれらの暗黙知の指摘を再現できませんでした。
人間はなぜ気づけたのか？：ベテランQAエンジニアの思考プロセス
ベテランは、「ON/OFF設定がある」と見たら「OFF時のアクセス制御も確認する」といった、過去の失敗から学んだ暗黙知のチェックリストを暗黙知的に頭の中に持っています。
ベテランQAエンジニアは、こうしたチェックリストを手がかりに「この設定がONならOFF時はどうか」「この処理が成功するなら失敗時はどうか」といった「書かれていない前提」を一つずつ洗い出し、要件の行間から潜在的なリスクを見つけていきます。つまり壁2の本質は、仕様に明示されていない想定外パターンを、経験則にもとづいて先回りして検討できるかどうかという点にあります。
これら2つの壁に対し、私たちは以下のアプローチで解決に取り組みました。
- 壁1への解決策: Context Engineering（第2章）
- 壁2への解決策: TestSmell（第3章）
以降の章では、これら2つの解決アプローチについて解説します。
第2章：Context Engineering：段階的な対話で知識を蓄積する「5層レビュー」
前章で直面した壁1「情報過多と一発勝負の限界」を乗り越えるため、私たちはAIとの「対話の設計」を変えるContext Engineeringという考え方に辿り着きました。
Context Engineeringとは何か
プロンプトエンジニアリングが「全情報を一挙に渡す一発勝負」であるのに対し、Context Engineeringは、複数ターンで知識を段階的に積み上げ、AIの知識を「成長」させていくアプローチです。
Context Engineeringの適用：5層レビュープロセス
私たちは、このアプローチに基づき、テスト観点レビューのタスクを5つの知識層に分解しました。
📊 図2：5層レビュー構造の全体像
┌─────────────────────────────────────────────┐ │ │ │ 第1層：要件との比較 (General AI) │ │ 【役割】要件書と観点表の突き合わせ │ │ ↓ コンテキスト蓄積 │ │ │ │ 第2層：QAのテスト技法 + 第1層の記憶 │ │ 【役割】境界値分析、同値分割の適用 │ │ ↓ コンテキスト蓄積 │ │ │ │ 第3層：業務フロー + 第1-2層の記憶 │ │ 【役割】食べログオーダー特有の業務フロー │ │ ↓ コンテキスト蓄積 │ │ │ │ 第4層：既存機能 + 第1-3層の記憶 │ │ 【役割】既存機能への影響評価 │ │ ↓ コンテキスト蓄積 │ │ │ │ 第5層：過去バグ + 第1-4層の記憶 │ │ 【役割】過去の失敗からの学び │ │ ↓ │ │ │ │ 統合レビュー結果出力 │ │ │ └─────────────────────────────────────────────┘
なぜ5層に分けたのか？
これは単にAIの負荷を下げるためだけではありません。人間（ベテランQA）の思考プロセスを模倣するためです。
ベテランがメンバーの成果物をレビューする際、いきなりマニアックな過去バグの話はしません。まずは「要件通りか？（第1層）」を確認し、次に「QAのテスト技法は正しいか？（第2層）」、そして最後に「過去のトラブル事例（第5層）」を照らし合わせます。この「ベテランの思考プロセス」をそのままAIの対話設計（5層構造）に落とし込むことで、AIは初めて「良きメンター」として振る舞えるようになったのです。
なぜこの順番なのか？
この第1-5層は、「広く浅い知識」から「狭く深い知識」へという順番になっています。なぜこのような順番にしたかというと、各層で積み上げたコンテキストを次の層に引き継ぐことで、コンテキスト不足を防ぐためです。
人間と同じように、AIもコンテキスト（前提知識）を与えられていれば、欲しい情報を対話形式で引き出せます。各層で積み上げられたコンテキストが、次の層での専門的な判断を支えるのです。
この設計により、各層で積み上げたコンテキスト（前提知識）が次の層へと引き継がれ、AIの理解と指摘の再現率が飛躍的に向上しました。
第3章：TestSmellの構造：暗黙知を形式知に変えるフレームワーク
Context Engineeringによって壁1は乗り越えられましたが、残された壁2「暗黙知の壁」が、安定的な再現率を阻む最後の砦でした。
AIは、「書かれていること」を元に論理展開するのは得意ですが、「書かれていないこと」からアイデアを膨らませるのは苦手です。しかし、ベテランQAは「要件にはないが、経験上危ない」という箇所を直感的に見抜きます。このベテランの「勘」をAIに教えるために、私たちはTestSmellという概念を導入しました。
トリガーワードとは、要件書やテスト観点表に現れる特定のキーワード（例：「複数の機能」「失敗」「連携」「外部システム」「同時」「競合」など）であり、過去の不具合データから抽出されたリスクの高い機能や操作を表す言葉です。これらのトリガーワードを手がかりに要件をスキャンすることで、TestSmellの可能性を機械的に検出するためのパターンマッチングのキーとして機能します。
TestSmellの体系化とDepth Smellへの注力
TestSmellについては、過去約1,600件の不具合チケットを分析した結果、以下の5つのカテゴリに体系化することができました。
📊 図3：5つのSmell一覧表
| Smell名 | トリガーワード | 検出ロジック | 過去バグ例 |
|---|---|---|---|
| Coverage Smell | 複数の〜、全ての、各、組み合わせ | 複数要素（A×Bなど）が要件にあるのに個別テストのみで組み合わせテストなし | メニュー種別×注文方法の組み合わせ不足による価格計算ミス |
| Depth Smell | 送信、登録、失敗 | 正常系のみで失敗ケースなし | ネットワーク不安定時のメール送信エラー未処理 |
| Integration Smell | 連携、外部システム、POS | 連携はあるがタイムアウトなし | POS連携タイムアウト時の注文データ未送信 |
| Timing Smell | 同時、競合 | 単一操作のみで競合条件なし | 同時注文時のテーブル伝票金額の不整合 |
| Context Smell | 権限、状態、モード | 1つの状態のみで状態遷移なし | 特定の権限状態でのみ発生するエラー |
※トリガーワード欄に記載しているのは代表的なキーワードの一部であり、実際にはこれらに類する語句なども含まれます。
この5つのカテゴリの中でも、Depth Smell（正常系のみで異常系不足）は、最も重要で、誰にでも伝わりやすい暗黙知です。
Depth Smell：異常系テストの抜け漏れを防ぐ
Depth Smellが検出するのは、要件に正常系（ハッピーパス）の機能があっても、その裏側にある失敗や異常系のケースがテスト観点から漏れていないかという点です。Depth Smellの最大の価値は、「要件に書かれていないテスト」、つまり異常時の挙動やエラーハンドリングこそが品質問題に直結しやすいという、ベテランQAエンジニアの知見をAIに組み込めた点にあります。
このSmellは、特定のトリガーワードを使うことで検出できます。「送信」「登録」「失敗」といった動詞がそれにあたります。これらの動作は、必ず成功と失敗の両面を持っています。例えば「送信」という行為には、成功（メールが届く）だけでなく、ネットワークエラーやタイムアウトといった対になる失敗が必ず存在します。Depth Smellは、まるでコードに「もし成功したら（if）はあるのに、失敗したらどうする（else）が抜けている」という観点漏れを検出するように設計されています。
検出例：オンライン決済の異常系観点漏れ
この概念を具体的に示すのが、以下のオンライン決済機能に対するレビューです。外部の決済サービス（QR決済サービスA, QR決済サービスB, クレジットカード）と連携しているにもかかわらず、要件やテスト観点表では主に「決済が正常に完了した場合」にフォーカスしており、失敗時やタイムアウト時といった異常系の挙動までは十分に言語化されていませんでした。AIは、単にエラーを出すのではなく、「ここはベテランQAエンジニアなら必ず確認するポイントだよ」と気づきを促すように指摘を行います。
📊 図4：Depth Smell検出の実例（オンライン決済）
┌─────────────────────────────────────────────┐
│ 要件（抜粋） │
├─────────────────────────────────────────────┤
│ - オンライン決済完了後に領収書画面を表示する│
│ - 領収書画面では軽減税率を含む金額を表示 │
│ - 決済方法：QR決済サービスA, QR決済サービスB, クレジットカード│
│ （決済失敗 / タイムアウト / キャンセル時の │
│ 挙動は記載なし） │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ テスト観点表（検出前） │
├─────────────────────────────────────────────┤
│ 2.1 領収書画面の軽減税率表示確認 │
│ - オンライン決済完了後に領収書画面が表示 │
│ - 軽減税率を含む金額が正しく表示される │
│ │
│ ※ 決済失敗 / タイムアウト / キャンセル時の │
│ 挙動に関する観点はなし │
└─────────────────────────────────────────────┘
↓ AIの検出（Depth Smell）
┌─────────────────────────────────────────────┐
│ 🔴 AIの検出結果 │
├─────────────────────────────────────────────┤
│ Depth Smell検出！ │
│ │
│ 【トリガー】 │
│ 要件から「オンライン決済」「外部決済」 │
│ （QR決済システムA / QR決済システムB / クレジットカード）を│
│ 検出し、テスト観点表が「決済成功後」だけを │
│ 見ていることを確認 │
│ │
│ 【指摘の根拠（暗黙知の形式知化）】 │
│ 過去の失敗事例「外部決済エラー時の決済不整合」│
│ に基づき、 │
│ 「外部決済との連携がある機能では、決済失敗や│
│ タイムアウト、ユーザーキャンセル時の挙動を │
│ 必ず確認すべきである」 │
│ という知見を適用しました。 │
│ │
│ 異常系テスト観点を追加 │
│ - 決済失敗時（外部決済側エラー）の表示と処理 │
│ - 決済タイムアウト時の再試行・中断の扱い │
│ - ユーザーが決済をキャンセルした場合の扱い │
│ - オンライン決済失敗時に領収書画面へ遷移せず │
│ 不整合な表示にならないこと │
└─────────────────────────────────────────────┘
この成功事例が示すように、Depth Smellの導入は、AIが要件の裏側に潜むリスク（＝暗黙知）を自律的に見つけ出し、メンバーに気づきを与えるためのブレイクスルーとなりました。
第4章：実践投入：セルフレビューの質向上と、その成果
Context EngineeringとTestSmellという設計思想を確立した私たちは、11月からこのAIシステムをメンバーのセルフレビュープロセスに実戦投入しました。
成果：AIを壁打ち相手にした、自律的なレビュープロセスの確立
導入後、私たちのチームで最も顕著だった変化は、「メンバーのセルフレビューの質が劇的に向上し、リーダーの手元に届くテスト観点が洗練されたものになった」ことです。
これまでは、レビュー時にリーダーが「通信エラー時の挙動は考慮されていますか？」と指摘して初めて、メンバーがその観点に気づくというケースがありました。しかし、新プロセスでは、メンバーがリーダーに提出する前にAIと対話を行います。Context Engineeringの5層構造に基づき、AIは「この機能は決済を伴うため、第5層の過去バグDBにある『通信遮断時の二重決済』のリスクを確認してください」といった具合に、ベテランQAエンジニアのような視点でアドバイスを投げかけます。
特にTestSmell機能は強力で、「送信」などのトリガーワードに対し、「正常系だけでなく、失敗時のリカバリーフロー（Depth Smell）の観点が必要です」と具体的に指摘します。これにより、メンバーは単に指摘を修正するだけでなく、「なぜその観点が必要なのか」という背景をAIとの対話を通じて学びながら、自らのテスト設計をブラッシュアップできるようになりました。
結果として、リーダーによるレビューは、基本的な観点漏れの指摘から、より高度なリスク分析や探索的テストの議論へとシフトしました。手戻りが大幅に減ったことで、結果的にレビュー工数も約20%削減されましたが、それ以上に、チーム全体で「暗黙知」が形式知化され、メンバーが自律的に品質を高められるようになったことが、今回の取り組みの最大の成果です。
おわりに
私たちのプロジェクトは再現率0%という絶望的なスタートでしたが、試行錯誤の末、私たちはプロンプトの「書き方」ではなく、人間と同じように段階的な「対話の設計」を変える必要があるという切実な気づきを得ました。その結果、知識を段階的に蓄積するContext Engineeringというアプローチに辿り着き、さらにベテランの暗黙知を形式知化したTestSmellを検知する手法と組み合わせることで、AIレビューで直面した2つの壁を乗り越えることができました。
この取り組みを通じて学んだ最も重要なことは、AI活用の本質は「人間の作業をゼロにすること（完全自動化）」ではなく、「人間の気づきを最大化し、自律的な成長を促すこと」にあるという点です。AIは単なるツールを超え、メンバーの成長を支援するチームの「良きメンター」として機能し始めました。
もしあなたが、AIプロジェクトで不安定さや複雑なタスクの壁に悩んでいるなら、あるいはチームの育成や品質の底上げに課題を感じているなら、Context EngineeringとTestSmellを検知する手法というアプローチを検討してみてください。それはきっと、チームの自律的な成長を促す大きな一歩になるはずです。
明日は @ryotab22 の「新卒2年目でインバウンド向け新規アプリ開発に携わった話 - 立ち上げからリリースまで」です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
