IaC 化のその向こうへ - ポチポチ運用からセブンフェーズの進化⚡

この記事は Microsoft Azure Tech Advent Calendar 2025🎄 の 5 日目の記事 です。
なおかつ、 Azure PoC 部 Advent Calendar 2025🎄 の 5 日目の記事 です。

---

こんにちは、アーキテクトのやまぱんです。
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

私はお客様に対して IaC の導入を支援することがあり、その中で、感じたことがあります。
生成 AI の発展により、IaC 化のハードルはどんどん下がっているし、恩恵はどんどん上がっているということです。
逆に言うと、IaC を導入しないまま従来手法だけに留まってしまうと、以下のような運用負荷が積み上がります。

• 構成変更履歴の追跡負担：日々の変更を記録・照合する作業が手作業になり、レビューや監査で毎回ログを掘り起こす工数が膨らみます。
• 運用コストと人件費の肥大化：棚卸しや設定変更を人力で回し続けるため、繁忙期ほど追加要員や残業でしのぐサイクルから抜け出しにくくなります。
• 経営判断スピードの低下：自動化へ投資した競合はリリースやガバナンスを高速化できる一方、手動運用では構成差分や影響調査に時間を取られ、意思決定のバックログが積みあがります。

Section 1. はじめに

AI 時代の IaC は、従来の自動化を超えて「AI による自動生成・最適化・レビュー」という次元に進化しています。

「Azure は使ってるけど、ポータルでポチポチ作ってる…」
「IaC って聞いたことあるけど、導入する価値あるの？」

そんな Azure をはじめとしたパブリッククラウドユーザーや IaC 未経験者に向けて、IaC の導入が組織にもたらす価値を、進化の段階ごとに体系的に解説します。
単なる自動化の話ではなく、DevOps / DevSecOps から GitOps、Platform Engineering、そして AI 活用まで見据えた「IaC の未来」について、Azure を用いて具体例とともにお伝えします。
さらに、IaC (Bicep / Terraform など) と AI の組み合わせは「ビジネスのアジリティ向上」と「セキュリティ・ポリシー適用の高速化」を両立できます。これが IaC × AI の最強セットです。

きっと IaC の導入を進めたくなると思います。

• パブリッククラウド × IaC × AI の必然性：クラウド利用が当たり前になった今こそ、Azure などで IaC により環境差分ゼロと監査ログを同時に実現すべきです。生成 AI が雛形づくりやレビューを肩代わりしてくれるので、IaC 導入のハードルは驚くほど低くなりました。AI がテンプレート生成やレビューを担えば、デリバリー速度と構成品質を一緒に引き上げつつポリシー逸脱を自動検知できます。
• 読者ターゲット：IaC 導入を検討している IT 部門、既存の GUI ポータル運用から脱却したい Azure ユーザー

本記事は約 30 分で読めます。Phase 4（DevSecOps 統合）までの概要を掴みたい方は、「Section 3. IaC の 7 フェーズ」の表と「Section 4. 各フェーズの実務ユースケース」を中心にお読みください。

読み方ガイド（ペルソナ別）

• 初心者 / IaC 未経験者：Section 2〜4 で基礎と導入ステップを押さえ、Phase 4 までのイメージを固める。
• 実務者 / SRE / アーキテクト：Section 5〜8 でガバナンス・GitOps・デモの運用ポイントを重点的にチェック。
• 先進事例・AI 活用を知りたい方：Section 7〜9 の未来像と Copilot 活用例をピックアップ読み。
  気になるパートから読み進めてください。

前提として押さえておきたい用語

• Git：分散型バージョン管理システム。ブランチで並行開発し PR で差分レビューできる。（https://git-scm.com/doc）
• CI/CD：継続的インテグレーション／継続的デリバリー。自動ビルドとデプロイで変更の品質と頻度を両立するパイプライン。（https://learn.microsoft.com/ja-jp/devops/deliver/what-is-continuous-delivery）
• コンテナ：アプリと依存関係をイメージにまとめ、どこでも同じ構成で動かせるパッケージ技術。（https://learn.microsoft.com/ja-jp/dotnet/architecture/microservices/container-docker-introduction/docker-defined）
  ザックリ内容を把握しておけば、本文中の実践例をスムーズに追えます。

Section 2. IaC の基礎

IaC（Infrastructure as Code）の基本を押さえておきましょう。

• ポータル操作との違い：ポータルは「手作業の再現が困難」「作業・変更履歴の取得が困難」になりがちです。一方 IaC はコードレビューや CI に乗せられるため、監査性と再現性が飛躍的に高まります。Azure の コードとしてのインフラストラクチャを使用して Azure 環境をデプロイおよび管理する でも、Azure では Bicep や Terraform を使った IaC 管理をベースに保管ツールとして手続き型のスクリプト (Azure CLI や Azure PowerShell などのスクリプト言語) が推奨されています。

