CI/CD ― GitHub Actions+OIDC+Feature Flagが鉄板 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第7弾として、CI/CDについて解説する記事です。

Netflix が1日数千回デプロイする一方、週1回を恐る恐る進めるチームの差は競争力そのものです。本記事では CI/CD の段階別実務（pre-commit から本番Canaryまで）、PR時10分以内の鉄則、DBマイグレーションの expand/contract、段階的リリース、IaC・GitOps・DevSecOps・OIDC連携まで解説します。

略語	正式名称	内容
CI	Continuous Integration	push 毎に自動ビルド・自動テスト
CD	Continuous Delivery	いつでもデプロイ可能な状態を維持（人が承認）
CD	Continuous Deployment	本番デプロイまで完全自動化

Delivery と Deployment の違いは「人の承認が入るかどうか」金融・医療など規制業界では承認を挟む Delivery 型、Web サービス・SaaS では完全自動の Deployment型が主流です。

このカテゴリの他の記事

CI/CDが重要な理由

CI/CD を導入するメリットは、単なる時間短縮にとどまりません。ビジネス全体のスピードを決める根本的な仕組みです。

メリット	内容
バグの早期発見	push 毎にテストが走り、数分で問題検知
デプロイの属人化排除	誰が押しても同じ結果が再現される
デプロイ頻度の向上	1日複数回のリリースも可能に
ロールバックの容易化	問題があっても数分で前バージョンに戻せる
本番環境の再現性	手順書の読み違えが起きない

「mainにマージ＝本番化できる」状態を作るのがゴール。これができると機能追加・バグ修正を数時間で本番反映でき、競合との開発スピード差が決定的になります。Netflix・Amazon が1日に数千回デプロイできるのは、CI/CD なしには不可能な世界です。

デプロイ速度はビジネスの競争力に直結します。

主要なCI/CDプラットフォーム

CI/CD を提供するサービス・ツールは複数あり、ソースコードホスティングとの組み合わせで決まることが大半です。

製品	特徴	向いているケース
GitHub Actions	GitHub 統合・YAML 設定・圧倒的普及	GitHub 使用・新規採用の第一候補
GitLab CI	GitLab 統合・セルフホスト容易	GitLab 環境・エンタープライズ
CircleCI	高速・柔軟な設定	大規模 OSS・独立運用
AWS CodePipeline	AWS 統合・IAM 連携	AWS 特化の環境
Jenkins	OSS 老舗・高カスタム性	レガシー継続・特殊要件
Azure DevOps	Microsoft 系統合	.NET・Azure 環境

新規採用では GitHub Actions が圧倒的な本命です。GitHub のソースと密結合で、YAML で直感的に書け、Marketplace で再利用可能なアクションが豊富です。Jenkins は老舗ですが運用の手間が重く、新規で選ぶ理由はほぼ残っていません。

典型的なパイプライン

CI/CD パイプラインは、複数のステップを順番に実行します。各ステップで失敗したら次に進まず、即座に通知が飛ぶようにします。

flowchart TB
    A([git push]) --> B[Lint / Format<br/>数秒]
    B --> C[Unit Test<br/>数分]
    C --> D[Build Image<br/>数分]
    D --> E[Integration Test<br/>数十分]
    E --> F[Security Scan<br/>SAST / SCA]
    F --> G[Deploy to Staging<br/>自動]
    G -->|手動承認/<br/>ゲート| H[Deploy to Production<br/>Canary → 100%]
    B -. fail .-> X([即座に通知])
    C -. fail .-> X
    D -. fail .-> X
    E -. fail .-> X
    F -. fail .-> X
    classDef step fill:#dbeafe,stroke:#2563eb;
    classDef prod fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef fail fill:#fee2e2,stroke:#dc2626;
    class B,C,D,E,F,G step;
    class H prod;
    class X fail;

早いステップで失敗させる（Fail Fast）のが原則です。30分かかる E2E テストを最初に走らせると、些細なコード規約違反で30分待たされる。数秒のLint → 数分のUnit Test → 数十分のIntegration Testの順に並べ、遅いテストほど後ろに配置します。

CIで何を走らせるか — 段階別の実務

