Shinji Takenaka Experience 2022 - Present: Cloud Solution Architect at Microsoft 2021 - 2022: Solutions Architect at SORACOM 2012 - 2021: Software Engineer at Nintendo Skills Cloud Computing : Azure/GitHub/Bicep/Python IoT : AWS/Terraform/Go/TypeScript Software Development : C++/C#/Python Social Website GitHub LinkedIn

進化する開発：生成AIとIaCが拓く未来！​ タイトル IaC をフル活用したアプリ開発の最前線 日時 2025年 1月31日（金） 14:30-17:00 形式 オフライン (日本マイクロソフト株式会社 関西支店) 対象 業務部門 / IT部門 / ノーコード開発・分析にご興味のある方 定員 24名 イベント申し込み締め切り 2025年 1月28日（火）

Agenda 1. IaC とはなにか？ 2. IaC が解決する課題 3. Azure での IaC の実践 4. Demo: AI Agent のデプロイ 5. 組織での IaC の導入

質問タイム

IaC とはなにか？

IaC とはなにか？ Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバーなど）の構成管理・ 機械処理可能な定義ファイルの設定・プロビジョニングを自動化するプロセスである。 Wikipedia > Infrastructure as Code

クラウドインフラ管理手法の変遷 1. 手動操作 (Azure ポータル) 2. スクリプト (SDK, Azure CLI/Powershell) 3. プロビジョニングツール (ARM Template) 4. プログラミング言語/DSL (Bicep, Terraform) ← IaC に分類されるものはこれ 管理手法の進化を辿りながら仕組みを理解する

手動操作 ツール Azure ポータル 利点 簡単に操作できる 欠点 繰り返し操作が面倒 人的ミスが発生しやすい 時間がかかる 例: Azure ポータル 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL

スクリプト ツール SDK Azure CLI / Powershell 利点 繰り返し操作が可能 操作手順を自動化できる バージョン管理が可能 欠点 言語の学習コストがかかる テストが難しい ロールバック、アップデートが難しい 例: Azure CLI 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL !#/bin/bash # リソースグループを作成する az group create \ --name demoResourceGroup \ --location japanwest

