1. はじめに
こんにちは。株式会社レトリバでエンタープライズ案件や生成AI案件のプロジェクトマネージャーをしている野沢です。
本連載では、AI導入プロジェクトで頻発する「期待と出力のズレ」を減らし、現場で使われるAI構築のためのアプローチ「期待駆動開発」を紹介しています。
第1回：なぜAI導入は“期待外れ”に終わるのか？──よくある失敗のモデルケースでは、AI導入が“期待外れ”に終わる典型パターン（評価設計・データ整備・チューニングの失敗）を扱いました。
今回はその続き（第2回）として、ズレの根っこを断ち切る入口＝「問い直し」と、期待駆動開発の最重要ステップである「期待の言語化」への入り方を整理します。
2. なぜ今、「問い直し」が必要なのか
「問い直し」とは、AIに渡す前に、問い（＝やらせたいことの定義）をレビューし、期待（前提・判断軸・禁則）が抜けていないか確認して作り直すことです。
AI活用は「やるか／やらないか」ではなく、「どうやって安全に、価値へつなげるか」の局面に入っています。
一方で、現場の実感としてはこうなりがちです。
- それっぽい回答は返ってくるが、実務の判断に使えない
- 使うほど、確認・修正・説明責任が増えて疲れる
- 結果として「人間の方が早い」となり、定着しない
ここで重要なのは、AIが悪いというより、AIに“考慮してほしい前提”が渡っていないことです。
AIは「指示」には忠実でも、組織や人が暗黙知として持っている「期待」には鈍感です。
だから、最初にやるべきはプロンプトを工夫することでも、データを集めることでもなく、
「問い」を「問い直す」ことです。
この連載では、ズレを減らすために“最初に揃えるべき3つの問い”を型として扱います。
3. ミニケース：品質保証（QA：Quality Assurance）の対外窓口は、なぜ“AI化”で事故りやすいのか
※本ケースは現場で起きやすい状況を一般化した例です。
製造業のQAの対外窓口には、顧客・営業・現場から「今日中に返してほしい」が集まります。
1件1件は短い回答に見えても、実際はこうです。
- 根拠（どの資料・どの試験・どの合意）を探す
- 言い回しを調整する（言質・責任分界・契約影響）
- 追加で確認すべき条件を見極める（ログ、ロット、使用環境…）
- 優先順位・エスカレーション判断をする
ここにAIを入れると、検索や要約は速くなります。
しかし、“組織として言っていいこと／ダメなこと”や、“必要十分な確認”が抜けると簡単に事故ります。
つまり、QA窓口の本丸は「文章生成」ではなく、
暗黙の判断（期待）に沿った“回答の作法”にある、ということです。
4. 期待駆動開発の入口：問い直し3問
ここでいう「問い直し」は期待を言語化するための枠決めで、「期待の言語化」はその枠を成果物（ルール・テンプレ・評価）として仕様化する工程です。
第1回で扱った失敗（評価が割れる／データ整備が空回る／チューニングが迷走する）は、突き詰めると「期待が言語化されていない」ことに集約されます。
そこで、期待駆動開発では最初に問い直しを入れます。
ここでは実務で効く3つの問いに絞ります。
本連載で扱う“成功条件”は、期待を評価可能な形（SLA・必須要件・判定基準など）に落としたものです。
問い直し①：この回答の「成功」って、どんな状態？
- 何ができたら「使える」と言える？
- 誰が納得したらOK？（顧客／営業／品質／設計／法務…）
- 速度と正確さ、どっちが優先？（一次回答の早さ or 根拠の確実さ）
悪：いい感じに回答できる
良：一次回答は◯時間以内／根拠（参照元リンク）を必須／不明点は追加質問を返す
例（QA窓口）
「24時間以内に一次回答」「48時間以内に根拠付き回答」など、
“成功の形”が決まると、評価・運用・必要データが一気に揃い始めます。
問い直し②：この回答で「絶対に外してはいけないもの」は何？
- 言質リスク：断定していい？「可能性」止まり？
- 責任分界：自社の範囲／顧客の運用範囲／契約の前提
- 根拠の扱い：どの文書を参照し、どう明示する？
悪：断定して安心させる（そのほうが“良い回答”に見える）
良：断定禁止／責任分界の定型句を入れる／根拠がない場合は「追加確認中」と明示する
例（QA窓口）
AIは（設定次第では）「もっともらしい断定」をしがちです。
でも窓口の期待は「賢い文章」ではなく、事故らない文章です。
問い直し③：回答の前に「追加で聞くべきこと」は何？
- ログ・ロット・条件・再現手順など、必要十分な情報
- どの条件が揃ったら判断できるか
- エスカレーション判断（誰に渡すべきか）
悪：情報が足りなくても“それっぽい”推測回答を出す
良：不足情報をチェックリストで返す（ログ／ロット／使用条件／再現手順…）＋必要なら即エスカレーションする
例（QA窓口）
“回答生成”より先に、聞くべき質問のテンプレが暗黙知として存在します。
これが言語化されていないと、AIの回答は的外れになります。
期待の言語化で作る成果物（例）
- 成功条件：一次回答は24時間以内／根拠（参照元リンク）必須／不足情報は質問で返す
- 禁則：断定しない（可能性表現）／保証しない／契約・責任分界は定型句＋人にエスカレーション
- 追加質問：ログ／ロット／使用環境／再現手順が未記載ならテンプレで確認（不足情報チェック）
5. 問い直し3問を経て、AI設計に必要なものが見えてくる
上の3問を通すだけで、AIに載せるべきものが「プロンプトの工夫」から「期待の定義」へ移ります。
見えてくるのは、だいたいこの4カテゴリです。
- 前提条件：ルール、責任分界、優先順位、判断の境界線
- 前提情報：参照すべき資料、最新合意、用語、製品・工程の文脈
- 期待（成果イメージ）：内容・フォーマット・書き方・トーン・禁則
- 評価の基準：成功／失敗の判定、SLA、例外対応、監査観点
ここまでが揃って初めて、データ整備もチューニングも「正しい方向」に進みます。
逆に言うと、ここが曖昧なままだと、第1回で紹介した失敗に手戻ります。
6. 期待駆動開発の最重要ステップ：「期待の言語化」
問い直しの次にやるのが、期待駆動開発の入口であり核心でもある「期待の言語化」です。
これは単なるヒアリングではなく、
- 普段は言葉にされない暗黙知を掘り起こし
- 期待（欲しい成果のイメージ）を具体の言葉に落とし
- AIが取るべき情報・思考・行動として定義する
ための工程です。
ここが通ると、AIは「指示に忠実」から、「期待に沿える」側にグッと近づきます。
7. まとめ：AIを動かす前に、“問い”を見つめ直す
- AIは指示には忠実だが、期待には鈍感
- 期待のズレは、技術以前に「問いがズレている」ことで起きる
- まず問い直し3問を通して、暗黙知と期待を見える化する
- その次に期待の言語化を行い、評価・データ・チューニングを同じ方向に揃える
明日やること（3つ）
- 成功条件を1行で書く（SLA＋根拠提示＋一次回答の振る舞い）
- 禁則を3つ決める（断定禁止／保証禁止／判断は人へ）
- 追加質問テンプレを1個作る（不足情報チェックリスト）
次回予告（第3回）
次回は、今回の「問い直し」「期待の言語化」を踏まえて、
“プロンプトを頑張る”から抜け出し、実務で効くコンテキスト設計へ進む話をします。
提案・要件定義では「伝言ゲーム」（人を経由するたびに前提が落ちたり意味がズレること）が起きがちです。
“前提が抜けたまま／変質したままAIを作ってしまう”問題をどう食い止めるか——
エンジニア視点でも腹落ちする形で掘り下げます。
次に読む
前回（第1回）：なぜAI導入は“期待外れ”に終わるのか？──よくある失敗のモデルケース
次回（第3回）：要件定義におけるコンテキストとは何か？──実務で伝わらない「期待」を要件に落とす型
お知らせ
株式会社レトリバでは、期待駆動でお客様のAI活用・ビジネスを成功へ導く仲間を募集中です。
Discussion