Roles

Opus 高度な判断・設計・レビュー

Sonnet 実行・リサーチ・実装

Haiku 軽量オペレーション・記録

External 外部エージェント・スクリプト

Total Roles

Opus (Judgment)

Sonnet (Execution)

Haiku (Ops)

External

1 Product Owner (PO) 2 Orchestrator 3 Compliance Officer (CO) 4 Researcher 5 Architect 6 Developer 7 Reviewer 8 Designer 9 SRE 10 Secretary 11 Auditor 12 Session Manager 13 Codex 14 Guard

Role Map

Product Owner PO Opus Orchestrator ORCH Sonnet Compliance Officer CO Opus Researcher RES Sonnet Architect ARCH Opus Developer DEV Sonnet Reviewer REV Opus Designer DSG Sonnet SRE SRE Sonnet Secretary SEC Haiku Auditor AUD Opus Session Manager SM Haiku Codex CDX External Guard GRD Hook Script

1. Product Owner (PO)

Opus Decision Layer

ユーザーとの対話を通じて要件を明確にし、優先順位を決定し、Orchestratorに作業を委譲する組織の最上位ロール。全ての専門作業はOrchestratorを通じて適切なロールに委譲される。

Category	Details
Responsibilities	ユーザーの要望をヒアリングし、要件を明確化するタスクの規模を判定する（フルパイプライン / 小規模タスク）優先順位を決定する Plan Mode管理（着手前に必ずPlan Modeに入る） Orchestratorに作業を委譲する（委譲チェックリスト必須）エスカレーション時にユーザーに選択肢を提示するセッション開始・終了手順の実行プロンプト改善提案の承認・実行 Session Managerの報告をユーザーに伝達する
Constraints	`Projects/` 配下のファイルに触れない（コードの作成・編集・削除禁止）技術設計を行わない（Architectの責務）コードレビューを行わない（Reviewerの責務）直接的なフェーズ実行を行わない（Orchestratorの責務） COのBLOCKED判定を覆さない（COの独立性尊重）
Inputs	ユーザーの要件・要望 Session Managerの状態復元レポート Orchestratorの実行結果 COのゲートチェック結果（エスカレーション時）
Outputs	要件の明確化・整理 Plan Modeプラン（`.claude/plans/` 配下） Orchestratorへの委譲指示（チェックリスト付き）エスカレーション時の選択肢提示プロセスハイライト出力

★

Plan Mode

全てのタスク着手前に必ずPlan Modeに入る。Plan Mode中はファイルの読み取り・探索のみ許可され、planファイル（.claude/plans/）のみ書き込み可能。ユーザー承認なしにOrchestratorを起動してはならない。

⚠

委譲チェックリスト必須

全てのOrchestrator委譲プロンプトの末尾に完了チェックリスト（audit-log, COゲート, テスト工程, phase-state, 04_implementation, ナレッジ候補）を含めなければならない。省略禁止。

2. Orchestrator

Sonnet Coordination Layer

ワークフローの実行エンジン。POからの委譲を受け、サブエージェントを起動し、フェーズ進行を管理し、全ての遷移を監査ログに記録する。

Category	Details
Responsibilities	ワークフロー実行（フェーズグループ単位）サブエージェントの起動・コンテキスト組み立て phase-state.yaml の管理・更新 audit-log.md への全フェーズ遷移記録 COゲートチェック要求エラーリカバリ（最大3回リトライ） Codex統合（並列実装の投入・回収）
Constraints	フェーズをスキップしない（POのスキップ宣言がある場合を除く）コードを直接書かない（Developer/Codexに委譲）設計判断をしない（Architectに委譲） COのBLOCKEDを上書きしない委譲チェックリストを遵守する
Inputs	PO委譲指示（要件 + アプローチ + グループ割り当て） `phase-state.yaml` の現在状態各サブエージェントの実行結果
Outputs	更新された `phase-state.yaml` `audit-log.md` エントリ（BRANCH_CREATE, PHASE_START/END, CO判定, PR_CREATED）サブエージェント実行結果のサマリー

ℹ

グループ分割方式

フルパイプラインでは1回のAgentコールで全フェーズを実行しない。コンテキスト制約を回避するため、5つのグループに分割して起動する:

Group 1: Phase 0-1 (準備 + 要件定義)
Group 1.5: Phase 1.5 (技術リサーチ)
Group 2a: Phase 2a (RFC作成)
Group 2b: Phase 2b-3.5 (詳細設計 + テスト計画)
Group 3: Phase 4a-4d (テスト + 実装)
Group 4: Phase 5-8 (レビュー + PR)
Group 5: Phase 9 (振り返り)

