STEP 0: 自分のアプリを世界に公開する

ここまでに作ったアプリは、いま自分のPCの中（Live Server）でしか動きません。 このガイドでは、アプリのファイルを AWSのS3に置いて、世界中の誰でもURLで開ける状態＝「公開」にします。

前提: フロント編 STEP 6（第一目標）まで完成していること。バックエンド編まで済んでいればベスト

コードはもう書き終わっています。今日やるのは「作ったものを届ける」工程 ── 実務ではデプロイと呼ばれ、 どんなに良いアプリも、デプロイされなければ世界には存在しないのと同じです。

▼ ビフォーアフター — 緑の枠が、このガイドで自分が作る部分
🧑‍💻 いままで自分のPCのLive Server
→
🖥️ 自分のブラウザ自分しか見られない
🌍 これから世界中のブラウザ
→
☁️ CloudFront配達網（応用編）
→
📦 S3ファイル置き場（本編）

S3 にファイルを置けば公開は完成（本編・第一目標）。応用編ではその前に CloudFront を挟んで、HTTPS とキャッシュを手に入れる（第二目標）。
計算API（API Gateway + Lambda）はバックエンド編ですでにAWS上にある ── 今日フロント（画面）を S3 に置けば、画面も計算もすべて AWS の上で動くようになる。

▼ STEPごとに公開へ近づいていく
STEPやることクリアの条件
1自分のS3バケットを開く用意済みの自分のバケットを開ける
2アプリの3ファイルをアップロードバケット直下に3ファイルが並ぶ
3静的ウェブサイトとして有効化エンドポイントURLで 403 が出る（わざと！）
4公開設定で403を解決するエンドポイントURLでアプリが表示される
5公開URLで動作確認・API疎通確認公開URLで計算ができ、スマホでも開ける
6更新して再デプロイする🎉 第一目標クリア（公開と更新が自分で回せる）
7応用編 CloudFrontでHTTPS配信https:// のURLでアプリが開ける
8応用編 キャッシュの正体と無効化無効化で更新が反映される
9応用編 全体構成図を完成させて説明🏆 第二目標クリア
10拡張 拡張課題（好きなお題に挑戦）🚀 天井なし

STEP 6 までが全員のゴール。STEP 7〜10 は、余力があればチャレンジ！

進め方のルール
① AWSコンソールの画面・ボタンの名前は更新でよく変わる。このガイドと画面が違っても焦らない。見つからなければすぐメンターに聞こう
② 設定はまず自分で考えてやってみる。詰まったらメンターに声をかけてパスワードをもらい、「🔒 答えの設定例」を開こう
③ クリアの条件を満たしたらメンターに見せて、次のSTEPへ

STEP 1: 自分のS3バケットを開く

やることメンターが用意した自分専用のバケット（アプリのファイルを置く入れ物）をAWSコンソールで開く
到達チェックS3の一覧から、自分用のバケットを開ける
学ぶことS3 ＝ AWSのファイル置き場（容量無制限・落ちない）。リージョン ＝ データセンターの場所。利用者に近い場所を選ぶと速い ── だから日本向けは東京
📋 手順（AWSコンソール）
  1. メンターから配布されたアカウントで AWS コンソールにログインする
  2. 画面右上のリージョンが「東京 (ap-northeast-1)」になっているか確認する（違ったら切り替え）
  3. 上の検索バーで「S3」を検索して開く → バケット一覧を表示する
  4. 自分用のバケット（メンターが用意済み。名前はメンターが伝える）をクリックして開く
💡 バケットはパブリックアクセスがブロックされた状態で用意されている（だから今はまだ公開されていない）。公開は STEP 4 で自分の手で行う。
豆知識: バケット名は世界中で1つだけの一意な名前。世界に1つなのは、バケット名がこのあとURLの一部になるから。

STEP 2: アプリの3ファイルをアップロードする

