何が変わったか

これまで Codex を含む AI コーディングエージェントは、開発者が複数セッションを並行で立ち上げてタスクを手で割り振り、各セッションの進捗を追いかけるスタイルで運用されていた。OpenAI 内部でも 3〜5 セッション以上の同時運用は人間の注意切り替えコストで生産性が崩れていたという。

OpenAI は 5 月 4 日、Linear などのタスクトラッカーを Codex エージェントの司令塔に変えるオープンソース仕様「Symphony」をリファレンス実装つきで公開した。各オープンチケットが専用の Codex エージェントとワークスペースを獲得し、完了するまで自走する。タスクボードがそのまま「仕事を払い出す場所」になり、人間はマージ前のレビューに専念する設計だ。

社会にどんな影響があるか

ソフトウェア開発のボトルネックは「モデルの能力」ではなく「人間の注意」だと OpenAI が公式に再定義したことで、AI コーディング運用の設計原理が「supervised parallel sessions」から「ticket-driven autonomous agents」に書き換わる。OpenAI 内部チームでは導入後 3 週間でマージ済み PR 数が 6 倍に跳ね、Linear 創業者 Karri Saarinen も同サービス上のワークスペース新設が急増したと報告している。

一方で副作用として、エージェントが自発的に副次チケットを生成し勝手に進めることで、組織が把握できない開発項目とコード変更が増殖するリスクがある。曖昧な仕様や判断を要するタスクは依然として人間の対話的な Codex セッションで扱う必要があり、「Symphony 化していい範囲」と「人間直結を残す範囲」の線引きが各組織の運用ガバナンスに突き返される。

俺にどんな影響があるか

PRES のレンタル DX 推進室サービスでも、現場業務の自動化対象を「人間が常時注意を割く部分」として再定義し直す価値がある。Symphony が示したのは、「AI に何ができるか」を設計するより、「人間の注意がどの工程で律速になっているか」を可視化してそこをチケット化するという、業務プロセス側の再設計が AI 導入 ROI を決めるという構造命題だ。

ニュースの詳細

Symphony は Linear をステートマシンとして使い、チケットが「Todo」「In Progress」「Review」「Merging」の状態を遷移する。システムがボードを監視し、すべてのアクティブチケットにエージェントを割り当て、エージェントがクラッシュ・停滞すれば再起動する。アンブロックのチケットだけが拾われるため、依存関係を持つタスクツリーを並行実行できる。React アップグレードのような大型タスクは、上流の Vite 移行が完了して初めて起動する。

エージェントは作業中に発見した副次的問題 (パフォーマンス課題・リファクタリング機会など) を自分でチケットとして登録する。プロダクトマネージャーやデザイナーが直接機能要望を投げ、コードチェックアウトなしにビデオウォークスルー付きのレビューパッケージを受け取れる運用も可能だ。

リポジトリ中身の本体は SPEC.md という Markdown ファイル 1 本で、課題と望ましい解を記述する。リファレンス実装は Elixir で書かれ、Codex がワンショットで生成した。同じ仕様を TypeScript・Go・Rust・Java・Python でも実装してストレステストしている。OpenAI は Symphony をスタンドアロン製品として維持する予定はなく、リファレンス位置づけ。コミュニティはすでに Anthropic の Claude Code + GitHub Issues 用フォークを公開している。