Orkestra:AIエージェントを大規模にオーケストレーションする

この記事の数値は公開時点(2026年1月)のシステムを反映しています。最新の数値はチームページをご覧ください。

Claude Codeでの構築を始めたとき、AIコーディングアシスタントを使うあらゆるチームがいずれ直面する問題にぶつかりました。単一のエージェントでは、すべてをうまくこなすことはできないのです。

エージェントにデータベース専門家であるようプロンプトすることはできます。あるいはセキュリティ監査官として。あるいはフロントエンドエンジニアとして。しかしその3つすべてを同時にこなすよう求めた瞬間、品質は損なわれます。コンテキストは薄まります。指示は衝突します。エージェントは、何をやらせても平凡なジェネラリストになってしまいます。

そこで私たちはOrkestraを構築しました。

Orkestraとは何か

OrkestraはClaude Codeや類似のAIコーディングツール向けのエージェントオーケストレーションシステムです。それぞれ異なる専門知識を持つ複数の専門エージェントを、適切な専門家へ作業を振り分ける単一のオーケストレーターのもとで調整します。

AIエージェント向けの人材派遣会社だと思ってください。オーケストレーターがタスクを受け取り、どの専門家が担当すべきかを見極め、適切なコンテキストとともに委任します。作業が終わると、結果はオーケストレーターへ戻り、そこで統合されます。

数字がその実態を物語っています:

構成要素	数
専門エージェント	46
再利用可能なスキル	466
アイデンティティのアーキタイプ	27
マインドセット	11
コミュニケーションスタイル	10
知識ドメイン	21

キャラクターシステム:エージェント版のD&D

Orkestraの中核にある洞察は、エージェントの振る舞いが3つの組み合わせ可能なプリミティブから生まれるということです。

アイデンティティは、そのエージェントが何であるかを定義します。アーキテクトはシステム構造を設計します。デバッガーは障害を根本原因までたどります。ガーディアンはコンプライアンスとセキュリティ境界を守ります。私たちには、組み合わせ可能な27のアイデンティティのアーキタイプがあります。

マインドセットは、そのエージェントがどう考えるかを定義します。分析的なマインドセットは、主張をエビデンスに根ざし、不確実性を定量化します。懐疑的なマインドセットは前提を疑い、反証となる証拠を積極的に探します。探索的なマインドセットはあいまいさを受け入れ、複数のアプローチを試みます。

スタイルは、そのエージェントがどうコミュニケートするかを定義します。技術的なスタイルは、正確な値と具体的なファイルへの参照を含みます。簡潔なスタイルは無駄をそぎ落とし、結論から述べます。外交的なスタイルは正直さと配慮のバランスを取ります。

エージェントは、これらのプリミティブを組み合わせます:

# architecture-advisor.yaml
identity:
  - knowledge-architect
  - architect
  - strategist
mindset: analytical
style: concise

この組み合わせは、システムを設計し(アーキテクト)、ドメインをまたいで知識をつなぎ(ナレッジアーキテクト)、戦略的な方向性を定め(ストラテジスト)、エビデンスとデータで考え(分析的)、無駄なく伝える(簡潔)、そんなエージェントを生み出します。

その力は、組み合わせ爆発にあります。27のアイデンティティ×11のマインドセット×10のスタイルで、およそ3,000通りのエージェント人格が生まれます。しかし、実際に定義するのは自分たちの作業にとって意味のある組み合わせだけです。

スキル:再利用可能な能力モジュール

スキルは、エージェントが呼び出せる知識とワークフローです。スコープに基づく階層システムに従います:

ティア	名称	スコープ	例
K0	基盤	普遍的な方法論	テストファースト規律、エビデンスに基づく完了判断
K1	アイデンティティ	役割ベースのワークフロー	CLIインターフェース標準、パフォーマンスプレイブック
K2	ドメイン	ドメイン固有の知識	データベースマイグレーションパターン、認証の検証
K3	スタック	技術固有	Cloudflareデプロイ、Supabase運用
K4	プロジェクト	このコードベース限定	プロジェクト固有のワークフローと規約

