OpenAI Symphony 解説【2026年版】— 「Linearチケット → AIエージェント → PR」を自動で回すオープンソース仕様の正体

OpenAI Symphony は、コーディングエージェント Codex を「個別タスクごとに自律稼働させ続ける」ためのオープンソース仕様です。中核アイデアはシンプルで、Linear（チケット管理ツール）に積まれたタスク1枚ごとに、専用ワークスペースと専用 Codex エージェントを割り当てるというもの。各エージェントは、そのチケットが完了状態に到達するまで自分のループの中で走り続けます。OpenAI 自身が「Symphony は単独プロダクトとしては保守しない参照実装」と明言しており、SPEC.md（Markdown で書かれたプロトコル仕様）と、それを Elixir で動かしたリファレンス実装が GitHub の `openai/symphony` で公開されています。

AI コーディングツールはここ数年で「対話して書かせる」「Issue を貼って提案を受ける」段階まで到達していましたが、Symphony はそこから一歩踏み込んで 「人間がチケットを切ったあとは、エージェントに任せて寝る」 という前提のオペレーションモデルを提案しています。 - 既存: 開発者が IDE 上で Codex / Cursor / Copilot に依頼 → 都度レビュー - Symphony: PM・デザイナーがチケットを書く → 仕様に沿ってエージェントが自走 → PR を返す OpenAI が公表した社内データでは、Symphony 導入から最初の3週間で マージされた Pull Request が約6倍に増えた との報告があり、開発オペレーションの "単位" が個人作業からチケット並列処理へ大きく揺れていることを象徴するリリースです。

Symphony の Elixir 参照実装は、次の3段ループで動きます（公開ドキュメントに基づく整理）。 1. Poll（既定 30 秒間隔で Linear をポーリング）: アクティブ状態のチケットを取得 2. Dispatch（チケットごとに分離されたワークスペース＋Codex プロセスを起動）: 設定済みのワークフロープロンプトと、チケット文脈を Codex に渡す 3. Execute（チケットが終端状態に到達するまで Codex が走り続ける）: クラッシュしたエージェントは Erlang/OTP のスーパーバイザが自動再起動 各エージェントは独立したワークスペース（ファイルシステム上の独立ディレクトリ）を持つため、チケット間のコード変更が干渉しない ように設計されています。Erlang/OTP のスーパーバイザツリー上で動く構造は、長時間並列・障害時自動回復・部分故障の隔離という "電話交換機由来の堅牢性" を、AI エージェント運用にそのまま当てている、と捉えると理解しやすいです（Erlang/OTP の歴史的背景については、本サイトのElixir コラムも参照）。

OpenAI 公式の説明では、Elixir を選んだ理由として "並行プロセスを supervise する原始的な道具立てが優れている" という点が挙げられています。短く言えば、「数百〜数千のエージェントを同時に走らせ、片方が落ちても全体は止まらない」性質を、言語レベルで標準装備しているのが Elixir / Erlang/OTP の特徴です。 また興味深いのは、Symphony 公開時にチームが Codex 自身に TypeScript / Go / Rust / Java / Python での再実装を依頼し、その結果を SPEC の曖昧さ検出に使った という運用です。AI 自身が複数言語実装を生成することで、仕様の透明性を高めるという "スペック設計の新しい流儀" を示しています。

公開資料で言及されている特に注目すべき設計： - エージェントが Linear に追加チケットを書ける: 担当タスクの周辺で「あ、ここ別途リファクタリングが必要」「このエンドポイントは性能改善余地あり」と気づいたとき、その場で 新しいチケットとして Linear に追加 できる。サイドオブザベーションが "取りこぼされる気づき" にならず、キューに入る - PM・デザイナーが直接チケットを書く運用が現実的に: リポジトリをチェックアウトしなくても、機能要望を書いて Symphony に渡すと、動画ウォークスルー付きのレビューパケットが返ってくる 「AI が IDE 内ヘルパーから業務オペレーションの主体に変わる」という業界全体の潮流の、現時点で最もくっきりした実装例の一つだと言えます。

向く案件 - 複数の小〜中サイズタスクを並列で消化したい開発組織: Linear のバックログをそのまま AI に流せる - PM・デザイナーが多く、開発者が "チケット消化のボトルネック" になっている組織: Symphony がチケット消化を肩代わり - テスト・ビルド・CI が成熟している環境: エージェントが PR を出した後の検証パイプラインが信頼できないと、品質劣化が早い - 明確なコーディング規約・アーキテクチャドキュメントがある: エージェントへの "前提プロンプト" として活用できる 向かない案件 - 機密性が極めて高く、Codex API への送出が許されない（→ DGX Spark + ローカル LLM のような構成と組み合わせる必要あり） - チケットが "探索的・曖昧" すぎる（要件抽出から AI に任せたいなら別の体制が必要） - レビューを通さずマージできない契約・規制下の業務（医療・金融基幹系・防衛 等）

