Codex と Claude のレビューを通じて見えた「指摘の重要度と実害のズレ」を、勉強のためにまとめたものです。
ここで言う「web」は、綴ったものを web でも見られるように開発中のアプリ（紡Book）のことです。
AI にコードレビューをさせると、指摘に「P1」「Critical」のような重要度ラベルが付いてきます。便利なのだが、この重要度を鵜呑みにすると判断を誤ります。同じ指摘でも、それが本番で露出しているか・既に別の仕組みで緩和されているか・そもそも意図的な設計かで、実害はまるで変わります。綴Photo の Web とモバイル両方のレビューで、ちょうど良い実例が複数出たのでまとめる。
この記事で見ていく点
- feature flag で本番無効になっている指摘（露出していない Critical）
- レートリミットで既に緩和されている指摘（「制限なし」は不正確だった）
- そもそも意図的な設計だった指摘（バグではなく仕様）
Critical だが、feature flag で本番には出ていない
Web のレビューで、ある書き込み API に CSRF 保護（他サイトから勝手に操作を仕込まれるのを防ぐ仕組み）が漏れているという Critical 指摘が出た（別記事参照）。指摘自体は正しい。
ところが実コードを確認すると、その API は feature flag の管理下にあり、本番ではフラグがオフ＝そもそも URL が登録されていません。
危険度ゼロではない。危険が顕在化するタイミングが『フラグを入れる時』にずれているだけだ。
「制限なし」と言われたが、実はレートリミットがあった
共有ページのパスワードについて、レビューでは当初「試行回数の制限が無いので総当たりされうる」という指摘が出た。
実コードを確認すると、パスワード検証エンドポイントには「1分10回まで」のレートリミットが既に効いていた。
ただし、ここで「じゃあ問題なし」と判断するのも早いです。AI の指摘（試行制限なし）は不正確だったが、それで安心していいわけでもありません。指摘を裏取りして、正確な残リスクに置き換えるのが正しい読み方だった。
バグに見えて、実は意図的な設計だった
モバイル版のレビューで「デスクトップのフォルダ読み込み中、操作ボタンが無効になっている」という指摘が出た。一見、操作不能のバグに見える。
だが開発記録を確認すると、これは意図的な設計だった。読み込み中は操作画面ではなく「読み込み中プレースホルダ」を表示する作りになっていて、過去に「読み込みが終わる前に一瞬だけ操作画面がちらつく」問題を直したときの対応だった。
AI（Codex）自身も「完了待ちが意図ならコメントと UI 文言を合わせるべき」と留保を付けていた。正しい対応は「バグ修正」ではなく「意図をコメントに明記して、次に読む人（自分含む）が誤読しないようにする」だった。
このテーマの括り
3つに共通するのは、「コードの字面だけでは危険度は決まらない」ということ。AI レビューは網羅的に「コード上の問題」を挙げてくれます。これは非常に有用だ。だが重要度ラベルは「コードを見た時点の評価」であって、運用の文脈（フラグ・throttle・設計意図）を踏まえた「実害」とは別物。指摘を受け取る側が、本番実態と突き合わせて『実害に翻訳する』工程が要ります。
おわりに
AI にコードを書いてもらい、AI にレビューもさせる開発だと、「AI が Critical と言ったから全部今すぐ直さなきゃ」と焦りやすいです。危険度は「コードがどう書かれているか」だけでなく「それが今どう晒されているか」で決まります。指摘を一度立ち止まって裏取りすると、「今すぐ」「フラグを入れる前」「コメントを足すだけ」と、対応のタイミングと重さが分かれた。この翻訳の工程を挟むかどうかで、レビュー結果との付き合い方が変わります。
この記事は2026年5月時点の自分の理解で書いています。