このlessonを読み終えたら、以下の3つを自信を持ってできるようになります。

• ▸✅ バイブコーディング = AIペアプログラミング
• ▸✅ CLAUDE.md / .cursorrulesの作成でトークンを節約
• ▸✅ ハルシネーション対策チェックリスト5項目

学習目標をチェックリストとして手元に置き、すべてに答えられたらlessonを閉じましょう。

一言で言うと: バイブコーディング = AIと共にコードを作る手法。コードは成果物で、人間は意図・検証・アーキテクチャを担う。

3つの役割モデル:

AIが得意なこと:

• ▸✅ ボイラープレート (REST API CRUD・テストケース)
• ▸✅ 変換・リファクタリング (TS↔JS・class↔hook)
• ▸✅ ドキュメント・コメント・CHANGELOG作成
• ▸✅ エラーメッセージの解釈・デバッグ仮説

AIが苦手なこと:

• ▸❌ ドメイン知識のないビジネスロジック
• ▸❌ 大規模なアーキテクチャ決定
• ▸❌ パフォーマンス・セキュリティの評価 (仮説はOK、検証は人間)
• ▸❌ 意図と異なるもっともらしいコードの生成 (ハルシネーション)

> 💡 Iron Law: AIが生成したコードも自分の責任。コードレビュー能力がより重要になる。

トークンとは何か — おさらい

トークン = AIがテキストを読む単位。英語1単語 ≈ 1.3トークン、日本語1文字 ≈ 1〜2トークン。AIの応答ごとに入力トークン + 出力トークンの両方がカウントされ、課金されます。

出力トークンは5倍高い

→ AIが長く答えるほどコストが急増。質問が曖昧だと → AIがすべての可能性を安全に説明 → 出力トークンが爆発。

❌ 悪いプロンプト vs ✅ 良いプロンプト — トークンの差

例1: コード修正

❌ 悪い (推定出力2000トークン):
> 「このコード見てください」

→ AIがコード全体を書き直して表示しようとする。触らなくていい部分もすべて出力。

✅ 良い (推定出力100トークン):
> 「auth.tsの47行目の型エラーだけ修正して。他のコードは触らないで。変更箇所だけ見せて。」

→ AIがその一行だけを回答。出力トークンを20分の1に節約。

例2: 機能追加

❌ 悪い (推定出力3000トークン):
> 「ログイン機能を作って」

→ AIがすべてのオプション (OAuth・JWT・セッション・パスワードハッシュ・メール認証など) を説明してフル実装。

✅ 良い (推定出力800トークン):
> 「@CLAUDE.mdのスタック基準で。POST /api/auth/login。
> 入力: zodスキーマ (email, password)。
> 処理: bcrypt比較 → JWTアクセス15分 + リフレッシュ7日。
> レスポンス: httpOnlyクッキー。
> Vitestテスト含む。」

→ AIが明示された要件だけを正確に実装。

CLAUDE.md / .cursorrules — 繰り返しコンテキストの節約

会話のたびに「Next.js 14・TypeScript・Tailwindを使っています」と繰り返す必要がなくなります。

プロジェクトルートにCLAUDE.mdまたは.cursorrulesを作成:

# プロジェクトガイド

## スタック
- Next.js 15 (App Router)
- TypeScript strict mode
- Tailwind CSS + shadcn/ui
- Drizzle ORM + PostgreSQL

## コーディング規約
- コンポーネント: function 宣言 (arrow 禁止)
- import 順序: 外部 → 内部 → 相対
- 日本語コメント推奨

## 禁止パターン
- var 使用禁止 (const/let)
- any 型禁止
- テストのない新規関数禁止
- "TODO" コメントを残さない (issueとして)

このファイルをAIが毎回自動的に読み込んで応答に反映。繰り返し説明はゼロ。

トークン節約7つの実践ヒント

1. ファイルを明示: 「全部見て」ではなく → 「src/auth.tsだけ」
2. 変更範囲を限定: 「この部分だけ修正」
3. 結果フォーマットを明示: 「diffだけ見せて」・「コードのみ、説明不要」
4. CLAUDE.mdを活用: 繰り返しコンテキストを一度にまとめる
5. prompt caching: 同じシステムプロンプトはキャッシュ活用 (Anthropicで90%割引)
6. 小さいモデルから: Haikuを試して → 不十分ならSonnetへ
7. コンテキストを整理: 長い会話は要約のみを次の会話に引き継ぐ

まとめ

• ▸曖昧なプロンプト = トークン爆弾
• ▸具体的なプロンプト = AIが短く正確に応答
• ▸CLAUDE.mdがすべてのトークン節約の出発点

核心の一言

LLMは知らないことを正直に言いません。最ももっともらしい答えをでっち上げます。関数名・ライブラリバージョン・APIレスポンスすべてが偽物の可能性があります。

なぜそうなるか — 確率予測のメカニズム

LLMは「次に来る最も可能性の高いトークン」を予測します。本当に知らないという概念が存在しません。「もっともらしければそれが答え」という仕組みです。

例: 「ReactのuseSnapshotフックとは？」

• ▸事実: そのフックは存在しない (Valtioライブラリにはある)
• ▸AI: 「ReactのuseSnapshotはコンポーネントの状態スナップショットを保存するフックです。使い方は…」
• ▸→ 自信満々に嘘をつく

遭遇したときのチェックリスト

