Symphony Elixir：課題トラッカーをまたいでCodexをオーケストレーションするプロトタイプ
このサービスは、問題追跡作業を個別の実装実行に変換し、チームがワークフロー ファイルを通じてプロジェクト固有の自動化を定義できるようにします。
ひと目でわかる
- これは何？
- Elixir/OTPベースのプロトタイプで、トラッカーの課題を隔離されたCodexワークスペースに変換します。評価専用であることが明示されています。
- 誰に向いている？
- このリポジトリは自らをプロトタイプソフトウェアと明示し、SPEC.mdに基づいた堅牢なバージョンの実装を推奨しています。ドキュメントは、ディスパッチループ、ワークフロー設定、5つのトラッカーアダプター、Phoenixダッシュボード、ライブE2Eテストをカバーしています。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に Elixir です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
プロトタイプのステータスと明示的な警告
リポジトリはSymphony Elixirを評価専用のプロトタイプソフトウェアとして提示し、そのままの状態で提供します。READMEは、リポジトリルートのSPEC.mdに基づいて独自の堅牢なバージョンを実装するよう読者に警告しています。これはドキュメントが最初に述べることであり、プロジェクトの残りをどう読むべきかを形作ります。つまり、コードはオーケストレーション概念のリファレンス実装であり、本番サービスではありません。
ディスパッチループ
Symphonyは設定されたトラッカーをポーリングして候補となる作業を取得します。サポートされるアダプターは、Linear、GitHub Issues、Jira Cloud、Asana、GitLabです。各課題について、ワークスペースを作成し、そのワークスペース内でCodexをApp Serverモードで起動し、ワークフロープロンプトを送信し、課題が完了するまでCodexを稼働させ続けます。主張された課題が終了状態（Done、Closed、Cancelled、Duplicate）に移行すると、Symphonyはアクティブなエージェントを停止し、一致するワークスペースをクリーンアップします。Codexがオペレーター入力、承認、またはMCP誘発を必要と報告した場合、Symphonyは課題を主張したままにし、ランタイム状態、JSON API、ダッシュボードでブロック済みとしてマークします。ブロックされたマップはメモリ内のみに存在するため、再起動するとクリアされます。
ワークフローファイルと設定
Symphonyは、設定用のYAMLフロントマターとCodexセッションプロンプトとして使用されるMarkdown本文を含むWORKFLOW.mdファイルを読み取ります。ファイルパスはデフォルトで./WORKFLOW.mdであり、CLI引数で上書きできます。オプションのフラグには--logs-rootと--portがあり、後者はPhoenix可観測性サービスを有効にします。READMEには、セーフティ関連のCodexフィールドのデフォルトが記載されています。approval_policyは拒否マップにデフォルト設定され、thread_sandboxはworkspace-writeに、turn_sandbox_policyは課題ワークスペースをルートとするworkspaceWriteポリシーにデフォルト設定されます。LINEAR_API_KEYなどの環境変数は$VARとして参照でき、トークンがワークスペースに入らないようにします。ワークフローファイルが起動時に欠落しているか、無効なYAMLを含む場合、Symphonyは起動しません。
トラッカーアダプターとそのツール
各トラッカーアダプターは、app-serverセッション中にCodexにプロバイダー固有のツールを公開します。Linearにはlinear_graphql、GitHub Issuesにはgithub_api、Jira Cloudにはjira_rest、Asanaにはasana_api、GitLabにはgitlab_apiです。Symphonyは設定された認証を使用してこれらのツールをホスト側で実行し、宣言されたトラッカートークン環境変数をCodex子プロセスから取り除きます。READMEには各アダプターの詳細な設定、必須フィールド、デフォルトの環境変数、スコープルールが記載されています。たとえば、GitHubアダプターはrepoをowner/repo形式で要求し、Issues APIが返すプルリクエストをディスパッチ不可として扱います。Linearアダプターは、生のクエリ文字列またはqueryとvariablesを含むオブジェクトのいずれかを受け入れます。
可観測性ダッシュボードとJSON API
可観測性UIは、最小限のPhoenixスタック上で動作し、ダッシュボード用のLiveViewが/に、JSON APIが/api/v1/*の下にあります。エンドポイントには、/api/v1/state、/api/v1/<issue_identifier>、/api/v1/refreshが含まれます。トラッカーが提供するURLがhttpまたはhttpsを使用する場合、トラッカーの課題識別子はそのURLにリンクされます。ランタイム状態にはブロックされた課題が含まれ、メモリ内にのみ保持されます。オーケストレーターを再起動するとそのマップはクリアされ、まだアクティブなトラッカー課題は再びディスパッチ候補になり得ます。
テスト、リリース、ライセンス
READMEには、make allによるテストスイートの実行と、各トラッカーのオプトインライブE2Eテストが記載されており、使い捨てリソースを作成して実際のcodex app-serverセッションを起動します。Symphonyは、macOSとLinuxのarm64およびx86_64向けにBurritoで構築された自己完結型実行ファイルを提供し、Erlang/OTP、Elixir、Symphonyを組み込んでいますが、ターゲットマシンにはcodex、git、トラッカー資格情報が必要です。このプロジェクトはApache License 2.0の下でライセンスされています。ライセンス抜粋は、作品を複製、派生物の作成、公開表示、上演、サブライセンス、配布するための永続的、世界的、非独占的、無償、ロイヤリティフリーの著作権ライセンスを付与します。サポート、保証、セキュリティ保証については触れていません。 openai-symphony-deep-analysisについてREADMEに記載された入口を確認する際は、対象のコマンド、設定項目、生成されるログまたは画面の変化を一つずつ対応付けます。入力を変えたときの出力差分と、権限や依存関係が不足した場合のエラーを残すと、説明された機能と実環境で使える範囲を区別できます。 openai-symphony-deep-analysisについてREADMEに記載された入口を確認する際は、対象のコマンド、設定項目、生成されるログまたは画面の変化を一つずつ対応付けます。入力を変えたときの出力差分と、権限や依存関係が不足した場合のエラーを残すと、説明された機能と実環境で使える範囲を区別できます。
編集部の結論
このリポジトリは自らをプロトタイプソフトウェアと明示し、SPEC.mdに基づいた堅牢なバージョンの実装を推奨しています。ドキュメントは、ディスパッチループ、ワークフロー設定、5つのトラッカーアダプター、Phoenixダッシュボード、ライブE2Eテストをカバーしています。Apache 2.0ライセンスは広範な著作権と特許の許可を与えますが、サポートや保証については触れていません。
コミュニティノート