委譲するのは調査と実装だけ。3エージェントに役割を固定するスキルを作った

マルチエージェント開発で最初に迷うのは、何をどのエージェントに委ねるかだ。

自分はこれをスキル1本に固定した。agent-orchestration という agent skill で、Claude Code が判断とレビューを、OMP(oh-my-pi)が調査を、Codex が実装を担う。スキルは「オーケストレーション、レビュー、完了の判断は決して委譲しない」と明記している。委譲するのは調査と実装だけだ。

スキルは ChatGPT との対話で設計し、レビュー指摘を反映して磨いた。Laravel の S3 クライアント側暗号化パッケージ laravel-encrypted-s3 の開発で実際に使い、使う過程で書き直しを重ねて、agent skills リポジトリに公開した。

3つの役割とモデル割当

モデル割当は、作業の性質に合わせて決めた。

調査は探索的な試行を何度も繰り返す。deepseek-v4-flash はコストが低い割に性能が高く、試行の多い調査に向く。実装は gpt-5.6-luna(max)を当てる。こちらも高コスパで、価格の割に実装の品質が高い。この割り当ては、設計レビューでも妥当と評価された。

この3モデルへの固定は、以前のオーケストレーションからの移行でもある。それまでは OpenCode で oh-my-opencode-slim を使い、Orchestrator や Explorer といったロールにモデルを割り当てていた(以前の記事 )。

Claude Code で Opus 5 を使う機会が増えた。Codex の gpt-5.6-luna(max)と deepseek-v4-flash はどちらも高コスパで使い勝手が良く、ほかのオープン系モデルを使わなくなった。今は OpenCode 自体は使っていない。OpenCode Go のモデルが必要なときだけ OMP を経由する。

委譲しない3つが設計の中心

設計の中心は、何を委譲しないかを決めたことだ。

オーケストレーション、レビュー、完了の判断。この3つは Claude Code が手放さない。計画とスコープの定義、調査結果の評価、実装のレビュー、完了の決定は、すべてオーケストレーターの仕事としてスキルに固定されている。

この分離が効くのは、レビューと実装が同じ頭で進まないからだ。実装者が報告する「成功しました」と、作業ツリーが実際に正しいことは別の主張で、レビューが実装者から独立しているからこそ、実装者の思い込みを拾える。スキルは「diff を自分で読み、検証を自分で実行する」と書いている。

OMP は読み取り専用

OMP と Codex は1つの作業ツリーと1つの git index を共有する。2つのエージェントが同時にファイルを書けば、互いの作業を壊す。だからスキルは OMP を読み取り専用と明記し、ファイルの変更は Codex だけにさせる。調査のプロンプトにも「読み取り専用。ファイルは変更しない」と書く。

調査結果は形式を固定して返させる。結論、根拠と出典、該当ファイル、制約と影響、代替案、仮説と確度だ。deepseek-v4-flash の応答は冗長になりがちで、そのまま読み返すとオーケストレーターのコンテキストを消費する。形式を固定して、読み手の負荷を下げる。

仮説は評価してから実装に渡す

OMP の調査結果をそのまま Codex の実装指示にしない。これもスキルの明示的なルールだ。

OMP は仮説を提示する。仮説は、もっともらしく見えて間違っていることがある。評価のステップを飛ばして実装に渡すと、誤った仮説がそのままコードになる。オーケストレーターは調査結果を評価し、確信が足りなければ追加調査を依頼する。実装の前に仮説レビューと方針決定が入るのは、このためだ。

ChatGPT との設計レビューで直った3つ

スキルの設計は ChatGPT との対話で進めた。フローの図を描いてもらい、レビューしてもらい、指摘を反映する往復だ。このレビューで直ったのは大きく3つある。

1つ目はフローの矢印だ。最初の図は、矢印の向きがバラバラだった。調査依頼、調査結果、実装依頼、実装結果、レビュー後の修正依頼。すべて Claude Code を起点に、一方通行に統一した。視点がまず中央の Claude Code に行き、「Claude が DeepSeek と Codex を使っている」ことが一目で分かる形になった。

2つ目はレビュー指摘の反映だ。設計レビューは、良い点としてモデル割当とフィードバックループを挙げ、3つの懸念を出した。

• ハブ&スポーク構成のボトルネック。全通信が Claude Code を経由するので、調査結果の要約でコンテキストを消費する
• 調査の仮説が誤っていた場合の検知。実装まで進んでから気づくと手戻りが大きい
• 完了基準が静的。プロジェクトによって検証コマンドは変わる

それぞれに、スキルへ反映する答えを決めた。引き継ぎフォーマットの規約、実装前の仮説レビュー、完了基準の「プロジェクトが定める検証コマンド」だ。特定のツール名で固定していた記載は消し、Workspace / Worktree 分離の記載も削った。herdr は新しい workspace や worktree を明示要求なしに作らないからだ。

結果的に、フローはこの形に落ち着いた。

