LinearチケットからCodexを自走させるOpenAI製OSS「Symphony」

OpenAIは2026年4月、コーディングエージェントを大量管理するためのOSS「Symphony」を公開しました。GitHubリポジトリは公開直後にスター22,499、フォーク2,095（2026年5月7日時点）まで伸び、Elixir/OTPを採用した参照実装と言語非依存の仕様（SPEC.md）の二段構えという独特な構成が話題になっています。

ただし国内の解説記事はリリースニュースとSPEC翻訳が中心で、「自分のチームに導入すべきか」「Multicaなどの類似OSSと何が違うのか」「Engineering Preview扱いの参照実装にどこまで依存できるのか」という採用判断の論点に正面から答える情報はまだ多くありません。

本記事では、CodexをすでにCLIで業務利用している開発リード・テックリードを想定読者に、Symphonyが何を自動化するのか、SPEC.mdに書かれた8コンポーネント×6レイヤーのアーキテクチャ、Elixir採用の公式理由、そして類似OSS（Multica・Paperclip）との設計思想の違いを整理します。最後に「採用すべきケース／見送るべきケース／様子見すべきケース」をチェックリスト化し、読了後に意思決定の軸を持ち帰れる構成にしています。

なお本記事は公式README・SPEC.mdのドキュメントベースで記述しており、インストール・実行は行っていません。コードブロックはすべて公式の引用であり、引用直後に出典URLを明記します。

SymphonyとはOpenAIが提示する「実装ランの分離」というコンセプト

Symphonyは、OpenAIが2026年4月に公開したコーディングエージェントのオーケストレーション用OSSです。リポジトリは openai/symphony で公開されており、ライセンスはApache-2.0、参照実装の主言語はElixirとなっています。

公式READMEは、Symphonyが解決しようとしている問題を次のように説明しています。

Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.

出典: openai/symphony README

直訳すると「プロジェクトの作業を、隔離された自律的な実装ランに変えることで、コーディングエージェントを監督するのではなく作業そのものを管理できるようにする」となります。ポイントは「supervise coding agents（エージェントを監督する）」と「manage work（作業を管理する）」を対比させていることです。Codex CLIをチャット越しに都度起動して逐次プロンプトを与える運用から、Linearのチケットを「実行キュー」として扱い、エージェントを並行に走らせる運用へ抽象度を引き上げる、というのがSymphonyの中心コンセプトです。

リポジトリ概要と公式ステータス

リポジトリのメタ情報をまとめると次の通りです。

READMEには「Symphony is a low-key engineering preview for testing in trusted environments.」と明記されており、本番運用ではなく信頼できる環境での評価を前提とした位置づけです。Elixir参照実装側のREADMEではさらに踏み込んで「prototype software intended for evaluation only」と自己評価しており、商用サポートを期待する性質のソフトウェアではない点に注意が必要です。

harness engineeringの延長線上に位置づけられる理由

公式READMEの「Requirements」セクションには、Symphonyが活きる前提条件として「Symphony works best in codebases that have adopted harness engineering.」と書かれています。harness engineeringはOpenAIが 公式ブログ で提唱した概念で、AIコーディングエージェントを動かすための環境・制約・フィードバックループを設計する規律を指します。「Agent = Model + Harness」という関係でモデル単体ではなく周辺の足場まで含めて品質を上げるという考え方です。

Symphonyはこのharness engineeringの「次のステップ」として位置づけられています。harness engineeringが個々のエージェントを快適に動かす土台を整える段階だとすれば、Symphonyは整った土台の上で複数のエージェントを並行に走らせ、人間は個別のエージェントを監督するのではなく作業全体を管理する段階へ進めるためのレイヤーです。逆に言えば、harness engineeringの整備が進んでいないコードベースにSymphonyを載せても期待した自走は得られません。

なおSymphonyと同じく「コーディングエージェントの品質を別レイヤーで担保する」アプローチには、エージェントの個別スキル（コミット規約・PR記述・テスト戦略など）をプロンプト資産として整理する取り組みもあります。こちらは AIコーディングエージェントをTDDで品質管理するagent-skills で扱っているため、Symphonyのオーケストレーション層と組み合わせて捉えるとレイヤー構造が見えやすくなります。

SymphonyとLinear・Codexの関係——チケットを実行キューに変える仕組み

Symphonyの最大の特徴は、Issueトラッカーとして広く使われている Linear を「control plane（制御平面）」として再利用する点にあります。SPEC.mdの§1 Problem Statementでは、Symphonyが解決する4つの運用課題が挙げられています。

