指揮者（conductor）とオーケストレーター（orchestrator）は、AI コーディングエージェントを指揮する二つの対照的なやり方を表す Addy Osmani の用語であり、両者の区別を探り二つの役割を定義することを目的とした彼の投稿 エージェント型コーディングの未来：指揮者からオーケストレーターへ（2026 年 1 月）で定義されている。指揮者モデルでは、開発者は一つのエージェントをリアルタイムに、同期的かつ逐次的に導き、そのエージェントのコンテキストウィンドウが越えられない上限となる——Claude Code の CLI やエディタ内のエージェントモードのようなツールの姿勢である。オーケストレーターモデルでは、開発者はそれぞれ独自のコンテキストウィンドウを持つエージェントの一団全体を調整する。エージェントは非同期に作業し、その間、開発者はすべてのステップを操縦するのではなく、作業を計画して割り当て、定期的に進捗を確認する。
用法
この投稿は、二つのモードを五つの軸で対比している。制御の範囲（一つのタスクから、一度に委任できる一連のタスクまで）、自律性の度合い（各ステップでプロンプトを待つエージェントから、フィードバックを求める前に内部で多くのステップを計画・実行するエージェントまで）、同期的なやり取りか非同期的なやり取りか、それぞれが後に残す成果物、そして開発者の労力の配分である。最後の軸について、Osmani の説明では、指揮者はエージェントが作業している時間のほぼすべてにわたって能動的に関与するのに対し、オーケストレーターの労力は、良いタスク記述を書くことに前倒しで、また結果のレビューとテストに後倒しで集中し、その間に必要な労力はわずかである——彼はこれを、単一エージェントでの作業よりも多くの作業を一人が同時に抱えられる理由として提示している。
同じ説明は、それぞれのモードをツールが提供するものと結びつけている。指揮者型の作業は IDE 内のアシスタントや CLI セッションの姿勢である。開発者が各アクションを起動し、その出力をすぐにレビューする。やり取りの大部分は一時的なものなので、コードに残されなかったコンテキストや決定はセッションの終了とともに失われる可能性がある。一方、オーケストレーター型のツールは、何かを提示する前にリポジトリをクローンし、ブランチを作成し、複数のファイルにまたがって編集し、テストを実行して解決策を磨き上げるのに十分な主体性をエージェントに与え、作業をプルリクエストとして返す——そのため、やり取りはチャットウィンドウの中にとどまるのではなく、バージョン管理に記録され、チームの他のメンバーもレビューできる。
この投稿はさらに、オーケストレーターの役割を実装の先へと広げ、専門化されたエージェント——計画、コーディング、テスト、コードレビュー、ドキュメント作成、デプロイまたは監視——のパイプラインを、一人の人間が調整する姿を描いている。その人間は計画を承認し、エージェントが提起した疑問を解決し、デプロイに最終承認を与える。投稿はこれを現在の実践ではなく方向性として提示しており、その初期の兆候として、エンタープライズ向けプラットフォームがマルチエージェントワークフローの構成要素を提供していることや、エージェント同士が互いのプルリクエストを批評し、最後にヒューマン・イン・ザ・ループで人間が関与していることを挙げている。
この区別は、ツールの変化であると同時に、求められるスキルの変化としても提示されている。Osmani は、指揮者からオーケストレーターへの移行を、ツールの変化である前にスキルの変化であると述べ、この性格づけを二つの役割を示した投稿へと結びつけている。同じ二つのラベルは、AI がソフトウェアのライフサイクルをどう変えつつあるかについての Google のホワイトペーパーでも使われており、彼はそれを共同執筆したと述べている——したがって、その記述はこの記述と独立に裏づけるものではなく、著者を共有している。彼が伝えるところでは、その実践的な指針も同じである。開発者がまだよく知らないコードをリアルタイムに扱う作業には指揮者、移行やテスト生成のような十分に仕様化された作業を非同期に委任するにはオーケストレーターである。
同じ著者による別の投稿は、指揮者やオーケストレーターという名前は使わずに、同じ二つのモードを描いている。アーキテクチャ上の決定、厄介なリファクタリング、プロダクトの微妙なニュアンス、曖昧な要件には「人間がループの中にとどまる、ローカルで手厚く関与するセッション」を、素直な機能追加、明確なパターンを持つ移行、テスト生成、ドキュメント更新といった範囲が限定され十分に仕様化されたタスクには「非同期に実行されるクラウドまたはバックグラウンドのセッション」を使う、というものである（AI コーディングエージェントにはマネージャーが必要だ）。
また別の投稿は、指揮者がすべての楽器を演奏するわけではないのに、なぜその役割が疲れるものなのかを説明するために、指揮者のイメージに直接立ち返っている。曲全体を把握し続けるにはシステム全体への意識が必要であり、その意識こそが、努力を重ねても拡張できないものなのだという（あなたの並列エージェントの上限）。
適用される場面
二つのモードは、一方が他方に取って代わるものではなく、共存するものとして提示されている。同じ開発者が、あるタスクには非同期のエージェントを送り出しつつ、別のエージェントとは指揮者型で厄介なアルゴリズムに取り組むこともある。この二つは硬直したカテゴリではなく、間にハイブリッドなワークフローを挟むスペクトルの両端として説明されている。どこから始めるかの大まかな目安として経験が挙げられている。ジュニア開発者は複数のエージェントを扱う前に単一のエージェントを指揮することに慣れ、より経験のあるエンジニアは、すでにタスクを分解し結果を評価しているため、早い段階でオーケストレーションを採用する。
困難が集中するのはオーケストレーションの側である。エージェント型コーディングの未来：指揮者からオーケストレーターへ は次の点を挙げている。品質管理と信頼（変更が行われるたびにそれを目で確認する人がいないため）、複数のエージェントが一つのコードベースに手を入れるときの調整と競合（現状では、エージェント同士が交渉するのではなく、ワークスペースの隔離と「1 タスクに 1 エージェント」によって対処されている）、エージェント間で受け渡されないコンテキストと状態（それぞれがサイロ化する）、仕様の質に左右される出力の質（これにより、人間自身の「コーディング」は一段上の、仕様と受け入れ基準を書くことへと移る）、そして道を誤ったエージェントのデバッグ（それを直すには指揮者モードに戻る必要があるかもしれない）である。結果として得られるコードにおけるライセンス遵守、セキュリティ脆弱性、バイアスに対する責任は、終始、人間のオーケストレーターまたはその組織にとどまると説明されている。