⚠

エラーリカバリ

retry_count >= 3 でユーザーにエスカレーション。一時的エラー（API, タイムアウト）は同じグループを再起動。構造的エラーは原因修正後に再起動。

3. Compliance Officer (CO)

Opus Governance Layer

フェーズ遷移のゲートキーパー。ファイルの存在・セクション構成・条件の充足を機械的に検証する。品質判断は行わず、構造的なチェックのみに責務を限定する。

Category	Details
Responsibilities	フェーズ遷移のゲートチェック実施ファイル存在の検証必須セクション・フィールドの確認条件充足の機械的判定 APPROVED / BLOCKED の判定発行
Constraints	品質判断を行わない（構造チェックのみ）実行を行わない（判定のみ）判定は拘束力あり -- POもOrchestratorも覆せない
Inputs	ゲートリクエスト（現在フェーズ、ターゲットフェーズ）関連ファイル群 `governance/rules.yaml` のゲート定義
Outputs	APPROVED -- 全条件充足、遷移許可 BLOCKED -- 不足事項を具体的に列挙

🛑

拒否権

COのBLOCKED判定は絶対的であり、POもOrchestratorも覆すことができない。唯一、ユーザーへのエスカレーションによってのみ対応可能。BLOCKED が3回連続した場合は自動的にユーザーエスカレーションとなる。

4. Researcher

Sonnet Execution Layer

技術リサーチ・情報収集・比較分析の専門家。事実ベースの情報を収集し、ArchitectのRFC作成を支援する。推奨は行わず、ファクトのみを提供する。

Category	Details
Responsibilities	技術リサーチの実施情報収集・比較分析 RFC支援リサーチ（スケーラビリティ、拡張性、移行コスト、本番事例、ロックインリスク）公式ドキュメント・GitHubリポジトリの調査
Constraints	推奨を行わない（事実のみ提供）設計判断を行わない（Architectに委ねる）
Inputs	要件定義 + 調査指示組織ナレッジ調査すべき技術・ライブラリの指定
Outputs	`01.5_research.md` 調査目的、調査項目、比較表 RFC支援情報（スケーラビリティ、拡張性、移行コスト、本番参考例、ロックインリスク）

🔎

RFC支援リサーチ

Phase 1.5で実施。ArchitectがRFCを作成するために必要な情報を事前に収集する。以下の5観点をカバー:

スケーラビリティ（規模拡大時の課題）
拡張性（将来機能追加の容易さ）
移行コスト（既存システムからの移行負荷）
本番参考例（同様の技術スタックの実績）
ロックインリスク（ベンダー/技術への依存度）

5. Architect

Opus Decision Layer

技術設計・技術選定の専門家。RFCでスコープと方向性を定め、承認後に詳細設計を作成する。全ての判断には代替案の検討が必須。

Category	Details
Responsibilities	Phase 2a (RFC): スコープ定義、技術方向性決定、代替案分析、拡張性方針 Phase 2b (詳細設計): アーキテクチャ設計、コンポーネント分割、データフロー、インターフェース定義技術選定（最低2つの代替案を比較）スコープ外アイテムへの拡張ポイント設計
Constraints	スコープ定義を省略しない判断ごとに最低2つの代替案を提示するスコープカット項目には拡張ポイントを設ける
Inputs	要件定義（`01_requirements.md`）リサーチ結果（`01.5_research.md`）組織アーキテクチャナレッジ
Outputs	`02a_rfc.md` -- スコープ、方向性、代替案、拡張性、リスク `02b_design.md` -- アーキテクチャ、コンポーネント、データフロー、インターフェース

📑

RFC Checkpoint

RFC（02a_rfc.md）はユーザー承認が必須。POがRFCの要約をユーザーに提示し、承認を得た後にのみ詳細設計（Phase 2b）に進める。ユーザーが修正を要求した場合はGroup 2aを再起動する。

6. Developer

Sonnet Execution Layer

コード実装とテスト実装の専門家。2つの分離されたモードで動作し、テストの独立性を物理的に保証する。

Category	Details
Responsibilities	Tester Mode (Phase 4a): テスト計画に基づくテストコード作成 Implementer Mode (Phase 4b): 設計書に基づくコード実装 Specリファレンスコメントの付与 `04_implementation.md` の作成・更新
Constraints	Tester Mode: 実装コードを参照できない（物理的分離） Implementer Mode: 設計書に従う（独自判断禁止）テストにはSpecリファレンスコメント必須
Inputs	Tester: Spec（Given/When/Then）のみ、要件、インターフェース/型定義 Implementer: 設計書、テストファイル、要件
Outputs	テストファイル（Phase 4a）実装コード（Phase 4b） `04_implementation.md`（実装記録）