1. Replaces ad-hoc per-issue scripts with a repeatable, daemonized workflow that watches a tracker, dispatches agents, and tears them down.
2. Provides isolated workspaces (per issue) so agent commands and side effects do not collide.
3. Versions workflow policy as WORKFLOW.md inside the repository so the workflow is reviewable.
4. Surfaces enough observability to operate and debug multiple concurrent agent runs.

出典: openai/symphony SPEC.md

要約すると「手動スクリプト集を再現可能なデーモンワークフローに変える」「issueごとにワークスペースを隔離する」「ワークフローポリシーをリポジトリ内の WORKFLOW.md でバージョン管理する」「並行エージェントを運用・デバッグできる可観測性を提供する」の4点です。

Linear issue → workspace → Codexセッションの流れ

Elixir参照実装のREADMEに記載されている動作フローは次の通りです。

1. Linearから候補となるissueをポーリングする
2. issueごとにワークスペース（ディレクトリ）を作成する
3. ワークスペース内でCodexをApp Serverモードで起動する（Codex App Server docs）
4. ワークフロー（プロンプト）をCodexに送信する
5. issueが完了するまでCodexを動かし続け、terminal state（Done / Closed / Cancelled / Duplicate）に遷移したら停止しワークスペースをクリーンアップする

Codex App Serverモードは、Codexを単発のCLIではなく長時間稼働するサーバープロセスとして起動し、JSON-RPCベースで複数ターンのやり取りを継続できるモードです。SymphonyはこのApp ServerをLinear issueごとに専用プロセスとして立ち上げ、終わったら片付けるライフサイクル管理を担当します。

ハンドオフ状態（Human Review）で完了する設計の意味

SPEC.mdで強調されているもう一つの重要な境界は、「Symphonyはスケジューラ／ランナー＋トラッカーリーダーであり、チケット書き込み（state遷移・コメント・PRリンク）はコーディングエージェント側が行う」という責任分担です。さらに「成功実行は Done ではなく Human Review などのハンドオフ状態で終わってよい」と書かれています。

つまりSymphonyは「人間レビューを排除する」設計ではなく、「人間が処理すべきレビューにきれいに引き継げる状態までを自走範囲とする」設計です。この境界線を理解しておくと、後述する採用判断のチェックリストでも「自社のレビュー文化と整合するか」を確認しやすくなります。

なお、社内導入により「PR数が約500%増加した」という数字がメディア報道で紹介されています（Ledge.ai など）。READMEに直接の記載はなく一次情報ではない点に注意が必要ですが、ハンドオフ状態までを自走させた結果として人間がレビューに集中できるようになり、スループットが上がったことを示唆する数字として報じられています。

アーキテクチャ8コンポーネント×6レイヤーで読み解く設計

SPEC.mdの§3では、Symphonyの内部構造が「8コンポーネント」と「6抽象レイヤー」の二軸で記述されています。SPEC全文を読む前にこのマップを押さえておくと、参照実装のコードや自前実装の設計がぐっと読みやすくなります。

主要コンポーネント（SPEC §3.1）

SPEC.mdに記載された8つの主要コンポーネントは次の通りです。

出典: openai/symphony SPEC.md §3

ポイントは、Issue Tracker ClientとAgent Runnerが「外部システムとの境界」、Orchestratorが「全体の制御」、Workspace Managerが「副作用の隔離」を担当することです。Linearを別のIssueトラッカーに差し替える、あるいはCodexを別のコーディングエージェントに差し替えるといった改造は、これらの境界コンポーネントを置換する作業として整理できます。

抽象レイヤー（SPEC §3.2）

ポータビリティを保つための6層は次の通りです。

出典: openai/symphony SPEC.md §3

PolicyレイヤーがリポジトリにバージョンコントロールされたMarkdownである点が特徴的です。チームルールをコードレビューと同じワークフローで変更できるため、エージェントの挙動を変えるたびにデプロイが必要、という運用にはなりません。

WORKFLOW.mdの最小例

WORKFLOW.md はYAML front matterと自然言語プロンプトを1ファイルにまとめた形式です。Elixir参照実装の README に記載された最小例を引用します。

---
tracker:
  kind: linear
  project_slug: "..."
workspace:
  root: ~/code/workspaces
hooks:
  after_create: |
    git clone git@github.com:your-org/your-repo.git .
agent:
  max_concurrent_agents: 10
  max_turns: 20
codex:
  command: codex app-server
---

You are working on a Linear issue {{ issue.identifier }}.

Title: {{ issue.title }} Body: {{ issue.description }}

出典: openai/symphony elixir/README.md

front matterのtracker・workspace・hooks・agent・codexが型付き設定として読み込まれ、後続の自然言語部分がプロンプトテンプレートになります。Linear issueの属性は {{ issue.identifier }} のようなテンプレート変数として埋め込み可能です。