• 主要 IaC ツール：

  • Bicep：Azure 専用の宣言的テンプレートで、ARM Template(JSON) へビルドでき既存資産も活かせます。型補完やモジュール分割が標準のため構造化しやすく、いま Azure 向け IaC を書くなら Bicep が最も実務的だと思っています。
  • Terraform：複数クラウドを同じワークフローで扱えるオープンソースの IaC ツールです。クラウドごとに IaC の仕組みが存在し、どの環境でも構成をコードで再現できるようになっています。

バージョン管理システムの歴史 🕰️

CVS → SVN → Git と進化する過程で、バージョン管理は集中管理から分散管理へ移りました。Git はローカルで完全な履歴を持てるためブランチ運用やレビューが軽く、IaC の変更を Pull Request で検証する現在のワークフローと相性抜群です。Phase 2 以降では Git を基盤にした運用を前提に考えましょう。

Section 3. IaC の 7 フェーズ 🚀

Azure 現場でよく見る成熟パターンを 7 段階に独自に整理し、比較しました。Phase 6（Platform Engineering & AIOps）は未来志向の内容なので、詳細は後半の「Section 7. IaC × AI の未来」でまとめてご紹介します。

図解：IaC 成熟度の進化フロー

最低でも Phase 4（DevSecOps 統合）までは到達しよう！！
ここまで進めば「宣言 → 共有 → 自動テスト → セキュリティ検査」までが一気通貫で回り、事故前に差し戻せる体制になります。Phase 0-3 で止まるとヒューマンエラーやポリシー違反を見逃しやすいので、多少の学習コストを払っても Phase 4 まではやり切るのが実務的には最もコスパが高いです。クラウド利用規模や業種を問わず、顧客データや社内基盤を守る組織なら誰でもここまでは共通の必須ラインだと考えています。
※あくまで筆者個人の感想

GitOps（Phase 5）や Platform Engineering / AIOps（Phase 6）は、Git を唯一の信頼できるソース（SSOT）として Desired State（目標状態）を自動同期したい場合やセルフサービス化を推進する組織に強い選択肢ですが、Phase 4 までの CI/CD + Policy as Code（DevSecOps 統合）で十分コントロールできている環境では無理に適用せず、要件に応じて段階的に評価するのがおすすめです。

Phase	概念	技術	ユースケース	メリット	デメリット	学習コスト
0	手動構築	手動操作ツール（ポータル / スクリプトなど）	小規模 PoC、緊急対応	学習コストが低く即座に対応できる	再現性なし、ヒューマンエラー多発	低
1	IaC 導入	宣言的 IaC テンプレート	Dev / Stage / Prod を同じテンプレで構築 (ローカル管理可)	再現性とドキュメント化を同時に実現	学習コストと初期整備が必要、バージョン管理なしでは履歴が追いにくい	低〜中
2	バージョン管理システム統合	バージョン管理システム	Pull Request（以下 PR）運用やブランチ戦略の定着、差分管理の可視化	変更履歴・レビュー・ロールバックをコードで管理	Git / ブランチ設計とシークレット扱いの難度	中
3	CI/CD 統合	CI/CD パイプライン	PR / Push トリガーの自動テストと反映	自動テスト・承認フローでデプロイ時間を短縮	パイプライン設計が複雑	中〜高
4	DevSecOps 統合	IaC 静的検証	本番前の IaC スキャン、ポリシー違反の早期検出	セキュリティとコンプライアンスを自動検証	ツールチェーンが複雑化、False Positive 対応が必要	中〜高
5	GitOps & ガバナンス	GitOps エンジン + ランタイムガバナンス	組織標準テンプレート、タグ強制	Git を唯一の信頼できるソース（SSOT）としてガバナンスと FinOps を両立	GitOps ツール習熟、依存関係管理が複雑	高
6	Platform Engineering & AIOps	開発者ポータル / AI アシスタント	ゴールデンパス提供、AI によるレビュー	セルフサービス化と AI 補助で Time-to-Market を最短化	プラットフォーム構築コストと AI 出力の最終確認が必要	高

Phase 4 と Phase 5 の Policy の違い
Phase 4 で扱う Azure Policy や Checkov は PR / what-if 段階の静的検証として機能し、リリース前に違反を差し戻します。Phase 5 では Azure Policy / OPA をランタイムガバナンスとして活用し、稼働中リソースのドリフトを検知・強制修正する運用統制を指しています。

ハンズオンで体験したい方へ
後述の「Section 8. DevSecOps を感じるデモ アプリ」で紹介する azure-devsecops-demo では、Phase 0〜4 を Bicep + GitHub Actions で実際に体験できます。詳細はレポジトリを参照してください。

Section 4. 各フェーズの実務ユースケース

Phase 0〜6 の段階差を一言で言えば「属人業務からクラウドネイティブな継続改善ループへの転換」で、具体的に言えば「手作業 → コード化 → 自動検証 → セルフサービス」です。

各フェーズの詳細に入る前に、まず「誰が何を担当するのか」を明確にしておきましょう。

👥 ロール分担の現場例

以下は大規模組織での典型的な分担例です。ただし、あくまで一例であり、組織規模やカルチャーによって最適解は異なります。

