OpenAIがCodexオーケストレーションの仕様「Symphony」をオープンソース化

2026年4月27日公開

原文リンク：https://openai.com/index/open-source-codex-orchestration-symphony/

リポジトリリンク：https://github.com/openai/symphony

半年前、OpenAIのチームが社内向けの効率化ツールを作っていたとき、当時としてはかなり物議を醸す決断を下しました。それは、コードリポジトリ全体に人間が書いたコードを一切許容せず、一行たりともCodexによって生成させる、というものです。

この目標を達成するために、彼らはエンジニアリングのワークフローを根本から設計し直しました。エージェントに優しいコードリポジトリを構築し、自動テストと安全策に多額の投資を行い、Codexを正式なチームメンバーとして扱ったのです。この経験は、以前のブログ記事「Harness Engineering」で詳しく記録されています。

この仕組みは確かに機能しましたが、やがて彼らは新たなボトルネックに直面しました——コンテキストスイッチングです。

この問題を解決するために、彼らはSymphonyと呼ばれるシステムを構築しました。Symphonyはエージェントオーケストレーターであり、Linearのようなプロジェクト管理ボードを、Coding Agentのコントロールハブに変えます。つまり、保留中の各タスクにエージェントが割り当てられ、エージェントは継続的に実行され、人間は結果をレビューするだけで済むのです。

この記事では、Symphonyがどのようにして作られたのか（一部のチームでは最終的にマージされたPRの数が500%増加しました）と、このシステムを使って自分のIssueトラッカーを、止まることのないエージェントオーケストレーターに変える方法について説明します。

インタラクティブなCoding Agentの限界

Coding Agentはますます使いやすくなっていますが、ウェブ経由であれコマンドライン経由であれ、本質的には依然としてインタラクティブなツールです。

OpenAI社内でエージェントの規模が拡大するにつれて、新たな負担が浮上し始めました。各エンジニアが複数のCodexセッションを同時に開き、タスクを割り当て、出力を確認し、方向性を調整する、ということを繰り返していたのです。実際に運用してみると、ほとんどの人は3つから5つのセッションを同時に管理するのがやっとで、それを超えると効率が落ち始めました。どのセッションで何をしていたか忘れてしまったり、エージェントを軌道に戻すために各ターミナルを飛び回ったり、途中で止まってしまった長時間のタスクをデバッグしたりする必要があったのです。

エージェントの実行速度は非常に速いのですが、ボトルネックは人間の注意力にありました。このやり方は、非常に有能なジュニアエンジニアのチームを編成し、人間のエンジニアが彼らを監視するようなものです。これは長続きする方法ではありません。

視点を変える

チームは、最適化の方向性を間違えていたことに気づきました。以前のワークフローは「セッション」と「PRマージ」を中心に構成されていましたが、これらは目的ではなく手段に過ぎません。ソフトウェア開発の本質は、Issues、タスク、チケット、マイルストーンといった、成果物を中心に展開されます。

そこで彼らは自問しました。「エージェントを直接監視するのではなく、エージェントが自らタスクトラッカーからタスクを取得して実行するようにしたらどうなるか？」と。

このアイデアがSymphonyになりました。Symphonyはドキュメントとして記述された「仕様（spec）」であり、エージェントの作業を指揮する監督者の役割を果たします。

Issue Trackerをエージェントオーケストレーターに変える

Symphonyの核となる理念は非常にシンプルです。それは、すべての保留中のタスクには、それを完了させるエージェントが存在すべきである、ということです。複数のタブでCodexセッションを監視する代わりに、Issueトラッカーをコントロールハブに変えるのです。

このワークフローでは、各Linear Issueが独立したエージェントワークスペースに対応します。Symphonyはタスクボードを継続的に監視し、各アクティブなタスクにエージェントが割り当てられ、完了するまで実行されるようにします。エージェントがクラッシュしたり停止したりした場合、Symphonyはそれを再起動します。新しいタスクが発生すると、Symphonyはそれを拾い上げ、割り当てます。

ワークフロー全体はチケットのステータスに基づいて駆動され、Linearをステートマシンとして利用します。

実際に使ってみると、Symphonyは「作業」を「セッション」や「PR」から切り離しました。複数のリポジトリにまたがって複数のPRを生成するIssueもあれば、純粋に調査分析であり、コードには一切触れないものもあります。

