ensemble-team

アンサンブルチームのセットアップ

あらゆるソフトウェアプロジェクト向けに、AI アンサンブルプログラミングチームをセットアップします。コンセンサスに基づく意思決定、TDD、継続的な振り返りを行いながら、単一のドライバーによるモブプログラミングスタイルで作業する専門家エージェントチームの構成一式を作成します。

ワークフロー

フェーズ 1：プロジェクトの把握

プロジェクトに関する重要な情報を集めます。ユーザーに次の質問をします。

1. プロジェクト名と説明：何を作るのですか？どのような問題を解決しますか？
2. 技術スタック：言語、フレームワーク、データベース、フロントエンドのアプローチ、テストツール。 まだ決まっていない場合は、目標に基づいて選定を支援します。
3. プロダクトビジョン：対象ユーザーは誰ですか？MVP の範囲は？漠然としたアイデアでも構いません。プロダクトマネージャーエージェントが具体化します。
4. 開発環境：Nix？Docker？標準のパッケージマネージャー？CI プロバイダー？
5. リポジトリ：既存のリポジトリですか、新規ですか？ブランチ戦略は？

フェーズ 2：チーム構成

適切なチームを決定します。

前提条件：先に進む前に references/role-catalog.md を読みます。

段階別のチームプリセット

まずプリセットを選び、プロジェクトのニーズに応じて調整します。チーム編成セッション（フェーズ 5）で、適切な構成を決定します。ユーザーはどのプリセットも変更できます。

プリセット	規模	構成
Full	約9名	プロダクトマネージャー1名、UI/UX デザイナー1名、アクセシビリティスペシャリスト1名、ドメイン SME 1名、QA アナリスト1名、ソフトウェアエンジニア4名
Lean	約5～6名	プロダクトマネージャー1名、ドメイン SME 1名、開発プラクティスリード1名、ソフトウェアエンジニア2～3名、必要に応じて UX、QA、DevOps のいずれかを担当するフレックスロール1名
Solo-plus	約3名	ドメイン SME 1名、開発プラクティスリード1名、ソフトウェアエンジニア1名

ディスカッション1ラウンドあたりの概算トークンコスト：

• Solo-plus（エージェント約3名）：軽量。1ラウンドあたり約5～10Kトークン。
• Lean（エージェント約5～6名）：中程度。1ラウンドあたり約15～25Kトークン。
• Full（エージェント約9名）：高負荷。1ラウンドあたり約30～50Kトークン。ガバナンスのオーバーヘッドに見合う効果が得られるプロジェクト向けです。

実際のコストは、モデル、コンテキスト長、ディスカッションの複雑さによって異なります。これらは予算感をつかむための概算であり、正確な会計値ではありません。

プリセットの選択：プロジェクトの範囲、スケジュール、複雑さについてユーザーに尋ねます。Solo-plus は、焦点を絞ったタスクやスパイクに適しています。Lean は、ほとんどのプロジェクトに適しています。Full は、UI、アクセシビリティ、品質に関する要件がある大規模な製品に適しています。

置き換えるのではなく拡張する：これらのプリセットはロールカタログを基盤としています。Security、Data/ML、API Specialist など、どのプリセットにも追加できる条件付きロールについては、カタログを参照してください。同点を解消する際は、奇数人数を優先します。

各専門家を調査し、記憶したリストから選ばないでください。 各ロールについて、次の手順を実行します。

1. このプロジェクトで必要となる具体的な技術やドメインを特定します
2. WebSearch を使って、その分野で認められている権威、つまり書籍を執筆した人、ツールを作成した人、またはその分野を代表する講演を行った人を探します
3. 経歴、最近の活動、このプロジェクトとの関連性を確認します
4. 次の観点で評価します：公表された実績、際立った個性、実務経験、他のチームメンバーを補完する視点

提案する専門家ごとに、名前、経歴、主な著作、このプロジェクトに適している理由、担当する内容を提示します。ユーザーが承認、交代、削除できるようにします。

フェーズ 3：チームプロフィールの作成

各メンバーについて .claude/agents/<name>.md を作成します。

前提条件：先に進む前に references/profile-template.md を読みます。

必須セクション：冒頭の略歴、役割、基本方針（著作から抽出した5～8個の原則）、技術的専門知識（6～12項目）、このプロジェクトでの指針（具体的な助言）、コミュニケーションスタイル（性格と特徴的なフレーズ4～6個）、モブでの取り組み方、コードレビューのチェックリスト（6～12項目）、学び（更新用に空欄）。