3つ目はレイアウトだ。最初は固定レイアウトを描いていたが、herdr の分割ルールは違う。現在のペイン形状を見て right / down を決め、同じ方向の連続分割を避ける。分割対象は呼び出し元ペイン(--current)で、フォーカスは --no-focus で維持する。

このルールを確認したうえで、「Claude Code 50% / OMP 25% / Codex 25%」を目標値としてスキルの推奨レイアウトにした。1エージェントだけ委譲している間は右半分をそのエージェントが使い、2つ目を起動したら右側を上下分割する。50/25/25は目標値で、既存のユーザーペインや可読性を壊してまで強制しない。

実プロジェクトで試した: laravel-encrypted-s3

できあがったスキルで作ったのが laravel-encrypted-s3 だ。AWS S3 のクライアント側暗号化(CSE V3)を Laravel のファイルシステムドライバとして提供する Composer パッケージで、暗号化の実装は AWS SDK に委譲する。パッケージの中身の話は、また別の記事で書く。

セキュリティパッケージは、オーケストレーションの題材として良かった。不変条件が存在理由で、不変条件を静かに弱める変更は diff の上では正しく見える。AGENTS.md にそう書いてある。実装者から独立したレビューが、この「正しく見える変更」を拾う役割を担う。

開発は2日間で42コミット進んだ。うち34コミットに「Co-Authored-By: Claude Opus 5」が付いている。リポジトリには、役割分担の痕跡がそのまま残っている。AGENTS.md の「一度に一人の書き手」という規約と検証ゲートだ。

検証ゲートは、テスト・スタイル・静的解析の3つが通らないと完了と報告しない、という運用だ。失敗した実行は答えであって障害ではない。原因は実装側で直し、検証の設定は変えない。委譲された実装が「ゲートをクリアした」と報告しても、オーケストレーターが自分で検証を実行し直す。スキルの「検証は自分で実行する」というルールが、リポジトリ側の規約としても固定された形だ。

セキュリティに関わる判断の扱いも、スキルとリポジトリが同じ線を引いている。AGENTS.md は、タスクがセキュリティの不変条件を緩める形になったら止めて報告しろと書いている。この判断は人間のものだ。スキルのエスカレーションルールも、セキュリティや重要なデータに関わる決定は推測で進めずユーザーに聞くと書いている。2つの文書が同じ境界を指しているのは、スキルで開発しているからこそだと思う。

スキルは実戦で書き直しを重ねた

スキルは laravel-encrypted-s3 の開発中に、設計の見直しを重ねた。設計時に想定していなかった問題が実戦で見つかった。

モデル指定の扱いは、一周して戻ってきた。最初の版は起動時にモデルを指定するよう書いていたが、途中で「エージェントは kind(omp / codex)だけで起動する」に書き直した。最新版では再びモデルと reasoning レベルを起動時に明示的に指定する。役割に割り当てたモデルが確実に使われるようにするためだ。起動に失敗したら黙ってデフォルトにフォールバックせず報告し、既存エージェントの再利用も、モデルとレベルが役割の設定と一致するときだけに限る。

もう1つの追加は、find-docs の指針だ。公式ドキュメントの調査には find-docs スキルを使うと明記した。Laravel と AWS SDK の組み合わせはバージョン依存の挙動が多く、うろ覚えでは書けない。

レイアウトの推奨も、ChatGPT との議論を経て加わった(前述)。開発初日の23時台に、スキル導入、レイアウト追加、kind-only 書き直しが続いた。

スキルは2026年8月11日に j1nn0/skills へ公開した。

うまくいかなかったことと、残る制約

ハブ&スポークはボトルネックになる

全通信がオーケストレーターを経由する。一貫性は保てるが、Claude Code のコンテキストと作業がボトルネックになる。これは設計レビューでも指摘された点で、引き継ぎフォーマットの規約で応じた。完全には消えていない。判断を1か所に集める代償だ。

実装の待機は想定より長い

調査は1回のタイムアウトで収まるが、実装は長く走る。スキルは「タイムアウトは失敗ではなく、まだ働いていると扱う」と書いている。待機が切れても即再プロンプトせず、herdr agent get で状態を確認してから動く。働いている実装を中断して再依頼するほうが、待つよりコストが高い。

委譲の境界は経験でしか掴めない

スキルには「調査や実装が十分に大きく、委譲の価値があるときだけ使う」と書いた。1分で終わる確認に OMP を呼ぶのは、往復のコストのほうが高い。

公開したスキルと、次の一歩

スキルは j1nn0/skills に公開している。

npx skills@latest add j1nn0/skills -s agent-orchestration

使うには herdr のセッション(HERDR_ENV=1)と、herdr スキルが必要だ。Herdr の外では、このスキルは単一エージェントの作業にフォールバックする。

laravel-encrypted-s3 は Packagist に公開し、v1.0.0-RC1 まで出ている。

3エージェント構成を試すなら、最初に「何を委譲しないか」を決めることから始めるといい。自分は判断とレビューを Claude Code に残した。この線がどこにあるかで、スキルの形は変わる。