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

この章で学ぶこと：ご自身の既存スキル（Oracle SQL・Python・Dify/n8n）をカリキュラム内のどの章に対応させ、どの順で進めれば最短で Web アプリを公開できるかが分かります。
なぜ学ぶのか：全章を順番に読む必要はなく、既知の概念を飛ばすことで学習時間を 1/3 以下に短縮できるためです。
Web 開発のどの領域か：横断的なオリエンテーション章です。具体的な技術は b01 以降で扱います。

前提: 特にありません。まずこのページから読み始めていただければ十分です。

所要時間: 20 分（読解 10 分＋確認クイズ 10 分）

到達目標: 自身のスキルに合わせた学習順を 1 つ選び、最初の 60〜90 分で取り組むスプリント課題を決められる状態。

このカリキュラムが目指すもの

このカリキュラムの最終目標は「Web アプリをゼロから自力で公開できる状態」です。ゴールは ../sns_clone リポジトリで構築する SNS アプリの公開で、技術スタックは React + Hono + PostgreSQL + AWS（EC2・RDS・CloudFront・S3）です。

ただし、読者によってスタート地点が大きく異なります。本章は SQL・Python・Dify/n8n 経験者 が既存知識を活かし、最短で目標に到達するための学習パスを示します。

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

あなたが知っていること	対応する章	推奨対応
Oracle SQL（SELECT・JOIN・集計）	b15：DB 設計	「SQL → Drizzle ORM 対応表」だけ読めば十分です
Python（pandas・機械学習）	b09：JS 基礎、b10：TS 基礎	Python 対比のセクションを中心に読み進めます
Dify/n8n の API 呼び出し	b06：HTTP/REST	「Dify の API を例に」のセクションを確認する程度で構いません
Dify/n8n の認証設定	b07：認証・認可	「Dify API キー認証との対応」だけご確認ください
Dataiku/Alteryx のワークフロー	b05：Web アーキテクチャ	Web アプリ全体像の把握のため、一度通読することをお勧めします

スキップしてよい章: b01（シェル）・b02〜b03（Git/GitHub）・b04（pnpm）は開発作業をしながらご自身で調べても追いつけます。詰まったときの参照用として使ってください。

推奨学習順

ステップ 1：全体像をつかむ（1〜2 時間）

b05 → b06 → b07 → b13

「Dify/n8n で毎日やっていること」が Web アプリの文脈でどう表現されるかをご確認ください。新しい概念はほぼ出てきませんので、用語の対応関係を整理するイメージで読み進めていただけます。

ステップ 2：フロントエンドを集中的に学ぶ（メインの学習領域）

b08 → b09 → b10 → b11 → b12

ここが最も新しい領域になります。Python 経験者向けの対比説明が各章に入っていますので、Python の感覚を足がかりに読み進められます。

ステップ 3：バックエンド・DB の「TypeScript 化」を理解する

b13 → b14 → b15 → b16

SQL は既知のため、b15 は「Drizzle ORM 対応表」のみ確認いただければ十分です。b16（マイグレーション）は重要ですので、本番 DB を安全に変更するフローを必ずご理解ください。

ステップ 4：AWS デプロイ → テスト → Claude Code 活用

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

Docker と AWS（EC2・RDS）は新しい概念が多い領域ですが、Dify のセルフホストと構造が似ているため比較的スムーズに理解いただけます。

最初のスプリント課題（60〜90 分）

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

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

この課題を最初に選ぶ理由は次のとおりです。

Python の CSV 処理・pandas の感覚を TypeScript で再現できます。
Dify のワークフローと同じ「入力 → 処理 → 出力」の構造で理解しやすいです。
DB なし・認証なし・デプロイなしで「動くもの」を 1 セッションで完成できます。

コードかノーコードかの判断基準

Dify/n8n をすべてコードに置き換える必要はありません。「どこからコードにすると価値が上がるか」 を見極める視点が重要です。

シナリオ	判断	理由
Dify の API をフロントから呼び出す	コード（TypeScript）	秘匿情報の扱い・エラーハンドリングが必要です
n8n の Webhook を定期実行する	n8n 継続	コードにする理由がありません
CSV を読んで DB に格納する ETL	コードが有利	テスト・再実行・バージョン管理が容易です
Dify で作ったチャット UI を埋め込む	Dify 継続	埋め込みで十分です
承認フロー・ログ・監査証跡が必要	コード（＋DB）	規制対応・再現性のためにコードが必要です

Human-in-the-loop の考え方

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

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

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

セッションの進め方

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

今日できるようになること（5 分）— 目標を明確にします。
実装スプリント（45〜60 分）— 動くものを作ります。
振り返り（15 分）— 「現場のどのユースケースに使えるか」を確認します。

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

【他言語対応】表：このカリキュラムの位置付け

TypeScript は本カリキュラムの主軸ですが、既に慣れ親しんだ言語との対応を意識すると読み進めやすくなります。