品質基準：プロフィールは、他の専門家と入れ替え可能な内容であってはなりません。プロジェクト固有の指針を含める必要があります。その人物らしい際立った個性を反映させる必要があります。

AI による近似である旨の免責事項

すべてのプロフィールには、冒頭の略歴の直後に、次の免責事項ブロックを必ず含めてください。

> **AI-Approximation Notice**: This profile is an AI-generated approximation inspired
> by [Name]'s published work, talks, and writings. The real [Name] has not endorsed
> or reviewed this profile. All outputs should be verified against their actual
> published work. This profile creates a "diversity of heuristics" drawing on their
> known perspectives — it does not simulate the actual person.

AI の自己認識に関する条項

各プロファイルの「このチームにおけるあなたの役割」セクションには、チームメンバーが、実在する人物ではなく、ある視点を体現する AI エージェントであると認識していることを明記する必要があります。人間の時間的制約は AI エージェントには関係ありません。担当分野が役割の専門知識を超える場合、判断を控えるのは適切な敬意の示し方であり、不賛成を意味するものではありません。

圧縮アクティブコンテキスト形式

各プロファイルには、末尾に ## Compressed Context セクションを必ず含めてください。役割、重要な原則 3～5 個、主な専門分野、特徴的なレビュー観点を網羅した、500 トークン未満の簡潔な要約を記載します。この圧縮形式は、議論とレビューのフェーズで読み込まれます。完全なプロファイルは、そのメンバーがコードの作成や方針決定を主導しているときにのみ読み込まれます。

フェーズ 4：プロジェクトのひな形を生成する

コーディネーター向け指示

前提条件：作業を進める前に references/coordinator-template.md を読んでください。

メンバー構成、ビルドツール、チームの規模を記入します。コーディネーター向け指示を .team/coordinator-instructions.md に生成します。次に、ハーネス固有の設定ファイル（Claude Code の場合は CLAUDE.md、Cursor の場合は .cursorrules、その他のハーネスの場合はプロジェクト指示など）に、メインエージェントが .team/coordinator-instructions.md を読むよう促す参照を追加します。コーディネーター向け指示ファイルは、コーディネーター専用です。

AGENTS.md — チーム構成セクション

AGENTS.md に「チーム構成」の管理対象セクションを挿入し、以下を明記します。

• チームメンバーのプロファイルは .claude/agents/ にあります
• プロジェクトオーナーの制約は PROJECT.md で定義されています
• ドメイン用語集は docs/glossary.md で管理されています

このセクションは、すべてのエージェントに概要を示すものです。AGENTS.md の規約セクションは、チームが形成セッション（フェーズ 5）で作成します。

PROJECT.md

前提条件：作業を進める前に references/project-template.md を読んでください。

技術スタック、スコープ（必須／推奨／任意／対象外）、開発上の必須事項、環境を記入します。

補足ドキュメント

• docs/glossary.md：ドメイン用語集のひな形（コア型の表、アクションの表、エラーの表、型設計の原則）
• docs/deferred-items.md：追跡表（項目 | カテゴリ | 出典 | 重大度 | ステータス）
• docs/future-ideas.md：スコープ外のアイデアを保留しておく場所

フェーズ 5：チーム形成セッション

ここは重要なフェーズです。チームは、作業規約、アーキテクチャ上の決定、ドメイン用語について議論し、合意に達します。

進め方：コーディネーターがチーム全体を招集し、議論のトピックを一つずつ提示します。チームは議論を行い、アプローチを提案し、ロバート議事規則のプロトコルに従って合意に達します。成果物は、決定の種類に応じて適切な場所に記録します。

• 作業規約（協働の規範、完了の定義、コード規約、コミュニケーションの規範、モブモデルの詳細、ふりかえりの頻度、ツールの規約）は、AGENTS.md の規約セクションに記録します。
• アーキテクチャ上の決定（原則、デプロイ戦略、状態管理、テストの方針）は、docs/ARCHITECTURE.md に ADR として記録します。
• ドメイン用語（型、アクション、エラー、命名規約）は、docs/glossary.md を更新します。

10 個のトピック（すべてを網羅しているわけではありません。チームは追加できます）：