こうして作業が抽象化されると、1枚のチケットがより大きな粒度の作業単位を表せるようになります。

チームは、複雑な機能開発やインフラ移行をオーケストレーションするためにSymphonyをよく利用します。例えば、エージェントにコードベース、Slackの記録、Notionドキュメントを分析させ、実装案を出力させるタスクを直接依頼できます。案が承認されると、エージェントはタスクツリーを生成し、作業を複数の段階に分解し、依存関係を定義します。

エージェントはブロックされていないタスクのみを処理するため、実行プロセス全体が自然に最適な並列方式で展開されます。例えば、ReactのアップグレードがVite移行に依存しているとマークされていれば、エージェントはVite移行が完了するのを待ってからReactのアップグレードを開始するため、完全に期待通りに動作します。

エージェントは自らタスクを作成することもあります。実装やレビューの過程で、現在のタスク範囲外の改善点（パフォーマンスの問題、リファクタリングの機会、より良いアーキテクチャ案など）を頻繁に発見します。その場合、彼らは直接新しいIssueを作成し、人間による評価とスケジューリングを待ちます。これらの後続タスクも、しばしばエージェントによって引き続き実行されます。

この作業方法は、曖昧なタスクを開始する心理的コストを大幅に引き下げます。エージェントが作成したものが完全に見当違いだったら？それも問題ではありません。それ自体が貴重な情報であり、コストはほぼゼロです。チケットを発行してエージェントにプロトタイプを探求させ、気に入らなければ単に破棄すればよいのです。

オーケストレーターはDevbox上で動作するため、決してオフラインになることはなく、いつでもどこでもタスクを依頼でき、必ずエージェントが処理してくれることが分かります。チームのあるエンジニアは、電波状態が非常に悪い小さな山小屋で、携帯電話のLinearアプリだけを使って3つの重要な変更を完了させました。

仕事のやり方が変わり、探索性も高まる

Symphonyを使用して最も直感的に分かる変化は、アウトプットの量です。OpenAI社内の一部のチームでは、最初の3週間で最終的にマージされたPRの数が500%増加しました。社外では、Linearの創業者であるKarri Saarinen氏も、Symphonyのリリース前後でワークスペース作成数に顕著なピークが見られたことに気づきました。しかし、より深い変化は、チームの仕事への向き合い方にありました。

エンジニアがCodexセッションを監視する必要がなくなると、コード変更ひとつひとつの「心理的コスト」が全く変わります。実装そのものを人間が推進する必要がなくなり、各変更の知覚コストは大幅に低下します。

これは人々の行動に直接影響を与えました。Symphonyで探索的なタスクを起票することが非常に簡単になりました。アイデアを試す、リファクタリングを実行する、仮説を検証する、そして価値がありそうな結果だけを残すのです。

同時に、作業を開始するハードルも下がりました。プロダクトマネージャーやデザイナーは、コードの知識がなくても、自分でCodexセッションを管理する必要もなく、Symphonyに直接機能リクエストを送れるようになりました。彼らが機能を説明すれば、実際の製品で動作する機能の動画デモを含む完全なレビューパッケージを受け取ることができます。

大規模なモノレポ（例えばOpenAI社内で使用されているもの）では、Symphonyにはもう一つの優れた点があります。それはCIを監視し、必要に応じて自動的にリベースし、コンフリクトを解決し、不安定なチェックを再試行し、人間が見守ることなく変更内容をメインブランチまで届けることです。チケットがMergingステータスに入ったら、基本的に問題なく着地すると安心できます。

Symphonyの導入後、より多くの作業がエージェントに委任され、人間のリソースはより困難で探索価値の高いタスクに集中できるようになります。

新しい働き方がもたらす、新たな問題

このレベルの運用方法には、当然ながら代償も伴います。エージェントと直接対話して監視する状態から、チケットレベルでタスクを割り当てる状態に移行することは、いつでも介入して途中で修正する機会を失うことを意味します。エージェントが作成したものが完全に見当違いな場合もありますが、これらの失敗自体に価値があり、システムの脆弱性を明らかにし、メカニズム全体をより堅牢にすることを促進します。

