1. はじめに
こんにちは。株式会社レトリバでエンタープライズ案件や生成AI案件のプロジェクトマネージャーをしている野沢です。
本連載では、AI導入プロジェクトで頻発する「期待と出力のズレ」を減らし、現場で使われるAI構築のためのアプローチ「期待駆動開発」を紹介しています。
第2回では、AIに渡す前に問い（やらせたいことの定義）をレビューして作り直す「問い直し」と、最重要ステップである「期待の言語化」の入口までを整理しました。
第3回は、少しエンジニア視点に寄せて書いてみます。
テーマは「プロンプト設計」ではなく、「コンテキスト設計」です。
ありがちな誤解：「コンテキストが大事」＝「情報を具体的にたくさん入れれば良い」
実際：量の問題ではなく、質、つまり適切な要件に落とせるレベルで言語化できているかどうかの問題です。
2. 「伝言ゲーム」が起きると、いくら実装の品質が良くても成功しない
本稿でいうコンテキストとは、単なる背景情報ではなく、判断に必要な前提・根拠・禁則・成功条件を“仕様に落とせる形”で揃えたものを指します。
ここで言う「伝言ゲーム」とは、人を経由するたびに前提が落ちたり意味が変質したりすることです。
そのリスク対策として、会議の録画・文字起こし・要約が整っていても、エンジニアがユーザーヒアリングに同席しても、普通に起きます。
相手にとって必要なことを十分に正しく伝えられる人はまれです。大抵は思い浮かんだ伝えたいことだけを伝えます。
抜け落ちや変質は、表面的な「発言そのもの」より 発言の裏にある前提（暗黙知） です。
- その業界では当たり前すぎて言わない
- その会社では常識すぎて説明されない（同音異義語が一般用語として存在するケースは要注意！）
- その部署だけの“作法”なので資料に残っていない
結果として、エンジニアが受け取る要件はこうなります。
- 一見丁寧で長い（ので安心する）
- でも 会社・部署固有のルール が抜けている
- その結果、実装・評価フェーズで「なんか違う」「使えない」が噴出する
これは、誰が悪いというより、他人・他社のコンテキストを扱う難しさが原因です。
3. ミニケース：設計変更影響調査RAGが「それっぽいのに使えない」理由
※本ケースは現場で起きやすい状況を一般化した例です。
製造業でよくある相談です。
「設計変更の影響調査、資料が多くて大変。RAGで何とかならないか？」
なおRAGの性能は、参照元ドキュメントのデータ整備（最新版管理・粒度・メタデータ等）と、どの根拠を優先するかの設計に強く依存します。
本稿ではまず“根拠と判断軸”を落とさない設計（コンテキスト）に焦点を当てます。
ここでハマりやすいのが、“一見よさそう”なプロンプトで進めてしまうことです。
まずは、いかにも正しそうな例から入ります。
4. 初手：一見よさそうなプロンプト例（でもうまくいかない）
「コンテキスト設計が大事」と言うと抽象的に聞こえますが、まずは一見それっぽいプロンプトを見てみます。
個人のタスクならそこそこ当たる。でもエンタープライズの設計判断だと、わりと簡単に外します。
【悪い例（それっぽいけど外す）】
あなたは製造業の設計業務に詳しいアシスタントです。
設計変更の内容を入力するので、影響が出そうな範囲を洗い出してください。
# 入力
- 変更内容：A部品の材質をSUSからアルミに変更する
- 目的：コスト削減
# 出力形式
- 影響範囲／確認事項／推奨アクション を箇条書き
これに対してAIは、だいたい「腐食・強度・熱・加工・コスト…」みたいな、一般論として筋の通った観点を返します。
でも現場で困るのは、ここからです。
- 判断の根拠セット：参照すべき一次情報は？（規格／設計標準／過去トラブル事例／試験結果…）
- 見るべき範囲の線引き：影響調査はどこまで見る？（部品→ユニット→全体／製造／調達…）
- 優先順位のルール：割れ・腐食・疲労などのリスクが出たとき、何を優先？（安全＞法規＞信頼性＞コスト＞納期…）
- 例外・特例の存在：特定顧客／特定品番／海外は別ルール（輸出向け、A社向け…）
- 後で詰む地雷リスト：後工程で炎上しやすい観点（再試験／認証／金型・治具／在庫…）
つまり、プロンプトがそれっぽくても「会社固有の期待」が抜けると、実務では期待外れ（足りない・使えない）になります。
5. なぜ外れるのか：伝言ゲームで“期待”が変質する
この「外れ」は、AIの能力不足というより、入力に含まれていないのが原因です。
第2回で述べた通り、AIは指示には忠実ですが、期待には鈍感です。
期待が入力に含まれていないと、“それっぽい一般論”に寄ります。
では、なぜ入力が薄くなるのか。その理由はだいたいこれです。
- 営業・コンサルが聞いたことが、要件化の途中で削られる（「当たり前」扱い）
- 議事録は残るが、言外の前提（会社の常識・禁則・判断軸）が落ちる
- クライアント自身も、暗黙知を“説明するもの”だと思っていない
結果として、エンジニアにはこう届きます。
- 仕様に落とせない（判断軸が足りない）
- 仕様に落ちたように見えて、地雷が残る
- PoCや初期導入で不満が噴出して、手戻りが発生する
ここで効くのが、第2回で扱った「問い直し」です。
問い直しは、“問い（＝AIにやらせたいことの定義）”が、期待を的確に言語化できているかをレビューすることです。
6. 問い直しで何が変わる？（編集＝意味を落とさず、必要があれば補って渡す）
会議を録画して文字起こしして、フォーマット通りに整形して…
仕組みを整えたからと言って、油断していませんか？
“言葉通り”に見えても、“意味”が落ちることがあります。
ここで必要なのは、単なる見た目の整理ではなく、
- どの前提が省略されたか
- どこが判断の分岐点か
- 何が禁則か（言ってはいけない、断定してはいけない）
- どこが例外か（顧客・製品群・プロセス固有）
を、読み手（エンジニア）が仕様に落とせる形に編集すること。
この編集ができると、同じ会議ログでも「使えるコンテキスト」になります。
7. 改善：問い直しで得られた期待を再現可能なコンテキストに編集する
問い直し → 期待の言語化 → コンテキスト編集（要件定義） → プロンプトは最後の器
では、さっきのプロンプトをどう直すか。
ポイントは「情報を増やす」ではなく、期待を言語化して要件として十分な状態に編集することです。
- ゴール / 成功条件：何ができたら「使える」と言える？誰がOKを出す？
- 制約 / 禁則：断定していい？言ってはいけないことは？責任分界は？
- 根拠（参照優先順）：何を一次情報とする？矛盾したらどれを採用？
- 不足情報（確認質問）：推測で埋める？止めて聞き返す？誰に聞く？
- 出力形式：次工程に渡せるフォーマットは？（観点・粒度・並び）
出力の一次評価は、設計標準・顧客合意・不具合DB・試験規格への参照が必要な根拠が過不足なく提示されているかで行う。
【改善例（期待＝要件として編集する）】
あなたは「設計変更の影響調査」を支援するアシスタントです。
以下の“会社ルール/前提”を守り、影響調査の一次アウトプットを作成してください。
# 目的
- 設計変更の影響範囲を漏れなく洗い出し、次アクションに繋げる（調査のたたき台）
# 成功条件
- 影響範囲が「品質/安全/規格/製造/調達/顧客合意」の観点で網羅されている
- “必ず当たるべき根拠”に当たれている（参照元を明示）
- 不足があれば推測せず、確認質問を返す
# 制約（禁止事項）
- 断定しない（根拠がない場合は「要確認」）
- 例外製品群/顧客合意事項に触れる場合は、必ずエスカレーションを提案する
- 参照先が取得できない／矛盾する場合は断定せず、「不足／矛盾」として列挙し、どれを採用するべきか確認質問を返す
# 根拠（参照優先順）
1) 最新の設計標準（`DesignStd_vX`）
2) 顧客合意（`Agreement_latest`）
3) 過去不具合DB（`DefectDB`）
4) 試験規格（`Spec_Test`）
# 入力
- 変更内容：A部品の材質をSUSからアルミに変更する
- 対象製品：XXXシリーズ
- 変更理由：コスト削減
# 出力形式
1. 影響範囲（観点別：品質/安全/規格/製造/調達/顧客合意）
2. まず当たる根拠（参照先＋理由）
3. 追加で必要な情報（確認質問）
4. 次アクション（担当/エスカレーション含む）
同じ「材質変更」でも、ここまで枠を決めると、出力は“賢い文章”から実務の判断に使えるたたき台に変わります。
そして重要なのは、この枠はプロンプト小技ではなく、期待の言語化の成果物だという点です。
8. まとめ：コンテキスト設計はプロンプトの工夫ではなく「期待の言語化」であり要件化
- 一見よさそうなプロンプトでも、会社固有の期待が抜けると外れる
- 外れの原因は、伝言ゲームで“意味”が落ちること
- 問い直しで、成功条件・禁則・根拠・不足情報を揃える
- それを補えると、コンテキスト設計は“実装可能な要件”になる
次回予告（第4回）
ここまでの話は、ヒアリングの観点リストを整備して、人間が頑張ればできる話ではあります。
でも言うは易し、正直マニュアル運用はしんどいと思います。
次回は、ここまでの「問い直し→期待の言語化」をツールで楽する話をします。
フレームワークを“再現可能な手順”に落とし、チームで回せるようにします。
その入口として、対話型ツールで「問い直し」「期待の言語化」を仕組み化するところまでを紹介します。
次に読む
前回（第2回）：AIは指示には忠実だが期待には鈍感──「問い直し」から始める期待駆動開発
次回（第4回）：期待駆動開発の「期待の言語化」を属人化させない──GPTsとの対話で整理するコンテキスト設計の実践
お知らせ
株式会社レトリバでは、期待駆動でお客様のAI活用・ビジネスを成功へ導く仲間を募集中です。
Discussion