チーム	担当領域	Phase との関係
アプリチーム	要件定義・開発・PR 作成	Phase 1〜3（IaC 作成・バージョン管理・CI/CD）
プラットフォーム / セキュリティチーム	ガードレール設計・ツール運用・Policy as Code	Phase 4（DevSecOps 統合）
SRE / インフラチーム	GitOps 同期エンジン・監視・ドリフト検出	Phase 5（GitOps & ガバナンス）
プラットフォームチーム	ゴールデンパス整備・開発者ポータル運用	Phase 6（Platform Engineering）

DevOps の本質は「壁を取り払う」こと
上記のようなチーム分担はあくまで責務の整理であり、DevOps のベストプラクティスでは「Dev と Ops を厳密に分けない」ことが推奨されます。チームを分けすぎると、かえってサイロ化やハンドオフの遅延を招く恐れがあります。理想は 1 つのクロスファンクショナルチームが開発から運用まで一気通貫で担う 形です。ガードレール（Policy as Code）やプラットフォーム基盤は「誰かが専任で整備する」というより、チーム全員がオーナーシップを持ちつつ、必要に応じて専門性の高いメンバーがリードする、という柔軟な体制が現実的です。

小規模チームの場合
小規模チームでは 1 人が複数の役割を兼務することも多く、むしろ DevOps の理想形に近づきやすいです。「誰がガードレールを整備するか」だけは最初に決めておくと、Phase 4 への到達がスムーズになります。

この分担を頭に入れたうえで、各フェーズのユースケースを見ていきましょう。

フェーズ別ユースケース概要

前のセクションで述べたとおり、まずは Phase 4 を目指しましょう。「宣言 → 共有 → 自動検証 → セキュリティゲート」という一連のループが PR の場で閉じるため、手戻りや緊急対応の頻度を減らせます。Phase 3 以前だとガードレールが弱く、レビュー品質がレビュワーの経験値に依存しがちです。

• Phase 0：リソースを作成する際はポータル操作を録画し、後で IaC に移行する TODO を作る。
• Phase 1：宣言的 IaC ファイル（例：Bicep / Terraform）を単体で管理し、パラメータファイルの切り替えだけで Dev / Stage / Prod を再現。共有はローカル ZIP やファイルサーバーでも開始でき、のちに Git へ移行します。
• Phase 2：バージョン管理システム（例：GitHub / Azure Repos）で env/dev のようなブランチ戦略を敷き、PR でレビュー + 承認を必須化。Git の履歴や PR 差分で変更理由・責任者を追跡できるため、構成変更の監査が一気に楽になります。シークレットは OIDC + Key Vault や GitHub Actions / Azure Pipelines の Secrets などに保管し、リポジトリへ平文で残さない方針を徹底します。
• Phase 3：CI/CD パイプライン（例：GitHub Actions）を PR 作成で動かし、bicep build や terraform fmt/validate を実行してからマージ後に自動デプロイ。障害時は保護ルールで人の承認を必須化してリスクを低減します。
• Phase 4：静的解析ツール（例：Checkov / tfsec）の結果とクラウドポリシーの deny ログを PR コメントに貼り、開発者がその場で修正できるフローを構築。IaC 修正に即反映します。
• Phase 5：クラウドを直接変更せず、PR だけで本番を更新します。Flux / Argo などの GitOps エージェントが Git と本番を自動同期し、Azure Policy の deny が手動更新をブロック、deployIfNotExists や Flux の Reconcile が逸脱を自動補正します。RBAC は Contributor 以上を PIM で一時付与に絞る or 読み取り専用に落とし、ブランチ保護 + 必須レビュー + Environments Approvals で PR 以外の変更ルートをなくすと「Git にマージされた内容だけが反映される」SSOT を実務で再現できます。
• Phase 6：プラットフォームチームが「ゴールデンパス」（標準テンプレート + CI/CD）を整備し、開発者はセルフサービスポータルから環境を即時払い出し。AI アシスタントがレビュー結果をナレッジ化し、改善サイクルを加速します。

Section 5. DevOps 系プラクティスと発展形

アプリの DevOps（コードをビルド → テスト → デプロイ）と、インフラ/IaC の DevOps（テンプレートを宣言 → レビュー → 自動適用）は対象こそ違えど「PR を唯一の変更窓口にして継続改善する」という文化を共有しています。両者を同じリポジトリとパイプラインで走らせることで、アプリ差分とインフラ差分をセットで審査し、ガードレールの効いたループを一本化できます。

ここからは IaC パイプラインを支える文化的プラクティスと、その発展形である Platform Engineering・AIOps を整理します。DevOps → DevSecOps → GitOps の流れを押さえたうえで、Platform Engineering によるセルフサービス化と AIOps による自律運用を組み合わせると、Phase 6 で目指す「開発者体験の最大化 × 運用負荷の最小化」が現実味を帯びてきます。

DevOps / DevSecOps / GitOps

