Infrastructure as Code（IaC）は、クラウドインフラ管理の標準手法として定着した。しかし2026年現在、単なるインフラのコード化では不十分となり、ガバナンス・セキュリティ・コンプライアンスを自動的に強制する「IaC 2.0」への進化が急速に進んでいる。Gartnerによれば、2026年には80%の大規模ソフトウェアエンジニアリング組織がInternal Developer Platform（IDP）を導入し、その基盤としてIaC 2.0・Policy-as-Code・GitOpsの三位一体が不可欠となる。本記事では、この新たなインフラ自動化の標準について解説する。

IaC 2.0とは何か ── 検知から強制への進化

従来のIaC 1.0は「インフラをコードで定義する」という概念に留まっていた。Terraform、CloudFormation、Pulumiといったツールでインフラを宣言的に記述し、バージョン管理し、再現可能にする。これだけでも大きな進歩であったが、2026年の現実はさらに厳しい要求を突きつけている。

IaC 2.0の核心は「検知から強制へ」のパラダイムシフトである。従来のツールは問題を検知してアラートを発行するに留まり、修正は人間の手に委ねられていた。しかしAIによるコード生成が爆発的に増加した現在、手動レビューはもはやスケールしない。CNCFの調査によれば、81%の組織が「生成AIによる変更速度に手動レビューが追いつかない」と回答している。

IaC 2.0では、ポリシー違反はマージやデプロイのパイプラインで自動的にブロックされる。問題がJiraチケットに積み上がるのを待つのではなく、問題を含むコードはそもそもマージできない。これがガバナンスを「組み込む」という意味である。

Policy-as-Code ── ガバナンスのコード化

Policy-as-Code（PaC）は、セキュリティ・コンプライアンス・ガバナンスのルールを機械可読なファイルとして記述し、ツールによって自動評価・強制する実践である。紙のポリシードキュメントやスプレッドシートでのチェックリストを、CI/CDパイプライン、インフラプロビジョニング、ランタイムにおける自動チェックに置き換える。

典型的なPolicy-as-Codeのユースケースには以下がある：

  • S3バケットのパブリックアクセスを自動ブロック
  • 必須タグ（コスト配分、オーナー、環境区分）の強制
  • Kubernetesリソースのアドミッション時検証
  • 暗号化要件を満たさないTerraformプランの却下
  • リソース制限（CPU/メモリ上限）の強制

重要なのは、これらのポリシーがインフラコードと同様にバージョン管理され、レビューされ、テストされることである。ポリシーもコードとして扱うことで、変更履歴の追跡、ロールバック、監査対応が可能となる。

Open Policy Agent（OPA）の中核的役割

Policy-as-Codeの実装において、Open Policy Agent（OPA）が業界標準として台頭している。OPAはCNCFの卒業プロジェクトであり、Regoという高水準の宣言的言語でポリシーを記述する。

OPAの強みは、あらゆるシステムに統合できる汎用性にある。Kubernetes、マイクロサービス、CI/CDパイプライン、Terraform、API Gatewayなど、ポリシー評価が必要なあらゆる場所でOPAを活用できる。SpaceLift、env0、Atlantisといったプラットフォームは、OPAをネイティブに統合し、Terraform、OpenTofu、Pulumi、CloudFormation、Kubernetesのデプロイメントに対してポリシーを適用する。

HashiCorp Sentinel、Checkov、Regula、Kyverno、Gatekeeper（OPAのKubernetes向けラッパー）など、複数のPolicy-as-Codeツールが存在するが、OPAはその汎用性と成熟度から、エンタープライズ環境で最も広く採用されている。2026年には、OPAポリシーライブラリがオープンソースコミュニティで共有され、業界標準のコンプライアンスルールセット（CIS Benchmarks、PCI DSS、SOC 2など）がすぐに利用可能となっている。

GitOps ── 宣言的デリバリーの決定版

IaC 2.0とPolicy-as-Codeを実現するための配信メカニズムとして、GitOpsが決定的な役割を果たす。CNCFの2025年調査によれば、77%の組織がGitOpsを採用しており、64%以上がArgo CDをプロダクション環境で2年以上運用している。

GitOpsの原則は明確である。Gitリポジトリが「信頼できる唯一の情報源（Single Source of Truth）」となり、すべてのインフラ・アプリケーション設定はGitに宣言される。実際の状態がGitの宣言と乖離すれば、自動的に修正される（Reconciliation）。この自己修復（Self-healing）機能により、ドリフト検知と修正が自動化される。

