前回との接続とこの講義の役割
前回のR-05では、コードを配布できる形へ変換するビルドと、実際にリクエストを処理する実行時を区別しました。ビルドで作られた成果物は、この時点ではまだ利用者のもとには届いていません。この講義では、その成果物を実行環境へ配置し、新しい版へ切り替えて使えるようにする工程、つまりデプロイを扱います。R章のなかでも、本番へ触れる操作の中心になる回です。
このスライドのポイント
- R-05: コードを配布できる形へ変換する「ビルド」と、実際に処理する「実行時」を区別した
- ビルド成果物は、まだ利用者のもとには届いていない
- この講義: その成果物を実行環境へ配置し、新しい版へ切り替えて使えるようにする工程を扱う
- R章のなかでも本番へ触れる操作の中心となる回
デプロイの技術的な定義
デプロイとは、ビルド成果物と設定を実行環境へ配置し、新しい版へ切り替えて利用可能にする一連の処理を指します。ここでいう設定とは、B-06やB-09で学んだ環境変数、つまり接続先や秘密情報のことです。現代のPaaSと呼ばれる仕組みでは、この一連が自動化されています。O-07で学んだpushが引き金となり、pushすれば自動でビルドが走り、そのままデプロイまで繋がる、という構成が一般的です。
このスライドのポイント
- デプロイ＝ビルド成果物（R-05）と設定を実行環境へ配置し、新しい版へ切り替えて利用可能にする一連の処理
- ここでの設定＝環境変数（B-06/B-09）。接続先や秘密情報のこと
- 現代のPaaS（実行基盤まで借りる形）では、この一連が自動化されている
- O-07で学んだpushが引き金となり、push→自動でビルド→デプロイまで繋がる構成が一般的
なぜデプロイを理解する必要があるか
デプロイが何をする処理か分からないままだと、本番反映という、A-09で学んだ最も高いリスクの操作を、意味を理解せずにAIへ任せてしまいます。特に多いのが、環境変数の設定漏れです。手元では.envというファイルに書いた設定で動くのに、本番では公開サービス側に別途設定が必要で、その存在を知らないまま公開して失敗します。これはB-06で学んだ環境差が、そのまま事故になった形です。
このスライドのポイント
- 意味が分からないままだと、本番反映（A-09の最高リスク操作）を理解せずAIに丸投げしてしまう
- 定番事故: 環境変数の設定漏れ
- 手元では.envというファイルの設定で動く／本番では公開サービス側に別途設定が必要（B-06の環境差）
- 「動くはずなのに本番で動かない」の多くはこの設定差が原因
デプロイの一連の流れ
デプロイの流れを順に追います。pushから始まり、ビルドが走り、成果物と環境変数が揃い、実行環境へ配置され、新しい版へ切り替わって、ようやく利用可能になります。ここで最も大切な注意点を一つお伝えします。コードは運ばれるが、.envは運ばれない、ということです。ソースコードは自動で送られますが、環境変数の中身は自動では運ばれず、本番側で別途設定しなければなりません。この一点を押さえるだけで、初回公開の失敗の多くを防げます。
このスライドのポイント
- 流れ: push → ビルド → 成果物＋環境変数 → 配置 → 版の切替 → 利用可能
- 最重要注意: コードは運ばれるが、.envは運ばれない（本番側で別途設定）
- ソースコードは自動で送られる／環境変数の中身は自動では運ばれない
- この一点を押さえるだけで初回公開の失敗の多くを防げる
Webアプリでの具体例
具体例で確かめましょう。経費アプリを初めて公開する場面です。手元では問題なく動いていたのに、本番ではデータベースへの接続に失敗します。原因を調べると、本番側に接続情報の環境変数が設定されていませんでした。B-06の環境差の表で見た「設定が違う」が、そのまま起きた形です。コードは運ばれても、接続先の設定は運ばれない。ですから、動かない理由がコードではなく設定にある、という切り分けが最初にできると、復旧が早くなります。
このスライドのポイント
- 経費アプリの初回公開: 手元では動くのに本番でデータベース接続に失敗
- 原因: 本番側に接続情報の環境変数が未設定
- B-06の環境差の表で見た「設定が違う」が実際に起きた形
- 切り分け: 「動かない理由はコードか設定か」を最初に見分けると復旧が早い
技術サンプルカード
サンプルは、デプロイのフロー図と、反映前に確認する3点です。前チェックは、環境変数を本番側に設定したか、マイグレーションを適用したか、そして問題が起きたときに戻す手段があるか、の3つです。マイグレーションはL-10で学んだデータベースの構造変更のことで、これも別途の反映が要ります。戻す手段については次回以降で詳しく扱います。AIへ頼むときは、このデプロイで必要な環境変数の一覧と、本番側に設定済みかの確認方法を教えてください、と聞きます。
このスライドのポイント
- 種別: diagram（デプロイのフロー図＋反映前チェック3点）
- 目的: デプロイの一連と、本番反映の前に確認すべき3点を一枚で確かめる
- サンプル本体:
混同しやすい概念
混同しやすいのが、pushとデプロイです。pushはO-07で学んだ、コードを共有する操作でした。デプロイは本番への反映です。両者は別物ですが、pushが自動デプロイに繋がる構成では、pushした瞬間に本番反映まで進みます。すると、pushの重みが、A-09でいう高リスク操作と同じになります。だからこそ、O-05で学んだブランチ運用が、本番を守る仕組みとして効いてきます。
このスライドのポイント
- pushとデプロイは別物
- push（O-07）＝コードを共有する操作／デプロイ＝本番への反映
- pushが自動デプロイに繋がる構成では、pushした瞬間に本番反映まで進む
- そのときpushの重みはA-09の高リスク操作と同じ／O-05のブランチ運用が本番を守る
バイブコーディングでの確認点
確認しておくべきは、mainブランチへのマージが、そのまま本番反映になる構成かどうかです。まず最初にこれを確かめてください。もしそうなら、mainへのマージは、O-10で学んだレビューと検査のフローを必ず通します。そして、B-06とA-09で学んだstaging-firstの原則どおり、本番へ触れる変更は、その手前の環境で先に確かめてから反映します。いきなり本番で初めて動かす、という状況を作らないことが要点です。
このスライドのポイント
- 最初に確認: mainブランチへのマージ＝本番反映になる構成かどうか
- そうなら、mainへのマージはO-10のレビュー・検査フローを必ず通す
- B-06・A-09のstaging-first原則: 本番へ触れる変更は、その手前の環境で先に確かめてから反映
- 「いきなり本番で初めて動かす」状況を作らない
- AIへの質問例: 「mainへのマージが本番反映になる構成ですか。反映前に通すべき確認は何ですか」
まとめと一問一答
最後に一問一答です。コードと一緒には自動で運ばれず、本番側で別途設定が要るものは何でしょうか。（間）答えは、環境変数です。接続先や秘密情報がこれにあたります。30秒まとめです。デプロイは、成果物と環境変数を実行環境へ配置し、新しい版へ切り替える一連の処理でした。コードは運ばれても.envは運ばれない、本番反映は高リスク操作としてstaging-firstで扱う。次回は、本番の手前にある環境たちを一つずつ見ていきます。関連資料は「Vercel公開 完全手順書」と「AIアプリ公開前チェックリスト100」です。なお公開サービスの画面は更新されることがあります。
このスライドのポイント
- 一問一答: 「コードと一緒には自動で運ばれず、本番側で別途設定が要るものは？」→ 環境変数（接続先・秘密情報）
- 30秒まとめ: デプロイ＝成果物＋環境変数を実行環境へ配置し、版を切り替える一連。コードは運ばれても.envは運ばれない。本番反映は高リスク操作としてstaging-firstで扱う
- 次回: 本番の手前にある環境たちへ
- 関連資料: 「Vercel公開 完全手順書」「AIアプリ公開前チェックリスト100」