ここではまず、IaC パイプラインを支える 3 つの文化的プラクティスを整理します。Git を唯一の信頼できるソース（SSOT）に据えて開発フローを統一（DevOps）し、そのパイプラインにセキュリティ検査をシフトレフト（DevSecOps）で組み込むことで、さらに目標状態を Git と同期させる運用モデル（GitOps）へ自然につなげられます。GitOps エージェント（Flux / Argo など）は Git 内の IaC と本番環境の差分を常時照合し、ドリフトを検知したら即座に Git 側の宣言へ引き戻すため、PR が構成変更の唯一の入り口であり監査証跡でもある、と明言できるようになります。

図解：DevOps / DevSecOps / GitOps の関係性

• DevOps：アプリとインフラを同じチームで継続改善し、IaC を CI/CD パイプラインへ組み込んでリードタイム短縮と変更失敗率低減を狙う文化的実践です。
• DevSecOps：DevOps パイプラインへセキュリティ検査（例：静的解析ツール、クラウドセキュリティセンター）をシフトレフトして「早期検知 → 自動ゲート」を実現。
• GitOps：IaC の目標状態を Git で唯一の信頼できるソース（SSOT）に固定し、同期エンジン（例：Flux / Argo CD）が本番環境との差分を常時照合。ドリフト検知で即座に Git 側の宣言へ戻すため、PR が唯一の変更経路であり監査証跡も自動で蓄積されます。

ライフサイクル段階	DevOps	DevSecOps	GitOps
設計〜実装	チケット駆動（Azure Boards / Jira で変更理由と責務を一元化）+ ペアレビューでドメイン知識を共有	SAST（CodeQL）と IaC スキャン（Checkov）で要件段階のミスを抑止	-
PR / CI	CI ワークフローでビルド・Lint・テンプレート差分を自動検証	Secret Scan（Gitleaks）、SCA（Dependabot）、Azure Policy deny の早期検知	-
デプロイ	CD で Dev / Stage / Prod 間の構成差分をゼロに近づける	セキュリティサマリとポリシーログを承認の必須資料としてレビューに添付	GitOps エージェントが目標状態を適用
運用	MTTR / リリース頻度を可視化	Defender for Cloud / Trivy で継続スキャン、アラートを SLA で追跡	Flux / Argo がドリフト検出 → 自動修復

SAST / DAST / IaC スキャンの役割

対象は違っても、いずれも早期検知でリリース前にリスクを潰すことが目的です。

• SAST（アプリの静的解析）：CodeQL などでアプリコードをスキャンし、SQL インジェクションや認可漏れを PR の段階で自動検出します。
• DAST（実行環境の攻撃シミュレーション）：OWASP ZAP などで稼働中のアプリをテストし、設定ミスや想定外の応答を洗い出します。
• IaC スキャン（インフラテンプレートの静的解析）：Checkov や tfsec で Bicep / Terraform を検証し、公開ストレージや不要なポート開放といった違反を PR 前に止めます。

標準フローとしては「PR 受付 → 事前差分プレビュー（例：bicep what-if / terraform plan）→ SAST + SCA + Secret Scan → Azure Policy / Checkov のゲート → GitOps エージェントによる適用 → 監視 / ログ基盤で稼働中のメトリクスとポリシー逸脱を可視化 → 改善チケット起票」という一本のループを意識すると、文化の境界が曖昧にならずに済みます。

KPI 例：

• DevOps：リードタイムとデプロイ頻度でフロー効率を測り、変更失敗率で安定性を併せて追跡する（DORA 指標で Dev / Ops のバランスを可視化）。
• DevSecOps：SAST 検出から修正までの平均時間やポリシー deny 件数、Secret Scan の再発率を追うことで、シフトレフトの速度とガードレールの効き具合を測定できる。
• GitOps：同期遅延・ドリフト検出件数・手動 HOTFIX 比率を監視すると、SSOT がどれだけ保たれているか、Git 外の迂回変更が発生していないかを定量化できる。

ロール分担の詳細は「Section 4. 各フェーズの実務ユースケース」の「👥 ロール分担の現場例」を参照してください。

この先の Platform Engineering / AIOps 連携は未来志向の Phase 6 以降のテーマなので、詳細は Section 7. IaC × AI の未来 で図解と合わせて整理しています。

Section 6. 事前ツールセット

Phase 4 でポリシーゲートを固めるには、Azure Cloud Adoption Framework が推奨するように CLI / エディタ / セキュリティツールを早期に統一して再現性を担保 することが近道です（Use infrastructure as code to deploy and manage your Azure environment）。

Phase 4 直前チェックリスト（最小構成）