2025年のCNCF調査では、GitOps採用の動機として71%が「ソフトウェアデリバリーの高速化」を、66%が「設定管理の改善」と「デプロイメント一貫性の向上」を挙げている。さらに60%が「高速な復旧とロールバック」をセキュリティ向上の重要な要素として評価している。

Argo CDは2026年1月時点で97%がプロダクション利用、NPS（ネットプロモータースコア）79を記録し、KubernetesクラスタのGitOpsソリューションとしてデファクトスタンダードの地位を確立した。プラットフォームエンジニアがユーザーの37%を占め、内部開発プラットフォーム（IDP）におけるArgo CDの役割が拡大している。

Internal Developer Platform（IDP）との統合

Gartnerは、2026年に80%の大規模ソフトウェアエンジニアリング組織がプラットフォームエンジニアリングチームを設立し、再利用可能なサービス・コンポーネント・ツールの内部プロバイダーとなると予測した（2022年の45%から上昇）。この予測は現実となり、IDPはエンタープライズITの標準アーキテクチャとなっている。

IDPは、IaC 2.0・Policy-as-Code・GitOpsを統合するオーケストレーションレイヤーとして機能する。開発者はセルフサービスポータルからインフラをリクエストし、そのリクエストは事前定義されたポリシーによって自動検証される。承認されたリクエストはGitOpsパイプラインを通じてプロビジョニングされ、継続的にポリシー準拠が監視される。

Backstage（SpotifyがオープンソースしたCNCFプロジェクト）、Port、Cortex、Humanitecといったプラットフォームが、IDPの構築基盤として広く採用されている。これらは開発者体験を抽象化しつつ、背後でIaC・Policy-as-Code・GitOpsのワークフローを実行する。

実装への道筋 ── 段階的アプローチ

IaC 2.0への移行は一夜にして達成できるものではない。以下の段階的アプローチが推奨される。

フェーズ1：基盤整備

  • 既存のIaCコードをGitリポジトリに統合（すべてのTerraform/CloudFormationをバージョン管理下に）
  • 命名規則・タグ付け規則の標準化
  • モジュール化による再利用可能なコンポーネントの構築

フェーズ2：ポリシー導入

  • OPAまたは同等ツールの導入
  • 最も重要なポリシー（セキュリティ・コンプライアンス）から開始
  • CI/CDパイプラインへのポリシーチェック統合
  • 初期は警告モードで運用し、チームの学習曲線を考慮

フェーズ3：GitOps化

  • Argo CDまたはFlux CDの導入
  • プルリクエストベースのインフラ変更ワークフロー確立
  • ドリフト検知と自動修復の有効化

フェーズ4：プラットフォーム化

  • 開発者向けセルフサービスポータルの構築
  • ゴールデンパス（推奨ワークフロー）の定義
  • メトリクス・可観測性の統合

FAQ

IaC 2.0と従来のIaCの最大の違いは何ですか？

従来のIaCがインフラの「コード化」に焦点を当てていたのに対し、IaC 2.0はガバナンス・セキュリティ・コンプライアンスの「自動強制」を核心とする。問題を検知してアラートするのではなく、ポリシー違反をパイプラインレベルで自動ブロックする点が決定的な違いである。

Policy-as-Codeの導入にはどのツールを選ぶべきですか？

汎用性と成熟度の観点から、Open Policy Agent（OPA）が最も広く推奨される。Kubernetes中心の環境ではGatekeeper（OPAのラッパー）やKyvernoも選択肢となる。HashiCorp製品を中心に構築している場合はSentinelも有力である。

GitOpsを導入するとどのような効果がありますか？

CNCFの調査によれば、GitOps採用組織の71%がソフトウェアデリバリーの高速化を、66%が設定管理の改善とデプロイメント一貫性の向上を報告している。また、60%が高速な復旧・ロールバック能力をセキュリティ上の重要なメリットとして挙げている。

小規模な組織でもIaC 2.0は必要ですか？

組織規模によらず、クラウドインフラのセキュリティとコンプライアンスは重要である。小規模組織では段階的に導入し、まず最もリスクの高い領域（本番環境、機密データを扱うサービス）からポリシーを適用することを推奨する。

参考文献