切り分けとは

原因の候補はいくらでも思いつきます。切り分けは、確かめられる問いを順に当てて、候補を減らしていくことです。この講座では、次の4つの問いを順に使います。

1. 再現する条件を、比べて見つける

第2回の「全部壊れたように見えた」実例では、条件を1つずつ変えて比べました。

ここから「日本語をそのまま含むURL」と「パンくずを作る部分」の組み合わせで壊れる、と絞れました。動くものと動かないものの違いが、原因のありかを教えてくれます。

2. 直近で何を変えたか

障害の多くは、何かを変えた直後に始まります。新しい版の公開、設定の変更、外部サービスの更新などです。第4回の練習用ログでは、公開の35秒後に最初のエラーが出ていました。

naminori の「応募が失敗と表示される」不具合も、さかのぼるとメールの配信をやめた変更の日から始まっていました。通知の処理を書き換えたときに、求人の名前の取り方を間違えていたのです。

3. どの層で起きているか

第3回の層をもう一度使います。

ブラウザ → ネットワーク → Webサーバ → アプリ → データベース

naminori で実際にあったことです。2026年10月、AIキャリア診断の「無料で始める」を押しても、何も起きずにトップページへ戻されていました。

• 画面を、「どこから来たか」を一切送らない設定（Referrer-Policy）にしていた
• その設定が強すぎて、ブラウザがフォームを送るときに「送り元」を空にしていた
• アプリは、送り元が確かめられない送信を、なりすましの防止のため拒んでいた

このとき、コマンド（curl）や自動テストでは再現しませんでした。それらは、そもそも「送り元」を送らないからです。本物のブラウザでだけ起きることが、ブラウザの層を疑う手がかりになりました。さらに、この種類の拒否は、以前ボットのノイズを減らすために「エラー追跡ツールに送らない」と決めていた種類でした。本番のアプリのログには、送り元が空だったことを示す警告が残っていました。

自分の確かめ方では再現しない、ということ自体が情報です。 利用者と自分で、何が違うか（ブラウザ・ログインの有無・入力・時刻）を並べます。

4. 範囲を半分にする

候補が多いときは、半分ずつ確かめます。正常だった版と壊れた版の間に変更が10個あるなら、真ん中の版で試し、壊れていれば前半、正常なら後半に原因があります。これを繰り返すと、10個でも4回ほどで1つに絞れます。Git には、この作業を手伝う git bisect というコマンドがあります。

ログの範囲、設定の項目、入力の内容でも同じです。1つずつ全部試すより、半分に割るほうが速いのです。

仮説は、1つずつ確かめる

「たぶんこれだ」と思ったら、それを確かめる方法を決めてから試します。一度に2つ以上を変えないようにします。2つ変えて直ったら、どちらが効いたのか分からなくなります。

ここで後から困ること

• 推測で原因を決めつけると、記録に誤りが残る。naminori でも、ある調査で「本番のバグ」と書いた原因が、実は手元で実行したときだけ起きることだったと分かり、記録を訂正したことがあります
• 原因が分からないまま「直った」ことにすると、同じ障害がまた来て、そのときにまたゼロから調べることになる

• 切り分けの4つの問い
• 動くものと動かないものを比べる
• 直近の変更を疑う
• ブラウザでだけ起きた実例と層の考え方
• 半分にして絞る、仮説は1つずつ