• Azure CLI：ローカル検証や IaC 実行端末でも一貫した操作感を得るため、az login を OIDC / Service Principal で自動化し、az config set auto-upgrade.enable=yes + az upgrade で CLI / 拡張を常に最新化。az config set core.only_show_errors=yes でコンソール出力を簡潔に保ち、同じ設定をパイプラインにも流用できる状態にします。
• VS Code 拡張：Bicep / Terraform / ARM ツール + GitHub Copilot + YAML Lint を統一し、全員同じ補完を得られるようにする。
• Checkov / Trivy：PR で IaC / コンテナをスキャンし、結果を Step Summary で共有する。
• 補助ツール：Terraform Cloud Remote State、OIDC + Azure Key Vault、taskfile.yml でコマンドを標準化。
• ガイドライン：.github/copilot-instructions.md やチーム共通のスタイルガイドにコーディング規約・レビュー観点・Copilot 利用ルールを集約し、AI からの提案も同じ基準でチェックできるようにする。※ Copilot を使う際は Get started with GitHub Copilot in Azure で提示されている認証・責任共有モデルを参照し、個人情報や秘密情報をプロンプトへ入れない運用を徹底。

Section 7. IaC × AI の未来

ここからは少し未来の話も交えつつ、「すでに一部の現場で動き始めている近未来像」を覗いてみましょう。

AI がドラフト生成と PR レビューを担い、人がポリシー・セキュリティの最終判断を下す構造にすると、学習コストを抑えつつ品質とスピードを両立できます。

さらに、AI をモニタリング / ログ基盤（Azure なら Azure Monitor / Log Analytics など）と組み合わせることで、設計・レビューだけでなく運用監視や障害対応まで一気通貫で支援できます。メトリック・ログ収集とアラートを統合することで異常検知から根本原因分析までを自動化できるようになる世界が到来しつつあります。また GitHub Copilot や Azure OpenAI にアラート内容と IaC の変更履歴を連携すると、再発防止の IaC パッチ案や ワークフロー 改修案を即座に得られます。

加えて、Azure Monitor 自体が AIOps と機械学習機能を取り込みつつあります。Microsoft Learn の Azure Monitor で AIOps と機械学習を使用して潜在的な問題を検出して軽減する では、インシデント相関や異常検知を ML モデルが自動実行し、ノイズ削減や根本原因特定に役立てるワークフローが紹介されています。Azure 側でこのような前処理が走るように進化しつつあるため、Copilot や Azure OpenAI は精度の高いシグナルを受け取り、IaC の差分やポリシー変更と突き合わせながら再発防止策を提示しやすくなります。

プレビュー提供中の Azure SRE Agent を組み合わせると、Azure リソースのインシデント対応や定期運用を AI がチャット形式で肩代わりできます。コネクタ機能では、Outlook / Microsoft Teams への通知、Datadog / Dynatrace / New Relic などの監視プラットフォームからのテレメトリ取得、さらにカスタム MCP サーバーを通じた外部サービス統合が可能です。また コードリポジトリ接続により GitHub / Azure DevOps と連携し、インシデントのトリアージ・根本原因分析・緩和アクションを実行前レビュー付きで提案してくれるため、Phase 6 以降で目指す「Self-Healing な SRE エージェント」を Azure ネイティブに試せます。

Azure SRE Agent の言語制限（2025 年 11 月時点）
現時点では、Azure SRE Agent のチャットインターフェイスは 英語のみ サポートされています。今後のアップデートで多言語対応が期待されますが、導入検討時はこの制限を考慮してください。

Platform Engineering / AIOps の接続イメージ

Phase 6 で掲げた Platform Engineering × AIOps の姿は、AI にレビューと改善を任せつつゴールデンパスでセルフサービスを回す開発体験です。

図解：DevOps / DevSecOps / GitOps に Platform Engineering と AIOps を統合したもの

• Platform Engineering：承認済み IaC テンプレートと CI/CD を「ゴールデンパス」として配布し、開発者ポータルから即時に環境を払い出します。Azure では azd テンプレートや Azure Deployment Environments がこの仕組みを提供してくれるので、環境差分を最初から潰したままセルフサービス化できます。
• AIOps：ログ／メトリクスを AI で分析し、異常検知 → 根本原因分析 → 自動修復を担います。Azure Monitor の AIOps 機能 やプレビュー中の Azure SRE Agent が担当し、Platform チームが整備したガードレールに沿って復旧案を提示してくれます。

レイヤー	DevOps / DevSecOps / GitOps	Platform Engineering	AIOps
開発フェーズ	PR でコードレビュー + セキュリティスキャン	ゴールデンパスで環境を即時払い出し	-
デプロイフェーズ	GitOps エージェントが目標状態を適用	IDP がガバナンス（タグ・コスト）強制	-
運用フェーズ	ドリフト検出 → 自動修復	開発者ポータルで稼働状況を可視化	異常検知 → RCA → 自動修復
改善フェーズ	KPI（MTTR / 変更失敗率）を追跡	テンプレート改善を PR で反映	インシデント傾向を学習 → 予防策を提案

この 3 層がそろうと「PR を出すだけで安全に環境が立ち上がり、運用は AI が 24 時間見張っている」状態になります。現場では Platform チームがガードレール更新を PR 化し、AIOps が拾ったノイズや誤検知を週次レビューで潰していくと運用コストが安定します。

