ここでは、IaCツールとCI/CDパイプラインの実装において検討すべき主要なポイントを説明する。 ツール選定の基準、リソースの分割方針、パイプラインの構築方法、アプリケーションとインフラの管理方針など、実装時の判断基準や考え方を示す。

1. IaCツールの選定

IaCツールは、利用するCSPが推奨しているツール（例えば、AWSを利用する場合は AWS Cloud Development Kit（AWS CDK））を優先的に検討する。CSPが推奨しているツールには以下の利点がある。

• 新規サービスや機能への迅速な対応
• バグや脆弱性修正の早期提供
• CSPサポートによる技術支援の充実

ただし、開発チームが特定のIaCツールに習熟している場合や、特定のIaCツールのみが利用している機能を重要視する場合は、CSPが推奨しているツールとは異なるIaCツール（例： Terraform）の選択肢も候補として検討する。

2. IaC の分割方針

IaCでは、リソース（サーバー、データベース、ネットワークなど）をグループ化して管理できる。システムを構成するリソースを複数のグループに分割することで、管理責任を明確にし、変更時の影響範囲を限定できる。リソースを適切なグループへ分割するためには、表1 に示す3つの観点を、優先順位に従って検討することが重要である。

表 1 IaCにおけるリソースのグループ分割の観点

なお、表1に示す観点に加え、利用するIaCツール固有の推奨事項を加味して、最終的なグループの分割方針を決定する必要がある。IaCツールの設計思想に基づいた推奨事項と合わせて、総合的に分割方針を決定することが望ましい。IaCツールの推奨事項は変更される場合があるため、最新の公式ドキュメントを確認することが必要である。

3. インフラCI/CDパイプラインの構築

本節では、レベル3（CI/CDパイプラインによる自動デプロイ）を実現するための、パイプライン構築の具体的な方法を説明する。

3.1 パイプラインで自動化する手順

IaCソースコードのデプロイ用パイプラインで自動化する手順の例を表2 に示す。パイプラインには、セキュリティチェックを含むデプロイ内容のチェックからデプロイ実行、デプロイ結果の確認まで一貫した流れを組み込むことができる。セキュリティチェックでは、リソースの意図しないパブリック公開などの問題点をデプロイ実行前に検出できる。パイプラインでチェックを実施することで、実装者のローカル環境でのチェック実行状況に関わらず、すべてのデプロイに対してチェックを一貫して実行できる。なお、デプロイ結果の確認の例として、APIエンドポイントをパイプライン内で呼び出し、ネットワーク接続が正常であることや、APIエンドポイントを提供するアプリケーションが正常に動作することの確認が挙げられる。

また、IaCツールによっては独自の検証機能が提供されている場合がある。これらの独自の検証機能についても、セキュリティ要件や品質保証の観点から積極的な活用を検討されたい。

表 2 IaCソースコードのデプロイ用パイプラインで自動化する手順例

4. インフラCI/CDパイプラインのツール選定の考え方

IaCソースコードのデプロイを自動化するために、ソースコードの取得からIaCツールによるデプロイ実行まで、一連の作業を実施するパイプラインを構築する必要がある。パイプライン内でIaCツールを実行することで、人的ミスを排除した一貫性のあるデプロイが可能となる。

パイプラインの構築においては、セキュリティを確保しつつ、設計・初期構築・メンテナンス負荷を最小限に抑える方針とする。

上記方針に従ってパイプラインを構築するために、CSPのマネージドサービスやGitサービスの付随機能を優先的に検討する。これらのサービスや機能では、パイプライン実行環境の管理やログ管理等が自動化されており、パイプラインの構築に関するコストを低減できる。

仮想サーバー上にパイプライン用ミドルウェアを独自に構築する方式は、仮想サーバーの管理・保守やセキュリティ対策等の運用負荷が発生するため避けるべきである。特に、パイプラインの障害はシステムのリリースに影響するため、可用性確保の観点からもマネージドサービスまたはGitサービスの付随機能の利用を優先することが望ましい。

