Codex と Claude のレビューで浮かんだ「指摘の優先度の付け方」まわりの観察を、勉強のためにまとめたものです。
コードレビューで見つかる問題には、ざっくり2種類あります。「今すでに効いている穴」と、「ある機能を有効化した瞬間にはじめて効く穴」です。後者は本番の入口が機能フラグで閉じられていて、今は誰も到達できません。ここで「今は届かないから」と重要度を下げて忘れると、いざフラグを点けた瞬間に眠っていた穴が一斉に発火します。
この記事は、その「今は届かない穴」をレビューでどう扱うか、という優先度の付け方の話だ。
この記事で扱う観察ポイント
- 機能フラグの裏に隠れた問題を「深刻さ」だけで並べると、なぜ忘れられるのか
- 「いつ効くか（発火タイミング）」を2本目の軸にして仕分けるやり方
- データ系（保存・上書き・削除）の穴がとくに後回しと相性が悪い理由
コードで起きていたこと
写真日記アプリ（綴Photo）のレビューで、ある一連のAPI群がフラグの裏に隠れている構造が浮かんだ。ルーター（受け取ったリクエストをどのAPIに渡すか振り分ける、サーバ内の交通整理役）への登録が環境変数（サーバの起動設定として外から渡す値。ここでは「この機能をオンにするか」のスイッチをコードの外側から差し込むために使う）によるフラグで条件分岐していて、本番ではその機能群がそもそも読み込まれない、という形だ。
匿名化した疑似コードで構造だけ示すと（実際のコードとは変えてある）、おおよそこうなっている。
# 機能フラグで、API群を登録するかどうかを切り替える
ENABLE_FEATURE_X = get_env_flag("ENABLE_FEATURE_X") # 本番では false
def register_routes(app):
app.include(public_routes) # 常に有効
app.include(account_routes) # 常に有効
if ENABLE_FEATURE_X:
# この一連のAPI（保存・上書き・編集まわり）は
# フラグが立っているときだけ登録される
app.include(feature_x_routes)この feature_x_routes の中に、レビューで気になる挙動がいくつかあった。ただし本番では ENABLE_FEATURE_X が立っていないので、これらのAPIは今この瞬間、外から誰も叩けません。エンドポイント（外から呼び出すときの入口となるURL）自体が存在しないのと同じ状態です。
ここで判断が分かれる。「今は到達できないから、重要度は低くていいか?」
なぜそうなりやすいか
レビューの指摘を並べるとき、無意識に「深刻さ」という1本の物差しだけで並べてしまいがちです。深刻さで並べると、機能フラグの裏の指摘は不思議な位置に来ます。中身は深刻（データを壊しうる）なのに、「今は誰も踏めない」という事実が効いて、体感の優先度がぐっと下がります。
問題は「深刻さ」と「到達可能性」という別々の性質を、1本の物差しに混ぜて潰してしまうことにあります。到達可能性は時間とともに変わる（フラグを点ければ変わる）のに、それを「今の深刻さ」として固定で評価してしまいます。
とくにデータ系（保存・上書き・削除）は、この後回しと相性が悪いです。表示や見た目の不具合は、点けてから気づいても直して作り直せます。だがデータの上書きや削除は、点けてから気づいたときには既に何かが失われていることが多いです。写真日記のような一点物のデータは、一度壊れると戻せません。「点けてから気づく」が一番効いてはいけない領域です。
改善の方向
物差しを2軸に分けます。深刻さ（どれだけ壊れるか）はそのまま残し、もう1本「発火タイミング（いつ効くか）」を足します。そして指摘を、深刻さで並べる前に、まずタイミングで束ねます。
タイミングの分類は、たとえばこの3つで足ります。
- 公開前マスト … 今すでに効きます。本番に出す前に必ず塞ぎます
- 機能開放前マスト … 今は届かないが、フラグを点ける前に必ず塞ぎます
- 後回し … 効いても軽いです。落ち着いてから
こうすると、機能フラグの裏の深刻な穴は「機能開放前マスト」という棚に入ります。「今は届かないが、点ける前に必ず塞ぐもの」として、忘れられずに棚で待てます。
軸を1本から2本にすると、同じ指摘の居場所がこう変わります。
運用としては、各指摘に「深刻さ」と「発火タイミング」の2つのタグを付け、タイミングで束ねてから着手順を出します。
学びポイント
- 「今は到達不能」はバグが無い証明ではありません。 経路が今ふさがっているだけで、中の問題はそのまま残っています。設定でオフにしている機能の中身が安全だ、という話ではありません。
- 優先度は固定の性質ではなく、いつ・誰が踏むかという文脈で決まります。 深刻さ1本で並べると、この「いつ効くか」という時間の軸が潰れます。段階的ロールアウト（一度に全員へ公開せず、対象を少しずつ広げていくリリースの仕方）や条件付きの有効化のように「今はオフだが、いつか点く」コードを抱えているときは、同じ物差しでは並べきれません。
- フラグを点ける意思決定が、棚を空ける締め切りになります。 「この機能を開放する」と決めた日に棚卸しする、という形でセットにしておきます。
この記事は2026年6月時点の自分の理解で書いています。仕様や認識が変わってる可能性があります。