OpenAI Symphonyとは？「仕事を丸投げ」する自律実装ランの仕組みと導入ポイント

はじめに

ソフトウェア開発の現場では、課題管理ツールに登録されたイシューをひとつずつ手作業で実装し、プルリクエストを出す流れが一般的です。OpenAIが公開したSymphonyは、この一連の作業をデーモン型の自動化サービスとして回し続ける仕組みを提供します。

本記事では、Symphonyがどのような課題を解決し、どんなコンポーネントで動いているのかを整理します。導入時の設定やセキュリティ面で押さえるべきポイントまで、順を追って確認できます。

OpenAI Symphonyとは何か

OpenAI Symphonyは、課題管理ツールから作業を読み取り、イシューごとに隔離されたワークスペースを作成し、その中でコーディングエージェントを実行する長時間稼働の自動化サービスです。仕様書では、Symphonyは「課題管理ツールから継続的に作業を読み取り、各イシューに隔離されたワークスペースを作成し、そのワークスペース内でコーディングエージェントのセッションを実行する」と定義されています（参照*1）。

Symphonyの動作はElixir実装のドキュメントでより具体化されています。Linearから候補となる作業をポーリングし、イシューごとに隔離ワークスペースを作成し、そのワークスペース内でCodexをアプリサーバーモード（App Server mode）で起動し、ワークフロープロンプトを送信し、作業が完了するまでCodexを動かし続けます（参照*2）。つまり、人がイシューを確認してからコードを書き、プルリクエストを出すまでの工程を、Symphonyが一括で引き受ける形になります。

Symphonyが解決する4つの課題

Symphonyの仕様書は、このサービスが解決する運用上の問題を4つ挙げています。1つ目は、イシューの実装を手動スクリプトではなく繰り返し可能なデーモンワークフローに変える点です。2つ目は、エージェントの実行をイシューごとのワークスペースに隔離し、コマンドが専用ディレクトリ内でしか走らないようにする点です。

3つ目は、ワークフローの方針をリポジトリ内のWORKFLOW.mdに置くことで、エージェントへのプロンプトや実行設定をコードと一緒にバージョン管理できるようにする点です。4つ目は、複数のエージェントが同時に動くときに運用やデバッグを行えるだけの可観測性を提供する点です（参照*1）。

これら4つは、手作業の属人化、実行環境の汚染、設定の散逸、障害時のブラックボックス化という開発現場でありがちな困りごとにそれぞれ対応しています。自分たちのチームでどの問題が深刻かを確認すると、Symphonyの導入効果を見積もりやすくなります。

「仕事を丸投げ」できる理由——スケジューラ兼ランナーという位置づけ

Symphonyが「仕事を丸投げ」できるのは、単なるエージェント実行ツールではなく、スケジューラとランナーの両方の役割を1つのサービスで担うからです。仕様書では、Symphonyはスケジューラ/ランナーであり、課題管理ツールの読み取り役でもあるとされ、オーケストレーターがポーリングの周期を管理し、どのイシューをディスパッチ、リトライ、停止、またはリリースするかを決定します（参照*1）。

O’Reillyの記事では、オーケストレータは高レベルの目標を設定し、タスクを定義し、複数の自律コーディングエージェントが独立して実装の詳細を実行できるようにすると整理されています（参照*3）。

Symphonyではこの考え方を具体化し、イシューの取得からワークスペース生成、エージェント起動、結果の追跡までを1プロセスで回しています。開発者はイシューを起票するだけで、あとはSymphonyが完了まで面倒を見る構造です。

Symphonyの全体像と主要コンポーネント

Symphonyは複数のコンポーネントが協調して動きます。仕様書では、Workflow Loader、Config Layer、Issue Tracker Client、Orchestrator、Workspace Manager、Agent Runnerという6つの要素が定義されています（参照*1）。ここでは特に重要な役割を持つものを取り上げて、それぞれの働きを確認します。

ワークフローローダーとWORKFLOW.mdの役割

Workflow Loaderは、リポジトリに置かれたWORKFLOW.mdを読み込み、YAMLフロントマターとプロンプト本文をパースして、設定とプロンプトテンプレートの組み合わせを返すコンポーネントです。Config Layerはその設定値に型付きのゲッターを提供し、既定値の適用や環境変数の間接参照、バリデーションを行います（参照*1）。

