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

• ▸✅ ポートフォリオ用トイプロジェクトを1週間で完成させるロードマップ
• ▸✅ AIが生成したコードのPR / README作成
• ▸✅ トークン使用量の計測 + 節約ポイントの把握

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

目標: 会社紹介・SaaSランディングページを1時間以内に。

ツール: v0 + Cursor + Vercel

1時間の計画:

v0プロンプト例:

SaaS landing page hero section:
- Headline + subtext
- CTA buttons (Get Started, Watch Demo)
- Background: gradient + animated grid
- Dark mode by default
- Use shadcn/ui components

主要パターン:

• ▸shadcn/ui — デザインシステムの一貫性
• ▸Next.js Image — 画像最適化
• ▸Framer Motion — 軽量アニメーション
• ▸Resend·Loops — メールフォーム

> 💡 完璧なデザインを追い求めない。目標は動くMVP。

目標: REST API + DB + 認証を一連の流れで。

スタック: Next.js 14 API Routes / Drizzle ORM / Postgres (Neon) / JWT

2時間の計画:

Claude Codeプロンプト例:

@CLAUDE.md の技術スタックに従い:
1. drizzle schema: posts (id·title·body·userId·createdAt)
2. /api/posts:
   - GET (list with pagination)
   - POST (auth required, zod validation)
   - PUT /:id (author only)
   - DELETE /:id (author only)
3. 各メソッドにvitestテスト（成功・認証失敗・認可失敗）
4. CIで自動実行

主要な学び:

• ▸APIコントラクト（input/outputの明示）
• ▸認証 vs 認可
• ▸エラーハンドリング・HTTPステータス
• ▸プロダクション対応のセキュリティ（レートリミット・入力検証）

目標: 会社ドキュメントを基にしたRAGチャットボット。

スタック: Next.js + Anthropic API + Postgres + pgvector + Vercel AI SDK

3時間の計画:

RAGの核心コードフロー:

// 1. チャンキング (langchain·llamaindex)
const chunks = await splitter.splitDocuments(docs);

// 2. 埋め込み
const vectors = await Promise.all(
  chunks.map(c => openai.embeddings.create({
    input: c.pageContent,
    model: 'text-embedding-3-small'
  }))
);

// 3. pgvectorへ保存
await db.insert(documents).values(/* ... */);

// 4. 検索（質問の埋め込み → コサイン類似度）
const results = await db.execute(sql`
  SELECT * FROM documents
  ORDER BY embedding <-> ${queryEmbedding}
  LIMIT 5
`);

// 5. Claudeにコンテキスト + 質問を送信
const stream = await anthropic.messages.stream({
  model: 'claude-sonnet-4-6',
  messages: [{
    role: 'user',
    content: `根拠:
${results}

質問: ${userQuestion}`
  }],
});

プロダクションの考慮事項:

• ▸チャンキング戦略（意味単位・固定サイズ・スライディングウィンドウ）
• ▸キャッシング（Redis）
• ▸レートリミット
• ▸ロギング（質問・根拠・回答）
• ▸評価（RAGAS・精度メトリクス）

1. AIツールの活用経験

• ▸「どんなツールを使う？なぜそのツール？」
• ▸「AIが生成したコードをどうやって検証する？」
• ▸「Cursor・Claude Code・Copilotの違いを説明して」

2. プロンプトエンジニアリング

• ▸「1つのプロンプトでうまくいかないときどう改善する？」
• ▸「Chain-of-thoughtの使用経験は？」
• ▸「プロンプトはどうバージョン管理する？」

3. LLMの限界の理解

• ▸「ハルシネーションに遭遇した事例・対応は？」
• ▸「なぜLLMは考えないのか？」
• ▸「コンテキストウィンドウが足りないときの戦略は？」

4. RAG・エージェント

• ▸「RAGとファインチューニングの違い」
• ▸「ベクトルDBの選択基準（Pinecone vs pgvector）」
• ▸「MCPがLSPに似ているとはどういう意味？」

5. 倫理・セキュリティ

• ▸「AIが生成したコードのIP問題」
• ▸「社内コードを外部LLMに送ってもいいのか？」
• ▸「AIがセキュリティ脆弱性を作ったとき、責任は誰に？」

良い回答パターン:

• ▸✅ 実際の使用経験（具体的なツール・プロジェクト）
• ▸✅ トレードオフの認識（どんな状況に適切・不適切か）
• ▸✅ 検証能力を強調（テスト・コードレビュー）
• ▸❌ 「AIが全部やってくれて楽です」（検証責任が弱い）
• ▸❌ 「全く使いません」（トレンドへの無知）

> 💡 核心メッセージ: AIが作ったコードも自分の責任。方向性・検証・アーキテクチャは人間の仕事。

面接官が聞くあの質問

> 「このPRのコード、AIが全部書いたんじゃないですか？」

焦らないでください。すべての面接官が聞きます。回答の準備が合否を決めます。

❌ 悪い答え

> 「はい、AIが書きました。私はプロンプトを書いただけです。」

→ 「ではあなたが何をしたのか」という追加質問に詰まる。不合格のリスク。

> 「AIは使っていません。全部自分で...」

→ git logで短時間に大きな変更が露見する — 嘘がバレる。即不合格。

