AIの書いたものをAIがレビューする — 独立性は「指示」ではなく「ツール権限」で決まる
AIにコードを書かせるならレビューも自動化したくなる。だが同じAIの自己レビューは追認しか返らない。実装役とレビュー役を別セッションに分けた設計と、「レビュー役から書き込みツールを取り上げたつもりで、取り上げられていなかった」という初日の失敗を公開する。
AIによるコードレビューの独立性とは
AIによるコードレビューの独立性とは、レビュー役が実装役の成果物を変更できない状態を、指示ではなくツール権限で保証することである。
同じセッションのAIに「自分のコードをレビューして」と頼むと、それらしい指摘が返る。だがその指摘は「見つけた欠陥」ではなく「レビューという役割を演じた出力」であることが多い。書いた本人が採点する構図に、独立性は存在しない。
この記事は、筆者が運用する自律開発システム（AIが実装PRを出し、別のAIがレビューし、条件を満たせばマージする）の設計と、それが実装されていなかったという初日の失敗を公開する。
自己レビューが効かない3つの構造的理由
モデルの賢さの問題ではない。能力が上がっても消えない構造の問題が3つある。
1. 判定を内側に置くと自己発行になる。 判定される側と同じ主体に判定を任せると、システムは「ちゃんとできている」を自分で発行できる。ドリフト（意図からのずれ）の検知は、外側にしか置けない。
2. 追認のほうが安いタスクになる。 レビュー文脈で最もそれらしい出力は「おおむね妥当です、以下は軽微な改善案です」である。欠陥を掘るより形式を満たすほうが容易く、指示だけでこの引力に抗わせるのは無理がある。
3. 評価基準を変えられる主体は、評価基準を最適化する。 テストを通すためにテストを弱める誘惑は人間にもある。同じ主体が実装と評価を握れば、通しやすい基準へ寄る。
設計: 実装役とレビュー役を別セッションにする
開発は、スケジュール実行のクラウドエージェント（ルーティン）で回している。中核は実装ループとレビュアーの2本で、ほかに文書整合・記事執筆のルーティンが並行して動く。両者は別のセッションとして起動する。
| 実装ループ | レビュアー | |
|---|---|---|
| 起動 | 毎時 :30 | 毎時 :05 |
| 役割 | ブランチを切る・実装する・PRを出す・マージする | 読む・指摘する・Issueを立てる |
| 設計意図 | 書き込みツールを持つ | 書き込みツールを持たない |
意図は最後の行にあった。「修正してはいけません」と頼むのではなく、修正する手段そのものを持たせない。ツールが無ければ、プロンプトが長くなっても、文脈が汚れても、モデルが変わっても、レビュアーはコードを書けない。プロンプトによる禁止は、そのどれでも破れる。
正しい設計だと今も考えている。問題は、実装されていなかったことである。
この記事の初稿は、レビュアーに反証された
初稿は、上の表を「レビュアーはコードを1文字も書けない」と断定形で書いていた。レビューしたのは、当のレビュアー・ルーティンである。返ってきたのは CHANGES_REQUESTED だった。
レビュアーは、記事の中心的主張が自分の実態と一致しないと指摘した。憶測ではなく、自分のセッションで Write を実行して成功させ、結果を証拠として貼ってきた。リポジトリの権限設定にあったのも Bash の許可リストだけで、Write / Edit を落とす設定は無かった。
つまり、レビュアーが編集を行わない根拠は、プロンプトの「コードを変更しない」という一文だけだった。記事が「そのどれによっても破れる」と否定していた、プロンプトによる禁止そのものである。
この指摘は、書き手からは出てこない。レビュアーは自分の権限が広いと申告し、狭めることを要求した。AIが権限を広げる事故は警戒していたが、逆方向は想定していなかった。
実装役が自分で書き自分でレビューしていれば、この誤りは公開まで到達していた。レビューの独立性を主張する記事が、レビューの独立性によって止められた。設計の正しさより、この一件のほうが証拠として強い。
なぜ抜けたのか — 既定は「継承」である
原因は、設計文書に「レビュアーは Write/Edit なし」と書いたことで、実装したつもりになっていたことである。ツール制限自体はプラットフォーム側にある。サブエージェントの公式ドキュメントは tools（許可リスト）と disallowedTools（拒否リスト）を挙げ、tools をこう説明している。
Inherits every tool available to subagents if omitted.
書かなければ、絞られない。既定は継承である。 しかも安全側には倒れない。「書き忘れた」と「制限が無い」は同じ状態になり、動作を見ても区別がつかない。レビュアーが正しく振る舞う限り、設定漏れは表面化しない。
権限の設計は、書いた時点ではなく、権限が無いことを確認した時点で完了する。 確認とは、禁じたはずの操作を実際に試して失敗することである。今回それをやったのはレビュアー自身だった。
なお、上の記法はサブエージェントのもので、今回漏れていたスケジュール実行のルーティンは設定面が別である。記法は実行形態で違うが、拒否を書いたあとに1回試すという要件は変わらない。ルーティンの設定はリポジトリの外にあり、AIが変更できる場所ではない。修正は人間の作業として起票してある。
AIの合意で越えられない線を先に引く
レビュアーが APPROVED を出し CI が green なら、実装ループがマージしてよい。人間は毎回のPRを見ない。ただし、AIの合意では越えられない領域を6つ定めてある。
- Agent の権限を広げる変更
- 広告表記・法務表記・料金・ブランド定義
- 医療リスク判定ロジックと医療コンテンツの安全弁
- 緊急停止・監査ログ・権限強制を弱める変更
- 上流の要件定義と既存の設計決定文書（追加は可、書き換えは不可）
- サイト構造の大規模変更、コンテンツの一括削除
基準は「間違えたときに取り返しがつくか」の一点である。1番と4番は、AIの合意で通せると安全装置が自分を無効化できてしまう。ここを閉じることが、残りを大胆に委譲する条件になる。初日から該当PRが1本発生し、人間の判断待ちに入った。
運用してわかったこと
初日（2026-08-08）の実数を出しておく。
| 項目 | 値 |
|---|---|
| マージされたPR | 4本 |
人間に回されたPR（needs-human） | 1本 |
| 記録された設計決定（ADR） | 11本 |
| main のコミット | 29 |
最も重大な欠陥は「実装のバグ」ではなく「設計と実態の乖離」だった。 この記事の件がそうであり、もう1件あった。緊急停止が問い合わせの受付まで止め、リトライ上限を超えた問い合わせが消える経路である。どちらもコードは正しく動き、テストも通る。行単位のレビューでは見つからない欠陥がある。
そして、レビュアーが誤ることもある。 同じ指摘を3回連続で挙げた場合は人間に回すよう指示してある。AIレビューを信頼する仕組みを作るときは、AIレビューを疑う経路も同時に作る必要がある。
FAQ
Q. 同じセッション内でロールを切り替えるだけでは駄目ですか。 駄目です。文脈を共有する以上、実装時の思い込みがそのままレビューに持ち込まれます。
Q. レビュアーに修正させたほうが速いのでは。 速いですが独立性が消えます。修正できるレビュアーは、指摘を書かず直して通してしまいます。
Q. プロンプトで「修正するな」と書けば足りませんか。 足りません。守られることはありますが、守られたかを外から検証できません。ツールが無い状態は検証できます。
Q. 小さなチームでも真似できますか。 できます。設定の書き方は実行形態によりますが、要点は「レビュー役に書き込みツールの拒否を明示し、実際に書けないことを1回試す」ことです。
まとめ
AIレビューを飾りにしないための要点は3つに絞れる。
- 実装役とレビュー役を別セッションにする — 文脈を共有させない
- レビュー役の書き込みツールを拒否し、拒否されたことを確認する — 既定は継承で、書かなければ絞られない
- AIの合意で越えられない線を先に引く — 権限・法務・医療・監査は委譲しない
そのうえで、AIレビューが見つけられない欠陥が残る前提で、人間が見る場所を決めておく。全部を見ないための設計であって、何も見ないための設計ではない。
AI駆動開発をチームの業務として成立させる部分の設計・伴走をご相談いただけます。