前回との接続——環境を分けたら、次は検査を自動化する
前回のR-07では、プレビュー・ステージング・本番という3つの環境を分け、本番へ触れる前に必ず検証を通す考え方を学びました。ただ、環境を分けても、その環境で検査を回すかどうかは、まだ人の手に委ねられています。この講義では、その検査を変更のたびに自動で走らせる仕組みを扱います。R章で積み上げてきたデプロイの流れに、自動の安全網を組み込む回です。
このスライドのポイント
- R-07: プレビュー・ステージング・本番の3環境を分け、本番の前に必ず検証を通す考え方を学んだ
- ただし「環境で検査を回すか」は、まだ人の手に委ねられている
- この講義の役割: その検査を、変更のたびに自動で走らせる仕組みを組み込む
- R章のデプロイの流れに、自動の安全網を差し込む回
CIの定義と、自動実行する検査4点
CI、継続的インテグレーションとは、O-07で学んだpushやPRのたびに、検査を自動で実行する仕組みです。参照スタックではGitHub Actionsなどが担います。自動実行する検査は4点あります。1つ目はビルド、R-05で学んだ変換工程が通るか。2つ目は型検査、F-10で予告した型の確認。3つ目はテスト、P-04からP-07で書いた確認の全実行。4つ目が静的解析で、コードを実行せずに危険な書き方や乱れを見つける検査です。O-10の③の自動検査と、P-07の回帰の自動実行、その実行主体がこのCIです。
このスライドのポイント
- CI（継続的インテグレーション）＝pushやPR（O-07/08）のたびに検査を自動実行する仕組み（参照スタックではGitHub Actions等）
- 検査4点:
なぜ必要か——「人間は忘れる」を仕組みで解決する
テストを書いても、その実行を人が覚えていなければ意味がありません。急いでいる時ほど、実行を飛ばしたまま本番へ反映してしまいます。CIは、この「人間は忘れる」を仕組みで解決する装置です。検査を人の記憶に頼らず、変更が起きた瞬間に機械が必ず走らせます。忘れる余地そのものを無くすところに、CIの本質があります。
このスライドのポイント
- テストを書いても、実行を人が覚えていなければ守りにならない
- 急いでいる時ほど実行を飛ばして本番へ反映してしまう（A-09の本番反映）
- CIは「人間は忘れる」を仕組みで解決する装置
- 検査を記憶に頼らず、変更が起きた瞬間に機械が必ず走らせる
構造——赤いままではマージできない
CIの流れを見てみます。誰かがpushすると、CIが自動で4つの検査を順に走らせます。すべてが緑、つまり合格ならマージできる状態になり、1つでも赤、つまり失敗があればマージできません。R-07で学んだPRの合格条件に、この自動検査が組み込まれる形です。価値の中心は「赤いままではマージできない」という強制力にあります。人が「大丈夫だろう」と判断で押し通す隙を、仕組みが塞ぎます。
このスライドのポイント
- 流れ: push → CIが自動で4検査 → 全部緑ならマージ可能（O-08）／1つでも赤ならマージ不可
- R-07で学んだPRの合格条件に、この自動検査が組み込まれる
- 価値の中心は「赤いままマージできない」という強制力
- 人が「大丈夫だろう」と判断で押し通す隙を仕組みが塞ぐ
処理の流れ——依存追加を、気づく前に検出する
具体的に見ます。AIに頼んで、依存を1つ追加する変更をしたとします。F-08で学んだように、依存の追加は他の箇所へも影響しうる操作です。この変更をpushすると、CIが自動で全テストを回します。もし過去に作った機能が壊れていれば、P-07で学んだ回帰として、人間が気づく前にCIが検出します。バイブコーディングの安全網が、手動から自動へ切り替わる瞬間です。AIが速く大量に変更を作るほど、この自動の検査が効いてきます。
このスライドのポイント
- 例: AIに頼んで依存を1つ追加（F-08。他の箇所へ影響しうる操作）
- pushするとCIが自動で全テストを回す
- 過去に作った機能が壊れていれば、回帰（P-07）として人間が気づく前に検出
- バイブコーディングの安全網が、手動から自動へ切り替わる瞬間
- AIが速く大量に変更を作るほど、この自動検査が効く
技術サンプルカード（config）
スライドの設定は、CIの考え方を疑似的に書いたものです。pushされたら、インストール、ビルド、型検査、テストの順に実行し、1つでも失敗したら赤とする、という流れを表しています。実際の記法はサービスによって異なりますので、形ではなく順序と条件を読んでください。読みどころは、検査が上から順に並び、どれか1つでも失敗すれば全体が失敗になる点です。AIには「このプロジェクトにCIを設定して、ビルド・型検査・テストの3点をPRごとに実行する構成で」と依頼できます。
混同しやすい概念——テストがある／テストが毎回自動で走る
混同しやすいのは、「テストがある」ことと「テストが毎回自動で走る」ことの違いです。テストは書いた時点では、ただの資産にすぎません。実行されて初めて、壊れを止める守りになります。CIは、その資産を変更のたびに必ず実行へ変える仕組みです。テストを書くこと自体が目的になって、実行の自動化を後回しにしないよう気をつけてください。
バイブコーディングでの確認点——立ち上げ時にCIを含める
バイブコーディングでの確認点です。プロジェクトを立ち上げる時、定型の作業として「CIの設定」をAIへの依頼項目に含めてください。理想は、最初のテスト、P-04で書く1本目と同時にCIを用意することです。テストとその自動実行が最初から揃っていれば、以降のすべての変更が安全網の上で進みます。後から入れるより、最初から仕組みにしておく方が確実です。
このスライドのポイント
- プロジェクト立ち上げの定型として「CIの設定」をAIへの依頼項目に含める
- 理想は、最初のテスト（P-04の1本目）と同時にCIを用意すること
- テストとその自動実行が最初から揃えば、以降のすべての変更が安全網の上で進む
- 後から入れるより、最初から仕組みにしておく方が確実
一問一答とまとめ
最後に一問一答です。CIが変更のたびに自動実行する検査4点は何でしょうか。……答えは、ビルド、型検査、テスト、静的解析の4つです。30秒でまとめます。CIは、検査を人の記憶ではなく仕組みに任せ、赤いままではマージさせない強制力で、バイブコーディングの安全網を自動化する仕組みでした。次回のR-09では、この検査を通った変更を実際に届けるCD、そして問題が出たときに戻すロールバックへ進みます。関連資料は「Git・GitHub 完全入門」と「テスト観点プロンプト50」です。
このスライドのポイント
- 一問一答: CIが変更のたびに自動実行する検査4点は？ → ビルド・型検査・テスト・静的解析
- 30秒まとめ: CIは検査を記憶ではなく仕組みに任せ、赤いままマージさせない強制力で、安全網を自動化する
- 次回R-09: 検査を通った変更を届けるCD、問題時に戻すロールバックへ
- 関連資料: 「Git・GitHub 完全入門」「テスト観点プロンプト50」
