この記事でわかること
- ClaudeCodeに任せる“リリース前チェック”の範囲の決め方（権限と秘密が先）
- 差分レビューの観点をテンプレ化して、24時間以内に返せる形にする方法
- 「やらないこと」を決めて、誤検知と責任の押し付けを避けるコツ
リリース前チェック、毎回ちょいちょい同じ事故が起きます。
「権限が足りず見えない」「秘密情報が混ざる」「差分の見落としで再リリース」あたりが、地味に効いてくるやつです。
そこでClaudeCodeに“チェックだけ”寄せて、最終判断は人がやる形に寄せました。
筆者の一言：自動化って気持ちいいけど、権限で詰まると一気に冷めます。
まずここで詰まる（よくある勘違い）
最初の勘違いは「AIにリポジトリ全部読ませればOK」です。
実際は、社内だとリポジトリが分かれていたり、サブモジュールや設定ファイルに機密が混ざってたりします。
たとえば、.env相当の値がPRに入ってたら、その時点でアウトです（しかもレビュー以前の問題）。
なので“読む範囲”を先に決めます。
私の現場だと、対象は「変更ファイル＋依存関係の宣言（package/Podfile相当）＋リリース手順書（該当箇所だけ）」に固定しました。
数字で言うと、PRあたり最大40ファイルまで、差分は最大2,000行までを目安にしています（それ超えると人間のレビューも落ちがち）。
現場あるある：「AIに全部見せたのに漏れた」が発生すると、だいたい“見せてない前提”が後から出てきます。
自分がやらかした話（小さくてOK）
一回やりました。
「差分の安全確認」だけのつもりでClaudeCodeに投げたら、ログ出力にトークンっぽい文字列が残ってるのを見落としたまま、レビューOKを出しかけました。
原因は単純で、私が“秘密情報チェック”を差分の観点に入れてなかったことです。
回避策として、チェックの最初に「秘密情報っぽい文字列（APIキー形式、JWTっぽい3分割、長いBase64）」を機械的に洗い出すステップを入れました。
あと、もう一つ。権限が弱いトークンで実行してたせいで、一部ディレクトリが読めず、ClaudeCodeの回答が「見えないけどたぶんOK」っぽい空気になったことがあります。
ここ、正直迷ったのですが、結局は“読めないならNG（要人手確認）”に倒しました。
会話っぽい一言を置くとこんな感じです。
「そこ見えてないなら、OKって言わないで…」
現場の判断基準（ここは会社で割れる）
判断基準は3段階に分けると揉めにくいです。
1つ目は「ブロック（絶対止める）」で、秘密情報の混入や権限不足のままのレビューはここに入れます。
2つ目は「警告（人が判断）」で、たとえばタイムアウト周りの変更、リトライ回数を3→10に上げた、みたいな運用影響が読める変更です。
3つ目は「記録だけ」で、命名揺れや軽微なLintの指摘などです。
数字の例だと、リトライは最大3回、タイムアウトは30秒、みたいに“会社の標準値”があるなら、それを超えたら警告に寄せると運用が平和になります。
逆に、やらないことも決めました。
「一括更新の可否」みたいな業務判断は、ClaudeCodeに決めさせないです（責任が曖昧になるので）。
筆者の一言：自動で止める線引き、強すぎると現場が回らないので“止めどころ”だけ固定しました。
表：チェックリスト or 比較（※TABLE HERE）
| 観点 | ClaudeCodeにやらせる | 人が判断する | メモ（数値例） |
|---|---|---|---|
| 秘密情報混入 | パターン検出して列挙 | 本当に秘密か最終確認 | JWT/32桁キー/ENV名を検知 |
| 権限不足 | 読めないファイルを報告 | 権限付与 or 手動確認 | 読めない=ブロック扱い |
| 差分の危険箇所 | 認証/権限/外部通信を抽出 | 仕様と照合してOK判断 | 外部通信追加は警告 |
| 運用影響 | タイムアウト/リトライの変更検出 | 監視・手順書更新判断 | 30秒/3回を超えたら要確認 |
| リリース手順 | 手順書の該当箇所を差分確認 | 当日オペの可否判断 | 手順が2工程増なら再確認 |
この表をそのまま“PRテンプレのチェック欄”に持っていくと、レビューの往復が減ります。
私は「レビュー依頼から24時間以内に一次回答」を目標にして、ClaudeCodeの結果を先に貼ってから人が追記する形にしました。
FAQ（質問が飛んできがちなやつ）
Q. ClaudeCodeに秘密情報が見えたらどうする？
A. まずPRを止めて、該当キーをローテーションします（消して終わりにしない）。
Q. 権限が足りないトークンで回しても意味ある？
A. “見えてる範囲だけ”のチェックになるので、少なくとも読めない一覧を出す用途に限定します。
Q. AIの指摘が外れたら、誰が責任取るの？
A. そこを曖昧にしないために「ブロック条件だけ固定」「最終OKは人」に寄せます。
まとめ（次にやること1つ）
リリース前チェックは、機能より先に「権限」「秘密情報」「差分観点」を固定すると安定します。
まずは“ブロック条件”を2つだけ決めるのが早いです（秘密情報混入、権限不足）。
次に、差分の抽出観点を表の形でテンプレにして、毎回同じ入口にします。
次に読むおすすめ
- CodexでIssueテンプレを運用に落とす：再現手順・期待値・ログ・影響範囲を「書かせる」仕組み
- Pleasanterの日付が1899/12/30で入ってくる問題：更新トリガーを汚さない弾き方（サーバースクリプト）
コメント