複数のAIエージェントに作業を割り当てるとき、どのissueが進んでいて、誰がレビューするのか。その管理コストが生産性の上限になりつつある状況で、OpenAIが公開したのがSymphonyだ。Codex向けのオーケストレーション仕様であり、Linearのissueを起点に各タスクへ独立した作業空間を割り当て、エージェントが完了すればPRが人間のレビューに届く流れを自動化する。一部チームでPR数が500%増加したとOpenAIは発表しているが、同時に「生成は拡張できても検証はできない」という問題も浮上している。Codex自身がElixirでワンショット実装したことも含め、AI開発の焦点が「生成」から「管理」へ移る転換点となる試みだ。
プロンプト駆動からissue駆動へ、開発指示の単位が変わる
2026年4月28日に公開されたSymphonyは、Codexエージェントを個別のプロンプトではなく、issue tracker上のタスクに紐づけて動かすための仕様だ。リリース後の短期間でGitHubスター数は15,000を超え、5月初旬には19,700から21,300に達した。焦点は、コード生成モデルの性能ではなく、生成された作業をどの順序で走らせ、どこで人間が確認するかを仕様として明文化した点にある。従来の「プロンプトを投げて返答を待つ」使い方から、issueを作業キューに変える設計へ比重が移っている。
プロンプト駆動では、開発者が毎回コンテキストを説明し、生成結果を確認し、次の指示を作る。issue駆動では、Linear上のタスクが共有コンテキストになり、各issueに独立したagent workspaceが作られる。人間は個々のセッションを細かく監視する役割から、キュー、優先度、レビューの流れを管理する役割へ近づく。Symphonyの狙いは、AIエージェントを「会話相手」ではなく「作業単位を受け取る実行者」として扱う点にある。
Linearを司令塔にしてワークスペースを切り分ける
SymphonyはLinearと直接統合し、各issueに対して独立したagent workspaceを作成する。これにより、あるissueで進む変更と別のissueで進む変更を分離し、Codexがそれぞれの作業文脈を持てる。Karri SaarinenはXで、Symphonyのリリース直後にLinearの新規ワークスペース作成が急増したと述べた。共有コンテキストと人間・エージェント間の協調がデモで強調されたことも、Linear側の需要を押し上げた要因と見られる。
Symphonyの仕組みは、issue trackerをタスク一覧ではなく制御面として扱う点にある。issueには目的、制約、参照情報、担当状態がまとまり、エージェントはそこから作業空間を作ってコード変更へ進む。作業結果はPRとして人間のレビュー対象になり、issueと変更履歴が結びつく。開発者にとっては、チャット履歴を追うよりも、issueとPRの関係を見た方が進捗を把握しやすい。
v1.1.0では、SymphonyがKata CLI（Command Line Interface）に対応した。Kata CLIはpi-coding-agentを基盤にしており、この対応はCodex以外のモデルやツールへ仕様を広げる余地を示す。報道では、Claude CodeやGeminiなどのエージェントへの対応可能性も言及されている。OpenAIが仕様をCodex専用の閉じた仕組みにしなかった点は、開発現場の既存ツールチェーンに入り込むうえで重要である。
Elixir参照実装と多言語検証が示す設計思想
参照実装はElixirで書かれ、OpenAIによればCodexがワンショットで完成させた。Elixirが選ばれた理由として、Open Telecom Platform（OTP）の監督木を活用した並行処理と障害分離の強みが挙げられている。監督木は、複数のプロセスを親子関係で管理し、失敗した処理だけを再起動できる仕組みだ。複数のエージェント作業を同時に走らせるSymphonyでは、ひとつの失敗が全体を止めない構造が求められる。
Codexは仕様検証のため、TypeScript、Go、Rust、Java、Pythonでも実装を試した。複数言語で同じ仕様を実装すると、曖昧な表現や言語依存の前提が見つかりやすくなる。OpenAIはこの検証を通じて仕様の曖昧性を特定し、設計を単純化したとしている。エージェントが仕様を読み、別言語で再実装し、その結果から仕様を磨く流れは、開発プロセスそのものにAIを組み込む実験でもある。
コミュニティ側でも、Claude Code向けにSymphonyを移植した事例がDEV Communityで報告されている。この動きは、Symphonyが特定のモデルを呼び出すツールというより、エージェント作業を束ねる共通形式として受け止められていることを示す。OpenAI自身はSymphonyをスタンドアロン製品としてメンテナンスするのではなく、リファレンス実装として扱うと説明している。仕様の価値は、単一アプリの完成度よりも、他のエージェント基盤が同じ作業モデルを採用できるかに左右される。
PR増加の成果は、レビュー体制の限界も同時に押し広げる
OpenAIは「内部チームでPR数が500%増加した」と発表したが、ベースラインのPR数も測定期間も対象チームの規模も公開していない。数字は数学的には6倍の増加を意味し、Symphonyの効果を示す最も引用される根拠になっているが、外部から検証できる材料は限られる。内部実験の結果であることを前提に読む必要がある。
The Decoderは、「生成は無料で拡張できるが、検証、つまり人間のレビューはそうではない」と指摘した。この見方に立てば、PR数が6倍になるほど、レビュー待ち、設計確認、セキュリティ確認が次の制約になる。InfoWorldも、大規模な企業導入にはセキュリティ方針、監査証跡、レガシーツールチェーン統合、所有権の明確化、変更追跡、職務分離への対応が必要だと分析している。Symphonyは生成量を増やす仕組みであると同時に、組織がレビュー工程を再設計する圧力を強める。
OpenAIの動きは、AIコーディングの競争軸がモデル性能から運用設計へ広がったことを示している。Codexがコードを書くだけなら、評価対象は補完精度やテスト通過率に偏る。Symphonyのような仕様が普及すれば、issue、作業空間、PR、レビュー、監査の連結までがAI開発基盤の評価対象になる。次に問われるのは、エージェントが何件のPRを作れるかではなく、人間のチームがその速度を安全に受け止められるかである。