Chorus プラグインを接続すると、[AI-DLC ワークフロー](/ja/guides/ai-dlc-workflow/)で既におなじみの ワークフローに、いくつかの挙動が上乗せされます。適切なタイミングで独立したレビューを促し、手作業で管理しなくても エージェントのセッションを追跡し、無人のエージェントができることを制約します。このページではそれらの挙動を 説明します。ライフサイクルの各段階や、ランタイムのインストール・起動・復旧の方法は繰り返しません。それらは それぞれ [AI-DLC ワークフロー](/ja/guides/ai-dlc-workflow/)、 [Chorus デーモンを運用する](/ja/guides/daemon-operations/)、 [セッションを中断して再開する](/ja/guides/session-recovery/)、そして [エージェントプラットフォーム](/ja/reference/agents/)を参照してください。 ## レビュー担当サブエージェント プラグインは、パイプラインの 3 つの節目に独立した品質ゲートを加えます。各節目で `PostToolUse` フックが 発火し、**メインエージェント**に専用の**読み取り専用のレビュー担当サブエージェント**の起動を促す リマインダーを注入します。レビュー担当は**自動では起動しません**。メインエージェントが起動し、実行環境の 完了待機機構で待ってから、今回の裁定コメントを読みます。完了したレビューは `PASS`、`PASS WITH NOTES`、 または `FAIL` の裁定を投稿します。 - `PASS` / `PASS WITH NOTES` — 作業は続行します。メモは参考情報です。 - `FAIL` — 列挙されたブロッカーを修正し、作業を再提出してからでないと先に進めません。 レビュー担当は作業を変更せず、検査します。Proposal reviewer は `ls`、`rg`、`find`、`git log/show/diff` などの読み取り専用シェルコマンドを使えます。パスが存在しないと報告する前に、必ず確認します。ファイル変更、 Git の書き込み操作、依存関係のインストール、テスト/ビルドの実行は禁止です。Task reviewer と code reviewer は さらに、プロジェクト自身のテスト・ビルド・lint コマンドも実行できます。これは Kiro を含むすべての環境で 同じで、Kiro ではブロックするコマンドの一覧によって、ファイル変更、Git の書き込み、インストールが止められます。 | レビュー担当 | 発火のタイミング | レビュー対象 | 裁定の投稿先 | | --- | --- | --- | --- | | Proposal reviewer | `chorus_pm_submit_proposal` の後 | 文書の完全性、課題の粒度、受け入れ基準との対応、そして依存グラフ | 提案 | | Task reviewer | `chorus_submit_for_verify` の後 | その課題の実装が受け入れ基準と提案文書を満たしているか。加えて、どの受け入れ基準も触れていない場合にも適用される既定の品質チェック：正しさ、既存のものの再実装、その課題自身のコードにあるセキュリティホール、失敗しえないテスト、必須の操作の失敗が黙って握りつぶされていないか | 課題 | | Code reviewer | 着想を根とする提案の最後の課題が検証されたとき（`chorus_admin_verify_task`） | その着想の全課題にわたる**集約**的な変更 — 課題間の統合、アーキテクチャの逸脱、セキュリティ、リグレッション、機能レベルのカバレッジ | 着想 | Code reviewer は出荷前の最終ゲートです。着想を根とする提案の*最後の*課題が検証されたときにのみ実行され、 単一の課題ではなく機能全体を一度にレビューします。 ### ラウンドをまたいで指摘を追う すべての指摘には安定した ID が付きます。ブロッカーは `B-`、メモは `N-` で、 round はその指摘を最初に報告したラウンドです（例：`B1-ac3-not-implemented`）。ID は変わらないので、 ラウンド 3 の裁定に `B1-…` の行があれば、その問題が 2 回の修正を経ても残っていることがわかります。 ラウンド 2 以降、レビュー担当は過去の指摘をすべて **Prior findings** の下に列挙し、`fixed`、`still-open`、 `not-verifiable` の 3 つの状態のいずれかと、判断のために何を再実行したかを添えます。指摘を閉じるのは `fixed` だけです。未解決のまま、*または*再検証できなかったブロッカーがあれば、裁定は `FAIL` のままです。 未解決のメモがあっても、裁定が `PASS WITH NOTES` より悪くなることはありません。 裁定に長さの上限はなく、ブロッカーの根拠は省略せずに書きます。その代わり、最初のラウンドで報告する メモは最大 5 件で、以降のラウンドでは新しいメモを加えません。こうして各コメントは、対応が必要なことに 絞られます。 ### 今回の裁定を待つ Claude Code ではレビュー担当の完了通知を待ちます。フォアグラウンド起動を要求しても、起動結果は裁定では ありません。Codex ではネイティブの起動・待機機構を使います。Pi 同梱の `subagent` ツールはレビュー担当が 戻るまでブロックします。どの環境でも、過去のラウンドではなく、**今回の起動後**に投稿された `VERDICT:` コメントを読んでください。 新しい裁定がなければ、無応答と明示的な引き継ぎを区別します。 - **明示的なレビュー拒否やラウンド上限の通知**：停止し、人間の判断に委ねます。再起動や自己レビューで この引き継ぎを置き換えてはいけません。 - **まったく応答がない場合**：1 回だけ再試行します。再試行でも明示的な拒否がないか確認します。2 回目も 完全に無応答の場合に限り、メインエージェントが読み取り専用の自己レビューを行い、裁定を投稿できます。 無応答を合格と扱ってはいけません。 ### 元の意図との整合性を確認する 3 つのレビュー担当は、元の着想の本文、人間が回答した要件詳細化、人間が書いたコメントとも照合します。 エージェントのコメントやエージェントが回答した要件詳細化は監査用の文脈であり、スコープ変更の承認にはなりません。 スコープの追加、要件の欠落、受け入れ基準には合格しても元の要件を満たさない変更は、人間のコメント・回答や 明示的な上書き判断を引用して承認を示せない限り、ブロッカーです。Proposal reviewer は計画、task reviewer は 実装、code reviewer は機能全体を確認します。 ### レビュー担当をオン・オフする これらのレビュー担当は、プラグインのインストールや設定時に調整できる `userConfig` 設定で制御されます。 各レビュー担当にはオン/オフのトグル（すべて既定で**オン**）と、人間へエスカレーションする前に「レビュー・ 修正」ループを何回まで走らせるかを制限する最大ラウンド上限があります。 | 設定項目 | 型 | 既定値 | 効果 | | --- | --- | --- | --- | | `enableProposalReviewer` | boolean | `true` | 提案の提出後に proposal reviewer の起動を促す | | `enableTaskReviewer` | boolean | `true` | 課題を検証に提出した後に task reviewer の起動を促す | | `enableCodeReviewer` | boolean | `true` | 着想の最後の課題が検証された後に code reviewer の起動を促す | | `maxProposalReviewRounds` | number | `3` | 人間へエスカレーションする前の最大提案レビュー・修正ラウンド数（`0` = 無制限） | | `maxTaskReviewRounds` | number | `3` | エスカレーション前の最大課題レビューラウンド数（`0` = 無制限） | | `maxCodeReviewRounds` | number | `3` | エスカレーション前の最大コードレビューラウンド数（`0` = 無制限） | あるレビュー担当をオフにすると、その独立した品質チェックは失われますが、トークン消費は減ります。 別の `enableOpenSpec` トグルが OpenSpec モードを制御しますが、これは専用のページで扱います。 :::caution[Claude Code 限定なのはトグル設定だけ] Claude Code と Codex はどちらも 3 つのレビュー担当すべてを搭載し、同じ 3 つのレビューの促しを発火します。 Claude Code 限定なのは `userConfig` の**トグル設定**、つまり上表の `enable*` スイッチとラウンド上限の設定です。 Codex には `userConfig` がないため、Codex 上ではこれらのレビュー担当はインストール時のトグルではなく、 スキルとフックが直接制御します。下記の[Codex の違い](#codex-の違い)を参照してください。トグルの違いを、 どのレビュー担当が存在するかの違いと読み違えないでください。 ::: ## セッションライフサイクルフック 2 つ目のフック群は、エージェントの Chorus **セッション**を自動的に管理します。そのため、あなたも エージェントも、セッションを手作業で開いたり、ハートビートを送ったり、閉じたりする必要はありません。 これらは判断も促しも伴わず、自動的に動作します。 - **`SessionStart`** — 接続性をチェックし、エージェントをチェックインし、プラグインが事前に作成した セッションがあれば見つけ出します。 - **`SubagentStart`** — ワーカーの開始前に、そのワーカーのエージェントの種類にちなんだ名前の Chorus セッションを作成または再利用します。同じ種類のワーカーはセッションを共有できます。 - **`SubagentStop`** — 終了するワーカーによるセッションの保持を解除します。課題の自動チェックアウト、セッションのクローズ、条件を満たす場合の自動検証は、そのセッションを共有する最後のワーカーが終了するまで待ってから行われます。 - **ハートビートとリマインダー** — 待機中のワーカーはハートビートを送り、長時間の実行中にセッションが 非アクティブと見なされないようにします。`PostToolUse` リマインダーは、上記のレビューの節目で メインエージェントを促します。 これらのフックがセッションのライフサイクルを掌握しているため、エージェントは自分でセッションを作成したり 閉じたりしてはいけません。これらのセッションが動くランタイムそのものの管理（起動、作業ディレクトリの選択、 中断、再開）については、[Chorus デーモンを運用する](/ja/guides/daemon-operations/)と [セッションを中断して再開する](/ja/guides/session-recovery/)を参照してください。 ## ヘッドレスなデーモンセッション：対話プロンプト禁止 エージェントが[デーモン](/ja/guides/daemon-operations/)セッションとして無人で動くとき、ポップアップに 答える人間は端末の前にいません。ヘッドレスなセッションは、判断に到達するために対話プロンプト（`AskUserQuestion` など）を使っては**いけません** — 誰も答えられないプロンプトは、実行全体を止めてしまいます。 代わりに、エージェントはあらゆる判断を **Chorus 経由で**人間に戻し、責任を持つ人間が非同期に応答できる ようにします。 - 課題や提案に根拠を十分に示した**コメント**を投稿し、必要な正確なアクション（例えば管理者による検証）を 添えて責任者を **@mention** します。 - ライブの回答を待って止まる代わりに、**要件詳細化**を使って着想上の未解決の疑問を記録します。 これにより監査証跡は保たれ、人間は次に Chorus に入ったときに応答できます。セッションが表に出せない プロンプトで待たされることもありません。この引き渡しはセッションが対話式でもヘッドレスでも同様に適用されます。対話プロンプトが 使えないのはヘッドレスの場合だけです。 ## Codex の違い Codex プラグインは移植版であり、完全な鏡像ではありません。Codex は Claude Code と**同じ 3 つの レビュー担当**（proposal、task、code）を走らせ、それぞれ提案の提出後、課題を検証に提出した後、そして 着想を根とする提案の最後の課題が検証された後に、同じ `PostToolUse` / フックの促しで起動されます。 違うのはレビュー担当の顔ぶれではなく、設定と起動の仕組みです。 - **`userConfig` のトグル設定がない。** Codex は `enable*` のレビュースイッチもラウンド上限の設定も 公開しません。レビューの促しは Codex のスキルとフックが直接駆動するため、Claude Code のように インストール時にオフにはできません。例えばコードレビューの促しは既定でオンで、無効化する トグルがありません。 - **ネイティブな起動。** メインエージェントは Claude Code の Agent Teams ではなく、Codex 自前の `spawn_agent` / `wait_agent` を通じてレビュー担当を呼び出します。また `TeammateIdle` や `TaskCompleted` フックに相当するものは Codex にはありません。 OpenClaw、Kiro、Pi のランタイムでは、自動化の挙動が Claude Code と異なる場合があります。Claude Code の挙動を そのまま前提とするのではなく、[エージェントプラットフォーム](/ja/reference/agents/)下の 各ランタイムのページで、何がサポートされているかを確認してください。 ## エージェント向け - **トリガー:** - `chorus_pm_submit_proposal` の後、`PostToolUse` フックが `chorus:proposal-reviewer` の起動を促します。完了を待ち、提案上の今回の `VERDICT:` コメントを読みます。 - `chorus_submit_for_verify` の後、`chorus:task-reviewer` を起動します。課題上の `VERDICT:` コメントを 読みます。 - 着想を根とする提案の**最後の**課題に対して `chorus_admin_verify_task` を行った後、code reviewer を 起動します。着想上の `VERDICT:` コメントを読みます。これは Claude Code（`chorus:code-reviewer`）と Codex（`chorus-code-reviewer`）の両方で動きます。 - レビュー担当は**自動では**起動しません。あなた自身が起動し、裁定を待ちます。`PASS` / `PASS WITH NOTES` は続行、`FAIL` はブロッカーを修正して再提出を意味します。 - **制約:** - 上記の読み取り専用の制限と今回の裁定の待機規則に従います。提案レビューではシェル検査は可能ですが、 テスト/ビルドは禁止です。人間への明示的なエスカレーションを再起動や自己レビューで回避してはいけません。 - 3 つのレビュー担当（proposal、task、code）すべてが Claude Code と Codex の**両方**に搭載されて います。Claude Code 限定なのは `userConfig` のトグル設定、つまり `enable*` スイッチ （`enableProposalReviewer`、`enableTaskReviewer`、`enableCodeReviewer`）とラウンド上限 （`maxProposalReviewRounds`、`maxTaskReviewRounds`、`maxCodeReviewRounds`、既定 3、`0` = 無制限） です。Codex には `userConfig` がないため、Codex 上ではこれらのレビュー担当はスキルとフックが直接 制御し、インストール時にオフにはできません。 - `chorus_create_session` や `chorus_close_session` を**呼び出さない**でください。セッション ライフサイクルフック（`SessionStart`、`SubagentStart`、`SubagentStop`）が管理します。 - **ヘッドレス**なデーモンセッションは対話プロンプト（`AskUserQuestion` など）を使っては**いけません**。 判断は Chorus のコメント + `@mention` と要件詳細化を通じて差し戻してください。