自然言語でAWSを操作し、Terraformで守る運用の記録

AWSの構築や運用は、マネジメントコンソールとTerraformを使えば十分に行えます。それでもAIエージェントを加えてみると、これまでとは違う感覚がありました。「今月の料金を調べてください」と自然な言葉で頼むだけで、接続先を確認し、AWSから必要な情報を取得し、分かりやすく整理して返してくれるのです。

これは単にコマンド入力が楽になった、という話ではありません。調査、設計、コード作成、検証、実行という一連の作業を、会話しながら進められるようになったことに驚きました。

一方で、AWSは会社やサービスの基盤です。便利だからといって、AIエージェントに無制限の権限を渡し、判断まで丸投げするわけにはいきません。重要なのは「安全に接続すること」と「勝手に変更させないこと」です。

この記事では、AWS、Terraform、AIエージェントを組み合わせるまでに行った準備と、実際に運用して分かった統制の勘所を紹介します。

なぜAWS運用にAIエージェントを加えたのか

私は普段、AWSのマネジメントコンソールやTerraformを使ってインフラを構築・運用しています。画面で現在の状態を確認し、Terraformで構成をコード化し、planで差分を見てから反映する。この流れは、再現性と変更履歴を守るうえで非常に重要です。

ただ、実際の仕事はTerraformを書くことだけではありません。

• 既存環境に何があるかを調べる
• 公式ドキュメントを確認する
• 作業手順やWBSを作る
• 変更前後の差分を確認する
• エラーの原因を調査する
• 実施結果を記録する

こうした周辺作業には、かなりの時間がかかります。そこで期待したのがAIエージェントでした。人間が目的と制約を伝え、AIエージェントが調査や作業案を組み立て、必要な操作を実行する。うまく役割分担できれば、Terraformの良さを残したまま、運用全体をもっと滑らかにできると考えました。

最初に作ったのはAWSリソースではなく「作業のルール」だった

いきなりAIエージェントをAWSへ接続したわけではありません。最初に作ったのは、環境構築のWBSと設定手順書です。

何を準備するのか、どこまでをAIエージェントに任せるのか、どの操作で人間の承認を必要とするのか。これらを先に文書化しました。AIエージェント自身に計画と手順の下書きを作らせ、人間が確認しながら進めたのです。

この順番は大切でした。自然言語による操作は簡単に見えますが、その裏ではAWS CLIやTerraformが動きます。会話が柔らかくなっても、実行される操作の重みは変わりません。だからこそ、入口で統制を決めておく必要があります。

今回、特に重視したルールは次の通りです。

• AWSへの接続には一時認証を使い、長期アクセスキーを保存しない
• 操作前に、対象のAWSアカウントとロールを必ず確認する
• 既存リソースは、確認できるまで「外部管理」として扱う
• Terraformの変更は、静的検査とplanを通してから判断する
• apply、destroy、importなどの変更操作は、人間の明示承認なしに実行しない
• Terraformのstateや実値設定、認証情報をGitへ保存しない

AIに何をさせるかより先に、何を勝手にさせないかを決める。これが今回の環境づくりの出発点でした。

IAM Identity Centerで「鍵を置かない」接続を作る

AWSへの認証には、IAM Identity Centerを使いました。専用のユーザーを作成し、パスワード設定とMFA登録を行い、グループ、許可セット、対象アカウントへの割り当てを順番に設定しました。

AIエージェントが使うAWS CLIも、IAM Identity Centerのプロファイルを利用します。ブラウザでサインインし、短時間だけ有効な認証情報を取得する方式です。アクセスキーやシークレットキーを設定ファイルへ書き込む必要はありません。

実際の接続では、最初から完璧に進んだわけではありません。しばらく時間が空いた後に料金を確認しようとしたところ、セッションの期限切れで接続に失敗しました。そこでAIエージェントがサインイン画面を開き、パスワードとMFAの入力は私自身が行いました。認証後に作業を再開できました。

この「認証は人間、認証後の定型作業はAI」という分担は、とても自然でした。AIエージェントにパスワードやMFAコードを渡す必要はありません。

一休みポイント:AIエージェントをAWSへ接続する方法