この状況に直面して、チームは結果を手動で修正するのではなく、エージェントが次回は正しく実行できるように、ガードレールとスキルを追加しました。長期的には、これが彼らにハーネスへの新しい機能追加を継続的に促しました。エンドツーエンドテストの実行、Chrome DevToolsを介したアプリケーションの操作、QAスモークテストの管理などです。同時にドキュメントも大幅に改善し、「良いアウトプットとは何か」をより明確に説明するようになりました。

もちろん、すべてのタスクがSymphonyのこの働き方に適しているわけではありません。特に曖昧な問題や、強力な判断力と専門的経験を必要とする作業には、依然としてエンジニアがインタラクティブなCodexセッションを直接使用する必要があるものもあります。実際のところ、こうした種類のタスクは、多くの場合エンジニアが最も興味を持ち、最も楽しめる部分でもあります。

Symphonyがカバーできるのは、大量の定型的な実装作業であり、これによりエンジニアは一度に一つの難しい問題に集中でき、多数の小さなタスク間で絶えず切り替える必要がなくなります。

チームはまた、エージェントをステートマシンの死んだノードとして扱うことは通用しないことにも気づきました。モデルはますます強力になり、当初想定されていた枠をはるかに超える問題を解決できるようになります。初期のアプローチでは、Codexにタスクを実装させるだけでしたが、すぐに限界が明らかになりました。Codexには、複数のPRを作成し、レビューフィードバックを読み取り、修正意見を処理する能力が十分にあります。そこで、古いPRを閉じたり、完了した作業と放棄された作業のレポートを出力したりするなど、より多くのことを行わせるために、gh CLIやCIログを読み取る機能などのツールが与えられました。これらのタスクは、「機能を実装する」という当初の枠を完全に超えています。

最終的にチームは、厳格な状態遷移フローを規定するのではなく、エージェントに目標を割り当てる方向へと徐々に移行しました。それは、優れたマネージャーが直属の部下に目標を与え、一歩一歩の手順を細かく指示しないのと同じです。モデルの価値はその推論能力にあり、ツールとコンテキストを与え、自ら発揮させることにあります。

Symphonyを使ってSymphonyを構築する

Symphonyのコードリポジトリを開くと、まず興味深いことに気づくでしょう。技術的な観点から見ると、Symphonyは単なるSPEC.mdファイルであり、問題の定義と期待される解決策の説明に過ぎません。チームは複雑な監視システムを構築するのではなく、問題と期待される方向性を明確に定義し、エージェントに高レベルのガイダンスを提供しました。

# Symphony Service SpecificationStatus: Draft v1 (language-agnostic)Purpose: Define a service that orchestrates coding agents to get project work done.## 1. Problem StatementSymphony is a long-running automation service that continuously reads work from an issue tracker(Linear in this specification version), creates an isolated workspace for each issue, and runs acoding agent session for that issue inside the workspace....

リファレンス実装はElixirで書かれています。なぜなら、コードのコストがほぼゼロになると、ついに言語の特性に基づいて言語を選択できるようになり、Elixirは並行性において自然な強みを持っているからです。しかし、核となる考え方は、実際にはMarkdownドキュメントに過ぎません。チームは、この仕様書を自分好みのCoding Agentに直接投げて、独自のバージョンを実装させることを推奨しています。

Symphonyの最初のバージョンは、tmux内で動作するCodexセッションに過ぎず、Linearをポーリングして新しいタスクのために子エージェントを起動していました。使えますが、信頼性は十分ではありませんでした。2番目のバージョンは、メインのプロジェクトリポジトリに組み込まれました。このリポジトリはもともとエージェント向けに設計されており、チームは以前からエージェントが高品質な作業を行えるようにハーネスを構築していました。Symphonyはこれら全てを接続しただけです。

基本機能が整った後、チームはSymphony自身を構築するためにSymphonyを使い始めました。

システム管理タスクを社内でデモし、作業証明のビデオを自動的に添付した後、反響は予想外に大きく、Symphonyのプロジェクトチャンネルは急速に成長し始め、各チームが自発的に使用し始めました。OpenAIでは、社内プロダクトマーケットフィットが外部公開の前提条件ですが、社内利用データはSymphonyが共有する価値があることを明確に示していました。