5. アプリとインフラの管理方針

パイプラインによるデプロイの自動化は、インフラ（IaC）とアプリケーションの両方で実現すべきである。ただし、両者を同一パイプラインで管理するか、分離するかは検討する必要がある。基本的には、アプリケーションとインフラでパイプラインを分離することが望ましい。

5.1 パイプライン分離の基本的な考え方

アプリケーションとインフラでは、更新頻度や変更の性質が大きく異なる。アプリケーションは機能追加やバグ修正で頻繁に更新される一方、インフラの更新は相対的に低頻度である。パイプラインを分離することで、それぞれの特性に合わせた最適な運用が可能になる。

パイプラインを分離する際は、どちらのパイプラインが何を担当するかを明確に定義する必要がある。基本的に、クラウドリソースに関する操作はインフラ側パイプラインに集約し、アプリケーション側パイプラインはアプリケーションのデプロイに必要な最小限の操作のみを行う。図1 に分離したパイプラインの責任分担イメージを示す。

図 1 分離したパイプラインの責任分担イメージ

責任分担の判断基準は以下の通りである。

データベースやネットワークなどクラウドリソースに関わる操作はインフラ側パイプラインが担当する。一方、コンテナイメージのビルド、デプロイ、アプリケーション設定の更新など、アプリケーション固有の操作はアプリケーション側パイプラインが担当する。

パイプライン間の連携は、インフラ側パイプラインがリソース名やエンドポイント等の情報を、設定管理サービスやIaCツールの出力機能を通じてアプリケーション側パイプラインに提供する。アプリケーション要件変更によりインフラ変更が必要な場合は、事前調整の上でインフラ側パイプラインで対応する。

5.2 リポジトリ管理の基本的な考え方

パイプラインと同様に、ソースコードを保管するリポジトリの管理方針も検討する必要がある。リポジトリの分離・統合は、チーム体制や開発規模に応じて判断する。

(1) チームが分離している場合

アプリケーションとインフラをそれぞれ別のチームで管理する場合（大規模開発に多い）、リポジトリも分離することが望ましい。リポジトリを統合していると、チーム間の調整コストが嵩むことになる。

リポジトリを分離することで、以下のメリットが得られる。

• それぞれのチームの責任範囲が明確になる。
• お互いが独立して作業を進めることが可能となる。
• 並行作業が容易になる。

(2) チームが統合されている場合

アプリケーションとインフラの両方を1つのチームで管理する場合（小規模開発に多い）、ソースコードを1つのリポジトリで保管する選択肢も有り得る。リポジトリを統合することで、以下のメリットが得られる。

• アプリケーションとインフラの間で依存する設定の管理が容易になる。
• リポジトリの管理コストを低減できる。
• チーム内の調整コストが小さいため、統合のデメリットが顕在化しにくい。

ただし、リポジトリを統合する場合でも、パイプラインは分離することを推奨する。利用するパイプラインツールによっては、リポジトリ内のどのファイルが更新されたかに応じてパイプライン実行を柔軟に切り替えることができない場合がある。その場合、アプリケーション変更時にインフラ側パイプラインも実行されてしまい、不要な処理が発生する可能性がある。パイプラインツールの機能と制約を考慮して判断する必要がある。

5.3 参考: パイプライン統合時のメリット・デメリット

アプリケーションとインフラでパイプラインを分離することが望ましい。ただし、統合にもメリットがあるため、プロジェクトの特性に応じて検討すべきである。

メリット:

• 小規模プロジェクトでは管理オーバーヘッドを削減できる。
• パイプライン自体の設定や保守が簡単になる。
• アプリケーションとインフラをまとめて管理するため整合性を保ちやすい。

デメリット:

• アプリケーション更新のたびにインフラ確認処理が実行され時間がかかる。
• インフラ側の問題がアプリケーションデプロイに波及する。
• 並行作業ができず開発効率が低下する。
• アプリケーションのみのロールバックが困難になる場合がある。

6. ブランチ戦略の検討

6.1 ブランチ戦略選択の考え方

IaCソースコードをGitリポジトリに格納し管理する場合は、Gitリポジトリのブランチの機能を効果的に利用することが望ましい。Gitリポジトリにおけるブランチとは、メインのソースコードから枝分かれして、独立して開発できる仕組みである。複数の開発者が同じGitリポジトリで並行して作業する際に、お互いの作業が干渉しないよう、作業内容や目的に応じてソースコードを分離して管理するためにブランチの機能を利用する。

ブランチをどのように作成・管理・統合するかを定めた運用方針のことをブランチ戦略と呼ぶ。ブランチ戦略として、GitHub FlowやGitLab Flowなど複数の方式が提唱されており、開発しているプロダクトや開発体制に合わせた戦略が選択されている。

IaCのブランチ戦略においては、アプリケーション開発とは異なる考慮が必要である。 アプリケーション開発では機能単位でのリリースが中心となるが、IaCでは環境（開発・検証・本番）単位での段階的な適用の場合が多い。また、インフラ変更は必ず下流環境から上流環境へ（開発環境→検証環境→本番環境）と一方向に進むという特性がある。このため、IaCではデプロイ対象の各環境に対応した複数のブランチを用意する方式が適している場合が多い。

6.2 ブランチ戦略に従ったデプロイの例(GitLabフロー戦略の例)

ブランチとして、開発環境、検証環境、本番環境のそれぞれに対応した、developブランチ、stagingブランチ、productionブランチを用意した場合のデプロイの例を以下に示す。このブランチ戦略は、一般的にGitLabフロー戦略と呼ばれているものである。

• develop(main)ブランチ: 開発環境に対応するブランチである。develop(main)ブランチへの直接コミットは禁止であり、開発者はdevelop(main)ブランチから作業用のfeatureブランチを分岐して作成し、個別のインフラ変更作業を実施する。作業の完了後プルリクエストを経由してdevelop(main)ブランチに統合される。develop(main)ブランチに統合されたのを契機としてデプロイ用のパイプラインを実行、または手動でパイプラインを実行し、開発環境に自動デプロイする。
• featureブランチ: 開発者は、個別のインフラ変更作業や機能開発のために、develop(main)ブランチからfeatureブランチを分岐して作成する。作業の完了後、プルリクエストを作成してコードレビュー（3.3.6節参照）を受け、承認後にfeatureブランチをdevelop(main)に統合する。
• stagingブランチ: 検証環境に対応するブランチである。検証環境において、本番適用前の最終的なインフラ変更内容の検証を実施する。開発環境での確認完了後、develop(main)ブランチをstagingブランチに統合して検証環境にデプロイする。
• productionブランチ: 本番環境に対応するブランチである。検証環境での確認完了後、stagingブランチからproductionブランチに統合して本番環境にデプロイする。

図 2 ブランチ戦略に従ったデプロイの流れの例(GitLabフロー戦略の例)

このように、インフラに対する変更点を本番環境へ直接適用するのではなく、各環境に対応した複数のブランチを活用し、段階的に検証を進めることで、変更点の適用時に発生する問題を事前に検出できる。

6.3 ブランチ戦略に従ったデプロイの例(GitHubフロー戦略の例)

ブランチとして、単一のmainブランチを用意し、機能開発やインフラ変更ごとにfeatureブランチを分岐する場合のデプロイの例を以下に示す。このブランチ戦略は、一般的にGitHubフロー戦略と呼ばれているものである。