- "参照実装" でありプロダクトではない: OpenAI は Symphony を単独プロダクトとして保守しない方針。本番採用するなら 自社で fork して運用 する前提で SPEC.md を読み込む必要あり - PR 数の爆発に運用が耐えるか: 6倍のマージという社内データは、レビュー・QA・デプロイ側の体制も同時に強化されている前提で出ている数字。レビューがボトルネック化すると "未レビュー PR の山" が新しい技術負債を作る - ライセンス・著作権の整理: AI が大量にコードを書く以上、生成物のライセンス取り扱い・サードパーティライブラリの混入チェックを CI に組み込む - チケットの粒度設計: チケットが小さすぎるとエージェントが多すぎて API コストが嵩み、大きすぎると終わらない。社内基準を最初に決める - Codex API コスト: 並列エージェント分の課金が走る。ピーク時の予算上限・優先度キューを実装するのが現実解 - Linear 以外への移植: 仕様自体は "状態機械を持つチケットボード" を抽象化しているため、JIRA / GitHub Issues / Asana への移植は技術的には可能。ただし参照実装は Linear 前提

オブライトでは、Symphony の SPEC を「チケット駆動 AI 開発」の標準語彙として参考にしつつ、お客様の環境（Linear / JIRA / GitHub Projects）と機密性要件に合わせた中間層を設計します。 - クラウド送出 OK の案件: Symphony 参照実装を fork、Codex を裏で動かす - 機密性の高い案件: SPEC のオーケストレーション思想だけ借りて、エージェント本体は DGX Spark 上のローカルモデルや、OpenClaw のエージェント基盤に差し替える二段構え - PM・デザイナーがチケットを書ける運用: DocDD（Document Driven Development） のテンプレートに沿ってチケットを書いてもらうことで、エージェントへの前提プロンプトの質を底上げ ソフトウェア開発 や AI 導入コンサルティング の文脈で、Symphony 風オペレーションの段階導入をご相談いただけます。

Q1: Symphony は OpenAI が今後アップデートし続けますか？ A: 公式は 「単独プロダクトとして保守しない」 と表明しています。SPEC は更新される可能性がありますが、運用するなら自社 fork が前提です。 Q2: Linear 以外でも使えますか？ A: 仕様レベルでは状態を持つボードであれば移植可能です。ただし参照実装は Linear 前提なので、別ボードへ移植する作業は自分たちで行う必要があります。 Q3: PR が大量に出てレビューが追いつきません A: チケット粒度の調整、優先度キュー、AI 同士のクロスレビュー、自動テストの強化、人間レビュー前のフィルタが現実解です。Symphony を入れる前に CI・レビュー体制を強化する のが定石です。 Q4: Elixir を書けない組織でも使えますか？ A: 利用するだけなら Elixir のコードを書く必要はありません。ただし fork してカスタマイズする際は Elixir / OTP 知識が必要になるため、社内に1人以上は触れる人を確保するか、外部パートナーと組むのが現実的です。 Q5: 既存の Codex / Cursor / Claude Code の使い方とどう違いますか？ A: 既存ツールは "開発者を補助するアシスタント"。Symphony は "開発者を介さずチケットからPRまで走らせるオーケストレーター"。共存可能で、複雑タスクは人＋ AI、定型タスクは Symphony 任せ、という棲み分けが現実的です。 Q6: 予算感は？ A: チケット数 × 平均トークン消費量 × 単価 で試算します。並列稼働するため瞬間消費は跳ねやすく、月額上限・優先度キュー・夜間バッチ化など、コスト管理の仕組みを最初から組むことを推奨します。

- An open-source spec for Codex orchestration: Symphony（OpenAI 公式） - openai/symphony（GitHub） - SPEC.md（GitHub） - Elixir 参照実装 README（GitHub） - OpenAI Releases Symphony Codex AI Agent Orchestrator（Winbuzzer） - OpenAI Debuts Symphony to Orchestrate Coding Agents at Scale（DevOps.com） - openai/symphony — DeepWiki - 関連: Elixir 完全ガイド（弊社既存） - 関連: DGX Spark + ローカルLLM ワークフロー（弊社既存） - 関連: DocDD（Document Driven Development）