そこでチームは、核となる考え方を独立したSPEC.mdに抽象化し、Codexにそれを実装させました。リファレンス実装にはElixirを選択し、その後も継続的に仕様と実装の両方で反復を繰り返しました。仕様を磨き上げるために、彼らはCodexにTypeScript、Go、Rust、Java、Pythonでそれぞれ実装させ、その結果を使って仕様の曖昧さを見つけ、システム設計を簡素化しました。各言語で動作させることに成功しました。

構築プロセス全体を通して、チームは特定のリポジトリやLinear MCPへの依存といった、偶発的な複雑さを大量に排除しました。Symphonyは内部リポジトリや内部ワークフローに依存しなくなり、中核的なアプローチは非常にシンプルになりました。

保留中のすべてのタスクに対して、そのタスク専用のワークスペースでエージェントが継続的に実行されることを保証する。

具体的な作業の遂行を支援するだけでなく、開発ワークフロー自体も、エージェントが従うべきものとして理解できる形になりました。このプロセス——Issueに対応し、リポジトリをチェックアウトし、PMに対応中であることを知らせるために「進行中」に設定し、PRを追加し、「レビュー」ステータスに変更し、動画を添付するなど——は、以前はエンジニアの暗黙の了解によって維持されており、文書化されたことはありませんでした。現在、これらはWORKFLOW.mdに記述され、Symphonyはエージェントが各ステップを確実に実行するようにします。将来、エージェントに完了した作業に対する自己評価を添付させたい場合、WORKFLOW.mdに追加するだけで、Symphonyはエージェントをそのステップへと導きます。

全プロセスでCodexのApp Serverモードも活用されました。これはヘッドレス実行用に特別に設計された内蔵モードで、洗練されたJSON-RPC APIを介してプログラム的にCodexと対話できます。例えば、スレッドを開始したり、ターンイベントに応答したりできます。これは、CLIやtmuxセッションを介して対話するよりもはるかに便利で拡張性があります。

Codex App Serverは、このシナリオに非常に適合しています。Codexが提供するハーネスを活用する一方で、接続可能な十分な数のノブとフックがあります。例えば、Linearのアクセストークンを子エージェントに公開することを避けるために、チームは動的ツール呼び出しを使用し、生のlinear_graphql関数をエージェントに公開しました。これにより、MCPを使用したり、トークンをコンテナに公開したりすることなく、Linearに対する任意のリクエストを実行できます。

次のステップ

Symphonyは、意図的に極めてシンプルに保たれたオーケストレーションレイヤーです。これをオープンソース化した目的は、Codex App ServerとLinearのようなワークフローツールを組み合わせた場合の可能性を示すことです。リファレンス実装として、チームはSymphonyを独立した製品として継続的にメンテナンスするつもりはなく、むしろ設計図として扱っています。かつて多くの開発者が、リポジトリの足場を構築するためにHarness Engineeringのブログ記事を自分のエージェントに投げたように、皆さんにもSymphonyのSpecとリポジトリを好みのCoding Agentに投げて、自分のチームに合ったバージョンを構築してほしいと願っています。

真の力はCodexとそのApp Serverから生まれます。Symphonyは、すでに使用しているCodexとLinearという2つを接続し、作業管理の問題を解決するだけです。Coding Agentの推論能力と命令追従能力が絶えず向上するにつれ、他の企業のボトルネックも「コードを書くこと」から「エージェントの作業を管理すること」へと移っていくかもしれません。ワクワクするのは、この種のCoding Agentシステムで実験を行うハードルが、今や驚くほど低くなっていることです。何か試したいことがあれば、直接Codexを使って実行すればよいのです。

コミュニティからの反響

リリース以降、このプロジェクトはGitHubで（4月23日時点で）15,000以上のスターを獲得しています。

コミュニティではすでに行動を起こしている人々がいます。ある人は、Elixir ERPアプリケーションで、GenServerと本番環境のバグをキャプチャして自動修正をコミットするカスタムエージェントを備えた完全なダッシュボードを、ワンクリックでエージェントに作成させました。また、GoとCharm CLI TUIスタックを使用して独自のバージョンを実装した人や、SymphonyをClaude CodeとGitHub Issuesをサポートするバージョンに改造し、Homebrew経由でインストールを提供している人もいます。

これこそが、オープンな仕様を公開する意義です。方向性を示し、コミュニティに自ら走ってもらうことなのです。