CI は「push したら全部を一気に走らせる」ものではありません。コードが人の目に触れるタイミングに合わせて4段階に分け、各段階で役割を変えるのが現実的です。早い段階ほど速く・頻繁に・ローカルで、遅い段階ほど重く・広くなります。

段階	いつ走るか	何を走らせるか	目標時間
①pre-commit	コミット作成時（ローカル）	フォーマッタ・Lint・シークレット検出	5秒以内
②pre-push	push 直前（ローカル or サーバ）	変更ファイル周辺の Unit Test	30秒以内
③PR作成・更新時	GitHub に push された時	全 Unit + 型チェック + カバレッジ + SAST + SCA	10分以内
④merge時	main にマージされた瞬間	Integration Test + ビルド + イメージ push + IaC plan	20分以内

pre-commit（Husky・lefthook・pre-commit framework で実装）はコーディング規約とシークレット漏洩だけに絞るのがコツです。重くすると開発者がスキップするため、5秒を超えるものは置かない。この段階での定番は Prettier／Biome／ESLint／gitleaks です。

CIの実行時間は10分以内に収める

PR 作成時の CI（③段階）が10分を超えると開発速度が露骨に落ちます。「PRを出す→何か別のタスクをやる→CIが終わる→レビュー依頼する」のリズムが崩れ、開発者は待ちの間にコンテキストを失います。Google の社内研究でも、CI 応答時間が長いほど1日のコミット数が減ることが示されています。

手法	効果	注意点
ジョブの並列化	Lint・Unit・型チェックを同時実行で3倍速	ランナー料金が線形に増える
依存関係キャッシュ	node_modules 等を2回目から数秒に	キャッシュキーの設計ミスで古い依存を引く事故
変更範囲テストのみ実行	モノレポで全部走らせない	テスト依存関係の解析が必要（Nx・Turborepo・Bazel）
Docker レイヤーキャッシュ	イメージビルドを数倍速	Buildx・GHA cache の設定が必須
遅いテストの別ジョブ化	E2E・負荷試験は夜間バッチへ	PR 時に回らないためカバレッジ担保の別ルートが要る

まず並列化 → キャッシュ → 変更範囲限定の順で効きます。10分を切れない場合、CI にテスト以外の重い処理（毎回クリーンビルド・不要な統合テスト）が混ざっていないか疑うのが先です。

PR時のCIは10分以内。これを守れない組織の開発速度は確実に鈍化します。

CDで何を走らせるか — 環境別の責務

CD は「本番に届ける」だけではなく、段階的に環境を通過させながら検証するプロセスです。各環境の役割を曖昧にすると「stgで動いたから本番も大丈夫」の思考停止に陥ります。環境は最低3つ、理想は4つ用意します。

環境	目的	データ	アクセス	自動／手動
dev	開発者の動作確認	合成データ	開発チーム	main マージで自動
staging	本番相当の結合検証	本番のマスクコピー	QA・PM・関係者	main マージで自動
pre-prod（canary）	本番トラフィックの一部で実戦検証	本番そのもの	内部ユーザー・一部顧客	承認＋自動
production	全ユーザー	本番	全顧客	canary 通過後に自動拡大

staging を「開発者だけが触る環境」にすると形骸化します。QA・PMが定常的に触り、本番データに近い内容で操作できることが stg の存在意義です。本番データのマスクコピー（PII除去・支払い情報は合成）を日次で同期するのが定石。pre-prod（canary）は省略されがちですが、stg だけでは「本番の実際のトラフィック・データボリューム・サードパーティ連携」での問題が捕まえられないため、クリティカルなシステムでは分けます。

DBマイグレーションはCDの鬼門

CD で最も事故るのがDBスキーマ変更です。コードは Blue／Green で即座に戻せても、スキーマ変更は片方向で、しかも本番データを抱えたまま動きます。だからコードと別のライフサイクルで、後方互換を保ちながら段階的に進めます。これを expand/contractパターンと呼びます。

【列名 user_name を full_name に変える場合】
① expand : full_name 列を追加（両方書き込み・読み出しは user_name） ← デプロイ1回目
② backfill: full_name に user_name の値をコピー（バッチ）
③ switch : 読み出しを full_name に切替                            ← デプロイ2回目
④ contract: user_name 列を削除                                    ← デプロイ3回目

