external-review-operations

name	external-review-operations
description	Use when asking an external agent or subagent to review something or give a second opinion, applying review feedback, deciding whether to accept a finding, running two reviews at once, or before calling work "reviewed" and merging it. Triggers: 「外部レビューを依頼」「codex にレビューさせて」「レビュー指摘を反映」「この指摘は採用すべきか」「レビュー済みか確認」「マージ前レビュー」. Fire even when the work feels already reviewed — that false sense is the failure this skill prevents.
summary	外部レビューの運用。依頼する前の設計（何を対象にするか・編集権をどこまで渡すか・ ラウンドの目的）、返ってきた指摘の採否検証、「どのゲートが何に対して通ったか」の 会計の3局面を扱う。CLI の起動手順は external-agent-invocation が持つ。

外部レビューの運用

外部のレビュー（別プロセスのエージェント / 別モデル / サブエージェント）を回すときに、依頼する前・指摘が返ってきたあと・「レビュー済み」と判断する時点の3局面で守ること。

起動手順はここに無い。 どの CLI をどう起動するか、対象をどう渡すか、重大度をどうラベルさせるかは external-agent-invocation を読む。このスキルが扱うのは「何を対象に、どこまで許して、何往復するか」と「返ってきたものをどう扱うか」だけ。

ここに並ぶ手順はすべて、実際に起きた取りこぼしから来ている。多くに共通する機序は1つ——「レビューした」という感覚と「実際にレビューされたもの」がズレること。感覚は回数やラウンド数で増えるが、保証されるのはレビュアが実際に読んだ対象の分だけで、両者は簡単に食い違う。

1. 依頼する前の設計

編集権を渡すなら、スコープ境界を同じ依頼文に書く

外部レビューAIに「改善点があれば直接編集して修正せよ」と頼むと、対象スコープ外のファイルへ「善意の修正」を残すことがある。指摘としては妥当でも、黙って取り込めばスコープの拡大・別途必要な専門レビュー（安全性レビュー等）の迂回・意図しない責務領域への変更混入になる。

依頼文に「このブランチのスコープは〜のみ。スコープ外のファイルへの修正提案は、編集せずテキストで報告するに留めよ」と明記する。明記すれば実際に抑止できる（実例: 明記前は対象外モジュールへ未コミット修正が残ったが、明記後は「編集せずテキスト報告」に収まった）。

抑止の明記は前提であって保証ではないので、受け取り側の照合（「編集権レビューが残した差分は、スコープ照合してから採否を決める」）とセットで運用する。

ラウンドの目的に応じて編集モードを切り替える

スコープ（ファイル範囲）だけ決めても足りない。ラウンドの目的に応じた編集モードを明示しないと、往復が終端しない。

ラウンド	編集モード
発見ラウンド（初回・網羅的に見せる回）	編集許可 + スコープ境界明示
収束確認ラウンド・最終ラウンド	「読み取り専用。編集せず指摘のみ」を明示

収束を意図するラウンドに編集許可を残すと、スコープ内の妥当な修正であっても新しい未コミット差分が生まれ、「編集 → 再検証 → 再レビュー」で往復が1回増える。往復には上限があるので、これは終盤ほど高くつく。

実例: 収束のつもりの2回目を「修正が必要な問題が見つかった場合のみ編集」で依頼したところ、妥当な修正が未コミットで残って3回目が必要になった。3回目で読み取り専用を明示したら指摘のみで終端した。

最終ゲートは反証を要求するモードで回す

編集モードとは別に、指摘の出方はレビュー依頼の姿勢で変わる。「レビューしてください」と頼むと、レビュアは実装の主張を追認する側へ寄り、成立している経路を確認して終わることがある。最終ゲート（マージ直前の全体レビュー）では、代わりに**「この変更は安全であるという主張の反証を試みよ」**と依頼し、反証できた項目とできなかった項目を1つずつ明記させる。

実例: 通常モードの外部レビュー・自己レビュー・領域特化の安全性レビューがいずれも指摘ゼロで通した変更に対し、同じレビュアへ反証を要求したところ、認証照合の fail-open を1件構成して返した。設計文書側も別途5ラウンドのレビューを通していたので、通算9系統を素通りしていた。

