IaCへのAI活用が注目される背景には、IaCそのものの特徴がある。

　IaCはサーバやネットワーク、クラウドリソースの設定をコードとして記述する手法だ。アプリケーションコードと同様に、Gitによるバージョン管理やコードレビュー、自動テストを適用できる。

　生成AIはこうしたコードベースの作業を得意とする。特にTerraformやOpenTofu、Ansibleには定型的な記述が多く、変数定義やモジュール作成、テストコード生成などはAIが支援しやすい領域だ。

　実際、先進企業の多くはテスト生成やテンプレート作成、設定ファイルのひな型作成といった反復作業からAI活用を始めている。

　一方で、インフラ設計には性能要件や可用性要件、セキュリティポリシー、コスト最適化など企業固有の判断が含まれる。こうした領域では依然として人間の知識や経験が必要であり、AIだけでは対応できない。

事例1．TD Bank：「無制限の許可」は与えない

　カナダのTD Bankは、Ansible Automation PlatformとMicrosoft Copilotを活用し、全国1300支店のネットワーク再構築を自動化するプロジェクトを進めた。約1万3000行のコードを開発し、支店ごとのネットワーク再構築を90分で完了できる仕組みを構築したという。

　同行のエンジニアは、テストコード生成など反復的な作業でCopilotを利用した。ただし、AIを活用する前にコーディングスタイルや品質基準を統一したフレームワークを整備している。

　結果としてCopilotは有効な支援ツールになったが、システムの設計や判断ロジックは人間が管理したままだ。AIの貢献度は全体作業の約15％程度であり、常に人間の監督下に置かれていた。

　TD Bankの担当者は将来的な活用にも期待を示している。しかし、本番環境でAIに自由な権限を与える考えはない。AIは既存の自動化資産を活用するための「判断支援ツール」として利用するのが現実的だと考えている。

なぜ規制業界ほど慎重なのか

　金融機関や医療機器メーカーが慎重な理由は明確だ。

　アプリケーションコードの不具合であれば一部機能の停止で済む場合もある。しかしインフラコードの誤りは、システム全体の停止や情報漏えい、コンプライアンス違反につながる可能性がある。

　例えばクラウドストレージのアクセス権限設定を誤れば、機密データが外部に公開される恐れがある。ネットワーク設定のミスによって重要システムが停止するケースも考えられる。

　規制業界ではこうした事故が監督当局への報告や高額な制裁金につながる可能性があるため、「AIが作ったから正しい」という考え方は通用しない。

事例2．EYが導入したIBM Bobとガードレール

　監査法人であるEY（Ernst & Young Global）もAIエージェントの活用を進めている。

　同社のGlobal Tax Platformでは、IBMのAIコーディングアシスタント「IBM Bob」を利用し、アプリケーション開発・実行環境「.NET」のモダナイゼーションやTerraformを利用したIaC開発を支援している。

　EYは、Bobには一定の自律性を認めているものの、本番環境へのデプロイは別だ。AIが生成したコードは全てPull Requestを通じて人間がレビューする。

　さらにAWSなどのクラウド基盤側にもガードレールを設定し、リソースの過剰作成や予期せぬコスト増加を防いでいる。

　EYの事例が示しているのは、AI活用の成否を決めるのはモデル性能ではなくガバナンスだということだ。

事例3．医療機器業界のDevOpsチーム

　医療機器業界のDevOpsチームが公開した事例は、AI活用のリスクを象徴している。

　同チームは3カ月にわたり、Claude Codeを利用してOpenTofu用のコードを生成した。この結果、バグ検出や変数定義、出力ブロック生成などで成果を得たという。

　しかし同時に、存在しないインフラ変数をAIが作り出すケースが繰り返し発生した。しかも、それらは通常のバリデーションテストを通過する可能性があった。規制の厳しい業界では、こうした小さなミスが重大な障害やコンプライアンス違反につながりかねない。

　この経験から同チームは、全エンジニアに対し「AIがそう言ったから」ではなく、「AWSが実際にどう動作するのか」を説明できることを求めるように運用を変更したという。つまり、AI活用が進むほどインフラの仕組みを理解する人材の重要性は高まるということだ。

情シスが整備すべき3つのガードレール

　今回の事例から見えてくるのは、AI導入の前に運用ルールを整備する必要があるということだ。

1．AIが生成したコードを直接本番環境へ反映させないこと

　Pull Requestによるレビューと承認プロセスを欠かさない。

2．AIが利用できる権限を最小限に限定する

　ID・アクセス管理（IAM）でAIエージェントのロールやサービスアカウントを適切に制御すれば、誤ったコードが生成された場合でも被害を限定できる。

3．本番環境とは切り離したサンドボックス環境で事前検証すること

　ネットワークやセキュリティ関連の設定は特に慎重な検証が求められる。

事例4．フィンテック企業Vega

　フィンテック企業Vegaは、Spaceliftの「Intent」を利用してAWSのサンドボックス環境でIaCを試行している。

　同社が期待しているのは、AIがIaCそのものを置き換えることではない。自然言語でインフラを操作するための新しいインタフェースになることだ。

　Vegaの開発者はこれまで、TerraformやAnsibleの構文を理解しなければインフラを操作できなかった。しかし将来的には、「検証環境にRedisを追加して」「開発環境用のデータベースを作成して」といった指示だけで、背後のIaC基盤が処理する世界が実現する可能性がある。

　Red Hatの「Automation Orchestrator」も同様の方向性を示している。AIエージェントが既存の自動化ワークフローを呼び出し、人間の承認や監査証跡を維持したまま処理を実行する仕組みだ。

　つまり、多くの企業が目指しているのは「AIによる完全自律運用」ではない。AIをIaCの上位レイヤーとして活用し、自然言語による操作と既存の自動化基盤を結び付けることだ。

　情シス担当者にとって重要なのは、AIエージェントを導入することそのものではなく、その背後にあるIaCや自動化基盤をどこまで標準化できているかである。先進企業の事例は、「自動化の整備が先、AIは後」という原則が依然として有効であることを示している。