このカリキュラムの使い方（SQL・Python・Dify経験者向け）

このカリキュラムは「Webアプリをゼロから自力で公開する」ことを目標に設計されている。ただし、読者によってスタート地点が大きく異なる。このガイドは SQL・Python・Dify/n8n経験者 が既存知識を活かしながら最短で目標に到達するための学習パスを示す。

あなたの既存スキルとカリキュラムの対応表

スキップしてよいファイル: b01（シェル）・b02〜b03（Git/GitHub）・b04（npm）は開発作業をしながら自習できる。詰まったときの参照用として使う。

b05 → b06 → b07 → b13

「Dify/n8nで毎日やっていること」がWebアプリの文脈でどう表現されるかを確認する。新しい概念はほぼないはずで、用語の対応関係を整理するイメージ。

b08 → b09 → b10 → b11 → b12

ここが最も新しい領域。Python経験者向けの対比説明が各ファイルに入っているので、Pythonの感覚で読み進められる。

b13 → b14 → b15 → b16

SQLは既知なので b15 は「Drizzle ORM対応表」のみ確認。b16（マイグレーション）は重要で、本番DBを安全に変更するフローを必ず理解する。

b17 → b18 → b19 → b20 → b21 → b22 → b23

DockerとAWS（EC2・RDS）は新しい概念が多いが、Difyのセルフホストと構造が似ているため理解しやすい。

初回セッションで目指す成果物：「CSVを読み込んでAPIで返し、画面に表示する」小さいWebアプリ

[入力] CSV（薬剤データ・患者集計など手元にあるもの）
  ↓ TypeScript API (Next.js Route Handler)
  ↓ データ整形・集計
[出力] ブラウザのテーブル表示

なぜこの課題か：

Dify/n8nをコードに置き換える必要はない。「どこからコードにすると価値が上がるか」 を判断する視点が重要：

AIが出力したものを「そのまま本番適用する」設計は避ける。特に医療・製薬データを扱う場合：

AI（Claude/Dify/LLM）が処理結果を生成
    ↓
人間が確認・承認（ダッシュボード・Slackで通知など）
    ↓
承認された場合のみ本番DBに反映・外部APIを呼び出す

このパターンはb20（テスト設計）・b23（コードレビュー）で詳しく扱う。

毎回のセッションは以下の構造で進めると学習効率が高い：

理論だけのセッションは設けない。毎回「動くもの」か「理解が深まった既存の仕組み」を持ち帰ることを目標にする。

本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。

ブランチの作り方・見方は b00-curriculum-map を参照してください。