AIエージェントに仕事を渡す技術——タスクを「検証できる単位」に割る

AIエージェントへのタスク委譲は、指示の丁寧さではなく「完了条件を機械で判定できる単位に割れているか」で成否がほぼ決まります。 私たちが1人＋AIで4プロダクトと公式サイトの日次運用を回すなかで、直近に表面化した委譲の失敗3件は、いずれもモデルが指示を誤解したのではなく、指示に完了条件が書かれていなかったことが原因でした。この記事では、実際に壊れた指示文とその修正を一次体験として公開し、そこから引いた分解の基準をまとめます。

TL;DR

• 1タスク＝1つの検証可能な完了条件。「〜して」で終わる指示は、たいてい何をもって終わりかが書かれていない
• 件数・範囲・形式の期待値を指示に含める。「全部取って」は全部取れたかを判定できない
• エージェントが観測した値（画面の状態・属性）は真実とは限らない。判定根拠を指定する
• 委譲の宛先は人ではなく工程にする。「後で誰かがやる」は実行されない

前提——ワークフローとエージェントを分けて考える

Anthropic のエンジニアリングチームは、Building effective agents で、実装が成功している事例の共通点をこう書いています。

"Consistently, the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns." （成功している実装は一貫して、複雑なフレームワークや専用ライブラリを使っていなかった。単純で組み合わせ可能なパターンで作られていた） — Anthropic エンジニアリングチーム

同記事は、手順が事前に決まっているものをワークフロー、モデル自身が手順を決めるものをエージェントとして区別しています。委譲設計で最初にすべきなのはこの仕分けです。手順が決まっているならスクリプトに落とし、決められない部分だけを渡す。判断の余地を残す範囲＝壊れうる範囲だからです。

実際に壊れた3つの指示

① 「全件取得して」——件数の期待値がない

外部サービスの管理画面から自分のアカウントの投稿指標を取得する処理で、一覧ページを一気に最下部までスクロールさせたところ、取得件数が実際より大幅に少なくなりました。原因は画面が仮想スクロールで、飛ばすと途中の行がDOMから消えることでした。

エージェントは指示通り「一覧を取得」し、正常終了しています。抜けを検知できなかったのは、何件取れれば成功かが指示にも検証にも無かったからです。

修正後の指示はこうなりました——「一覧を500pxずつスクロールし、各回で行を収集してIDをキーに辞書へ蓄積する。プロフィールに表示された総件数と一致するまで繰り返し、一致しなければ失敗として報告する」。完了条件が数値になった時点で、同じ失敗は自動的に検知されます。

② 「差分を渡す」——入出力の契約が食い違う

集計データを外部スプレッドシートへ同期する処理で、追記モードに差分だけのCSVを渡したところ、0行が同期される結果になりました。そのコマンドは「渡されたCSV全体が正本であり、シートの既存行数を超えた分を追記する」設計だったためです。差分を渡すと既存行数に届かず、追記対象が空になります。

これはモデルの問題ではなく、インターフェースの前提を指示側が知らなかっただけです。委譲するときは「何を渡すか」ではなく「受け手が何を前提に動くか」を書く必要があります。今は累積ファイル全体を渡す前提を、コマンドの説明そのものに書いています。

③ 「状態を見て判断して」——観測が嘘をつく

ある画面で、要素が押下済みかどうかを aria-pressed 属性で判定させたところ、全件が true を返しました。実際には未処理の項目が大半でした。アクセシビリティ属性が状態を反映しておらず、実際に信頼できる判定材料はアイコンの計算後の色だけだったのです（クリック前後で1→0→1と変化することを実測して確定しました）。

教訓は明確です。エージェントが「見た」と報告する値は、そのUIが正しく状態を表現している場合にのみ正しい。 判定根拠を指示側で固定するか、「根拠が正しいことを最初に1件で検証してから全件に適用する」手順を挟むべきです。

タスクを割る4つの基準

3件の共通構造から、私たちは委譲前チェックを4項目にしました。

1. 完了条件が機械で判定できるか。 「確認して」ではなく「件数がNと一致すること」「exit 0 かつ出力ファイルの行数が10以上」のように書く
2. 必要な文脈がタスク内に閉じているか。 前のタスクの記憶や、口頭で共有した前提に依存しない。依存するなら、その前提を指示文に転記する
3. 失敗したときに戻せるか。 破壊的操作（上書き・削除・外部への送信）を含むタスクは、まず対象を列挙して報告させ、実行は別タスクに分ける
4. 受け手が工程として定義されているか。 「デプロイ後にシェル側で実施」のような、宛先が人でも工程でもない委譲は実行されません（この型の障害は無言の失敗で詳しく扱いました）

とくに1と4は、指示を書く時間が5分増える代わりに、壊れたまま数日走る事故を防ぎます。委譲の失敗の大半は、指示を書く5分をケチったところで発生しています。

並列で渡すときの境界

複数タスクを同時に走らせる場合、分け方の基準は「同じものに触るか」です。

• 並列にしてよい: 調査・読み取り・独立したファイルの生成
• 直列にすべき: 同一ファイルの編集、同じ外部サービスへの書き込み、ビルド成果物を共有する工程

読み取りは広く並列に、変更は狭く直列に。これだけで、原因の切り分けができない事故はほぼ無くなります。なお恒久的な前提（構成・禁止事項・品質ゲート）は毎回書かず、CLAUDE.md の書き方の通り設定ファイル側に置き、指示文にはタスク固有の情報だけを残します。

チェックリスト（委譲前に30秒）

• [ ] このタスクの「終わった」は何で判定するか、1行で書けるか
• [ ] 期待される件数・範囲・形式を書いたか
• [ ] 受け手のコマンド／APIの前提（入力の形・冪等性）を確認したか
• [ ] 判定に使う観測値は、実測で信頼性を確かめたものか
• [ ] 破壊的操作は別タスクに切り出したか
• [ ] 同時に走る他タスクと同じファイル・同じ外部サービスに触らないか

よくある質問

Q. 指示を細かく書くほど良いのですか? A. 長さではなく、判定可能性です。手順を細かく書いても完了条件が無ければ壊れます。逆に完了条件が数値で書けていれば、手順はエージェントに任せて構いません。全体構成はClaude Codeで個人開発を自動化する構成にまとめています。

Q. 完了条件を書きにくいタスク（文章生成など）はどうしますか? A. 成果物の性質を条件にします。記事なら「frontmatterの必須項目が揃う」「文字数が範囲内」「内部リンクが実在する」。品質そのものは判定できなくても、形式の破綻は機械で弾けます。

Q. 失敗した委譲はどう再発防止しますか? A. 指示文を直すのではなく、受け手の側に検査を足す方が長持ちします。件数不一致でエラー終了する、前提と違う入力を弾く。指示は忘れられますが、スクリプトの検査は残ります。