「どこで動くか」を区別する
ここまでのカテゴリBでは、CPUやメモリ、ファイルやパスといった「自分のPCの中」の話を見てきました。ですが、公開されて多くの人が使うアプリは、あなたのPCの中では動いていません。同じアプリが、自分の手元と、確認用の場所と、利用者が実際に使う場所という複数の場所で動きます。この講義では、その「どこで動くか」の区別を身につけます。
このスライドのポイント
- B-05まで: CPU・メモリ・ファイル・パスなど「自分のPCの中」を見てきた
- しかし公開されるアプリは、自分のPCの中では動いていない
- 同じアプリが「手元」「確認用の場所」「利用者が使う場所」という複数の場所で動く
- この講義の役割: その「どこで動くか」の区別を身につける
3つの環境の定義
3つの環境を定義します。ローカル環境とは、自分のPCの中で動かしている状態で、原則として自分しか見られません。開発環境とは、本番の手前で、チームや確認したい人のために動かす環境で、ステージングとも呼ばれます。そして本番環境は、A-09で見たとおり、実際の利用者が使っている環境です。この3つは、同じアプリであっても、つなぐ設定、扱うデータ、そして誰が見られるかという公開範囲が異なります。
このスライドのポイント
- ローカル環境＝自分のPCの中で動かしている状態。原則として自分しか見られない
- 開発環境＝本番の手前で、チームや確認したい人のために動かす環境（ステージングとも呼ばれる）
- 本番環境＝A-09で見たとおり、実際の利用者が使っている環境
- 3つは同じアプリでも、設定・データ・公開範囲が違う
なぜこの区別が必要か
この区別を知らないと、「自分のPCでは動くのに、公開すると動かない」という現象の理由がつかめません。環境ごとに設定やデータが違うために起こることなのですが、原因を切り分けられないまま時間を溶かしてしまいます。さらに危険なのは、本番のデータで実験してしまうことです。A-09で学んだ高リスクな変更を、いきなり利用者の使っている本番環境で試せば、本物のデータを壊しかねません。
このスライドのポイント
- 知らないと「ローカルでは動くのに公開すると動かない」の理由が分からない
- 環境ごとに設定・データが違うために起こるが、原因を切り分けられない
- もっと危険なのは、本番のデータで実験してしまうこと
- A-09の高リスクな変更を本番で行う事故につながる
3つの環境の比較
3つの環境を、誰が見られるか、どんなデータを扱うか、壊れたときの影響という観点で並べてみます。ローカル環境は、自分だけが見られ、試験用のデータを使い、壊しても影響はありません。開発環境は、関係者だけが見られ、確認用のデータを使います。本番環境は、利用者全員が見られ、本物のデータを扱い、壊れたときの影響が最も大きくなります。左のローカルから右の本番へと、段階を踏んで「昇格」させていくのが基本の流れです。
昇格の流れ
日報アプリを作る場合の流れで考えます。まずローカル環境で、壊しながら自由に試作します。次に開発環境へ移し、関係者に実際に触ってもらって確認します。そこで問題がなければ、最後に本番環境へ反映します。ポイントは、いきなり本番環境を直さないことです。手元で十分に試し、確認の場を通してから公開する。この順番を守るだけで、利用者に影響する事故の多くを未然に防げます。
このスライドのポイント
- 日報アプリを作る流れの例
- ①ローカル環境で、壊しながら自由に試作する
- ②開発環境で、関係者に触ってもらって確認する
- ③問題がなければ、本番環境へ反映する
- 原則: いきなり本番環境を直さない
技術サンプル: 環境ごとの設定
技術サンプルを見ます。種別はconfig、環境ごとに設定が変わる例です。値はすべてダミーですが、ローカルは手元の試験用DBにつなぎ公開範囲は自分のみ、開発環境は確認用DBで関係者のみ、本番環境は本物のDBで利用者全員、というように設定が変わります。読み方の要点は、コードそのものは同じでも、つなぐ先と見える範囲が環境ごとに違うということです。この環境ごとの値を管理する仕組みは、後のB-09で学ぶ環境変数につながります。AIには「この変更は、ローカル・開発・本番のどの環境に影響しますか」と聞けます。
このスライドのポイント
- 種別: config
- 目的: 同じコードでも、環境ごとに設定（つなぐ先・公開範囲）が変わることを確認する
- サンプル本体（値はすべてダミー）:
混同しやすい概念
混同しやすいのは、「ローカルで動く」ことと「本番で動く」ことです。この2つは同じではありません。環境が違えば、設定もデータも、土台となるソフトのバージョンも違います。ですから、片方で動いたことは、もう片方でも動くことの保証にはなりません。「手元では動いたから大丈夫」という思い込みが、公開後のトラブルの典型的な入口になります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに修正を頼むときや、AIがコマンドを提案してきたときは、「これはどの環境に対する操作か」を毎回確認してください。特に本番環境への操作は、A-09で学んだとおり、失敗すると戻せないことがあるため、必ず一度立ち止まります。AIへの質問例としては、「この変更は、ローカル・開発・本番のどの環境に影響しますか」と聞くのが有効です。
このスライドのポイント
- AIに修正を頼むとき・AIがコマンドを提案してきたとき、「これはどの環境に対する操作か」を毎回確認する
- 本番環境への操作は、A-09のとおり失敗すると戻せないことがあるため必ず立ち止まる
- AIへの質問例: 「この変更は、ローカル・開発・本番のどの環境に影響しますか」
まとめと一問一答
一問一答です。問題。本物の利用者データがあるのは、どの環境でしょうか。……答えは、本番環境です。だからこそ、実験は自分だけのローカル環境で行います。30秒まとめです。同じアプリでも、ローカル・開発・本番の3つの環境は、設定・データ・公開範囲が違います。「いまどの環境の話か」を常に確認し、本番では立ち止まる。これが安全な開発の土台です。次回は、これらの操作の入口になるターミナルとシェルへ進みます。関連資料は「Vercel公開 完全手順書」「AIアプリ公開前チェックリスト100」「環境変数・APIキー管理入門」です。
このスライドのポイント
- 一問一答: 本物の利用者データがあるのはどの環境？ → 本番環境（だから実験はローカルで）
- 30秒まとめ: 同じアプリでもローカル・開発・本番の3環境は設定・データ・公開範囲が違う。「いまどの環境か」を常に確認し、本番では立ち止まる
- 次回: これらの操作の入口になるターミナルとシェルへ
- 関連資料: 「Vercel公開 完全手順書」「AIアプリ公開前チェックリスト100」「環境変数・APIキー管理入門」