主要な設定キーはSPEC §6.4のCheat Sheetに整理されており、デフォルト値は次のようになっています（抜粋）。

出典: openai/symphony SPEC.md §6

動的リロード（MUST仕様）と運用への影響

SPEC §6.2では、WORKFLOW.md の変更を検知して再起動なしで設定とプロンプトを再適用することが必須仕様（MUST）として規定されています。プロンプトを修正するたびにオーケストレータを再起動するとなると、走行中のエージェントがすべて中断されてしまうため、長時間ジョブを多数走らせる前提では現実的ではありません。動的リロードを必須とした設計判断は、後述するElixir/OTP採用の根拠とも直結しています。

なぜElixir/OTPなのか——Symphony参照実装の選択理由

「Symphonyの参照実装はElixir」という事実は、Elixirに馴染みのないチームには採用検討の最初のハードルになります。なぜLanguage agnosticなSPECを掲げているOSSが、参照実装にElixirを選んだのでしょうか。Elixir参照実装のREADMEのFAQ「Why Elixir?」には、その理由が直接的に書かれています。

Elixir is built on Erlang/BEAM/OTP, which is great for supervising long-running processes. It has an active ecosystem of tools and libraries. It also supports hot code reloading without stopping actively running subagents, which is very useful during development.

出典: openai/symphony elixir/README.md

要点は3つです。

1. 長時間プロセスのスーパーバイズに強い: Erlang/BEAM/OTPはスーパービジョンツリーで子プロセスの再起動戦略を宣言的に記述でき、エージェントが落ちたらどう再起動するかを言語レベルでサポートします
2. ホットコードリロード: 実行中のサブエージェントを止めずに本体コードを更新できるため、SPEC §6.2の動的リロード要件と相性が良いです
3. エコシステム: 並行・分散システム向けのライブラリ群（GenServer、Supervisor、Phoenix等）が充実しており、ゼロから作る部分が少なくなります

Symphonyのワークロード（Codexサブプロセスを最大10並行で長時間動かし、issueの状態変化に応じて起動・停止を繰り返す）を素直に書き下すと、ErlangのVMが提供する軽量プロセスと監視ツリーがほぼそのまま地図になります。設計判断としての一貫性は高いと言えます。

SPECがlanguage-agnosticである意味——他言語移植の選択肢

一方で、READMEの「Running Symphony」セクションには2つの導入経路が示されています。

つまりOpenAIは「Elixirが嫌なら自分で書いてくれ。SPECさえ満たせば言語は問わない」というスタンスを取っています。SPEC.mdはRFC 2119のキーワード規約（MUST/SHOULD/MAY）に従って書かれており、移植時に守るべき必須要件と推奨要件を切り分けやすい構造です。

実際にElixirコミュニティ以外でも移植や類似プロジェクトの議論が始まっており、TypeScript・Python・Go等への移植は技術的には十分現実的です。「Elixir運用知見がゼロだからSymphonyは諦める」という判断の前に、「SPECだけを採用してOption 1で自前実装する」という選択肢があることを押さえておきましょう。

類似OSSとの比較——Multica・Paperclipとの設計思想の違い

「コーディングエージェント管理OSS」という広義テーマでは、Symphonyのほかにも複数のOSSが立ち上がっています。本記事では、特に検索需要の重なりが大きい Multica と Paperclip との比較を整理します。それぞれ「コーディングエージェントを束ねる」点では共通しますが、control plane（制御平面）と設計思想が明確に異なります。

比較表

Symphonyの最大の差別化要素は、既存のIssueトラッカー（Linear）をそのままcontrol planeとして再利用する点です。Multicaは独自カンバンUIで「エージェントをチームメイトとしてアサインする」体験を提供し、Paperclipは独自組織図UIで「AIエージェントによる会社運営」を実験できるよう設計されています。Symphonyはこの「独自UIを作らない」割り切りによって、既にLinearを使っているチームにとっては学習コストが極端に低くなる一方、Linearを使っていないチームには採用障壁になるというトレードオフを抱えています。

Multica・Paperclipの設計思想や機能の詳細は、それぞれ Multicaとは？OSSで注目されるAIエージェント管理プラットフォームを解説 と AIエージェントを会社化するPaperclipの特徴とCrewAI・Difyとの違い で扱っているのであわせて参照してください。

ユースケース別の選び方

3者は「広義のコーディングエージェント管理OSS」では重なりますが、検索意図と適合するユースケースは明確に分かれます。

