AI-Papers
- LinearやGitHub Issuesをコーディングエージェントのコントロールプレーンに変換するオーケストレーター「Symphony」を2026年4月27日にOSSとして公開
- 各タスクに専用エージェントを割り当てて並行・継続稼働させ、一部チームではマージ済みPRが500%増加
- CI結果・PRリンク・ウォークスルー動画をセットにした「作業証明」で、人間は少ない手間で成果物の品質を判断できる
コンテキストスイッチングという壁
2026年4月27日、OpenAIのエンジニアリングチーム（Alex Kotliarskyi、Victor Zhu、Zach Brock）はコーディングエージェント向けオーケストレーション仕様「Symphony」をGitHubでオープンソース公開した。
Symphonyが生まれた背景には、開発現場に根深く残る課題がある。AIコーディングエージェントが普及しつつある今も、エンジニアはSlack通知、Pull Requestレビュー、イシュートラッカーの確認などを往復し続けており、作業の「文脈の途切れ」が生産性の天井を形成していた。OpenAIのチームは自社プロジェクトを人間が書くコードなしで構築する試みを通じてこの問題を直視し、Symphonyを設計した。
Symphonyの仕組み
Symphonyの中核は「イシュートラッカーをエージェントのコントロールプレーンとして扱う」という設計思想だ。LinearやGitHub Issuesに登録されたすべてのオープンタスクに対し、Symphonyが自動的に独立したコーディングエージェントを割り当てる。エージェントはそれぞれ隔離されたサンドボックス環境で並行稼働し、人間の介入を待たずにタスクを処理し続ける。
エージェントが作業を終えると、CIの通過結果、生成されたプルリクエストへのリンク、そして変更内容を説明するウォークスルー動画を「作業証明（Proof of Work）」としてまとめてレビュアーに提示する。ウォークスルー動画はレビュアーが「何が変わったか」を数十秒で把握できるため、PR差分だけを読む従来のレビューと比べてレビュー判断のコストが大幅に下がる。
500%増という数値の意味
OpenAIは一部チームでSymphonyを導入した結果、マージ済みプルリクエスト数が500%増加したと報告している。この数値は単純なコード量の増加ではなく、エージェントが並行して複数タスクを処理することでレビュー待ちのキューが常に満たされた状態になり、人間のレビュー能力が律速になるほどスループットが上がったことを示している。
従来はエンジニア1人が順番にタスクに取り組む直列構造だったのに対し、Symphonyは「N個のタスクがN個のエージェントで同時進行し、人間はレビューに専念する」並列構造へと開発フローを転換する。OpenAI Agents SDKも長時間タスク対応を強化しており、Symphonyはその上位レイヤーとして機能する位置づけだ。
導入に必要な前提条件
Symphonyを有効活用するには、エージェントフレンドリーなリポジトリ構造の整備が欠かせない。具体的には、エージェントが自律的に変更の正当性を確認できるよう、自動テストとCI/CDパイプラインの充実が前提となる。テストカバレッジが低い状態でエージェントを大量稼働させると、誤った変更がレビューを通過するリスクが高まるため、導入前の自動テスト整備が強く推奨される。
OpenAIはリポジトリをエージェント対応にするための設計指針についても以前のブログ記事「harness engineering」で詳述しており、SymphonyはそのノウハウをOSSとして誰でも再現できる形に落とし込んだものといえる。
開発自動化基盤としての意義
Symphonyが示すのは、AIエージェントを「使うツール」から「常時稼働するチームメンバー」として扱う開発文化の転換だ。イシュートラッカーという多くのチームがすでに運用するインフラをコントロールプレーンとして再利用する設計は、新たなシステムの導入障壁を下げる。OSSとして即利用可能なため、企業規模を問わず試験導入できる点も普及を後押しするだろう。