具体的なマイグレーション断片の例(PostgreSQL想定):

-- ① expand: 新列を NULL 許可で追加（即時・ロックを避ける）
ALTER TABLE users ADD COLUMN full_name TEXT;

-- ② backfill: 既存行に値を入れる（バッチで分割し本番負荷を抑える）
UPDATE users SET full_name = user_name
WHERE full_name IS NULL AND id BETWEEN $1 AND $2;

-- ③ switch: アプリ側のリリース後、整合性を保証
ALTER TABLE users ALTER COLUMN full_name SET NOT NULL;

-- ④ contract: 旧列を削除（新コード100%稼働を確認後）
ALTER TABLE users DROP COLUMN user_name;

アプリ側も同期して書き換えます。

// expand 直後: 二重書き込み（旧コードに読まれても壊れない）
await db.update(users).set({
  user_name: name,
  full_name: name,
}).where(eq(users.id, userId));

// switch デプロイ後: 新列のみに書き込み
await db.update(users).set({ full_name: name }).where(eq(users.id, userId));

4段階に分ける理由は、どの瞬間で旧コードと新コードが同時に動いていても壊れないようにするためです。ローリング更新中は新旧インスタンスが数分〜数十分共存するので、「旧コードが読む列」「新コードが書く列」を両立させないと本番が死にます。

スキーマ変更はワンショットで済ませない。3回のデプロイに分けるのが鉄則です。

DBマイグレーションの禁じ手と運用

禁じ手	なぜダメか
列のリネーム1発	旧コードで動いているインスタンスが即死
NOT NULL 列の即時追加	既存レコードで制約違反、マイグレ失敗
インデックスのオンライン無し追加	大規模テーブルで書き込みがロックされる
破壊的変更とコード変更を同じデプロイに載せる	ロールバック時にスキーマが戻せない

マイグレは独立したステップとして CD パイプライン内で先に走らせ、コードデプロイの前に完了させます。PostgreSQL なら CREATE INDEX CONCURRENTLY・MySQL なら pt-online-schema-change や gh-ost を使い、本番テーブルをロックしない運用が必須です。

マイグレーションツールは Flyway・Liquibase・Prisma Migrate などが定番で、変更を SQL ファイル（または宣言的スキーマ）としてコード管理します。Gitに乗せてPRでレビュー対象にするのが現代の標準で、DBA の GUI 作業は監査証跡が残らないため避けます。大規模テーブルでは backfill バッチの実行時間が数時間〜数日になるケースもあり、マイグレのスケジュールをリリースカレンダーで別管理するのが実務です。

段階的リリース — 具体的な割合とGate

Canary は「一部に先に出して様子を見る」と説明されがちですが、何%で・何を見て・どう次に進めるかが曖昧だと機能しません。実務では以下の割合で自動進行させ、各段階でエラー率・レイテンシ・ビジネス指標をメトリクスベースで判定します。

フェーズ	割合	観察時間	自動ロールバック条件の例
Canary 1	1%	15分	エラー率 > 旧版 + 0.5%
Canary 2	5%	30分	p99 レイテンシ > 旧版 × 1.2
Canary 3	25%	1時間	ビジネス指標（CVR等） > 旧版 − 5%
Canary 4	50%	2時間	上記3つのいずれか
全展開	100%	—	—

自動ロールバックの閾値は旧版（baseline）との相対比較で設定するのが定石です。絶対値にすると、時間帯による変動で誤作動します。AWS CodeDeploy・Argo Rollouts・Flagger などが、この「メトリクス連動の自動段階展開」を標準装備しています。

人間の目視判断だけに頼ると、深夜に事故った時に誰も止められません。Gateは機械化、承認は省略しないが機械が先に判断するのが現代の CD 設計です。

ブランチ戦略

CI/CD と密接に関わるのがブランチ戦略です。チームの規模・リリース頻度・製品の性質によって使い分けます。