やること自分のアプリの index.html / style.css / app.js をバケットの直下にアップロードする
到達チェックバケットを開くと、3つのファイルが直下に並んで見える
学ぶことS3に置いたファイルは置き場所がそのままURLのパスになる（index.html を直下に置く → URL/index.html）。Live Server のフォルダ構成と同じ感覚
📋 手順（AWSコンソール）
  1. バケット一覧から自分のバケット名をクリックして開く
  2. 「アップロード」→「ファイルを追加」（またはドラッグ＆ドロップ）
  3. index.html / style.css / app.js の3ファイルを選ぶ（フォルダごとではなく、ファイルを直接！）
  4. 「アップロード」を押し、3件とも「成功」になるのを確認する
💡 アップロードする app.js は、バックエンド編で自分のAPIに差し替えた版（まだなら仮のAPIのままでOK ── CORSが * なので公開後もそのまま計算できる）。どちらのURLが入っているかは STEP 5 の Network タブで確認できる。
⚠️ フォルダごとドラッグしないこと。フォルダごと上げると フォルダ名/index.html のように1段深くなり、 公開URLの末尾にフォルダ名を足さないと開けなくなる。バケットを開いて index.html が直下に見えていれば正解。

STEP 3: 静的ウェブサイトとして有効化する（わざと403を出す）

やることバケットの「静的ウェブサイトホスティング」を有効にして、もらえたURLを開いてみる
到達チェックエンドポイントURLにアクセスして「403 Forbidden」が表示される（← これで計画どおり！）
学ぶことS3は普段「ただの倉庫」モード。ウェブサイトモードにするとURLで開ける入口ができる。それでも403なのは、S3が「公開して」と明示されるまで何も公開しないから ── 安全側がデフォルト
📋 手順（AWSコンソール）
  1. 自分のバケットを開き「プロパティ」タブへ
  2. 一番下までスクロールして「静的ウェブサイトホスティング」→「編集」
  3. 「有効にする」を選び、インデックスドキュメントに index.html と入力 → 保存
  4. 保存後に表示される「バケットウェブサイトエンドポイント」のURL（http://xxxx.s3-website-ap-northeast-1.amazonaws.com）をクリックして開く
✅ 「403 Forbidden」が出たら成功。失敗ではなく、「入口はできたが、中身を見せる許可がまだ無い」という状態。 エラー画面を恐れず読むクセを付けよう ── 403 ＝「あなたには見せられません（拒否）」。誰でも見られるようにする許可は、次のSTEPで自分の手で出す。

STEP 4: 公開設定で403を解決する

やること「ブロックパブリックアクセス」をオフにし、「バケットポリシー」で読み取りを許可する ── 公開にはこの2つが両方必要
到達チェックエンドポイントURLをリロードすると、自分のアプリが表示される
学ぶこと公開は「2つの鍵」 ── ① ブロックパブリックアクセス ＝ 金庫の扉（開けない限り、どんな許可も無効）、② バケットポリシー ＝ 許可証（誰に・何を・どこまで許すかのJSON）。片方だけだと403のまま（実務でも定番のハマりポイント）
📋 手順（AWSコンソール）
  1. 自分のバケットの「アクセス許可」タブへ
  2. 「ブロックパブリックアクセス（バケット設定）」→「編集」→「パブリックアクセスをすべてブロック」のチェックを外す → 保存（確認の入力が出たら 確認 と入力）
  3. 同じタブの「バケットポリシー」→「編集」→ 下の穴埋めJSONを完成させて貼り付け → 保存
  4. STEP 3 のエンドポイントURLをリロードする
