AIエージェントを組織で使い始めると、失敗は実行中だけで起きるわけではありません。むしろ入口で「何をしてほしいのか」「どこまで触ってよいのか」「完了条件は何か」が曖昧なまま依頼を投げると、その後の context、承認、監査ログ、review gate をいくら整えても苦しくなります。
この記事では、AIエージェントへ作業を渡す前の 依頼受付設計 を扱います。1回の run に何を渡すかは AIエージェントのコンテキスト設計ガイド、agent 間でどう引き継ぐかは AIエージェント引き継ぎ設計ガイド、実行後の返却形式は AIエージェント出力契約設計ガイド、完了報告と実状態の突合は AIエージェント state reconciliation 設計ガイド に分けています。
今回の論点は、依頼が agent に渡る前に、受ける・分ける・止める・戻す判断をどう固定するかです。
先に結論: task intake は prompt の前に置く
AIエージェント運用で一番危ない依頼は、長い依頼ではありません。入口で分類されていない依頼です。
このあたり、いい感じに調べて直しておいて。この依頼は人間同士なら補足質問で回収できます。けれど、AIエージェントにそのまま渡すと、調査、設計、実装、外部 docs 参照、依存追加、PR 作成、コメント投稿までが1つの流れに混ざります。途中で権限を上げる判断も、失敗時に戻す判断も曖昧になります。
私なら、AIエージェントに渡す前に依頼を次の6項目へ分解します。
| 項目 | 決めること | 曖昧なまま渡すと起きること |
|---|---|---|
request_type | 調査、実装、レビュー、監視、整理、外部操作 | agent が勝手に作業種別を変える |
risk_class | read、draft、write、external action | 承認なしに副作用が広がる |
scope | 対象 repo、path、issue、期限 | 依頼外ファイルや外部サービスへ広がる |
done_when | 完了条件、必要な検証、返却形式 | 「完了しました」だけが残る |
missing_info | 足りない情報、質問すべき相手 | 推測で実装が進む |
routing | main agent、subagent、automation、人間 | 不向きな lane に載る |
task intake は、prompt をきれいにする作業ではありません。依頼を実行可能な作業単位へ変換し、危ない依頼を入口で止める設計です。
既存記事との役割分担
AIエージェント運用の記事は近いテーマが多いので、責務を先に切ります。
| 近いテーマ | 扱うこと | この記事で扱うこと |
|---|---|---|
| context engineering | run に渡す情報の選別 | run を作る前の受付、分類、分解 |
| handoff contract | agent A から agent B へ渡す契約 | 最初にどの lane へ渡すか |
| approval flow | tool call 直前の人間承認 | 依頼時点で承認が必要な作業を見分ける |
| output contract | 作業後に返す形式 | 依頼時点で返却形式を指定する |
| state reconciliation | 完了前の状態突合 | 完了条件を入口で定義する |
つまり task intake は、運用フローの最初に置くフィルターです。ここで失敗すると、後段の記事で扱っている設計が全部「後始末」になります。
intake で最初に見るべき5つの分類
私は AIエージェントへの依頼を、まず作業種別で分けます。
| 種別 | 例 | 既定 lane |
|---|---|---|
| research | 仕様調査、ログ要約、競合比較 | read-only agent |
| draft | PR本文案、設計案、runbook案 | main agent or subagent |
| change | ファイル編集、テスト追加、記事作成 | worktree / branch |
| review | PR review、security review、SEO review | reviewer agent |
| external action | comment投稿、deploy、ticket更新、token発行 | 人間承認つき |
この分類をしないまま「調べて直して」と渡すと、research のつもりが change になり、change のつもりが external action まで進みます。逆に、分類を先に固定すれば、agent がどの tool を使ってよいか、どの時点で承認へ戻すかが決めやすくなります。
OpenAI Agents SDK の orchestration and handoffs では、specialist に会話を引き継ぐ handoff と、manager が specialist を tool として呼ぶ形を分けています。これは intake にもそのまま使えます。依頼者に返す責任を agent が持つのか、manager が統合するのかを入口で決めます。
Claude Code の subagents も同じです。subagent は task-specific workflow と context isolation に向いていますが、説明が曖昧だと自動委譲の判断も曖昧になります。intake では「これは subagent に逃がす調査なのか、main conversation で人間と詰める作業なのか」を決める必要があります。
依頼をそのまま queue に入れない
依頼受付でよくある失敗は、ユーザーの自然文をそのまま queue item にすることです。
悪い queue item はこうです。
title: "ログを見て原因を直す"
body: "昨日から失敗しているのでお願いします"これでは、どのログか、何を直すのか、修正してよいのか、PR まで作るのかが分かりません。
私なら、queue に入れる前に次の形へ正規化します。
task_intake:
request_id: intake-20260704-ci-001
request_type: change
user_goal: "PR #214 の build failure を解消し、修正 PR を出す"
scope:
repository: "example/web"
allowed_paths:
- "src/lib/build-config.ts"
- "package.json"
out_of_scope:
- "deploy"
- "main branch への直接 push"
risk_class: write
lane: "worktree_change"
required_inputs:
- "CI run URL"
- "base branch"
done_when:
- "原因が説明されている"
- "修正 commit がある"
- "pnpm run build が通っている"
- "PR URL が返っている"
approval:
before:
- "依存追加"
- "外部 comment 投稿"
return_contract:
format: "deliverable / verification / risks / next_action"この形式なら、agent に渡す前に不足情報が見えます。CI run URL がなければ質問に戻す。依存追加が必要なら承認へ戻す。PR 作成まで必要なら worktree と branch を用意する。queue item は、依頼文ではなく実行契約に近づけます。
入口で止めるべき依頼を決める
task intake の価値は、依頼を流すことだけではありません。止めることにもあります。
私は次の依頼を入口で止めます。
| 止める条件 | 理由 | 戻し方 |
|---|---|---|
| 目的が曖昧 | 完了条件を作れない | clarification_required |
| 対象が広すぎる | 調査と変更が混ざる | 分割案を返す |
| 権限が過剰 | write / external action が先に出る | read-only 調査へ落とす |
| データ境界が不明 | secret / customer data を誤送信しやすい | 承認者と扱うデータを確認 |
| rollback 不能 | 外部副作用を戻せない | dry-run / draft へ変更 |
| 成果物がレビュー不能 | 後段で受け入れ判断できない | output contract を要求 |
これは慎重すぎるように見えますが、実務では入口で5分止める方が安いです。実行後に「どこまでやったのか」「なぜこの tool を使ったのか」「戻せるのか」を調べる方がずっと高くつきます。
Claude Code の hooks は、tool 実行前のブロック、通知、session start の context injection などに使えます。ただし hook は実行時の制御です。入口の intent が曖昧なまま hook だけ増やすと、承認ダイアログやブロック理由が増えるだけになります。intake で依頼を narrow にしてから、hook や approval を置く方が効きます。
lane を4つに分ける
AIエージェントの依頼受付では、全部を同じ agent queue に入れない方がよいです。私は最初に4つの lane だけ作ります。
| lane | 向いている依頼 | 許可する操作 |
|---|---|---|
read_only_research | 仕様調査、ログ要約、候補比較 | read、要約、質問返し |
draft_design | 設計案、PR本文案、runbook案 | draft、内部リンク案、差分案 |
worktree_change | コード修正、記事作成、設定変更 | branch / worktree 内の write |
external_action | comment、deploy、ticket更新、権限変更 | per-call approval |
これだけでも運用はかなり安定します。
たとえば、記事作成は worktree_change です。新規 Markdown、keyword-plan、llms 生成物、build、PR 作成までが成果物になります。一方、カニバリ調査だけなら read_only_research です。そこで記事まで書き始めるのは scope 逸脱です。
MCP の Tasks は、長い処理や deferred result retrieval を扱うための state machine として定義されています。仕様上も task は requestor-driven で、requestor 側が concurrent request の orchestration に十分な文脈を持つ前提です。この考え方は、入口で lane と request_id を持たせる設計と相性がよいです。
自動振り分けは最初から信用しない
AIで intake を自動化したくなるのは自然です。問い合わせ、GitHub issue、Slack、フォーム、定期 automation の結果を読み、依頼種別やリスクを分類する。これは有効です。
ただし、自動振り分けを最初から信頼しすぎると危険です。特に次の2つは間違えやすいです。
- research に見える write 依頼
- 軽い修正に見える外部副作用つき依頼
例:
この issue を見て、必要ならユーザーに返事しておいて。前半は read ですが、後半は external action です。AI が「返事しておいて」を軽く扱うと、外部 comment が残ります。入口では、文中の一番危険な操作に合わせて risk_class を上げるべきです。
自動振り分けを使うなら、最初は次のようにします。
triage_result:
request_type: research
risk_class: external_action
confidence: low
reason:
- "issue 調査は read"
- "ユーザー返信は external action"
decision: clarification_required
question: "調査結果の下書きまでで止めますか、それとも返信投稿まで承認しますか？"confidence: low の依頼は agent に投げず、人間へ戻します。振り分け精度を上げるより、低信頼を低信頼として扱えることの方が重要です。
dynamic workflow は intake が固まってから使う
Claude Code の dynamic workflows は、多数の subagent を script で orchestration し、codebase audit、大規模 migration、cross-checked research のような仕事に使えます。強力ですが、入口の依頼が曖昧なまま使うと、曖昧さが並列に増えます。
私は、dynamic workflow へ載せる前に次を確認します。
- 依頼を独立タスクへ分解できる
- 各タスクの allowed action が同じではない
- 中間結果を統合する owner が決まっている
- 途中で人間確認へ戻す条件がある
- 最終成果物の output contract が決まっている
これを満たさないなら、workflow ではなく単一 agent か read-only 調査から始めます。並列化は設計を良くしません。設計済みの依頼を速くするだけです。
実務テンプレ: task intake checklist
私は依頼受付時に、最低限この checklist を使います。
task_intake_checklist:
identity:
- "request_id がある"
- "依頼者と承認者が分かれているか確認した"
scope:
- "対象 repo / path / issue / customer を限定した"
- "out_of_scope を書いた"
risk:
- "read / draft / write / external action に分類した"
- "一番危険な操作に合わせて risk_class を上げた"
inputs:
- "必要な URL、ログ、branch、期限が揃っている"
- "secret や個人情報を渡していない"
routing:
- "read-only / draft / worktree / external action の lane を選んだ"
- "subagent、automation、人間のどれが owner か決めた"
completion:
- "done_when を3から5個に絞った"
- "検証コマンドと返却形式を指定した"
fallback:
- "不足情報なら質問へ戻す"
- "scope 逸脱なら分割する"
- "承認が必要なら止める"この checklist は、依頼者に見せてもよい形にしておくと便利です。AIエージェント運用の入口をブラックボックスにすると、「なぜこの依頼は止められたのか」が説明しにくくなります。受付時点の判断も監査ログへ残すべきです。
失敗パターン
1. 依頼文を長くすれば安全だと思う
長い依頼でも、scope と done_when が曖昧なら危険です。背景説明が多いほど、agent は関係ない情報まで拾います。長さではなく分類を増やします。
2. 低リスク調査に write を混ぜる
「調べて、必要なら直して」は便利ですが、運用上は2つの依頼です。まず read-only 調査で原因と修正案を返し、その後に worktree change へ昇格する方が安全です。
3. queue の優先度だけを決める
priority は重要ですが、risk_class と lane がない priority は弱いです。高優先度の external action を無人 lane に載せると、速く事故るだけです。
4. 受付結果を保存しない
依頼受付は会話の前処理ではありません。後で「なぜこの agent に渡したのか」を説明する証跡です。request_id、risk_class、lane、done_when、承認条件は保存します。
5. 不足情報を agent に推測させる
AIエージェントは不足情報を埋めようとします。だからこそ、intake で missing_info を明示し、足りないなら質問に戻します。推測で進めるより、入口で止めた方が結果は安定します。
まとめ
AIエージェント依頼受付設計は、運用の地味な入口です。ただし、ここを飛ばすと後段の context engineering、handoff、approval、output contract、state reconciliation が全部重くなります。
まずは自然文の依頼をそのまま agent に渡さず、request_type、risk_class、scope、done_when、missing_info、routing に分解します。read-only、draft、worktree change、external action の4 lane へ分け、曖昧な依頼は clarification_required として返します。
AIエージェントを安全に使うコツは、賢い agent に全部任せることではありません。任せる前に、受けられる依頼と受けてはいけない依頼を決めることです。task intake を設計すると、AIエージェントの仕事は「何となく便利」から「レビューできる作業単位」へ近づきます。