前回とのつながりと、この講義の役割
前回のP-09 では、ログ、スタックトレース、デバッガという、内部を覗く3つの道具を学びました。ただ、道具を持っていても、どこを覗けばよいのかがわからなければ、その力を発揮できません。この講義では、不具合の在り処を絞り込む地図を用意します。これはカテゴリPの締めくくりであると同時に、これまでの講座全体の総復習にもなります。
このスライドのポイント
- 前回P-09: ログ・スタックトレース・デバッガという内部を覗く3つの道具を学んだ
- ただし、どこを覗けばよいかがわからなければ道具は力を発揮しない
- この講義の役割: 不具合の在り処を絞り込む「地図」を用意する
- カテゴリPの締めくくりであり、講座全体の総復習でもある
原因切り分けとは
原因切り分けとは、不具合の在り処を、データの通り道に沿って段階的に絞ることです。A-03 で見た構成要素からD-09 で見た経路まで、データは決まった道を通ります。その道を7つの層に分けて考えます。入力、画面、通信、サーバー、データベース、外部API、そして環境の7層です。絞り方の発想が二分探索です。端から順に調べるのではなく、真ん中で観測して、原因が前半にあるか後半にあるかを、1回で半分に絞ります。
このスライドのポイント
- 原因切り分け＝不具合の在り処を、データの通り道に沿って段階的に絞ること
- データは決まった道を通る（A-03の構成要素→D-09の経路）
- その道を7層に分ける: 入力→画面（I章）→通信（C/D章）→サーバー（J章）→DB（L章）→外部API（K章）→環境（B-06/B-10）
- 絞り方の発想は二分探索: 真ん中で観測して、前半か後半かを1回で半分に絞る
なぜ切り分けが必要か
切り分けの言葉を持たないと、「動きません」から先へ進めません。AIに現状を丸ごと渡して、当てずっぽうの修正を繰り返すことになります。逆に、どの層まで正常だと確認できているかをAIに伝えられれば、その精度は桁違いに上がります。これは、D-09 で予告した切り分けの、完成した姿でもあります。切り分けの言葉は、そのままAIへの良い指示の言葉になります。
このスライドのポイント
- 切り分けの言葉がないと「動きません」から先に進めない
- AIに現状を丸ごと渡して、当てずっぽうの修正を繰り返すことになる
- 「どの層まで正常か」を伝えられれば、AIの精度は桁違いに上がる
- D-09で予告した「切り分け」の完成した姿
7層の切り分け地図と観測手段
7層の切り分け地図を見てみましょう。それぞれの層には、対応する観測手段があります。画面はH-07 で見た状態表示、通信はD-06 のステータス番号、サーバーはJ-08 のログ、データベースはL-06 のSELECTで直接中身を確認できます。外部APIはK-06 の応答、環境はB-06 やB-10 で見た実行場所の違いです。この地図は、これまでの講座で学んだ確認方法が、1枚に集まったものだと言えます。
このスライドのポイント
- 7層それぞれに、対応する観測手段がある
- 入力＝何が入ったか／画面＝H-07の状態表示／通信＝D-06のステータス番号／サーバー＝J-08のログ／DB＝L-06のSELECTで直接確認／外部API＝K-06の応答／環境＝B-06・B-10の実行場所
- この地図は、講座で学んだ確認方法が1枚に集まったもの
- どの観測手段を使うかは、疑う層で決まる
二分探索で追い込む具体例
「一覧に新しい申請が出ない」という不具合を、二分探索で追ってみます。まず、真ん中あたりのデータベースを直接見ます。L-06 のSELECTで確認すると、行はちゃんと増えていました。ここで原因は後半、つまり取得から画面までに絞られます。次にAPIの応答をD-04 で見ると、データは正しく返っています。すると残るは画面層です。I-10 で学んだ再検証漏れが原因だと確定しました。3回の観測で、7層が1層まで絞れました。
このスライドのポイント
- 題材:「一覧に新しい申請が出ない」
- ①真ん中のDBを直接見る（L-06のSELECT）→行は増えていた→原因は後半（取得〜画面）に絞られる
- ②APIの応答を見る（D-04）→データは正しく返っている→残るは画面層
- ③画面層に確定（I-10の再検証漏れ）
- 3回の観測で、7層が1層まで絞れた
技術サンプル: 7層の切り分け地図
今回のサンプルは、7層の切り分け地図そのものです。各層と観測手段を対応させ、真ん中から観測する矢印を添えています。読み方の要点は3つあります。1つ目、症状が出た場所ではなく、データの上流から順に層を疑うこと。2つ目、端からではなく真ん中から観測して、半分に割ること。3つ目、各層には必ず対応する観測手段があること。AIには最初に観測すべき層と確認方法を提案させると、切り分けの心強い相棒になります。
混同しやすい概念: 症状の場所と原因の層
混同しやすいのが、症状の場所と、原因の層です。「画面に出ない」という症状は、いちばん下流の画面で目に見えます。しかし原因は、データベースかもしれず、通信かもしれません。症状は最下流に出るが、原因は上流にある。これが切り分けの定石です。だからこそ、症状の場所をすぐ疑う前に、上流から順にたどって、どこまでが正常かを確かめる必要があります。
このスライドのポイント
- 「症状の場所（画面に出ない）」vs「原因の層（画面とは限らない）」
- 症状は最下流に出るが、原因は上流にある——これが切り分けの定石
- 「画面に出ない」の原因は、DBかもしれず、通信かもしれない
- だから、症状の場所を疑う前に、上流から順にたどる
バイブコーディングでの確認点
バイブコーディングでの確認点です。P-08 で学んだ再現条件の5点セットに、「どの層まで正常だと確認済みか」を1行足してみましょう。これで完璧なデバッグ依頼になります。テストがAIの出力の検収装置であるのと同じように、この切り分けの地図は、AIへの指示の精度を上げる装置です。どの層まで正常かを渡してから相談する。この型を身につけることが、カテゴリPの卒業制作です。
このスライドのポイント
- P-08の再現条件の5点セットに「どの層まで正常確認済みか」を1行足す
- これで完璧なデバッグ依頼になる（カテゴリPの卒業制作）
- テストがAIの出力の検収装置であるのと同じく、切り分けの地図はAIへの指示の精度を上げる装置
- AIへの質問例:「私はDBまで正常を確認しました。次に観測すべき層と確認方法を教えてください」
まとめと次回
最後に一問一答です。切り分けを速くする探索の発想は何でしょうか。（間）答えは、二分探索です。真ん中で観測して、原因を一度に半分に絞ります。30秒まとめです。原因切り分けとは、7層の地図に沿って原因の在り処を絞ること。症状は最下流に出ますが、原因は上流にあります。二分探索で真ん中から観測すれば、少ない回数で犯人にたどり着けます。これでカテゴリPは修了、見つける・直す・守るの一式が揃い、Step 4 を完走しました。次回からはカテゴリQ、安全性の本丸へ進みます。関連資料は「エラー文の読み方」「エラー解決プロンプト50」「アプリ運用チェックリスト」です。
このスライドのポイント
- 一問一答:「切り分けを速くする探索の発想は？」→ 二分探索（真ん中で観測して半分に絞る）
- 30秒まとめ: 原因切り分け＝7層の地図に沿って原因の在り処を絞ること／症状は最下流・原因は上流／真ん中から観測すれば少ない回数で犯人に届く
- カテゴリP修了。見つける・直す・守るの一式が揃い、Step 4 を完走
- 次回: カテゴリQ、安全性の本丸へ
- 関連資料:「エラー文の読み方」「エラー解決プロンプト50」「アプリ運用チェックリスト」
