この記事は、AIエージェントへの委任設計に関する運用記録の1本である。委任先のエージェントに作業を任せたところ、委任先が自分で書かずさらに子エージェントを起こし、その完了を待たずに終了する事故が同じ形で2回起きた。何が起きたか、なぜ気づけなかったか、どう直したかをまとめる。
この記事で分かること
- 委任先が子エージェントを起こして先に終了すると、成果物がどうなるか
- 完了通知の「completed」を見るだけでは気づけない理由
- 長時間タスクで成果を守るための保存先の設計
この記事で分からないこと(正直に書く)
- 子エージェントを起こすこと自体を機械的に禁止する仕組みを導入したかどうか
- 同種の事故がこの2回以外に起きていないかの継続確認
何が起きたか — 「起動しました」の後、成果物が0件だった
委任先のエージェントに記事の追記作業をまとめて依頼したところ、委任先は自分で作業せず、さらに複数の子エージェントを起こし、その完了を待たずに自分の処理を終えてしまった(出所: 自社の運用記録、確認日2026-09-06)。報告文は「複数のワーカーをバックグラウンドで並列起動しました。完了次第まとめて報告します」という、進行中であるかのような内容だった。ところが親のエージェントが終了した時点で起動していた子エージェントも同時に消え、実際に作られたファイルは1つも無かった。同じ形の事故がこれまでに2回起きている。
別の作業でも、プロセス終了と同時に成果が消えた
長時間かかる検証・構築作業を1つのエージェントにまとめて任せたケースでも、根は同じ問題が形を変えて起きた(出所: 自社の運用記録、確認日2026-09-06)。作業途中でプロセスが終了し、それまで走っていた工程が停止した。ログの一部が途切れて手順書が未作成のまま残った工程もあった。さらに、成果物がそのセッション限りの一時的な作業場所にしか置かれておらず、セッションが終わればゲート条件や候補ごと失われる状態になっていたことも分かった。
なぜ気づけなかったか
タスクの完了通知そのものは「completed」で返ってくる。報告文も、子エージェントを起動したこと自体は事実であるため嘘ではなく、成功したかのように読める。通知の内容だけを読んで次の作業に進むと、成果物が実際に存在するかを確認しないまま先へ進んでしまう。長時間タスクの側では、途中経過が一時的な作業場所にしか無いため、停止が起きるまでその作業場所が「正」であるかのように扱われてしまうことも、気づきを遅らせた一因である。
どう直したか
委任の完了は報告文でなく、成果物の実在をls や git status で数えて確認する運用に切り替えた。プロンプトには、委任先自身がさらに別のエージェントへ仕事を渡さないこと、本人が書くことを明記する。作業を分割したい場合は、依頼者自身の直下で並列に起こし、子エージェントの下に孫を作らせない。長時間かかる作業は、成果を工程ごとに恒久的な保存先へ書かせ、一時的な作業場所を最終的な置き場にしない。停止の通知が来た場合は、出力ファイルの実体を確認してから完了・途中・未着手を判定する。
再発防止の手順
- 委任プロンプトに「自分で作業する。さらに別のエージェントへ委任しない」と明記する
- 分割したい場合は依頼者自身の直下で並列に起こし、孫を作らせない
- 完了判定は報告文でなく、成果物の実在と件数をls・git statusで確認する
- 1時間を超えそうな長時間タスクは、成果を工程ごとに恒久的な保存先へ書かせる
- 停止通知が来たら、出力ファイルの実体を見てから完了・途中・未着手を判定する
以上は、いずれも今回の2件の事故を踏まえて実際に運用へ組み込んだ対策である(出所: 自社の運用記録、確認日2026-09-06)。同じ形の事故を防ぐ入口として、委任前に確認すべき点は「指示直前の3検査と汚れた作業ツリーへの委任」で、批判レビューの前提を扱う手順は「前提シートを先に渡す」で整理している。複数エージェントの判定をどこまで信じるかは「複数エージェントの批判が全滅判定を出すとき」も参照してほしい。
AIエージェントへの委任設計・長時間タスクの成果保全について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. なぜ成果物が0件になったのか
委任先が自分で作業せずさらに子エージェントを起こし、その完了を待たずに親のエージェントが終了したため。親が終了した時点で子エージェントも消え、作られるはずだったファイルが1つも残らなかった。
Q2. 報告文を読めば気づけたのではないか
気づけなかった。報告文は「並列起動しました」という内容で、起動したこと自体は事実であるため嘘ではなく、成功したかのように読める内容だった。
Q3. 長時間タスクではどんな問題が起きたのか
作業途中でプロセスが終了し、それまでの工程が停止した。成果物がセッション限りの一時的な作業場所にしか置かれておらず、セッションが終わると候補やゲート条件ごと失われる状態になっていた。
Q4. 再発防止のために何を変えたか
委任プロンプトに「自分で作業する。さらに委任しない」と明記し、完了判定を成果物の実在確認に切り替えた。長時間タスクは成果を工程ごとに恒久的な保存先へ書かせるようにした。