AIエージェントへの依頼書を標準化する方法――7項目と受け入れ手順

AIエージェントに仕事を任せたいのに、成果物の受け入れで結局すべてを読み直している。そんな運用者には、依頼書を7項目に固定する方法が効きます。

この型があれば、判断と監督は上位のAIに残し、手を動かす作業は下位のAIへ渡せます。読了後には、委任する仕事の選び方と、失敗を差し戻す境界を自分の環境に置けるはずです。

今回の工作展・第2期は全6回のうち5本目、中締めです。第2期の出発点は工作展、また開けます――第2期は『ラボを支える小さな道具たち』で示した通り、ラボを支える小さな道具たちでした。今回は物理的な道具の代わりに、仕事を渡すための依頼書を取り上げます。

課題は「分割できるか」ではなく「委任した方が得か」です

量産的な作業まで判断役が抱えると、判断、監督、受け入れに使うべき余力まで削られます。そこで2026-07-20に、委任は「作業を分割できるか」ではなく「委任した方が得か」で決める方針を置きました。

単一ファイルで、作業時間がおおよそ15分未満、かつ検証が自明な小さな作業は、上位のAIが直接扱って構いません。それ以外は、下位のAIへ渡すのが既定です。これは能力の序列ではなく、判断・監督・受け入れを量産作業から守るための役割分担です。

図1は、作業の難しさではなく、判断役の時間をどこに使うかで経路を選ぶ構成です。

図1で重要なのは、下位のAIに仕事を渡しても、検証まで丸ごと渡さない点です。上位のAIは量産作業には回さず、最後に差分と生の実行結果を見て受け入れます。

設計判断として、依頼書を7項目で閉じます

委任の単位は、自然言語のお願いではなく依頼書です。曖昧な「必要なら」は、実行できる明示条件へ置き換えます。同じ範囲を二つの依頼が同時に触る状態も作りません。

この7項目は、成果物の出来を魔法のように上げるものではありません。依頼者と実行者の間に残りがちな解釈の余地を、受け入れ前に減らすための枠です。下位のAIに渡す作業を細かくすれば必ず質が上がるわけではないことも、運用上は分かっています。細かさを上げる提案には、実測の裏付けを伴わせます。

仕事は、経路を決めてから最初の便を出します

全体図を読むだけで作ります

最初に、変更や作業の全体図を読み取りで作ります。この段階で書き込みを始めないため、後から依存関係を見失いにくくなります。

判断役の仕事と委任する仕事を分けます

次に、上位のAIが持つべき判断・監督・受け入れと、下位のAIに渡せる実務を仕分けます。意味がまだ定まらない判断は、依頼書に入れません。

実行経路を先に決めてから割り当てます

誰に頼むかより先に、どの経路で実行し、何が揃えば次へ進めるかを決めます。並行する依頼では書き込む範囲を重ねず、依存関係と開始条件を明記します。

承認と経路がそろえば実行へ進めます

承認と実行経路がそろったなら、提案のまま止めずに最初の便を出します。実行後は差分と生の実行結果から状況を組み立て直し、検証は上位のAIの持ち場で回します。リスクが高いときは、まっさらな文脈の確認役を立てます。

図2では、5段階目が提案止まりにならないこと、6段階目で検証が判断役へ戻ることを読み取ってください。実行側の報告だけでは、受け入れは完了しません。

受け入れは、実際に動いた記録から始めます

「設定しました」という自己申告と、実際に意図した経路で動いた事実は別です。この差を扱った前例は、「設定しました」は幻覚だった — AIエージェントの自己申告を検証するにも残しています。

受け入れでは、意図した宛先ではなく実際の記録から、どの経路・どのAIで動いたかを確認します。その後に差分を見て、依頼書に書いた検証コマンドを再実行します。複数の依頼がそろった場合は、統合の確認も必要です。

この二段構えは、失敗を無限に再試行させないための境界です。上位のAIが成果物を監督・検証する役回りについては、AIに企画会議と反証をさせて、アプリの要件書を作らせたでも別の角度から扱いました。実装を渡しても、意味の判断まで渡すわけではありません。

ハマり所は、依頼を細かくしすぎることです

依頼書を厳密にすると、仕事を際限なく細分化したくなります。しかし、細かさを上げれば必ず品質が上がるわけではありません。細かく分ける提案は実測で支え、得になるときだけ採用します。

もう一つの地雷は、同じ範囲を並行した依頼に触らせることです。競合を受け入れ段階で発見しても、何を根拠に直すべきかが曖昧になります。Allowed scopeとForbidden scopeを対にして書き、開始条件まで依頼書へ入れる理由はここにあります。

第2期の中締めでも、この型はまだ動いています

第2期は全6回のうち、この回を含めて残り1回です。依頼書は目立つ完成品ではありません。それでも、判断役を量産作業から離し、実務を次の便へ載せるための道具として、今も第2期の作業を運んでいます。

次にこの型へ載せるべきなのは、単に分けられる仕事ではなく、委任した方が得になる仕事でしょう。その候補を依頼書の7項目で書き切れるか、所長と一度見てみます。

コピペで再現

次のひな型を、依頼を出すたびに埋めてください。外部の仕組みを前提にせず、本文のまま使える最小再現物です。

Purpose:
- 目的:
- 成果:

Done conditions:
- 機械で判定できる完了条件:

Verify command:
- 実行する検証コマンド:

Allowed scope:
- 触ってよい範囲:

Forbidden scope:
- 触ってはいけない範囲:

Constraints and inputs:
- 前提:
- 入力:
- 開始条件:

Report:
- 結果:
- 変更点:
- 検証結果:
- 残るリスク:

前提条件：単一ファイル・作業時間がおおよそ15分未満・検証が自明な作業以外は、既定で下位のAIへ渡します。ビジネス上の意味が定まっていない判断は、依頼に入れません。

ハマり所：同じ範囲を複数の依頼で同時に触らせないこと。「必要なら」は明示条件へ直すこと。1回目の失敗は証拠付きで1回だけ差し戻し、2回目は仕事の分け方を書き直すか、上位のAIが引き取ることです。