戦略	特徴	向いているケース
GitHub Flow	main + feature branches	Web サービス・継続的デプロイ
Git Flow	main + develop + release + hotfix	製品型・バージョン管理型
Trunk-Based Development	短命 feature・main へ直push	高度な CI/CD・熟練チーム

モダン Web 開発では、GitHub Flow か Trunk-Based Development が主流です。複雑な Git Flow は、パッケージ製品・オンプレ配布など「バージョン単位で管理する必要がある」ケースでのみ有効で、継続的にデプロイする SaaS には過剰な複雑さでしかありません。

ブランチ戦略はシンプルさ優先。複雑な Git Flow はもう少数派です。

テスト自動化のレベル

テストには複数のレベルがあり、それぞれ役割が違います。全種類を書く必要はなく、用途ごとに適切な量を配分するのが重要です。

テスト	速度	範囲	比率の目安
Unit Test	速（秒）	関数・クラス単位	70%
Integration Test	中（分）	モジュール結合	20%
E2E Test	遅（数分〜十数分）	ユーザー操作再現	10%

この比率をテストピラミッドと呼びます。Unit Test を多く・E2E Test は少なく、というのが原則です。E2E は遅く・不安定で・壊れやすいため、本質的なユーザー動線だけに絞ります。CI では Unit + Integration を必ず走らせ、E2E はステージング環境でナイトリー実行するのが典型構成です。

デプロイ戦略

「デプロイ」といっても、複数のやり方があります。影響の大きいリリースほど段階的・慎重に行うのが定石です。

戦略	仕組み	特徴
Rolling Update	順次置換	シンプル・ダウンタイムなし
Blue/Green	新環境で検証し一気に切替	一瞬で戻せる・コスト2倍
Canary Release	一部ユーザーに先行展開	リスクを局所化
Feature Flag	コードは本番にあるが機能ON/OFF切替	デプロイとリリースを分離

大規模機能や不可逆な変更（DB マイグレーション等）は、Blue/Green か Canary で段階的に行います。問題があればコードを戻すのではなく、トラフィックを戻すのがポイントです。

CanaryとFeature Flag

Canary Release と Feature Flag は、現在最も重要視されるリスク管理の2大手法です。

Canary Release:
  Users
   ├─ 95% ──→ [旧版 v1.0]
   └─ 5%  ──→ [新版 v1.1]   ← 問題なければ徐々に拡大

Feature Flag:
  if (flag.newCheckout) {
    renderV2()
  } else {
    renderV1()
  }

Feature Flag はコードを本番にデプロイしつつ、フラグで機能の ON/OFF を切替可能にする仕組みです。「デプロイ＝リリース」という一蓮托生の関係を断ち切り、コードの配布と機能の公開を分離できます。LaunchDarkly・Unleash・GrowthBook などの専用 SaaS が広く使われます。

段階展開の本質は、「全員で壊れる」を避け、「一部で検知して即戻せる」にすることです。

Infrastructure as Code（IaC）

IaC（Infrastructure as Code）は、インフラ構成（サーバー・ネットワーク・DB 等）をコードで定義し管理する手法です。手動構築を廃止することで、再現性・監査性・変更管理が劇的に向上します。

ツール	特徴
Terraform	マルチクラウド対応・デファクト標準
OpenTofu	Terraform の OSS フォーク（2024年独立）
AWS CloudFormation	AWS 純正・JSON／YAML
Azure Bicep	Azure 純正・ARM 後継
Pulumi	TypeScript／Python 等で記述
AWS CDK	TypeScript 等で AWS を定義

標準は Terraform（または後継の OpenTofu）。マルチクラウド対応でコミュニティも大きく、ほぼ全てのクラウドリソースをコードで管理できる。CI/CD パイプラインに組み込み、インフラ変更もPull Requestでレビューするのが現代の定石です。

GitOps

GitOps は、Git リポジトリを唯一の真実（Single Source of Truth）として、Git への push が自動でインフラに反映される方式です。特に Kubernetes 運用で急速に標準化しています。

[Git push]
    ↓
[ArgoCD / Flux]        ← Gitリポジトリを常時監視
    ↓
[Kubernetes]           ← Gitの内容に自動収束

