👻
LLM時代はテキスト形式でドキュメントを書く 5. IaCとAIエージェント

2025/10/29に公開
Infrastructure as Codeの説明と、AIコーディングエージェント時代の考え方を書きます。

 Infrastructure as Code(IaC)とは従来(2000年代)は、インフラの設定管理をExcel手順書などで実施していましたが、
GUIベースなので設定に時間がかかる
設定時にオペミスのリスクがある
手順書修正する際に面倒。ミスも発生する。
と、効率的ではありませんでした。(唯一のメリットはGUIなので初心者でも作業できること)
この問題を解決する手段の1つとして、スクリプトベースでのインフラ設定がありました。
GUIベースなので設定に時間がかかる → スクリプトベースなので短時間
設定時にオペミスのリスクがある → スクリプトベースなので人や気分で設定内容が変わる事はない
手順書修正する際に面倒。ミスも発生する。 → 変更箇所のテキスト差分を出せるので、ミスが発覚しづらい
この流れがIT業界に波及、2010年代中盤にはWindowsOSもPowerShellを利用する事でさまざまな設定ができるようになりました。

 スクリプト設定からIaCへただしスクリプトでの実行は柔軟性が高いものではありませんでした。例えば、どこかで設定ミスして作業を中断し、もう一度スクリプトを実行する場合、例えば作成済みのユーザーの再作成するなど、最初の方のコマンドを再実行することでエラーが発生する可能性があります。
解決策として、if文で「既に作成済みの場合はスキップする」などすればよいですが、コードの見通しが悪くなり、シンプルなはずのスクリプト設定がかえって複雑になってしまいました。
そこで登場したのが宣言型のIaCです。宣言型というのは作業を命令するのではなく、状態を定義する方法で、例えば
ユーザー○○が存在する
と宣言して実行すると、ユーザー○○が存在すればOK、存在しなければ作成し、結果的に存在すればOKにしてくれます。期待される結果を書けば内部作業はシステム側で実施してくれるので、条件分岐などは不要です。代表的な宣言型ツールは以下です。
Windows：Powershell DSC
Azure：ARMテンプレート、Bicep
Microsoft 365：Microsoft 365 DSC
マルチクラウド：Terraform
**ある操作を1回行っても、複数回行っても、システムの状態が同じ結果になる性質を冪等性(べきとうせい)**と呼び、IaC = スクリプトで一発設定すればOKではなく、冪等性(べきとうせい)を持つもの、と定義されてます。

 宣言型IaCはちょっと難しい以下がBicepの構文です。
Bicep ファイルの構造と構文 - Azure Resource Manager | Microsoft Learn
metadata description = 'Creates a storage account and a web app'

@description('The prefix to use for the storage account name.')
@minLength(3)
@maxLength(11)
param storagePrefix string

param storageSKU string = 'Standard_LRS'
param location string = resourceGroup().location

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: uniqueStorageName
  location: location
  sku: {
    name: storageSKU
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

module webModule './webApp.bicep' = {
  name: 'webDeploy'
  params: {
    skuName: 'S1'
    location: location
  }
}
これくらいならなんとなく分かりそうですね。けどこれは最低限の設定であり、GUIや2,3行で設定が終わるPowershellと比べると構文は複雑になります。
宣言型IaCのメリットはありますが、よほど繰り返し実施する作業じゃないと学習コストとメリットが合わない、という状態でした。

 AIコーディングエージェントの登場そこでAIコーディングエージェント。もうお分かりかと思いますが、AIコーディングエージェントにBicep構文を書いてもらえばこの問題は解決します。またDocs as codeでも触れましたが、既にデプロイ済みのAzureリソースをBicep構文としてエクスポートし、詳細設計書に落とすことも可能です。

 もはや宣言型IaCでなくてもよい?ただしスクリプトでの実行は柔軟性が高いものではありませんでした。例えば、どこかで設定ミスして作業を中断し、もう一度スクリプトを実行する場合、例えば作成済みのユーザーの再作成するなど、最初の方のコマンドを再実行することでエラーが発生する可能性があります。
解決策として、if文で「既に作成済みの場合はスキップする」などすればよいですが、コードの見通しが悪くなり、シンプルなはずのスクリプト設定がかえって複雑になってしまいました。
実はこの問題も、AIコーディングエージェントを使う事で解決します。AIコーディングエージェントに対して「冪等性(べきとうせい)を意識してPowerShellスクリプトを書いて」と依頼する事で、PowerShellスクリプトながらも冪等性(べきとうせい)をもつものが生成されます。
今まで、宣言型の仕組みを使わないと、IaCは実現できないと言われていました。Microsoft 365 DSCは宣言型ではありますが、使い込んでいるユーザーからはバグの多さも指摘され、本番運用には注意が必要、と言われていました。
しかしMicrosoft 365 DSCを使わなくてもAIコーディングエージェント × PowerShellで冪等性をもったIaCが実現できる時代になりました。

 IaC / 冪等性(べきとうせい)を持つことで実現されるメリットシステムインテグレーター視点で見ていきます

 1. 複数の環境・お客様に同一設定の構成をデプロイできるいろんな設定のお客様がいたとしても、テンプレート一発で同じ状態にできます。手順書をお客様毎に作成する必要がないので、作業の手間が低下します。

 2. 設定のバージョン管理が楽Excelパラシで設定管理するのではなく、コードで設定を管理できるので、Gitの仕組みを使って差分管理・バージョン管理ができます。

 3. 設定の流用が簡単1と2の合わせ技ですが、検証環境で実績がある設定をGitの仕組みを使って他チームに共有、追試をしてもらったり、OKだったら本番環境に適用したり、ができます。

 4. 作業品質の安定化・工数削減CUIでの設定なので、人のスキルによる設定ミスが発生せず、作業品質が安定します。なんなら有識者1人で100つの環境にデプロイするのも簡単なので、初心者によるミス、という概念自体が消滅します。

 さいごに1つの環境を設定するなら、ステップバイステップで設定できるGUIやPowershellの方が分かりやすくて理解が進みます。宣言型IaCは、一発で全ての要素を設定する必要があるので、全体像が分からないと使うのは大変です。
ただ、AIコーディングエージェントのおかげで複雑な定義ファイルも説明してくれたり、編集もしてくれたりで、構文を覚えなくてもIaCを使える時代が来たのかなと思います。
Infrastructure as Code(IaC)とは

スクリプト設定からIaCへ

宣言型IaCはちょっと難しい

AIコーディングエージェントの登場

もはや宣言型IaCでなくてもよい?

IaC / 冪等性(べきとうせい)を持つことで実現されるメリット

1. 複数の環境・お客様に同一設定の構成をデプロイできる

2. 設定のバージョン管理が楽

3. 設定の流用が簡単

4. 作業品質の安定化・工数削減

さいごに

Discussion
