第51章：デバッグの基本姿勢（まず落ち着く😌）🧘
この章は「デバッグは技術というより“手順”」って感覚をつかむ回だよ〜😊✨ うまくいかないときほど、焦ってグチャグチャにしがちなので…順番を固定しちゃおう！📌🧠
この章でできるようになること🎯✨
- 何か壊れたときに「どこから見ればいいか」迷わなくなる🧭
- 直感ではなく「事実→仮説→検証」で進められる🔬
- 直すだけじゃなく「再発防止」まで一歩進める🛡️
デバッグの“基本フォーム”はこれだけ🥋😌
困ったら、次の 7ステップ を順番に回すだけでOK🙆♂️✨
- 深呼吸（まず落ち着く）😮💨
- 症状を言語化（何が起きてる？）🗣️
- 再現手順を固定（同じ手で再現できる？）🔁
- 事実を集める（ログ/状態/設定）📋
- 原因候補を3つに絞る（仮説）🧠
- 1個ずつ潰す（検証は最小変更）🧪
- 直った証拠を残す（メモ＆再発防止）📝🛡️
ポイントはこれ👇 **「一気にいじらない」**が最重要😅（3か所変えると、どれが効いたか分からなくなる）
Dockerで“事実を集める”ときの鉄板セット📦🔍
まずは「今どうなってる？」を取る！これが最速ルート🏃♂️💨
-
動いてる？落ちてる？
docker ps/docker compose ps
-
何が起きた？（まず概要）
docker logs <container>/docker compose logs
-
どう落ちた？（終了コード・原因の手がかり）
docker inspect <container>（ExitCode / OOMKilled など）
-
中で確認したい？
docker exec -it <container> sh（または bash）
さらに最近は、“中がスリムでツールが無いコンテナ”でも調査しやすい docker debug が公式に用意されてるよ🧰✨（exec で入れない時の救済になりやすい）(Docker Documentation)
ハンズオン：わざと失敗させて「順番」を体に入れる😈➡️😌✨
ここでは Todo API を題材に、あえて “ありがちなミス” を仕込みます🧪 目的は 直すこと じゃなくて、「調べる順番」を守れること！💪✨
① わざと壊す（ミスを仕込む）💥😇
compose.yml の API サービスで、存在しない npm script を実行するように変えてみよう👇
（例：start を startt にタイポする感じ）
services:
api:
# （中略）
command: ["npm", "run", "startt"]
② まず “状態” を見る（焦ってログに飛ばない）🧭📦
- 起動してみる
docker compose up
- 別ターミナルで状態確認
docker compose ps
ここで見るのはこれ👇
- api が Exited になってない？😵
- 何秒で落ちた？（一瞬で落ちる＝起動コマンドや設定ミスが多い）⏱️
③ 次に “ログ” を見る（でも読みすぎない）🪵👀
docker compose logs api
この段階では、ログを「全文読破」しなくてOK🙆♂️ 見るのはここだけ👇
- 最後の20行あたりに “致命的な一行” があることが多い🎯
- 今回なら「missing script」系のメッセージが出がち
④ 原因候補を3つに絞る（ここがデバッグ脳🧠✨）
ログを見たら、頭の中でこう分類しよう👇
- 仮説A：コマンドが間違い（タイポ/存在しない）⌨️
- 仮説B：依存が無い（node_modules/ビルド不足）📦
- 仮説C：作業ディレクトリが違う（WORKDIR/パス違い）📁
ここで大事なのが、候補を増やしすぎないこと😅 3つに絞れば、検証が早い⚡
⑤ 検証は “1個だけ直す” 🧪✅
今回は仮説Aが濃厚だから、まず command を正しいものに戻す👇
command: ["npm", "run", "start"]
そして再起動！
docker compose up --build
⑥ 直ったかの “証拠” を取る📸✅
直った！で終わると、また忘れる😂 この3点をチェックして「勝ち確」にしよう🏆✨
docker compose psで api が Up ✅docker compose logs apiでエラーが止まってる ✅- ブラウザ or curl で疎通できる ✅
⑦ 再発防止（1分でいい）🛡️📝
おすすめはこのどれか1つだけでOK👇
- README に「起動コマンドは start」って1行残す📘
package.jsonの scripts を整理してタイポしにくくする🧹- CI（軽くでOK）で
npm run startを検証する✅
AI活用：症状→原因候補→確認手順を一瞬で出す🤖⚡
コツは「丸投げ」じゃなくて、テンプレで聞くこと！📌
そのままコピペ用プロンプト💬✨
あなたはDocker/Node/TypeScriptのデバッグコーチです。
次の情報から、原因候補トップ3（優先度順）と、
それぞれを確認する具体的コマンド（docker/compose）を出してください。
【症状】（例：docker compose up すると api がすぐ落ちる）
【やったこと】（例：compose.yml の command を変更した）
【状態】（docker compose ps の結果を貼る）
【ログ】（docker compose logs api の末尾50行を貼る）
最後に「最小変更で試す順番」を箇条書きで提案してください。
AIに貼るときは、ログは末尾だけで十分なこと多いよ〜✂️🪵✨
焦りがちな人がやりがちな“事故”あるある😵💫💥
- ❌ 3か所同時に直す → どれが効いたか不明
- ❌ いきなり再インストール → 原因が消えて学べない
- ❌ 「多分これ」だけで進む → 事実が足りない
- ❌ ログを見ずに設定いじる → 遠回り確定
対策はシンプル👇 **「状態→ログ→仮説3つ→1個ずつ」**これだけ守れば勝率上がる🥇✨
ちょい最新：困ったら docker debug も選択肢🧰🐳
最近の Docker には docker debug ってコマンドがあって、
スリムなイメージでシェルやツールが入ってなくても調査がしやすい方向に寄せてくれるよ〜🙌✨ (Docker Documentation)
あと、Docker Desktop は更新で不具合/安全面が直ることもあるので、詰まったときに「自分だけおかしい？」って感じたら、公式のリリースノートやセキュリティ告知もチラ見すると安心😌🔧 (Docker Documentation)
この章のミニまとめ🎉
- デバッグは センスじゃなく順番 🧭✨
- Dockerでは 状態→ログ→仮説→最小変更 が最短ルート🏃♂️💨
- “直す”だけじゃなく 証拠と再発防止 まで行くと強い🛡️📝
次の第52章では、いよいよ ログの読み方を筋トレして「次の一手」をもっと速くするよ〜🪵💪😄