C
開発ツール/バイブ基礎/Lesson 04

バイブ基礎 — エラーの読み方・デバッグ・パッケージ管理

30分·theory

バイブ基礎 — エラーの読み方・デバッグ・パッケージ管理

🎯 このlessonを読み終えたら

このlessonをすべて読み終えたら、以下の3つを自信を持って実践できます。

  • ✅ エラーメッセージの読み方(stack traceの核心1行)
  • ✅ デバッグ4ステップ(再現・仮説・検証・修正)
  • ✅ AIデバッグ依頼の4要素テンプレート

学習目標をチェックリストとして持ち、すべて答えられるようになったらlessonを閉じてください。

エラーメッセージの読み方

一言で: エラーメッセージは答え。無視せず、末尾から逆に読む。

Stack Traceの読む順序:

code
Traceback (most recent call last):
  File "app.py", line 23, in main          # 最上部 = 最初のエラー
    process(data)
  File "app.py", line 15, in process       # 中間
    validate(item)
  File "app.py", line 8, in validate       # 最下部 = 実際のエラー
    raise ValueError("nil データ")          # ← ここから読む
ValueError: nil データ

3ステップ分析:
1. エラー: ValueError·NullPointerException·SyntaxError...
2. エラーメッセージ: 具体的な原因("nilデータ")
3. 場所: どのファイルの何行目か(一番下から逆に読む = 自分のコードを探す)

よく遭遇するエラー:

エラー意味解決策
NullPointerException (Java)nullオブジェクトのメソッド呼び出しnullチェック + Optional
Cannot read property of undefined (JS)undefinedのプロパティアクセスオプショナルチェーン ?.
ModuleNotFoundError (Python)importの失敗venvを有効化 + pip install
Address already in useポートが占有中lsof -ti :3000 \xargs kill
Permission denied権限不足chmod +x または sudo
CORS error異なるドメインによるブロックサーバー側でヘッダーを設定

> 💡 Googleの落とし穴: エラーメッセージ全体を検索しない。キーワードだけ"Cannot find module" express)。

デバッグの考え方 — 仮説・検証ループ

Iron Law: 根本原因なしに修正しない。「なんとかなりました」= 次回また発生。

デバッグ4ステップ:
1. 再現 — 100%再現できる最小ケースを作る(Hello, worldレベルまで)
2. 分析 — ログ・デバッガー・console.logprintデータフローを追跡
3. 仮説 — 「XのためにY」という明確な文章で
4. 検証 — 仮説通りに修正 → エラーが消えたか?消えなければ仮説が間違い

デバッグツール:

ツール用途
console.log / print素早い確認(production前に削除)
デバッガー(IDE・Chrome DevTools)ブレークポイント・ステップオーバー・変数検査
ログレベル(debug/info/warn/error)productionで使用
NetworkタブAPIリクエスト・レスポンス
Performanceプロファイラー遅延の原因
Heapスナップショットメモリリーク

高度なテクニック:

  • Binary search: 大きな変更 → 半分に切って原因を絞り込む
  • Rubber duck: コードを声に出して説明する — 半分はその過程で見つかる
  • タイムトラベルデバッグ: 一部のIDEが対応(変数の変化を逆追跡)
  • AIペア: エラー + コードをClaude/Copilotに貼り付け → 仮説候補を提示

よくある落とし穴:

  • ❌ 「再起動すれば直る」→ 放置して次の人への時限爆弾
  • ❌ try/catchでエラーを隠すcatch {})— 後で本物のバグが埋もれる
  • ❌ 一度に複数箇所を修正 → どれが効いたか分からない
  • ✅ 仮説1つずつ、変更1つずつ、即座に検証

🤖 AIデバッグ依頼テンプレート — *トークンを2〜3倍節約*

❌ このように依頼しないでください

code
"エラーが出ています。直してください。"

AIの最初の返答は「どんなエラーですか?コードを見せてください。環境は何ですか?」になります。1つの答えを得るために3〜5回のやりとり。毎回トークンが累積します。

✅ このように依頼してください — 4要素テンプレート

code
次のエラーが発生します:
[エラーメッセージ + stack trace 全体をコピー]

実行環境:
- 言語/ランタイム: Node 20 / Python 3.11 / Java 17
- フレームワーク: Next.js 15.4 / Spring Boot 3.2
- OS: Windows 11 / macOS 14

