01 CI/CD — コードを自動で検査する仕組みと「緑」の本当の意味
「CIが緑（成功）」と聞いて、それが何を証明しているか正確に言えますか？ この章では、現場で当たり前に使われるCI/CDを、根本から理解します。
📑 この章の目次
一言でいうと
CI（継続的インテグレーション） は、コードを共有リポジトリに登録（push）するたびに、機械が自動でビルド・テスト・品質チェックを回す仕組みです。CD（継続的デリバリー／デプロイ） は、その先——検査を通ったコードを、「いつでもリリースできる状態」に保つ（＝デリバリー）、あるいは**本番環境まで自動で届ける（＝デプロイ）**仕組みです。
1. なぜCIが必要なのか
チーム開発を想像してください。3人がそれぞれ別の機能を開発して、いっせいにコードを合わせようとしたとき：
- 「私のPCでは動いてたのに、合わせたら動かない」（環境の違い）
- 「テストしたつもりだけど、実は重要なパターンを漏らしていた」（検査漏れ）
- 「誰かが壊したコードに気づかず、翌日全員が止まる」（壊れたコードの混入）
CIは、これらを**「コードが入ってくるたびに、機械が機械的に検査する」**ことで防ぎます。人間の見落としや「後でやる」を、自動化で置き換えるのが出発点です。
💡 「インテグレーション」＝統合。複数人のコードを「統合」する瞬間の痛みを和らげる仕組み、という意味が名前に込められています。
2. CIは何をしているのか
GitHubでよく使われる GitHub Actions を例にします。コードをpush（またはPull Request作成）すると、リポジトリの .github/workflows/ に書かれた定義に従って、機械が自動で動きます。
# .github/workflows/test.yml（GitHub Actionsの例）
name: CI
on: [push, pull_request] # push・PR時に発動
jobs:
test:
runs-on: ubuntu-latest # GitHub側で用意したLinux環境
steps:
- uses: actions/checkout@v4 # コードを取得
- run: pip install -r requirements.txt # 依存ライブラリ導入
- run: pytest # テスト実行
- run: ruff check . # リンター（コード規約チェック）
このように、「どのタイミングで・何をするか」をYAMLファイルに書いておくと、機械がそのとおりに動きます。
CIがよく回す検査には、こんな種類があります：
| 検査 | 何を見るか |
|---|---|
| ビルド | コードがエラーなく組み立てられるか |
| テスト（unit/integration） | 各機能が期待通り動くか |
| リンター | コードがチームの規約を守っているか（読みやすさ・一貫性） |
| 型チェック | データの型が矛盾していないか（バグの未然防止） |
| セキュリティスキャン | 既知の脆弱性のあるライブラリを使っていないか |
| カバレッジ | テストがコードをどれくらい網羅しているか（%表示） |
💡 これらをすべて設定した上で通すのが「立派なCI」であって、単に pytest だけ回しているだけなら、それは「最低限のCI」です。何を検査に盛り込むかで、CIの「強さ」が変わります。
3. 「緑」と「赤」の意味
CIの実行結果は、GitHub上で色で表示されます：
- 🟢 緑（success） —— 書いたワークフローの全jobが成功した
- 🔴 赤（failure） —— どこかのjobが失敗した
- 🟡 黄色（in_progress） —— いま実行中
緑になる条件
緑になるのは、ワークフローに書いた全jobが、最後までエラーなく終わった時だけです。pytest が1つでも落ちれば赤、ruff check が1つでも指摘すれば赤。
ここが重要です。「緑＝完璧なコード」ではありません。「緑＝あなたがCIに課した検査を、コードがすべて通過した」 です。
4. 🔑 緑が「証明すること」と「証明しないこと」
ここが本章の核心です。緑を見て「これで安心」と思い込むのが、一番よくある落とし穴です。
✅ 緑が証明すること
- コードはビルドできる（文法エラー等はない）
- 定義したテストはすべて通過した
- （設定していれば）セキュリティスキャン・Lint・型チェックの基準をクリアした
- （設定していれば）カバレッジが閾値以上である
❌ 緑が証明しないこと（誤解しやすい）
| 誤解 | 本当のところ |
|---|---|
| 「テストの妥当性（中身が正しい）」 | テストが通っただけで、テスト自体が正しい保証はない（間違ったテストでも緑になりうる） |
| 「テストの網羅性（パターンの漏れがない）」 | カバレッジ100%でも、重要な経路を漏らしたテストなら意味がない |
| 「緑が常に再現する」 | flaky test（環境次第でたまに落ちる不安定なテスト）があると、緑でも信頼できない |
| 「本番で動く」 | CI環境と本番環境は別物。CIで通っても本番固有の問題は起きうる |
| 「ユーザーの要件を満たす」 | CIは書かれた仕様を検査するだけで、要件の正しさまでは見ない |
| 「バグがない」 | テストで網羅していない経路のバグは検出できない |
重要 「テストを書いてCIを通した」ことと、「正しいテストを書いてCIを通した」ことは全く別物です。緑は検査を通過した事実であって、正しさの証明書ではありません。
例えていうと
CIは**「建築確認」**のようなものです。「この建物は設計図（ワークフロー）の基準を満たす」と示しますが、「住人が満足する家になるか」「別の土地でも建つか」までは保証しません。保証の範囲を理解して使うのが、大人の態度です。
5. CD —— 検査を通ったコードを本番に届ける
CIで「壊れていないこと」を確認したら、次はそれをユーザーに届ける番です。この「検査の先」を自動化するのが CD です。
CD には、厳密には2つの意味があります：
| 略 | 正式名 | どこまで自動か |
|---|---|---|
| 継続的デリバリー (Continuous Delivery) | 検査を通ったコードを**「いつでもリリースできる状態」**に保つ。最後の「公開ボタン」は人間が押す | |
| 継続的デプロイ (Continuous Deployment) | 検査を通ったら、本番公開まで完全に自動。人間の関与ゼロ |
CIで「壊れていないこと」を確認してから自動で公開するので、手動デプロイのヒューマンエラー（ミス操作・手順漏れ）を防げるのが最大の利点です。
💡 どちらも頭文字は「CD」。文脈で「ボタン押すのか・全自動か」を読み分けます。
デプロイとロールバック
デプロイ（deploy） は、コードを本番環境（ユーザーが使う環境）に配置して動かすことです。「リリース」「公開」とほぼ同じ意味で使われます。
しかし、デプロイは「成功して終わり」ではありません。公開してみたら不具合が出た時の対応こそが重要です：
- ロールバック（rollback） —— 前のバージョンに戻すこと。「巻き戻し」
⚠ 重要な設計原則：「デプロイできる」ことと同じくらい「ロールバックできる」ことが重要です。戻せないデプロイは、本番障害の時に手も足も出なくなります。CDを組む時は、かならず「戻し方」もセットで設計します。
よくあるロールバックの仕組み：
- 前のバージョンのイメージを残しておく → 切替だけで戻せる
- 機能フラグ（feature flag） → コードは配置したまま、設定で機能をOFFにできる
6. なぜ「CIを緑に保つ」が開発の作法なのか
ここまでを読むと、CIが単なる「自動テストの実行機」でなく、チーム開発の信頼基盤であることが見えてきます。
作法として位置づけられる理由
- 壊れたコードがmain（中心のブランチ）に入るのを防ぐ
- 誰かが赤のまま放置すると、他の人も全員巻き込まれて開発が止まる
- 「このコードは検査済み」という共通の信頼がある
- レビューする側も「最低限の品質は担保されている」と前提できる
- 赤を放置＝技術的負債
- 「あとで直す」は雪だるま式に膨らむ。緑を保つのは日々の借金返済
面接・実務での意味
「CI、回していますか？」
この質問は、単に「テスト自動化しているか」を聞いているのではありません。**「あなたのコードが、チームで信頼して使える状態かを、機械で担保できるか」**を聞いています。
緑のCIバッジを提示できることは、「壊れたコードを放置しない・品質を自動で管理できる」という、プロの働き方の証明になります。
7. よくある失敗と対処
| 失敗 | 何が起きるか | 対処 |
|---|---|---|
| 赤を放置する | mainが壊れ、全員の開発が止まる | 赤を見つけたら最優先で直すかrevert（取り消し）するのが鉄則 |
| CIを通すためだけにテストを消す | 「緑」の実質がなくなる | テストを消すなら理由を明記。場当たり削除は厳禁 |
| CIが遅すぎる | 誰も待たず、形骸化する | 並列化・キャッシュで数分以内に収めるのが理想 |
| 本番とCI環境が違う | 「CIでは通ったのに本番で落ちる」 | 可能な限り**同じ環境（コンテナ等）**を使う（→ 第6章 Docker） |
まとめ
- CI は、push/PRのたび機械が自動でビルド・テスト・品質チェックを回す仕組み
- 緑 ＝ 「ワークフローに書いた全jobが成功した」。完璧の証明ではない
- 緑が証明するのは「検査を通過したこと」。テストの正しさ・本番動作・要件充足までは保証しない
- CD は、検査通過後にデプロイまで自動化する仕組み。ロールバック設計がセット
- CI緑を保つのは、チームの信頼基盤であり、プロの働き方の証明
💡 次のステップ: CIで「検査」の話が出ましたが、その検査の前提になるのが Git/GitHub によるコード管理とPull Requestです。第2章では、CIを回す土台となるバージョン管理の作法を扱います。