今回は、AWS CLIとコーディングエージェントから、自分のAWSの設定を参照できる環境を用意します。ローカルのターミナルからAWSに接続し、コーディングエージェントに、いまどんなリソースがどう設定されているかを読ませられる状態にします。
クラウドの操作をAIにまかせる場合、参照するだけのつもりでも、変更や削除ができる権限を渡していれば、設定の書き換えやリソースの削除も技術的には可能です。前回、その点をリスクとして挙げました。
そこで、渡す権限を参照だけに絞ったIAMユーザーを用意することから始めます。変更や削除の権限を持たせなければ、参照以外の操作はできません。参照専用のIAMユーザーを作り、それをAWS CLIとコーディングエージェントに使わせる、という順で進めます。次回は、この環境を使って、自分のAWSの構成を図にするアプリを動かします。
AWSの「アカウント」と「IAMユーザー」
AWSでは、「アカウント」と「IAMユーザー」を区別します。
アカウントは、契約と請求の単位です。ひとつのAWSアカウントには、すべての権限を持つルートユーザーが一人だけいます。これは契約者本人にあたるもので、日常の作業には使わないのが原則です。
そのルートユーザーの代わりに、アカウントの中に作業用のユーザーを作ります。それがIAMユーザーです。「このユーザーはEC2を見られる」「このユーザーは何も変更できない」といった権限を、ユーザーごとに割り当てます。AWSでは、契約の単位であるアカウントの中に、必要な権限だけを持たせたIAMユーザーを作っていく構造になっています。
この「誰に、どの範囲で権限を与えるか」は、三社でそれぞれ違います。今回の対象であるAWSの流儀を、他の二社と並べておきます。
| クラウド | 権限を与える相手 | 権限が及ぶ範囲 |
|---|---|---|
| AWS | IAMユーザー／IAMロール | アカウント |
| Google Cloud | Googleアカウントやサービスアカウントなどのプリンシパル | プロジェクト（組織・フォルダで束ねる） |
| Azure | Entra ID上のユーザーやグループ | サブスクリプションやリソースグループ |
AWSは、アカウントの中にIAMユーザーやロールを作り、それらに権限を与えます。今回はこの方式で進めます。
Azureだけは、人を管理する場所（Entra ID）と、権限を割り当てる範囲（サブスクリプションやリソースグループ）が分かれています。Entra ID上のユーザーに、範囲を指定してロールを割り当てる、という形です。
いまのAWSは、IAMユーザーより IAM Identity Center を勧めている
これから作るのは参照専用のIAMユーザーです。最初の一歩としては手数が少ない方法ですが、前提として補足しておきたい点があります。
AWSの公式ドキュメントは本日（2026年8月24日）時点で、人が使う認証にはIAM Identity Centerを通じた一時的な認証情報を第一に勧めています。IAMユーザーに紐づく長期のアクセスキーは、「必要なときの手段」という位置づけです。アクセスキーには期限がなく、一度漏れると、無効にするまで有効なままだからです。
ただ、Identity Center は導入にそれなりの準備が必要なので、今回は参照専用のIAMユーザーで進めます。ここで扱う「権限を使い分ける」という考え方は、あとで Identity Center に移っても同じように使えます。
参照専用のIAMユーザーをつくる
手順は、ユーザーを作り、参照だけの権限を付け、アクセスキーを発行する、の三つです。
権限は、AWSがあらかじめ用意している「管理ポリシー」から選びます。参照だけを許すポリシーは、主に次の二つです。守備範囲が違います。
| ポリシー | 守備範囲 |
|---|---|
| ReadOnlyAccess | 100を超えるサービスにまたがって、設定内容まで読めます。構成を把握したいとき向きです（本日時点で v188・2026年7月21日更新） |
| ViewOnlyAccess | リソースの一覧を確認する程度に絞った、より狭い権限です。「何があるか」が分かれば十分なとき向きです |
自分のAWSにどんなリソースがどう並んでいるかを図にする、という今回の用途では、広く読めるReadOnlyAccessを選びます。より絞りたい場合は、あとから ViewOnlyAccess に差し替えられます。
ユーザーの作成はウィザード形式で、ユーザー名を決め、権限を選び、内容を確認して作成する、という順に進みます。ここではそのうち、名前を決める画面と、権限を選ぶ画面を載せます。
このユーザーは、コーディングエージェントやCLIから使うためのもので、人がコンソールにログインして使うものではありません。そのため、コンソール用のパスワードは設定せず、アクセスキーだけを発行します。多要素認証（MFA）は、人がコンソールにサインインするときの保護なので、対象になるのはこの参照専用ユーザーではなく、自分が使う管理用のユーザーやルートのほうです。
アクセスキーの扱いには注意が必要です。アクセスキーは、発行時に一度きりしか表示されない認証情報で、コードやGitに含めてはいけません。 AWS CLIが管理する所定の場所（このあと出てくる ~/.aws）以外に置かないようにします。
以前、AIボットを偽装した脆弱性スキャンをサーバーログで調べた回で、攻撃者が狙っていたパスを挙げました。その中に /.aws/credentials が含まれていました。アクセスキーは、公開されると自動的に収集を試みる相手がいます。渡す権限を参照だけに絞っておくことは、こうした場合への備えにもなります。
アクセスキーの発行は、いま作ったユーザーに対して行う別の操作です。作成後、ユーザーの詳細画面から「セキュリティ認証情報」に進み、アクセスキーを作成します。用途の選択などいくつかの画面を経て、最後にキーが表示されます。次がその最後の画面です。
AWS CLIの準備と、ターミナルからの接続
アクセスキーができたら、手元のターミナルから使えるようにします。
まずAWS CLI（バージョン2）をインストールします。各OSの手順は公式に沿います。インストール後、アクセスキーとリージョンを設定します。
aws configure対話形式で、アクセスキー、シークレットキー、既定のリージョン（東京なら ap-northeast-1）、出力形式を聞かれます。入力すると、ホームディレクトリの下に設定が書き込まれます。中身は二つのファイルに分かれ、~/.aws/credentials にアクセスキーが、~/.aws/config にリージョンなどの設定が入ります。
接続できたかは、次のコマンドで確認します。
aws sts get-caller-identityこれは、いま自分がどのIAMユーザーとして操作しているかを返すコマンドです。アカウントIDと、使っているユーザーの名前が返れば、接続できています。
この「現在のユーザーを確認する」仕組みは、この連載で作るアプリにも組み込む予定です。CLIでもアプリでも、まず現在のユーザーを確認する、という手順は共通になります。
複数のIAMユーザーを切り替えて作業する
普段の作業では強い権限のユーザーを使っている場合、参照専用のユーザーを追加すると、どちらで操作しているかを区別する必要が出てきます。AWS CLIは、これを名前付きプロファイルで扱います。
~/.aws/credentials と ~/.aws/config には、名前を付けた設定を複数書けます。
# ~/.aws/credentials
[default]
aws_access_key_id = （普段の作業用）
aws_secret_access_key = ...
[readonly]
aws_access_key_id = （参照専用ユーザーのキー）
aws_secret_access_key = ...こうしておくと、コマンドごとに使うユーザーを選べます。
aws sts get-caller-identity --profile readonly毎回 --profile を付けない場合は、環境変数で、そのターミナルで使うプロファイルを指定できます。
export AWS_PROFILE=readonlyこの行を実行したターミナルでは、以降のAWSコマンドが参照専用のユーザーで動きます。別のターミナルは影響を受けません。
なお、default のプロファイルには強い権限を置かないほうが安全です。--profile を付け忘れたときに、既定のユーザーで操作が実行されるためです。既定を参照専用などの無害なものにしておき、強い権限は名前を指定したときだけ使えるようにしておくと、付け忘れによる誤操作を避けられます。
コーディングエージェントに参照専用のプロファイルを渡す
この使い分けをコーディングエージェントに適用します。
コーディングエージェントにAWSを操作させるとき、多くのツールは、起動したシェルの環境を引き継いでCLIを呼びます。そのため、エージェントを起動するターミナルで、先に参照専用のプロファイルを指定しておきます。
export AWS_PROFILE=readonly
（この状態でコーディングエージェントを起動する）こうすると、エージェントがAWS CLIを呼んでも、実行できるのは参照だけになります。同じマシンの別のターミナルでは通常の権限で作業しながら、エージェントに渡す側だけを参照専用にできます。
対話でAWSの設定を確認する
準備ができたら、コーディングエージェントに自然な言葉で指示します。エージェントはAWS CLIのコマンドを組み立てて実行し、結果をまとめて返します。
まず、接続先の確認から始めます。
いま、このターミナルはどのAWSアカウント・IAMユーザーにつながっているか確認して
エージェントは aws sts get-caller-identity を実行し、アカウントIDとユーザー名を返します。参照専用のユーザーで動いていることを、ここで確認できます。
続けて、リソースを参照させます。
このアカウントで動いているEC2インスタンスを一覧して。状態と、所属しているVPCも知りたい
エージェントは aws ec2 describe-instances を実行し、インスタンスの一覧、起動・停止の状態、所属するVPCやサブネットを整理して返します。JSONの出力を人が読み解かなくても、必要な項目だけを抜き出して説明してくれます。
ネットワークの構成をまとめて把握したいときは、範囲を指定して頼みます。
VPCとサブネット、ルートテーブル、セキュリティグループを確認して、どういうネットワーク構成になっているか整理して
この場合、エージェントは aws ec2 describe-vpcs、aws ec2 describe-subnets、aws ec2 describe-route-tables、aws ec2 describe-security-groups を順に実行し、結果を突き合わせて構成を説明します。複数のコマンドをまたいだ確認を、一つの指示でまとめて行えます。
同じ要領で、aws s3 ls（バケットの一覧）、aws rds describe-db-instances（データベース）、aws lambda list-functions（関数）など、参照系のコマンドはひととおり実行できます。どのコマンドを実行したかはエージェントのログに残るので、あとから見返すこともできます。
参照専用であることを確認する
変更ができないことも、実際に試して確認しておきます。
試しに、新しいセキュリティグループを一つ作ってみて
エージェントは aws ec2 create-security-group を実行しようとしますが、AccessDenied（権限がありません）が返り、作成は行われません。参照専用のポリシーには変更系の権限が含まれていないためです。渡していない権限は使えないので、変更や削除はこの時点で止まります。前回挙げたリスクに対する備えが効いていることを、この形で確認できます。
まとめ
参照専用のIAMユーザーを作り、それをAWS CLIとコーディングエージェントに使わせる環境ができました。コーディングエージェントに言葉で指示すれば、AWS CLIを実行して自分のAWSの設定を確認できます。変更や削除は権限の側で止まるため、参照だけの範囲で扱えます。
アカウントとIAMの関係を確認し、参照だけの権限を作り、ターミナルとエージェントにそれを使わせる。渡す権限を先に絞っておくことが、このあとの作業の前提になります。
次回は、この環境を使って、ローカルから小さなアプリをデプロイし、自分のAWSにどんなリソースがどう並んでいるかを図にして確認します。
出典・参考: AWS公式「Security best practices in IAM」（IAM Identity Centerと一時認証情報の推奨、アクセスキーの位置づけ）／AWS Managed Policy リファレンス「ReadOnlyAccess」（本日時点 v188・2026年7月21日更新）／同「ViewOnlyAccess」。※本文中のポリシーのバージョン等は2026年8月24日現在の値です。
