Symphonyとは何か——誕生の背景
OpenAIは2026年4月、AIコーディングエージェント「Codex」を複数並列で自律的に管理・運用するためのオーケストレーションツール「Symphony」をオープンソース（Apache 2.0ライセンス）でGitHub上に公開した。
リリース後わずか10日余りでGitHub Starsが8,600を超えるなど、開発者コミュニティから大きな注目を集めている。
Symphonyが生まれた背景には、AIコーディングエージェントが実用フェーズに入ったことによる「管理コストの爆発」という問題がある。
従来、CodexやClaude Codeといったエージェントを使う場合、エンジニアは複数のセッションをそれぞれ手動で開き、作業を割り当て、出力を確認し、必要に応じて追加指示を出す必要があった。
OpenAI社内でも、現実的に管理できるセッション数は同時に3〜5件が限界だったという。こうした「エンジニアの注意力がボトルネック」になる構造を解消するために設計されたのが、Symphonyだ。
公式の説明では「Symphonyはプロジェクトの作業を隔離された自律的な実装ランに変え、チームがコーディングエージェントを監視する代わりに仕事そのものを管理できるようにする」と定義されている。一言で表現すれば、「Issueを投入するだけでPRが出てくる工場」である。
仕組みの全貌——LinearからGitHub PRまでの自動フロー
Symphonyのアーキテクチャは、Linearなどのプロジェクトボードをポーリングしてチケットを検出し、チケット単位でCodexエージェントを自動起動、最終的にGitHub上にPull Requestを生成するまでを一気通貫で処理する構造だ。
中核となるOrchestratorは、デフォルトで5秒ごとにLinear APIをGraphQL経由でポーリングし、「Todo」状態のチケットを検出すると、チケットごとに隔離されたワークスペースを自動生成してCodexエージェントを起動する。
各エージェントはリポジトリのクローン、実装、テスト、PR作成、Linear上のステータス更新までを自律的にこなす。
作業が完了すると「Human Review」ステータスに移行し、人間によるレビューを待つ。
人間が承認すれば「Merging」→「Done」へ、修正が必要であれば「Rework」として最初からやり直す設計になっている。
設定はすべて「WORKFLOW.md」という1ファイルに集約されており、YAMLフロントマターでLinearやCodexとの接続設定を行い、Liquidテンプレートでエージェントに渡すプロンプトを定義する。
`{{ issue.title }}`や`{{ issue.description }}`といった変数でチケット情報が動的に注入されるため、チームメンバー全員が同じプロンプトとワークフローでエージェントを動かせる。
このプロンプトをリポジトリ上でバージョン管理できる点は、チーム開発において特に実用的だと評価する声が多い。
エラー処理も堅牢で、一時的なエラーは最大3回まで指数バックオフ（10秒→20秒→40秒）で自動リトライされ、3回失敗した場合は人間に差し戻される。「AIに丸投げして壊れる」リスクを最小限に抑えた設計思想が貫かれている。
Elixir/OTPが採用された理由——技術的選択の合理性
Symphonyのリファレンス実装にElixir/OTPが選ばれたことは、技術的に非常に合理的な判断だと多くのエンジニアが評価している。
AIエージェントは長時間実行されるタスクを処理し、失敗やリトライが頻繁に発生する。Erlang/BEAMのSupervisor Treeを活用することで、複数エージェントの並列実行を自然に実装でき、あるエージェントがクラッシュしても他のエージェントへの影響を自動的に遮断できる。
ホットコードリロードにより、稼働中のシステムを止めずにコードを更新できる点も、常時稼働デーモンとしての運用に適している。
ただし、あくまでリファレンス実装の位置づけであり、OpenAI自身がGitHub上のREADMEで「SPEC.mdに従って好きな言語で実装せよ」と明示している。
仕様書（SPEC.md）に基づいたPython版やTypeScript版の再実装も外部の開発者によって公開されており、Elixirへの依存はあくまで実験的なプロトタイプにとどまる。
実際の効果と限界——導入チームで500%のPR増加
OpenAIが公開したデータによると、Symphonyを導入した社内の一部チームでは、最初の3週間でマージされたプルリクエスト数が500%増加した。「変更ごとのコストが下がり、アイデアの試作やリファクタリングの探索、仮説検証といった作業をチケット化してエージェントに実行させ、有望な結果だけをレビューする運用が可能になった」と同社は説明している。
連続起業家のRyan Carsonが実践している「Code Factory」と呼ぶ運用では、朝にLinearへ5件のIssueを投入し、夕方に完成したPRをレビューするだけという流れで、1日あたり5件のPRを人間のコーディング作業なしに生成しているという。
一方で、Symphonyがすべての作業に適しているわけではない点も強調されている。チケット単位でエージェントに割り当てる方式では、対話型セッションのように途中で細かく軌道修正し続けることは難しい。強い判断力や専門性が必要な曖昧な問題、複雑な設計・アーキテクチャ検討といった作業では、今後もエンジニアが対話型のCodexセッションやClaude Codeを直接使う場面が残るとOpenAIは認めている。また、現時点ではLinear専用であり、JiraやGitHub Issuesへの対応は開発中の段階だ。
さらにコスト面では、10エージェントを並列稼働させた場合、月あたり5,000ドル程度のAPI費用がかかるとの試算も一部で示されており、導入規模に応じた費用設計が必要になる。
Symphonyが前提とする「Harness Engineering」とは
Symphonyの真価を発揮させるには、OpenAIが提唱する「Harness Engineering」と呼ばれる開発基盤の整備が不可欠だ。これは、AIエージェントが自律的に作業できる「装具（ハーネス）」を整備する考え方で、具体的にはCI/CD、自動テスト（ユニット・E2E・型チェック）、リンター・フォーマッター、オブザーバビリティ（ログ・メトリクス）、適切なドキュメントと型定義などが含まれる。
これらがない環境にSymphonyを導入しても、エージェントの成果物を機械的に検証する基準がなく、品質保証ができない。逆に言えば、テストとCIが整備されていれば「CIが通ること」を完了条件としてWORKFLOW.mdに組み込むことができ、エージェントが自律的に品質を担保しながら開発を進められる。Symphonyはオーケストレーション層、Harness Engineeringは実行基盤層であり、両方が揃って初めて「チケット→PR」の自動化が成立する。
まとめ
OpenAIが公開した「Symphony」は、LinearなどのプロジェクトボードのチケットをAIが検出し、Codexエージェントが自動でコードを書いてPull Requestを生成するオーケストレーションシステムだ。Apache 2.0ライセンスのオープンソースプロジェクトとしてGitHubで公開されており、導入した社内チームでは3週間でPR数が500%増加したという実績もある。Elixir/OTPによる堅牢なプロセス管理、WORKFLOW.md一ファイルによる設定の一元管理、指数バックオフを用いた自動リトライ機構などが技術的な強みだ。ただし、現時点ではLinear専用であること、曖昧な問題や複雑な設計には向かないこと、コスト管理が必要なこと、そして「Harness Engineering」と呼ばれる開発基盤の整備が前提となることに留意が必要だ。Symphonyは「コーディングエージェントを監視する」