スキルは遅延ロードされます。エージェントは起動時にスキルの名前と説明を目にしますが、実際に発動したときにのみ完全な内容が読み込まれます。これにより、何百ものスキルを発見可能にしながら、コンテキストを軽量に保てます。

各スキルには次が含まれます:

• 明確な発動条件(「データベーススキーマを移行するときに使う」)
• ステップバイステップのガイダンス
• そのワークフローで許可されるツール
• 成功基準と失敗時のリカバリー経路

私たちのレジストリにある466のスキルは、gitのworktree分離からWebリサーチのワークフロー、デプロイの健全性検証まで、あらゆるものをカバーしています。

なぜオーケストレーションが重要なのか

単一エージェントのアーキテクチャは、すぐに壁にぶつかります:

コンテキストの希釈。 20万トークンのコンテキストウィンドウは、データベーススキーマ、APIドキュメント、テストフィクスチャ、ドメイン知識を読み込むまでは大きく感じられます。専門エージェントであれば、絞り込んだコンテキストで作業できます。

指示の衝突。 エージェントに「徹底的に、しかし速く」「すべて検証せよ、しかし過剰設計はするな」と伝えると、緊張が生まれます。専門エージェントは明確なスコープを持つことでこれを解決します。

専門性の深さ。 ジェネラリストのエージェントは、何についても少しずつ知っています。適切なアイデンティティとスキルで構成された専門エージェントは、自分のドメインを深く知っています。

Orkestraはフラットなオーケストレーションを実装しています。1つのオーケストレーターが複数の専門エージェントを調整します。専門エージェントはサブ専門エージェントを生成できません。これにより、複雑性の爆発を防ぎながら並行作業を可能にしています。

オーケストレーターは、実質220万トークンの容量にアクセスできます。自身の20万トークンのウィンドウに加え、それぞれ20万トークンを持つ10体の同時実行サブエージェントです。単一のエージェントなら使い果たしてしまうような作業も、この編隊なら余裕をもってこなせます。

レンダリングパイプライン

エージェント定義はYAMLで存在します。Claude CodeはMarkdownを読みます。Orkestraは、決定論的なレンダリングパイプラインでこのギャップを橋渡しします:

