大規模言語モデル（LLM）を使ってコードや技術ドキュメントを作成するとき、最も根深い課題は「モデル自身による自己チェックの限界（Self-Review Bias）」です。同じセッション内でどれほど厳しく「バグを徹底的に探して」と指示しても、モデルは直前に自身が生成した文脈の慣性に引きずられ、「精査しましたが問題ありません」と楽観的な結論を出しがちです。
OpenClaw v2026.9.5 で専門家チーム機能が追加された際、多くの開発者が openclaw agents team create を試しました。しかし、これを実行すると、ローカル環境にコーディネーター（Coordinator）、調査担当（Researcher）、執筆担当（Writer）、査読担当（Reviewer）の4つの独立したワークスペースが一気に生成されます。個人の開発者や少人数のチームにとっては、4つのディレクトリ、4つの SQLite セッションデータベース、階層的な委任管理が生まれ、管理コストと認知負荷が急増します。
実践的な解決策は極めてシンプルです。4人のチームを作らず、既存の主力（main）Agentの横に「査読担当（Reviewer）」だけを1人追加することです。ソフトウェア工学で実績のある「作成者と検証者の分離（Maker-Checker）」を最小限の構成で実現します。
なぜReviewer単体なのか
マルチエージェントを構築する際、過度な「役割分担ごっこ」に陥りがちです。シンプルな開発タスクを無理に調査、執筆、統括に分解すると、トークンや時間の多くがエージェント間の挨拶やフォーマット変換で消費されます。
さらに、コーディネーターだけを不用意に作成すると、下流の専門家IDが見つからずにエラーや宙吊り状態になるリスクもあります。
Reviewerだけを追加する構成には3つの明確な利点があります。
- コンテキストの純粋性（Context Hygiene）：主力Agentのコンテキストは試行錯誤や妥協した仮定で汚染されています。一方、独立したReviewerは「完成した成果物」と「検証ルール」だけをまっさらなコンテキストで受け取るため、先入観なく厳密に評価できます。
- 作成者と検証者の対立構造：実装側と検証側が構造的に分離されることで、単一セッションの盲点を打破できます。
- 管理オーバーヘッドがゼロ：人間は主力Agentとだけ対話し、主力Agentが生成完了後にReviewerへ検証を依頼します。不要な中間層がありません。
3ステップの実装手順
OpenClawでこの構成を組む手順は以下の通りです。
ステップ1：CLIでReviewerのみを作成
team create は使わず、openclaw agents add に --role reviewer を指定します。
openclaw agents add code-reviewer --role reviewer
これで独立したワークスペース（例：~/.openclaw/workspaces/code-reviewer）と専用の SQLite ストアが生成され、公式の標準査読規約（AGENTS.md）が自動配置されます。
ステップ2：主力Agentの設定に委任先を追加
主力 main Agentの設定で、code-reviewer への委任を許可します。
{
"agents": {
"main": {
"allowAgents": ["code-reviewer"],
"delegationMode": "prefer"
}
}
}
-
allowAgents：意図しないエージェントへの分散を防ぐホワイトリスト。 -
delegationMode: "prefer"：生成完了時にsessions_spawnを通じて査読エージェントを呼び出すプロンプト上の誘導。
ステップ3：Reviewerの行動契約を遵守する
公式の査読者規約（AGENTS.md）には、以下の重要な制約が定められています。
- 査読権は修正権ではない（Audit-Only）：Reviewer自身がコードやファイルを書き換えることは禁止されています。修正の決定権は主力Agentと人間にあります。
- 指摘の3要素：具体的な位置（行番号）、違反した要件/テスト、具体的な修正案を必ず提示します。
- BlockerとOptionalの分離：重大な欠陥（Blocker）と改善提案（Optional）を明確に分け、些細な体裁の指摘で作業が停滞するのを防ぎます。
- エージェント間の横方向ループの禁止：査読結果は呼び出し元の主力Agentにのみ返却されます。
実際の査読レポート形式
Reviewerが主力Agentに返すのは、構造化されたレポートです。
# Code Review Report
Status: REJECTED (1 Blocker, 1 Optional)
## [BLOCKER] 並行リフレッシュ時の競合状態
- 位置: src/auth/token_manager.py:42-58
- 違反要件: 並行処理安全規約（重複トークン更新の防止）
- 根拠: 複数コルーチンが同時に例外を捕捉した際、重複して更新リクエストを送信する。
- 修正案: asyncio.Lock を導入し、ロック取得後に二重チェック（Double-Checked Locking）を行う。
## [OPTIONAL] 構造化ログの欠落
- 位置: src/auth/token_manager.py:65
- 提案: trace_id を含む JSON ログ形式への変更を推奨。
主力Agentは Blocker を修正して再レビューを依頼し、APPROVED になるまで検証サイクルを回します。
注意点
- コーディネーター単体を作らない：下流の専門家がいないコーディネーターは設定ミスや混乱の原因になります。
-
preferは強制ではない：プロンプトでの案内であるため、指示プロンプト内で「実装完了後は必ず code-reviewer の査読を受けること」と明記すると動作が安定します。 - 内部の承認と外部実行の分離：Reviewer の合格はコード品質の確認であり、外部への公開やマージには人間による承認が引き続き必要です。