言語／ツール Web アプリ開発での役割本カリキュラムとの関係
Python（pandas・FastAPI）データ処理・小規模 API 概念がほぼ共通。b09・b10 で TypeScript との対応を示します
Ruby（Rails）フルスタック Web フレームワーク Rails Guide は本カリキュラムの構成・粒度の参考元です
Go（net/http・chi）高速な API サーバー Hono の設計思想は Go 系フレームワークに近いです
Oracle SQL 関係データベース操作 PostgreSQL＋Drizzle ORM に読み替えます（b15 で対応表を提示）
Dify/n8n ノーコード・ローコード連携そのまま活かし、Web アプリのバックエンドから呼び出します

言語／ツール	Web アプリ開発での役割	本カリキュラムとの関係
Python（pandas・FastAPI）	データ処理・小規模 API	概念がほぼ共通。b09・b10 で TypeScript との対応を示します
Ruby（Rails）	フルスタック Web フレームワーク	Rails Guide は本カリキュラムの構成・粒度の参考元です
Go（net/http・chi）	高速な API サーバー	Hono の設計思想は Go 系フレームワークに近いです
Oracle SQL	関係データベース操作	PostgreSQL＋Drizzle ORM に読み替えます（b15 で対応表を提示）
Dify/n8n	ノーコード・ローコード連携	そのまま活かし、Web アプリのバックエンドから呼び出します

【アーキテクチャ】コラム：なぜ React + Hono + PostgreSQL + AWS を選ぶのか

選択肢: フロントエンドは React/Vue/Svelte、バックエンドは Hono/Express/Next.js API Routes、インフラは AWS/Vercel/Cloudflare など複数あります。

本カリキュラムの判断:

React: 採用企業・学習教材・AI 支援ツールのサポートが最も厚く、転用できる知識が多いためです。

Hono: 学習曲線が緩やか（Express に近い）で、TypeScript ファースト・Node.js / Cloudflare Workers / AWS Lambda のいずれでも動作するため、将来の移植性が高いです。

PostgreSQL: Oracle SQL の知識がほぼそのまま活きます。JSON 型・全文検索・拡張機能が豊富で、AWS RDS でのマネージド運用も容易です。

AWS: sns_clone のゴール構成に合わせています。Vercel や Cloudflare Pages はより手軽ですが、実運用の理解を優先するため本カリキュラムでは扱いません。

トレードオフ: 初期の学習コストは PaaS（Vercel 等）より高くなりますが、本番運用を見据えた知識が身につきます。

【セキュリティ】コラム：Human-in-the-loop が必要な理由

脅威: LLM の出力は確率的であり、機密情報の漏洩・事実と異なる内容の混入・意図しない外部 API 呼び出しを完全には防げません。

具体例: Dify で生成した「患者への返信メール草案」を人間の確認なしに送信する設計にした場合、患者氏名や疾患名を誤って別の患者に送るリスクが残ります。また、生成結果に含まれる指示を AI エージェントがそのまま実行してしまう「プロンプトインジェクション」にも無防備になります。

防御: 承認キュー（ダッシュボードや Slack 通知）を挟む／外部 API 呼び出しは明示的なボタン押下のみで発火させる／ログに入力・出力・承認者を必ず残す、の 3 点を最低限の防御線とします。本カリキュラムでは b20（テスト）と b23（コードレビュー）で具体的な実装例を扱います。

よくある詰まりポイント

スキップしてよい章（b01〜b04）を真面目に全て読んでしまい、本題のフロントエンド学習（b08〜b12）に到達する前に疲れてしまうことがあります。詰まったときの参照用という位置付けで構いません。
ステップ 1（全体像）を飛ばしていきなりステップ 2（フロントエンド実装）に入ると、リクエスト・レスポンスの流れが曖昧なまま React の学習が始まり、後で手戻りになりがちです。
「毎セッション動くものを作る」原則を忘れ、理論だけを積み上げるセッションになってしまうと進捗実感が失われます。毎回の初回 5 分で「今日できるようになること」を明文化することをお勧めします。

参考リソース

React チュートリアル（公式） — 本カリキュラムの構成・粒度の参考元です。
Rails Guides — 「フレームワークの Why を含めた網羅的解説」の手本として参照しています。
MDN Web Docs — Learn web development — Web 基礎の国際標準的な学習リソースです。
『Web を支える技術』山本陽平著（技術評論社） — HTTP・REST・URI を体系的に学べます。

確認クイズ

Q1. このカリキュラムで「スキップしてよい」と明示されている章の組み合わせはどれですか。

A. b05・b06・b07
B. b01・b02・b03・b04
C. b13・b14・b15・b16
D. b17・b18・b19

正解: B. b01・b02・b03・b04

解説: b01（シェル）・b02〜b03（Git/GitHub）・b04（pnpm）は開発作業をしながらご自身で調べても追いつける内容のため、詰まったときの参照用として使っていただければ十分です。ステップ 1 の推奨学習順にも含まれていません。

Q2. SQL・Python・Dify/n8n 経験者がステップ 1 で学ぶ推奨学習順として正しいものはどれですか。

A. b08 → b09 → b10 → b11
B. b13 → b14 → b15 → b16
C. b05 → b06 → b07 → b13
D. b17 → b18 → b19 → b20

正解: C. b05 → b06 → b07 → b13

