AIエージェントに仕事を任せる技術：依頼票・検収・引き継ぎの実践

AIエージェントへ仕事を任せるときは、「何を考えてほしいか」より「何ができたら終了か」を先に書きます。

依頼票、途中のチェックポイント、最後の検収、次の担当への引き継ぎを一つの流れにすると、人間が付きっきりにならなくても品質を管理しやすくなります。

この記事では、開発初心者でも使える依頼票の作り方を説明します。コード修正だけでなく、調査、原稿、ファイル点検にも使える方法です。

AIエージェントに任せる仕事は「小さく、観察でき、戻せる」ものから選ぶ

ここでいうAIエージェントとは、質問に答えるだけでなく、ファイルを読み、変更し、コマンドを実行し、その結果を見て次の行動を選ぶ仕組みです。

普通のチャットが「道を教える案内係」なら、AIエージェントは「地図と鍵を受け取り、荷物を運ぶ担当者」に近い存在です。

ただし、仕事を任せることと、判断をすべて手放すことは別です。人間は目的、触れてよい範囲、終了条件を決めます。AIエージェントは、その枠内で調査、変更、検証を進めます。

最初に任せる仕事は、次の3条件で選ぶと安全です。

1. 結果を目で見たり、テストしたりできる。
2. 失敗しても元へ戻しやすい。
3. 触るファイルや情報を狭く指定できる。

GitHub公式も、AIへ渡す仕事には、解決する問題、よい解決の受け入れ条件、変更対象ファイルを明確に含めるよう案内しています。最初は簡単で範囲の狭い仕事から始める考え方です。詳しくはGitHub Copilotへ仕事を渡すベストプラクティスで確認できます。

仕事を選ぶときは、次の早見表を使えます。

仕事の特徴	最初から任せやすいか	任せ方
短い文書の点検	高い	読み取りだけにし、不足情報を一覧にする
限定したバグ調査	高い	再現手順と原因候補までを成果物にする
既存機能のテスト追加	高い	対象関数とテストファイルを指定する
複数機能の作り直し	低い	調査、設計、実装を別の依頼へ分ける
顧客情報を含む作業	低い	必要性と権限を確認し、情報を最小限にする
本番公開やデータ削除	低い	準備まで任せ、実行前を人間の確認地点にする
仕様が決まっていない企画	低い	選択肢と判断材料の整理だけを先に頼む

「このアプリをいい感じに直して」では、正解の境界が分かりません。色を変えるのか、エラーを直すのか、設計を作り直すのかが分かれるからです。

曖昧で大きな仕事は、AIの能力だけで解決しようとしません。「エラーの再現」「原因候補の整理」「最小修正」「動作確認」のように分けます。

OpenAIの実務ガイドも、仕事を小さな手順へ分け、各手順を具体的な行動や出力として書く考え方を示しています。また、読み取りか書き込みか、元へ戻せるか、権限や金銭へ影響するかで危険度を考えます。詳しくはAIエージェント構築の実践ガイドを参照してください。

つまり、最初に見るのは「AIならできそうか」だけではありません。「結果を観察できるか」「失敗を戻せるか」「影響を限定できるか」を一緒に見ます。

依頼票は「目的・成果物・担当範囲・合格条件・停止条件」の5項目で作る

依頼票は、AIエージェントへ渡す短い作業指示書です。長い仕様書を書く必要はありません。次の5項目がそろっていることが大切です。

項目	書く内容	悪い例	よい例
目的	誰の何を改善するか	使いやすくする	初回利用者が迷わず文章を保存できるようにする
成果物	最後に何を残すか	修正して	src/save.tsの修正と対応テストを残す
担当範囲	読んでよい場所、変えてよい場所	全体を見て	src/save.tsとtests/save.test.tsだけ変更する
合格条件	観察できる終了状態	ちゃんと動く	指定テストが成功し、空入力では警告が出る
停止条件	人間へ判断を戻す境界	特になし	依存追加、データ削除、外部送信の前で止まる

合格条件は、受け入れ条件（完成と判定するための観察できる条件）とも呼ばれます。「高品質にする」のような形容詞ではなく、操作と結果を書きます。

たとえば、「保存処理を改善する」だけでは合否を決めにくいでしょう。「文章を入力して保存を押すと、再読み込み後も文章が残る」なら、実際に試せます。

Anthropic公式も、AI自身が合否を確かめられる手段として、テスト、ビルドの終了コード、リンター、期待値との比較、スクリーンショットなどを挙げています。終了コードとは、コマンドが成功したか失敗したかを返す番号です。詳しくはClaude Codeのベストプラクティスで確認できます。