特徴	内容
宣言的	「あるべき状態」を定義し、そこへ収束させる
監査性	全変更が Git 履歴に残り、誰がいつ何を変えたか明確
ロールバック容易	git revert だけで戻せる
権限管理	Git のアクセス権がそのままデプロイ権限になる

Kubernetes 環境では ArgoCD と Flux が2大 GitOps ツールです。現在の K8s 運用ではほぼ標準で、手動 kubectl apply を廃止する動きが広がっています。

DevSecOps（セキュリティの組込）

DevSecOps は、CI/CD パイプラインにセキュリティチェックを組み込む考え方です。シフトレフト（早い段階で問題を見つける）により、本番デプロイ前に脆弱性を潰します。

対象	ツール例
SAST（静的解析）	SonarQube／CodeQL／Semgrep
SCA（依存関係）	Dependabot／Snyk／Renovate
DAST（動的解析）	OWASP ZAP／Burp Suite
コンテナスキャン	Trivy／Grype／Docker Scout
IaCスキャン	Checkov／tfsec／Terrascan

GitHub Dependabot は無料で使え、依存ライブラリの脆弱性を自動検知し PR 作成まで行います。これだけでも導入する価値が高く、最低限の脆弱性対策として必須レベルです。

セキュリティはパイプラインに組み込むのが現代の基本です。

シークレット管理

CI/CD 環境で API キーやパスワードを平文で置くのは絶対にやめておく。漏洩すれば即座に悪用されます。適切な管理方法を使います。

方法	特徴
GitHub Actions Secrets	標準機能・シンプル
OIDC連携（GitHub ↔ AWS／GCP）	長期キー不要・最推奨
HashiCorp Vault	マルチ環境統合
AWS Secrets Manager	AWS 純正・自動ローテーション

現在の本命は OIDC（OpenID Connect＝OAuth2上の標準認証プロトコル）連携です。GitHub Actions から AWS にアクセスする際、長期の IAM アクセスキーを保存する代わりに、GitHub の認証情報で AWS の一時トークンを取得する方式です。IAM キーの漏洩リスクが消えるため、セキュリティ面で圧倒的に優位です。

OIDCが現在の標準。長期キーを Secrets に置くのは古い運用です。

よくある勘違い

CI/CD で非専門家・若手エンジニアが陥りやすいパターンです。

CI/CDを導入すればバグが減る

テストがないまま CI/CD を入れても、バグが高速で本番に流れるだけです。テストの質と量が先。パイプラインは増幅装置にすぎません。

E2Eテストを厚くすれば安心

E2E は遅くて壊れやすく、誰もメンテしなくなります。ユニットテスト7割・結合2割・E2E 1割のテストピラミッドが鉄則です。

デプロイ後すぐリリースしていい

デプロイとリリースを同一視するのは地雷。Feature Flag で分離し、リスクは段階的に公開するのが現代流です。

IAMキーをSecretsに入れておけば安全

Secrets も漏洩します。OIDC連携で長期キー自体を発行しない設計が本命です。

自動化は正しくないものを高速化する。正しさを先に整えます。

AI時代の視点

AI 駆動開発が前提になると、CI/CD は AI の生成精度を最大化する場として設計されます。GitHub Actions + 標準 YAML は AI の学習データが最も多く、パイプライン自動生成の精度が極めて高い。一方、Jenkins の独自 Groovy DSL（Domain Specific Language＝特定用途専用の記述言語）や商用 CI/CD の独自設定は、AI の生成がハルシネーションしやすく、避けられていく運命です。AI が書いたコードの自動レビュー・自動テスト生成・自動 PR マージまで、パイプラインが AI エージェントの動作基盤になっていく流れです。

AI時代に有利	AI時代に不利
GitHub Actions + 標準YAML	Jenkins 独自DSL・商用独自設定
OIDC連携（長期キー不要）	IAM キーを Secrets に保存
Trunk-Based + Feature Flag	長命ブランチ・手動リリース
AI対応のコード生成・レビュー統合	AI エージェントが触れないプライベート CI

「mainにマージ＝本番化」の自動化は、AI 時代ではさらに重要になります。AI がコードを生成・PR 作成・自動テスト通過後マージというオートパイロット運用も現実的で、人間は設計判断・コードレビュー・戦略に集中できるようになります。

