CodexをLinear連携で全自動化するSymphonyの仕組み

Linearに積まれたissueが増えるたびにCodexエージェントが自動で動き出す開発環境が、OSSとして手に入るようになりました。

この記事でわかること：

Symphonyが解決する「エージェント監視コスト」の問題
Orchestratorを中心とした主要コンポーネントの構成
自分のリポジトリへの導入手順2パターン

Symphonyとは

OpenAIが2026年4月に公開したオープンソースのエージェントオーケストレーターです。Linearのissueトラッカーを常時監視し、対象状態のissueひとつひとつにCodexエージェントのセッションを自動で割り当てます。エンジニアがやるのは、エージェントを起動・監視することではなく、issueという「仕事」を管理することだけです。

コーディングエージェントの「監視疲れ」を解消する

Codexのようなコーディングエージェントが普及するにつれ、「エージェントを起動して結果を確認する」という作業が新たな負担になっています。タスクが増えるほど、何かを実行させるたびに人間が付き添う必要があります。

Symphonyはこの問題を「自動ループ化」で解決します。issueがアクティブな状態にある限りエージェントは動き続け、失敗した場合は指数バックオフでリトライします。エージェントがクラッシュしても、Symphonyが再起動します。エンジニアが関与するのは、エージェントが「Human Review」状態に遷移してきたときだけです。

OpenAIの社内チームでは、導入から3週間でマージされたPRの数が500%増加したと報告されています。

主なコンポーネント

Symphonyは複数の役割が分担された構成になっています。

Orchestrator：中核となる調整機能。ポーリングループを管理し、どのissueにエージェントを割り当てるか・リトライするか・停止するかを決定します
Issue Tracker Client：LinearのAPIを叩いてissueを取得し、内部の正規化モデルに変換します
Workspace Manager：issueごとに独立したワークスペースディレクトリを作成・管理します
Agent Runner：ワークスペースを準備し、WORKFLOW.mdをもとにプロンプトを生成してCodexを起動します
Workflow Loader：リポジトリ内のWORKFLOW.mdからエージェントへの指示と設定を読み込みます

issueの状態はOrchestratorがLinearから毎回取得し直します。PMがissueを「Cancelled」に移したり、開発者が手動でクローズした場合、エージェントはすぐに停止します。外部からの状態変更がリアルタイムに反映される設計です。

WORKFLOW.mdはリポジトリ内に置くファイルで、エージェントへのプロンプトと実行設定を記述します。チームのルールをコードと同じリポジトリでバージョン管理できるため、エージェントへの指示が属人化しません。

導入手順

Symphonyの導入方法は2パターンあります。

パターン1：自分でSymphonyを実装する

Symphonyの仕様はSPEC.mdとして公開されており、任意の言語で実装できます。好みのコーディングエージェントに以下のように依頼するだけで、自分のリポジトリ向けにカスタムした実装を生成できます。

Implement Symphony according to the following spec:
https://github.com/openai/symphony/blob/main/SPEC.md

パターン2：公式のElixir実装を使う

Elixir/OTPベースのリファレンス実装が同リポジトリに含まれています。elixir/README.mdに従ってセットアップするか、コーディングエージェントにelixir/README.mdを読ませてセットアップを代行させることもできます。

前提として、LinearのAPIキーとCodexのApp Serverモードが必要です。OpenAIは「ハーネスエンジニアリング」（リポジトリ内にCI・テスト・Lintなどの品質チェックを整備するアプローチ）を事前に導入しておくことを推奨しています。エージェントが自律的に動くための土台として機能します。

使う前に知っておきたいこと

Symphonyは現時点で信頼された環境向けのエンジニアリングプレビューと位置づけられています。強力なサンドボックス制御は仕様の外にあり、実装者が設計する必要があります。

Codexへのトークン消費が大きい点にも注意が必要です。あるユーザーはLinearのissue 30件を1週間でSymphonyで処理した結果、週次のCodex利用上限に近づいたと報告しています（参考）。タスク数に応じてコストが線形に増加する傾向があります。

OpenAIはSymphonyをスタンドアロン製品として維持する予定はなく、あくまでリファレンス実装として公開しています。チームの用途に合わせてフォークし、独自に運用することが前提です。

まとめ

「エージェントを使う」のではなく「エージェントを動かす仕事そのものを消す」という発想は、今後のソフトウェア開発チームの構成を変える可能性があります。SymphonyがSPEC.mdとして言語非依存で仕様を公開したことで、同様の仕組みが他のツールやプラットフォームへ波及するきっかけになるかもしれません。