そのまま使える最小テンプレートは次の形です。

目的：
成果物：
担当範囲：
合格条件：
停止条件：

作業後の報告：
- 変更したファイル
- 実行した確認コマンド
- コマンドの結果
- 未確認の項目
- 次に必要な1手

依頼票を作るときは、次の順番で埋めます。

1. 目的に「誰が、何に困っているか」を書く。
2. 成果物に「最後に残る物」を書く。
3. 担当範囲に「読んでよい場所」と「変えてよい場所」を分けて書く。
4. 合格条件に「人間が観察できる動作」または「実行する検査」を書く。
5. 停止条件に「推測で進めてはいけない地点」を書く。

依頼票は長ければよいわけではありません。関係のない背景を増やすと、重要な条件が埋もれます。必要なファイル、期待する結果、よい例があるなら、それらを直接示します。

特に大切なのは、担当範囲を「読む範囲」と「変える範囲」に分けることです。原因調査では広く読めても、修正してよいのは2ファイルだけ、という依頼もあります。

停止条件は失敗を防ぐだけではありません。情報が足りない場面で、AIエージェントが勝手な前提を作るのを防ぎます。

たとえば、次のように書けます。

情報が足りない場合は、既存の動きを変えない案を選ぶ。
合格条件を判断できない場合は、未実装のまま必要情報を報告する。
担当範囲外の変更、外部送信、削除、課金が必要なら、その直前で止まる。

この3行があると、無人実行でも「返事がないので全部停止」と「危険な推測で進む」の間に、安全な退避先を作れます。

作業は「調査→計画→変更→検証」の4段階に分ける

一つの依頼でも、作業は4段階に分けます。

1. 調査：関連ファイル、既存ルール、現在の動きを確認する。
2. 計画：原因候補を絞り、最小の変更案と確認方法を決める。
3. 変更：担当範囲内だけを編集する。
4. 検証：合格条件と実際の結果を照らし合わせる。

この順番は、料理の「材料確認、手順確認、調理、味見」と同じです。材料を見ずに火を付けたり、味見をせずに食卓へ出したりしないための区切りです。

小さな誤字修正なら、計画は1行でも構いません。一方、初めて触るプロジェクトや、複数ファイルに関係する不具合では、最初の依頼を読み取り専用にします。

まずファイルを変更せずに調査してください。
原因候補、関係ファイル、最小の修正案、
修正後に実行する確認を報告してください。

調査の結果を見てから変更へ進むと、見当違いの大改修を避けやすくなります。Anthropic公式も、調査、計画、実装を分ける進め方を案内しています。

コード作業では、確認コマンドまで依頼票へ入れると終了判定が明瞭になります。JavaScriptのプロジェクトなら、たとえば次の形です。

npm test -- save
npm run lint
git diff -- src/save.ts tests/save.test.ts

git diffは、変更前後の違いを見るコマンドです。この違いを差分と呼びます。原稿の赤字校正に近いものです。

テストが成功しても、担当外のファイルが変わっていないとは限りません。テストは動作を見ます。差分は変更範囲を見ます。リンターは書き方の問題を見ます。実画面は見た目や操作を見ます。

それぞれが見つける問題は異なります。どれか1つで正しさ全体を保証するものではありません。

チェックポイントは時間ではなく状態で置く

「30分ごとに報告」と決めても、作業の切れ目と報告時刻は一致しません。代わりに、状態が変わる地点へチェックポイントを置きます。

• 原因を1つに絞った時点。
• 初めて指定テストが成功した時点。
• 担当範囲外の変更が必要だと分かった時点。
• 決めた失敗回数へ達した時点。
• 外部送信、削除、課金など影響の大きな操作へ進む直前。

チェックポイントの目的は、進捗を眺めることではありません。間違った方向へ進む距離を短くすることです。

OpenAIの実務ガイドは、人へ判断を戻す代表的な条件として、決めた失敗や試行の上限を超えた場合と、機密性、元へ戻しにくさ、重要性が高い操作を挙げています。停止条件は「AIが苦手そうだから止める」という感覚ではなく、状態として書けます。

NISTのAI RMF Coreも、人とAIの役割と責任を定め、導入前と運用中にテストし、評価方法と結果を文書化する考え方を示しています。NIST AI RMF Coreは改定作業中の資料です。法的義務としてではなく、役割分担と記録の参考として扱います。

無人実行では退避方法を先に決める

途中で質問に答える人がいない実行では、情報不足への対応も依頼票へ入れます。

