第3章 依頼を契約にする
この章で扱う能力
この章では、AIへの依頼を曖昧な会話ではなく、再利用可能な依頼仕様として設計する。これを本書では Request Contract と呼ぶ。読者は、目的、成果物、入力、対象範囲、制約、出力形式、品質基準、不明点の扱い、人間確認条件を含む依頼を作れるようになる。
この章の結論は次のとおりである。
AIへの依頼は、お願いではなく契約として書く。
契約とは、AIに自由を与えない文書ではない。
目的、範囲、制約、成果物、受け入れ条件を明確にし、
AIが安全に処理できる余地と、人間が判断すべき境界を同時に定義する文書である。
第2章では、AIに任せる仕事を選んだ。この章では、その仕事をAIに依頼できる形へ変換する。仕事選定が Work 層なら、この章は Request 層である。
本書全体における位置づけ
| 項目 | 内容 |
|---|---|
| 設計層 | Request |
| 目的 | 曖昧な依頼を、目的・制約・出力・品質基準を含む Request Contract へ変換する。 |
| 主な成果物 | AIエージェント依頼書、Request Contract、Acceptance Criteria |
| 前章から受け取るもの | AI適用判断シート |
| 次章へ渡すもの | Context Pack に必要な情報要求 |
| 参照 | Artifact Index、付録A: 成果物テンプレート集、Troubleshooting Flow |
本書の6層フレームワークでは、第3章は次の位置にある。
Work: どの仕事にAIを使うか
↓
Request: AIに何を依頼するか ← この章
↓
Context: AIに何を渡すか
第3章の役割は、AIに「何をしてほしいか」を書くことだけではない。AIに「何をしてはいけないか」「どこで止まるか」「何を成果物として受け入れるか」を定義することである。
Part II架空エピソード
「競合調査をいい感じに」で、価格、市場、出典、確認日が混ざった。Recurring Case の競合調査を、Request Contract、Context Pack、Task Briefへ分解する。
なぜ必要か
AIの出力品質が安定しない原因の多くは、モデル性能ではなく依頼の曖昧さにある。実務では、次のような依頼がよく発生する。
競合調査して。
この資料をいい感じにまとめて。
顧客に返信して。
障害原因を調べて。
営業資料を作って。
このコードを直して。
これらは人間同士であれば、周辺文脈や暗黙知で補える場合がある。しかし、AIエージェントは、渡された依頼、利用可能なコンテキスト、許可されたツールの範囲で処理する。依頼が曖昧であれば、AIはもっともらしい前提を補い、出力を作る。そこに実務上の危険がある。
「競合調査して」という依頼には、次が含まれていない。
何の意思決定に使うのか。
どの競合を対象にするのか。
どの市場、地域、顧客セグメントを見るのか。
いつ時点の情報を優先するのか。
出典は必要か。
不明な情報はどう扱うのか。
価格、機能、評判、導入事例のどれを重視するのか。
最終判断までしてよいのか。
出力は表なのか、文章なのか、会議資料なのか。
依頼にこれらがない場合、レビュー時に「思っていたものと違う」となる。これはAIの問題ではなく、仕事の受け入れ条件が定義されていない問題である。
Request Contract は、AIへの依頼を次のように変える。
目的：
法人向けバックアップサービスの価格改定検討のため、主要競合の価格体系、機能、対象顧客、強み、弱みを比較する。
対象範囲：
国内で法人向けクラウドバックアップを提供する主要5社。個人向けバックアップ、単純なストレージサービス、海外専業サービスは除外する。
出力形式：
Markdown表。列は「会社名」「サービス名」「価格体系」「主要機能」「対象顧客」「強み」「弱み」「要確認事項」「出典」。
制約：
不明な情報は推測せず「要確認」と書く。価格改定の結論は出さない。経営会議での論点整理に使う下書きとする。
人間確認条件：
価格判断、競合評価、顧客向け説明に使う前に、事業責任者が確認する。
この依頼であれば、AIの出力をレビューできる。列が足りない、出典がない、価格改定の結論を出している、不明情報を断定している、という評価が可能になる。
依頼を契約にする目的は、AIを縛ることではない。仕事の成功条件を明確にし、AIが処理すべき範囲と、人間が判断すべき範囲を分けることである。
Request Contract とは何か
Request Contract とは、AIエージェントに作業を依頼するときの実務仕様書である。プロンプトと似ているが、目的が違う。
| 用語 | 意味 | 主な用途 |
|---|---|---|
| プロンプト | AIに渡す入力文 | 単発の質問、下書き、変換 |
| 依頼文 | 人間がAIに頼む自然文 | 軽い作業指示 |
| Request Contract | 目的、範囲、制約、出力、品質基準、確認条件を含む依頼仕様 | 業務成果物を作る作業 |
| Acceptance Criteria | 出力を受け入れる条件 | レビュー、完了判定 |
| Task Brief | 分解された個別タスクの仕様 | 複数ステップ委任 |
本書では、実務で繰り返し使う依頼は Request Contract として扱う。単発のメモ整理や文章の言い換えなら、簡単なプロンプトでよい。しかし、顧客、契約、価格、障害、開発、運用、社内意思決定に関わる場合は、依頼を契約化する。
Request Contract は、AIに渡すだけでなく、人間のレビューにも使う。依頼仕様がなければ、出力が良いか悪いかを判断できない。Request Contract は、AIのための文書であると同時に、人間のためのレビュー基準である。
Request Contract の基本構造
Request Contract には、次の要素を含める。
| 要素 | 内容 | 例 |
|---|---|---|
| 目的 | なぜこの依頼をするのか | 価格改定の判断材料を作る |
| 最終成果物 | 何を完成物とするのか | 経営会議向け比較表 |
| 背景 | どの文脈で必要か | SMB向けプランの解約率が上昇している |
| 対象範囲 | 何を含めるか | 国内法人向けバックアップサービス |
| 除外範囲 | 何を含めないか | 個人向け、海外専業、ストレージ単体 |
| 前提条件 | 作業の前提 | 価格情報は公開情報を優先する |
| 入力情報 | AIに渡す資料やデータ | 競合URL、過去調査、顧客要望 |
| 利用可能情報 | 参照してよい情報 | 公開Web、社内FAQ、過去チケット要約 |
| 利用禁止情報 | 参照してはいけない情報 | 個人情報、認証情報、契約外の顧客情報 |
| 制約条件 | やってはいけないこと | 推測禁止、断定禁止、外部送信禁止 |
| 判断基準 | 何を優先するか | 経営判断に使える粒度、営業利用ではない |
| 出力形式 | 成果物の形式 | Markdown表、JSON、メール下書き、Issue |
| 品質基準 | 何を満たすべきか | 出典がある、要確認が分離されている |
| 不明点の扱い | 不足情報をどう扱うか | 要確認と書く、質問する、仮定を明示する |
| 途中確認条件 | どこで一度止めるか | 対象競合リストを確定する前 |
| 人間承認条件 | 人間確認が必須の操作 | 顧客送信、価格判断、契約判断 |
| 停止条件 | 作業を進めてはいけない条件 | 機密情報が必要、根拠が不足、権限外ツールが必要 |
すべての項目を毎回長く書く必要はない。重要なのは、依頼の性質に応じて欠かせない項目を落とさないことである。
たとえば、情報整理だけなら「人間承認条件」は軽くてよい。顧客返信や本番環境に関わる依頼なら、人間承認条件と停止条件は必須である。
最小 Request Contract
軽量な業務では、次の7項目で始める。
目的：
成果物：
対象範囲：
入力情報：
制約：
出力形式：
受け入れ条件：
これだけでも、単なる「いい感じにまとめて」より大きく改善する。
例: 議事録整理
目的：
定例会の決定事項と未決事項を整理し、次回会議の準備に使う。
成果物：
決定事項、未決事項、担当者、期限、次回確認事項の一覧。
対象範囲：
以下の議事メモのみ。過去会議や推測は含めない。
入力情報：
会議メモ本文。
制約：
担当者や期限が不明な場合は補完せず「要確認」と書く。
出力形式：
Markdown表。
受け入れ条件：
決定事項と未決事項が分かれている。担当者と期限の不明点が明示されている。
この依頼は短いが、レビュー可能である。
依頼モードを明示する
AIへの依頼では、何を作らせるかだけでなく、どのモードで作業させるかを明示すると安定する。
| モード | 目的 | 依頼例 | 注意点 |
|---|---|---|---|
| Explore | 論点、選択肢、リスクを洗い出す | 「まず論点を列挙する」 | 結論を急がせない |
| Produce | 成果物の初稿を作る | 「メール下書きを作る」 | 下書きと確定を分ける |
| Review | 出力や資料を検証する | 「根拠不足とリスクを指摘する」 | AIレビューを最終保証にしない |
| Transform | 形式を変換する | 「議事録からタスク一覧へ変換する」 | 入力外の補完を禁止する |
| Compare | 複数案を比較する | 「A案とB案を観点別に比較する」 | 比較軸を指定する |
| Plan | 作業手順を作る | 「実施手順と確認点を作る」 | 実行権限とは分ける |
| Execute-assist | ツール実行の補助をする | 「PR本文の下書きを作る」 | 書き込み・送信前に承認を置く |
モードを書かないと、AIは探索すべき場面で結論を出したり、レビューすべき場面で文面を整えたりする。依頼モードは、AIの作業姿勢を決める。
悪い例
この提案を見て。
改善例
モード：Review
目的：経営会議に出す前に、提案書の論理の飛躍、根拠不足、実行リスクを洗い出す。
出力：指摘一覧。列は「該当箇所」「問題」「なぜ問題か」「修正案」「重要度」。
制約：文章の言い換えではなく、意思決定リスクに関わる指摘を優先する。
成果物を先に決める
Request Contract では、最終成果物を先に決める。AIへの依頼は、会話の流れではなく、成果物から逆算して設計する。
| 成果物 | 出力形式の例 | 受け入れ条件の例 |
|---|---|---|
| 比較表 | Markdown表、CSV | 比較軸が揃っている。出典がある。要確認が分かれている。 |
| メール下書き | 件名、本文、社内確認事項 | 顧客に直接送れるとは扱わない。断定表現がない。 |
| Issue | 背景、目的、受け入れ条件、タスク | DoDがあり、担当者が実行可能。 |
| ADR | 状況、選択肢、決定、根拠、影響 | 代替案が比較されている。未決事項が明示されている。 |
| レビュー結果 | 指摘表 | 重要度、根拠、修正案がある。 |
| 実験計画 | 仮説、最小実験、成功条件、やめる条件 | 期限と評価指標がある。 |
成果物が曖昧なまま依頼すると、AIは読みやすい文章を返す。読みやすい文章は、必ずしも使える成果物ではない。
出力形式は後工程で決める
出力形式は、AIが得意そうな形式で決めるのではない。後工程で誰がどう使うかで決める。
会議で使うなら、論点表にする。
チケットに貼るなら、Issue形式にする。
APIやスクリプトで使うなら、JSONまたはCSVにする。
顧客確認に使うなら、メール下書きと社内確認事項を分ける。
レビューに使うなら、指摘表にする。
出力形式を指定するときは、列名やセクション名まで指定する。たとえば「比較表」と書くだけでは不十分である。
出力形式：Markdown表。
列は「項目」「A案」「B案」「差分」「判断に必要な追加情報」「リスク」。
このように書けば、レビューしやすく、後工程で再利用しやすい。
受け入れ条件を定義する
Request Contract には、Acceptance Criteria を含める。受け入れ条件は、AI出力を採用するか、修正するか、差し戻すかを決める基準である。
悪い受け入れ条件:
分かりやすいこと。
いい感じであること。
十分詳しいこと。
改善した受け入れ条件:
- 比較対象が5社である。
- 各社について価格体系、主要機能、対象顧客、強み、弱みが埋まっている。
- 不明な項目は「要確認」と書かれている。
- 出典が各行に付いている。
- 価格改定の最終判断は書かれていない。
- 経営会議で確認すべき論点が3〜5個に整理されている。
受け入れ条件は、レビュー表の元になる。第6章で扱う AI出力レビュー表は、この章で定義した受け入れ条件を使って出力を評価する。
不明点の扱いを指定する
AIに依頼するときは、不明点の扱いを必ず指定する。実務では、不明点をきれいに補完した出力より、不明点が正しく分離された出力の方が価値が高い。
不明点の扱いには、次の選択肢がある。
| 扱い | 使う場面 | 依頼文の例 |
|---|---|---|
| 質問する | 作業開始前に前提が必要 | 「不足情報があれば、作業前に最大5つ質問する」 |
| 仮定を明示する | 軽い作業で仮置き可能 | 「仮定を置く場合は、仮定欄に分離する」 |
| 要確認にする | 事実確認が必要 | 「不明な情報は推測せず要確認と書く」 |
| 複数案にする | 判断前の探索 | 「前提が異なる場合はA案/B案に分ける」 |
| 停止する | 高リスク業務 | 「契約・顧客影響に関わる不明点がある場合は作業を止める」 |
不明点の悪い扱い
分からないところは補って。
これは危険である。AIがもっともらしく補完する可能性がある。
改善例
不明点の扱い：
- 事実情報が不足する場合は推測しない。
- 「要確認事項」に分離する。
- ただし、文面構成上の仮置きが必要な場合は「仮定」と明記する。
- 契約、価格、補償、SLA、顧客影響に関わる不明点がある場合は作業を止め、人間確認を求める。
制約条件は「しないこと」まで書く
AIへの依頼では、やってほしいことより、やってはいけないことの方が重要になる場面がある。
制約条件には、少なくとも次を含める。
| 制約カテゴリ | 例 |
|---|---|
| 推測禁止 | 不明な価格、仕様、契約条件を断定しない |
| 情報制限 | 個人情報、認証情報、社外秘、顧客名を含めない |
| 判断制限 | 法務判断、価格判断、SLA判断、採用判断をしない |
| 表現制限 | 顧客に責任を転嫁しない、原因未確定を断定しない |
| 操作制限 | 外部送信しない、DB更新しない、チケットを確定しない |
| 範囲制限 | 対象外市場、旧製品、廃止済み仕様を含めない |
| 根拠制限 | 出典不明の情報を確定情報扱いしない |
制約は、AIを不自由にするものではない。制約は、AIが安全に処理できる空間を定義する。
人間確認条件を先に書く
AIエージェント協働では、AIがどこまで進めてよいかを先に決める。特に次の操作は、人間確認条件として明示する。
顧客、取引先、社外への送信
契約、SLA、補償、価格に関する判断
本番環境の変更
データ削除、DB更新、権限変更
支払い、発注、課金
人事、採用、評価に関わる判断
セキュリティインシデントの外部報告
人間確認条件は、依頼文の末尾に書くのではなく、制約条件と同じ重みで扱う。
例: 顧客返信案
人間確認条件：
- 顧客へ送信する前にCS担当者が確認する。
- 原因、復旧予定、SLA影響、補償に触れる場合は技術責任者と契約責任者の確認を必須にする。
- 顧客名、契約情報、内部ログが本文に含まれる場合は出力を停止し、社内確認事項として分離する。
Request Contract の粒度
Request Contract は大きすぎても小さすぎても使いにくい。
大きすぎる依頼:
新サービスの市場調査、競合分析、価格戦略、営業資料、顧客向けメール、実行計画を全部作って。
これは、目的、判断、成果物、レビュー観点が混ざりすぎている。
小さすぎる依頼:
この文章を少し短くして。
これは、単発のプロンプトで十分である。
Request Contract に適した粒度は、1つの業務成果物に対応する大きさである。
| 粒度 | 適切性 | 理由 |
|---|---|---|
| 文章の言い換え | 低 | 単発プロンプトでよい |
| 競合比較表 | 高 | 目的、範囲、出力、受け入れ条件がある |
| 顧客返信案 | 高 | 制約、人間確認条件が必要 |
| 価格改定の最終判断 | 低 | 人間が判断すべき |
| 障害一次報告の下書き | 高 | AIは下書き、人間が承認 |
| 全社AI戦略の決定 | 低 | AIは材料作成、人間が意思決定 |
目安は、次である。
1つのRequest Contract = 1つのレビュー可能な成果物
複数の成果物が必要なら、第5章で扱う Task Brief に分解する。
実務ケース1: 競合調査の Request Contract
第2章で扱った「法人向けバックアップサービスの競合調査」を Request Contract にする。
目的：
当社の法人向けバックアップサービスの価格改定を検討するため、国内主要競合の価格体系、主要機能、対象顧客、強み、弱みを整理する。
最終成果物：
経営会議前の論点整理に使う競合比較表。
背景：
SMB向けプランの解約率が上昇しており、価格と機能の見直しを検討している。営業現場からは「競合の価格訴求が強い」という声があるが、比較軸が統一されていない。
対象範囲：
国内で法人向けクラウドバックアップまたは関連バックアップサービスを提供する主要5社。
除外範囲：
個人向けバックアップ、単純なオンラインストレージ、海外のみで提供されるサービス、価格情報が公開されていない非公開提案は除外する。
入力情報：
- 競合候補リスト
- 公開Webページ
- 過去の社内調査メモ
- 営業からの顧客要望メモ
利用してよい情報：
公開Web情報、社内限定の過去調査メモ、匿名化された顧客要望。
利用してはいけない情報：
顧客名、個別契約価格、未公開の商談情報、認証情報、個人情報。
制約条件：
- 不明な価格や仕様は推測しない。
- 価格改定の結論は出さない。
- 競合を誹謗する表現は使わない。
- 出典不明の情報は確定情報として扱わない。
判断基準：
経営会議で、価格改定の論点を整理できる粒度にする。営業資料ではなく、意思決定前の分析材料として扱う。
出力形式：
Markdown表。列は「会社名」「サービス名」「価格体系」「主要機能」「対象顧客」「強み」「弱み」「要確認事項」「出典」。
品質基準：
- 競合5社が並んでいる。
- 各社で価格体系、主要機能、対象顧客、強み、弱みが整理されている。
- 不明情報は要確認として分離されている。
- 出典が各社に付いている。
- 最後に経営会議で確認すべき論点を3〜5個挙げる。
不明点の扱い：
不明な情報は推測せず「要確認」と書く。仮定を置く場合は「仮定」と明記する。
途中確認が必要な条件：
主要5社の選定に迷う場合は、比較表作成前に候補リストを提示して確認を求める。
人間承認が必要な条件：
価格判断、競合評価、営業資料への転用、顧客向け説明に使う場合は事業責任者が確認する。
停止条件：
公開情報または社内で利用許可された情報だけでは比較表を作れない場合、作業を停止して不足情報を列挙する。
この Request Contract では、AIが比較表を作る範囲と、人間が判断する範囲が分かれている。AIは価格改定を決めない。AIは、意思決定に必要な材料を整理する。
Request Contract の作成手順
手順は次の4段階に統一する。
- 上位成果物、対象、入力、責任者を確認する。
- 許可範囲、禁止事項、受け入れ条件、停止・エスカレーション条件を定義する。
- 低リスクな最小単位で実行し、途中成果物と判断経路を記録する。
- 結果をレビュー・評価し、権限、教材、評価ケース、改善バックログへ戻す。
章固有の項目は前後の表と付録Aを使う。
Request Contract のレビュー観点
Request Contract 自体もレビューする。AI出力だけでなく、依頼の品質を見る。
| 観点 | 確認内容 |
|---|---|
| 目的 | 何のための依頼か明確か |
| 成果物 | 何が完成すればよいか分かるか |
| 対象範囲 | 含めるものと除外するものが分かるか |
| 入力 | AIが使う情報が明示されているか |
| 禁止情報 | 渡してはいけない情報が明示されているか |
| 制約 | 推測、断定、送信、判断の制限があるか |
| 出力形式 | 後工程で使える形か |
| 品質基準 | レビュー可能な基準になっているか |
| 不明点 | 質問、仮定、要確認、停止の扱いが決まっているか |
| 人間確認 | 顧客影響、契約、価格、本番変更などで止まるか |
| 停止条件 | 危険な場合にAIが作業を止められるか |
依頼のレビューは、管理職やAI推進担当が行うと効果が高い。優れた Request Contract は、個人のスキルではなく、組織の資産になる。
典型的な失敗
失敗1: 目的を書かない
目的がなければ、AIは何を優先すべきか分からない。競合調査でも、営業提案に使うのか、経営判断に使うのか、製品企画に使うのかで必要な観点は変わる。
失敗2: 出力形式を指定しない
AIは読みやすい文章を返すかもしれないが、再利用しにくいことがある。表、箇条書き、JSON、CSV、メール、議事録、Issue、ADRなど、後工程で使う形式を指定する。
失敗3: 推測と事実を分けさせない
AIは不明な情報を補完してしまうことがある。実務では、確定情報、推定、仮定、要確認を分ける必要がある。
設計原則
原則1: 依頼は目的から書く
AIに何をさせるかより、何のために必要かを先に書く。目的が明確なら、AIは構成や粒度を合わせやすい。
原則2: 成果物を1つにする
1つの Request Contract で1つのレビュー可能な成果物を作る。複数成果物が必要なら、Task Brief に分解する。
原則3: 出力を後工程に合わせる
出力形式は、読みやすさではなく後工程で決める。会議に使うなら表、チケットに貼るならIssue形式、システム連携するならJSON、顧客送信するならメール下書きである。
原則4: 禁止事項を明示する
AIへの依頼では、何をするかだけでなく、何をしないかが重要である。推測しない、断定しない、外部送信しない、法務判断しない、顧客名を出さない、といった禁止事項を書く。
原則5: 不明点を成果物に含める
不明点は失敗ではない。不明点を「要確認」として分離できれば、次に人間が確認すべき作業が明確になる。
原則6: 確認条件を先に書く
AIが処理を進めてよい範囲と、人間確認が必要な範囲を分ける。特にエージェントがツールを使う場合は、送信、更新、削除、課金、本番反映の前で止める。
原則7: 依頼自体を改善対象にする
AI出力が悪いとき、モデル、ツール、コンテキストだけでなく、Request Contract も見直す。良い依頼は、個人のノウハウではなく、組織のテンプレートにする。
作成する成果物: AIエージェント依頼書
AIエージェント依頼書の目的、責任境界、採否判断は前節までで定義した。記入時は 付録A: 成果物テンプレート集 の必須項目を使い、完成後は Artifact Index から後続成果物へ接続する。
チェックリスト
Request Contract をAIに渡す前に、次を確認する。
- 目的が書かれているか
- 最終成果物が1つに絞られているか
- 誰が使う成果物か分かるか
- 対象範囲と除外範囲が明確か
- 入力情報が明示されているか
- 利用してよい情報と、利用してはいけない情報が分かれているか
- 推測、断定、法務判断、顧客送信などの禁止事項が明示されているか
- 出力形式が後工程に合っているか
- 不明点の扱いが決まっているか
- 人間確認条件があるか
- 停止条件があるか
- 受け入れ条件でレビューできるか
関連するチェックリストは 付録B: チェックリスト集 を参照する。
演習
本章で扱った主要成果物を、自分の低リスクな業務1件について作成する。入力、受け入れ条件、人間が担う判断、停止条件を明記し、第三者が再現・レビューできれば合格とする。
章の受け入れ基準
読了時は、本章の主要成果物を第三者が再現・レビューできる状態にする。章別の正本は Chapter Acceptance Criteria を参照する。
関連書籍への接続
- Prompt / Context / Harness を技術実践として深掘りする場合は『AIエージェント実践: Prompt / Context / Harness Engineering』へ進む。
- Issue、DoD、受け入れ条件、レビュー可能な作業単位は『チケット駆動の仕事術』へ接続する。
- 調査依頼や根拠確認の設計は『根拠で進める開発仕事術』へ接続する。
- 顧客向け文章や対人コミュニケーションの設計は『エンジニアのための実践コミュニケーション設計』へ接続する。
Source Notes
この章では、特定モデル向けのプロンプト最適化テクニックには踏み込まない。モデル、UI、API、ツール実行機能は変化しやすいため、実装時には利用するAIツールの公式ドキュメントを確認する。本文で扱う Request Contract は、本書内の実務設計上の概念であり、特定ベンダーの仕様名ではない。
まとめ
AIへの依頼は、曖昧なお願いではなく、目的、成果物、制約、出力形式、受け入れ条件を含む契約として書く。Request Contract があれば、AIは作業しやすくなり、人間はレビューしやすくなる。
次章では、Request Contract を成立させるために必要な前提情報を扱う。依頼が明確でも、渡す文脈が古い、不完全、過剰、機密混入していれば、AIの出力は実務に使いにくい。第4章では、AIに渡す情報を Context Pack として設計する。