反証させる主張は、実装者が「守った」と考えている不変条件をそのまま列挙する。反証できなかった項目も明記させるのは、「言及が無い」と「試みて構成できなかった」を区別するため。

最終ゲートにはモデルの多様性も入れられる

前節が依頼姿勢の多様性（追認 → 反証）なのに対し、こちらはレビュア自体の多様性で、効かせる機構が別。同一ツールでラウンドを重ねても、そのモデルが構造的に見落とす種類の欠陥は反復されるだけで埋まらない — ラウンド数は「読まれた回数」を増やすが、「読み方の種類」は増やさない。

ラウンド上限を持つ運用では、最終ラウンドを別モデル（別 CLI・別ベンダ）に充てる選択肢を持っておく。同じツールでもう1周するのとどちらが効くかは比較検証していないので、規定ではなく選択肢として置く。（auto-memory から昇格、2026-08-20）

反復でスコープを絞るなら、途中で一度は全体へ広げる

対象を1節・1関数へ絞った反復レビューは、その内部を磨くのは得意な一方、スコープ外の記述との矛盾は何ラウンド回しても出てこない。矛盾は境界をまたぐものなので、境界の内側だけを見る限り原理的に見えない。

実例: ある文書の1節に限定して8ラウンド回しても、その節と別の節との矛盾（同じ制約の帰属先が食い違っていた）は一度も出なかった。スコープを文書全体へ広げた直後に表面化した。

対処は、反復の途中で一度スコープを文書全体・モジュール全体へ広げるラウンドを入れること。同種の失敗として、外部指摘へ反証するときに自分の文書の他節と突き合わせないと、自分が書いた記述と矛盾する主張をしてしまう。反証も全体照合してから出す。

スコープ外が凍結済みの記録（遡及編集しない snapshot）の場合、矛盾はスコープ内側の修正でしか解消できない点に注意する。

編集権レビューと状態観測レビューを同一の作業ツリーで並行させない

「どちらも読み取り主体だから並行できる」は誤り。編集権を持つレビューは作業ツリーの状態を随時変える。一方、状態観測系のレビュー（git status が clean であること、テストが緑であることを前提に見るタイプ）は、進行中の編集と実欠陥を区別できない。結果、後者が前者の作業途中の差分を「レビュー対象と実態の不一致」「テスト red」としてブロック報告する。観測としては正しいので、切り分けコストだけが発生する。

• 編集権レビューが走っている間は、同一ツリーへの状態観測系レビューを起動しない（直列化する）。
• どうしても並行するなら、状態観測側の対象をコミット済みのハッシュ範囲に限定し、「未コミット差分は並行レビューの作業中でありスコープ外」と依頼文に明記する。
• 並行レビューから「未コミット差分がある」と報告が来たら、欠陥と断定する前にもう一方のレビューの進行状態を先に確認する。

2. 返ってきた指摘の扱い

保留付き・具体名の指摘は、一次情報で逐語照合してから採否を決める

「要確認 / 〜かもしれない / おそらく」と保留の付いた指摘、および具体的なシンボル名・ファイル名・行に関する指摘は、grep / Read で照合すれば即座に真偽が確定する。レビューAIは「読めば確定できる事実」でも自分のコンテキストに無いと安全側へ倒して "要確認" を盛る傾向があるので、保留の有無は信頼度の指標にならない。重大度ラベルも額面どおりに受け取らない。

特に警戒するのは「断定を避けて一般表現へ薄めよ」という方向の提案。正確な情報を失う改悪になりやすい。

実例: 計画文書に書いた関数名・protocol メソッド名について「実在しないかもしれないので一般表現に薄めよ」と最上位の重大度で指摘された（ただし「逐語名は要確認」の保留付き）。照合すると全て実在・正確で、従っていれば着手時に参照すべき正しい名前を消すところだった。

網羅性・不在の主張は、主張者と別の切り口で数え直す

「N件しかない」「〜は存在しない」といった網羅性・不在の主張は、分析の正しさとは独立に外れる。 保留の有無も確信度も当てにならない。レビュアは目についた箇所から書くので、分析が完璧でも列挙だけが尽きていないことが普通に起きる。