1. 既存の動きを変えない案があれば、それを選ぶ。
2. 判断できない項目は未実装として残す。
3. 分かったこと、足りない情報、次の確認方法を報告する。
4. 停止条件に触れる操作は実行しない。

この決め方なら、一つの不明点で安全な調査まで止まることを減らせます。同時に、公開や削除まで推測で進むことも防げます。

検収と引き継ぎは、説明ではなく証拠をつなぐ

検収とは、納品物が合格条件を満たすか確かめる作業です。AIエージェントの「完了しました」という文章だけではなく、次の4種類の証拠を見ます。

1. 変更ファイル一覧：頼んだ範囲と一致するか。
2. 差分：目的に関係しない変更が混じっていないか。
3. 実行コマンドと生の結果：検査を実際に実行したか。
4. 未確認事項と残る危険：確認できなかった環境や条件が書かれているか。

良い完了報告は、成功だけでなく失敗も残します。

変更：
- src/save.ts
- tests/save.test.ts

実行：npm test -- save
結果：12件成功、0件失敗

実行：npm run e2e
結果：ブラウザ未導入のため未実行
次の確認：テスト用ブラウザを準備した環境で再実行

担当範囲外の変更：なし
残る確認：スマホ実機の表示

「全部問題ありません」より、どこまで機械で確認し、どこからが未確認か分かる報告のほうが役立ちます。

テスト成功は重要な証拠です。しかし、画面崩れ、秘密情報の混入、頼んでいないファイルの変更、未実行の検査までは否定できません。

GitHub公式も、Copilotが作ったプルリクエストを、ほかの成果と同じように十分レビューするよう案内しています。また、2026-07-27確認時点では、Copilotが変更を送った場合のGitHub Actionsは既定で自動実行されません。特に.github/workflows/の変更を確認してから実行を承認する製品固有の手順があります。詳しくはCopilotの出力をレビューする手順で確認できます。

重要な仕事では、独立レビューも加えます。独立レビューとは、作業した本人とは別の視点による確認です。

NIST AI RMF Coreは、開発の当事者ではない人を評価へ関与させる考え方を示しています。別の視点は、内部の思い込みや利害による偏りを抑える助けになります。

ただし、別の人や別のAIが見たこと自体を合格証にはできません。依頼票の合格条件、差分、テスト結果を同じ基準で見ます。

検収表で合否を分ける

受け取り側は、次の表へ一つずつ印を付けます。

確認項目	合格の目安	未合格ならすること
成果物	指定したファイルや報告がそろう	足りない成果物だけを再依頼する
担当範囲	変更が許可した場所に収まる	担当外の差分を分けて理由を確認する
合格条件	指定した操作やテストの結果が合う	失敗条件を固定して修正へ戻す
停止条件	危険操作を勝手に進めていない	影響範囲を確認し、人間が判断する
未確認事項	未実行と失敗が分けて書かれる	次に必要な環境や情報を特定する

説明が上手でも証拠が足りなければ、検収は未完了です。反対に、確認できなかったことを正直に分けた報告は、次の作業へつなげられます。

引き継ぎメモには「現在地・証拠・次の一手」を残す

作業が1回で終わらない場合は、別のAIや翌日の自分が再調査しなくてよい形で引き継ぎます。

会話ログを丸ごと渡すだけでは、重要な決定が埋もれます。次の固定項目へ短く抜き出します。

目的：
担当範囲：

完了済み：
未完了：

変更ファイル：
決定事項と理由：

実行コマンドと結果：
残る危険・未確認：

次に最初に行う1手：

引き継ぎメモへパスワード、認証情報、秘密鍵、不要な個人情報は複写しません。必要な権限があることだけを書き、秘密そのものは正規の保管場所に残します。

再開する人は、次の順に読みます。

1. 目的と担当範囲を読み、仕事の境界を戻す。
2. 完了済みと未完了を分け、同じ作業を繰り返さない。
3. 変更ファイルと差分を見て、現在の状態を確かめる。
4. コマンド結果と残る危険を見て、証拠の範囲を知る。
5. 「次に最初に行う1手」から再開する。

製品によっては会話を再開する機能もあります。Claude Codeでは、2026-07-27確認時点の公式案内で、claude --continueは現在のディレクトリの直近セッション、claude --resumeまたは/resumeは選択したセッションの再開に使えます。詳しくはClaude Codeの一般的な作業手順を参照してください。

会話再開は便利な補助です。しかし、重要情報を会話履歴だけに置くと、別の製品や別の担当へ移れません。目的、現在地、証拠、未完了、次の一手は、自己完結したメモにも残します。

初心者向け実践：既存ファイル1つを読み取り専用で点検する