WORKFLOW.mdはYAMLフロントマター付きのMarkdownファイルです。仕様書では、WORKFLOW.mdはプロンプト、実行設定、フック、課題管理ツールの選択と設定を記述でき、サービス固有の外部設定を必要としない自己完結型であるべきだと述べています（参照*1）。

つまり、チームがSymphonyの振る舞いを変えたいときは、WORKFLOW.mdを編集してコミットするだけで済みます。設定とプロンプトがリポジトリ内に一元化されるため、どのバージョンのコードにどの設定が適用されていたかを履歴から追えます。

オーケストレーターによるポーリング・ディスパッチ・リトライ

Orchestratorは、Symphonyの心臓部にあたるコンポーネントです。仕様書では、Orchestratorはポーリング周期を管理し、インメモリのランタイム状態を保持し、どのイシューをディスパッチ、リトライ、停止、またはリリースするかを判断するとされています。さらにセッションのメトリクスやリトライキューの状態も追跡します（参照*1）。

ポーリングの1ティック内で行われる処理は、仕様書に順序が定義されています。実行中イシューのリコンシリエーション、ディスパッチ前のバリデーション、課題管理ツールからの候補イシュー取得、優先度順のソート、スロットが残っている限り対象イシューのディスパッチ、状態変化の通知という流れです（参照*1）。

この一連の流れが定期的に繰り返されることで、新しいイシューが投入されても自動的にキューに入り、空きスロットがあれば即座にエージェントが起動します。開発者はOrchestratorの処理順を把握しておくと、障害時にどの段階で止まったのかを特定しやすくなります。

ワークスペースマネージャーとエージェントランナーの連携

Workspace Managerは、イシューの識別子をワークスペースのパスにマッピングし、ディレクトリの存在確認やライフサイクルフックの実行、終了したイシューのワークスペース掃除を担当します。Agent Runnerは、ワークスペースを作成し、イシューとワークフローテンプレートからプロンプトを組み立て、コーディングエージェントのApp Serverクライアントを起動します。エージェントからの更新情報はOrchestratorへストリーミングされます（参照*1）。

Workspace ManagerとAgent Runnerはそれぞれ「場所を用意する」「中身を実行する」と役割が分かれています。Workspace Managerがディレクトリを確保してフックを走らせた後に、Agent Runnerがそのディレクトリ内でエージェントを立ち上げるという手順です。

この分離により、ワークスペースの準備に失敗した場合はAgent Runnerが起動されず、環境の不整合を防げます。導入する際はWorkspace Managerのフック設定を先に固めて、Agent Runnerの動作確認へ進む順番で検証してください。

自律実装ランの仕組み——イシューからPRができるまで

Symphonyがイシューを受け取ってからプルリクエストが作られるまで、内部では複数のステップが自動で進みます。ここでは仕様書に基づいて、その流れを3つの段階に分けて見ていきます。

イシュー取得からワークスペース生成までの流れ

Orchestratorはティックごとにまず既存の実行中イシューをリコンシリエーションし、次にディスパッチ前のバリデーションを行います。その後、課題管理ツールからアクティブ状態の候補イシューを取得し、ディスパッチ優先度でソートし、空きスロットがある限りイシューを順にディスパッチします（参照*1）。

ディスパッチされたイシューに対して、Workspace Managerがイシュー識別子に基づいた専用ディレクトリを作成します。このディレクトリの中でライフサイクルフックが走り、たとえばリポジトリのクローンなどの前処理が実行されます。

ワークスペースが正常に作成された段階で、Agent Runnerへ制御が渡ります。候補イシューの取得からワークスペース生成まではOrchestratorとWorkspace Managerの範囲であり、この区間で問題が起きた場合はエージェントは一切起動しません。

プロンプト構築とコーディングエージェントの実行

Agent Runnerは、WORKFLOW.mdのMarkdown本文をイシューごとのプロンプトテンプレートとして利用します。仕様書では、テンプレートの描画にLiquid互換のセマンティクスを用い、未知の変数やフィルタが含まれる場合は描画を失敗させることが求められています。テンプレートに渡される入力変数には、ラベルやブロッカーを含むイシューオブジェクトと、リトライ回数を示すattempt値があります（参照*1）。