• 価値拡張：AI が要件ヒアリングをもとに Bicep / Terraform の初期ドラフトを生成し、エンジニアはレビューとガードレール設計に集中できます。
• 学習コスト低減：Copilot Chat へエラーログを貼り付けると修正提案が返るため、チーム全体のキャッチアップ時間を短縮。必要に応じて公式ドキュメントも参照しましょう。
• 現場 Tips：LLM の提案をそのまま適用せず、what-if / plan で差分を確認してからマージする。AI の出力を再利用する際はプロンプトと結果をドキュメント化しておくと、後続の検証やナレッジ共有に効果的です。

これまで整理した観点を踏まえて、ここからは実際に手を動かして学べるハンズオンリポジトリを紹介します。

Section 8. DevSecOps を感じるデモ アプリ

「まずは小さな PoC で Phase 4 を体感したい」という方は、Microsoft Learn の Azure Policy の概要 と連動したデモリポジトリ aktsmm/azure-devsecops-demo を触ってみてください。Azure Policy / Checkov の結果を PR に集約し、GitHub Actions 上でガードレールの動きをそのまま追えます。

詳しいコマンドや画面キャプチャは README_QUICKSTART.md にまとまっているので、上記ステップをそのままなぞれば最小構成の DevSecOps ループを半日以内に PoC できます。

リポジトリ内の README.md / README_QUICKSTART.md にシナリオ、ワークフロー図、トラブルシューティングがまとまっています。本文では概要のみに絞り、詳細はレポジトリで確認してください。

デモリポジトリ：https://github.com/aktsmm/azure-devsecops-demo

🎯 このデモで体験できること

• Phase 0〜4 を一気に再現：Bicep + GitHub Actions で構成 → what-if → デプロイ → Policy 適用のループを確認
• Security Shift-left：PR を起点に Checkov / Azure Policy を走らせ、違反があっても、警告は出すものの、ワークフロー自体は止めずに最後まで証跡を残す運用を確認（デモでは「DevOps ループの一連フローを体験する」ことを優先し、敢えて止めずに最後まで what-if → Deploy → Policy まで流しています。本番では ワークフローを強制停止し、CI から先へ進ませない運用が推奨）
• IaC + アプリの同時運用：Board / Admin の 2 アプリを AKS へ継続デプロイし、バックアップやヘルスチェックまで一貫化

🔄 GitHub Actions ワークフロー構成

7 本のワークフローが Validate → what-if → Deploy → Azure Policy 適用までを分担しつつ、メイン 3 本＋サポート 4 本 の二層構成になっています。

• メインライン（1〜3 本）：
  • 1-infra-deploy.yml：Bicep 基盤デプロイ（what-if → Deploy）後に policy-deploy ジョブで Azure Policy 定義と割り当ても IaC 化。
  • 2-board-app-build-deploy.yml / 2-admin-app-build-deploy.yml：2 系統のアプリをビルド & リリースし、IaC で敷いた基盤にコードを届ける本流です。
• サポートライン（4〜7 本）：
  • backup-upload.yml / cleanup-workflows.yml / security-scan.yml / azure-health-check.yml：バックアップ・クリーンアップ・多層スキャン・ドリフト復旧などの補助機能を束ね、詳細手順はリポジトリ本体の README.md（READMEs/README_WORKFLOWS.md など）に記載しています。

🛡️ Security Scan ワークフローのイメージ

security-scan.yml では CodeQL / Trivy / Gitleaks / GitGuardian / Dependabot を一括実行し、Step Summary と security-top-findings.json へ結果を集約します。図を見れば PUSH を起点にどのスキャンが動いたか一目で追跡できるので、PR → スキャン → 修正 → 再実行の DevSecOps ループを実践的に理解できます。

🚀 QUICKSTART：ハンズオンの始め方

Service Principal 作成 → GitHub Secrets 投入 → 1-infra-deploy.yml 手動トリガーの 3 ステップを、図付きで README_QUICKSTART.md にまとめています。

💡 このデモの勘所

• Step Summary 集約：security-scan.yml が CodeQL / Trivy / Gitleaks など 5 つの結果を Step Summary + security-top-findings.json に束ね、PR 1 画面で確認できます。
• PR 一元管理：README.md のガイド通り、what-if・Checkov・Azure Policy ログを PR コメントへ集約して証跡を一本化します。
• Azure Policy × GitOps：1-infra-deploy.yml → 2-*-app-build-deploy.yml → Policy 適用を Actions のみで回し、PR → Actions を唯一の変更パスにする文化を体感できます。

Section 9. 生成 AI 活用ポイント

GitHub Copilot と Azure CLI を用いて、各種メトリックとログを一元化できると検出から是正までのループを高速化できます。ここに GitHub CLI を組み合わせると、ワークフロー履歴や Activity Log、リソース構成差分を AI が横断確認してくれるため、IaC パイプラインの失敗原因や再発防止策を PR と同じ場（GitHub Copilot など）で言語化できます。

