オーケストレーター・ワーカー・MCP：複数のエージェントとツールを連携させる構造
約12分developer-tools
#オーケストレーター vs ワーカー#デリゲート#MCP#フォーク#リリースタグ#サブモジュール#AIコーディングツール#用語集
※ 編集方針：以下の業務状況および人物は、用語の理解を助けるための架空のシナリオです。実際の著者の経験や特定企業の出来事を再現したものではありません。
モバイルアプリ、バックエンド、管理者ツールの3つのリポジトリを一度にまとめてリリースする架空のプロジェクトを考えてみましょう。
1つのエージェントがすべてを行うのではなく役割を分担するときの、「オーケストレーターとワーカー」
text
1orchestrator: 릴리스 순서·의존성 관리2 ├─ worker: mobile-app 빌드3 ├─ worker: backend 빌드4 └─ worker: admin-tool 빌드
数ヶ月前に残したメモに、すでにこの構造が整理されていました。全体の順序と依存関係を管理する役割と、実際の担当者の作業を一つひとつ処理する役割を分け、一方が指示すると他方がそれぞれの役割を処理する構造でした。全体のスケジュールを管理する工事現場の監督と、担当エリアを実際に施工する各チームに分かれているようなものです。
実際にリリースを開始すると、エージェントが3つのリポジトリの作業を一つずつ別のセッションに引き渡すのを何度も繰り返し目にすることになりました。
同じパターンが繰り返されるとき、これが「デリゲート」だと気づいた瞬間
text
1Delegating mobile-app build to worker session...2Delegating backend build to worker session...
3回とも同じ文言が表示されるのを見て初めて、これがその場しのぎの臨機応変な対応ではなく、決められた方式であることに気づきました。直接処理する代わりに、その仕事をうまく処理できる別の主体に委ねて結果だけを受け取る動作がデリゲート（委譲）でした。チームリーダーが実務をすべて自分で行わずに各担当者に任せるのと同様の名前が、ここでもそのまま使われていました。
バックエンドリポジトリのリリースノートを準備しているとき、最近新しく連携したツールがどのように私たちのシステムに接続されているのか気になり、調べてみました。
異なるツールを標準化された方法で接続するときの「MCP」
json
1{ "mcpServers": { "figma": {...}, "notion": {...} } }
検索してみると、この略称はモデルと外部ツールを接続する共通規格を意味していました。各ツールごとに毎回異なる接続方法を新しく覚える必要はなく、定められた一つの規格に従うだけでどんなツールでも接続できるようにする標準でした。世界中の電化製品が異なるプラグ形状の代わりに標準規格のコンセントを使うのと似たアイデアなので、名前自体は馴染みがなくても、コンセプトはすぐに理解できました。
管理者ツールのリポジトリを整理していると、ログに残されたライブラリの参照元が、元々知っていたプロジェクトとリンク先が異なることに気づきました。
同じ名前なのにオリジナルではないときの「フォーク」
text
1origin: github.com/our-team/chart-lib-fork2(원본: github.com/original-author/chart-lib)
ログを再確認したところ、数ヶ月前にチームでオリジナルのライブラリに必要な機能を追加するために丸ごと複製し、独自のバージョンとして分岐させた形跡でした。
オリジナルのリポジトリをそのまま複製し、その後は独立して開発を進めていく自分専用のコピーがフォークでした。オリジナルにない機能をこちら側だけに個別に追加していたのですが、今回のリリースにもその機能が必要でした。
3つのリポジトリのビルドがすべて終わり、いよいよ正式にバージョンを表記する番になりました。リリースを担当する同僚が手順を教えてくれました。
今回のバージョンを後からでも正確に見つけられるようにする「リリースタグ」
bash
1$ git tag v3.4.02$ git push origin v3.4.0
同僚が「コミット番号は覚えにくいから、タグでラベルを貼っておくんだよ」と教えてくれました。
数多くのコミットの中から『これが正式にデプロイされた3.4.0バージョンだ』とピンポイントで示すラベルでした。後からトラブルなどの事例に対応することになっても、その時点のコードを正確に再び取り出すことができました。
最後に、管理者ツールのリポジトリの中に、別のチームが管理するデザインコンポーネントのリポジトリが丸ごと入っているのを発見しました。
リポジトリの中に別のリポジトリが丸ごと入っているときの「サブモジュール」
text
1.gitmodules2[submodule "design-kit"]3 path = libs/design-kit4 url = github.com/design-team/design-kit
公式ドキュメントを調べてみると、このフォルダは私たちのリポジトリに属しているのではなく、別のリポジトリの特定のバージョンをそのまま参照しているだけでした。
独立して管理されている別のリポジトリを、自分のリポジトリ内の特定のフォルダ位置に、特定のバージョンで丸ごと組み込む方法でした。額縁の中に他人が描いた絵をそのまま入れて展示するようなものです。これで、3つのリポジトリの統合リリースがすべて完了しました。
3つのリポジトリのリリースは、同日の午後に一斉に行われました。リポジトリが複数ある場合に難しいのは、それぞれをデプロイすることではなく、どのバージョンとどのバージョンがペアだったのかを後からでも確認できるように残しておくことでした。
よくある質問
オーケストレーターが停止すると、ワーカーはどうなりますか？
進行中だった作業は通常そのまま処理されますが、全体の順序を管理する主体が失われるため、次の段階に進めず停止します。オーケストレーター自体の復旧や再起動の方法を別途用意しておくのが安全です。
フォークしたライブラリは、オリジナルのアップデートを継続して受け取ることができますか？
アップストリームのリポジトリをリモートとして登録しておけば、新しいバージョンを取得できます。ただし、自分たちで独自に修正した部分と競合が発生した場合は、その都度手動でマージ（解消）する必要があります。
サブモジュールは常に自動的に最新バージョンに追従しますか？
いいえ。サブモジュールは特定のコミット時点に固定されているため、オリジナルがアップデートされても、手動で更新コマンドを実行するまではそのまま維持されます。
AIコーディングツール用語集シリーズの第12話です。次回予告 · 第13話：並行処理のバグを特定するために一晩中ログを解析した日（プラグイン · スキルファイル · 自動承認モード · デッドロック · レースコンディション）
参考・根拠
関連記事
サブエージェント・フック・スラッシュコマンド：AIコーディングツールでよく使われる拡張概念
AIコーディングツールの使用中に出会う「サブエージェント」「フック」「スラッシュコマンド」を、架空の業務シナリオを交えて分かりやすく解説します。
パーミッションプロンプト・Sandbox・Checkpoint：AIエージェントの実行境界を理解する
AIコーディングツールを使う中で直面するパーミッションプロンプト、サンドボックス、チェックポイントなど5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。
Kill Switch・Backoff・Runtime：実行を停止し復旧するための基本機能
AIコーディングツールを使っていると遭遇する、キルスイッチ、バックオフ、リポジトリなどの5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。