テンプレートがエラーなく描画されると、そのプロンプトがCodexのアプリサーバーモード（App Server mode）へ送信されます。Codexはワークスペース内でコードの生成や変更を行い、作業が完了するまでセッションが続きます。

attempt変数を使えば、リトライ時に「前回の失敗原因を踏まえて再実行してほしい」といった指示をプロンプトに織り込めます。テンプレートの設計が実装の品質を左右するため、まずは小さなイシューで試してプロンプトの精度を確認してください。

リコンシリエーションとリトライによる自動復旧

Orchestratorは各ティックの冒頭で、実行中イシューの状態を課題管理ツールから再取得するリコンシリエーションを行います。仕様書では、課題管理ツール側の状態が終了状態であればワーカーを停止してワークスペースを掃除し、まだアクティブであればインメモリのイシュー情報を更新し、どちらにも該当しない場合はワーカーを停止するがワークスペースは残すと定めています（参照*1）。

この仕組みにより、人が課題管理ツール上でイシューをキャンセルすれば、Symphonyは次のティックで自動的にそのエージェントを終了させます。逆にエージェント側がエラーで停止した場合は、リトライキューに入り、バックオフを挟んで再度ディスパッチされます。

リコンシリエーションの頻度はポーリング周期に依存するため、どの程度のタイムラグを許容するかをチームで決めておくことが運用の前提になります。

導入時に押さえるべき設定と判断基準

Symphonyを実際に動かすにはWORKFLOW.mdの記述と、いくつかの実行パラメータの調整が必要です。ここでは設定の最小構成と、チューニングすべき数値を確認します。

WORKFLOW.mdの書き方と最小構成例

Elixir実装のREADMEには、WORKFLOW.mdの具体例が掲載されています。YAMLフロントマターにはtrackerの種類とプロジェクトスラッグ、ワークスペースのルートパスとafter_createフック、エージェントの同時実行数や最大ターン数、Codexの起動コマンドを記述します。Markdown本文がプロンプトテンプレートで、issue.identifier、issue.title、issue.descriptionといった変数を埋め込みます（参照*2）。

WORKFLOW.mdは変更が即座に反映される設計が求められています。仕様書では、ファイルの変更を監視し、変更があればサービスを再起動せずに設定とプロンプトテンプレートを再適用する必要があるとされ、ポーリング周期、同時実行数、アクティブ/終了状態の定義、Codex設定、ワークスペースのパスやフック、将来のランへのプロンプト内容が反映される設計です（参照*1）。

最初はafter_createフックにリポジトリのクローンだけを書き、max_concurrent_agentsを1にして1イシューだけ流すところから始めると安全に動作を確認できます。

同時実行数・リトライ・タイムアウトのチューニング

仕様書では主要な数値パラメータの既定値が定められています。agent.max_concurrent_agentsは既定10で、同時に走るエージェントの上限です。agent.max_turnsは既定20で、1セッション内のターン数を制限します。agent.max_retry_backoff_msは既定300000ミリ秒、つまり5分で、リトライの最大バックオフ間隔です。codex.turn_timeout_msは既定3600000ミリ秒、つまり1時間で、1ターンのタイムアウトです。codex.stall_timeout_msは既定300000ミリ秒、つまり5分で、エージェントが応答しない場合の停止判定時間です（参照*1）。

同時実行数はマシンリソースやAPIレート制限に直結するため、最初は小さめに設定して段階的に引き上げるのが現実的です。turn_timeout_msは複雑なイシューほど大きくする必要がありますが、無制限に伸ばすとリソースを長時間占有するため、イシューの粒度に合わせて調整してください。

セキュリティとハーネス強化の注意点

自律的にコードを書くエージェントを動かす以上、セキュリティの設計は欠かせません。Symphonyの仕様書とElixir実装には、ワークスペースの安全性と承認ポリシーに関する具体的な指針があります。

ワークスペース分離とパス検証の安全設計

仕様書は3つの不変条件を定めています。不変条件1は、コーディングエージェントをイシューごとのワークスペースパス内でのみ実行することです。エージェントのサブプロセスを起動する前に、カレントディレクトリがワークスペースパスと一致するか検証します。不変条件2は、ワークスペースパスがワークスペースルートの内部にとどまることです。両方のパスを絶対パスに正規化し、ワークスペースパスのプレフィックスがワークスペースルートであることを要求し、範囲外のパスは拒否します（参照*1）。

