株式会社レトリバ
🤖

期待駆動開発の「期待の言語化」を属人化させない──GPTsとの対話で整理するコンテキスト設計の実践

レトリバ野沢
に公開
要件定義
生成 AI
GPTs
コンテキストエンジニアリング
期待駆動
idea

1. はじめに

こんにちは。株式会社レトリバでエンタープライズ案件や生成AI案件のプロジェクトマネージャーをしている野沢です。
本連載では、AI導入プロジェクトで頻発する「期待と出力のズレ」を減らし、現場で使われるAI構築のためのアプローチ「期待駆動開発」を紹介しています。

第4回は、ここまで整理してきた「問い直し」「期待の言語化」「コンテキスト編集」を、人の力量に依存せず実践するための話です。
フレームワークを“対話の型”としてGPTsに埋め込み、抜け漏れ耐性と再現性を上げる、アプローチを紹介します。

2. なぜフレームワークとツール化が必要か：理解しているつもりでも、そんなにうまく実践できない

第2回・第3回で、ポイントは見えてきました。

  • AIは指示には忠実だが、入力されていない期待には鈍感
  • 伝言ゲームで落ちるのは、発言そのものより前提（暗黙知）
  • だから、問い直しをして「成功条件・禁則・根拠・不足時の質問」を揃え、コンテキスト（要件）を編集する必要がある

問題は、ここからです。

この作業は、訓練された人がやると強い。
でも、毎回・誰でも・短納期でできるだろうか？　うまくできず、こうなりそうです。

  • 観点が漏れる（ヒアリング相手から遠い分野が聞けない）
  • ヒアリング担当者のスキルに依存する（属人化）
  • “わかったつもり”で進み、初期導入で「なんか違う」が噴出する

期待駆動開発の肝は、正しさ以上に再現性です。
そこで本稿では、再現性を手軽に実現する手段としてGPTs化（エージェント化）を扱います。

3. 期待駆動開発の全体ステップと、今回の立ち位置

期待駆動開発は、「期待の言語化 → 導入設計 → 初期導入 → 改善」の4ステップで進めます。
そして多くの案件でボトルネックになるのが、最初の「期待の言語化」です。

期待が十分に言語化されないまま進むと、後工程でこうなりがちです。

  • 導入設計：前提が漏れているのに気づかず、“無難で一般的な設計”に着地してしまう
  • 初期導入：PoCは動くが「なんか違う」が噴出する
  • 改善：手戻りが仕様変更として積み上がり、コストが膨らむ

第2回・第3回で扱った「問い直し」や「コンテキスト編集」は、まさにこの “期待の言語化”を失敗させないための技術です。
第4回は、その技術を “対話の型”として実装する話になります。

4. 「期待の言語化」はこの4つで整理できる

期待の言語化は、次の4つを整理すると実現できます。

  1. 業務プロセスと事例の整理

    • 誰が、何を、どう進め、何を“良い/悪い”と判断しているか
    • 良い例/悪い例（ギャップ）が整理できると強い

  2. 人間の思考の整理

    • 指示をどう解釈し、何を根拠に、どう判断したか
    • 「なぜそう言った/それをした？」の理由が要件の核になる

  3. 暗黙知と期待の発見・言語化

    • ルール、禁則、例外、責任分界、優先順位
    • ここが落ちると、AIは一般論に逃げやすい

  4. 期待を反映したAIの定義

    • AIに「何を考えさせ」「どう振る舞わせ」「何を出力させるか」を確定する
    • ＝第3回で登場した成功条件/禁則/根拠/不足時の質問/出力フォーマットを揃える

ここまでを人力で毎回やるのは正直しんどいです。スムーズにできないとヒアリングされる側も大変です。
そこで本稿では、この4ステップをGPTsの質問フローと出力テンプレに落とし、抜け漏れしにくい“型”として利用します。

5. エンジニア向け：今回のGPTs化は「プロンプトを素敵にする」話ではない

ここで誤解されがちなのは、GPTs化＝プロンプト小技、という見え方です。

実際にやることは、ヒアリングの設計です。

  • どの順番で質問するか（入力の欠損を減らす）
  • 何を“必須項目”にするか（要件に落ちる形）
  • 不足・矛盾が出たとき、どう対処するか（安全に気づかせる）
  • 生成の自由度をどこまで許すか（裁量と責任の境界）

GPTsを「文章生成ツール」ではなく、要件化のための対話UIとして使います。

6. 実装イメージ：期待の言語化4ステップを“会話の型”にする

本格活用なら、ここに社内ナレッジ連携（RAG）なども検討しますが、本稿では“型”の話に絞ります。

6.1 対話の流れ

期待の言語化（4ステップで問い直し） → コンテキスト編集（＝要件整理） → 要件提示

※プロンプトは“器”、期待（要件）が“中身”

6.2 GPTsが最初にやること：不足を埋める質問を固定化する

例として、第3回の「設計変更影響調査」を使います。
GPTsは、いきなり影響範囲を“それっぽく”埋めません。
代わりに、影響調査を成立させる前提（＝後工程で要件になる材料）を先に確定します。

  • 対象製品／対象顧客は？（例外の有無）
  • 目的は？（優先順位が変わる）
  • 成功条件は？（何が揃えば「OK」か）
  • 参照すべき一次情報は？（設計標準/規格/顧客合意/不具合DB）
  • 禁則は？（断定禁止、エスカレーション条件、責任分界）

ここで揃えた情報は、そのまま次の2つに変換します。

  1. コンテキスト（要件）の骨格：成功条件／禁則／根拠／不足時の質問
  2. 実務アウトプットの型：影響範囲（観点別）＋当たるべき根拠＋確認質問＋次アクション