YAML Registries → Jinja Templates → .claude/agents/*.md

オペレーターはYAMLソースを編集します。orkestra syncを実行します。レンダリングされたMarkdownは.claude/agents/に現れます。Claude Codeがその変更を取り込みます。

この分離は、異なる読み手に対応しています:

• YAMLソースには、ツール連携のためのライフサイクルメタデータ、タグ、検証ルール、非推奨の注記が含まれます
• レンダリングされたMarkdownには、モデルが必要とするものだけが含まれます。説明、ツール、スキル、振る舞いに関するガイダンスです

このパイプラインは、アイデンティティ、マインドセット、スタイル、スキルを1つの一貫したプロンプトへと合成します。アーキテクト×分析的×簡潔なエージェントは、いくつかの基盤スキルを共有していたとしても、デバッガー×懐疑的×技術的なエージェントとはまったく異なるシステムプロンプトを持つことになります。

ドメイン知識:4ファイルパターン

すべての知識ドメインは、一貫した構造に従います:

domain-name/
  decisions.md      # Key choices, rationale, consequences
  patterns.md       # Step-by-step guidance and examples
  anti-patterns.md  # Failure modes and remediation
  evolution.md      # Dated log of changes

この構造は、エージェントのコンテキスト読み込みに役立ちます。認証まわりの作業をしているエージェントは、ガイダンスのためにauthentication/patterns.mdを、既知の落とし穴を避けるためにauthentication/anti-patterns.mdを読み込みます。ファイルは効率的なコンテキスト読み込みのためにサイズ調整されています。有用であるために十分に絞り込まれており、権威あるものであるために十分に包括的です。

私たちは、分析、認証、データサイエンス、インフラ、機械学習、パフォーマンス、セキュリティなどを含む21のトップレベルドメインを維持しています。各ドメインは、より細かい粒度のためのサブドメインを持つことができます。

価値観:オペレーティングシステム

すべてのエージェントは、その動作を定義する共通の価値観のベースレイヤーを共有しています:

シンプルさを最優先。 機能する最もシンプルな解決策を使う。複雑さは正当化される場合にのみ加える。

根本原因を直す。 失敗を回避するパッチを当てない。パイプラインが失敗したらパイプラインをデバッグする。テストが失敗したらコードかテストを直す。

エビデンスに基づく。 主張には「検証済み」(ベンチマーク付き)か「推定」(前提条件付き)のラベルを付ける。パターンの検出は、問題の確定を意味しない。

コンテキストの経済学。 MCPツールのコストはコンテキストの0.1%。ファイル読み込みは1回あたり2%。コードを探索する前にドメインの専門知識を適用する。

これらの価値観は、レンダリングパイプラインを通じてすべての専門エージェントへ伝播します。エージェントは組み合わせによってこれを迂回することはできません。

CLI:コントロールプレーン

Orkestraには、エージェントエコシステムを管理するためのCLIが付属しています:

# Discovery
orkestra agents search "database"
orkestra agents info database-architect

# Validation
orkestra validate --show-warnings

# Rendering
orkestra sync --dry-run
orkestra sync

# Skills
orkestra skills list
orkestra skills info schema-migration-workflow

# Decisions
orkestra decisions search "authentication"

このCLIは、どんなエージェントが存在し、どんなスキルを持ち、システムが健全かどうかを知るための信頼できる情報源です。問題を早期に発見するため、同期前にバリデーションを実行します。

オープンソースについての検討

私たちがOrkestraを構築したのは、自分たち自身の問題 ―― 複雑なコードベースに対して、大規模にAIエージェントを調整すること ―― を解決するためでした。そこで発見したパターンは、私たちのドメインに特有のものではありません。

キャラクター合成システム(アイデンティティ+マインドセット+スタイル)は、エージェントの人格を定義するどんなチームにも当てはまります。

スキルティアシステム(K0〜K4)は、再利用可能な能力をスコープ別に整理するためのメンタルモデルを提供します。

レンダリングパイプラインのパターン(YAMLソース+テンプレート+生成された成果物)は、ツール連携とモデルの消費とを関心事として分離します。

フラットなオーケストレーションモデル(1つのコーディネーター、多数の専門エージェント)は、並行性を可能にしながら複雑さを回避します。

Orkestraがオープンソースになるかどうかは、これらのパターンが、Claude Codeで構築している他の人々にとっても価値があるかどうかにかかっています。もしあなたが私たちの説明したのと同じ壁にぶつかっているなら、このアーキテクチャは助けになるかもしれません。

私たちが学んだこと

Orkestraを構築して学んだのは、オーケストレーションはエージェントを賢くすることではない、ということです。エージェントをより集中させることなのです。

完璧な指示を持つ単一のエージェントでも、いずれコンテキストは尽きます。すべてのスキルを持つ単一のエージェントでも、どれを適用すべきか混乱します。すべてになろうとする単一のエージェントは、あらゆる場面で平凡な結果しか出せません。

それぞれの領域で卓越した40体の専門エージェントを、いつ委任すべきかを知るオーケストレーターが調整する ―― それが私たちの出荷の仕方です。

数字よりも重要なのはアーキテクチャです。必要なのは5体のエージェントかもしれませんし、50体かもしれません。原則は変わりません。能力より合成を、汎用化より専門化を、個人技より協調を。

---

Orkestraは、私たちのコードインテリジェンスプラットフォームMaguyvaを支えるエージェントエコシステムの原動力です。もっと知りたいですか? チームまでお問い合わせください。