前回との接続とこの講義の役割
B-06では、いきなり本番を直さず、開発用の環境で先に試すという考え方を学びました。R-06では、pushをきっかけに自動でビルドとデプロイが進む仕組みを見ました。この講義は、その二つを一本の線でつなぐ回です。変更が本番にたどり着くまでに通る環境を、O-10の変更フローと合わせて具体化します。ここが、本番を守る仕組みの中心になります。
このスライドのポイント
- B-06: いきなり本番を直さず、開発用の環境で先に試す考え方を学んだ
- R-06: pushをきっかけに自動でビルド→デプロイが進む仕組みを見た
- この講義の役割: その二つを一本の線でつなぎ、変更が本番に届くまでに通る環境を具体化する
- O-10の変更フローと合わせて、本番を守る仕組みの中心を組み立てる
三つの環境の定義
言葉を正確に決めます。プレビュー環境とは、PR、つまりO-08で出した変更ごとに自動で作られる、使い捨ての確認用環境です。O-10の変更フローの一段が、ここで実物になります。ステージングとは、本番と同じ構成で一連の検証を行う環境で、B-06で開発環境と呼んでいたものの正式な名前です。本番は、実際の利用者が使う環境です。そして原則が一つあります。本番に触れる変更は、必ずステージングを先に通すこと。これをstaging-firstと呼びます。
このスライドのポイント
- プレビュー環境: PR（O-08）で出した変更ごとに自動で作られる、使い捨ての確認用環境（O-10の変更フローの一段が実物になる）
- ステージング: 本番と同じ構成で一連の検証を行う環境（B-06の「開発環境」の正式名）
- 本番: 実際の利用者が使う環境
- 原則: 本番に触れる変更は、必ずステージングを先に通す（staging-first）
なぜ環境を分けるのか
この分け方を知らないと、B-06で学んだいきなり本番を直さないという原則を、実際の仕組みとしてどう作ればよいかが分かりません。結果として、変更をいきなり本番へ流し、利用者の前で初めて動かすことになります。これはA-09で言う最高リスクの操作そのものです。また、変更ごとに実物で確認できるプレビュー環境という強力な道具も、存在を知らなければ使いこなせません。
このスライドのポイント
- 分け方を知らないと、B-06の「いきなり本番を直さない」を仕組みとしてどう作るかが分からない
- 結果、変更をいきなり本番へ流し、利用者の前で初めて動かすことになる（A-09の最高リスク操作）
- 変更ごとに実物で確認できるプレビュー環境という道具も、知らなければ使えない
昇格パイプラインという構造
三つの環境は、変更が昇格していく一本のパイプラインとして並びます。PRを出すとプレビュー環境が変更ごとに自動で作られ、まずそこで確かめます。次に本番同等のステージングで一連の検証を行い、問題がなければ本番へ昇格させます。B-06で表として学んだ環境の違いと、O-10で学んだ変更フローが、ここで一つの仕組みに合体します。左から右へ、確認の密度を上げながら進む流れです。
このスライドのポイント
- 三つの環境は、変更が昇格していく一本のパイプラインとして並ぶ
- PR→プレビュー（変更ごと・自動）→ステージング（本番同等・検証）→本番
- B-06の「環境の違いの表」と、O-10の「変更フロー」がここで一つの仕組みに合体する
- 左から右へ、確認の密度を上げながら進む
経費アプリでの具体例
経費アプリで、承認ルールを変更する場合を追います。まず開発者がプレビュー環境のURLで、変更が意図どおりか確かめます。次にステージングで、経理担当が本物と同じデータ構成を相手に検証します。そこで承認が取れて初めて、本番へ反映します。こうすると、本番で初めて動かすという瞬間が無くなります。利用者が触れる前に、実物同然の環境で二段階の確認を終えているからです。
このスライドのポイント
- 例: 経費アプリの承認ルールを変更する
- ①開発者がプレビュー環境のURLで、変更が意図どおりか確認
- ②ステージングで、経理担当が本物と同じデータ構成を相手に検証
- ③承認が取れて初めて本番へ反映
- 効果: 「本番で初めて動かす」瞬間が無くなる
技術サンプルカード
このスライドは、三つの環境の関係を図と表で示したサンプルです。上の昇格パイプライン図は、PRからプレビュー、ステージング、本番へと変更が進む道筋を表します。下の表は、各環境のデータ、URL、見られる人、いつ作られるかを並べたもので、B-06の表に仕組みの裏付けを付けたものです。AIへの質問例は、この変更のプレビュー環境のURLと、ステージングと本番の設定差分を尋ねる形になっています。
混同しやすい概念
混同しやすいのは、プレビュー環境とステージングです。プレビュー環境は、変更一つを確認するための使い捨ての環境です。一方ステージングは、本番と同じ構成で総合的に検証するための、常設の環境です。役割が違うので、片方だけでは足りず、両方が必要になります。プレビューで個別の変更を見て、ステージングで全体としての整合を見る、という分担だと考えてください。
このスライドのポイント
- プレビュー環境: 変更1つを確認するための使い捨ての環境
- ステージング: 本番と同じ構成で総合的に検証するための常設の環境
- 役割が違うので、片方では足りず両方が必要
- プレビューで個別の変更を見て、ステージングで全体の整合を見る
バイブコーディングでの確認点
バイブコーディングでは、本番への反映を伴う変更のたびに、ステージングで確認しましたかという問いを必ず通してください。これはこのプロジェクト自身が守っている運用原則でもあります。AIが本番反映を提案してきたときも、staging-firstの順番を飛ばしていないかを人間が確かめます。質問例です。この変更を本番へ出す前に、ステージングで検証すべき項目を挙げてください。
このスライドのポイント
- 本番への反映を伴う変更のたびに、「ステージングで確認しましたか」を必ず通す
- これはこのプロジェクト自身が守る運用原則（staging-first）でもある
- AIが本番反映を提案しても、staging-firstの順番を飛ばしていないか人間が確認する
- 質問例: 「この変更を本番へ出す前に、ステージングで検証すべき項目を挙げてください」
まとめと次回
一問一答です。本番と同じ構成で検証する環境は何でしょうか。少し考えてみてください。答えは、ステージングです。三十秒でまとめます。変更はプレビュー、ステージング、本番の順に昇格し、本番に触れる変更は必ずステージングを先に通す。これがstaging-firstです。B-06の環境の分け方と、O-10の変更フローが、この昇格パイプラインとして一つになりました。次回は、変更のたびに自動で検査する仕組み、CIへ進みます。関連資料は、Vercel公開 完全手順書と、AIアプリ公開前チェックリスト100です。
このスライドのポイント
- 一問一答: 「本番と同じ構成で検証する環境は？」→ ステージング
- 30秒まとめ: 変更はプレビュー→ステージング→本番の順に昇格し、本番に触れる変更は必ずステージングを先に通す（staging-first）
- B-06の環境の分け方と、O-10の変更フローが、この昇格パイプラインとして合体した
- 次回: 変更のたびに自動で検査する仕組み、CIへ
- 関連資料: 「Vercel公開 完全手順書」「AIアプリ公開前チェックリスト100」