• ある指摘は、呼び出し鎖の分析は完全に正しかったのに、対象箇所を「設定ファイルの2箇所のみ」と断言してテストファイルの3箇所目を落とした。
• 別の場面では、対象コミットの内容を正しく確認しながら「それが指摘対象と別の記述である」ことに気づかず、確信度「高」で誤った結論を出した（反証を提示したら撤回した）。
• 自分自身も「識別子が grep で 0 hits」を「概念が存在しない」と誤読し、3件中2件を誤診したことがある。片方はその名前の識別子が無いだけで挙動としては実装されていたもの、もう片方は同じ概念が別の呼称で書かれていたもので、どちらも識別子の検索では見えない。

独立した複数レビューが一致しても、網羅性の裏取りにはならない。 一致が保証するのは「指摘そのものが妥当か」までで、「列挙が尽きているか」は保証しない。見落としの分布が似れば、独立でも同じ取りこぼし方をする。実例: 自己レビューと全体外部レビューが独立に同じ指摘へ収束したが、対象範囲は両方とも3ファイルと書いていた。機械的に全走査すると5ファイルあり、2件を両者が落としていた。

対処:

• 主張者と別の切り口で数え直す（識別子でなく挙動、コードでなくテスト、grep でなく呼び出し元追跡、目視でなく AST 走査）。
• 不在を主張する前に「別名で実装されていないか」を挙動で確認する。
• レビュアへ依頼するときは「この主張を立てた調査者は N 件中 M 件を誤診している」と伝えて同調圧力を先に潰す（実際にこれで外部レビューは誤った結論を撤回した）。
• 一致は着手の根拠にしてよいが、範囲は着手前に自分で数え直す。

編集権レビューが残した差分は、スコープ照合してから採否を決める

抑止を明記していても信用せず、レビュー後に git status / git diff で実際に編集されたファイル一覧をスコープと照合する。

• スコープ外の編集は既定で不採用。diff を退避して証拠を保全したうえで revert し、指摘として妥当なら別課題として起票を人間に諮る。
• 複数の担当者・エージェントで分担しているなら、採否を判断するのはそのプロジェクトの方針知識を持つ側——つまりその変更を実装した担当者本人。修正の見た目が妥当でも、方針との整合を判断できるのはそこだけなので、取りまとめ役が代行しない。受容・改良・反論のいずれかで決着させる。

実例1: 「ブロック指摘なし」と報告しつつ、対象外モジュールとそのテストに未コミット修正が残っていた。内容自体は診断メッセージの改善として妥当だったが、(a) スコープ外、(b) 変更に別途安全性レビューが要る領域、(c) 現行コードも同じ形で fail fast しており欠陥ではない、の3点から不採用とした。

実例2: 最適化パラメータの探索範囲を広げる修正が残されたが、実装した担当者が「探索範囲の拡張は過学習抑制の方針に反する」と根拠付きで revert した。

指摘の反映に自作の新規判断が混じったら、差分スコープで収束確認する

レビュアが提示した選択肢をそのまま採らず第3案を自作した場合、あるいは指摘が開けた新たな未決を自分で埋めた場合、その部分は未レビューの新規設計になる。指摘対応の体裁をしていても品質保証はされていない。

新規判断を名指しした差分スコープの収束確認ラウンドを回してから確定する。依頼文には「読み取り専用」と「全文の再レビューは不要」を明示する（「依頼する前の設計」の編集モードとスコープ絞りをここで使う）。これが無いと往復が終端しない。

要否は改訂の量ではなく判断の有無で決める。レビュアの提案をそのまま文面化しただけ、誤字レベルの改訂なら不要。

実例: レビュー指摘4件の反映で、レビュアが挙げた2択に無い第3案と、自分で埋めた未決を1つずつ作った。収束確認ラウンドが、そのうち前者に残っていた未定義の穴（矛盾入力時の意味論が決まっていなかった）を投稿前に捕捉した。

3. 「レビュー済み」の会計

完了報告・マージ・外部への書き込みの直前に、どのゲートが何に対して通ったかを対象単位で照合する。ここを感覚で済ませると、通っていないゲートが静かに落ちる。