不変条件3は、ワークスペースキーのサニタイズです。ディレクトリ名に使える文字はA-Z、a-z、0-9、ピリオド、ハイフン、アンダースコアのみに制限されています（参照*1）。

これらの不変条件は、エージェントがワークスペース外のファイルやシステム領域を操作するリスクを防ぐための仕組みです。導入時には、パストラバーサル攻撃が起きないことをテストケースで確認してください。

承認ポリシーとサンドボックス設定の選択肢

仕様書は、信頼と安全に関する姿勢を実装ごとに明示的に文書化するよう求めています。単一の承認ポリシーやサンドボックス方針、オペレーター確認方針を規定してはおらず、高い信頼を前提とした環境向けの設定もあれば、より厳格な承認やサンドボックスを要求する実装もあり得ると述べています（参照*1）。

Elixir実装では、ポリシーフィールドが省略された場合に安全側に倒す既定値が適用されます。codex.approval_policyはサンドボックス承認、ルール、MCP確認をすべて拒否する設定が既定です。codex.thread_sandboxはworkspace-writeが既定で、codex.turn_sandbox_policyはイシューごとのワークスペースをルートとするworkspaceWriteポリシーが適用されます（参照*2）。

自組織のセキュリティ要件に合わせて、これらのポリシーを明示的に上書きするか、既定値のまま使うかを判断してください。

他のエージェントオーケストレーションとの比較

Symphonyの特徴をつかむには、他のツールとの位置づけの違いを確認するのが早道です。ここでは、関連するツールとの違いと、Symphonyが合うチーム像を整理します。

Codex CLI・Claude Code・Copilotエージェントとの違い

O’Reillyの記事では、指揮者とオーケストレータの違いを次のように区別しています。指揮者はミクロレベルで動作し、1つのエージェントを1つのタスクや狭い問題に導きます。一方、オーケストレータはマクロレベルで動作し、複数のエージェントや多段階のプロジェクトを扱える強力なエージェントのために幅広いタスクと目標を設定します（参照*3）。Symphonyはこの分類でいうオーケストレータに該当します。

Codex CLIは端末でのCodex利用を指し、端末やIDE、課題管理ツールなどあらゆるツール上で出会えるように設計されていると説明されています（参照*4）。Codex CLIが1つの端末で1タスクを扱うのに対し、Symphonyは課題管理ツールと連動して複数イシューを並列に処理する点が大きな違いです。

OpenAIの公開資料では、単一のエージェントでもツールを段階的に追加すれば多くのタスクを処理でき、複雑さの管理や評価、保守がしやすくなると述べられています（参照*5）。Symphonyを使うかどうかは、単一エージェントで足りるのか、複数イシューの並列自動実行が必要なのかという粒度で判断することになります。

Symphony導入が適するチームと適さないケース

Symphonyの強みは、課題管理ツール上のイシューを次々と自動実行する仕組みにあります。あるニュースレターでは、OpenAIのチームが3人のエンジニアで100万行の内部製品を5か月で構築し、エンジニア1人あたり1日平均3.5件のプルリクエストを出すスループットを実現したと報じています。チームが大きくなるほどスループットが向上したとも述べられています（参照*6）。

このように、定型的なイシューが大量に発生し、並列処理で開発速度を上げたいチームにはSymphonyが合います。逆に、イシューの粒度が大きく1件ごとに人間の設計判断が欠かせない場合や、課題管理ツールとの連携が不要な小規模プロジェクトでは、Codex CLIのような単体ツールのほうが軽量に導入できます。

自分たちのチームのイシュー発生量と粒度、そしてセキュリティ要件を棚卸しした上で、Symphonyの同時実行モデルが効果を発揮する領域かどうかを見極めてください。

おわりに

OpenAI Symphonyは、イシューの取得からワークスペース生成、エージェント実行、リコンシリエーションまでを一貫して自動化するサービスです。導入を検討する際は、WORKFLOW.mdによる設定の一元管理、3つの不変条件によるワークスペース分離、承認ポリシーの明示という3つのポイントを軸に評価してみてください。

まずは同時実行数を1に絞った最小構成で小さなイシューを流し、動作を確認するところから始めると、Symphonyの仕組みとチームへの適合度を実感しやすくなります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））