深夜2時、PagerDutyのアラート音で叩き起こされる。インフラ運用に関わるエンジニアであれば、一度は経験があるのではないでしょうか。原因はまたしても「構成のドリフト（Configuration Drift）」です。誰かがコンソールから直接セキュリティグループを変更したのか、あるいは古いTerraformコードが現状と乖離したのか。修正作業自体は数行のコード変更で済むかもしれません。しかし、その影響範囲の確認とテストには膨大な時間がかかります。
「AIを使えば自動化できる」
そんな声も聞こえてきますが、現場でインフラを預かるエンジニアにとって、それは魅力的な提案であると同時に、不安も感じます。「もしAIが間違った判断をして、本番DBを削除してしまったら？」「生成されたコードがブラックボックス化して、誰もメンテナンスできなくなったら？」
インフラ領域において「完全自動運転」を目指して成功した例は多くありません。逆に、AIを「人間の判断を補助するツール」として割り切って使っているチームは、着実に成果を上げています。
今回は、長年の開発現場で培った知見をもとに、「AIに本番環境を壊させない」ことを大前提とした、現実的で安全なドリフト修正の自動化アプローチを解説します。まずは動く仕組みを作り、安全に検証を重ねていく実践的な手法論です。
なぜ「AIによる自動修正」は現場で敬遠されるのか
多くのAIベンダーは「自律型エージェントがインフラを管理する未来」を語りますが、現場のSRE（Site Reliability Engineer）が抱く感情は、期待よりも「懸念」が勝るのが現実ではないでしょうか。
「勝手に書き換えられる」心理的ハードル
インフラエンジニアにとって、IaC（Infrastructure as Code）のリポジトリは重要な場所です。そこにあるコードは、システムの「あるべき姿」を定義したものでなければなりません。
ここに、確率論で動作するLLM（大規模言語モデル）が介入し、コードを書き換えて terraform apply まで実行してしまうとしたらどうでしょう？ それは管理不能な状態です。AI特有の「ハルシネーション（もっともらしい嘘）」がインフラ設定に紛れ込んだ場合、その発見は困難を極め、障害発生時のデバッグは悪夢と化します。
効率化よりも安全性が優先されるインフラ運用の現実
アプリケーションコードであれば、バグがあっても次のデプロイで修正できるかもしれません。しかし、インフラの変更は不可逆的な結果を招くことが多い。ステートフルなリソースの再作成や、ネットワーク設定の誤りによる全断など、リスクが大きいです。
だからこそ、実務の現場では「AIによる完全自動化」を最初から目指すべきではありません。ビジネスへの最短距離を描く上で目指すべきは、AIを「実行者」ではなく「優秀な提案者」として位置づけ、最終的な決定権（Apply権限）を人間が握り続けるワークフローです。
これから紹介する5つのTipsは、この「人間中心のAI活用」を実現するための具体的な方法です。ぜひ、皆さんの現場にどう適用できるか想像しながら読み進めてみてください。
Tip 1：最初は「Apply権限」を剥奪して提案だけさせる
インフラストラクチャ管理にAIエージェントやボットを導入する際、システム思考に基づくリスク管理の第一歩は、権限設定の観点から「AIが致命的な事故を起こせない仕組み」を構築することです。最初に取り組むべき重要なステップは、「書き込み権限の制限（Apply権限の剥奪）」です。
Read-Only権限でのAI接続
AIツールがクラウドプロバイダー（AWS、Azure、Google Cloudなど）や、IaCの状態管理ファイル（Terraform Stateなど）にアクセスする際、その権限は厳格な Read-Only （読み取り専用）に制限することが不可欠です。AIに求められる役割は「インフラの現状がどうなっているか（Driftの検知）」を正確に把握することであり、環境に対して直接的な変更を加える権限は必要ありません。
近年のクラウドセキュリティの動向、例えばAWS Security Hubにおけるクラウドアクティビティ監視の強化や、IAMによる厳密なアクセス制御のベストプラクティスを見ても、最小権限の原則はますます重要視されています。具体的には、AIが実行できる範囲を terraform plan などの影響を及ぼさないコマンドに限定します。このコマンドから出力された「差分情報」だけをAIに入力として渡し、「インフラの現状とIaCコードの間にこれだけの乖離がある」という事実データのみを安全に提供する設計にします。
Pull Request作成までをAIの担当範囲にする
直接の変更権限を持たないAIに対する最適なアウトプットの設計は、「修正パッチを含むプルリクエスト（PR）の作成」をゴールとすることです。具体的なプロセスは以下のようになります。
- 既存のCI/CDパイプラインや監視ツールを活用して、インフラのドリフトを検知する。
terraform planの実行結果をAIに渡す。- AI（構造化出力に対応した最新の推論モデルなど）が、差分を正確に埋めるためのHCLコード（Terraformコード）を生成する。
- AIが自動的にGitブランチを作成し、コードをコミットした上でPRを提出する。
プロセスはここで意図的に停止させます。「マージボタンを押して変更をインフラに適用する」という最終的な意思決定は、必ず人間のエンジニアが行うように設計します。
このアプローチにより、AIは「勝手にインフラ構成を変更してしまう不確実な存在」から、「高精度なコーディングを代行し、レビュー依頼を出してくれる優秀なアシスタント」へと役割を変えます。コードレビューの工数は発生しますが、ゼロから修正パッチを記述する手間からは完全に解放されます。人間の判断を介在させることで心理的安全性を確保しつつ、運用効率を飛躍的に高めることが可能です。
Tip 2：AIに「なぜその修正が必要か」を解説させる
コードが自動生成されたとして、次に困るのがレビューです。機械が書いたコードは、時に人間には理解しがたいロジックになっていることがあります。「動くけど、なぜこう書いたのかわからない」コードをマージするのはリスクです。
修正コードだけでなく「意図」を出力させる
プロンプトエンジニアリングの工夫として、単に「修正コードを生成せよ」と指示するのではなく、「以下のフォーマットでプルリクエストの概要（Description）を作成せよ」と指示を追加しましょう。
- 検知されたドリフト: 何が変わっていたのか（例：S3バケットの公開設定が手動で変更されていた）。
- 修正の意図: このコードを適用することでどうなるのか（例：公開設定をブロックし、IaCの定義通りに戻す）。
- リスク評価: 副作用の可能性。
ドリフト原因の推測とセットで提案を受ける
さらに一歩進んで、AIに「なぜドリフトが起きたのか」を推測させるのも有効です。CloudTrailなどのログと突き合わせることができればベストですが、コードの差分だけでも「これは手動での緊急対応の跡に見える」といった洞察が得られることがあります。
AIが「この変更は、セキュリティグループに特定のIPを追加するための緊急措置のようです。IaC側に取り込みますか？ それとも元に戻しますか？」と提案してくれるようになれば、レビューワーの認知的負荷は大幅に下がります。説明責任をAIに持たせることで、ブラックボックス化を防ぐのです。
Tip 3：開発環境・非重要リソース限定で「お試し適用」する
「PR作成まで」の運用に慣れてくると、少しずつ自動化の範囲を広げたくなるものです。しかし、いきなり本番環境（Production）で試すのは無謀と言わざるを得ません。まずは安全な領域でプロトタイプを動かし、段階的に信頼を構築していくアプローチが不可欠です。
タグベースでの対象リソース絞り込み
AIが触れるリソースを明確に区別しましょう。例えば、Terraformのリソースタグに ai-managed: true や env: sandbox といったメタデータを付与します。
AI側のスクリプトやプロンプトで、「このタグが付いているリソース以外のドリフトは無視する（あるいは通知のみにする）」というルールを徹底させます。これにより、基幹データベースやコアネットワークといったクリティカルなリソースが、AIの誤判断によって操作されるリスクを遮断できます。
Sandbox環境での成功実績を作る
まずは開発者個人のSandbox環境や、夜間に停止しても問題ない検証環境で、AIによる「自動Apply」をテストしてみるのも有効な手段です（もちろん、バックアップは必須です）。
経営層やチームメンバーを説得するには、理論よりも「実際にどう動くか」を示す実績データが最も強力です。信頼は言葉ではなく、実績の積み重ねでしか得られません。リスクのない場所でAIに「練習」をさせ、その挙動を人間が観察・評価する期間を設けましょう。
Tip 4：AIに「既存コードの作法」を学習させる
AIが生成するコードが、チームのコーディング規約を無視したスタイルだと、どれほど正確に動くものであってもマージへの心理的ハードルが上がります。例えば、変数の命名規則が違う、モジュールの使い方が独特、インデントが崩れているといった些細な違いです。これらは確実に「技術的負債」として蓄積され、将来的なインフラのメンテナンスを困難にします。
リポジトリ内の命名規則やモジュール構造の参照
AIに期待通りのコードを書かせるためには、LLMにコンテキストとして「既存のコードベースの一部」を渡すことが不可欠です。
現在、RAG（Retrieval-Augmented Generation）技術は急速に進化しており、評価フレームワークのRagasや、構造をより深く理解するGraphRAGといった高度な手法が次々と登場しています。しかし、日々のインフラ運用におけるパッチ生成のようなタスクにおいて、必ずしもメンテナンスコストのかかる複雑なRAGパイプラインを構築する必要はありません。
OpenAIのAPI環境では、GPT-4oやGPT-4.1といったレガシーモデルが段階的に廃止され、より高度な文脈理解と推論能力を持つ新たな標準モデルへと移行が進んでいます。この技術的な移行に伴い、一度に処理できる情報量（コンテキストウィンドウ）が大幅に拡大しただけでなく、プロンプトの指示に対する正確な追従性や、複雑なリポジトリ構造の理解力も飛躍的に向上しました。
そのため、大掛かりな検索システムを介さずとも、プロンプトのSystem Messageに直接「チームの作法」や「主要な定義ファイル」を注入するシンプルなアプローチが、現在最も手軽かつ確実な手段となっています。具体的には、以下のような明確な指示を含めることで、生成されるコードの品質は劇的に向上します。
- 「リソース名には必ず指定のプレフィックスを使用する」
- 「セキュリティグループの定義には、標準モジュールを再利用すること」
- 「変数定義はハードコードせず
variables.tfに分離すること」
「動くコード」より「読みやすいコード」を優先
AIに対しては、単に「最短で動くコード」を求めるのではなく、「可読性が高く、既存のスタイルに完全に合致したコード」を生成するよう明示的に指示してください。
ここでの実践的なポイントは、自動化プロセスの中に静的解析ツール（Lint）を組み込むことです。例えば、TerraformであればTFLintなどを活用し、Lintエラーが出たコードはAIに自動でフィードバックして再生成させるループを作ります。
最新世代のAIモデルは、エラーログを的確に読み解いて根本原因を修正する能力に極めて長けています。人間のエンジニアがレビューで指摘する前に、機械的なスタイル違反や明白な構文エラーをAI自身に排除させる仕組みを整えることが重要です。人間が読んで違和感のない、チームの作法に則ったコードであれば、それがAIによって自動生成されたパッチであっても、チームは抵抗なく安全にインフラへ適用することができます。
Tip 5：万が一のための「ロールバック手順」も同時に生成させる
どれだけ注意深くレビューしても、問題が起きる可能性はゼロにはなりません。インフラエンジニアが最も恐れるのは「壊れたこと」そのものよりも、「元に戻せないこと」です。
修正適用後の切り戻しプランの提示
AIにパッチコードを生成させる際、同時に「その変更を打ち消すための逆パッチ」や「ロールバック手順書」も生成させましょう。
例えば、セキュリティグループのルールを変更するPRであれば、PRのコメント欄に以下のような記述を自動生成させます。
ロールバック手順:
もしこの変更によって通信障害が発生した場合、以下のコマンドを実行して直前のStateに復帰してください。terraform apply -var-file=rollback.tfvars
または、以下のバックアップ用ブランチbackup/sg-20231027をデプロイしてください。
リスク評価の自動化
「元に戻すボタン」が用意されているという安心感は、意思決定のスピードを劇的に早めます。人間は「もし失敗しても、戻せる」と分かっていれば、AIの提案をより前向きに採用できるようになります。
リスク管理とは、リスクをゼロにすることではなく、リスクが発生した際の影響をコントロール可能な範囲に収めることです。AIにその「コントロール手段」まで用意させるのが、賢い使い手のアプローチです。
まとめ：AIは「勝手に直すロボット」ではなく「頼れる副操縦士」
インフラドリフトの修正におけるAI活用は、決して「全自動化」か「手動」かの二者択一ではありません。その間には、「AIが提案し、人間が承認する」という、安全かつ効率的な方法が存在します。
- 権限を分離し、AIにはPR作成までを任せる。
- 説明責任を求め、修正の意図を言語化させる。
- スコープを限定し、安全な場所から信頼を積み上げる。
- コンテキストを注入し、チームの作法を守らせる。
- ロールバック手順を用意させ、心理的安全性を担保する。
これらのステップを踏むことで、現場のエンジニアは「AIに仕事を奪われる」ことも、「AIに本番環境を壊される」こともなく、単調な修正作業から解放されます。そして、よりクリエイティブなアーキテクチャ設計や、ビジネス価値を生み出す改善業務に集中できるようになるはずです。
制御権（コントロール）は常に人間の手に残しつつ、AIという強力な副操縦士（Co-pilot）と共に、より堅牢で柔軟なインフラ運用を目指していきましょう。技術の本質を見抜き、まずは今日、開発環境の小さなドリフト修正から、AIに「提案」させるプロトタイプを動かしてみてはいかがでしょうか。皆さんの現場での挑戦を応援しています。
コメント