❌ 長期アクセスキーをAIや設定ファイルへ渡す
漏えい時の影響が大きく、失効や棚卸しも人任せになりやすい

✅ IAM Identity Centerの一時認証を使う
サインインとMFAは人間が行い、期限付きセッションで作業する

「AIがいつでも入れる環境」ではなく、「人間が許可したセッションでAIが働ける環境」にしました。

TerraformとS3で、変更内容と状態を管理する

AWSリソースの管理にはTerraformを使い、コードはGitで履歴管理する構成にしました。一方、TerraformのstateはGitへ入れず、暗号化、バージョニング、公開アクセス遮断を設定したS3へ保存します。ロックも利用し、同時実行によるstate破損を防ぎます。

ここで重要なのは、GitHubとS3の役割を混ぜないことです。

• GitHubにはTerraformコード、手順書、サンプル設定を保存する
• S3にはTerraformのstateを保存する
• 実値の変数ファイル、backend設定、planファイル、認証情報はGitHubへ送らない

GitHubへ初回登録する際には、コミット候補のファイルを洗い出し、stateや実値設定が除外されていることを確認しました。認証情報らしい文字列が含まれていないかもスキャンし、問題がないことを確認してからPrivateリポジトリへ送信しました。

AIエージェントが便利なのは、こうした地味な確認を一連の流れとして実行できる点です。ただし、除外ルール自体を人間が理解していなければ、誤った設定をそのまま高速化するだけになります。自動化の前に、守るべき境界を決める必要があります。

「勝手に変更しない」を仕組みにする

既存のRoute 53を「ないもの」として扱わない

新しいTerraform環境を作るときに怖いのは、すでに存在するAWSリソースへの影響です。今回のアカウントには、既存のRoute 53ホストゾーンがありました。

Terraformのコードに書かれていないからといって、既存リソースが直ちに削除されるわけではありません。しかし、AIエージェントが「理想の構成へ揃えよう」と考え、既存資産まで勝手に管理対象へ入れてしまえば危険です。

そこで、既存リソースは最初から外部管理として扱い、参照と変更を分けました。Terraform管理へ取り込む場合も、いきなりimportするのではなく、対象、影響、取り込み後の差分を確認してから人間が承認するルールにしています。

この考え方は、AIエージェントと既存環境をつなぐうえで特に重要です。新規環境なら作り直せるものもありますが、DNSやデータを持つリソースはそうはいきません。「見えているから触ってよい」ではなく、「管理対象として承認されたから触ってよい」という境界が必要です。

変更前に必ず止まる流れを作る

AIエージェントへ「変更しないで」とお願いするだけでは、運用統制として十分ではありません。そこで、変更までの流れを段階に分けました。

自然言語で依頼
    ↓
接続先アカウントとロールを確認
    ↓
現状調査・コード作成
    ↓
フォーマット、構文、セキュリティ検査
    ↓
Terraform planで差分確認
    ↓
アカウント、ロール、作業場所、変更件数、費用影響を報告
    ↓
人間が明示承認
    ↓
確認済みのplanだけをapply

この中でAIエージェントが自律的に進めてよいのは、基本的に読み取り、調査、コード作成、検査、planまでです。実環境を変える操作は、対象と差分を示したうえで止まり、人間の承認を待ちます。

特に、destroy、import、stateを直接変更する操作、ロックの強制解除は、通常のapply以上に慎重に扱います。これらは単なるコマンドではなく、管理境界や復旧可能性を変える操作だからです。

一休みポイント:AIエージェントにTerraformを任せる範囲

❌ 「いい感じに作って、そのまま反映して」
対象アカウント、既存資産、削除件数、費用影響が曖昧なまま進む

✅ 「調査とplanまで。差分を報告し、apply前に止まって」
人間が変更内容を確認し、実行の可否を判断できる

AIエージェントの価値は、確認を省略することではありません。確認に必要な材料を、早く正確にそろえることにあります。

自然言語でAWSを操作できた瞬間

環境が整った後、AIエージェントに「AWS環境に接続して、今月の利用料金を調べてください」と頼んでみました。