• Linearで既にissue管理が定着しており、Codex CLIを業務利用している: Symphony。既存ワークフローに最も摩擦少なく挿入できます
• 既存の人間チームに段階的にAIエージェントを「チームメイト」として混ぜたい: Multica。協働UIとスキル蓄積の発想が活きます
• AIだけで会社運営を試したい・予算と監査ログでガバナンスしたい: Paperclip。組織化と予算管理の発想が活きます

「すべてを一つのOSSで賄う」より、チームの現状（control planeとして何を使っているか／エージェントとどう協働したいか）から逆算して選ぶのが現実的です。

採用判断のチェックリスト——Symphonyを使うべきケース・見送るべきケース

ここまでの内容を踏まえて、Symphonyの採用判断を3パターン（採用 / 見送り / 様子見）に分けてチェックリスト化します。Engineering Preview扱い・standalone product としては保守しないという公式方針・Linearへの依存・Codex前提・trusted environments限定、といった制約を踏まえた判断軸です。

採用すべきケース

以下の条件にすべて当てはまる場合、Symphonyの導入価値は高いと考えられます。

• Linearでissue管理が既に定着しており、Linearの状態遷移をチームの共通言語として運用している
• Codex CLIをすでに業務利用しており、harness engineering（ガード／フィードバックループの整備）に取り組んでいる
• Elixir/OTPの運用知見が社内にある、または学習投資を許容できる
• Engineering Preview扱いであることを承知し、本番ワークフローではなく社内検証ワークフローから導入する割り切りができる
• ハンドオフ状態（Human Review）で人間が引き継ぐレビュー文化が既に存在する

見送るべきケース

以下のいずれかに該当する場合、現時点での導入は推奨されません。

• Linear以外のIssueトラッカー（Jira / GitHub Issues / Backlog等）が必須で、移行も難しい
• sandbox要件が厳しく、Codexのsandbox / approval policyだけではガバナンス要件を満たせない
• 本番運用が前提で、商用サポート・SLA・長期メンテナンスが必要
• Elixir/OTPの運用知見がゼロで、学習投資も難しい
• harness engineeringの整備がまだ始まっていない（Symphonyを載せても自走の前提が成立しない）

様子見すべきケース

以下に当てはまる場合、SPEC安定化やエコシステムの成熟を待つ判断が合理的です。

• SPECがDraft v1段階のため、v1.x安定化までは投資判断を保留したい
• Kata CLI等を経由してClaude / Gemini等の他コーディングエージェントに置換できるかを検証中
• 自前実装（Option 1）でTypeScript / Python / Go移植版を作るかどうか検討中
• 社内のLinear利用率が低く、まずLinearの定着から着手すべき段階

「採用」「見送り」「様子見」の境界はチームの状況次第ですが、共通して言えるのは、Symphonyは「エージェント運用の前提（harness engineeringとLinear運用）が整っているチーム」が次の段階に進むためのレイヤーであるということです。前提が揃っていない段階で導入しても、期待した自走は得られません。

まとめと公式情報

Symphonyは、Linearを既存control planeとして再利用しながらCodexの並行実行を自動化するためのOpenAI公式OSSです。SPEC.mdが言語非依存仕様として独立しており、Elixir参照実装はあくまでプロトタイプとして提供される、という構造を取ります。

3行サマリ:

• Symphonyの本質: コーディングエージェントを「監督する」運用から、Linear issueを「実行キュー」として作業を「管理する」運用へ抽象度を引き上げるオーケストレーション層
• 設計の中心: SPEC.mdの8コンポーネント×6レイヤーと、WORKFLOW.md のリポジトリ管理＋動的リロード（MUST仕様）。Elixir/OTPはこれら要件に素直にマップする
• 採用判断: Linear運用 + Codex CLI業務利用 + Elixir運用知見が揃うチームに最も適合。前提が欠ける場合はOption 1での自前実装か、SPEC安定化を待つ様子見が現実的

次のアクションとして、まずは公式リソースに目を通すことをおすすめします。

• openai/symphony リポジトリ（README・全体像の把握）
• SPEC.md（言語非依存仕様、自前実装する場合の必読資料）
• elixir/README.md（参照実装のFAQ・設定例）
• Codex App Server docs（Symphonyが起動するCodexモードの公式ドキュメント）
• OpenAI公式ブログ「harness engineering」（前提となる規律の解説）

OpenAIはSymphonyを「standalone productとしては保守しない」方針を表明していますが、SPEC自体は十分に練られた仕様であり、Linear×Codex以外のスタックに移植する設計図としても有用です。コーディングエージェントの並行実行を自社ワークフローにどう落とすかを検討している段階の読者にとって、Symphonyは「採用するかどうか」より「設計図として何を学べるか」を最初に問うべきOSSと言えます。