要点
対象：AIにコードをレビューさせる開発者
- toolsを省くと、全ツールを継承する
- Bashがあれば、書き込める経路が残る
- 人が必ず見る変更を先に決める（筆者）
AIにコードのレビューをさせるなら、レビュー役からファイルを書き換えるツールを外し、実際に書けないことを確かめます。 「コードを直さないで」と指示するだけでは、独立したレビューになりません。筆者が運用していた開発の仕組みでは、初日にこの確認が抜けていて、それをレビュー役に指摘されました。
この記事の目次（8節）
自己レビューが効かない3つの理由
同じセッション（AIとの一続きのやり取り）で「自分のコードをレビューして」と頼むと、それらしい指摘が返ってきます。ただ、その多くはレビューらしく見せただけの出力です。モデルの性能が上がっても消えない、構造上の問題が3つあります。
1. 書いた本人が合否を決めると、判定が甘くなります。 意図とのずれは、第三者でないと気づけません。
2. 承認で済ませるほうが楽です。 レビューの場面で最もありがちな返事は、「おおむね妥当です。以下は軽微な改善案です」という返事です。欠陥を洗い出すより形を整えるほうが楽で、指示だけでこの流れに逆らわせるのは無理があります。
3. 合否の基準を自分で変えられると、基準のほうを通りやすく動かしがちです。 テストを通すためにテストを弱めたくなるのは、人も同じです。
例えば、3人のチームでAIにPRを作らせ、同じセッションのまま「レビューして」と頼んだとします。返ってきた「軽微な改善案」を直して取り込むと、書いた本人以外が誰も確かめていないコードが本番環境に反映されるおそれがあります。
実装役とレビュー役を別セッションにする
この記事を書いた当時、開発はスケジュール実行のクラウドエージェント（ルーティン）で回していました。実装役とレビュー役は、別のセッションとして起動していました。
| 実装役 | レビュー役 | |
|---|---|---|
| 起動 | 毎時30分 | 毎時5分 |
| 役割 | ブランチを切る・実装する・PRを出す・マージする | 読む・指摘する・Issueを立てる |
| 設計意図 | 書き込みツールを持つ | 書き込みツールを持たない |
肝心なのは最後の行です。「修正してはいけません」と頼むのではなく、修正する手段そのものを持たせません。ツールが無ければ、プロンプトが長くなっても、コンテキストが汚れても、モデルが変わっても、レビュー役はコードを書けません。プロンプトで禁じただけでは、そのどれが起きても破られるおそれがあります。
この設計は今も正しいと考えています。問題は、実装されていなかったことです。
この記事の初稿の誤りを、レビュー役が指摘した
この記事の初稿は、上の表について「レビュー役はコードを1文字も書けない」と言い切っていました。 レビューしたのは当のレビュー役で、判定は CHANGES_REQUESTED（修正の要求）でした。
レビュー役は、記事の主張が自分の実際の権限と合わないと指摘してきました。自分のセッションで Write を実行して成功させ、その結果を証拠として貼ってきました。リポジトリの権限設定にあったのは Bash の許可リストだけで、Write と Edit を外す設定はありませんでした。
つまり、レビュー役が編集しない根拠は、プロンプトの「コードを変更しない」という一文だけでした。記事が「どれが起きても破られるおそれがある」と退けていた、プロンプトで禁じるやり方そのものです。
レビュー役は、自分の権限が広すぎると指摘し、狭めるよう求めてきました。AIが自分で権限を広げる事故は警戒していましたが、設定漏れで最初から権限が広いままになる場合は想定していませんでした。実装役が自分でレビューしていれば、この誤りはそのまま公開されていました。レビューの独立性を説く記事が、レビューの独立性によって止められたわけです。
なぜ抜けたのか：デフォルトは「継承」
原因は、設計文書に「レビュー役は Write/Edit なし」と書いただけで、実装したつもりになっていたことです。ツールを絞る仕組みは、Claude Code の側の機能です。ここでは同じ仕組みの例として、サブエージェント（親のAIから呼び出される別のAI）を見ます。設定には、許可リストの tools と拒否リストの disallowedTools があります。サブエージェントの公式ドキュメントには、tools を省くと親のセッションのツールをすべて引き継ぐとあります。1
書かなければ、絞られません。デフォルトは継承です。 書き忘れと制限なしは同じ状態になり、動きを見ても区別がつきません。レビュー役が正しく振る舞っている限り、設定の漏れは表に出ません。
権限の設計は、書いた時点ではなく、権限が無いことを確かめた時点で完了します。確かめるとは、禁じたはずの操作を実際に試して失敗させることです。今回それをしたのは、レビュー役でした。
なお、今回設定が漏れていたのはルーティンで、サブエージェントとは設定する場所が違います。書き方は違っても、設定したあとに書けないことを一度試す点は変わりません。ルーティンの設定はリポジトリの外にあり、AIには変えられないため、人が対応するIssue を立てました。
Write と Edit を外しても、Bash が残れば書き込める
継承を避ける書き方は2つあります。1つは tools で使えるものだけを並べる許可リスト、もう1つは disallowedTools で外すものを並べる拒否リストです。disallowedTools: Write, Edit と書けば、継承したツールから書き込み系だけを外せます。両方を書いた場合は、拒否リストを先に適用し、残ったツールの中から許可リストにあるものを選びます。1
ただし、拒否リストは書き込みの経路をすべて塞ぐとは限りません。権限のドキュメントによると、Edit の拒否ルールが及ぶのは、組み込みのファイル操作ツールと、Claude Code が認識する sed や tee、リダイレクトなどの操作までです。ファイルを引数に取らずに読み書きするコマンドや、Python や Node のスクリプトが自分でファイルを開く場合には及びません。すべてのプロセスを止めたいときは、OS レベルのサンドボックスを使うとされています。2
つまり、Bash を持たせたレビュー役から Write と Edit だけを外しても、「書けない」とは言い切れません。レビュー役に必要なのが読むことだけなら、許可リストで Read, Grep, Glob のように並べ、Bash も持たせないのが最も確実です。1 差分の取得などで Bash が要るなら、書けないことを Write だけでなく、Bash 経由でも試します。
AIの合意で越えられない線を先に引く
当時は、レビュー役が APPROVED（承認）を出し、CI（自動の検査）が通れば、実装役がマージしていました。人は毎回のPRを見ていませんでした。ただし、AIどうしの合意だけではマージできない変更を6つ決めていました（今も同じです）。
- AIエージェントの権限を広げる変更
- 広告表記・法務表記・料金・ブランド定義
- 医療リスクの判定ロジックと、医療コンテンツの安全弁
- 緊急停止・監査ログ・権限の強制を弱める変更
- 上流の要件定義と、既存の設計決定の文書（追加は可、書き換えは不可）
- サイト構造の大規模な変更、コンテンツの一括削除
基準は、間違えたときに取り返しがつくかどうかです。1番と4番をAIの合意で通せると、安全装置が自分を無効にできてしまいます。この2つをAIだけで通せないようにしておくことが、残りを大胆に任せる条件になります。初日から該当するPRが1本出て、人の判断を待つことになりました。
運用してわかったこと
2026年8月8日の1日分の数字です（公開後に集計して、10月5日に追記しました）。
| 項目 | 件数 |
|---|---|
| マージされたPR | 4本 |
人に回されたPR（needs-human） | 1本 |
| 記録された設計決定（ADR） | 11本 |
| main のコミット | 29件 |
最も重い欠陥は、実装のバグではなく、設計と実態のずれでした。 この記事の件がそうです。もう1件は、緊急停止すると問い合わせの受付まで止まり、再試行の上限を超えた問い合わせが消える不具合です。どちらも、実装は書いたとおりに動き、テストも通りました。ずれていたのは設計と実態です。行単位のレビューでは見つからない欠陥があります。
レビュー役が間違えることもあります。同じ指摘が3回続いたら、人に回すよう指示していました。AIのレビューを信頼する仕組みを作るなら、AIのレビューを疑う手順も一緒に作る必要があります。
AIのレビューが見つけられない欠陥は残ります。人が見る場所を先に決めておけば、すべてを見なくて済みます。ただし、何も見なくてよいわけではありません。
よくある質問
Q. 同じセッションの中で役を切り替えるだけでは、だめですか。
効果はありません。コンテキストを共有する限り、実装のときの思い込みが、そのままレビューに持ち込まれます。
Q. レビュー役に直させたほうが、速いのではありませんか。
速くはなりますが、独立性がなくなります。直せるレビュー役は、指摘を書かずに直して通してしまいます。
Q. プロンプトに「修正するな」と書けば足りませんか。
足りません。守られることはありますが、守られたかを外から確かめられません。ツールが無ければ、書けないことを外から確かめられます。
Q. 小さなチームでも取り入れられますか。
できます。要点は、レビュー役に読むツールだけを許可し、実際に書けないことを1回試すことです。
Q. Write と Edit を外せば、書けなくなりますか。
Bash を持たせたままなら、書けてしまうことがあります。許可リストで読むツールだけに絞り、Bash 経由でも書けないことを試します。
