はじめに

AIを活用したインフラ構築は開発効率を飛躍的に向上させますが、同時に「本当に設計通りにデプロイされたか？」という検証の重要性が増しています。特に予算制限やセキュリティ権限の設定ミスは致命的なリスクとなりますが、マネジメントコンソールでの目視確認は漏れが発生しやすく、非効率です。

本記事では、Firebase Studio (IDX) 上で former2 を使い、実環境からエクスポートした IaC と、設計書（Readme.md）を AI に突き合わせて自動監査させる「インフラ監査」の手法を紹介します。

前提：Readme.md は「聖典」である

この手法を成立させるための絶対条件は、Readme.md等に詳細かつ厳密な設計（仕様）が記載されていることです。AI に「監査」をさせるためには、比較対象となる「正解のスペック」が明確に定義されており、しかもMachine-readableでなければなりません。

予算閾値: 具体的な金額（例: 3.1 USD）と、監視が「実績値」か「予測値」かの指定
権限管理: 最小権限原則に基づいた IAM ポリシーの具体的な内容
リソース制限: Lambda の同時実行数やタイムアウト値などの制約条件

実装 → エクスポート → 監査

以下の 3 ステップにより、実装の整合性を物理的に証明します。

Implementation: AI または手動で AWS リソースを構築
Export (IaC): former2 CLI を使い、デプロイ済みのリソースを CloudFormation テンプレートとしてエクスポート
Audit: エクスポートされた IaC と Readme.md を AI に読み込ませ、齟齬を抽出させる

実践：former2 CLI による現物抽出

Firebase Studio (IDX) のターミナルで former2 を使い、現在の構成をコードとして書き出します。

# former2 CLI の実行（npx を使用して環境を汚さず実行）
npx former2 generate --output-cloudformation audit-pre-test.yaml

AI への監査依頼プロンプト（例）

エクスポートした audit-pre-test.yaml と Readme.md を AI に渡し、以下のプロンプトを実行して整合性を検証します。

# 任務：AWS 実装整合性監査

設計書（Readme.md）と、実環境からエクスポートされた IaC（audit-pre-test.yaml）を比較し、実装の正確性を検証せよ。

## 監査対象
1. **設計書**: `Readme.md`（期待される仕様）
2. **現物エビデンス**: `audit-pre-test.yaml`（実環境から抽出したコード）

## 監査項目
以下の観点で、設計と実装に齟齬がないか確認せよ。

### 1. 数値・設定の照合
- Budgets の `Amount` が設計通りか？
- アラート通知のトリガーが `ACTUAL`（実績）か `FORECASTED`（予測）か？
- Lambda の Runtime、Timeout、メモリ設定、同時実行制限が仕様通りか？

### 2. IAM 権限の検証
- 指定された IAM ポリシー（例: `ShutdownPolicy`）に `Effect: Deny` が正しく記述されているか？
- アクション（Actions）やリソース（Resources）の範囲が設計通りか？

### 3. リソース間の紐付け
- SNS トピックと Budgets/Lambda の接続が正しいか？
- EventBridge ルールのスケジュールやターゲットが一致しているか？

## 報告形式
- **[一致]**: 仕様と現物が完全に一致している項目。
- **[齟齬/警告]**: 差異がある項目。具体的な差異の内容を記述せよ。

おわりに

実環境から抽出した「嘘をつかないコード（IaC）」をエビデンスとして AI に提示し、それを設計書と照合させる。このプロセスにより、インフラ構築の信頼性は劇的に向上します。AI による自動構築の時代だからこそ、コードレベルでの厳密な「答え合わせ」を行う文化が不可欠です。