Linearのチケットが勝手にPRになる — OpenAIが公開した「Symphony」の仕組み

タスク管理ツールにチケットを立てると、AIが勝手にコードを書いてPRを出す。しかも落ちたらリトライし、新しいチケットが来たら即座に拾う。

4月27日、OpenAIがオープンソースで公開したSymphonyは、まさにその「全自動開発パイプライン」を実現するためのオーケストレーション仕様だ。GitHub上で公開からわずか4日で18,000スターを超えた。

「人間がボトルネック」という発想

Symphonyの出発点は、OpenAI社内で実際に起きた問題だったという。Codexエージェント自体は優秀だが、タスクの割り当て・監視・リトライを人間が手動でやっている限り、エージェントの処理能力に対して人間の管理能力が追いつかない。

解決策はシンプルだった。プロジェクト管理ボードそのものを「コントロールプレーン」にしてしまう。Linearのボードを常時監視し、アクティブなタスクごとにエージェントを自動起動する。エージェントがクラッシュしたら再起動し、新しいタスクが追加されたら即座にピックアップする。

OpenAI社内の一部チームでは、導入後3週間でマージされたPR件数が500%増加したと報告されている。

技術的にはどうなっているのか

Symphonyの中身は、仕様書（SPEC.md）とElixirで書かれたリファレンス実装の2つで構成される。Apache 2.0ライセンスだ。

動作の流れはこうなる。

1. Symphonyがタスクボード（現時点ではLinearに対応）を常時ポーリング
2. 未着手のタスクを検知すると、Codexエージェントを隔離環境で起動
3. エージェントがコードを書き、テストを実行し、CIの結果やコードレビューのフィードバックを検証アーティファクトとして記録
4. 問題なければPRを自動作成。人間はレビューしてマージするだけ

リファレンス実装にElixirが採用されたのは、並行性の高さが理由だろう。複数のエージェントを同時に走らせ、それぞれの状態を独立して管理するには、Erlang VM上のプロセスモデルが理にかなっている。

ただし仕様自体は言語非依存で、SPEC.mdに沿って自前実装を作ることもできる。

v1.1.0でCodex以外のエージェントにも対応

注目すべきは、v1.1.0で追加されたKata CLIのサポートだ。Kata CLI（pi-coding-agentベース）を代替ランタイムとして接続できるようになったことで、Claude CodeやGeminiなど他社のモデルもSymphonyの枠組みで動かせるようになった。

OpenAI製なのにモデル非依存のオーケストレーターとして設計されている点は、正直意外だった。囲い込みではなく仕様のオープン化で主導権を取りにいく戦略に見える。

「ハーネスエンジニアリング」という前提条件

Symphonyには一つ大きな条件がある。リポジトリが「ハーネスエンジニアリング」に対応していなければ、まともに動かない。

ハーネスエンジニアリングとは、エージェントが自律的に作業できるようリポジトリを整備する設計手法のことだ。具体的には、自己完結型のテストスイート、モジュラーなアーキテクチャ、エージェントが自分の作業を自動検証できるガードレールなどが必要になる。

つまり、テストが充実していない既存リポジトリにSymphonyを入れても、エージェントが壊れたコードをPRし続けるだけだ。この点は公式も「エンジニアリングプレビュー。信頼できる環境でのテスト向け」と明記している。

500%増加の数字、額面通りに受け取れるか

PR件数500%増加というのはインパクトのある数字だが、これはOpenAI社内の特定チームでの結果だ。OpenAIのモノレポは、タスクのスコープが明確でテストが充実しているからこそ、エージェントが正確に動ける環境が整っている。

テストカバレッジの低いレガシーコードベースや、タスクの粒度が粗いプロジェクトで同じ結果が出るかは別問題だろう。導入を検討するなら、まずリポジトリ側の整備から始める必要がある。

Oh My codeXとの違い

2日前に記事にしたOh My codeX（OmX）もCodex CLIのオーケストレーションツールだが、アプローチが異なる。OmXはCodex CLIを「チーム」として拡張するコミュニティ主導のツールで、36のスキルやMCP統合を足す形。一方Symphonyは、プロジェクト管理ツールとの統合を仕様レベルで定義するOpenAI公式の上位レイヤーだ。

併用も可能だが、思想としてはSymphonyが「チケットからPRまでの自動化」、OmXが「個別タスクの実行能力の拡張」という住み分けになる。

何が変わるのか

Symphonyが示しているのは、AIコーディングの次のフェーズだ。「人間がプロンプトを書いてエージェントに指示する」段階から、「人間はタスクをボードに書くだけで、あとはシステムが回る」段階への移行。

実現可能性が高いのは、まずマイクロサービスの定型的なエンドポイント追加や、テストの自動生成、依存関係のアップデートといった「スコープが明確で、正解が検証可能な」タスクだろう。

もう少し先の話をすれば、LinearのチケットにデザインのFigmaリンクを貼っておくだけでフロントエンドの実装PRが上がってくる世界も、技術的にはそこまで遠くない。ただしそこには、デザイン→コードの翻訳精度と、「どこまでの品質を自動で担保できるか」という壁がまだ残っている。

現時点ではエンジニアリングプレビューだが、仕様がオープンなだけに、Linear以外のツール（Jira、Asana、GitHub Projects）への対応や、Codex以外のエージェントランタイムの統合が進めば、チーム開発のあり方が根本的に変わる可能性がある。少なくとも、プロジェクト管理ツールの選定基準に「Symphonyとの互換性」が加わる日は来るかもしれない。