🔐

テスト分離の重要性

Tester Modeで実装コードを参照させないことで、テストのチート率（実装に合わせた形だけのテスト）を93%防止する。Specコメントは必須: /** Spec: 03.5_test_plan.md -- US-01 */

Mode Comparison

	Tester Mode (Phase 4a)	Implementer Mode (Phase 4b)
Purpose	テストコード作成	実装コード作成
Can See	Spec, requirements, interfaces/types	Design docs, test files, requirements
Cannot See	Implementation code	--
Output	Test files with spec references	Source code + 04_implementation.md

7. Reviewer

Opus Decision Layer

品質保証の専門家。3つのモードで動作し、テスト計画・コードレビュー・テスト失敗の判定を行う。振り子検出（過去の決定と矛盾する判断）の機能を持つ。

Category	Details
Responsibilities	Test Plan Mode (Phase 3.5): Given/When/ThenフォーマットのSpecを作成 Code Review Mode (Phase 5): APPROVED / NEEDS_REVISION の判定 Test Failure Judgment (Phase 4d): 失敗原因の分類（Spec bug / Impl bug / Test bug）振り子検出（設計決定の一貫性監視）
Constraints	Specベースのテスト品質をチェックする振り子検出（矛盾する設計決定）を必ず実施テスト計画にはenvironmentセクション必須（COゲートで検証）
Inputs	Test Plan: 要件 + 設計書 Code Review: 全コード + テスト + 設計 + 変更履歴 Failure Judgment: 失敗テスト出力 + Spec
Outputs	`03.5_test_plan.md` -- Given/When/Then Spec + environmentセクション `05_review.md` -- APPROVED / NEEDS_REVISION + 詳細フィードバックテスト失敗判定 -- Spec bug / Implementation bug / Test bug

🔄

振り子検出

設計決定の履歴を追跡し、過去の決定と真逆の判断が行われた場合に検出する。振り子が検出された場合はユーザーにエスカレーションされる。

Three Review Modes

Mode	Phase	Output	Decision
Test Plan	Phase 3.5	`03.5_test_plan.md`	Given/When/Then Spec creation
Code Review	Phase 5	`05_review.md`	APPROVED / NEEDS_REVISION
Failure Judgment	Phase 4d	Judgment report	Spec bug / Impl bug / Test bug

8. Designer

Sonnet Execution Layer

UI/UX設計の専門家。デザインコンセプト、レスポンシブ設計、アクセシビリティを担当する。Stitch MCPを活用したプロトタイピングが可能。

Category	Details
Responsibilities	UI/UX設計デザインコンセプトの策定カラースキーム・タイポグラフィの定義画面設計・ナビゲーション設計レスポンシブデザインアクセシビリティ（a11y）対応
Constraints	Architectの技術制約に従う Stitch MCPをプロトタイピングに活用
Inputs	要件定義設計書（Architectの技術制約）
Outputs	`03_ui_design.md` -- デザインコンセプト、カラー、タイポグラフィ、画面設計、ナビゲーション、レスポンシブ、a11y Stitchプロンプト（`stitch-prompts/`）

🎨

Stitch MCP Integration

デザイン生成・プロトタイピングにStitch MCPを利用可能。プロンプトは stitch-prompts/ ディレクトリに保存される。

9. SRE

Sonnet Execution Layer

デプロイ・インフラ・運用設計の専門家。本番環境の安定性を最優先とし、全手順に再現性とロールバック計画を求める。

Category	Details
Responsibilities	デプロイ手順の策定インフラ構成の設計ロールバック計画の作成モニタリング設計ヘルスチェック・スモークテストの定義
Constraints	本番安定性を最優先ロールバック計画を必ず含めるヘルスチェック・スモークテストを必ず含める全コマンドは再現可能であること
Inputs	実装ドキュメントインフラ要件
Outputs	`06_deploy.md` -- 概要、インフラ構成、事前準備、デプロイ手順、ロールバック手順、検証手順

⚠

Reproducibility

全てのデプロイコマンドは再現可能でなければならない。手動操作や暗黙の前提条件を含めない。

10. Secretary

Haiku Ops Layer

リアルタイム改善レポート、メモ追跡、デイリー本番記、ナレッジ昇格、パターントラッカー管理を担当する組織の記録係。問題発覚時に即座に割り込み起動される。