プロビジョニングツール ツール ARM Template 利点 自動化が容易 テンプレートを使ってインフラストラクチャを 定義できる テンプレートを使って再利用が可能 テンプレートを使って環境を再現できる 欠点 サービスの学習コストがかかる 抽象化がなく、実装詳細の認知コストが高い 例: ARM Template 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL { "$schema": "https://schema.management.azure.com/schemas/ "contentVersion": "1.0.0.0", "resources": [ { "type": "Microsoft.Resources/deployments", "apiVersion": "2021-04-01", "name": "nestedDeployment", "resourceGroup": "demoResourceGroup", "properties": { "mode": "Incremental", "template": { resource-group-resources } } } ],

プログラミング言語/DSL ツール Bicep Terraform 利点 プログラミング言語の恩恵を受けられる テストが容易 バージョン管理が容易 抽象化が可能 欠点 記述言語の学習コストがかかる 例: Bicep 手動操作 > スクリプト > プロビジョニングツール > プログラミング言語/DSL targetScope='subscription' param resourceGroupName string param resourceGroupLocation string resource newRG 'Microsoft.Resources/resourceGroups@2024-03 name: resourceGroupName location: resourceGroupLocation }

IaC の基本概念 コードのパラダイム 手続き型 手順をステップバイステップで実行 (手動操作、スクリプト) ロールバックをどう実装するか? 再試行をどう実装するか? 宣言型 望ましい最終状態を記述 (プロビジョニングツール、プログラミング言語/DSL) 現在の状態との差分を計算して変更を適用 同じコードを何度実行しても同じ結果になる !#/bin/bash az group create \ --name myResourceGroup \ --location japaneast resource "azurerm_resource_group" "rg" { name = "myResourceGroup" location = "japaneast" }

Azure でのリソース管理の全体像 Azure CLI New-AzResourceGroupDeployment PowerShell terraform apply Azure Resource Manager az deployment group create Deploy to Azure button Azure Portal ... ARM Template Compile Bicep Terraform (Provider) Authentication Microsoft Entra ID HCL SDK (Go) SDK (Python) SDK (.NET) Azure Resource Manager の呼び出し経路が違うだけでやってることはほどんど同じ

IaC が解決する課題

IaC 利用者の声 新規プロジェクト立ち上げ時の環境構築が自動化され、顧客への納期が大幅に改善しました。 インフラ構成の変更履歴をGitでバージョン管理することで、問題発生時に原因を特定し、迅速に復旧でき るようになりました。 IaC を導入したら環境の再現性が高まって開発環境、テスト環境、本番環境で全く同じ構成を保てるように なりました。 インフラ構成の変更がシステムに与える影響を、事前にテストできるようになったため、リリース時のリス クを大幅に軽減できました。 複数のチームで共通のインフラを利用する際、コードレビューを通じて、チーム全体でのコラボレーション が活発化しました。 IaC の効能 ♨️

IaC が解決する課題 特徴 説明 自動化 手作業による設定ミスを削減し、一貫性のあるインフラストラクチャ構築を実現 バージョン管理 バージョン管理システムを利用でき、インフラの変更履歴の追跡やロールバックが容易 再現性 異なる環境に同じインフラストラクチャを容易に再現できる テスト コードとして記述されているため容易にテストが可能 コラボレーション コードレビューなどを通じて、チームでの共同作業が可能

IaC を利用するメリット 1. ソフトウェア開発のようにインフラを構築: ソフトウェア開発の手法を適用できる 2. インフラの再現が容易: 異なる環境に同じインフラストラクチャを容易に再現できる 3. 組織全体での共通基盤化: IaC ツールの機能であるモジュール化、パラメータ化を活用できる

ソフトウェア開発のようにインフラを構築 バージョン管理システムでコードを管理 コード変更を Pull Request でレビュー コード変更時の静的解析 デプロイの自動化 出典: GitHub Actions を使用して Azure インフラストラクチャにデプロ イする ソフトウェア開発の手法を適用できる

インフラの再現が容易 aka.ms/awesome-azd: Azure Developer CLI で Azure リソースを作成するためのテンプレート 異なる環境に同じインフラストラクチャを容易に再現できる # --- # [構築手順の例] # --- REPOSITORY_URL=https://github.com/Azure-Samples/ # カレントディレクトリで azd プロジェクトを初期化 azd init --template $REPOSITORY_URL # リソースのプロビジョニングとアプリのデプロイ azd up # リソースの削除 azd down

組織全体での共通基盤化 出典: 株式会社 エーピーコミュニケーションズ > Bicep (IaC)ファイルの共通モジュール化の取り組み 共通設定と固有設定を分離し、共通モジュール化を推進し開発効率を向上させる

Azure での IaC の実践

IaC を実現するテクノロジー IaC ツール 提供元 対象クラウド アプローチ 記述言語 Bicep Microsoft Azure 宣言型 Bicep ARM Template Microsoft Azure 宣言型 JSON Terraform HashiCorp Azure, AWS, GCP, etc 宣言型 HCL Pulumi Pulumi Azure, AWS, GCP, etc 宣言型 TypeScript, Python, Go, … Ansible Red Hat Azure, AWS, GCP, etc 手続き型 YAML

Bicep について Azure リソースの IaC を実現するために Microsoft が開発したドメイン固有言語 (DSL) 簡潔で可読性の高い構文でインフラストラクチャを定義 すべてのリソースの種類と API バージョンのサポート VS Code の Bicep 拡張機能などのツールサポートが充実 Bicep とは

Bicep の記法 ~ 例: Storage Account の作成 ~ リソースの定義: main.bicep パラメーターファイル: main.bicepparam 1 param storageSKU string = 'Standard_LRS' 2 param location string = resourceGroup().location 3 4 @description('ストレージアカウント名に使用するプレフィックス') 5 @minLength(3) 6 @maxLength(11) 7 param storagePrefix string 8 9 var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGr 10 11 resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = { 12 name: uniqueStorageName 13 location: location 14 sku: { 15 name: storageSKU 16 } 17 kind: 'StorageV2' 18 properties: { 19 supportsHttpsTrafficOnly: true 1 using main.bicep' 2 3 // storageSKU, location は省略可能 4 5 var prefix = 'my' 6 param storagePrefix = '${prefix}storage'

Bicep での開発環境 ツール名 概要 Bicep CLI commands Bicep ファイルをビルド、デプロイするための CLI コマンド Bicep language support for Visual Studio Code Visual Studio Code で Bicep ファイルを編集するための拡張機能 Bicep Bicep is a declarative language for describing and deploying Azure resources

Azure CLI を使ったデプロイ 1. Azure アカウントにログイン 2. Bicep で定義されたリソースをデプロイ az login --use-device-code # 変数の設定 RESOURCE_GROUP_NAME=rg-sukiyanenazure-iac-20250131 # リソースグループを作成 az group create \ --name $RESOURCE_GROUP_NAME \ --location japaneast # Bicep テンプレートをデプロイ az deployment group create \ --resource-group $RESOURCE_GROUP_NAME \ --template-file main.bicep \ --parameters main.bicepparam

Terraform について 出典: What is Terraform? HashiCorpによって開発されたオープンソースの IaC ツール AWS, Azure, GCP などのサービスに対応 ワークフローは、3 つのステージで構成される 1. Write: HCL でインフラストラクチャを記述 2. Plan: リソースの変更をレビュー 3. Apply: リソースの変更を適用

Terraform(HCL) の記法 ~例:Storage Account の作成~ リソースの定義: main.tf パラメーターファイル: variables.tf 12 name = "${var.name}sa" 13 location = var.location 14 tags = var.tags 15 resource_group_name = var.resource_group_name 1 terraform { 2 required_version = ">= 1.6.0" 3 required_providers { 4 azurerm = { 5 source = "hashicorp/azurerm" 6 version = "~> 4.5.0" 7 } 8 } 9 } 10 11 resource "azurerm_storage_account" "storage_account" { 16 account_tier = "Standard" 17 account_replication_type = "LRS" 18 allow_nested_items_to_be_public = false 19 } 1 variable "name" { 2 description = "リソース名" 3 type = string 4 } 5 6 variable "location" { 7 description = "リソースのリージョン" 8 type = string 9 } 10 11 variable "tags" { 12 description = "リソースのタグ" 13 type = map(any) 14 default = {} 15 } 16 17 variable "resource_group_name" { 18 description = "リソースグループ名" 19 type = string 20 }

Terraform での開発環境 ツール名 概要 Terraform CLI Terraform ファイルをビルド、デプロイするための CLI コマンド Terraform Extension for Visual Studio Code Visual Studio Code で Terraform ファイルを編集するための拡 張機能 TFLint Terraform ファイルの静的解析ツール Trivy コンテナイメージの脆弱性スキャンツール

Terraform を使ったデプロイ 1. Azure アカウントにログイン 2. Terraform で定義されたリソースをデプロイ az login --use-device-code export ARM_SUBSCRIPTION_ID= # プロジェクトの初期化 terraform init # プランの作成 terraform plan -out=tfplan # リソースのデプロイ terraform apply tfplan

Terraform 固有の特徴 カスタムプロバイダーを開発することで、任意の API に対して Terraform での管理が可能になる カスタムプロバイダーを開発する求人 さくらインターネット > ソフトウェア開発エンジニア(クラウドSDK) 実際に作ってみたブログ Terraform provider for SORACOM を作って Azure Functions と連携してみた 出典: Plugin Development

Terraform 固有の特徴 出典: GitHub Actions から OpenID Connect で Azure に接続する設定作業を Terraform で自動化する クロスプラットフォーム対応の例: Azure だけでなく、AWS, GCP, GitHub などのサービスに対応

Bicep と Terraform の比較 記法そのものはほとんど変わらず、モジュール化・パラメータ化もほぼ同じ 片方を習得すればもう片方の習得も容易 リソースグループを作成する例 Bicep Terraform resource rg 'Microsoft.Resources/resourceGroups@2021-04-01 name: 'myResourceGroup' location: 'japaneast' } resource "azurerm_resource_group" "rg" { name = "myResourceGroup" location = "japaneast" }

Bicep と Terraform の比較 基本は Bicep、クロスプラットフォーム対応が必要な場合は Terraform 選定基準は MS Learn > Terraform と Bicep の比較 が参考になる ツール 個人的な選択理由 Bicep デフォルトの選択肢。機能への追従が早い。開発環境が整っている。 Terraform クロスプラットフォームで使いたい場合に選択。周辺ツールが充実している。 ARM Template 基本的には触らない (どうしても直接 ARM Template を触る必要がある場合のみ) 個人的な選択基準

エコシステム タスクランナー アプリケーションのデプロイ、インフラのプロビジョニング、事前/事後処理などの自動化に利用 ツール: シェルスクリプト, Makefile, Azure Developer CLI など CI/CD プルリクエストの自動テスト、デプロイの自動化 ツール: GitHub Actions, Azure DevOps Azure Verified Modules (AVM) Azure のベストプラクティスに準拠したモジュール Bicep, Terraform で利用可能

Azure Developer CLI Azure の使用を開始するのにかかる時間を短縮する Azure Developer CLI (azd) azure.yaml に定義された手順が実行される。暗黙的なデフォルトの挙動を理解する必要がある Azure/azure-dev でソースは公開されている 出典: Introducing the Azure Developer CLI (azd): A faster way to build apps for the cloud Azure Developer CLI テンプレートの概要

Azure Developer CLI を使ったデプロイ 0. リポジトリのクローン 1. Azure アカウントにログイン 2. azd 環境の作成 3. リソースのプロビジョニングとアプリのデプロイ azure.yaml git clone $REPOSITORY_URL azd auth login --use-device-code azd env new azd up name: yourApp-terraform metadata: template: [email protected] services: web: project: ./src/web dist: build language: js host: appservice api: project: ./src/api language: js host: appservice

タスクランナーの選定 サンプルが azd に準拠している場合は Azure Developer CLI を使うと無難 Microsoft が提供するサンプルコードは azd に準拠することが多い(例: awesome-azd) 開発チームが使い慣れているツールを使う 宗派が色々あるため、開発チームのスキルセットに合わせる CI のパイプラインなどでも必要になるため、依存関係少なくクイックに動かせるものが好ましい 手持ちのスキルセットとの整合性を考慮

Demo

Demo: AI Agent アプリのデプロイ Azure Container Apps に AI Agent アプリを Terraform でデプロイする # リポジトリのクローン git clone https://github.com/ks6088ts-labs/basel cd infra/scenarios/workshop_azure_openai # 環境変数の設定 export ARM_SUBSCRIPTION_ID=$(az account show -- # 変数ファイルの作成 cat < terraform.tfvars create_container_app = "true" container_app_image = "ks6088ts/workshop-llm-ag container_app_ingress_target_port = "8501" ... EOF # Terraform でデプロイ terraform init terraform apply -auto-approve

組織での IaC の導入

新技術の導入プロセス 導入に必要なタスクを要素分解して小さなステップの連なりに分ける 後ろのステップが実現されなかったとしてもそれぞれ価値を持つように並べる 組織の現在地に合わせてステップを選択する 出典: 詳解 Terraform 第3版 //////////////////////////////////////////////////////////////////////////////////////////////////////////// 例: 新たに IaC ツールを導入する場合 1. IaC ツールを導入するためのワークショップ・勉強会を実施する (ここで終わってもノウハウは残る) 2. 新規プロジェクトなどで小規模に IaC ツールを活用してみる (ここで終わっても実践した経験が残る) 3. IaC ツールを活用した CI/CD の導入 (ここからは文化として根付かせて維持していく) 新たに導入する場合は 漸進主義 で少しづつ進めることを意識する

強い個の力で打開する お伺いを立てる前に手を動かし、実践して既成事実を作り、パッションとともに推進する

組織での IaC の導入 開発に求められる技術領域が広く、複雑化してきた (CI/CD, IaC, MLOps, DevSecOps, Observability, …) 開発者の認知負荷を下げつつ幅広い技術を使いこなして生産性を向上させる芸の価値が高まる プラットフォームエンジニアリングという言葉が流行する背景

やることは"関心の分離" 例: Android Platform アプリ開発者は Linux Kernel のことを意識しながらアプリケー ションを書くことはほぼ無いし意識したくもない ひとつ下のレイヤーだけを意識して開発するのがあるべき姿 隠蔽することで開発者は自分の関心事に集中できるし、プラッ トフォームのメンテナンスは容易になる 関心事を分離して"知らなくていいこと"を隠蔽する

利用者観点で「知らなくていいこと」を増やす ベストプラクティスを知る Bicep に関するベスト プラクティス に準拠する 利用者が変更しないパラメータを隠蔽する 変数として露出はさせず、モジュール内部で固定する 利用者が変更するパラメータ 「変更したい変数だけ認知して変更できる」、「変更したくない変数は知らなくて良い」状態を作る 尤もらしい default 値を備えたモジュールを作り溜める 要求に合わない default だけ変更すれば良い モジュール分割単位のちょうど良さは組織やプロジェクトのフェーズによって異なる 定期的な振り返り、ディスカッションが必要 GitHub Discussions などで DR (Decision Record) を残す IaC のモジュール化の判断軸

プラットフォームを維持するための設計 いきなり共通基盤化は難しい 情報が少ない中で必要十分な外部仕様を定義することが難しい どう始めるか？ まずは成功した事例(AVM や世間のベストプラクティスなど)をベースラインにする いくつか成功した具体的な事例を積み上げて、共通項を見つけて抽象化すると尚良し プラットフォームの寿命は外部仕様で決まる ユーザーストーリーに基づいて外部仕様を定義する 闇雲に内部仕様(変数、利用リソース、etc)をさらさない Assert, Validation はまずは厳しくする (緩めるのは簡単だが、厳しくするのは後方互換性を損なう) 自社にあった外部仕様を漸進的に定義していく モジュール分割の指針、デプロイ対象の環境、デプロイの頻度、などは組織によって異なる 利用者のフィードバックとプラットフォーム開発者の改善のループを高速に回す

プラットフォームを維持するための自動化 Fail Fast するための自動化 Bicep では What-If 操作、Terraform は terraform plan を CI に組み込む 特に AI model は更新頻度が高く、プラットフォーマ側の変更により IaC コードが陳腐化しやすい 引数の Validation、静的解析、コードフォーマット、テストを徹底する ヒューマンエラーを排除するための自動化 デプロイが常に一貫性のある環境から行われることを保証する インフラコードをデプロイする権限を CI サーバーに集約する 雑多な作業を排除するための自動化 Dependabot などを使って、依存関係の更新を自動化する 自動化！自動化！自動化！

参考資料 スライド 俺とAzureとTerraform ～2024新春バージョン～ Azure Developer CLI Deep Dive MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた コード awesome-azd AI app templates github.com/Azure-Samples github.com/Azure github.com/Microsoft baseline-environment-on-azure-terraform baseline-environment-on-azure-bicep