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連携まで解説します。

本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』・『実践Claude Code入門』も参考にしてみてください。

そもそもCI/CDとは何か

CI/CDとは、ざっくり言えば「コードを書いたら、テスト・ビルド・配布を全自動でやってくれる仕組み」です。

出版の工程を想像してください。著者が原稿を渡すと、校正者が誤字をチェックし、問題がなければ印刷工場に送られ、書店に届きます。CI/CDはこの一連の流れをソフトウェア開発で再現したもので、開発者がコードを保存した瞬間に自動でテストが走り、問題がなければ本番環境に届けられます。

用語を整理すると、CI（Continuous Integration）はpush毎の自動ビルド・自動テスト、CDは2つの意味があり、Continuous Delivery（いつでもデプロイ可能な状態を維持し、人が承認）とContinuous Deployment（本番デプロイまで完全自動化）です。違いは「人の承認が入るかどうか」で、金融・医療など規制業界ではDelivery型、WebサービスやSaaSでは完全自動のDeployment型が主流です。

なぜCI/CDが必要なのか

CI/CDがない世界では、開発者が手作業でサーバーにログインし、ファイルを1つずつ配置し、手元のチェックリストを目で追いながらテストを実行します。深夜の本番デプロイで手順を1行飛ばし、翌朝に障害が発覚する──こうした「人間の手作業に起因する事故」はCI/CDなしの現場で繰り返し起きてきました。

導入のメリットは時間短縮にとどまりません。push毎のテストで数分でバグを検知でき、誰が押しても同じ結果が再現され、問題があっても数分で前バージョンに戻せる。「mainにマージ＝本番化できる」状態を作るのがゴールで、これができると機能追加・バグ修正を数時間で本番反映でき、競合との開発スピード差が決定的になります。デプロイ速度はビジネスの競争力に直結します。

プラットフォームの選定はソースコードホスティングとの組み合わせで決まることが大半で、新規採用ではGitHub Actionsが圧倒的な本命です。GitHubのソースと密結合で、YAMLで直感的に書け、Marketplaceで再利用可能なアクションが豊富。その他、GitLab環境ならGitLab CI、AWS特化ならCodePipelineがあります。老舗のJenkinsは運用の手間が重く、新規で選ぶ理由はほぼ残っていません。

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

CIは「pushしたら全部を一気に走らせる」ものではありません。コードが人の目に触れるタイミングに合わせて4段階に分け、各段階で役割を変えるのが現実的です。

pre-commit（Husky・lefthook等で実装）はコーディング規約とシークレット漏洩だけに絞るのがコツです。重くすると開発者がスキップするため、5秒を超えるものは置かない。定番はPrettier／Biome／ESLint／gitleaksです。パイプライン内の並び順は早いステップで失敗させる（Fail Fast）が原則で、数秒のLint→数分のUnit Test→数十分のIntegration Testの順に、遅いテストほど後ろに配置します。

PR作成時のCI（③段階）が10分を超えると開発速度が露骨に落ちます。「PRを出す→別のタスクをやる→CIが終わる→レビュー依頼する」のリズムが崩れ、開発者は待ちの間にコンテキストを失います。短縮はまず並列化→依存キャッシュ→変更範囲テスト限定（モノレポならNx / Turborepo）の順で効きます。10分を切れない場合、毎回クリーンビルドや不要な統合テストが混ざっていないか疑うのが先です。

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

CDは「本番に届ける」だけではなく、段階的に環境を通過させながら検証するプロセスです。環境は最低3つ、理想は4つ用意します。

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

なお、ブランチ戦略はGitHub FlowかTrunk-Based（詳細は構成管理）、テストの構成はUnit 70 / Integration 20 / E2E 10のピラミッド（詳細はテスト設計）、デプロイ方式のBlue/Green・Canary・Feature Flagの使い分けは次回のデプロイ戦略で扱います。

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;

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

マイグレは独立したステップとしてコードデプロイの前に完了させ、PostgreSQLなら CREATE INDEX CONCURRENTLY、MySQLなら gh-ost 等で本番テーブルをロックしない運用が必須です。マイグレーションツール（Flyway・Prisma Migrate等）で変更をSQLファイルとしてコード管理し、Gitに乗せてPRでレビュー対象にするのが現代の標準です。

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

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

自動ロールバックの閾値は旧版（baseline）との相対比較で設定するのが定石です。絶対値にすると時間帯による変動で誤作動します。AWS CodeDeploy・Argo Rollouts・Flaggerなどが、この「メトリクス連動の自動段階展開」を標準装備しています。人間の目視判断だけに頼ると深夜に事故った時に誰も止められません。Gateは機械化するのが現代のCD設計です。

IaC・GitOps・DevSecOps・シークレット