特に GitHub Copilot は Bicep / ARM の補完に最適化されており、自然言語から Azure リソース定義をドラフト生成できるので、開発経験の浅いメンバーでも宣言的テンプレートを素早く組み立てられます。手戻りの多いセクションは Copilot が型情報とリソース依存関係を提案してくれるため、レビュー観点に集中でき、ツールを正しく使いこなせば未経験者でも IaC の可能性を大きく広げられます（Get started with GitHub Copilot in Azure）。

以下は、私が効果を実感した 4 つの活用パターンです。

• VS Code + GitHub Copilot：エディタ上で Bicep Module や parameter file のドラフトを一気に生成し、bicep build / bicep lint で落ちた箇所をその場で直してもらう用途に振り切っています。型の不整合や dependsOn 抜けを即時に埋めてもらえるので、雛形づくりとファーストフィックスが爆速です。
• Copilot Chat でレビュー：ワークスペース全体や az deployment what-if / gh run view の結果をまとめて読ませ、構成レビュー・影響範囲の洗い出し・PR コメントの叩き台づくりを任せます。複数モジュールを横断したトラブルシューティングを会話で詰められるので、セルフレビューの精度が段違いでした。
• Copilot + git CLI + GitHub CLI + Azure CLI🚀：自然言語で「最新 PR のステータスを GitHub CLI で調べて」「直近のワークフローの失敗原因をトラブルシューティングして」と頼むだけで gh pr status や gh run view、必要な git / Azure CLI コマンドを自動発行し、結果を 1 つのチャットで要約まで返してくれるのが特にうれしいところ。コマンドを暗記していなくても、同僚に駆け込み相談するノリで運用ペアリングを回せます。🚀
• プロンプト管理：/prompts ディレクトリに業務で効果が高かった Prompt を Markdown で保存し、フェーズ別に使い分けると属人化を防げます。

Section 10. まとめ

本記事では、IaC の進化を 7 フェーズに整理し、各段階のメリットと実務ユースケースを紹介しました。

• Phase 4 を最低目標に：セキュリティゲートを PR に組み込むことで、事故を未然に防げる体制が整います。
• IaC × AI で学習コスト激減：GitHub Copilot や Azure OpenAI がドラフト作成・レビューを支援し、チームのキャッチアップ時間を短縮できます。
• 小さく始めて段階的に成熟：Phase 0 → 1 → 2 と順に進め、無理なく GitOps / Platform Engineering へ。
• ハンズオンで体感：aktsmm/azure-devsecops-demo で Phase 4 までの DevSecOps ループを実際に試してみてください。

IaC は「導入したら終わり」ではなく、継続的に成熟度を上げていく旅路です。まずは Phase 4 を目指し、AI の力を借りて「安全・迅速・再現性の高い」インフラ運用を実現しましょう！

Section 11. 用語集

• DevOps：開発と運用を同じチームで継続改善する文化・実践。IaC を CI/CD に組み込むことで俊敏なリリースを支えます。
• DevSecOps：セキュリティ検査をシフトレフトし、PR の段階で脆弱性や設定ミスを自動検出する考え方です。
• GitOps：Git を唯一の信頼できるソース（SSOT）として目標状態を宣言し、Flux や Argo CD などの同期エンジンが環境へ適用する運用モデルです。
• SSOT（Single Source of Truth）：信頼できる唯一の情報源。IaC では Git リポジトリを SSOT として扱い、構成変更や監査証跡をすべて PR に集約します。
• ランタイムガバナンス（Runtime Governance）：Azure Policy や OPA で稼働中リソースの状態を継続評価し、違反時にアラートや自動修正で目標状態へ戻す運用統制です。
• シフトレフト：テストやセキュリティチェックをライフサイクルの早期段階へ前倒しするアプローチです。
• SAST（Static Application Security Testing）：アプリケーションコードを静的解析し、SQL インジェクションや認可漏れなどを検出します。
• DAST（Dynamic Application Security Testing）：稼働中のアプリに疑似攻撃を行い、設定ミスや脆弱な応答を検出します。
• Secret Scan：GitHub Advanced Security や Azure DevOps の Secret Scanning 機能を使い、API キーや PAT などの秘匿情報がコミットや PR へ混入していないかを自動検出するワークフローです。
• SCA（Software Composition Analysis）：Dependabot や Microsoft Defender for DevOps が行うように、OSS 依存関係のバージョンと脆弱性データベースを照合し、修正バージョンへの更新を促す解析です。
• IaC スキャン：Bicep や Terraform テンプレートを静的解析し、公開ストレージなどのリスクをデプロイ前に検知します。
• Checkov：Bridgecrew 製の IaC セキュリティスキャナー。Bicep / Terraform / ARM などを解析し、CIS Benchmarks や社内ポリシー違反を PR で可視化します。
• tfsec：Aqua Security の OSS スキャナーで Terraform コードを対象にし、危険なデフォルト値やポート開放を静的解析で検出します。
• Flux / Argo CD：代表的な GitOps エンジン。Flux は Azure Arc GitOps の公式実装でも採用されています。
• Platform Engineering：開発者ポータルやゴールデンパスを整備し、セルフサービスで安定した環境提供を実現する組織的取り組みです。
• AIOps：監視データを機械学習で分析し、異常検知や自動復旧を支援する運用手法です。
• DORA 指標：DevOps Research and Assessment が提唱するリードタイム・デプロイ頻度・変更失敗率・平均復旧時間の 4 つのメトリックで、継続的デリバリー体制の成熟度を定量評価する指標です。
• Environments Approvals：GitHub Actions の保護環境（environment）で手動承認を必須にし、本番デプロイ前に SRE やセキュリティ担当が最後の Go / No-Go を行うゲート機能です。
• copilot-instructions：.github/copilot-instructions.md のようにリポジトリ単位で Copilot への執筆ルールや文体を定義し、生成 AI からの提案をチーム標準へ揃えるためのカスタムガイドラインです。

