OpenAI は 2026 年 4 月 27 日、An open-source spec for orchestration: Symphony を公式ブログで発表し、GitHub に仕様リポジトリを公開しました。MCP がツール呼び出しの標準を担うように、Symphony は「マルチエージェント間の協調」を標準化する試みです。
受託開発の視点では、「複数のエージェントを束ねるとき、どの仕様に乗るか」は今後 1〜2 年の重要な技術判断になります。本記事では Symphony の構成要素と、受託案件で採用するかを判断する観点を整理します。
Symphony が解こうとしている問題
これまでマルチエージェントは 「フレームワークごとに独自仕様」 が当たり前で、案件ごとに次のような問題が再発していました。
| 問題 | 具体例 |
|---|---|
| ジョブの受け渡し形式が独自 | LangGraph で書いたエージェントを CrewAI に移行できない |
| 状態共有がフレームワーク依存 | グローバルな会話履歴をどこに置くかが毎回違う |
| エラー伝播が暗黙的 | サブエージェントが落ちたとき、親が気づかないことがある |
| 観測ツールが横断不可 | 各 SDK の独自イベント形式に Langfuse / Datadog が個別対応する必要 |
Symphony は 「ジョブ・状態・イベント」の 3 つを共通フォーマット化 することで、フレームワーク横断のオーケストレーションを実現しようとしています。
仕様の 3 つの柱
1. Job Envelope（ジョブのエンベロープ）
エージェント間で受け渡すジョブを、共通スキーマで包みます。
{
"job_id": "j-2026-04-27-abc123",
"from": "agent.coordinator",
"to": "agent.code-writer",
"task": {
"type": "implement",
"spec": "POST /users エンドポイントを追加",
"constraints": ["TypeScript 5.x", "express 5.x"]
},
"context_refs": ["ctx://session/01HX..."],
"deadline": "2026-04-27T15:00:00Z",
"callback": "agent.coordinator.on_complete"
}ポイントは context_refs が URI 参照 になっていることです。コンテキスト本体をジョブに埋め込まず、参照だけ渡すことで、トークン消費を抑えつつ「同じ会話履歴を複数エージェントが見る」状況を作れます。
2. State Bus（状態バス）
複数エージェントが同じ状態を読み書きするための、Pub/Sub 型のステートバス仕様です。
| イベント | 意味 |
|---|---|
state.created | 新しい状態オブジェクトが生成された |
state.updated | 既存状態が更新された（diff 含む） |
state.locked | 排他更新中（ロック解除まで他エージェントは待機） |
state.archived | 状態が完了し、長期保管に移った |
実装は Redis Streams / NATS / Kafka などを抽象化したアダプタ方式で、SDK 実装が現時点で TypeScript / Python / Go の 3 つ提供されています。受託で TypeScript を選んでも、後で Python のエージェントを追加できる構造です。
3. Trace Spec（トレース仕様）
OpenTelemetry と互換性を保ちつつ、エージェント特有の属性（プロンプト・思考ログ・ツール呼び出し）を表現する拡張です。
span:
name: agent.code-writer.invoke
attributes:
symphony.agent_id: agent.code-writer
symphony.job_id: j-2026-04-27-abc123
symphony.tools_used: ['mcp.github.create_pr', 'mcp.fs.write']
symphony.tokens_in: 4521
symphony.tokens_out: 1023
symphony.cost_usd: 0.018Langfuse・Datadog APM などはすでに Symphony Trace Spec への対応を表明済み（公式発表時点）。観測ツールを後から差し替えやすい構造になっています。
既存フレームワークとの関係
OpenAI Agents SDK v2 の記事 で取り上げた Agents SDK や、Anthropic Claude Code、CrewAI、LangGraph などとの関係を整理します。
| 既存フレームワーク | Symphony との関係 |
|---|---|
| OpenAI Agents SDK v2 | ネイティブ対応（ファーストパーティ） |
| Anthropic Claude Code | アダプタ提供予定（コミュニティ実装が進行中） |
| LangGraph | アダプタ実装済（実験的） |
| CrewAI | アダプタ実装済 |
| Mastra | 公式対応中（リファレンス実装の 1 つ） |
つまり Symphony は 「特定 SDK の代わり」ではなく「SDK の上に被せるオーケストレーション層」 です。受託で「LangGraph を使い続けたい」「Claude Code を中心にしたい」という選択は維持できます。
受託案件で採用するかの判断軸
「とりあえず Symphony で組む」と決める前に、3 つの軸でチェックします。
軸 1：エージェントが単独 vs 複数
エージェントが単独で完結するなら、Symphony はオーバースペックです。2 つ以上のエージェントが連携する案件で初めて投資対効果が出ます。
軸 2：観測の重要度
エンタープライズ案件で「監査ログ・トレースを必ず残すこと」が要件にあるなら、Symphony Trace Spec は強い武器になります。逆に PoC 段階の案件では、独自実装のほうが速いケースも多いです。
軸 3：ベンダーロックインの懸念
「OpenAI の仕様だから OpenAI に縛られるのでは？」という懸念は、ライセンスを見ると杞憂です。Apache 2.0 で公開されており、仕様策定もコミュニティに開かれています。MCP のように Linux Foundation 移管 という動きが今後出てくる可能性も高いと見ています。
弊社が PoC 案件で実装する標準構成
弊社で受託したマルチエージェント案件で、Symphony を採用する場合の標準構成です。
[Coordinator Agent]
│
│ Job Envelope (Symphony)
↓
┌──────────────┬──────────────┬──────────────┐
│ Code Writer │ Reviewer │ Test Runner │
│ (Claude) │ (GPT-5.5) │ (Gemini) │
└──────────────┴──────────────┴──────────────┘
│ │ │
└──── State Bus (Redis Streams)────┘
│
Trace → Langfuse異なるモデルベンダーを混在させても、Job Envelope と State Bus が共通仕様なので組み替えコストが低いのが利点です。
コスト感
| 項目 | 期間 | 単価帯 |
|---|---|---|
| Symphony PoC（2〜3 エージェント） | 4〜6 週間 | 250〜500 万円 |
| 本番マルチエージェント基盤構築 | 4〜6 ヶ月 | 1,500〜3,500 万円 |
| 既存エージェントの Symphony 移行 | 6〜10 週間 | 400〜900 万円 |
| 観測基盤統合（Langfuse / Datadog） | 単発 | 200〜500 万円 |
まとめ ─ 「マルチエージェントの共通言語」を 2026 年中に決める
Symphony は OpenAI 主導の仕様ですが、本質的には 「マルチエージェントを業界標準のフォーマットで動かす」 試みです。受託開発の現場では、案件ごとに異なる SDK を採用しても、Job Envelope と State Bus を Symphony に揃えておけば、「次の案件で別 SDK に乗り換える」コストを大幅に減らせます。
弊社では、Symphony を中心に据えたマルチエージェント基盤の設計・PoC・本番構築・運用伴走を受託で行っています。「複数のエージェントを業務フローに組み込みたい」「既存のエージェントを横断観測したい」というご相談は、お問い合わせフォーム からお気軽にどうぞ。
