自然言語でAWSを操作し、Terraformで守る運用の記録 番外編:システム構成解説

前回は、AWSへAIエージェントを接続し、自然言語で構築や運用を進められる環境について紹介しました。今回は番外編として、その裏側をシステム構成図で整理します。

AIエージェントがAWSを操作すると聞くと、「AIがAWSへ直接入り、自由にリソースを変更する」姿を想像するかもしれません。しかし、今回作った環境はそうではありません。中心にあるのはAIではなく、人間の認証と承認です。

AIエージェントは、決められた経路とルールの中で調査や作業を進めます。認証、コード、state、実際のAWSリソースを分離し、変更の直前には必ず人間が判断する構成にしました。

全体構成図

全体像を1枚にまとめると、次のようになります。

図は、左から右へ「人間の依頼」「AIエージェントによる作業」「承認ゲート」「AWS環境」という順番で読みます。GitHubはローカル環境の上、IAM Identity Centerは下に配置し、コードと認証の経路を分けています。S3 backendはAWS環境と同じ右側に置き、実環境とstateの保存先を並べました。

大切なのは、AIエージェントからAWSへ伸びる経路が一本ではないことです。読み取りやterraform planは調査経路として進められますが、実環境を変更する操作は承認ゲートで止まります。

接続先確認と一時認証で安全な入口を作る

自然言語の依頼は、いきなりAWS操作にはならない

人間はAIエージェントへ、「既存のリソースを確認して」「今月の利用状況を調べて」「この構成をTerraformで作るとどうなるか」と自然言語で依頼します。

AIエージェントは、その依頼をAWS CLIやTerraformの具体的な操作へ分解します。ただし、最初に行うのはリソース操作ではありません。まずaws sts get-caller-identityを実行し、接続先のAWSアカウントとロールが、設定された対象と一致するかを確認します。

この確認に失敗した場合は先へ進みません。正しいコマンドでも、違うアカウントで実行すれば事故になるからです。「何をするか」の前に「どこで、誰として実行するか」を確定させます。

認証はIAM Identity Center、人間がMFAを通す

AWSへの入口にはIAM Identity Centerを使います。AIエージェントの設定ファイルへ長期アクセスキーを保存するのではなく、人間がブラウザでサインインし、MFAを通した後の一時セッションをAWS CLIから利用します。

セッションが期限切れになれば、AIエージェントは再認証が必要だと知らせます。パスワードやMFAコードをAIへ渡す必要はありません。認証操作は人間が担当し、認証後の確認や定型作業をAIエージェントが引き継ぎます。

この境界によって、端末上に長期間有効な鍵を置かずに済みます。また、AIエージェントが人間の知らない時間に勝手に接続し続ける状態も避けられます。

GitHubはコード、S3はstateを保管する

Terraformに関係するデータは、役割に応じて保存先を分けました。

GitHubのPrivateリポジトリへ保存するのは、Terraformコード、手順書、検査設定、値を伏せたサンプルファイルです。変更履歴を残し、「誰が、どのような意図で構成を変えたか」を追えるようにします。

一方、TerraformのstateはS3へ保存します。stateにはAWSリソースの管理情報が含まれるため、GitHubには入れません。S3側では暗号化、バージョニング、公開アクセス遮断、ロックを使い、機密性と復旧性を確保します。

実値の変数ファイル、backend設定、保存済みplan、AWSの認証キャッシュもGitの対象外です。コードを共有する場所と、環境固有の情報を保管する場所を分けることが、構成全体の土台になっています。

一休みポイント:GitHubとS3の役割分担

❌ GitHubへ全部まとめて保存する
Terraform stateや実値設定まで履歴に入り、漏えい時の影響が大きくなる

✅ コードはGitHub、stateは保護したS3へ保存する
共有したい情報と、環境固有の管理情報を分離できる

保存先を分けることは少し手間に見えますが、その手間自体が安全境界になります。

承認ゲートが「勝手に変更しない」を支える

今回の構成で最も重要なのが、人間による承認ゲートです。

AIエージェントは、現状の読み取り、Terraformコードの作成、フォーマット、構文検査、セキュリティ検査、terraform planまでを進められます。その後、次の情報を人間へ報告します。

• 接続しているAWSアカウントとロール
• Terraformを実行した作業場所
• 作成、変更、削除されるリソース数
• 既存リソースへの影響
• 想定される費用への影響

人間が内容を確認し、対象と現在のplanに対して明示的に承認した場合だけ、確認済みのplanをapplyします。途中でplanが変わった場合や認証が切れた場合は、改めて確認します。

destroy、import、stateを直接変更する操作、ロックの強制解除は、さらに影響が大きい操作として扱います。これらも「以前に一度許可したから」という理由では実行せず、その時点の対象と内容に対する承認を必要とします。

既存AWSリソースは外部管理から始める

図の右側にあるAWSリソースには、Terraformで新しく作るものだけでなく、すでに存在しているRoute 53のホストゾーンなども含まれます。

既存リソースは、見つけた時点ではTerraform管理外として扱います。AIエージェントが参照できることと、変更してよいことは別です。Terraformへ取り込む場合は、対象を特定し、import後にどの差分が出るかを確認してから承認します。

この方針によって、AIエージェントが「構成をそろえる」という善意から、既存のDNSやデータを変更することを防ぎます。管理対象の境界を人間が決めることは、権限設定と同じくらい重要です。

障害や誤操作が起きたときの戻り道

統制は、変更を防ぐだけではありません。問題が起きたときに追跡し、戻せることも含みます。

Terraformコードの変更履歴はGitHubに残ります。S3のstateはバージョニングされます。実行前にはplanがあり、実行後にはAWSとstateを再確認できます。どの段階で想定とずれたのかを切り分けられる構成です。

ただし、stateの過去バージョンを人間の判断だけで直接戻す、といった危険な復旧は行いません。まず状況を読み取り、影響を整理し、正しい復旧手順を決めます。AIエージェントには調査と選択肢の整理を任せ、復旧操作そのものは通常の変更以上に慎重に承認します。

今回の教訓

AWSを自然言語で操作する仕組みは、AIエージェント単体で成り立っているわけではありません。IAM Identity Center、AWS CLI、Terraform、GitHub、S3という既存の仕組みを、AIエージェントが会話の中でつないでいます。

そして、その中心にあるのは人間です。人間が認証し、管理対象を決め、差分を読み、最後の変更を承認する。AIエージェントは、その判断に必要な情報を集め、作業を正確に進める役割を担います。

便利さと統制は、どちらか一方を選ぶものではありません。「鍵を置かない」「接続先を確認する」「planで止める」「既存資産を勝手に管理しない」という境界を構成に組み込めば、自然言語によるAWS運用は、安全性を保ちながら十分に実用化できます。

次のアクション

この構成を導入する場合は、最初にAIエージェントへ広い権限を与えるのではなく、読み取り操作から始めるのがおすすめです。接続先確認と監査の流れが安定したら、Terraformのコード作成とplanまで範囲を広げます。

そのうえで、変更操作には必ず人間の承認ゲートを置きます。AIエージェントに任せる範囲を段階的に広げることが、便利さを実感しながら安全な運用を続ける近道です。