✅ 良い答え — 3ビート

1. 正直に + 検証を強調

> 「はい、CursorとClaude Codeを積極的に活用しました。コードの生成はAIが素早くやってくれましたが、
>
> 1. 検証は私が直接行いました — VitestでユニットテストのカバレッジをCC80%、PlaywrightでE2Eテストを作成。
> 2. トレードオフの判断も私の役割でした — 例えばDrizzle vs Prismaを選ぶ際、DrizzleのよりコンパクトなバンドルサイズとTypeScript推論の精度を優先しました。
> 3. アーキテクチャの決定 — 最初AIがREST APIを提案しましたが、リアルタイム通知の要件のためWebSocket + SSEハイブリッドに変更しました。」

→ 面接官の頭に「この人はAIをコントロールできる」と刻み込まれる。

2. AIができなかったことを明示

> 「AIが最初に生成したコードで発見した3つの問題:
>
> 1. N+1クエリ — User → Orders → Itemsを取得するとき。Drizzleのwithで一度にJOIN。
> 2. レースコンディション — 同時決済で残高がマイナスに。PostgreSQLの行レベルロックを追加。
> 3. XSS脆弱性 — dangerouslySetInnerHTMLをそのまま使用。DOMPurifyを導入。」

→ 問題発見能力の証明。AIより人間の判断が優れている。

3. 再現可能なワークフロー

> 「再現できるようCLAUDE.mdとspec.mdをgitに含めました。新しいチームメンバーが来ても同じコンテキストでAIと協業できます。
>
> またプロンプト自体もバージョン管理しています — prompts/フォルダに頻繁に使うプロンプトテンプレートを保存しています。」

→ チーム協業 + 再現性を強調。チームで働ける人のマインドセット。

面接実践Q&A — 模範回答

Q1: ハルシネーションに遭遇した事例は？

> 「v0が存在しないshadcnコンポーネント（<Slider3D>）を使いました。公式ドキュメントと照合して発見し、それ以来プロンプトに使用可能なコンポーネント名を明示しています。
>
> またClaudeがnpm install zod-extrasを勧めましたが、npm viewで存在しないことを確認。実際にはzodのsuperRefineで代替できました。」

Q2: コンテキストが不足しているときの戦略は？

> 「1) まずCLAUDE.mdに不足している部分を追加
> 2) それでも足りなければ関連ファイルを明示してプロンプトに添付（@src/auth.ts）
> 3) 本当に大きな作業なら先にSpecを書いて後続会話のコンテキストを節約」

Q3: SPEC-Driven vs Vibe、いつどちらを使う？

> 「1時間以内に終わるプロトタイプはVibe。
> 複数人協業・決済・認証のようなリスクの高い領域はSPEC。
>
> 判断基準：後でこのコードをデバッグする誰かにとって、specがあると速くなるか？ → YESならSPEC。」

Q4: AIが生成したコードのセキュリティ・IPは？

> 「1) セキュリティ: AIが生成したSQL・認証コードは必ずOWASP Top 10チェック。パラメータ化クエリ・bcrypt・HTTPSを強制。
>
> 2) IP: 社内コードを外部LLMに送るのは法的問題。Copilot Businessまたは社内LLMの使用を推奨。
>
> 3) ライセンス: 学習データのGPLコードの偶発的複製リスク。コアアルゴリズムは直接記述または許可されたライブラリを使用。」

まとめ

• ▸AI使用を正直に認める
• ▸検証・判断・アーキテクチャが自分の役割と強調
• ▸AIができなかったことを具体的に提示
• ▸CLAUDE.md・spec.mdをgitに含める — 再現性

[1時間プロジェクト] ランディングページ — トークン節約ポイント

核心: v0 → Cursorの流れが最も効率的。

⚠️ やってはいけないこと: 「このランディングページを別のデザインで作り直して」 — 全体再作成 = トークン爆弾

[2時間プロジェクト] CRUD API — トークン節約ポイント

核心: spec.mdを先に、次に1エンドポイントずつ。

⚠️ やってはいけないこと: 「CRUD API全部作って」 — 一度に出力すると5000以上のトークン、しかも各エンドポイントの検証が困難

[3時間プロジェクト] RAGチャットボット — トークン節約ポイント

核心: 最も複雑 → Spec-Kit活用 + ステップバイステップの検証が必須。

⚠️ やってはいけないこと: 「RAGチャットボットを最初から最後まで全部作って」 — specなしで始めると5回の再作成。本物のトークン爆弾。

まとめ

3つのプロジェクトすべての共通原則:
1. 段階を分ける — 一度に全部はX
2. ファイル・範囲を明示 — 「@auth.tsのX関数だけ」
3. specを先に — プロジェクトが大きいほど効果大
4. 頻繁に検証 — git commit + テスト

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

• ▸「このトイプロジェクトをポートフォリオ用PRにまとめて（README + デモGIF + 振り返り）」
• ▸「この作業のトークン使用量を分析 + 節約ポイントを教えて」

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

概念を知らないと、AIの回答を受け取った後も「それって何ですか？」と再度聞かなければなりません。その再質問がトークンを消費します。概念を一度身につければ、会話が一度で完結します。