Agents Reference: Orchestrators & Cross-Cutting

Language: English | 日本語 Last updated: 2026-05-30 Update history:

2026-05-30: analyst チェーン spawn コントラクト + legacy-resume injection-only mode を文書化 (#141)

2026-04-30: doc-flow を第 5 のフローとして追加 (#54)

2026-04-30: Add doc-reviewer (Quality Agents) per #91

2026-04-26: Sync with #62, #66, #72, #74 (issue #77)

2026-04-25: terminology rebalance per #40 EN canonical: 2026-05-30 of wiki/en/Agents-Orchestrators.md Audience: エージェント開発者

このページはもとの Agents-Reference.md を 6 ページに分割したもの（#42）です。Flow Orchestrator（フローオーケストレーター）、セーフティエージェント、品質エージェント、スタンドアロンエージェント（横断系エージェント）を扱います。ドメイン別エージェントは関連ページを参照してください: Discovery、Delivery、Operations、Maintenance、Doc。

注意: doc-flow が起動する 6 種の author エージェントは Doc Domain ページに記載しています。

Flow Orchestrator

Flow Orchestrator はドメイン全体を管理します。トリアージで選択されるエージェントではなく、セッションエントリーポイントです。

discovery-flow

正規: .claude/agents/discovery-flow.md
ドメイン: Flow Orchestrator（Discovery）
責務: 要件探索フロー全体を管理します。トリアージの実行、エージェントの順次起動、承認とロールバックの処理を担い、最終成果物として DISCOVERY_RESULT.md を生成します。
入力: ユーザーのプロジェクト説明（コマンド引数経由）
出力: DISCOVERY_RESULT.md（最終ハンドオフ）、INTERVIEW_RESULT.md、RESEARCH_RESULT.md、POC_RESULT.md、CONCEPT_VALIDATION.md、SCOPE_PLAN.md
AGENT_RESTULTフィールド: N/A（Flow Orchestrator は AGENT_RESULT を出力しない；ハンドオフファイルを生成する）
NEXT条件: 完了後、ユーザーに/delivery-flowの実行を促す

delivery-flow

正規: .claude/agents/delivery-flow.md
ドメイン: Flow Orchestrator（Delivery）
責務: 設計・実装・テスト・レビューフロー全体を管理します。DISCOVERY_RESULT.md を読み込んでトリアージを実行し、テスト/レビュー失敗時のロールバックを処理したうえで、DELIVERY_RESULT.md を生成します。
入力: DISCOVERY_RESULT.md（オプション）、既存のSPEC.md / ARCHITECTURE.md
出力: DELIVERY_RESULT.md（最終ハンドオフ）、SPEC.md、ARCHITECTURE.md、実装コード、TEST_PLAN.md、SECURITY_AUDIT.md、README.md
AGENT_RESTULTフィールド: N/A
NEXT条件: 完了後、ユーザーに/operations-flowの実行を促す（serviceの場合）

operations-flow

正規: .claude/agents/operations-flow.md
ドメイン: Flow Orchestrator（Operations）
責務: デプロイと運用フローを管理します。PRODUCT_TYPE: serviceの場合のみ実行。DELIVERY_RESULT.mdを読み込み、トリアージを実行し、OPS_RESULT.mdを生成します。
入力: DELIVERY_RESULT.md（必須）、ARCHITECTURE.md、SPEC.md
出力: OPS_RESULT.md、Dockerfile、docker-compose.yml、CI/CDパイプライン、DB_OPS.md、OBSERVABILITY.md、OPS_PLAN.md
AGENT_RESTULTフィールド: N/A
NEXT条件: フロー完了（ユーザーがデプロイを処理）

maintenance-flow

正規: .claude/agents/maintenance-flow.md
ドメイン: Flow Orchestrator（Maintenance — 第 4 のフロー）
責務: 既存プロジェクトの保守ライフサイクルを管理します。トリガー (バグ / CVE / パフォーマンス / 技術的負債 / 機能追加) を受け取り、change-classifier で Patch / Minor / Major のトリアージを行い、対応するエージェントを順次起動します。Patch と Minor は単独完結、Major は MAINTENANCE_RESULT.md を生成して delivery-flow に引き渡します。
入力: ユーザーが指定するトリガー情報 (ログエラー / CVE 通知 / 機能要望等)、SPEC.md、ARCHITECTURE.md
出力: GitHub issue、PR、テスト結果。Major のみ MAINTENANCE_RESULT.md を生成
AGENT_RESTULTフィールド: Patch/Minor は N/A (PR + issue で報告)。Major のみ: PLAN、MAINTENANCE_RESULT、HANDOFF_TO
NEXT 条件:
- Patch / Minor 完了 → done
- Major 完了 → delivery-flow (ユーザーが MAINTENANCE_RESULT.md を確認後に /delivery-flow を手動実行)

doc-flow

正規: .claude/agents/doc-flow.md
ドメイン: Flow Orchestrator（Doc — 第 5 のフロー）
責務: 既存の Aphelion 成果物（SPEC.md、ARCHITECTURE.md 等）から顧客向け納品ドキュメント（HLD / LLD / API リファレンス / 運用マニュアル / ユーザーマニュアル / 引継ぎ資料）を生成します。doc type ベースのトリアージを実施し、6 種の author エージェントをユーザー承認ゲートとともに順番に起動し、DOC_FLOW_RESULT.md を生成します。他のフローからの自動連鎖はなく、SPEC.md と ARCHITECTURE.md が揃った任意のタイミングでユーザーが /doc-flow で起動します。
入力: SPEC.md、ARCHITECTURE.md（および任意で DISCOVERY_RESULT.md、UI_SPEC.md、インフラ成果物、OPS_RESULT.md）; 引数 --types、--lang、--slug、--target-project
出力: DOC_FLOW_RESULT.md、docs/deliverables/{slug}/*.md（選択した doc type 1 つにつき 1 ファイル）
AGENT_RESULT フィールド: STATUS、SLUG、OUTPUT_LANG、GENERATED_DELIVERABLES、SKIPPED_TYPES、TEMPLATE_VERSIONS、SUGGEST_DOC_REVIEW
NEXT 条件:
- 選択した全 doc type 完了 → done
- author エージェントが blocked（テンプレート major バンプ）→ AskUserQuestion で上書き / バックアップ / 中断を確認
トリアージ: doc type 数ベース（Minimal/Light/Standard/Full とは異なる）:
- Minimal: 1〜2 doc type 選択
- Light: 3〜4 doc type 選択
- Standard: 5〜6 doc type 選択
- Full: 全 6 種 + 生成後の template_version 整合検証
Author エージェント: 6 種の author エージェントの詳細は Agents Reference: Doc Domain を参照（hld-author、lld-author、api-reference-author、ops-manual-author、user-manual-author、handover-author）
スラッシュコマンド: /doc-flow（引数仕様は .claude/commands/doc-flow.md を参照）

セーフティエージェント

これらのエージェントは他のエージェント全体にセーフティポリシーを適用します。Flow Orchestrator から自動的に挿入されることも、Bash を持つ任意のエージェントから明示的に委譲されることもあります。

sandbox-runner

正規: .claude/agents/sandbox-runner.md
ドメイン: セーフティ（横断的）
責務: 最も強力な利用可能な隔離を使って高リスクコマンドを実行します。まず container モード（devcontainer + Docker）を試み、利用不可の場合はプラットフォームのパーミッション制御にフォールバックします。sandbox-policy.mdに照らしてコマンドを再分類し、フォールバック理由を含む完全な監査証跡を返します。
入力: command、working_directory、timeout_sec、risk_hint、allow_network、allow_write_paths、dry_run、reason、caller_agent
出力: stdout、stderr、exit_code、sandbox_mode、detected_risks、decision、fallback_reason、notes
実行経路選択（Workflowの Step 2）:
1. リポジトリ内の .devcontainer/devcontainer.json の存在確認
2. 5秒タイムアウトで docker info 実行
3. 両方 OK → container モード（ワーキングディレクトリのみマウント；既定 --network=none；ホスト環境変数なし）
4. いずれかNG → FALLBACK_REASON を記録して platform_permission にフォールバック
AGENT_RESTULTフィールド: STATUS、SANDBOX_MODE、EXIT_CODE、DETECTED_RISKS、DECISION、CALLER、DURATION_MS、FALLBACK_REASON（container モード成功時は省略）
NEXT条件:
- 別エージェントから呼び出された場合 → 呼び出し元エージェントに返る
- ユーザーがスタンドアロンで起動した場合 → done
- セッション中断 → suspended

品質エージェント

これらのエージェントは他のエージェントの成果物に対して品質ゲートを適用します。Flow Orchestrator が特定フェーズ完了直後に自動挿入（post-insert）するため、生成元のエージェントが直接呼び出すことはありません。

doc-reviewer

正規: .claude/agents/doc-reviewer.md
ドメイン: 品質（横断的）
責務: マークダウン成果物（SPEC.md / ARCHITECTURE.md / UI_SPEC.md / docs/design-notes/、DISCOVERY_RESULT.md）の文書間整合性をレビューします。Flow Orchestrator が spec-designer / architect / ux-designer / scope-planner / analyst の各完了直後に自動挿入（post-insert）します。生成元エージェントから独立したコンテキストで動作。読み取り専用 — ファイルの生成・更新は行わず、テキストレポートのみを返します。
入力: 直前フェーズの対象成果物 + それが依存する上流成果物（例: ARCHITECTURE.md レビュー時は SPEC.md も読む）。TRIGGERED_BY フィールドで上流エージェントを識別。
出力: severity 付き findings のテキストレポート（🔴 DR / 🟡 DA / 🟢 DI）。ファイル成果物なし。
5つの観点: coverage / naming / scope / version / acceptance
AGENT_RESULT フィールド: STATUS、DOC_REVIEW_RESULT（pass | fail | conditional）、INCONSISTENCY_COUNT、TRIGGERED_BY、REVIEWED_FILES、FINDINGS、NEXT
NEXT 条件:
- DOC_REVIEW_RESULT: pass → 次フェーズ
- DOC_REVIEW_RESULT: fail → 上流エージェントへ rollback（orchestrator-rules.md の Rollback Limit Common に従い max 3 回）。上限超過時は approval gate で「Approve despite findings」を提示
プランティア:
- delivery-flow: 全プランで必須（spec-designer / architect / ux-designer の後）
- discovery-flow: scope-planner 完了後で必須。Minimal では scope-planner が走らないため skip。
- maintenance-flow: 条件付き auto — analyst.DOCS_UPDATED に SPEC.md 差分が含まれる場合のみ実行（Patch かつ SPEC 変更なしなら skip）

スタンドアロンエージェント

これらのエージェントはトリアージシステムの外で動作します。analyst はユーザーが直接起動し、codebase-analyzer もスタンドアロンです。

analyst チェーンは 3 ファイルで構成されます: トップレベルオーケストレーター（analyst）と 2 つのサブエージェント（analyst-intake、analyst-core）で、内部的にチェーンされます。ユーザーは /analyst のみを起動します。

analyst（トップレベルオーケストレーター）

正規: .claude/agents/analyst.md
ドメイン: スタンドアロン（トップレベルオーケストレーター、/analyst スラッシュコマンドのみで起動）
モデル: Sonnet
責務: analyst チェーンのトップレベルオーケストレーター。Agent tool を使って analyst-intake → analyst-core をチェーンします。既存の planning doc を 3 つの resume ケース（post-Pattern-B resume / legacy resume / fresh）で検出します。ファイル書き込みや git 操作は行わず、オーケストレーションのみを担当。
入力: ユーザーの課題説明（/analyst コマンド経由）
出力: analyst-core の AGENT_RESULT をパススルー（後方互換のため agent-name を analyst に書き換え）
NEXT条件: architect（デフォルト）| developer

サブエージェント spawn コントラクト（重要）: analyst.md は Agent tool に依存しており、この tool はトップレベルセッション限定です。 Flow Orchestrator やメインセッションは Agent(subagent_type="analyst") で analyst を起動してはなりません。プログラム的に呼び出す場合の正しいパターン:

analyst-intake を直接起動（レガシー doc を resume する場合は legacy_planning_doc + existing_issue_url + existing_issue_number を渡す）。
analyst-intake の AGENT_RESULT から HANDOFF_PAYLOAD を受け取る。
その HANDOFF_PAYLOAD をプロンプトとして analyst-core を起動する。

このパターンは fresh / post-Pattern-B resume / legacy resume の全ケースに適用されます。

Resume 検出（3 ケース）:

post-Pattern-B resume: planning doc が存在し  ブロックがある → 解析した YAML で analyst-core を直接起動。
legacy resume: planning doc が存在し handoff ブロックがなく > GitHub Issue: 行がある → injection-only mode で analyst-intake を起動（下記参照）。
fresh: 一致する planning doc なし → 通常通り analyst-intake を起動。

analyst-intake

正規: .claude/agents/analyst-intake.md
ドメイン: スタンドアロン（サブエージェント; analyst オーケストレーターまたは flow orchestrator から起動）
モデル: Sonnet
責務: 構造化インテイクフェーズ（Steps A–D）。AskUserQuestion で最小限の情報を収集し、resume 検出用の  YAML を埋め込んだ planning doc §1-4 スタブを作成し、GitHub イシューを作成し、ワークブランチの初回コミットを行います。呼び出し元が analyst-core に転送するための HANDOFF_PAYLOAD を発行します。レガシー doc の resume 用に injection-only mode もサポートしています（下記参照）。
入力: ユーザーの課題説明、既存の SPEC.md / ARCHITECTURE.md / UI_SPEC.md。injection-only mode では: legacy_planning_doc、existing_issue_url、existing_issue_number。
出力: docs/design-notes/<slug>.md（§1-4 スタブと handoff YAML、またはレガシー doc への注入ブロック）、GitHub イシュー（初期本文; injection-only mode ではスキップ）、ワークブランチのコミット
AGENT_RESULTフィールド: HANDOFF_PAYLOAD（13 フィールドの YAML）、BRANCH、GITHUB_ISSUE、ARTIFACT_PATHS
NEXT条件: analyst-core（呼び出し元経由）

injection-only mode: 呼び出し元のプロンプトに legacy_planning_doc + existing_issue_url + existing_issue_number が揃っている場合にトリガーされます。このモードでは:

スキップ: インテイク AskUserQuestion（Steps A-B）、gh issue create（Step D）、proposals/ プロモーション。
実行: 既存 planning doc を読み込み →  ブロックを注入（既存コンテンツと渡された issue パラメーターから 13 フィールドを構築）→ 現在ブランチに関わらず main からワークブランチを作成（B3 修正）→ 注入したブロックをコミット → push → HANDOFF_PAYLOAD を発行。
HANDOFF_PAYLOAD の 13 フィールドスキーマは fresh mode と同一（スキーマ変更なし）。

analyst-core

正規: .claude/agents/analyst-core.md
ドメイン: スタンドアロン（サブエージェント; analyst オーケストレーターまたは flow orchestrator から起動）
モデル: Opus
責務: 深掘り分析フェーズ（Steps 1–5）。handoff payload を検証し、課題を分類し、完全な分析を実行し、ユーザー承認を要求し、SPEC.md / UI_SPEC.md をインクリメンタルに更新し（必要な場合）、GitHub イシュー本文を精製し、planning doc §5-8 を記述し、最終状態をコミットします。
入力: HANDOFF_PAYLOAD YAML（analyst-intake からの 13 フィールド、spawn プロンプト経由）
出力: docs/design-notes/<slug>.md（§5-8 追記）、更新された SPEC.md / UI_SPEC.md（インクリメンタル）、GitHub イシュー本文（gh issue edit で精製）、最終コミット
AGENT_RESULTフィールド: ISSUE_TYPE、ISSUE_SUMMARY、DOCS_UPDATED、GITHUB_ISSUE、HANDOFF_TO、ARCHITECT_BRIEF
NEXT条件: architect（デフォルト）| developer

codebase-analyzer

正規: .claude/agents/codebase-analyzer.md
ドメイン: スタンドアロン
責務: ドキュメントがない既存コードベースからSPEC.mdとARCHITECTURE.mdをリバースエンジニアリングします。analyst → delivery-flowを通じてプロジェクトが標準Aphelionワークフローに参加できるようにします。
入力: 既存コードベース（作業ディレクトリ内のソースファイル）
出力: SPEC.md、ARCHITECTURE.md（リバースエンジニアリング）
AGENT_RESTULTフィールド: HAS_UI、PRODUCT_TYPE、LANGUAGE、FRAMEWORK、UC_COUNT、ENTITY_COUNT、TBD_COUNT
NEXT条件: done（ユーザーが/analystまたは/delivery-flowを実行）

正規ソース

.claude/agents/ — エージェント定義ファイル全体（権威あるソース）
.claude/orchestrator-rules.md — Flow Orchestrator ルールとトリアージ