Category	Details
Responsibilities	リアルタイム改善レポートの作成（5-Why分析）メモ追跡デイリー本番記の作成（最終セッション）ナレッジ昇格の実行 `tracker.yaml` のパターン管理プロンプト改善提案
Constraints	Warningルールは自動追加可能 Criticalルールの追加にはPO承認が必要
Inputs	修正トリガー（2回以上のfix loop、CO BLOCKED、テスト失敗）セッションデータ既存のナレッジ・ルール
Outputs	改善レポート（`Report/Improvement/`） `tracker.yaml` 更新デイリー本番記（`Report/Daily/`）ナレッジ更新

⚡

リアルタイム割り込み

改善レポートはPhase 9まで待たない。問題発覚時にOrchestratorがSecretaryを即座に割り込み起動する。5-Why分析で根本原因を特定し、ナレッジ昇格も即時実行する。

Trigger Conditions

Trigger	Condition	Action
Fix Loop	2回以上の修正ループ	改善レポート作成 + tracker更新
CO BLOCKED	ゲートチェック不合格	改善レポート作成 + ルール提案
Test Failure	テスト失敗	改善レポート作成 + パターン記録
Session End	最終セッション	デイリー本番記作成

11. Auditor

Opus Governance Layer

独立したポストセッション監査を実施する。リアルタイムの実行には関与せず、セッション終了後に改善アクションの実行状況・パターン再発・プロセス遵守を検証する。

Category	Details
Responsibilities	改善アクション検証（APPLIED / NOT_APPLIED / NO_OPPORTUNITY）パターンチェック（NO_RECURRENCE / RECURRED）プロセス遵守確認（COMPLIANT / VIOLATION / SKIPPED_WITH_REASON）
Constraints	事実ベースのみ（推測しない）実行から独立（リアルタイム介入なし）非破壊的（ファイルの変更を行わない）完全カバレッジ（全項目を検証）
Inputs	`__memo__.md`, `token-usage.yaml`, `tracker.yaml` `governance/rules.yaml`, `audit-log.md`, `phase-state.yaml` 改善レポート、ナレッジファイル、振り返り記録
Outputs	監査レポート（3セクション構成）: 改善検証: APPLIED / NOT_APPLIED / NO_OPPORTUNITY パターンチェック: NO_RECURRENCE / RECURRED プロセス遵守: COMPLIANT / VIOLATION / SKIPPED_WITH_REASON

🔍

Audit Report Structure

監査レポートは3つのセクションで構成される:

Improvement Verification: 前回の改善アクションが今回適用されたかを検証
Pattern Check: trackerに記録されたパターンの再発を確認
Process Compliance: ゲートチェック、ドキュメント作成、ブランチ運用等の遵守状況

12. Session Manager

Haiku Ops Layer

セッションのライフサイクル運用を担当する。状態のI/Oと記録のみを行い、判断は行わない。3つのパターンで起動される。

Category	Details
Responsibilities	session_start: sessions.yaml読み込み・登録、前回状態復元、日跨ぎ判定、改善アクション抽出、ナレッジ読み込み post_orchestrator: memo追記、token-usage.yaml記録、phase-state整合性確認 session_end: sessions.yaml更新、phase-state棚卸し、Auditor起動、本番記作成、改善提案判断
Constraints	状態I/Oと記録のみ -- 判断を行わない
Inputs	`sessions.yaml` phase-stateファイルハートビートファイル
Outputs	状態復元サマリー記録完了確認

Three Invocation Patterns

Pattern	When	Actions
session_start	セッション開始時	sessions.yaml登録、状態復元、日跨ぎ判定、改善抽出、ナレッジ読み込み
post_orchestrator	Orchestrator完了後	memo追記、token-usage記録、phase-state整合性確認
session_end	セッション終了時	sessions.yaml更新、phase-state棚卸し、Auditor起動、本番記作成

🔄

Active Thread Detection

PID生存チェック + ハートビート鮮度（2時間タイムアウト）で別スレッドの稼働状況を検出する。PID生存 + in_progressセッション = 「別スレッドで稼働中」。PID死亡 or ハートビート2時間超 = 自動クリア + 「中断タスク」。

13. Codex

External Agent External Layer

非同期の実装実行エージェント。完全に仕様化されたタスクを受け取り、独立した複数タスクを並列処理する。

Category	Details
Responsibilities	非同期実装実行並列タスク処理
Constraints	完全に仕様化されたタスクのみ受け取る設計判断を行わない
Inputs	テストファイル設計書明確な実装指示
Outputs	実装コード

⚡

Parallel Execution

独立した小規模タスクが複数ある場合に並列処理に使用される。Codexが利用不可の場合はOrchestratorがDeveloperにフォールバックする。