解説: ステップ 1 は「全体像をつかむ（1〜2 時間）」フェーズで、Dify/n8n で毎日やっていることが Web アプリの文脈でどう表現されるかを確認することが目的です。新しい概念はほぼ出てこないため、用語の対応関係を整理するイメージで進められます。

Q3. 最初のスプリント課題（60〜90 分）で作る成果物として正しいものはどれですか。

A. 認証付きの SNS アプリ
B. CSV を読み込んで API で返し、画面に表示する小さな Web アプリ
C. Docker で PostgreSQL を立ち上げてマイグレーションを実行するスクリプト
D. Dify の API を呼び出してチャット UI を埋め込んだページ

正解: B. CSV を読み込んで API で返し、画面に表示する小さな Web アプリ

解説: DB なし・認証なし・デプロイなしで「動くもの」を 1 セッションで完成できるため、この課題を選んでいます。Python/pandas の感覚を TypeScript で再現でき、Dify の「入力 → 処理 → 出力」構造とも対応しています。

Q4. Oracle SQL 経験者が b15（DB 設計）に対してとるべき推奨対応はどれですか。

正解: 「SQL → Drizzle ORM 対応表」だけ読めば十分です。

解説: Oracle SQL の SELECT・JOIN・集計はすでに習得済みのため、新たに学ぶ必要はありません。TypeScript での ORM（Drizzle）がどの SQL に対応するかの対応表を確認するだけで、実務に使える知識が得られます。

Q5. 「n8n の Webhook を定期実行する」ユースケースに対して、このカリキュラムが推奨する判断はどれですか。

A. TypeScript コードに置き換える
B. n8n を継続して使う
C. AWS Lambda に移行する
D. Dify のワークフローで代替する

正解: B. n8n を継続して使う

解説: コードにする理由がないシナリオでは、ノーコードツールを継続するのが合理的な判断です。「どこからコードにすると価値が上がるか」を見極める視点が重要で、すでに動いているものをわざわざ置き換える必要はありません。

Q6. Human-in-the-loop パターンにおいて、AI の処理結果が本番 DB に反映されるタイミングはいつですか。

正解: 人間が確認・承認した場合のみです。

解説: AI が出力したものをそのまま本番適用する設計は避けるべきとされています。特に医療・製薬データを扱う場合は、ダッシュボードや Slack 通知などで人間が確認・承認した後にのみ本番 DB への反映や外部 API 呼び出しを行う設計が推奨されます。

Q7. 毎回のセッション構造として正しい順序はどれですか。

A. 振り返り → 実装スプリント → 今日できるようになること
B. 実装スプリント → 今日できるようになること → 振り返り
C. 今日できるようになること → 実装スプリント → 振り返り
D. 今日できるようになること → 振り返り → 実装スプリント

正解: C. 今日できるようになること → 実装スプリント → 振り返り

解説: 最初の 5 分で目標を明確にし（今日できるようになること）、45〜60 分で動くものを作り（実装スプリント）、最後の 15 分で「現場のどのユースケースに使えるか」を確認する（振り返り）という流れが学習効率を高めます。

Q8. 「承認フロー・ログ・監査証跡が必要」なシナリオに対する判断として正しいものはどれですか。

A. Dify 継続
B. n8n 継続
C. コード（＋DB）
D. TypeScript のみで DB は不要

正解: C. コード（＋DB）

解説: 規制対応・再現性のためにコードと DB が必要なシナリオとして明記されています。ノーコードツールでは監査証跡を確実に残すことが難しく、コードで実装することで再現性・バージョン管理・テストが容易になります。

Q9. Python 経験者がステップ 2（フロントエンド）を進める際のポイントとして正しいものはどれですか。

正解: 各章に含まれている Python 対比の説明を参考にしながら読み進められます。

解説: b08〜b12 のフロントエンド学習領域は最も新しい領域ですが、Python 経験者向けの対比説明が各章に含まれています。Python の感覚を足がかりにすることで、まったくの白紙から学ぶよりもスムーズに理解が進む設計です。

Q10. Dify/n8n 経験者が b06（HTTP/REST）に対してとるべき推奨対応はどれですか。

A. 全体を精読して 1 週間かけて学ぶ
B. 「Dify の API を例に」のセクション確認程度でよい
C. スキップしてよい
D. b05 の後に必ず 2 時間以上かけて学ぶ

正解: B. 「Dify の API を例に」のセクション確認程度でよい

解説: Dify/n8n の API 呼び出し経験者は HTTP/REST の基礎概念をすでに実践的に身につけているため、Dify を具体例にしたセクションを確認する程度で十分です。既存スキルとの対応表で明示されている推奨対応です。

この章で理解しておくこと

この章は導入編にある「考える」の章です。本文を読み終えたあと、次の観点だけ確認すると次へ進みやすくなります。

この章で理解すること:

自分の既存スキルに応じた学習順を選べる
飛ばしてよい章と重点的にやる章を判断できる

次に活きる章:

環境構築の段階的導入（macOS / Windows）
カリキュラム参照マップ（概念・領域・ステップ別）

補助参照: