複数のAIコーディングエージェントを併用しているチームに向けた話です。Claude Code（Anthropicが提供するCLI型のAIコーディングツール）に、軽い作業はCodex（OpenAIのコーディング支援CLI）へ回すよう指示だけ出して、実際には何も委譲されていない、という状態に心当たりはないでしょうか。
ある開発環境では、CLAUDE.md（Claude Codeが起動時に読み込むプロジェクトルール用ファイル）に委譲ルールを書いた翌日、実務で起動したサブエージェント（親のAIが呼び出す子タスク実行単位）46件のうち、Codexへの委譲は0件でした。ルールの文言を書くだけでは、エージェントの行動は変わらなかったということです。この記事では、委譲が実際に動き出すまでに必要だった仕組みと、そこから見えるチーム運用上の教訓を整理します。
何が起きていたのか
最初に試したのは、もっともシンプルな方法でした。CLAUDE.mdに「軽い作業はCodexに委譲します」という一文を足しただけです。
ところが規則が読み込まれたあとに起動したサブエージェント26件で委譲は0件、条件を見直して書き直し46件で数え直しても0件でした。興味深いのは、46件の大半（文面の監査や独立レビュー）はそもそも委譲対象ではなく、Codexに回さないのが正しい判断だった点です。
一方で突き合わせや一覧作り、コードの調査など、委譲の条件に当てはまる作業が10件ほど含まれていました。そのうち4件は、依頼文に「codex-solへ委譲してよい」と明記されていたにもかかわらず、サブエージェントは自分でGrepやReadを重ねて作業を終えていました。ルールを読んだうえで、使っていなかったということです。
「してよい」から「回してください」への書き換え
ここで見つかった問題は、技術的な設定ミスというより、指示文の言い回しの問題でした。「委譲してよい」という許可形の文は、「しなくてもよい」とも解釈できます。
手元のツールで片づくタスクなら、エージェントはわざわざ外部呼び出しをせず自己完結を選ぶ、という挙動が見られました。これは人間のチームマネジメントでもよくある話です。「レビューは依頼してもいいですよ」という曖昧な依頼より、「このレビューはAさんに回してください」という明確な指示のほうが実行されやすい、という経験則に近いものがあります。
対策として、依頼文とサブエージェントの定義を、許可形から指示形に書き換えています。たとえば「軽い作業はcodex-solへ委譲してよいです」という文を、「対象ファイル・完了条件・検証方法が明確な検索、既知のテスト実行、局所的な修正、機械的な置換は~/.local/bin/codex-solに回し、結果を確かめてから使ってください」という形に変えました。対象範囲と手順、検証義務までを一文に含めることで、解釈の余地を減らしています。
仕組み面で加えた3つの手当て
文言の修正だけでは足りず、実行環境側にも手当てを加えています。
1つ目は呼び出しを1本のラッパースクリプト（~/.local/bin/codex-sol）に固定したことです。モードをread（読み取り専用）とwrite（作業ディレクトリへの書き込み）の2種類だけに絞り、モデルや推論量、禁止事項（commit・push・外部送信・環境変数ファイルの読み書き禁止）を毎回同じ内容で冒頭に付ける形にしています。呼び方が1本化されることで、委譲の都度エージェントが引数を組み立てる揺れがなくなります。
2つ目はサブエージェントの定義ファイル自体の書き換えです。CLAUDE.mdだけでなく、リポジトリ内の個別のサブエージェント定義にも同じ指示形の文言を反映させ、どの階層のルールを読んでも同じ行動指針になるようにしています。
3つ目はPreToolUseフック（ツール呼び出し前に発火する仕組み）を使って、調査や一覧作りに見えるサブエージェントの起動を親のClaudeに知らせる処理を入れたことです。重要なのは、このフックが処理を止めない点です。あくまで通知だけを行い、実行をブロックしません。委譲するかどうかの判断自体は、エージェント側に委ねたままにしています。
チーム運用として見るべきポイント
この事例は単体エージェントの設定問題に見えますが、開発プロセスの観点で読むと、見積もりとタスク配分の課題に近い構造を持っています。
チームでタスクを振り分けるとき、「暇な人がいたら手伝って」という曖昧な依頼では実際には誰も動かない、という状況と同じです。委譲が機能するには、対象範囲の明確化、完了条件の明示、検証責任の所在、という3点がそろっている必要があります。これはスクラムのタスク分解でバックログアイテムに受け入れ条件（Acceptance Criteria）を書く作業とも重なります。
委譲ルールを「ドキュメントに書いた」という事実と、「実際に運用で機能している」という事実は、まったく別のものだという点が、この事例のいちばんの教訓です。
また、終了コードが0であることと、依頼した作業を最後までやり切ったことは別物、という指摘も見逃せません。ラッパーのログに「未完了事項の有無」という列を後から追加した経緯が示す通り、プロセス終了の成否と、タスク完了の成否は別の軸で監査する必要があります。これはCI/CDパイプラインで「ジョブは成功したがテストは実質的に何も実行していなかった」という事故パターンとも共通する注意点です。
今日から確認できること
自分のチームでAIエージェントへのタスク委譲ルールを運用している、あるいはこれから導入を検討しているなら、次の点を確認してみる価値があります。
- 委譲ルールを「許可形」(〜してもよい)で書いていないか、「指示形」(〜に回してください)に書き換えられないか確認する
- ルールを書いた日から一定期間、実際の委譲件数をログやセッション記録から数えてみる
- 委譲対象の条件(対象範囲・完了条件・検証方法)が、依頼文の中で具体的に書けているか見直す
- プロセスの終了コードとタスクの完了状態を、別の指標として記録しているか確認する
AIエージェントの行動を変えるには、ルールを書くことよりも、実測して検証するサイクルのほうが効いてきます。これは人間のチーム運用で「決めたルールが形骸化していないか定期的に棚卸しする」という営みと、本質的には同じ作業です。まずは自分の環境で、委譲ルールを書いた日から1週間分のログを数えてみるところから始めてみてはいかがでしょうか。