→ 以降の7章では、この変換を毎回ブレなく起こすために、GPTs側に固定する「システムプロンプト」を提示します。

7. GPTs（システムプロンプト）の雛形：最低限これだけは固定する

7.1 システムプロンプト雛形（最小）

あなたは「期待の言語化」を支援する設計アシスタントです。
ユーザーの入力が曖昧な場合は、推測せず、必要な確認質問を返してください。

あなたの目的は、次の4点を揃えた「コンテキスト（要件）」を作ることです。
1) 成功条件（評価可能）
2) 禁則（ガードレール）
3) 根拠（参照すべき一次情報と優先順）
4) 不足時の確認質問

出力は必ず以下の構造で返してください。
- 現状理解（入力の要約）
- 追加で必要な情報（確認質問）
- 仮のコンテキスト（暫定版：成功条件/禁則/根拠/出力形式）
- 次アクション（誰が何を確認すべきか）

7.2 期待の言語化を“進行”させる質問テンプレ

# Step1: 業務プロセスと事例
- いまの業務フローは？（誰が、何を、いつ判断する？）
- 良い結果例 / 悪い結果例は？（ギャップは何？）

# Step2: 人間の思考
- その判断は、何を根拠に、どう解釈している？
- 優先順位は？（安全/法規/品質/コスト/納期など）

# Step3: 暗黙知と期待
- 禁則は？（断定禁止、責任分界、顧客合意が必要 等）
- 例外は？（顧客/品番/地域/製品群）
- 後工程で爆発する地雷は？（再試験/認証/金型/在庫 等）

# Step4: AI定義
- AIに何を出してほしい？（現場で使える成果物の形）
- 「OK」の判定方法は？（一次評価の観点）

8. 対話で“期待が深まる”のはなぜか：仮説を置き、合意を取りにいくから

この型のポイントは、GPTsが賢い文章を返すことではありません。
「結論より先に、判断材料を揃える」ことです。

  • 不足があれば、先に聞き返す
  • 禁則や例外がありそうなら疑ってかかり、条件を先に確かめる
  • そして最後に、前提を“仮説として言語化”し、合っているか確認する

これにより「薄い入力 → 確認 → 補強 → 形になる」という流れが、対話で再現できます。

9. やり取り例：入力が薄い状態から、コンテキスト（要件）に育てる

前提：テーマは「設計変更影響調査」（材質変更）

  • ユーザー（よくある薄い入力例）

    • A部品の材質をSUSからアルミに変更したい。コスト削減。影響範囲を教えて。

  • GPTs（結論を急がず、必要な材料を揃える）

    • 現状理解：材質変更（SUS→アルミ）の影響調査のたたき台を作りたい。目的はコスト削減。

    • 追加で必要な情報（問い直し）

      1. 対象製品（品番/シリーズ）と用途（安全系か、一般用途か）
      2. 対象顧客（輸出向け/特定顧客向け等の例外の有無）
      3. 参照すべき一次情報の所在（設計標準/規格/顧客合意/不具合DB）
      4. 禁則（断定NG、エスカレーション条件）
      5. “OK”判定（一次評価で何が揃えば合格か）

※この時点では「影響範囲」を書き出すよりも、影響範囲を漏らさないことが優先です。

  • ユーザー（部分回答）

    • 対象はXXXシリーズ。輸出向けもある。断定は基本NG。顧客合意は案件による。

  • GPTs（ここが肝：仮説を置いて確認する）

    • ありがとうございます。現時点の情報から、次の前提がありそうです。合っていますか？

      • 前提A：輸出向けがあるため、規格/認証観点は必ず確認が必要
      • 前提B：断定はNG。根拠が揃わない場合は「要確認」とし、質問を返す
      • 前提C：顧客合意が必要な条件（どの変更が対象か）を明確化しないと、後で手戻りになりやすい

    • 合っていれば、この前提を「成功条件/禁則/根拠/不足時の質問」に落とし込み、影響範囲を書き起こします。

    • 違うなら、違う箇所がそのまま会社固有の期待なので、そこを優先して補強します。

10. “壊れない”ための実務Tips：GPTs化で起きる3つの事故と対策

GPTsは万能ではありません。雑に使うと事故ります。
よくある事故を3つに絞って対策を書きます。

  1. 事故1：それっぽい一般論で埋める

    • 対策：推測禁止＋不足質問を強制する
      • →「不足なら質問する」をシステム側に徹底させる。

  2. 事故2：根拠が揃っていないのに結論だけ出す

    • 対策：根拠（参照優先順）を必ず出力させる
      • → “参照元の提示がない回答は不採用・回答不可”扱いにする。

  3. 事故3：矛盾があるのに、うまく丸めてしまう

    • 対策：矛盾検出したら対処する（安全に気づかせる）
      • → 例：参照先が取得できない／矛盾する場合は断定せず、「不足／矛盾」として列挙し、どれを採用するべきか質問を返す。

11. まとめ

  • 期待駆動開発は「期待の言語化 → 導入設計 → 初期導入 → 改善」で進む
  • 詰まりやすいのは最初の「期待の言語化」
  • 期待の言語化は4ステップ（業務/思考/暗黙知/AI定義）で整理できる
  • これをGPTsの会話フローとテンプレに落とすと、再現性が上がる
  • GPTs化はプロンプト小技ではなく、要件化のための対話設計である

振り返り

次回（第3回）：要件定義におけるコンテキストとは何か？──実務で伝わらない「期待」を要件に落とす型

お知らせ

株式会社レトリバでは、期待駆動でお客様のAI活用・ビジネスを成功へ導く仲間を募集中です。

株式会社レトリバ
株式会社レトリバ

Discussion