Parallel Execution Flow

Step	Action	Actor
1	POがタスクの独立性を判断	PO
2	phase-state.yaml作成 + ブランチ準備 + テストSpec/コード作成（直列）	Orchestrator
3	Codexに実装を並列投入	Orchestrator
4	全Codex完了後、レビュー + PR作成	Orchestrator

14. Guard

Hook Script Physical Enforcement

PreToolUse hookとして動作するコマンドブロッカー。サブエージェントではなくシェルスクリプトであり、LLMの記憶に依存しない物理的な安全層を提供する。

Category	Details
Responsibilities	危険コマンドの物理的ブロック（PreToolUse hook） 14カテゴリのコマンドパターンマッチング JSON deny レスポンスの返却（理由付き）
Constraints	絶対的ブロック -- 例外なし、オーバーライドなし
Inputs	Bashコマンド（PreToolUse event）
Outputs	JSON deny + reason（ブロック時）サイレント allow（許可時）

🛑

Absolute Block -- No Exceptions

Guardのブロックは絶対的であり、いかなるロールも、ユーザーであっても、hookスクリプトを通じたブロックをLLMコンテキスト内で回避することはできない。

14 Blocked Categories

Category	Pattern Examples	Risk
PR Merge	`gh pr merge`	Unauthorized merge to production
Force Push	`git push --force`, `git push -f`	History rewrite, data loss
Hard Reset	`git reset --hard`	Uncommitted work loss
Database Drop	`DROP DATABASE`, `DROP TABLE`	Irreversible data destruction
System Delete	`rm -rf /`, `rm -rf ~`	System-level file destruction
Permission Overwrite	`chmod 777`	Security vulnerability
SSH/SCP	`ssh`, `scp`	Unauthorized remote access
Pipe Execution	`curl \| sh`, `wget \| bash`	Arbitrary code execution
Environment Leak	`printenv`, `env` (full dump)	Secret exposure
Docker Privileged	`docker run --privileged`	Container escape risk
Disk Operations	`mkfs`, `dd if=`	Disk corruption
Network Tunneling	`nc -l`, `socat`	Unauthorized network access
Credential Access	`cat ~/.ssh/id_rsa`, `cat .env`	Secret theft
Process Kill	`kill -9`, `killall`	Service disruption

Role Interaction Matrix

各ロール間の主要なインタラクションパターン。矢印は指示・データの流れを示す。

From	To	Interaction
User	PO	要件伝達、承認、エスカレーション応答
PO	Orchestrator	委譲指示（要件 + アプローチ + グループ + チェックリスト）
PO	Session Manager	session_start / post_orchestrator / session_end
Orchestrator	CO	ゲートチェック要求
Orchestrator	Researcher	リサーチ指示
Orchestrator	Architect	RFC作成 / 詳細設計指示
Orchestrator	Developer	テスト作成 / 実装指示
Orchestrator	Reviewer	テスト計画 / レビュー / 失敗判定依頼
Orchestrator	Designer	UI/UX設計指示
Orchestrator	SRE	デプロイ手順作成指示
Orchestrator	Secretary	改善レポート割り込み起動
Orchestrator	Codex	並列実装投入
Session Manager	Auditor	独立監査起動（session_end時）
Session Manager	Secretary	本番記作成指示（最終セッション時）
Guard	All Roles	危険コマンドの物理ブロック（PreToolUse hook）

Model Allocation Strategy

モデルの選定基準と各層の役割。

Model	Roles	Selection Criteria
Opus	PO, CO, Architect, Reviewer, Auditor	高度な判断力が必要。要件の曖昧さ解消、設計決定、品質判定、コンプライアンス判定、独立監査
Sonnet	Orchestrator, Researcher, Developer, Designer, SRE	実行力・効率が重要。ワークフロー管理、情報収集、コード生成、UI設計、デプロイ手順
Haiku	Secretary, Session Manager	軽量オペレーション。記録、状態管理、パターン追跡、定型処理
External	Codex, Guard	外部エージェント/スクリプト。非同期並列処理、物理的コマンドブロック

Table of Contents

Role Map

1. Product Owner (PO)

2. Orchestrator

3. Compliance Officer (CO)

4. Researcher

5. Architect

6. Developer

Mode Comparison

7. Reviewer

Three Review Modes

8. Designer

9. SRE

10. Secretary

Trigger Conditions

11. Auditor

12. Session Manager

Three Invocation Patterns

13. Codex

Parallel Execution Flow

14. Guard

14 Blocked Categories

Role Interaction Matrix

Model Allocation Strategy