サブエージェントに作業を渡す親のエージェントには、コマンドを叩かせない
サブエージェントに作業を渡す親のエージェントのミスがどこで起きていて、どう分担を変えれば減るのかを、私の 2日分の作業記録から書きます。私は個人で複数のサイトとボットを運用し、開発作業を AI エージェントに任せています。1つの親のエージェントが作業を GitHub の Issue に書いてサブエージェント（親から作業を受け取り、実際にコマンドを叩く AI エージェント。Claude Code の機能）に渡し、返ってきた結果を確かめて記録します。変える前の既定では、親は判断と確認に加えて自分でシェルのコマンドも叩いていました。
親の失敗の一例を挙げます。依存の更新の PR を 5本続けて merge した直後にデプロイが失敗し、親はログを読む前に「続けて merge したせいで lockfile（依存パッケージの版を固定するファイル）が上書きされた」と診断しましたが、これは誤診でした。ログの 1行を見ると、失敗した npm ci はビルドの途中で別のディレクトリに依存を入れる段で走っていました。原因はその段で使う別管理の lockfile が更新から取り残されていたことで、root の lockfile は正しかったのです。
私の記録では、こうした失敗は親が自分でコマンドを叩いた場面に集まっていました。そこでエージェントの階層は足さずに、親には判断と確認だけをさせ、手を動かす作業は最初からサブエージェントに渡す分担に変えました。
失敗 11件のうち 9件は親のエージェントだった
2日間の作業記録に、失敗として書き残した物は 11件ありました。9件が親のエージェント、2件がサブエージェントです。1人の運用の 2日分なので、数としては小さいものです。
親の失敗は、セッションの後半に親が自分でシェルのコマンドを叩いていた場面に集中していました。
親の失敗は 3つの型に揃っていた
型は次の 3つです。
- 確かめる前に決める。 冒頭のデプロイの誤診がこの型です。ほかに、1つのサイトの設定だけを見て全サイトに当てはまると説明した例があります。GitHub Actions の更新を、リリースノートの一部（入力名の変更）だけ読んで merge し、リリースの処理を壊した例もあります。そのアクションの新しい版が前提にするツールの版を確かめていませんでした。
- 出力を見ない。 npm の出力を捨てたまま PR を作り、lockfile が更新されていないことに気付きませんでした。作業用のブランチ（git worktree）の作成に失敗したのを見ずに続け、main に直接コミットした例もあり、これは push の前に気付いて戻しました。
- 2つの話を混ぜる。 私への説明で、「CI が要らない検査に時間を使っている（削ってよい無駄）」という話と「依存が変わったときに全サイトのデプロイを省く案は却下した（省いてはいけない仕事）」という話を 1つの話にしました。
どれも事実を作り上げた失敗ではなく、ログや出力という証拠が手元にあるのに見ずに自信を持って結論を出した失敗でした。
Issue で渡して結果だけを確かめた作業は、6件とも通った
同じ 2日間に、親が Issue に書いてサブエージェントに渡した作業が 6件ありました。Issue には何をするかと何で確かめるか（差分と CI の結果）を書きます。結果は差分と CI の run だけで確かめ、6件とも成功しました。このやり方では、親のセッションの会話にコマンドの出力が入りません。
サブエージェントの失敗 2件は、どちらも親のレビューで捕まえました。1件は、親がリリースの処理を壊したのと同じ GitHub Actions の更新を「このリポジトリには関係ない」と判定したものです。もう 1件は、PR の本文で CI の実行時間（開始から終了まで）とジョブの合計時間を取り違えたものです。
親の失敗の原因は、親の注意力ではなく既定の分担にあると判断しました。変える前の既定は「親のエージェントが実際の作業まで自分で手を動かす」で、親が判断に使う 1つのセッションの会話にコマンドの出力が積もっていました。
親は判断と確認だけをする
既定を逆にしました。親のエージェントは判断・委譲・検証・記録だけをし、作業はサブエージェントにさせます。
- 親が叩いてよいコマンド: 取り消せる読み取りと成果の確認だけ
- 最初から渡す作業: 数回で終わらない操作。lockfile の作り直し、設定ファイルの手書きの修正、作業用ブランチ（worktree）の操作、依存の更新
- 止める条件: 同じ作業で 2回失敗したら止めて、Issue に書く
エージェントの階層は足さない
親のミスを減らす別の案は 2つ検討し、どちらも入れませんでした。1つは、エージェントを会社の組織のように、社長役、PM 役、テックリード役、作業者と上下に重ねる構成です。もう 1つは、エージェントをチームにして互いに会話させる構成です。
入れなかったのは、層を 1つ足すたびに上の指示を下の層が言い換える回数が 1回増え、指示が食い違う箇所とそれを確かめる箇所も増えるからです。親のミスを減らすのに要ったのは、作業の取り決めを書いた Issue と、CI・差分・実行結果のように機械的に判定できる確認でした。
役は上下ではなく仕事の種類で分け、判断・作成・検証の 3つで足ります。今は作成をサブエージェントに、判断と検証を親に任せています。