AIエージェントのスコープ文書の書き方

2026年8月公開。

TL;DR： スコープ文書は、「自分のビジネス用にAIエージェントが欲しい」という漠然とした依頼を、見積もり可能な数字とクライアントが承認できる合意に変えるものです。必要なのは6つの要素——トリガー、入力、出力、触れるツール、明示的な除外事項、そして書面の受け入れテストリストです。構築費を見積もる前に書いてください、後からではなく。私はこれを構築とは別に、$500〜$1,000の定額監査成果物として価格設定しています。

[オペレーターの視点] 私はコンサルティングブランドとPickleland（テキサス州プフルーグビルのピックルボール施設）を通じて、本番環境で30以上のエージェントを運用しており、その経験の上でクライアント向けのエージェント構築のスコープ設定も行ってきました。エージェント案件がうまくいかなくなる最大の理由はコードではありません——請求書が発行される前に、誰も「完了」の意味を書き留めていなかったことです。スコープ文書は、これを一度の作業で解決します。私が納品する成果物の中で最も地味なものですが、最も多くの争いを未然に防いでくれるものでもあります。

目次

なぜ提案メールではなくスコープ文書なのか

提案メールは、あなたが何をするかを説明します。スコープ文書は「完了」がどのようなものかを定義します——完成したエージェントと照らし合わせて、あなたとクライアントの双方が、会話をせずとも合格したかどうかに合意できるほど具体的にです。

この区別が重要なのは、AIエージェントの料金設定が機能するのは、構築費が何か固定されたものに紐づいている場合に限られるからです。未定義のスコープに対して固定価格を見積もれば、実際には納品できない数字を見積もったことになります——クライアントの「自分のビジネス用のAIエージェント」というメンタルモデルは、あなたが押し返すまで無償で膨張し続けます。そして、デポジットを受け取った後に押し返すのは、その前に境界線を定義しておくよりもずっと悪い会話になります。

私はすべての構築案件について、小さなものも含めてスコープ文書を書きます。単一ワークフローのエージェントなら半ページ版で済みますし、マルチエージェントシステムならフルバージョンの文書になります。フォーマットは変わりません——変わるのは長さだけです。

スコープ文書に必要な6つの要素

1. トリガー。 何がエージェントの実行を開始させるか——フォーム送信、スケジュールされた時刻、受信メール、他のツールからのWebhookなどです。トリガーのカテゴリではなく、正確なトリガーを名指ししてください。「リードフォームが送信されたときに実行する」はスコープです。「受信リードを処理する」はスコープではありません。

2. 入力。 エージェントが受け取るデータと、その出所です。ソースだけでなく、フィールドをリストしてください——「フォームデータ」ではなく、「Typeformの送信内容から、氏名、メールアドレス、会社規模、自由記述メッセージ欄」のようにです。

3. 出力。 エージェントが生み出すものと、それがどこへ送られるかです。ルールは同じです——送信先とフォーマットを名指ししてください。「人間の承認のために#leads Slackチャンネルに下書きの返信を投稿する」はスコープです。「リードに返信する」はスコープではありません。

4. 触れるツールと統合。 エージェントが呼び出すすべてのAPI、データベース、プラットフォームです。ここは、明示的に統合しないものを書き留める場所でもあります——ディスカバリーコールで一度触れただけなのに、自分のCRMが含まれていると思い込んでいるクライアントは、私がこれまで見た中で最も多いスコープの膨張の原因です。

5. 除外事項。 関連しているように聞こえたとしても、エージェントがやらないことの短く明示的なリストです。リード分類エージェントを構築しているなら、それが当たり前に思えても「送信メッセージは送らない」と書いてください——あなたにとって当たり前でも、ソフトウェアのスコープ設定をしたことのないクライアントにとっては当たり前ではありません。

6. 受け入れテストリスト。 最終支払いが発生する前に、完成したエージェントが合格すべき実際のケースのリストです。「うまく動く」ではなく——具体的でチェック可能なケースです。「提供されたデータセットのサンプルリード10件中9件を正しく分類する」「手動介入なしで、接続されたSlackチャンネルへの投稿に成功する」「不正な送信（メールフィールドが欠落している）をクラッシュせずに処理する」など。これが文書の中で最も重要なセクションです。なぜなら、後になって「意味していたこと」を蒸し返さずに、双方が指し示せる唯一のセクションだからです。

テンプレート

これは私が実際に使っている構造です。コピーして6つのセクションを埋めれば、価格を付けられる文書が出来上がります。

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

構築費とリテイナーの行があるのは、価格がその上のスコープに直接アンカーされるようにするためです——構築の価格を決めたことがないなら、両方の数字をどう決めるかを参照してください。クライアントがこの文書に署名することは、同じ一つの動作でスコープと価格の両方に承認することを意味します——それがポイントです。

この文書を生み出す通話をどう進めるか

私はスコーピングセッション自体を、構築費とは別の、定額$500〜$1,000の監査として価格設定しています——クライアントが実際に進めることになった場合でも、構築費に組み込むことは決してありません。理由は2つあります。スコーピング段階が無償の営業活動になるのを防ぐこと、そしてクライアントに無料相談としてではなく、真剣にこの通話に臨んでもらうことです。