1. 何を作るか、どのように決めますか？
2. ドライバー・レビュアーのモブモデルはどのように機能しますか？
3. 作業はどの時点で「完了」となりますか？
4. コミットと統合のパイプラインはどうなっていますか？
5. 意見の相違をどう解決しますか？
6. コード規約はどのようなものですか？
7. ふりかえりはいつ、どのように行いますか？
8. アーキテクチャの原則は何ですか？
9. チーム内でどのようにコミュニケーションを取りますか？
10. どのようなツールとリポジトリの規約に従いますか？

各トピックには、取り上げる課題と、議論の指針となるサブ質問が含まれます。チームの回答が、そのチームの規約や決定になります。あらかじめ用意されたテンプレートをそのまま使うものではありません。

フェーズ 6：権限を設定する

チームエージェントが作業に必要な権限（ファイル編集、シェルアクセスなど）を付与します。設定方法はハーネスによって異なります。

• Claude Code："allow": ["Edit", "Write", "Bash(*)"] を含む .claude/settings.json を作成または更新します
• Cursor/Windsurf：IDE の設定でツールの権限を設定します
• その他のハーネス：エージェントへの権限付与について、ハーネスのドキュメントに従います

レビュー担当者に必要なのは、.reviews/ への書き込みアクセスのみです。権限の範囲を限定する設定とレビュー用ファイルのワークフローについては、references/file-based-reviews.md を参照してください。

フェーズ 7：CI を設定する

CI の実行をトリガーしないように、ハーネスが生成するセッションまたはトランスクリプトのディレクトリ（例：Claude Code の .claude-sessions/）に対する paths-ignore ルールを CI 設定に追加します。

フェーズ 8：まとめ

作成したファイルとチームの開始方法を説明します。ハーネス設定ファイル（例：Claude Code の CLAUDE.md）は、@（または同等のインクルード機構）を使って AGENTS.md を参照し、コーディネーターは作業手順を確認するために .team/coordinator-instructions.md を読み込みます。コーディネーターに何を構築するか伝えるよう提案します。

作成したファイル：

• .claude/agents/<name>.md — エージェント定義ファイル（チームメンバーのプロフィール）
• .team/coordinator-instructions.md — コーディネーターの作業手順
• AGENTS.md — チーム構成と規約（編成セッション中に記入）
• PROJECT.md — プロジェクトオーナーの制約事項
• docs/ARCHITECTURE.md — アーキテクチャ決定記録（編成セッション中に記入）
• docs/glossary.md — ドメイン用語集
• docs/deferred-items.md — 保留項目トラッカー
• docs/future-ideas.md — 対象範囲外のアイデアの置き場
• .reviews/ — レビューフィードバック用ディレクトリ（作業中にレビュー担当者が作成）
• ハーネス設定の参照ファイル（例：CLAUDE.md）— コーディネーターに .team/coordinator-instructions.md を読むよう指示

振り返りプロトコル

1 人のエージェントがすべての視点を書いたものは振り返りではなく、要約です。振り返りのために起動するすべてのエージェントは、.claude/agents/ に登録された名前付きのチームメンバーでなければなりません。

振り返りは時間ベースではなく、イベントを起点に実施します。トリガー：PR が出荷されるたび（インテグレーションブランチにマージされた後）。

全手順については、references/retrospective-protocol.md を参照してください。必須の 4 つのフェーズは次のとおりです。

1. 前回のアクションアイテムの監査 — 以前のすべてのアクションアイテムの状況を確認します。2 回以上前の振り返りから未着手のままの項目は、ブロッキング項目に引き上げます。
2. 個別の所見 — 各メンバーが独立して .reviews/retro/ 内のファイルに記入します。全員が記入するまで議論は行いません。
3. チームでの議論 — メンバーが互いの所見に反応し、実際にメッセージをやり取りします。コーディネーターは、1 人のエージェントによる要約ではなく、実際にやり取りが行われたことを確認します。
4. 合意形成と記録 — 提案には同意プロトコルを適用します。結果は AGENTS.md の規約または ADR に記録します。すべてのアクションアイテムに、名前付きの担当者を割り当てます。

アクションアイテムの実施ゲート： 振り返りのアクションアイテムは、次の作業項目を開始する前に実施します。これにより、改善が未対応のまま蓄積し、振り返りが無意味に感じられるのを防ぎます。

