［開発者向け］OpenAIがオープンソース公開「Symphony」——コーディングエージェントを自律管理するオーケストレーター仕様とは

2026-04-28

はじめに

　OpenAIが2026年4月27日、コーディングエージェントの実行を自動管理するオーケストレーター仕様「Symphony」をオープンソースとして公開しました。プロジェクト管理ツールをエージェントのコントロールプレーンとして機能させるアプローチで、一部チームではPRのランディング数が500%増加したと報告されています。本稿では、その背景・仕組み・実際の効果を解説します。

参考記事

タイトル: An open-source spec for Codex orchestration: Symphony
著者: Alex Kotliarskyi, Victor Zhu, Zach Brock
発行元: OpenAI Engineering Blog
発行日: 2026年4月27日
URL: https://openai.com/index/open-source-codex-orchestration-symphony/

要点

SymphonyはLinearなどのプロジェクト管理ツールをコーディングエージェントのコントロールプレーンにするオーケストレーター仕様である
すべてのオープンタスクにエージェントを自動割り当てする仕組みで、一部チームでは導入後3週間でPRのランディング数が500%増加した
技術的な核はSPEC.mdファイル1つであり、ElixirによるリファレンスとともにGitHubで公開されている
Codex App ServerのJSON-RPCプロトコルを通じてエージェントとやり取りし、Linear以外のトラッカーにも対応できる設計となっている
スタンドアロンプロダクトではなく「仕様書」として公開されており、各チームが独自実装を構築するための出発点として位置づけられている

詳細解説

コンテキストスイッチングという新たなボトルネック

　OpenAIの内部チームは半年前、「リポジトリ内のコードはすべてCodexで生成する」という方針でプロダクト開発を試みました。この取り組みの経緯と知見はハーネスエンジニアリング記事にまとめられていますが、その成果を踏まえて次のボトルネックが明らかになりました。それが「コンテキストスイッチング」です。

　OpenAIによれば、エンジニアたちは複数のCodexセッションを同時に管理し、タスクを割り当て、出力をレビューし、エージェントを軌道修正するという作業に追われるようになりました。一人が快適に管理できるのは同時に3〜5セッションが限界で、それを超えると生産性が低下したといいます。

　チームが気づいたのは、「セッション管理ではなく、成果物（タスク・チケット・マイルストーン）を軸に仕事を組み直すべきだ」という点でした。エンジニアがエージェントを直接監視するのではなく、エージェントがタスクトラッカーから仕事を「引き取る」仕組みにする——この発想の転換がSymphonyの出発点です。

タスクトラッカーをコントロールプレーンに

　Symphonyのコアコンセプトはシンプルです。「すべてのオープンタスクに対して、エージェントが実行中であることを保証する」というものです。

　具体的には、プロジェクト管理ツールのチケット一覧を常時ポーリングし、アクティブなタスクにはそれぞれ専用のワークスペースを作成してCodexエージェントを起動します。エージェントがクラッシュや停止した場合は自動的に再起動し、新しいタスクが追加されれば自動的に拾い上げます。

　チケット間の依存関係（ブロック関係）も考慮されます。「ReactのアップグレードはViteへの移行が完了するまでブロックされている」という設定をすれば、Viteの移行完了後に自動的にReactのアップグレードを開始します。これはDAG（有向非巡回グラフ）と呼ばれる依存関係グラフに基づく並列実行の仕組みで、ソフトウェア開発のビルドシステム等で広く使われる考え方です。

　エージェントは実装だけでなく、コードベースやSlack・Notionの分析、実装計画の作成、サブタスクへの分解、CIの監視、コンフリクトの解消なども担います。人間は個々の実装を監視するのではなく、タスクの定義とレビューに集中できます。

SPEC.mdファイル1つが技術的な核

　Symphonyの技術的な核心は、実はSPEC.mdというMarkdownファイル1つです。OpenAIによれば「複雑な監督システムを構築するのではなく、問題と意図する解決策を定義し、エージェントへの高レベルな指針を与えた」とのことです。

　主要コンポーネントは以下の通りです。Workflow LoaderがWORKFLOW.mdを読み込み、Orchestratorがポーリングループ・ディスパッチ・リトライを管理し、Workspace Managerがチケットごとのワークスペースを管理します。また Agent Runner がCodex App Serverとプロトコル通信を行い、Issue Tracker Client がLinear GraphQL APIと連携します。

　エージェントとの通信にはCodex App ServerのJSON-RPCベースのプロトコルが使われます。initialize→thread/start→turn/startという順序でセッションを確立し、ヘッドレスモードでCodexをプログラマティックに操作する仕組みです。tmuxやCLIを介さずにエージェントを大規模管理できる点が重要で、Symphonyがこのアーキテクチャを採用した主な理由の一つです。

　ワークフローの定義はリポジトリ内のWORKFLOW.mdファイルに記述します。チケットのステータス遷移ルール・エージェントへのプロンプトテンプレート・フック（セットアップスクリプト等）をここで管理します。これにより「エージェントがどう動くべきか」がコードと一緒にバージョン管理されます。

実際の効果と組織への影響

　OpenAIによれば、一部チームでは導入後3週間でランディングされたPRの数が500%増加しました。また、Linearの創業者Karri Saarinen氏もSymphonyのリリース時にワークスペース作成数の急増を報告しています。

　定性的な変化も大きく、実装コストの心理的ハードルが下がることで「やってみて、気に入らなければ捨てる」というスペキュレイティブな開発が容易になりました。プロダクトマネージャーやデザイナーがリポジトリを操作したりCodexセッションを管理したりすることなく、機能要求をSymphonyに直接投入できるようになった点も注目されます。

　一方でトレードオフもあります。エージェントをインタラクティブに操作する場面での随時修正ができなくなるため、失敗が起きた際は手動でパッチを当てるのではなく、ガードレールとドキュメントを整備して次回の成功率を高める対応が求められます。エンジニアが直接手を動かす作業は、より難易度の高い曖昧な問題へとシフトしていきます。

オープンソース公開と今後

　リファレンス実装にElixirが採用された理由を、チームは「コードが実質的に無償になると、ようやく言語をその強みで選べる」と説明しています。Elixirの並行処理プリミティブが適していると判断したためです。Codexに依頼したところワンショットでElixir実装が完成したといいます。

　仕様の曖昧さを解消するため、TypeScript・Go・Rust・Java・Pythonの5言語でも実装を試み、すべての言語で成功したとOpenAIは述べています。コミュニティによる独自実装も既に登場しており、4月23日時点でGitHubスターは15,000以上となっています。

　Symphonyは「スタンドアロンプロダクトとして維持管理する予定はない」とされており、あくまで仕様書・リファレンス実装として公開されています。任意のコーディングエージェントや課題管理ツールに合わせた独自バージョンを構築する際の出発点として活用することが意図されています。

まとめ

　SymphonyはCodexを活用するチームが直面した「エージェント管理の手間」という現実的な課題への一つの回答です。コーディングエージェントが普及するにつれ、「どう実装するか」から「どう仕事を管理するか」へと関心がシフトするチームは増えると思います。仕様書としての公開により、異なるエージェントや課題管理ツールへの応用も広がると考えられます。