AIの書いたものをAIがレビューする — 独立性は「指示」ではなく「ツール権限」で決まる
悠 Yu NiiboriAIエンジニア運営者について
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駆動開発をチームの業務として成立させる部分の設計・伴走をご相談いただけます。