エンジニアリング - ENGINEERING -

OpenAI、Codexエージェントを大量管理する「Symphony」公開　人間の監督負荷を減らしプルリク数500％増

OpenAIは2026年4月27日、コーディングエージェントをオーケストレーションするためのツール「Symphony」をオープンソースで [公開]{target=“_blank”}した。Symphonyは、Linearのようなプロジェクト管理ボードをコーディングエージェントの制御盤として使い、Codexエージェントをチケット単位で継続的に実行する仕組みだ。 同社によると、OpenAIの一部チームでは、Symphonyの導入後にマージされたプルリクエスト数が500％増加したという。Symphonyのソースコードや仕様書は、GitHubで公開されている。 ## Codexエージェントをチケット単位で運用 OpenAIは、Symphonyを「Linearのようなプロジェクト管理ボードを、常時稼働するエージェント・オーケストレーターに変える」仕組みとして説明している。 これまでCodexを使った開発では、エンジニアがWebアプリやCLIで複数のCodexセッションを開き、それぞれに作業を割り当て、出力を確認し、必要に応じて追加の指示を出す必要があった。OpenAIは、こうした運用ではエンジニアの注意力が制約になりやすく、社内でも実用上は3〜5個のセッションを管理するのが限界だったとしている。 Symphonyでは、作業の単位を個別のCodexセッションではなく、Issueやタスクに置く。各Issueに専用のワークスペースを作成し、その中でコーディングエージェントを実行する。これにより、エンジニアはエージェントそのものを細かく監督するのではなく、完了すべき作業を管理する形に近づく。 ## Linearを状態機械として利用、レビューからマージまで管理 Symphonyは、Linear上のチケットステータスを使ってエージェントの作業を管理する。OpenAIはこの仕組みについて、コーディングエージェントがLinearを「状態機械」として使い、人間と並行して作業すると説明している。 タスクが「TODO」「IN PROGRESS」「REWORK」などの状態にある間、エージェントは実装、テスト、改善を進める。一定の成果が出ると、人間にレビューを依頼する。OpenAIの説明では、エージェントが動作する機能の動画ウォークスルーなどを提示し、人間が内容を確認する流れも想定されている。 **■ Linearを状態機械として利用するSymphonyのワークフロー** ![symphony1.jpg] :::small 画像の出典：[OpenAI]{target=“_blank”} ::: 人間が承認すると、エージェントはコンフリクトの解消、CIの通過、変更のマージまでを進める。さらに、作業中に見つけた後続タスクや改善案はBacklogに記録する。これにより、開発者が一つ一つのCodexセッションを開いて確認するのではなく、チケット管理システム上で複数のエージェント作業を追跡できる。 ## 一部チームでプルリクエスト数が500％増加 OpenAIによると、Symphonyを導入した一部チームでは、最初の3週間でマージされたプルリクエスト数が500％増加した。 同社は、Symphonyによって変更を試すコストが下がったとしている。エンジニアは、アイデアの試作、リファクタリングの探索、仮説検証といった作業をチケット化し、エージェントに実行させることができる。結果が有望なものだけをレビューし、採用する運用が可能になる。 OpenAIは、Symphony導入前後でCodexの使い方が変化したことも示している。導入前は、明確なバグ修正や探索的な作業などにCodex webや対話型Codexセッションを使い分けていた。一方、導入後は、明確なバグ修正、小さなバグ、大きめの機能開発など、より広い範囲のタスクにSymphonyを使う構成になっている。 **■ Symphony導入前後におけるCodexエージェントの適用領域の変化** ![before and after symphony.jpg] :::small 画像の出典：[OpenAI]{target=“_blank”} ::: ## GitHubで仕様書と参照実装を公開 Symphonyのソースコードは、OpenAIのGitHubリポジトリで公開されている。READMEでは、Symphonyについて「プロジェクト作業を隔離された自律的な実装ランに変換し、チームがコーディングエージェントを監督するのではなく作業を管理できるようにする」と説明している。ライセンスはApache-2.0。 リポジトリには「Symphony Service Specification」としてSPEC.mdも含まれている。この仕様書では、Symphonyを「コーディングエージェントをオーケストレーションしてプロジェクト作業を進めるサービス」と定義している。 仕様書では、Issue実行を手動スクリプトではなく反復可能なデーモン型ワークフローにすること、Issueごとに独立したワークスペースを作ること、ワークフローの方針をリポジトリ内のWORKFLOW.mdで管理すること、複数のエージェント実行を観測・デバッグできるようにすることなどが目的として挙げられている。 OpenAIは、Elixir/OTPベースの参照実装も公開している。ただし、同実装は評価用のプロトタイプであり、実運用ではSPEC.mdに基づいて堅牢な実装を構築することを推奨している。 ## すべての開発作業に適するわけではない OpenAIは、Symphonyがすべての作業に適しているわけではないとも説明している。チケット単位で作業を割り当てる方式では、対話型セッションのように途中で細かく軌道修正し続けることは難しい。エージェントが的外れな成果物を出すこともあるという。 一方で同社は、こうした失敗をガードレールやスキル、ドキュメントの改善につなげたとしている。たとえば、エンドツーエンドテストの実行、Chrome DevToolsを使ったアプリ操作、QAスモークテスト管理などの機能を追加してきたという。 OpenAIは、強い判断や専門性が必要な曖昧な問題では、今後もエンジニアが対話型Codexセッションを直接使う場面が残るとしている。Symphonyは、コーディングエージェントを単発の補助ツールとしてではなく、チケット管理システムに接続された継続的な開発ワークフローとして扱う試みといえる。 :::box [関連記事：OpenAI、コーディングエージェント「Codex」を刷新 “ほぼすべて”の開発作業を支援へ] ::: :::box [関連記事：OpenAI、コードの脆弱性を発見し修正パッチまで提案するAIエージェント「Codex Security」公開] ::: :::box [関連記事：OpenAI、自然言語でコード編集・実行可能な「Codex CLI」をリリース──ターミナル操作をAIが支援] ::: :::box [関連記事：GitHub、「Agent HQ」を発表──“あらゆるエージェントを同じ画面で”管理へ] ::: :::box [関連記事：Google、AIコーディングアシスタント「Jules」を正式公開──Gemini 2.5 Pro搭載、無料プランから利用可能に] :::