OpenAIは2026年4月27日、「Codex（AIコーディングエージェント）オーケストレーション（複数のAIを協調させて動かす仕組み）のためのオープンソース仕様：Symphony」を公開しました。

Symphonyは、Linear（リニア）のような課題管理ツールを、CodexなどのAIコーディングエージェントを動かすための制御盤に変えるオープンソース仕様です。実験的な参照実装も含まれています。

単なる便利ツールというより、AIコーディングエージェントを「人間が横で操作する相手」から「チケット単位で仕事を任せる相手」へ移す試みです。今回はこのユニークな取り組みについて解説します。

チケットの進行状況に応じて、複数のCodexエージェントが作業を進める様子を示しています。

人間が複数セッションを見張る方式には限界がある

はじまりはOpenAI社内チームが6か月前に取り組んだ内製ツールです。そのリポジトリ（コードを管理する場所）では、人間がコードを書かず、すべての行をCodexに生成させるという大胆な方針が採られました。エージェント向けのリポジトリ設計や自動テスト、ガードレール、Codexをチームメイトとして扱う運用を整えた結果、開発自体は動き始めたのです。ところが次に壁になったのが、人間側の文脈切り替えでした。

Codexのようなコーディングエージェントは、WebアプリやCLI（コマンドライン）から気軽に使えるようになっています。しかし、エンジニアが複数のCodexセッションを開き、それぞれに作業を与え、出力を確認し、必要に応じて方向修正するようなやり方だと、3〜5セッションほどで人間の注意力が苦しくなり、生産性が下がってしまいます。

これは、エージェントの能力不足だけの話ではありません。むしろ、エージェントが速く動くほど、人間が「どのセッションが何をしているのか」を覚え続ける負荷が増えます。端末やブラウザタブを行き来し、止まったタスクを再起動し、途中結果を追いかけなければなりません。AIが実装を進めても、人間の監督コストが膨らむなら、チーム全体の速度は詰まってしまいます。

OpenAIのチームは、最適化する対象を変えました。コーディングセッションやPR（プルリクエスト：コードの変更をチームにレビュー依頼する仕組み）を直接管理するのではなく、ソフトウェア開発で本来使われている作業単位——issue（課題）やタスク、チケット、開発上の区切りを中心に置く発想です。人間がCodexセッションを見張るのではなく、エージェントがタスク管理ツールから仕事を取りに行くという考え方です。

Symphony導入前後で、人間の監督作業とエージェントへの委任の比重が変わる様子を示しています。

Symphonyは課題管理ツールをエージェントの制御盤にする

Symphonyの基本はシンプルです。Linear（課題管理ツール）に登録されたチケットを、AIエージェントへの作業依頼として扱います。Symphonyはそのチケット一覧を定期的に確認し、作業対象になっているチケットごとに、Codexエージェントが動く専用の作業場所を用意します。新しい仕事が追加されればAIに担当させ、途中で止まった作業があれば再開させます。

これにより、人間はCodexの画面をいくつも開いて見張るのではなく、普段使っている作業ボードを見ながら、AIに仕事を任せられるようになります。

Symphonyが扱う作業は、必ず1つのPRに対応するとは限りません。あるissueから複数リポジトリにまたがる複数のPRが生まれる場合もあれば、コードを書かずに調査や分析だけで終わる場合もあります。OpenAIは、複雑な機能やインフラ移行にもSymphonyを使っており、エージェントがコードベース、Slack、Notionを調べて実装計画を作る例も紹介しています。

さらに、タスクを依存関係つきで分解し、先に進められるタスクだけを並列に進める運用も説明されています。たとえば、Reactアップグレードという作業がVite移行の完了待ちになっていた例では、Vite移行が終わった後にReactアップグレード側のエージェントが動き出したそうです。人間が順番を細かく指示し続けるのではなく、タスク同士の関係をもとに実行順が決まるわけです。

公開デモでは、課題管理ツール上のチケットを起点に、エージェントが作業を進める様子が紹介されました。

3週間でPRが500％増加、失敗から学ぶ設計も必要

OpenAIは、Symphonyの効果として、社内の一部チームで最初の3週間にマージ済みPR数が500％増加したと述べています。もちろん、この数字はOpenAIの特定チームの結果であり、どの組織でも同じ伸び方をするとは限りません。それでも、AIエージェントを「手元の補助ツール」として使う段階から「継続稼働する作業担当」として運用する段階へ進むと、チームの振る舞いが変わることは伝わってきます。