▼ バケットポリシーの穴埋め — ＿＿＿ を埋めて完成させよう（ヒントは右のコメント）
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": ＿＿＿, ← 「誰に」: 世界中の誰でも、を意味する1文字（引用符も忘れずに） "Action": "s3:GetObject", ← 「何を」: ファイルの読み取りだけ。書き込みは許さない "Resource": "arn:aws:s3:::＿＿＿/*" ← 「どこを」: 自分のバケット名。末尾の /* は「中の全ファイル」 } ] }
⚠️ 「公開したのに403」の定番原因 ── ① と ② のどちらか片方しかやっていない。両方やったのに403なら、 Resource のバケット名の打ち間違い・末尾の /* 忘れを疑おう。
🔒 詰まったら: 答えの設定例を見る（要パスワード）
🔒 パスワード解除後にここに答えが表示されます

STEP 5: 公開URLで動作確認・API疎通確認

やること公開URLでアプリを開いて計算を実行し、APIまで通ることを確認する。メンターやほかのインターン生にも開いてもらう
到達チェック公開URLで計算結果が表示され、メンターやほかのインターン生の端末からも開ける
学ぶこと画面（S3）と計算（API Gateway + Lambda）は別の場所から届いている。「自分のPCで動く」と「世界中で動く」の違いを体感する
🔍 「本当に公開されている」ことを確認する（証跡の取り方）
  1. 公開URLでアプリを開き、F12 → Network タブを開く
  2. 計算ボタンを押す → 一覧の calc をクリックし、宛先が自分のAPI・ステータスが 200 であることを確認する
  3. 自分の公開URLをメンターやほかのインターン生に開いてもらう（お互いのURLを開き合うのも◎）→ 自分のPC以外の端末からも表示されたら、正真正銘「世界に公開」されている
  4. 公開URLでアプリが動いている画面のスクショを撮っておく ── 成果発表の「公開した証拠」になる
💡 アプリのAPI呼び出しは何も変えずにそのまま動く。API Gateway の CORS を *（どこから呼んでもOK）にしてあるため、 呼び出し元が Live Server から S3 に変わっても受け付けてもらえる。もし「CORS policy」の赤いエラーが出たら、バックエンド編 STEP 4 の CORS 設定を見直そう。
▼ いまの構成 — 画面と計算は別の道で届く
🌍 ブラウザ世界中のどこでも
→
📦 S3html / css / js（画面）
🌍 ブラウザapp.js の fetch
→
🚪 API Gatewayバックエンド編で作成
→
⚙️ Lambda計算

STEP 6: 更新して再デプロイする

やることローカルでアプリを1か所変更し、同じファイル名で再アップロードして、公開URLに反映させる
到達チェック🎉 第一目標クリア ── 変更が公開URLで見える。「作る → 公開する → 直す」のサイクルが自分の手で回せる
学ぶことデプロイは1回きりではなく繰り返すもの。「更新したのに変わらない」第一の容疑者はブラウザのキャッシュ（前に見た画面の使い回し）
📋 手順
  1. ローカルの index.html を1か所変える（例: タイトルに「公開版」と足す、見出しの色を変える）
  2. S3のバケットを開き、変えたファイルを同じ名前のままアップロードする（同名は自動で上書き）
  3. 公開URLをリロードして、変更が見えることを確認する
  4. 変更が公開URLに反映されていることをメンターに見せる ── これで 🎉 第一目標クリア！
⚠️ 更新したのに画面が変わらないとき ── まず Ctrl+F5（スーパーリロード）。ブラウザは一度見たページを使い回す（キャッシュ）ことがある。 それでも変わらなければ、アップロード先のバケット・ファイル名が合っているか確認しよう。 ※「キャッシュのせいで古いまま」はこの後の応用編でもう一度、別の形で登場する（STEP 8）。

STEP 7: CloudFrontでHTTPS配信にする 応用編

やることCloudFront ディストリビューションを作り、S3の前に配置する
到達チェックhttps://xxxx.cloudfront.net で自分のアプリが開ける（アドレスバーに鍵マーク🔒）
学ぶことCloudFront ＝ 世界中に置かれた配達拠点（CDN）。利用者に近い拠点がキャッシュから返すので速い。そしてHTTPSが手に入る ── S3のウェブサイトURLは http:// のみ（通信が丸見え）。https:// は通信が暗号化され、改ざん・盗み見から守られる
📋 手順（AWSコンソール）
  1. 検索バーで「CloudFront」を開く →「ディストリビューションを作成」
  2. オリジンドメインで自分のバケットを選ぶ。「ウェブサイトエンドポイントを使用」ボタンが出たら必ず押す
  3. ビューワープロトコルポリシー: Redirect HTTP to HTTPS
  4. WAF（ファイアウォール）は「セキュリティ保護を有効にしない」を選ぶ（今回は学習用）
  5. 他はデフォルトのまま「ディストリビューションを作成」
  6. ステータスが「デプロイ中」→ 完了になるのを待ち、「ディストリビューションドメイン名」（xxxx.cloudfront.net）を開く
⚠️ 作成直後はデプロイ完了まで数分かかる ── 世界中の拠点に設定を配り終わるまでの時間。あせらず待とう（待ち時間にSTEP 8 のシミュレーターで予習するのがおすすめ）。 開いてエラーが出ても、まだ配り終わっていないだけのことがある。
▼ URLが2つになった — 違いを見比べよう
URLプロトコル経路
xxxx.s3-website-...amazonaws.comhttp のみ（鍵なし）毎回 S3 まで取りに行く
xxxx.cloudfront.nethttps（鍵🔒あり）近くの拠点がキャッシュから返す
🔒 詰まったら: 答えの設定例を見る（要パスワード）
🔒 パスワード解除後にここに答えが表示されます

STEP 8: キャッシュの正体と無効化を体験する 応用編

やることまずシミュレーターでキャッシュの動きを理解し、次に本物のCloudFrontで「更新が反映されない → 無効化で反映される」を体験する
到達チェック無効化（インバリデーション）のあと、変更が CloudFront のURLに反映される
学ぶことキャッシュ ＝ オリジン（S3）の代わりに手元の控えを返す仕組み。速くなる代わりに「古いまま」になることがある ── 速さと新しさのトレードオフ。無効化 ＝ 配信側がキャッシュを捨てさせる操作
▼ キャッシュシミュレーター — 3つのボタンを押して「更新したのに変わらない」を再現してみよう
いまの状態 ── S3の中身: バージョン1 ／ CloudFrontのキャッシュ: （空）

おすすめの実験: アクセス → アクセス（2回目はどこから返る？）→ 更新 → アクセス（あれ？）→ 無効化 → アクセス

📋 手順（本物のCloudFrontで体験）
  1. ローカルでアプリを1か所変更し、S3 に上書きアップロードする（STEP 6 と同じ）
  2. CloudFront のURL（xxxx.cloudfront.net）をリロード → 変わらない！（S3のエンドポイントURLでは変わっているのに）
  3. CloudFront のコンソールで自分のディストリビューションを開き「無効化」タブ →「無効化を作成」
  4. オブジェクトパスに /*（全ファイル）と入力して実行 → 完了を待つ（1分ほど）
  5. CloudFront のURLをリロード → 変更が反映される
⚠️ Ctrl+F5 で消せるのは自分のブラウザのキャッシュだけ。CloudFront のキャッシュはAWS側（配信側）にあるので、 見る人の操作では消せない ── 配信する側が「無効化」する。これが STEP 6 のブラウザキャッシュとの違い。 /* は「全ファイルを捨てる」指定で、実務では更新したファイルだけ指定することも多い。

STEP 9: 全体構成図を完成させて説明する 応用編

やること10日間で作った全部品を1枚の構成図にまとめ、各部品が「なぜ要るのか」を自分の言葉で説明できるようにする
到達チェック🏆 第二目標クリア ── メンターに構成図を見せながら、2分で全体を説明できる
学ぶこと部品の名前を覚えることではなく、「なぜそれが要るのか」を語れることが構成を理解したということ。成果発表の核になるスライドがここで完成する
▼ 自分のアプリの全体構成 — 全部、自分のAWSアカウントの中にある
🌍 ユーザーのブラウザ世界中のどこでも
→
☁️ CloudFrontHTTPS・キャッシュ
→
📦 S3html / css / js
🌍 ユーザーのブラウザapp.js の fetch
→
🚪 API GatewayAPIの玄関・CORS
→
⚙️ Lambda計算（Python）
→
🗄️ DynamoDB車種データ（応用）

道が2本あることに注目 ── 上は「画面を届ける道」（静的配信）、下は「計算結果を届ける道」（API）。 フロント編・バックエンド編・インフラ編で、この図の全部品を自分の手で作った。

▼ 説明の練習 — 発表で聞かれそうな質問。まず自分で答えてから、トグルを開いて答え合わせ
Q1. S3だけで公開できたのに、なぜCloudFrontを挟んだの？
主な理由は2つ。① HTTPSになる（S3のウェブサイトURLはhttpのみ。httpsは通信が暗号化され、利用者を守れる）。② キャッシュで速くなる（利用者に近い拠点が控えを返すので、毎回東京のS3まで行かなくていい）。
Q2. キャッシュって何？ 何が嬉しくて、何に困った？
一度取りに行ったものの控えを手元に置いて使い回す仕組み。嬉しいのは速いこと。困ったのは、S3を更新してもキャッシュが古いままで変更が反映されなかったこと（STEP 8）。配信側が「無効化」してキャッシュを捨てさせることで解決した。
Q3. HTTPSだと何が嬉しいの？ 鍵マークの意味は？
通信が暗号化され、途中で盗み見・改ざんされない。鍵マークは「このサイトとの通信は暗号化されていて、相手が本物だと証明されている」という印。今のWebでは公開サイトはHTTPSが当たり前（httpのままだとブラウザが「保護されていない通信」と警告する）。
Q4. リージョンって何？ なぜ東京を選んだ？
AWSのデータセンターがある場所のこと（東京・バージニア・フランクフルト…）。データは選んだリージョンに置かれる。利用者が日本なので、一番近い東京を選ぶと通信が速い。S3・Lambda・DynamoDBは全部東京に作った（CloudFrontだけは世界中に拠点がある）。
Q5. URLを開いてから画面に計算結果が出るまで、裏で何が起きてる？
① ブラウザがCloudFrontにアクセス → ② CloudFrontがキャッシュ（なければS3）からhtml/css/jsを返す → ③ 画面が表示され、app.jsが動き出す → ④ 計算ボタンでfetchがAPI Gatewayに飛ぶ → ⑤ Lambdaが計算してJSONを返す → ⑥ app.jsが結果カードに表示。この流れを構成図を指差しながら言えれば完璧。
🎤 発表準備のヒント
  1. 構成図は紙に手描きでもOK（draw.ioで清書したい人はSTEP 10へ）
  2. 集めたスクショを並べる: 公開URLのアプリ／スマホで開けた画面／F12のNetwork 200／無効化の画面
  3. 「一番ハマったところ」を1つ話せると、発表がぐっと面白くなる（403？ キャッシュ？）

STEP 10: 拡張課題 — 好きなお題に挑戦しよう 拡張

やること下のメニューから好きなお題を選んで挑戦する。順不同・いくつでもOK。着手前にメンターに一言伝えよう
到達チェックなし。ここから先は天井なし 🚀
学ぶことここまでは「決められたものを作る」、ここからは「何を作るか自分で決めて作る」。実務にいちばん近い部分
▼ 拡張課題メニュー（答えはありません。メンターと相談しながら自走しよう）
お題難易度できると何が嬉しい？ヒント
エラーページを作る★ 存在しないURLでも、自分のデザインの案内が出せる error.html を作ってアップロード → 静的ウェブサイトホスティングの「エラードキュメント」に設定 → わざと変なURLにアクセスして確認
キャッシュを観察する★★ 「速さ」と「新しさ」のトレードオフを自分の目で確かめられる F12 → Network でレスポンスヘッダーの x-cache（Hit / Miss）を観察。同じページを2回開くと？ 無効化の直後は？
構成図をdraw.ioで清書★★ 成果発表の説得力が一気に上がる STEP 9 の図を draw.io（diagrams.net）で描き直す。AWS公式のアイコンセットが組み込みで使える
独自ドメインを調べる★★ xxxx.cloudfront.net が「自分の名前のURL」になる未来を語れる 調査のみでOK（実際に付けるには会社のドメイン承認が必要）。「Route 53」「ACM証明書」「CNAME」を調べて、必要な手順をメンターに説明してみよう
自由課題？ 企画から自分でやる、いちばん実務に近い体験 「あったら便利」をメンターに提案して実装（例: 2つ目のバケットで別アプリを公開、S3のバージョニングで「間違って消した」に備える）