polyphony

polyphony skillの概要

polyphony は、コンテナで分離されたワークスペース上で並列にエージェント作業を走らせるためのマルチエージェント・オーケストレーション skill です。各セッションに専用の Docker コンテナと git ブランチが割り当てられるため、同時実行してもブランチ衝突、共有状態の不具合、後始末の煩雑さを避けたい場面で役立ちます。

polyphony skillは何のためにあるか

polyphony skill は、1回のプロンプトでは収まりきらないものの、構造化した分担があると進めやすい作業に向いています。たとえば、機能開発の並列化、分離された検証、issue のトリアージ、同じコードベースに対する複数のエージェント経路の実行などです。きれいな実行、再現可能なタスク振り分け、安全なマルチエージェント協調を重視する人向けに設計されています。

polyphony skillが際立つ理由

polyphony の最大の差別化ポイントは、分離を前提にしたワークフロー設計にあります。エージェントに「全部やって」と丸投げするのではなく、タスクの発見、ルーティング、プロビジョニング、実行、検証を切り分け、各ワーカーが制御されたワークスペースで動くようにします。そのため、独立したテストとよりきれいな着地が必要なときに、polyphony for Multi-Agent Systems のアプローチが実用的になります。

向いているケースとトレードオフ

polyphony が最も合うのは、環境がすでに Docker か OrbStack をサポートしていて、単発のプロンプトではなくデフォルトでオーケストレーションしたい場合です。逆に、単一のチャット応答だけで足りる、コンテナを起動できない、リポジトリを意識したワークフローなしで最小限のセットアップにしたい、という場合にはあまり向きません。

polyphony skillの使い方

polyphony をインストールして読み込む

polyphony skill を skills ディレクトリにインストールし、skill の読み込みをサポートするホスト側のワークフローから使います。リポジトリの説明では、コンテナ分離が利用可能な場合は自動的に読み込まれる想定で、/spawn-team の既定値にもなっています。環境が異なる場合は、skill に頼る前に Docker へのアクセス、ブランチ作成、ワークスペースのマウントが使えるかを確認してください。

まず読むべきファイルから始める

polyphony を使うときは、まず skills/polyphony/SKILL.md から読み始め、その skill が内部で使う順序に沿って、リンクされている、または言及されているコンテキストを追ってください。タスクのライフサイクル、アーキテクチャ、前提条件、設定、そしてファイル内に埋め込まれたリポジトリ固有の参照です。このリポジトリには補助スクリプトや追加の参照フォルダがないため、コアの動作は skill ファイル自体にあります。だからこそ、丁寧に読む価値があります。

ざっくりした目的を使えるプロンプトに変える

polyphony に向いたプロンプトには、対象の repo、並列化したいエージェント数、各エージェントが担当すべき作業の種類、ブランチや PR に関する期待値、テスト・認証情報・クリーンアップに関する制約を入れるべきです。たとえば「このプロジェクトを直して」ではなく、「この issue を3つの分離されたエージェントタスクに分けてください。再現、修正、検証をそれぞれ担当し、別々の Docker ワークスペースを使って、各ブランチごとの landing 状態を報告してください」と依頼します。

よりよい出力のために指定すべきこと

skill に対しては、タスクの優先度、依存関係、まず読み取り専用で進める必要があるかどうか、どの環境ならプロビジョニングしてよいか、何をもって検証完了とみなすか、といった具体的なルーティング情報を与えてください。これにより orchestrator がより適切な RunSpecs を選びやすくなり、無駄なコンテナ起動も減ります。polyphony のガイドでは、最も価値がある入力は長い説明文ではありません。タスクの境界をより明確にすることです。

polyphony skillのFAQ

polyphony は Docker 環境専用ですか？

実質的にははい、です。polyphony skill はコンテナ分離が利用可能であることを前提にしているため、Docker か OrbStack のサポートが導入可否の主な分岐点になります。コンテナを立てられないなら、このワークフローの価値はほとんど失われます。

polyphony は普通のプロンプトと何が違いますか？

違います。普通のプロンプトはエージェントに行動を促しますが、polyphony は複数のエージェント実行をどう確保し、どう振り分け、どうプロビジョニングし、どう検証し、どう着地させるかを定義します。その構造こそが polyphony skill の本質であり、独立したブランチときれいな実行が速度以上に重要なときに特に効きます。

初心者でも polyphony を使えますか？

はい、すでにコンテナを実行できて skill ファイルを読めるなら使えます。主な学習曲線はプロンプトの書き方ではなく、polyphony がタスク分解と実行環境の準備を前提にしている点を理解することです。初心者は、まず小さなタスクを1つと、明確な検証ゴールを1つだけ設定すると、よりよい結果を得やすいです。

どんなときに polyphony を使うべきではありませんか？

すぐ答えがほしい単発の質問、軽い編集、Docker が使えない環境では使わないでください。また、タスクが曖昧で、各エージェントが何を担当するのかまだ決めていない場合も不向きです。オーケストレーションのオーバーヘッドが、得られる利点を上回ることがあるためです。

polyphony skillを改善するには

ルーターが判断しやすいタスク境界を与える

polyphony で品質が最も上がるのは、タスク分解を明確にしたときです。どの作業が探索、どの作業がコード変更、どの作業が検証専用なのかを明示してください。並列化したいなら、曖昧な目的から system に推測させるのではなく、分担をはっきり定義するほうがよいです。

ワークスペース挙動に影響する制約を入れる

ブランチ命名規則、ネットワーク制限、テスト実行時間の想定、シークレットやマウント済みIDが必要かどうかを伝えてください。polyphony は分離されたコンテナと独立したブランチを使うため、こうした制約はプロビジョニングや、手動介入なしで実行を完了できるかどうかに直接影響します。

実装だけでなく検証も依頼する

よくある失敗は、「コードが変わった」で終わってしまうことです。polyphony をうまく使うには、各エージェント経路ごとに再現手順、テストコマンド、着地条件まで求めることが大切です。複数のワーカーが異なる解決策に収束する可能性がある場面では、信頼できるマージ判断が必要になるため、特に重要です。

1回目の実行後に調整する

最初の出力が広すぎるなら、タスクを絞って成功条件を1つにして再実行してください。結果が細かく分かれすぎるなら、並列エージェント数を減らし、ステージ間の依存関係を強めます。polyphony では、改善はたいてい長いプロンプトではなく、より鋭いオーケストレーション入力から生まれます。