IaC（Infrastructure as Code）は、インフラ構成をコードで定義し管理する手法です。標準はTerraform（またはOSSフォークのOpenTofu）で、マルチクラウド対応でほぼ全てのクラウドリソースをコード管理できます。CI/CDパイプラインに組み込み、インフラ変更もPull Requestでレビューするのが定石です。その他、AWS純正のCloudFormation / CDK、TypeScript等で書けるPulumiがあります。

GitOpsは、Gitリポジトリを唯一の真実（Single Source of Truth）として、Gitへのpushが自動でインフラに反映される方式です。Kubernetes環境ではArgoCDとFluxが2大ツールで、全変更がGit履歴に残り、git revert だけでロールバックできます。手動 kubectl apply を廃止する動きが標準になっています。

DevSecOpsは、パイプラインにセキュリティチェックを組み込む考え方です。SAST（Semgrep / CodeQL）・SCA（Dependabot / Snyk）・コンテナスキャン（Trivy）・IaCスキャン（Checkov / tfsec）をCIに乗せ、シフトレフト（早い段階で問題を見つける）で本番前に脆弱性を潰します。無料のDependabotだけでも必須レベルです（詳細は脆弱性診断）。

シークレット管理の現在の本命はOIDC連携です。GitHub ActionsからAWSにアクセスする際、長期のIAMアクセスキーをSecretsに保存する代わりに、GitHubの認証情報でAWSの一時トークンを取得する方式で、キーの漏洩リスクそのものが消えます。長期キーをSecretsに置くのは古い運用です。

3つのシナリオで考える

個人開発・スタートアップの場合

GitHub ActionsとVercelやCloud Runの自動デプロイで、mainマージ＝本番化という最小のCDを最初から作ってしまいましょう。pre-commitにはLintとgitleaksだけ入れて、重いパイプラインは組みません。この段階の唯一のゴールは、デプロイが怖くない状態を保つことだと思っています。

個人・スタートアップ ― 1か月で出せる構成が正解 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-startup/

中小SaaSの場合

GitHub ActionsにOIDC連携、TerraformによるIaC、段階リリースまで含めたフルセットに進む段階です。PR時のCIは10分以内を死守して、DBマイグレーションはexpand/contractで分割し、Canaryの判定はメトリクス連動で機械化していきます。

中小SaaS ― マネージドに寄せて少人数で回す ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-saas/

大企業・規制業種の場合

人の承認を挟むContinuous Delivery型が基本となります。変更諮問委員会（CAB）の承認ゲートや監査証跡の保存、ビルドした人とデプロイを承認する人を分ける職務分掌をパイプラインに組み込んで、規制要件を自動化の中に埋め込んでいく形です。

大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-enterprise/

AI判断軸 ― AIレビューとAIエージェントをパイプラインに組み込む

AIコードレビューをパイプラインに組み込む

2025年以降、CI/CDパイプラインの中にAIレビューを組み込むのが標準的な構成になりつつあります。PR作成時にAI（GitHub Copilot code review・CodeRabbit・PR-Agent等）が自動でレビューコメントを付け、人間のレビュアーはAIが見つけた指摘を確認するところから始められます。重要なのは、AIレビューを「人間レビューの代替」ではなく人間レビューの下準備として配置することです。

パイプライン上の配置は③段階（PR作成・更新時）のLint / テストと並列が定石です。最初はコメントのみ（non-blocking）で導入し、精度を確認してからblockingに昇格させる段階的アプローチが現実的です。

AIエージェントがパイプラインを操作する場合の設計

Claude Code等のAIエージェントが自律的にPRを作成し、CIを回してマージまで持っていくワークフローが現実になっています。考慮すべき点は3つです。

1. エージェント専用のGitHub Appを作る — 個人のPATを共有させず、操作を識別・制限できるidentityを持たせる
2. 保護ブランチ + 必須レビューは維持する — エージェントが直接mainにpushできない状態を保つ
3. パイプライン実行のコスト上限を設ける — 1PRあたりのCI再実行回数に上限を設定する

「AIが全自動でデプロイまでやる」構成は技術的には可能ですが、本番環境への影響がある操作には人間の承認ゲートを残しておくのが現時点での現実解です。なおGitHub ActionsのYAMLは宣言的で学習データも豊富なためAIが正確に書けます。JenkinsfileのGroovy DSLや独自CI製品の設定はAIの精度が落ちるため、「AIがパイプライン定義を読み書きできるか」自体が選定基準になります。

やってはいけないこと

CI/CDで事故る典型を、特に危険な6つに絞ります。

筆者メモ — Knight Capitalの45分

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

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

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

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

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

この記事に関連する記事

まとめ

本記事は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時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は GitHub Actions も合わせて参考にしてください。

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