Section 12. 参考 URL 一覧

IaC / DevOps 基盤

• コードとしてのインフラストラクチャを使用して Azure 環境をデプロイおよび管理する — Bicep/Terraform 選定指針、モジュール設計、CI/CD パイプライン構築、What-If + Azure Policy によるドリフト検知
• aktsmm/azure-devsecops-demo README — AKS/ACA/MySQL VM/ACR を含む DevSecOps デモ。CodeQL・Trivy・Gitleaks 等のセキュリティスキャン統合例
• aktsmm/azure-devsecops-demo QUICKSTART — デモ環境構築手順。Service Principal 作成、GitHub Secrets 設定、IaC デプロイ、アプリビルドの流れ
• GitHub Actions で Azure に安全・簡単にデプロイしたい — Configure Azure Settings を使った OIDC 連携で GitHub Actions からセキュアにデプロイ
• GitOps (Flux v2) を使用したアプリケーション デプロイ — Flux クラスター拡張機能と各種コントローラー（Source/Kustomize/Helm/Notification）による Git 同期

セキュリティ / DevSecOps

• Microsoft Azure でセキュリティで保護されたアプリケーションを開発する — SDL 実装フェーズ：コードレビュー、静的解析(SAST)、動的テスト(DAST)、ファジング、ペネトレーションテスト
• Microsoft Defender for Containers の概要 — コンテナーのセキュリティ態勢管理、脆弱性評価、Kubernetes ノード/クラスターの実行時保護
• GitHub Advanced Security for Azure DevOps 機能を構成する — シークレットスキャン・依存関係スキャン・CodeQL によるコードスキャンの有効化手順

ガバナンス / 監視

• Azure Policy の概要 — JSON ベースのポリシー定義、audit/deny/modify/deployIfNotExists エフェクト、イニシアティブ、コンプライアンスダッシュボード
• Azure Monitor の概要 — メトリクス・ログ・トレース・変更の統合データ基盤。ダッシュボード/ワークブック/Grafana 連携、アラート/オートスケール

Platform Engineering / セルフサービス

• Backstage を完全に理解した — Spotify 製の開発者ポータル OSS。ゴールデンパス・サービスカタログの実装例
• Azure Deployment Environments の概要 — IaC テンプレートベースのセルフサービス環境プロビジョニング。CI/CD 連携、サンドボックス、ガバナンス統制

AI / AIOps

• Azure Monitor で AIOps と機械学習を使用して潜在的な問題を検出して軽減する — ML ベースの異常検出、ログデータの異常パターン特定・対応支援
• Azure SRE Agent の概要 — AI 駆動のインシデント調査・自己回復システム支援エージェント（プレビュー）
• Azure SRE Agent コネクタ — 外部サービス統合（通信コネクタ・データ取り込みコネクタ）の設定
• Azure SRE Agent コードリポジトリ接続 — GitHub/Azure DevOps 連携による詳細な根本原因分析とサマリーレポート生成
• AWS DevOps Agent と Azure SRE Agent で変わるオンコールの未来 — AWS DevOps Agent と Azure SRE Agent の自律性・連携範囲・ガバナンス姿勢を比較し、選定ポイントを整理

GitHub Copilot / エージェント

• Get started with GitHub Copilot in Azure — VS Code 拡張機能のセットアップ、Azure リソースクエリ、CLI コマンド生成、Bicep/ARM 支援
• GitHub Copilot の runSubagent を検証してみた：コンテキスト分離の効果と限界 — runSubagent の仕組みとトークン消費・実行時間の検証結果から、コンテキスト管理のベストプラクティスを解説
• GitHub Copilot サブエージェントによるオーケストレーター パターンの実践 — Issue 生成から PR 作成までをサブエージェントへ委譲するオーケストレーション設計と責任分離の考え方を紹介
• GitHub Copilot の設定ファイルをテンプレ管理するツールを作った話 — .github 配下の Copilot 指示ファイルをテンプレ化して再利用する dotgh の使い方とメリットを解説

Special Thanks

本記事の改善にあたり Microsoft の ussvgr / S.Yoshikawa 氏から多くのフィードバックをいただきました。

ありがとうございました。