AIエージェントは、まずIAM Identity Centerのセッションを確認しました。期限切れだったため、私がブラウザで再認証します。その後、AIエージェントはAWSのアカウントとロールが想定通りであることを確認し、Cost Explorerから月初から当日までの料金とサービス別内訳を取得しました。

返ってきたのは、月初から当日までの暫定料金と、サービス別の内訳を整理した簡潔な報告でした。Cost Explorerの情報には反映遅延があり、確定請求ではないという注意も添えられていました。具体的な金額やアカウント固有の情報は、外部へ公開しない前提で扱っています。

自分で行うなら、AWSへログインし、請求画面を開き、対象期間を確認し、内訳を読み取る作業です。CLIを使う場合も、コマンドと期間指定を考える必要があります。それが会話だけで完了した瞬間、「AWSを操作するインターフェースが変わった」と感じました。

もちろん、裏側ではAWS CLIとAPIが動いています。魔法ではありません。それでも、目的を自然言語で伝え、AIエージェントが安全確認を挟みながら結果まで持ってくる体験には、これまでの自動化とは違う感動がありました。

AIエージェントは管理者ではなく、統制された作業者

今回の経験から、AIエージェントを「何でも任せられる管理者」と考えるのは危険だと感じました。むしろ、明確な作業規則のもとで働く、非常に速い作業者と考える方がしっくりきます。

目的、権限、禁止事項、確認方法、承認条件を人間が決める。その範囲でAIエージェントは、調査やコード作成、検査、定型操作を驚くほど速く進めてくれます。

マネジメントコンソールやTerraformが不要になるわけでもありません。AIエージェントは、その上に自然言語の操作層を追加します。AWSの仕組みを理解している人ほど、どこを任せ、どこで止めるべきかを判断できるため、効果を引き出しやすいと感じました。

今回の教訓

AWSをAIエージェントから操作する環境は、十分に実用的でした。自然言語で目的を伝え、調査から結果確認まで進められる体験は、従来のコンソール操作やスクリプト実行とは明らかに違います。

ただし、その便利さを支えるのは、IAM Identity Centerによる一時認証、Terraformによる差分管理、S3によるstate保護、Gitによる変更履歴、そして実行前の人間承認です。AIエージェントに自由を与えるのではなく、安全に働けるレールを敷くことが重要でした。

「セキュリティ」と「勝手に変更しない」。この二つを先に設計すれば、AIエージェントはAWS運用を置き換える存在ではなく、これまでの経験と仕組みを大きく拡張してくれる相棒になります。

次のアクション

次は、日常的な読み取り作業やTerraformの小さな変更から、AIエージェントとの分担を増やしていきます。便利さだけでなく、どこで人間の判断が必要になるのかも、実際の運用を通して記録していくつもりです。

自分の環境に当てはめるときの確認項目

• AWSへの接続に、長期アクセスキーを使わず、一時認証を使っているか。
• 操作の前に、対象のアカウントとロールを確認する決まりがあるか。
• 既存のリソースを、確認できるまで「外部管理」として扱っているか。
• apply、destroy、import などの変更操作を、人間の明示承認なしに実行させない仕組みになっているか。
• stateや実値の設定、認証情報を、Gitへ保存しない仕組みになっているか。

これらは、この記事で決めたルールを、確認の形に直したものです。環境によって、当てはまらない項目もあります。

もしAIエージェントをAWSへ接続するなら、最初の一歩は権限を増やすことではありません。まず「何を確認し、どの操作で必ず止めるか」を決めるところから始めてみてください。この環境の全体構成は、番外編の構成図でも整理しています。

参考資料

この記事で触れた仕組みを、公式の資料で確認した範囲です(確認日 2026年11月1日)。

• AWS CLI:IAM Identity Center認証の設定:aws configure sso と aws sso login の手順。サインイン後、キャッシュされた認証情報が使われ、期限が切れたら再ログインが必要になる、と説明されています。
• AWS Cost Explorer の概要:データは少なくとも24時間に1回更新されるが、上流のデータにより、遅れて更新されるものもある、と説明されています。
• Terraform:S3バックエンド:stateをS3に保存する設定。暗号化、バージョニング(強く推奨)、ロック(任意)の説明があります。なお、この資料では、ロックの方法のうち、DynamoDBによるロックは、非推奨とされています。