• mainブランチ: 全環境（開発環境、検証環境、本番環境）へのデプロイのソースとなるブランチであり、常にデプロイ可能な状態を維持する。mainブランチへの直接コミットは禁止し、全ての変更はプルリクエストを経由して統合される。
• featureブランチ: GitLabフロー戦略のfeatureブランチと同じ。
• デプロイフロー: mainブランチへの統合後にリリースを発行することをトリガーとして、または手動起動にてデプロイ用のパイプラインを実行し、開発環境、検証環境、本番環境のそれぞれへデプロイされる。統合前に十分なテストと検証を実施することで、mainブランチの品質を担保する。

図 3 ブランチ戦略に従ったデプロイの流れの例(GitHubフロー戦略の例)

7. 手動デプロイから自動デプロイへの移行方法

IaCソースコードのデプロイは、3.3.5 IaCの活用レベルとデプロイ方式 で述べたとおり、システム開発当初からパイプラインによる自動化（レベル3）を導入することが望ましい。しかし、既存システムでレベル2（継続的にIaCを活用、手動デプロイ）の状態にある場合、レベル3への段階的移行が可能である。

本節では、レベル2からレベル3へ移行する際の具体的な手順を説明する。この移行により、手動デプロイ時の人的ミスのリスクとセキュリティリスクを根本的に排除し、Zero Touch Productionの実現に近づくことができる。

稼働中の本番環境への影響を避けるため、パイプライン自体の動作検証を段階的に行う。ガバメントクラウドでIaCのパイプラインによる自動化を実施する利用システムの場合は、本番環境・検証環境・開発環境の払い出しができるため、開発環境でパイプラインの基本動作を検証し、検証環境で本番に近い条件での動作を確認した後、本番環境に適用する。

7.1 前提条件

以下の手順は、次の条件を満たしていることを前提とする。

• 各環境（開発環境・検証環境・本番環境）に既にIaCソースコードが手動でデプロイされている。
• 現在のIaCソースコードと環境の状態が一致している。
• パイプラインの定義自体もIaCとして管理する。

7.2 導入手順

• ステップ1: 開発環境でのパイプライン構築
  • 開発環境において、IaCソースコード取得からセキュリティチェック等の検証までを含むパイプラインの基本構成を構築する。この段階では実際のデプロイは実行せず、IaCソースコードの検証機能の動作確認のみを行う。
• ステップ2: 開発環境での差分確認機能追加
  • パイプラインにIaCツールの差分確認コマンドの実行を追加し、現在デプロイされているIaCソースコードとの差分がないことを確認する。デプロイ時の影響を事前に確認するための差分確認コマンドを実行することで、パイプラインからデプロイを実行した場合に変更が発生せず、環境への影響がないことが確認できる。
• ステップ3: 開発環境でのデプロイ機能追加
  • パイプラインにIaCツールのデプロイの実行を追加し、実際のデプロイを実行する。ステップ2で差分がないことを確認済みのため、デプロイを実行してもリソースに変更は発生しない。これにより、デプロイ機能の動作確認を安全に行える。
  • ※パイプラインの定義自体もIaCとして管理するため、ステップ3が終了すると、開発環境で検証済みのパイプラインの定義がIaCソースコードして作成されていることになる。
• ステップ4: 検証環境への適用
  • 開発環境で検証済みのパイプラインのIaCソースコードを検証環境にデプロイする。ステップ2・3と同様の手順で差分確認とデプロイ機能の検証を実行する。
• ステップ5: 本番環境への適用
  • 検証環境で検証済みのパイプラインのIaCソースコードを本番環境にデプロイする。ステップ2・3と同様の手順で差分確認とデプロイ機能の検証を実行する。

上記手順完了後、次回以降のIaCソースコード更新時には、構築したパイプラインによる自動デプロイが実行される。

7.3 移行完了後の対応

パイプラインによる自動デプロイが正常に動作することを確認した後、手動デプロイ時に使用していた担当者の権限を削除する。これにより、手動による変更を防ぎ、全ての変更がパイプラインを経由することを保証できる。権限削除は、パイプラインの安定稼働を十分に確認してから実施し、緊急時対応用の権限については別途検討する。