再現条件:
[どのような入力値/条件で発生するか — "users API GET /users/{id}
に id=999 を送信すると" のような具体的なシナリオ]

すでに試したこと:
- npm cache clean → 同じエラー
- node_modules 削除後再インストール → 同じ
- 他のルートは正常動作

原因と修正方法を教えてください。

なぜ効果的なのか

AIが答えに必要なコンテキスト4軸を一度に受け取れます:

1. エラー自体 — stack traceが最大の手がかり
2. 環境 — 同じコードでもバージョンによって動作が異なる
3. 再現条件 — 「常にそうなる」vs「この条件のときだけ」が核心
4. 試したこと — AIがすでに提示しようとしていた解決策をスキップできる

トークン比較 — 実測

悪い依頼(3ターンのやりとり):

code
私: エラーが出た。直して。   (50トークン)
AI: エラーメッセージを見せてください。 (30)
私: [コピー]  (200)
AI: 環境は何ですか?  (20)
私: Node 20。  (10)
AI: 回答  (1000)
合計: 約 1310 トークン

良い依頼(1ターン):

code
私: [4要素すべて含む]  (400)
AI: 回答  (1000)
合計: 約 1400 トークン

似たようなもの?違います — 最初の答えの品質が異なります。良い依頼は1回で正確な答え、悪い依頼は会話後に追加補強が必要となり、結局3000+トークン。

さらに節約するコツ

  • エラーメッセージが長い場合は核心だけ: Caused by:の行 + stack traceの最初の5行
  • 機密情報を削除: APIキー・パスワード・実際のユーザーデータ → <REDACTED>
  • 最小再現コード(MRE): 100行のうち問題のある10行だけを添付
  • stack traceが長すぎる場合は最初の5行+最後の5行

面接への応用

「AIツールはうまく使えますか?」→ この4要素テンプレートを答えれば合格。AI活用の深さを測る指標になります。

💻 📌 npm + pip 仮想環境の要点
# ═══════════════════════════════════════════
# npm — Node パッケージ管理
# ═══════════════════════════════════════════
npm init -y                         # package.json 自動生成
npm install <pkg>                   # 依存関係を追加 (dependencies)
npm install -D <pkg>                # 開発依存関係 (devDependencies)
npm install -g <pkg>                # グローバル (通常は避け、npxを推奨)
npm uninstall <pkg>                 # 削除
npm update                          # マイナー・パッチアップデート
npx <pkg>                           # インストールせずに1回実行 (create-next-app)

# package.json scripts 活用
# {"scripts": {"dev": "next dev", "lint": "tsc --noEmit"}}
npm run dev                         # scripts.dev 実行
npm run lint                        # 定義されたすべての script

# === よくある npm の落とし穴 ===
# 1. node_modules 破損 → 削除後再インストール
rm -rf node_modules package-lock.json && npm install
# 2. グローバル権限エラー → npx または nvm を使用 (sudo X)
# 3. ロックファイル無視 → チームビルドが壊れる。git add package-lock.json 必須

# ═══════════════════════════════════════════
# pip + venv — Python パッケージ管理
# ═══════════════════════════════════════════
python -m venv .venv                # プロジェクトごとの仮想環境
source .venv/bin/activate           # macOS/Linux
.venv\Scripts\activate              # Windows
which python                        # → .venv/bin/python (隔離確認)
deactivate                          # 仮想環境終了

pip install requests                # 依存関係をインストール
pip install -r requirements.txt     # 一括
pip install -e .                    # 編集可能 (開発用)
pip freeze > requirements.txt        # 現在のバージョンを固定

# === モダンなツール (pip の代替) ===
# uv: Rust ベース、pip より 10-100倍速い (2024+)
uv venv && uv pip install -r requirements.txt
# poetry: 依存関係 + パッケージング統合
poetry add requests && poetry install
# pipenv: Pipfile + Pipfile.lock

# === よくある落とし穴 ===
# 1. venv をアクティベートせずに pip install → システム Python が汚れる
# 2. requirements.txt のバージョン未固定 → 次のビルドが壊れる
#    ❌ requests        ✅ requests==2.31.0
# 3. .venv/ を git コミット → .gitignore に追加必須

🤖 AIへのおすすめの依頼方法

このlessonの概念を理解すれば、AIに具体的に指示できます。

  • 「次のエラー: [エラー全体を貼り付け] / Node 20 / 再現条件: [入力値] / 試したこと: [内容] — 原因と修正方法を教えて。」
  • 「このpackage.jsonの依存関係の競合を、npm lsの結果と一緒に診断して。」
  • 「このstack traceの核心1行を見つけて、デバッグ順序を4ステップで教えて。」

なぜこれがトークンを節約するのか

「エラーが出ました。直してください。」はAIが5回は聞き返します。環境 + 再現 + 試したことの3要素を一緒に送れば、一度で答えが返ってきます — トークン2〜3倍の節約。

次のおすすめ: ネットワーク
Vibe の基礎 — エラーの読み方・デバッグ・パッケージ - 開発ツール