最初の一件には、公開や削除を伴わない点検が向いています。READMEや短い設定ファイルを一つ選びます。

次の依頼票をそのまま使えます。

目的：
このスクリプトを初めて読む人が、実行方法を理解できる状態にする。

成果物：
不足情報の一覧と、READMEの修正案。

担当範囲：
README.mdと対象スクリプトを読み取る。
今回はファイルを変更しない。

合格条件：
必要環境、実行コマンド、成功時の表示、
失敗時の確認先が分かる。

停止条件：
推測で仕様を補わない。
不明な点は「不明」として報告する。
外部送信、削除、課金は行わない。

作業後の報告：
- 読んだファイル
- 分かったこと
- 不足情報
- 修正案
- 未確認事項

結果を受け取ったら、次の順に検収します。

1. 読んだファイルが担当範囲内か確認する。
2. 不足情報が合格条件の4項目に対応するか確認する。
3. 推測と確認済みの事実が分かれているか確認する。
4. ファイルが変更されていないか差分で確認する。
5. 次に修正を頼むなら、変更してよい場所を新しい依頼票へ書く。

うまくいかなかったときは、AIの能力だけを疑いません。「成果物の形」「担当範囲」「合格条件」のどれが曖昧だったかを一つ選び、そこだけ直します。

一度に全部を書き換えると、どの改善が効いたか分からなくなります。1項目ずつ直すと、次回も使える依頼票へ育てられます。

よくある質問

依頼票は長く書くほどAIエージェントの精度が上がりますか？

長さより、問題、成果物、対象範囲、観察できる合格条件、例外時の行動が明確かどうかが重要です。

関係のない背景は増やしません。必要なファイル、期待する出力、よい例を直接示します。長い資料が必要なら、「何の判断に使う資料か」も一言添えます。

初めてAIエージェントへ任せるなら、どんな仕事が向いていますか？

公開、削除、本番変更を伴わない、短い文書の点検、限定したバグ調査、既存機能のテスト追加が向いています。

結果を確認でき、失敗しても戻せて、対象範囲を狭く書ける仕事を選びます。広範囲、機密、重要な業務判断を含む仕事は、安全な小工程へ分けます。

どんな場合にAIを止めて人間へ判断を戻すべきですか？

決めた失敗回数を超えたとき、担当範囲外の変更が必要になったとき、情報不足で合格条件を判定できないときが代表例です。

機密情報、元へ戻しにくい変更、外部送信、削除、課金など、影響の大きい操作へ進む前も確認地点にします。組織や利用製品の権限設定と規約がある場合は、そちらを優先します。

テストが成功すれば、そのまま採用してよいですか？

テスト成功は大切な証拠ですが、それだけでは足りません。

担当外の変更、画面崩れ、秘密の混入、未実行の検査は別に確認します。変更ファイル、差分、実画面、未確認事項を分けて検収します。重要な変更では、作業者とは別の視点も加えます。

新しいセッションや別のAIへ、何を渡せば作業を再開できますか？

元の目的、担当範囲、完了済み、未完了、変更ファイル、決定理由、実行コマンドと結果、残る危険、次の1手を渡します。

会話履歴が残っていても、重要事項は短い引き継ぎメモへ抜き出します。秘密、認証情報、不要な個人情報はメモへ複写しません。

公式一次情報

確認日: 2026-07-27

• Best practices for Claude Code: 調査・計画・実装の分割と、テスト出力やコマンド結果など検証可能な証拠を使う方法が説明されています。
• Common workflows: Claude Codeの計画確認や、保存された会話を再開する製品固有の手順が説明されています。
• Best practices for using GitHub Copilot to work on tasks: 問題、受け入れ条件、変更対象ファイルを明確にし、範囲の狭い仕事から始める考え方が示されています。
• Review output from Copilot: Copilotが作った変更も十分にレビューし、ワークフロー変更を確認してから実行を承認する手順が案内されています。
• A practical guide to building agents: 明確な手順、例外処理、危険度による停止、人への引き継ぎという実務上の設計が説明されています。
• AI RMF Core: 人とAIの役割分担、導入前と運用中のテスト、評価結果の文書化、独立した視点による評価が整理されています。

まとめ

• 公開や削除を伴わない既存ファイルを1つ選び、まず読み取り専用の点検を任せる。
• 「目的・成果物・担当範囲・合格条件・停止条件」の5項目を埋め、状態でチェックポイントを置く。
• 変更一覧、差分、コマンド結果、未確認事項を検収し、「現在地・証拠・次の一手」を引き継ぎメモへ残す。