通話自体は30〜45分で、上記の6つのセクションの順番に沿って構成されています。私は会話が「AIエージェントが理論上あなたのビジネスのために何をできるか」という方向に脱線するのを許しません——それは別の、より高くつく会話であり、誰も価格を付けられない文書を生み出すものです。私はまずトリガーを尋ねます。プロセスを開始させるものを名指しできないクライアントは、たいてい自動化するにはまだ十分に安定したワークフローを持っていないからです——これは、どちらかが構築にコミットする前に明らかにしておく価値があります。

白紙のページではなく、プロンプトを出す

私は文書の初稿を手書きしません。通話メモ——たいていは箇条書きの乱雑な段落にすぎません——を取り、これをClaudeに貼り付けます。

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

最後の指示——ギャップを埋めるのではなくフラグを立てる——が重要な部分です。モデルは、文書を完成させるためにもっともらしく聞こえる受け入れテストを喜んででっち上げます。そして、クライアントが実際に意図したこととずれた「もっともらしいテスト」は、聞きに行かなければならない空欄よりも悪いものです。

いまだに見かけるよくある間違い

除外事項セクションを最後に書く、あるいは省略する。 除外事項セクションは、多くの人が任意だと考えているものです。しかし、最も多くの争いを防いでくれるのがこのセクションです。受け入れテストの前に書いてください、後ではなく。

結果ではなく振る舞いを記述する受け入れテスト。 「エージェントはクライアントのトーンを理解すべきだ」は振る舞いです。「エージェントの下書き返信がサンプルケース10件中7件で編集なしに承認される」は結果です。チェック可能なのは結果だけです。

書面のメモなしに、たった一度の会話だけでスコープを決める。 スコープ文書が案件の最初の書面の成果物である場合、あなたは数日後に記憶から通話を再構築していることになります。通話中に、6セクションの順番でメモを取ってください。そうすれば文書はほぼ自動的に書き上がります。

クライアントにスコープを書かせる。 クライアントが自分の言葉で欲しいものを説明することは、文書への入力であって、文書そのものではありません。彼らの言葉は通常、機能の形をしています（「自分のリードを処理してほしい」）が、テストの形にはなっていません。それをチェック可能な受け入れ基準に翻訳することこそが、スコーピングセッションの実際の価値です——だからこそ、これは有料の成果物であり、クライアント自身が記入するフォームではないのです。

この業務を回すために使っているツール

Claude は、上記のプロンプトを使って生の通話メモから文書の下書きを作成し、推測で埋めるのではなくギャップにフラグを立てます。

Notion は、完成したスコープ文書が置かれる場所であり、デポジットを受け取る前にクライアントと共有します——案件のその他の記録を保管しているのと同じ場所です。

Airtable は、どの案件がスコーピング中で、どれが署名済みで、どれが構築中かを、クライアントごとに1行でトラッキングします。これにより、スコープ文書が誰にも気づかれないまま何週間も未署名で放置されることがなくなります。

FAQ

スコープ文書はどのくらいの長さにすべきですか？

すべての受け入れテストをチェック可能にするのに必要な長さだけで十分です、それ以上は不要です。単一ワークフローのエージェントなら半ページかもしれません。複数の統合を持つマルチエージェントシステムなら2〜3ページになることもあります。長さがゴールではありません——クライアントと開発者がそれぞれ独立して受け入れテストを読み、合格したかどうかに合意できることがゴールです。

署名後にクライアントがスコープを変更したいと言ったらどうしますか？

それは変更要望であり、別料金で、作業開始前に見積もります——その条件を、上記のテンプレートのように文書自体に書き込んでください。署名後に静かに膨張させられるスコープ文書は、実際にはスコープ文書ではありません。

非常に小さな自動化にもスコープ文書は必要ですか？

はい、短いものでかまいません。価値は長さではありません——構築を始める前に書面の受け入れテストリストを持っていること、それによって「完了」が感覚ではなくチェックリストになることです。まさにこの理由で、非公式にスコープ設定した小さな案件が、きちんとスコープ設定した大きな案件よりも長引いた経験があります。

スコープ文書そのものは誰のものですか——それは成果物の一部ですか？

構築に進むかどうかにかかわらず、クライアントがそれを生み出した監査の代金を支払っている以上、私はこれをクライアントが保持すべきものとして扱っています。私が保持するのは、根底にあるテンプレートとプロンプトです——案件をまたいで再利用可能な足場を保持しているのと同じやり方です。文書の構造は私のものであり、彼らの具体的なビジネスについて書き込まれた内容は彼らのものです。

次のステップ： 私のAI Agents for Beginnersコースは、このようなスコープ文書が記述するエージェントの構築を扱っています。コワークプログラムは、この種の業務のスコープ設定と構築を練習するための構造化された環境を求めるオペレーターのためのものです。代わりにスコープ文書を書いてほしい場合は、30分のセッションを予約してください。