AI 時代はAIがパイプラインを書き、AIがパイプラインで動く。標準 YAML + OIDC が絶対条件です。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• CI/CDプラットフォーム（GitHub Actions／GitLab CI等）
• ブランチ戦略（GitHub Flow／Trunk-Based／Git Flow）
• CI段階（pre-commit／pre-push／PR／merge）で何を走らせるか
• PR時のCI目標時間（10分以内を推奨）
• 環境構成（dev／staging／canary／production）と各環境の責務
• DBマイグレーション戦略（expand／contract・ツール選定）
• 段階的リリースの割合・観察時間・自動ロールバックGate
• IaCツール（Terraform／CloudFormation／CDK）
• シークレット管理方法（OIDC推奨）
• ロールバック手順と訓練頻度

筆者メモ — Knight Capitalの45分

2012年8月1日、米国の証券会社 Knight Capital が新しい取引システムを投入した際、8台のサーバーのうち1台だけ古いコードが残ったままで稼働してしまい、誤った注文を大量に発行。45分間で約4億6000万ドルの損失を出し、会社そのものが事実上消滅した──という業界で語り継がれている事例です。

教訓は、「一部だけ違う状態」を許す運用そのものがリスクということ。デプロイ手順を人間の手作業に委ねると、サーバー1台の取り違えのような事故が必ず起きる。CI/CD で全台を同じ成果物で同じ手順でデプロイする、という当たり前を実装として担保するのが、最低限の防衛線です。

人間は、たまに1台だけ忘れる生き物です。

よくある失敗

• テストがないままCI/CD導入 — 自動化してもバグが流出する。Unit Test から整備すべき
• E2E Testを大量に書く — 壊れやすく遅く、誰もメンテしない
• mainブランチへの直push運用 — レビューなしで事故が頻発。PR + CI 必須
• IAMキーをGitHub Secretsに保存 — 漏洩事故につながる。OIDC 連携に切り替える
• Feature Flagを使わず全員同時リリース — 問題発生時に全ユーザーに影響。Knight Capital の事故のように、一部だけ更新されなかった状態は会社を消すほどのリスクになる

最終的な判断の仕方

CI/CD の選定はデプロイ速度＝ビジネスの競争力という大前提から逆算します。「mainにマージ＝本番化可能」の状態を維持できるかが全て。1日数回の安全なリリースが回る組織と、週1回恐々リリースする組織では、機能追加・バグ修正の速度に決定的な差がつく。だから選定の核は、人間の介在を最小化しつつ、リスクは段階的に局所化できる構成です。

現在の鉄板は「GitHub Actions + Trunk-Based + OIDC + IaC + Feature Flag」の組み合わせ。GitHub Actions は情報量と AI 生成精度で他を圧倒し、OIDC は長期キー管理の負債を消し去り、Feature Flag は「デプロイ＝リリース」の一蓮托生関係を断ち切ります。AI 駆動開発では、AI がパイプラインを書き・AI がパイプラインで動く時代に入っており、標準 YAML・標準プロトコルから外れた構成は機能しなくなります。

選定の優先順位

1. ソースコードホスティングと密結合のCI/CDを選ぶ — GitHub なら GitHub Actions
2. OIDC連携を必須要件にし、長期IAMキーをSecretsから排除
3. Trunk-Based + Feature Flagでリリースとデプロイを分離
4. IaC + DevSecOpsをパイプラインに組み込む（シフトレフト）

「標準YAML + OIDC + Feature Flag」が絶対条件です。独自 DSL と長期キーは今すぐ捨てます。

まとめ

本記事はCI/CDについて、段階別実務・PR時10分以内・DBマイグレーション・段階的リリース・IaC・GitOps・DevSecOps・OIDC連携まで含めて解説しました。如何だったでしょうか。

GitHub Actions+Trunk-Based+OIDC+IaC+Feature Flagを軸に、PR時CIは10分以内、DBマイグレはexpand/contract、段階リリースのGateは機械化する。これが2026年のCI/CD設計の現実解です。

次回はデプロイ戦略（Blue-Green・Canary・Feature Flag詳細）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。