記事のサマリー（TL;DR）
- OpenAI が Codex 向けエージェントオーケストレーター「Symphony」を OSS として公開。コアは SPEC.md 1ファイル
- Linear などのイシュートラッカーをコントロールプレーンに変え、一部チームで最初の3週間にマージ済みPR件数が500%増加
- リファレンス実装は Elixir で記述。TypeScript / Go / Rust / Java / Python でも Codex が1発で実装に成功
国内 AI エージェント活用企業・開発チームが注目すべき点
Symphony の本質は「人間が Codex セッションを管理する」から「イシュートラッカーがエージェントを管理する」への視点転換です。日本国内でも Linear や Jira、Backlog などのプロジェクト管理ツールを既に運用しているチームは多く、Symphony の SPEC.md をベースに自社のイシュートラッカーと Codex App Server を接続するだけで、類似の自律エージェント基盤を構築できます。
特に注目すべきは、WORKFLOW.md にチームの開発プロセスを文書化し、それをエージェントが従うという設計思想です。「暗黙知だったワークフロー」を明文化する副次効果があるため、日本のエンジニアチームが慣れ親しんでいる「ドキュメント整備」の延長線上として導入しやすい構造と言えます。
また、kintone や Salesforce を Rails で UI 補完している構成であっても、Codex App Server の JSON-RPC API を通じてエージェントをプログラム制御できるため、業務 SaaS のバックエンド改修タスクをイシュートラッカー経由で自動化する用途にも応用余地があります。
詳細
インタラクティブな Coding Agent の限界
6か月前、OpenAI のあるチームが社内生産性ツールを構築する際に下した決断は「すべてのコードを Codex が生成する」というものでした。この取り組みの詳細は「harness engineering」についての前回のブログ記事に記録されています。
アーキテクチャ面では成功しましたが、次のボトルネックが浮上しました。コンテキストスイッチです。
エンジニアは複数の Codex セッションを並行して開き、タスクを割り当て、出力をレビューし、エージェントを誘導するというサイクルを繰り返していました。実際には、一人のエンジニアが快適に管理できるのは3〜5セッションが限界で、それを超えると生産性が低下しました。どのセッションが何をしているか忘れ、ターミナルを行き来してエージェントを軌道修正し、途中で止まった長時間タスクのデバッグに追われるという状況です。
エージェント自体は速い。しかしボトルネックは 人間の注意力 でした。非常に優秀なジュニアエンジニアのチームを作り上げたのに、人間のエンジニアをマイクロマネジメント担当者にしてしまっていたのです。このままではスケールしないと判断しました。
視点の転換
チームが気づいたのは「最適化する対象を間違えていた」ということです。コーディングセッションやマージ済みPRを中心に考えていましたが、それらは手段に過ぎません。ソフトウェア開発のワークフローは本来、イシュー・タスク・チケット・マイルストーンという 成果物 を軸に構成されています。
そこで生まれた問いが「エージェントを直接監視するのをやめて、タスクトラッカーから仕事を引き取らせたらどうなるか」でした。この発想が Symphony の原点です。
イシュートラッカーをエージェントオーケストレーターに変える
Symphony のコアコンセプトはシンプルです。「オープンなタスクはすべてエージェントが拾い上げて完了させる」。複数タブで Codex セッションを管理する代わりに、イシュートラッカーをコントロールプレーンにします。
実際の運用例を挙げると、コードベース・Slack・Notion を分析して実装計画を作成するようエージェントにタスクを投げると、エージェントがタスクのツリーを生成し、作業をステージに分割してタスク間の依存関係を定義します。
ブロックされていないタスクのみ実行が始まるため、DAG（有向非巡回グラフ） として自然かつ並列に展開されます。例えば「React のアップグレードは Vite への移行が完了してから」とブロック設定すれば、エージェントは Vite 移行後にのみ React のアップグレードを開始しました。
エージェントは自発的に作業を生み出すこともあります。実装やレビュー中に現在のタスクのスコープ外の改善点（パフォーマンス問題・リファクタリング機会・より良いアーキテクチャなど）に気づいた場合、新しいイシューとして登録します。そのフォローアップタスクも多くはエージェントが拾い上げます。
devbox 上でオーケストレーターが24時間稼働しているため、どこからでもタスクを追加すれば必ずエージェントが拾います。実際にチームのあるエンジニアは、山小屋の不安定な Wi-Fi 環境で Linear のスマートフォンアプリから3件の重要な変更をコミットしました。
500% 増という成果と、働き方の変化
Symphony を導入したチームの一部では、最初の3週間でマージ済みPR件数が500%増加しました。また Symphony のリリース時には、Linear の共同創業者 Karri Saarinen 氏がワークスペース作成数の急増を自身のアカウントでハイライトするほどの反響がありました。
しかし数字以上に大きな変化は「仕事に対する思考コストの低下」です。エージェントを監視する必要がなくなった分、エンジニアのコスト感覚が変わりました。アイデアを試す・リファクタリングを探索する・仮説を検証するといった投機的なタスクを気軽に発行し、有望な結果だけを残す、という行動が自然に生まれました。
プロダクトマネージャーやデザイナーが直接 Symphony にフィーチャーリクエストを投げられるようになったことも大きな変化です。リポジトリをチェックアウトしたり Codex セッションを管理したりする必要がなく、機能を記述するだけで、実際の製品上で動作する機能のビデオウォークスルーを含む「レビューパケット」が返ってきます。
大規模なモノリポ環境では、CI の監視・リベース・コンフリクト解消・不安定なチェックの再試行・パイプラインへのプッシュを Symphony が担います。チケットが「マージ」ステータスに達する頃には、人間が付き添わなくてもメインブランチに入る確信が持てます。
課題とトレードオフ
インタラクティブなエージェント操作からチケットレベルの作業割り当てに移行した結果、作業中のエージェントへの細かい軌道修正は難しくなりました。エージェントが的外れな成果物を出すこともありましたが、それ自体がシステムのギャップを明らかにする有益な情報でした。
失敗が起きた際は結果を手動で修正するのではなく、次回成功できるよう ガードレールとスキルを追加するアプローチを取りました。これにより、エンドツーエンドテストの実行・Chrome DevTools を通じたアプリ操作・QA スモークテスト管理など、新しい能力がハーネスに追加されていきました。
すべてのタスクが Symphony スタイルに合うわけではありません。曖昧な問題や強い判断力と専門知識が求められる作業は、引き続きエンジニアが Codex セッションをインタラクティブに操作する形が適しています。実際、そういったタスクはエンジニアにとって最も興味深く楽しい作業でもあります。
もう一つの重要な学びは「エージェントを状態機械の硬直したノードとして扱うのは機能しない」という点です。モデルはより賢くなり、想定より大きな問題を解けるようになっています。Codex は複数 PR の作成・レビューフィードバックの読み取りと対応も十分に行えます。そのため、厳密な状態遷移ではなく 目標（Objective）を与える スタイルに移行しました。優秀なマネージャーが部下に目標を設定するのと同じ発想です。
Symphony で Symphony を構築する
Symphony リポジトリを開くと、コアは SPEC.md という1つのファイルであることに気づきます。複雑な監視システムを構築するのではなく、問題と意図したソリューションを定義して、エージェントに高レベルの方向性を与える設計です。
リファレンス実装は Elixir で書かれています。「コードが事実上タダになった世界では、言語を強みで選べる」というチームの哲学から、並行処理に優れた Elixir が選ばれました。とはいえコアのアイデアはシンプルな Markdown ドキュメントで表現できるため、好みのコーディングエージェントに SPEC.md を読み込ませて独自バージョンを実装させることが推奨されています。
Symphony の最初のバージョンは、tmux 上で動く Codex セッションが Linear をポーリングしてサブエージェントを生成する仕組みでした。その後、エージェントフレンドリーに設計された本プロジェクトのメインリポジトリに移行しました。
仕様の精緻化にあたっては、TypeScript・Go・Rust・Java・Python など複数の言語で Codex に実装させ、その結果から仕様の曖昧さを特定してシステムを簡素化しました。すべての言語で成功しています。
Codex App Server との組み合わせ
Symphony の構築にあたり、Codex App Server（Codex のヘッドレスモード）が大きな役割を果たしました。このモードでは、スレッドの開始やターンへの反応といった操作を、文書化された JSON-RPC API 経由でプログラム的に行えます。CLI や tmux セッションを通じた操作よりも利便性とスケーラビリティに優れています。
例えば、Linear アクセストークンをサブエージェントに露出させないために、ダイナミックツールコールを使って Linear の GraphQL 関数を実行できる仕組みを用意しています。MCP に依存せず、コンテナにアクセストークンを渡す必要もありません。
今後の展望
Symphony は意図的にミニマルなオーケストレーション層として設計されています。スタンドアロン製品としてメンテナンスする予定はなく、リファレンス実装として位置づけられています。
自分のプロジェクト管理ツールや開発ワークフローに合わせて Symphony SPEC を読み込ませ、独自バージョンをビルドすることが OpenAI の推奨アプローチです。コーディングエージェントが推論・指示追随においてさらに進化するにつれ、ボトルネックは「コードを書くこと」から「エージェント作業を管理すること」へとシフトすると OpenAI は見ています。そして今、そのシステムを実験するためのハードルは驚くほど低くなっています。