こんにちは！ブロックチェーンエンジニアの山口夏生です。
ブロックチェーン×AI Agentで自律経済圏を創る開発組織Komlock labでCTOをしています。
コーディングエージェントを複数並列で自律的に回すマルチエージェント開発が、ここ数ヶ月でエンジニアの間に急速に広まっていますが、まだそれぞれ試行錯誤しているフェーズで、最適解はない認識です。
OpenAIが最近発表したSymphonyに注目しています。
自分もClaudeCodeとOpenClawのオーケストレーションを日常的に考えていて、複数エージェントのタスクやセッション管理に苦労していたので、とても気になりました。中身を読んでいきます。
これまでの試行錯誤 — 「エージェントチームの管理」は個人技だった
Ralph Loop — エージェントの基本的なフィードバックループ
マルチエージェント開発の文脈で「Ralph Loop」と呼ばれるパターンがあります。
Ralph Loopとは、AIコーディングエージェントがソフトウェア開発を自律的に進めるための反復プロセスで、AIが「次にやるべきタスクを計画（Plan）→コードを実装（Implement）→テストやCIで検証（Test）→結果をレビューして問題を見つける（Review）→修正や次タスクを生成して再度計画に戻る（Iterate）」というループを継続的に回す仕組みを指します。
つまり、人間の開発者が普段行っている「考える→書く→試す→直す→次を決める」という思考サイクルをAIに実行させる設計パターンであり、Claude CodeやCodexなどのAIエージェント、GitHub IssueやCIと組み合わせることで、AIが自動でタスク処理・改善・開発を繰り返す“自律的な開発ループ”を構築できます。
ただし、基本のRalph Loopには限界があります。毎サイクル同じプロンプトで再実行するため、「なぜ失敗したか」の分析がプロンプトに反映されません。学習データは蓄積されますが、次回の実行指示そのものは静的なままです。
ElvisのOpenClaw + Ralph Loop V2
@elvissunが2月に公開した投稿は5.1M Viewsを記録。
ElvisはOpenClawというAIオーケストレーター（通称Zoe）を自作し、Codex、Claude Code、Geminiの3モデルを使い分けてエージェントを並列実行しています。git worktree + tmuxでワークスペースを隔離し、cronで10分ごとに監視。B2B SaaS（Medialyst.ai）をほぼ一人で運営し、自己申告で1日94コミット、30分で7PR、コスト月$190という脅威の生産性。
ElvisはこのRalph LoopをV2に進化させています。V2ではZoeがビジネスコンテキストを使ってプロンプト自体を書き換えます。コンテキスト不足なら「この3ファイルだけに集中」、方向違いなら「顧客はXではなくYを求めている。会議メモはこれ」と動的に調整する仕組みです。
共通する課題
Elvis含め、マルチエージェント開発を実践しているエンジニアが共通して解決しようとしている問題は4つあります。
- ワークスペース隔離 — エージェント同士が干渉しないようにする
- タスクディスパッチ — どのチケットをどのエージェントに割り当てるか
- 監視とリトライ — 失敗を検知して再実行する
- 人間との接点 — いつ、どこで人間がレビューするか
これらは各自がスクリプトやcronで自作してきました。再現性がなく、属人的になりがちでした。自分もClaude Codeのサブエージェントを複数回す仕組みを自作していますが、まさにこの4つが常に課題です。
Symphonyとは何か — OpenAIの回答
一言で言うと
上記4つの課題を、言語非依存の仕様書として標準化したものです。Linearのプロジェクトボードを監視し、チケットごとにエージェントを自動ディスパッチする長時間稼働デーモンの設計仕様になっています。
何が新しいのか
- Elvisたちが個別に組んでいたスクリプト群を、SPEC.mdという正式な仕様書に落とし込んでいる
- リファレンス実装はElixir/OTPだが、「好きな言語で作れ」と明言している
- WORKFLOW.mdでプロンプトとランタイム設定をリポジトリにバージョン管理できる
- CI/CDと同じ感覚で、エージェントのワークフローをチームで共有・改善できる
既存ツールとの関係
| 比較対象 | 役割 | Symphonyとの違い |
|---|---|---|
| CI/CD | コードプッシュ→ビルド・テスト | Symphonyはチケット→コード実装そのもの |
| LangChain / CrewAI | 汎用LLMフレームワーク | Symphonyはコーディングエージェント専用 |
| Codex CLI / Claude Code | エージェント本体 | Symphonyはそれらを管理するメタシステム |
| Swarm（2024年） | 手動ハンドオフ中心 | Symphonyはissue駆動の自律実行 |
SymphonyはClaude CodeやCodexの「代替」ではなく、それらを「ワーカーとして管理する」上位レイヤーにあたります。
アーキテクチャ — 仕様書が示す設計
全体フロー
処理の流れはこうなっています。
- Linearプロジェクトボードをポーリング（デフォルト5秒間隔）
- Todo / In Progressのチケットを検出
- チケットごとに隔離ワークスペースを作成し、
hooks.after_createでリポジトリをclone - Codex App Serverモードを起動し、WORKFLOW.mdのプロンプトを送信
- エージェントが実装→テスト→PR作成→Linear上に「Codex Workpad」として進捗記録
- Human Reviewへ移行し、人間がレビュー
- 承認後、landスキルでマージ→Done
WORKFLOW.md — プロンプトと設定の一体管理
WORKFLOW.mdはYAMLフロントマター + Markdownプロンプトテンプレートの構成です。最小構成はこうなります。
---
tracker:
kind: linear
project_slug: "my-project"
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
approval_policy: never
thread_sandbox: workspace-write
---
あなたはソフトウェアエンジニアです。
以下のイシューを実装してください。
## イシュー情報
- ID: {{ issue.identifier }}
- タイトル: {{ issue.title }}
- 説明: {{ issue.description }}
Liquid形式のテンプレート変数でチケット情報が自動で埋め込まれます。プロンプトをリポジトリにコミットできるので、チーム全員が同じワークフローでエージェントを動かせます。個人的にはこのWORKFLOW.mdの設計が一番気に入っています。プロンプトをバージョン管理できるのは、チーム開発では地味に大きいです。
ステートマシン
Rework時の設計が面白い。既存PRをクローズし、Workpadを削除し、新ブランチを作成して最初からやり直す。中途半端なパッチを当てるのではなく、前回の失敗を踏まえた上で全面リセットする設計です。自分もClaude Codeでコード生成がうまくいかないとき、差分修正より全部やり直した方が早いケースが多いと感じていて、この判断を自動化してくれるのは合理的です。
なぜElixir/OTPなのか
リファレンス実装にElixir/OTPが選ばれた理由は明確です。
- Erlang/BEAMは長時間稼働プロセスの管理に向いている
- supervision treeで複数エージェントの並行実行を自然に実装できる
- ホットコードリロードで稼働中のエージェントを止めずに更新可能
ただし、これはリファレンス実装に過ぎません。SPEC.mdがあるので、TypeScriptでもGoでもPythonでも再実装できます。
Harness Engineering — Symphonyが前提とする開発基盤
Symphonyは「チケットを投げればコードが出てくる」システムですが、それが機能するにはコードベース側の準備が必要です。OpenAIはこれをHarness Engineeringと呼んでいます。
Harness Engineeringとは
OpenAIが2026年2月に公開した社内開発手法です。5ヶ月の実験で、小規模チームがCodexエージェントを使い、手動でコードを一切書かずに約100万行のプロダクトをベータリリースしました。エンジニアの仕事は「コードを書くこと」から「エージェントが働ける環境を設計すること」に変わったとのことです。
具体的に何を整備するか
エージェントが自律的に作業するために必要な「ハーネス（装具）」を整理します。
| 要素 | 役割 |
|---|---|
| CI/CD | エージェントのPRが自動でテスト・ビルドされる仕組み。これがないと成果物を検証できない |
| テスト | ユニットテスト、E2E、型チェック。エージェントの「完了」を機械的に判定する基準 |
| リンター・フォーマッター | コードスタイルの自動統一。エージェントが書いたコードの一貫性を保つ |
| オブザーバビリティ | ログ、メトリクス、スパン。エージェントがバグを再現し、修正を検証するために必要 |
| ドキュメント・型定義 | エージェントがコードベースの構造を理解するための情報。AGENTS.mdやADRなど |
SymphonyとHarness Engineeringの関係
SymphonyのWORKFLOW.mdには、エージェントへのプロンプトに加えて「CIが通ること」「コードレビューを通過すること」などの完了条件が含まれています。これらの条件はHarness Engineeringで整備した基盤がなければ機能しません。
つまりSymphonyはオーケストレーション層、Harness Engineeringは実行基盤層。両方が揃って初めて「チケット→PR」の自動化が成立します。逆に言えば、テストもCIもないリポジトリにSymphonyを入れても意味がありません。エージェント導入の前に、まず開発基盤を整えるのが先です。
ElvisのOpenClawでも同じ構造が見えます。CI（lint、typecheck、unit test、E2E、Playwright）+ 3モデルによるコードレビューがエージェントの品質保証になっています。形は違えど、「エージェントの成果物を機械的に検証する仕組み」は共通要件です。
ハンズオン: Symphonyをセットアップして動かす
前提環境
- Linearアカウント + Personal API Key
- Codex CLI（App Serverモード対応版）
- mise（Elixir/Erlangバージョン管理）
環境構築
miseが未インストールの場合は先にインストールします。
# mise のインストール（macOS / Linux）
curl https://mise.run | sh
# シェルに mise を有効化（zshの場合）
echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc
Homebrew経由でもインストールできます
brew install mise
echo 'eval "$(mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc
miseの準備ができたら、Symphonyをセットアップします。
# リポジトリをクローン
git clone https://github.com/openai/symphony
cd symphony/elixir
# mise でElixir/Erlangランタイムをインストール
mise trust
mise install
# Elixir の依存関係をインストールしてビルド
mise exec -- mix setup
mise exec -- mix build
Linearプロジェクト設定
SymphonyはLinear（プロジェクト管理ツール）のチケットをポーリングして動作します。JiraやGitHub Issuesと同じ領域のツールですが、現時点ではLinear以外には対応していません。
Linearに馴染みがない方は、公式のスタートガイドが参考になります。
まだアカウントがない場合はLinear公式サイトから作成してください（無料プランあり）。
Symphonyが認識するカスタムステータスをプロジェクトに追加する必要があります。
- Linearでワークスペースにログインし、プロジェクトを作成
- Settings → Custom statuses で以下を追加
- Rework
- Human Review
- Merging
- Settings → Security & access → Personal API keys でAPIキーを取得
- 環境変数を設定
export LINEAR_API_KEY="lin_api_xxxxxxxxxxxxx"
WORKFLOW.mdのカスタマイズ
自分のリポジトリ向けに書き換えます。最低限変更が必要な項目は以下です。
-
tracker.project_slug— Linearプロジェクトのslugを指定 -
hooks.after_create— git cloneするリポジトリURLを自分のものに変更 -
agent.max_concurrent_agents— 並列数を調整（デフォルト10、RAMに応じて減らす）
サンドボックスポリシーは workspace-write（ワークスペース内の書き込みのみ許可）が推奨されています。
Webダッシュボードを使いたい場合は、serverセクションも追加します。設定しなくてもターミナル上のダッシュボードで状態は確認できます。
server:
port: 4000
host: "127.0.0.1"
起動
# Symphonyデーモンを起動
mise exec -- ./bin/symphony \
--i-understand-that-this-will-be-running-without-the-usual-guardrails \
./WORKFLOW.md
Engineering Preview版のため、「ガードレールなしで動作すること」に同意するフラグが必須です。このフラグなしで実行するとエラーになります。
起動すると、ターミナルにステータスダッシュボードが表示されます。エージェント数、トークン消費量、ポーリング間隔などがリアルタイムで更新されます。WORKFLOW.mdにserverセクションを追加していれば、http://localhost:4000 のWebダッシュボード（Phoenix LiveView）でも確認できます。
Linearでチケットを「Todo」に移動すると、Symphonyがそれを検出してエージェントを自動起動します。
OpenAIが公開しているデモ動画がこちら。
注意点
- 現時点ではLinear限定（Jira、GitHub Issues未対応）
- エージェント並列数に応じてAPI費用が増加します。X上では10エージェント並列で月$5,000/人程度との試算も出ています
- Codex App Serverモードが必要です（通常のCLIモードでは動作しません）
SPEC.mdから自分の実装を作るには
OpenAIの推奨アプローチ
READMEに明記されています。
Implement Symphony according to the following spec: https://github.com/openai/symphony/blob/main/SPEC.md
Elixir実装にこだわる必要はありません。SPEC.mdを読んで好きな言語で作れ、というスタンスです。SPEC.mdの全文はこちらで読めます。
最小実装に必要なコンポーネント
| コンポーネント | 役割 |
|---|---|
| Workflow Loader | YAML + Markdownパーサー。WORKFLOW.mdを読み込む |
| Issue Tracker Client | Linear APIをポーリングしてチケットを取得 |
| Orchestrator | ディスパッチ + 状態管理のメインループ |
| Workspace Manager | ディレクトリ作成 + hooks実行 |
| Agent Runner | Codex app-serverの起動とストリーム管理 |
Gotaさん(@gota_bara)がPython版を自作して公開しています。Elixirに馴染みがない場合はこちらが参考になります。
Symphonyの先にあるもの
静的ワークフロー→動的学習
現在のWORKFLOW.mdは静的なプロンプトテンプレートです。ElvisのRalph Loop V2が示した「失敗からプロンプトを改善する」仕組みが将来的に取り込まれれば、エージェントの品質は使うほど上がっていくことになります。現時点のSymphonyにはこの学習機構がありません。個人的には、ここが一番惜しいポイントです。自分がClaude Codeで記事生成パイプラインを組んでいるときも、失敗パターンのフィードバックが自動化されていないと品質が頭打ちになります。
Linear以外のトラッカー対応
tracker adapterの抽象化は済んでいるので、Jira/GitHub Issues対応は技術的に可能な状態にあります。ここが広がれば導入障壁は大幅に下がります。
チケットの書き方がコードの品質を決める時代
エージェントへの指示精度がそのまま成果物の品質に直結します。「良いチケットを書く力」が開発スキルの一部になる。曖昧な要件定義がエージェントに通らない以上、チケットの粒度と明確さがこれまで以上に求められるようになります。自分もClaude Codeに渡すプロンプトの書き方で出力が全然変わることを日々実感しているので、これはチケット管理でも同じことが起きるはずです。
まとめ
マルチエージェント開発は、ここまで個人の創意工夫で進化してきました。Symphonyは、その試行錯誤を仕様書として整理し、誰でも再実装できる形にしています。Engineering Previewの段階ではありますが、SPEC.mdの設計品質は高く、エージェントオーケストレーションの「共通言語」になる可能性があります。
自分はまだSymphonyを本番に組み込むには早いと感じていますが、SPEC.mdの設計思想は自分のエージェント管理にも取り入れられる部分が多いです。まずはリポジトリをcloneしてローカルで動かしてみる。次にSPEC.mdを読んで設計思想を掴む。自分の開発フローにどう組み込むかは、仕様書を読んでから考えればいいと思います。
あと個人的には、Linearの学習コストが一定あるので、早く他のツールにも対応して欲しいです。
Komlock labはAI x ブロックチェーン開発に注力しています！！
Komlock labでは、こうした最新規格の調査だけでなく、実際のプロダクト開発や技術検証に日々励んでいます。
こちらは、以前開発したAIエージェント間の業務委託契約の紹介記事です。
Komlock lab エンジニア募集中
「AI x ブロックチェーン」という未開拓な領域で、未来のインフラを一緒に作りませんか？
エンジニア絶賛募集中ですので、DMでもDiscordでもお気軽にご連絡ください！
DM宛先：
PR記事とCEOの創業ブログ
Komlock lab もくもく会＆LT会
ブロックチェーン開発関連のイベントを定期開催しています！
Discordコミュニティ
有益な記事の共有や開発の相談など行っています。どなたでもウェルカムです
Discussion