面白いのは、アウトプットの増加だけでなく、試行錯誤のコストが下がったという点です。エンジニアがCodexセッションを常に見張らなくてよくなると、試したいリファクタリング（コードの整理・改善）、仮説検証、プロトタイプを気軽にチケット化できます。プロダクトマネージャーやデザイナーも、リポジトリをチェックアウトしたりCodexを直接操作したりせず、機能要望をSymphonyに投げられると説明されています。

大規模なモノレポ（複数プロジェクトを1つのリポジトリで管理する手法）でも効果が出やすいようです。OpenAIは、CI（継続的インテグレーション：コードの自動テスト・ビルドの仕組み）を監視し、必要に応じてrebase（変更の取り込み）し、コンフリクト（競合）を解消し、flakyなチェック（不安定なテスト）を再試行し、PRがmainブランチに入るまで導く役割を挙げています。

課題管理ツールの作業ボード全体を表示したデモ画面です。チケットが未着手、作業中、人間の確認待ちに相当する状態で並んでいます。

SPEC.mdとWORKFLOW.mdが、暗黙の開発手順をエージェントに渡す

GitHubで公開されたopenai/symphonyを見ると、Symphonyはそのまま製品として導入する完成品というより、SPEC.md（仕様書ファイル）と実験的なElixir（エリクサー：並行処理に強いプログラミング言語）実装を含む参照実装として位置づけられています。READMEでも、信頼できる環境で試すための控えめなエンジニアリングプレビューだと説明されています。ライセンスはApache-2.0です。

SPEC.mdの中核は、課題管理ツールを一定間隔で確認し、同時に動かすエージェント数を調整しながら作業を割り当てるサービスです。タスクごとに専用の作業場所を作り、チケットの状態が変わったら実行中の作業を止め、一時的な失敗には少し間隔を空けながら再試行します。リポジトリ側にはWORKFLOW.mdを置き、チーム固有のプロンプト（AI指示文）や実行設定、フック、引き継ぎ条件を明文化します。

これまで暗黙知となっていた開発手順がWORKFLOW.mdに書き出されることで、大きなメリットが生まれます。issueに取り組み、リポジトリを準備し、進行中にし、PRを作り、レビュー状態へ移し、動画や作業証跡を添付するという、人間が普段なんとなくやっていた流れを、エージェントが読める約束事に変えるわけです。これはAI導入以前に、チームの開発プロセスを強くする動きでもあります。

GitHubで公開されているopenai/symphonyリポジトリ（https://github.com/openai/symphony）です。

Symphonyは製品ではなく、各チームが自分の環境に移植するための見本

OpenAIによると、Symphonyを単独製品として保守する予定はないとのことです。むしろ、Codex App ServerとLinearのようなワークフローツールを組み合わせると何ができるかを示すリファレンス実装（参照実装）と言えます。OpenAIは、Codexのヘッドレスな（UIなしの）app server modeを使い、JSON-RPC API（プログラム間の通信形式）でスレッド開始やターンへの反応をプログラムから扱えることも紹介しています。

参照実装にElixirを選んだ理由も、並行プロセスのオーケストレーションや監督に強い言語だからです。OpenAIは、SPEC.mdをもとにCodexへ実装を依頼し、Elixir実装を作らせたうえで、TypeScript、Go、Rust、Java、Pythonでも実装させ、仕様の曖昧さを見つけて簡素化したと説明しています。AIに仕様を渡し、複数言語で実装させ、仕様そのものを磨く流れはかなり今っぽい開発手法です。

Symphonyの価値は「エージェントが人間の代わりに全部やる」ことではなく、「人間が何を管理すべきかを変える」ことにあると思います。コードを書く作業が安く速くなるほど、次に高くなるのは、何を任せるか、どの状態で止めるか、どの証跡をもって受け入れるかという設計です。

AIエージェント時代の開発は、プロンプト（AI指示文）だけでなく、issue tracker（課題管理ツール）、CI、ドキュメント、権限を含む運用設計の勝負になっていきそうです。

Symphonyの仕組みをまとめた解説画像です。