各 CI ビルド後のミニ振り返りは、軽量な観察チェックポイント（パイプラインに従ったか、コミットはアトミックだったか）として引き続き実施し、人間の同意は必要ありません。これらは観察を目的としており、指示を目的とするものではありません。

主要原則

本番運用の経験に基づく、譲れない要件です。

前提条件：作業を進める前に、references/lessons-learned.md を読んでください。

• 名前付きチームメンバーのみ：チーム作業で起動するエージェントは、必ず .claude/agents/ に登録された名前付きメンバーでなければなりません。チームの活動に汎用バックグラウンドエージェントを使用してはいけません。
• プッシュ前に合意する（ローカルでレビューしてからプッシュする）
• すべてのコミットでリファクタリングのステップを必須とする
• CI 待機ルール（CI の実行を複数同時にキューへ追加しない）
• CI ビルドのたびにミニ振り返りを行う（コーディネーターではなく、チームが実施する）
• PR を契機とする振り返りと、同意に基づく成果物
• 次の作業項目を開始する前に、振り返りのアクション項目を実施する
• ドライバー引き継ぎプロトコル（要約＋git log＋グリーンなベースライン）
• 用語集への準拠（ドメイン型を用語集に合わせる）
• 後回しにした項目は直ちに記録する
• レビュアー間の連携（まず他のメンバーのレビューを確認する）
• ブロックしないフィードバックのエスカレーション：2 回以上連続するレビューに現れる項目は、ブロッキング項目に引き上げる
• アクティベーションプロンプトでドライバーのオンボーディングを明示する
• CI のトリガーからセッショントランスクリプトを除外する
• すべてのプロフィールに AI による近似であることの免責事項を記載する
• すべてのプロフィールにアクティブコンテキストを圧縮した形式を記載する
• 傍観は不賛成ではなく、判断を委ねることを意味する
• ファイルベースのレビューはコンテキスト圧縮後も保持する（メッセージは補足であり、置き換えではない）

適用に関する注記

• サブエージェントモード：構造的です。名前付きエージェントのプロフィールによってペルソナの境界を適用します。
• チェーンモード：助言的です。役割の切り替えは自己管理されます。
• パイプラインモード：ゲーティングです。合意ゲートにより、定められたチェックポイントでパイプラインの進行をブロックします。

制約

• AI による免責事項：免責事項は、形式的に記載するだけでなく、内容として誠実でなければなりません。免責事項を記載しながら、実際の推薦を示唆する口調でプロフィールを書くことは、その趣旨に反します。プロフィールは「この人物が何を考えているか」ではなく、「AI がこの人物の視点をどのように近似できるか」と読める内容にしてください。
• 「チーム活動では名前付きメンバーのみ」：チーム活動には、振り返り、合意形成ラウンド、コードレビュー、およびチームメンバーの視点（単なる作業力ではなく）が重要となるあらゆるタスクが含まれます。バックグラウンド調査、ファイル操作、機械的なタスクでは、名前付きメンバーを必要としません。

ファクトリーモードでの合意形成については、テンプレートディレクトリにある CONSTRAINT-RESOLUTION.md を参照してください。

ファクトリーモード（任意）

pipeline スキルが ensemble-team と併せてインストールされている場合、コーディネーターはセットアップ時にこれを検出し、ファクトリーモードを有効にします。これにより、チーム編成後、ビルドフェーズの前にフェーズ 1.5（「ファクトリーモードの設定」）が追加されます。

ファクトリーモードでは、コーディネーターはビルドフェーズ全体を直接管理せず、パイプラインコントローラーに委任します。パイプラインは、スライスのキュー投入、TDD ペアのディスパッチ、コードレビューの進行管理、品質ゲートを通じたマージ判断を担います。プッシュ前には、引き続きチーム全体でレビューを行います。

コーディネーターの引き継ぎの詳細については、references/factory-mode.md を参照してください。

ファクトリーモードと監督モード

• 監督モード（デフォルト）：コーディネーターがビルドフェーズを管理します。すべての判断でロバート議事規則の合意形成プロトコルを使用します。コーディネーターはドライバーの交代、レビューサイクル、振り返りを進行します。
• ファクトリーモード（pipeline がインストールされている場合）：パイプラインがビルドフェーズを管理します。ビルド時の判断では、合意形成の代わりに品質ゲートを使用します。コーディネーターは計画、ファクトリー設定、ビルド後のレビューで引き続き活動します。プッシュ前レビューと振り返りには、これまでどおりチーム全体が参加します。