『Low 指摘1件』のために計画からやり直す ── レビュー0件主義を多エージェントで3ラウンド回した話（C3 v2.39.0）
- URL: https://zenn.dev/satoh_y_0323/articles/5125a1021b312b
- 日付: 2026-06-25
- Tier: Tier 3
- 要旨: Claude Code Conductor (C3) v2.39.0 開発で「Low を含めて 0 件」レビュー規律を 3 ラウンド貫いた記録。複合 Bash (if・$()・リダイレクト) はプレフィックス一致で事前許可不可→session_guard.py 1 スクリプトに集約・1 行 allow でダイアログ恒久解消。レビュアーの誤った犯人特定 (v2.39.0 が追加)、実行役 tester が planner の is 比較を CPython タプルインターン化から AST 解析へ正す、たった 1 行重複 (Low) で計画から再開するコスト認識。セッション再起動後「現在地」1 行で続きから走り出す中断耐性。
詳細
C3 (Claude Code Conductor) は多エージェント・フレームワーク。自身の開発もワークフロー (ヒアリング→設計→計画→TDD→レビュー) で実施。縛り: 「Low 含め 1 指摘でも出たら全潰し。planner 戻り→再実装→再レビュー。0 件迄繰返」。フレームワーク本体＋実利用者ありゆえ内部品質投資。
小機能: /start 時に複数 Bash が毎回許可ダイアログ出す問題。原因: if・$()・リダイレクト含む複合 Bash は settings.json の allow がプレフィックス一致で許可不可 (静的解析不可)。Windows native 環境ではサンドボックス no-op で autoAllowBashIfSandboxed も効かず。
解: session_guard.py を 1 スクリプトに集約、mark・check・setup-mark を引数分岐。settings.json に “Bash(python .claude/skills/…/session_guard.py*)” 1 行。末尾 * プレフィックス一致で全 3 サブコマンド一発許可。複合構文消失で静的解析通、ダイアログ恒久解消・挙動完全不変・後方互換。
レビュー 3 ラウンド:
初回: code-reviewer 6 件 (M2・L4)・security-reviewer 5 件 (M2・L3)。最重要 Medium は「v2.39.0 が複合 Bash 追加したが allow 未登録」と指摘。git status/diff でファイル確認→未変更。「犯人特定」誤りだが、観察「/setup 初回実行時ダイアログ出る」は正。framing と観察を分離、正しい中身拾う決定。setup-mark も追加集約。
第 2 版: 初回 6 件全解消。security は 0。code-reviewer は新規 Low 1 件: SETUP_DONE_FLAG_REL と SETUP_MARKERS_REL[1] が同じタプル (".claude",“state”,“setup_done.flag”) 二重定義 (DRY リスク・将来誤り可能)。setup-mark 追加時に自分の修正で新重複発生。
第 3 版: たった 1 行重複のため計画からやり直す。理由: 強い規律は形骸化しにくく、例外許容始まると「次の些細」も通る。コスト直視 (6-8 回エージェント起動/ラウンド) した上で一貫。
エージェント協業の質: planner は重複検証を「SETUP_MARKERS_REL[1] is SETUP_DONE_FLAG_REL」is 比較で指示 (True=同一オブジェクト)。tester は実測で否定→CPython タプルインターン化でリテラル二重定義も is=True。代わり ast.parse で SETUP_MARKERS_REL[2 要素] が ast.Name (参照) か ast.Tuple (リテラル) か判定。計画誤りを実行役が理由付きで正す。
結果: 第 3 版 code/security 共 0 件。テストスイート 1518 pass。リリース承認→commit→tag→push→GitHub Release。
実務適用の教訓: (1) 複合 Bash は事前許可不可→1 スクリプト+1 行 allow に畳む (2) レビュー犯人特定は一次裏取り (git log/status で framing と観察分離) (3) 「全潰し」は強い規律だがコスト直視必須 (使い捨てスクリプトは Low 受容も可) (4) 計画は完璧不要・実行役の「待った」尊重で品質向上 (5) 中断耐性は「復帰後に次の一手が分かること」で初めて実用 (「現在地」1 行フィールド)。