判定は回数ではなく対象で行う

意思決定（合意した方針・設計判断）を外部レビューに何度かけても、その合意から書き起こした成果物（文書・コメント・spec・実装コード）は未レビューのままである。合意 N 回・成果物 0 回は「合計 N 回のレビュー実績」ではなく成果物 0 回。

危ないのは、レビュー回数の記憶が「レビュー済み」という感覚を作り、成果物レビューの工程が静かに飛ぶこと。外部書き込み・コミットの直前に「今から出すこの文面／このコードを、誰かが読んだか？」を対象単位で自問する。

実例: スコープ・突合契約・見積りといった意思決定について3回セカンドオピニオンを取り、主観的には「十分レビューした」状態だった。指摘を受けて確認すると、投稿予定の4つのドラフトは一度も外部レビューを通っていなかった。改めて回すと重大な懸念が5件——用語の語義が未定義で集計次元が不整合、再現しない実測値の断定、日数の取り違え、データ構造の誤記述、既に解消済みの事象を現存として書いた箇所。いずれも合意内容ではなく文面化の過程で混入した欠陥で、合意のレビューでは原理的に捕まらないものだった。

合意をそのまま1〜2行に写しただけの文面は省いてよい。判断が要るのは「合意に無かった数値・定義・構造記述を成果物側で書き足したとき」で、そこが混入点になる。

プロセススキル内蔵のレビューは、常設ゲートを代替しない

実装プロセスのスキル（subagent 駆動開発、計画実行など）が独自のレビューゲートを内蔵していても、それはスキル内部の品質工程であり、恒久運用として定めた常設ゲート（別プロセス・別ベンダーによる外部レビュー、安全性レビュー、フルテストゲート等）とは別枠。スキルの「final review clean」を「レビュー済み」と読み替えると、常設ゲートがスキルの完了定義に吸収されて落ちる。

逆説的だが、内蔵レビューが手厚いほど危ない。「レビュー済み」の感覚が強まる分、独立性（別プロセス・別モデル）が欠けていることが見えなくなる。

実例: 同じ課題の前半ステージは直接実装だったため「ステージ完了 → 外部レビュー」の運用がそのまま発火した。後半ステージを subagent 駆動開発で実行したところ、内蔵レビュー（タスクごと8回 + 最終の全体レビュー。合成欠陥の検出・修正まで完遂）を通過した時点で完了報告し、外部レビューは未実施のままだった。

完了報告の直前に、スキルの checklist とは独立に「スキル外の常設ゲートは全部通ったか」を照合する。常設ゲート側が「スキル内蔵レビューで代替可」と明文化していれば落ちではない。

レビュー痕跡が追えないなら、ブランチ全体を一括レビューする

複数フェーズ・複数セッション・複数作業ツリーで積み上げたブランチを統合する前、過去コミットの外部レビュー実施が確認できないときは「済んだはず」と仮定せず、ブランチ全体（base..HEAD）を一括で外部レビューする。フェーズごとのレビュー実施状況はセッションを跨ぐと追跡が切れやすく、レビュー痕跡は git に残らない。

実例: 4フェーズ・複数セッションで積み上げたブランチの統合前、当セッションで実施を確認できたのは後半2フェーズのみだった。ブランチ全体を一括レビューしたところ、未レビューだったフェーズから実ブロック欠陥を回収した——時間帯によって通過可否が変わるガードの後ろに設定検証が隠れており、同じ不正設定が時刻次第で fail fast したりしなかったりする非対称になっていた。ガードを通過する時間帯では未処理例外を投げ、孤立したレコードと未 close の接続を残す穴だった。フェーズ単位では見落とされていた。

これはフェーズごとのレビューの代替ではなく、網羅ギャップの最終ネット。各フェーズを確実に都度レビューし記録が追える運用では冗長。

なお、このネットと「内蔵レビューは常設ゲートを代替しない」は別物。ブランチ一括レビューは「実施したか分からない」ときに発動するものだが、内蔵レビューの読み替えは「実施していないと知りながら代替とみなす」機序なので、このネット自体が発動しない（発動を判断するのも自分だから）。常設ゲートの照合は、ブランチ一括レビューとは独立に行う。