✅ 1. 関数・ライブラリの存在確認

• ▸公式ドキュメントでgrepまたはCtrl+Fで関数名を検索
• ▸npm view <pkg>またはpip show <pkg>でバージョン確認
• ▸リンクをクリック — AIが示したURLが404なら偽物

✅ 2. 実際に実行する

• ▸受け取ったコードをすぐに実行してみる
• ▸TypeScriptならコンパイルエラーを確認
• ▸ランタイムエラーは真実の暴露

✅ 3. AIに再確認を要求

> 「この関数は本当に存在する？公式ドキュメントのリンクをください。」

ほとんどの場合、AIは「確認したところ存在しません」と自白する。

✅ 4. 疑わしければ別のモデルでクロス検証

• ▸ClaudeからGPTに同じ質問
• ▸答えが違えばどちらかが間違い

✅ 5. バージョンを明示

> ❌ 「Next.jsで…」 → AIがどのバージョンか推測

> ✅ 「Next.js 15 App Routerで…」 → 明確なコンテキスト

よくでっち上げられる項目TOP5

1. 存在しないnpmパッケージ (react-magic-formのような一見もっともらしい名前)
2. 誤ったimportパス (from 'next/legacy'のような存在しないパス)
3. 存在しないオプション ({ strictMode: 'super-strict' }のような)
4. APIレスポンスのフィールド (response.data.user.premiumLevelのような存在しないフィールド)
5. バージョン間の混同 (Tailwind v3のオプションをv4と言う)

実際の事例 — 面接でよく聞かれる回答

> Q: 「AIハルシネーションを経験したことはありますか？」
>
> A: 「v0で生成したコードで存在しないshadcn/uiコンポーネント (Slider3D) が使われていました。公式docsと照らし合わせて発見し、それ以降はプロンプトに使用可能なコンポーネント名を明示するようにしています。
>
> またClaudeがnpm install zod-extrasという存在しないパッケージを自信満々に勧めました。npm viewで確認後、実際のzodのsuperRefineで代替しました。」

まとめ

• ▸AIは知らないとでっち上げる (確率メカニズムの限界)
• ▸公式docs・実際の実行・別モデルとのクロスチェックで検証
• ▸バージョン・正確な名前を明示して推測の余地を減らす

良いプロンプトの5要素 (CRISP):

悪いプロンプト vs 良いプロンプト:

❌ 「ログインAPIを作って」

✅ 「Next.js 14 App Router・TypeScript・Drizzle ORM環境。

POST /api/auth/loginエンドポイント:

• ▸入力: {email: string, password: string} (zod検証)
• ▸処理: usersテーブル検索 → bcrypt.compare → JWT(15分) + refresh(7日)発行
• ▸レスポンス: 成功200 + httpOnlyクッキー、失敗401
• ▸Vitestテストも含む (成功・失敗・不正入力ケース)」

追加テクニック:

• ▸One-shot example: 「この形式で回答して: [例]」
• ▸Chain-of-thought: 「ステップごとに説明してからコードを書いて」
• ▸Reasoning: 「このアプローチのトレードオフを先に分析してから決定して」
• ▸Constraint: 「外部ライブラリなし・50行以内」
• ▸Verification: 「コードを書いた後、自分で実行して結果を教えて」

> 💡 プロンプトはコード。PRのようにバージョン管理すると良い (Cursor Rules・CLAUDE.md)。

コンテキストウィンドウ = LLMが一度に読めるテキスト量 (トークン単位)。

モデル別コンテキスト:

1トークン ≈ 英語0.75単語 ≈ 日本語1〜2文字。コード1000行 ≈ 約4〜8Kトークン。

トークンエコノミクスの4原則:

価格比較 (2025) (1M入力 + 1M出力):

> 💡 高速・低コスト: Haiku → バランス: Sonnet → 品質: Opus。役割分担が正解。

一言で言うと: LLMは次のトークンの確率を予測する。考えるのではなく、最ももっともらしい答えを生成する。

4つの基本:
1. ハルシネーション — 知らないと言うより、もっともらしくでっち上げる
- 関数の存在確認 (./docs/api.mdをgrep)・ドキュメントリンクの検証・実際の実行テスト
2. コンテキスト長の限界 — 1Mトークンでも後半の情報が優先される
- 重要な情報はプロンプトの末尾に置く
3. 確率的な応答 — 同じ質問でも異なる答えが返ることがある
- 一貫性が必要な場合はtemperature=0 + seedを固定
4. 学習データのカットオフ — Claude Opus 4.7 = 2026-01カットオフ
- 最新情報はウェブ検索が必要 (WebSearchツール・Perplexity)

LLMの強みと弱み:

> 💡 LLMは高速で賢いが、監督が必要なツール。

このlessonの概念を理解すれば、AIに具体的に指示できるようになります。漠然とした「直して」ではなく、語彙を持ったリクエスト — それがトークン節約の出発点です。

• ▸「この曖昧なプロンプトを、スコープ・コンテキスト・制約・出力フォーマットの4要素で書き直して」
• ▸「このプロンプトはハルシネーションの可能性が高いから、エビデンス要求を追加して」

なぜこれがトークンを減らすのか

概念を知らないと、AIの回答を受け取っても「それって何ですか？」と再度質問しなければなりません。その「再質問」がトークンを消費します。概念を一度理解しておけば、会話が一発で終わります。