導入
シリコンバレーの風が少し冷たく感じる季節になりましたね。
現地のスタートアップ界隈でも、「ChatGPTやAmazon Q Developerにインフラコードを書かせてみた」という話題で持ちきりです。S3バケットやLambda関数のようなステートレスなリソースを定義する際、AIアシスタントは驚くほどのスピードで定型コードを生成し、チームの生産性を飛躍的に高めてくれます。
しかし、データベース（DB）となると話は別です。
SREチームをリードする立場からシステム全体を俯瞰すると、CloudFormationテンプレートの構文が完璧でリンターのエラーがない場合でも、本番環境に適用すると稼働中のAmazon RDSインスタンスが「置換（Replacement）」され、データが消失するリスクが潜んでいることがわかります。
「AIは文脈を無視する」という前提に立ち、クラウドインフラ、特にDBという「状態を持つ（ステートフル）」リソースを扱う必要があります。
この記事では、AIが生成したCloudFormationコードをDBインフラに適用する際に潜む「見えないリスク」を、スタートアップのスピード感とSREの信頼性担保の両立という視点から解説していきます。AIを「魔法の杖」ではなく「優秀だが注意が必要なツール」として扱い、適切なガードレールを設けることが重要です。
これから紹介するリスク分析と監査手法が、大切なデータを守る一助となれば幸いです。
なぜDBインフラのAI自動生成は「Webアプリ生成」より危険なのか
AIによるコード生成技術は飛躍的に進化しており、最新のモデルでは複雑な推論や文脈理解が可能になっています。しかし、インフラ構築においては、「対象となるリソースの性質」によってリスクの重みが劇的に異なることを深く理解しておく必要があります。
Webアプリケーションのフロントエンドコードや、サーバーレスなLambda関数をAIに生成させる場合、最悪のケースでも「バグで動かない」程度で済むことが多いでしょう。修正してデプロイし直せば解決します。これらは本質的に「ステートレス（状態を持たない）」なため、壊して作り直すコストは比較的低いと言えます。
しかし、データベースは全く異なる領域です。
ステートレスとステートフル：AIにおけるミスの許容度の違い
データベースは「ステートフル（状態を持つ）」なリソースの代表格です。そこにはビジネスの核となる顧客データやトランザクション履歴が蓄積されています。インフラのコード（IaC）におけるわずかな設定ミスが、データの消失（ロスト）や長時間のダウンタイム、あるいは復旧不可能なデータの破損（コラプション）を引き起こす可能性があります。
AIは確率論に基づいてコードを生成します。AIにとって、DeletionProtection: true（削除保護あり）と DeletionProtection: false（削除保護なし）は、単なるトークンの選択確率の違いに過ぎません。しかし、データに基づいて意思決定を行い、システムの信頼性を守るSREの視点では、この true か false かが、致命的な運用事故を防げるかどうかの決定的な分水嶺になります。
CloudFormationの宣言的記述とAIの確率的生成の相性
AWS CloudFormationは「宣言的」なツールです。「どうやって作るか（How）」ではなく、「最終的にどうあるべきか（What）」を記述します。記述された内容はAWSによって厳密に解釈され、実行されます。
AIは文脈を補完するのが得意ですが、インフラ構築においてはその「気遣い」や「省略」が致命傷になることがあります。例えば、AIが学習データに含まれる古いベストプラクティスを参照し、現在のセキュリティ基準では許容されない設定（デフォルトVPCへの配置やパブリックアクセスの許可など）を提示してくるケースは珍しくありません。再現性とスケーラビリティを重視するアーキテクチャ設計において、こうした古い設定の混入は潜在的なボトルネックとなります。
「動けばOK」が通用しないインフラ領域の特殊性
アプリケーション開発では、テスト環境で動作すれば一旦の合格点が出ることが多いでしょう。しかし、DBインフラにおいては「動くこと」と「安全に運用できること」の間には大きな隔たりがあります。
AIが生成したテンプレートで STACK_CREATE_COMPLETE（スタック作成完了）が表示されたとしても、それは成功を意味しません。バックアップ設定が不十分だったり、メンテナンスウィンドウが考慮されていなかったりすれば、それはシステム内に「時限爆弾」を埋め込んだのと同じです。AIは、運用フェーズの長期的な要件を考慮したコード生成を依然として苦手としています。
AI生成CloudFormationテンプレートに潜む5つのリスク
AIアシスタント（ChatGPTの最新モデルやAmazon Qなど）は高度な推論能力を獲得しつつありますが、生成されるCloudFormationテンプレートには依然として特有の危険が潜んでいます。プロンプトの書き方次第で発生する代表的なリスクパターンを解説します。
1. デフォルト設定の落とし穴（DeletionProtection等の欠落）
AIはしばしば「最小構成」のコードを生成する傾向があります。プロンプトで明示的に指示しない限り、重要なオプション設定は省略されがちです。
Amazon RDSにおいて最も危険な省略の一つが DeletionProtection（削除保護）プロパティです。CloudFormationの仕様上、デフォルトでは false（無効）になっています。もしこの設定が false のまま本番環境にデプロイされ、操作ミスでスタック削除コマンドが実行されると、RDSインスタンスは即座に削除されてしまいます。
また、MultiAZ（マルチAZ配置）の設定も、開発環境向けのサンプルコードを学習している影響か、デフォルトで false（シングルAZ）になっているケースが多く報告されています。本番環境での可用性要件を満たさない構成が提案されるリスクを常に警戒する必要があります。
2. 認証情報のハードコーディングとSecrets Manager連携の不備
これは重大なセキュリティリスクです。AIに「RDSを作成するテンプレートを書いて」と依頼すると、以下のようなコードを出力することがあります。
MasterUsername: admin
MasterUserPassword: password1234 # セキュリティ上の重大な欠陥
これは学習データの中に、簡易的なチュートリアルや古いブログ記事が含まれているためです。本番環境では、AWS Secrets Managerと連携し、パスワードをテンプレートに直書きしない動的な参照（Dynamic Reference）を使用する必要がありますが、AIが自発的にそのセキュアな構成を提案してくることは稀です。
3. セキュリティグループの過剰な開放（0.0.0.0/0の提案）
接続性を確保しようとするあまり、AIはセキュリティグループのインバウンドルールを過剰に開放する傾向があります。
「EC2から接続できるようにして」という指示に対して、特定のSecurity Group IDをソースとして指定するのではなく、0.0.0.0/0（全開放）を設定したり、VPC内の全CIDRを許可したりするコードを生成することがあります。これはデータベースを不要な攻撃リスクに晒すことになります。
4. バックアップ・メンテナンスウィンドウの考慮漏れ
運用フェーズに入ってから問題化するポイントとして、以下の項目があります。
BackupRetentionPeriod: バックアップの保持期間。デフォルト値（多くの場合1日や7日）がビジネス要件を満たしているか。PreferredBackupWindow: バックアップ取得時間帯。トラフィックのピーク時に設定されていないか。PreferredMaintenanceWindow: メンテナンス時間帯。
AIはこれらの「時間」や「期間」に関するビジネス固有の要件を知り得ないため、デフォルト値のままコードを生成します。結果として、予期せぬ時間にパッチ適用による再起動が発生したり、必要な過去データが復元できなかったりするトラブルを招く可能性があります。
5. リソース置換（Replacement）を誘発するプロパティ変更
これはインフラエンジニアにとって最も警戒すべき挙動です。CloudFormationには、あるプロパティを変更すると、リソースを「更新（Update）」するのではなく、「削除して再作成（Replacement）」する挙動をとるものが存在します。
例えば、RDSの DBName プロパティ（初期データベース名）などは、スタック作成後に変更しようとすると置換が発生します。また、パラメータグループやオプショングループの変更も、設定によっては再起動や予期せぬダウンタイムを伴います。
AIに「設定を少し変えて」と依頼して生成されたコードが、実はこの「置換」トリガーを引く変更を含んでいる可能性があります。AIはCloudFormationの Update behavior（更新挙動）のドキュメントを厳密に考慮してコードを書いているわけではありません。
リスク発生確率と影響度評価マトリクス
すべてのAI生成コードが危険なわけではありません。リスクの所在を特定し、適切なレビューを行うために、以下のようなマトリクスを用いてリスク評価を行うことを推奨します。
ハルシネーションによるパラメータ捏造の頻度分析
AIは時として、存在しないパラメータやインスタンスタイプを生成（ハルシネーション）します。最新のモデルでは精度が向上していますが、依然として以下のような間違いが発生します。
- 高頻度:
db.t4g.microのような、実際にはRDSでサポートされていない（あるいは特定のエンジンバージョンでのみサポートされる）インスタンスクラスの指定。 - 中頻度: 存在しないCloudFormationプロパティの記述（Terraformのパラメータと混同しているケースなど）。
これらはデプロイ時にバリデーションエラーになるため、実害は少ないですが、手戻りの原因になります。
開発環境vs本番環境：環境別リスク許容度
スタートアップのようにスピードが求められる現場では、環境に応じたメリハリのある運用が不可欠です。
開発環境 (Dev):
- データ損失：許容（再作成可能）
- ダウンタイム：許容
- セキュリティ：最低限の制限は必要だが、緩和可能
- AI活用方針: 積極的に活用し、試行錯誤のサイクルを回してスピードを上げる。
本番環境 (Prod):
- データ損失：許容不可（致命的）
- ダウンタイム：計画外は許容不可
- セキュリティ：厳格な制限が必須
- AI活用方針: 生成コードはあくまで「参考（ドラフト）」とし、人間が厳格に監査する。
復旧難易度によるリスクの重み付け
リスクを評価する際は、「もしそれが起きたら、どれくらいで復旧できるか」を基準にします。
- レベル低（設定変更のみ）: パラメータグループの微修正など。再デプロイで直るもの。
- レベル中（ダウンタイム発生）: 再起動が必要な変更。メンテナンスウィンドウ内での作業が必要なもの。
- レベル高（データロスト・置換）: インスタンスの削除・再作成。スナップショットからのリストアが必要になり、長時間のビジネス停止を招くもの。
AIが生成したコードの中に、「レベル高」を引き起こす変更が含まれていないかを確認することが、SREの最重要責務です。
人間が担うべき「AIコード監査」のチェックリスト
属人化を排除し、チーム全体で安全性を担保するための具体的な監査ワークフローとチェックリストを紹介します。
ChangeSet（変更セット）の確認とAIへの再質問
CloudFormationの ChangeSet（変更セット）機能は、実際にスタックを更新する前に、何がどう変わるかをプレビューする不可欠な機能です。
チェック手順:
- AIコードでChangeSetを作成する。
- AWSマネジメントコンソールまたはCLIでChangeSetの詳細を確認する。
Replacementカラムを必ず確認する。ここにTrueと表示されているリソースがあれば、それは「削除・再作成」されます。RDSに対してTrueが出ていたら、作業を直ちに中断してください。- 不明点があれば、AIに再度質問します。「この変更を行うと、RDSインスタンスは置換されますか？公式ドキュメントに基づいて回答して」と問いかけることで、AI自身にリスクを再評価させることも有効です。
静的解析ツール（cfn-lint, cfn_nag）とのハイブリッド監査
目視だけに頼るレビューは属人化を招き、見落としのリスクを高めます。AIが生成したコードは、専用のチェックツールで機械的に検証し、自動化を積極的に導入しましょう。
- cfn-lint: CloudFormationの構文チェックツール。AIが生成したプロパティの誤りや、無効な値を検出してくれます。
- cfn_nag: セキュリティに特化したチェックツール。パスワードの平文保存や、ワイルドカード（*）の使用などを警告してくれます。
AWS Configなどのサービスでも対応リソースが拡大しており、継続的なコンプライアンス監視が可能になっていますが、まずはデプロイ前の「静的解析」でAIコードの品質を担保することが先決です。
ドリフト検出と手動修正の禁止ルール
AI活用を阻害する最大の要因は、「人間による手動変更」です。
緊急対応などで、コンソールから直接RDSの設定を変更してしまうと、CloudFormationのテンプレートと実環境の間に乖離（ドリフト）が生じます。この状態でAIが生成した（ドリフトを知らない）テンプレートを適用すると、意図せず設定が巻き戻ったり、予期せぬエラーが発生したりします。
AIをIaCワークフローに組み込むなら、「手動変更は厳禁（Read-Only）」というルールをチーム全体で徹底し、常にコードベースが正しい状態（Single Source of Truth）を保つ必要があります。これにより、再現可能なインフラ管理が実現します。
結論：AIは「ドラフト作成者」として扱う
AIによるDBインフラ構築のリスクを分析してきました。結論は「AIを使うな」ではありません。「AIの役割を正しく定義せよ」です。
AI活用の境界線：ボイラープレート作成はAI、パラメータ設計は人間
AIは、0から1を生み出す「ドラフト（草案）作成」において強力なパートナーとなります。数百行のYAMLファイルの骨組みを数秒で作ってくれます。しかし、パラメータ設定——どのインスタンスタイプを使うか、バックアップは何日保持するか、誰にアクセスを許可するか——は、ビジネス責任を持つ人間が決定する必要があります。
「AIが書いたから大丈夫だろう」という思考停止こそが最大のリスクです。AIはタイピングを代行してくれたに過ぎず、設計責任は人間にあります。
心理的安全性を確保する段階的導入ステップ
いきなり本番DBをAIコードで管理するのではなく、以下のようなステップで、チームの習熟度と信頼を積み上げていくことをお勧めします。
- 開発環境のDB: 壊れても良い環境で、AIコードの挙動や癖を掴む。
- 本番環境のRead Replica（参照用）: データロストのリスクがないリソースでIaC管理を試す。
- 本番環境のMaster: 十分な検証と、ChangeSetによる監査フローが確立されてから適用する。
チームで合意すべき「AI利用ガイドライン」の骨子
チームで共有すべきガイドラインの要素を挙げます。
- 原則: AI生成コードは「信頼できないソース」からのコードと同等に扱う。
- 必須アクション: 本番適用前には必ず
cfn-lintを通し、ChangeSetのReplacement項目をダブルチェックする。 - 禁止事項: 認証情報（シークレット）を含むコードをAIチャット画面に入力しない、生成させない。
- 情報確認: AWSの機能やベストプラクティスは頻繁に更新されるため、AIの知識だけでなく必ず公式ドキュメントで最新仕様を確認する。
AIは強力なエンジンですが、システム全体を俯瞰し、ハンドルを握り、ブレーキを踏むのはSREの仕事です。この技術を正しく理解し、適切なガードレールを設けることで、より創造的で価値のあるアーキテクチャ設計に集中できるようになるはずです。
コメント