前回との接続とこの講義の役割
前回のR-04では、アプリがどのリージョンで動くのかという場所の話をしました。今回は、そこへ届ける中身がどうやって作られ、どう動くのかという時間の話に移ります。R章のここからは、コードを実際に公開する仕組みへ入っていきます。その最初の一歩として、公開の前に一度だけ走る工程と、公開後に何度も走る工程を、はっきり分けて理解します。
このスライドのポイント
- R-04では「どのリージョンで動くか」という場所の話をした
- 今回は「その中身がどう作られ、どう動くか」という時間の話へ
- R章はここから、コードを実際に公開する仕組みへ入っていく
- 最初の一歩として、公開の前に一度だけ走る工程と、公開後に何度も走る工程を分ける
ビルドとランタイムの定義
ビルドとは、私たちが書いたソースコードを、本番で動く形へ変換する工程です。たとえばF-10で学んだTypeScriptは、そのままでは実行されず、変換され、複数のファイルが束ねられ、最適化された成果物になります。一方ランタイムは、J-03で一度学んだとおり、その成果物が実際にリクエストを処理する工程のことです。この2つは、起きる時も場所も違います。ビルドは反映の前に一度だけ、ランタイムは利用のたびに走ります。
このスライドのポイント
- ビルド＝ソースコードを、本番で動く形（変換・束ね・最適化された成果物）へ変える工程
- 例: F-10のTypeScriptはそのままでは実行されず、変換されて成果物になる
- ランタイム（J-03で既習）＝その成果物が実際にリクエストを処理する工程
- 2つは起きる時も場所も違う: ビルドは反映前に1回、ランタイムは利用のたび
なぜこの区別が必要か
この区別を知らないと、ビルドエラーと実行時エラーを混同し、原因を調べる場所を間違えます。F-10ではこの2種類のエラーの違いを予告しましたが、本番ではその区別がそのまま調査の入口になります。もう一つのつまずきが環境変数です。B-09で扱った環境変数には、ビルドのときに値が埋め込まれるものと、実行時に読み込まれるものがあり、扱いを取り違えると設定したはずの値が反映されません。
このスライドのポイント
- 区別を知らないと、ビルドエラーと実行時エラーを混同し、調べる場所を間違える
- F-10で予告した「2種類のエラーの違い」が、本番では調査の入口になる
- 環境変数（B-09）の頻出のつまずき: ビルド時に埋め込まれる値と、実行時に読む値がある
- 取り違えると、設定したはずの値が反映されない
2工程のタイムライン
全体像を時間の流れで見てみます。左から、コードがあり、ビルドの工程で変換と検査が行われ、成果物ができ、それが実行環境へ配置され、そこで初めて実行時のリクエスト処理が始まります。注目してほしいのは、エラーが出る場所が2箇所あることです。ビルドの箱の中で止まるのか、実行時の箱の中で落ちるのかで、意味がまったく違います。ビルドは公開前の準備、ランタイムは公開後の稼働、と時間軸で覚えてください。
このスライドのポイント
- 時間の流れ: コード →［ビルド: 変換・検査］→ 成果物 → 配置 →［実行時: リクエスト処理］
- エラーが出る場所は2箇所ある（ビルドの箱の中／実行時の箱の中）
- ビルドは公開前の準備、ランタイムは公開後の稼働、と時間軸で覚える
どちらの時間の問題か
具体例で見ます。F-10の型検査はビルドのときに走ります。だから型の食い違いは本番に出る前、ビルドの段階で見つかります。反対に、K-06で扱った外部APIの障害は、実行してリクエストが飛んで初めて起きるので、実行時にしか現れません。同じ不具合の相談でも、それがビルドの時間の問題なのか、実行の時間の問題なのかで、P-10で学ぶ切り分けの向きが変わります。まず時間を特定することが、調査の遠回りを防ぎます。
このスライドのポイント
- F-10の型検査はビルドで走る → 型の食い違いは本番に出る前に見つかる
- K-06の外部API障害は、実行してリクエストが飛んで初めて起きる → 実行時にしか現れない
- 同じ不具合でも、ビルドの時間か実行の時間かでP-10の切り分けの向きが変わる
- まず「時間」を特定することが、調査の遠回りを防ぐ
技術サンプルカード
サンプルは、2つの工程の図と、代表的なエラーがどちらで起きるかの分類表です。型エラーと構文ミスはビルドで、外部API障害とDB接続の失敗は実行時に起きます。AIへ相談するときは、このエラーはビルド時と実行時のどちらで起きていますか、ログのどこでそれが分かりますか、と聞いてください。多くの公開サービスでは、ログの見出しがビルドの段階と実行の段階で分かれているので、そこを見れば時間を特定できます。
混同しやすい概念
混同しやすいのが、ビルドが通ったことと、実行して正しく動くことです。ビルドが通ったというのは、変換できる形式として正しかったという意味にすぎません。それは品質の入口であって、意図どおりに動く保証ではありません。実際に正しく動くかどうかは、P章で学ぶテストの領分です。ビルド成功は合格ではなく、スタートラインだと考えてください。
このスライドのポイント
- 「ビルドが通った」＝変換できる形式として正しかった、という意味にすぎない
- それは品質の入口であって、意図どおり動く保証ではない
- 「実行して正しく動く」かはP章で学ぶテストの領分
- ビルド成功は合格ではなくスタートライン
バイブコーディングでの確認点
バイブコーディングでの確認点です。公開に失敗したという相談では、まずビルドと実行のどちらで失敗したのかを最初に切り分けます。ログの見出しを見れば、多くの場合どちらの段階で止まったかが分かります。段階が分かってからでないと、AIに渡すべき情報も、直すべき場所も定まりません。時間の特定を、公開トラブルの一番最初の手順として習慣にしてください。
このスライドのポイント
- 公開に失敗した相談では、まずビルドと実行のどちらで失敗したかを切り分ける
- ログの見出しを見れば、多くの場合どちらの段階で止まったか分かる
- 段階が分かってからでないと、AIに渡す情報も直す場所も定まらない
- 「時間の特定」を公開トラブルの最初の手順として習慣にする
一問一答とまとめ
一問一答です。F-10で学んだ型検査が走るのは、ビルド時と実行時のどちらでしょうか。少し考えてみてください。答えは、ビルド時です。だから型の問題は、本番で動く前に見つけられます。30秒のまとめです。ビルドは公開前に一度だけ走る変換の工程、ランタイムは利用のたびに走る実行の工程で、エラーはこの2箇所のどちらかで起きます。次回のR-06では、この成果物を実行環境へ置いて利用可能にするデプロイへ進みます。関連資料は「Vercel公開 完全手順書」と「エラー文の読み方」です。
このスライドのポイント
- 一問一答: 「型検査（F-10）が走るのはビルド時と実行時のどちら？」→ ビルド時（だから実行前に見つかる）
- 30秒まとめ: ビルド＝公開前に一度だけの変換／ランタイム＝利用のたびの実行／エラーはこの2箇所のどちらかで起きる
- 次回R-06: 成果物を実行環境へ置いて利用可能にする「デプロイ」へ
- 関連資料: 「Vercel公開 完全手順書」「エラー文の読み方」
