【AIエージェント×AWS 設定編】ベストプラクティスに基づいた認証・権限設定

2026年7月28日AI,AWS,Claude,Claude Code,IAM

はじめに

こんにちは。SMS2部の中村です。普段は、AWS を中心にインフラ領域のお仕事をしています。

突然ですが、AWS でインフラを構築するとき、こんな経験はありませんか？

  • 公式ドキュメント通りにやったはずなのに、なぜかうまくいかない
  • エラーが起きているが、どう問題を切り分けていけばよいかわからず、解決に多大な時間がかかってしまう
  • 見ず知らずの AWS サービスを組み合わせ、ベストプラクティスに沿った構成を考えるのに膨大な時間がかかる

今回の記事では、上記のような悩みを解消するために、「ローカルのAI エージェントに ReadOnly 権限で AWS 環境を見てもらう」構成の設定方法を紹介します。これにより、AI エージェントに「構成の相談 → 手順の提示 → 実施 → エラー時の原因調査」を一気通貫で支援してもらうことができ、AWSの構築や検証を大幅に効率化できます。

この記事は「【AI エージェント×AWS】AI エージェントに ReadOnly 権限を与える設定方法と活用事例」シリーズの設定編です。

記事内容
設定編（本記事）ベストプラクティスに基づいた認証・権限設定
実践編構築手順の提示からトラブルシューティングまでの一貫支援

本記事である設定編のゴールは、ローカルのAI エージェントが ReadOnly 権限で AWS 環境を安全に参照できる状態を構築することです。AWS のベストプラクティス、Claude のベストプラクティスに沿った設定方法を紹介します。

なお、AI領域は技術トレンドの変化が速く、ベストプラクティスも継続的にアップデートされています。実装にあたっては、必ず最新の公式情報をご確認ください。例えば、将来的には MCPサーバーの利用がベストプラクティスになる可能性もあります。

この記事の読み方

本記事は、以下の流れで読み進めることで、AI エージェントをAWS環境に接続する設計の考え方から、実際の設定まで一通り実施できます。

  • AI エージェント×AWSの目的と権限の設計方針
    　AI エージェントとAWS環境を統合する目的と、ReadOnly権限を付与する理由を理解する
  • 全体構成と方式の選び方
    　AI エージェントに権限を与える方式を2つから選ぶ
  • AWS 側の設定
    　前章で選んだ方式の節を実装する
  • AI エージェント側の設定
    　AI エージェント側の設定を行う

AI エージェント×AWS の目的と権限の設計方針

AI エージェント×AWS の目的

「AI エージェント×AWS」とは、具体的には「AI エージェントに AWS 環境を参照させ、実環境のリソース情報を踏まえて質問に回答できるようにする」というものです。これにより、AWS 業務の各フェーズを次のように一気通貫で支援してもらえます。

フェーズAI エージェントの役割
要件定義AWS 環境の現状を踏まえて、ベストプラクティスに沿った構成案を提示する
構築既存リソースを考慮した構築手順を出力する
テスト設定値が設計書と相違ないか確認する
インシデント発生時AWS 環境を横断して状態を確認し、原因を調査する

汎用的なドキュメントから推測する場合と比べ、実際にAWS環境を参照できるようになることで、回答の具体性と精度が大きく変わります。結果として、調査時間の短縮、構成品質の向上、トラブルシューティングの迅速化につながります。

なぜ管理者権限ではなく ReadOnly 権限を渡すのか

私がAI エージェントにAWSを触らせる構成を考えたとき、最初に悩んだのが「どんな権限を与えるか」でした。
正直、最初は「AIに全部やらせれば楽では？」と思っていました。しかし、以下の理由から、AIに変更権限を与えることはリスクが高いと判断しました。

リスク内容
不可逆な変更・削除の実行AWS には EC2 インスタンスやS3バケットの削除など不可逆な操作があり、
AIが誤ってこれらを実行する可能性を排除できない。
プロンプトインジェクション悪意あるコード・ドキュメント・外部データを読み込んだ際、
埋め込まれた指示によって意図しない AWS 操作が実行される可能性がある。
管理者権限を付与していた場合、そのリスクは甚大。
最小権限の原則への違反使用しないであろう AWS サービスの特権を付与することは、
AWS のセキュリティのベストプラクティスである「最小権限の原則」に反する。

また、本記事のスコープ（構成相談・トラブルシューティング支援）では、ReadOnly 権限で十分です。

構成の相談やトラブルシューティングをサポートしてもらうには、環境を「見てもらう」だけで対応できます。さらに、作業内容を強制的にダブルチェックすることになりAIの間違いに気づきやすくなります。

一方で、ReadOnly 権限にもリスクがあることをご認識ください。顧客データや機密情報にアクセスが可能な状態となるためです。例えば、S3 オブジェクトの中身、DynamoDB のアイテム、SSM Parameter Store の値など、機密データそのものを読むことができてしまいます。

全体構成と方式の選び方

全体構成図

AI エージェントにAWS環境へのアクセス権限を与える方法は2つあります。「IAM Identity Center 方式」と「AssumeRole 方式」です。

各方式の仕組みは以下の通りです。

「IAM Identity Center方式」と「AssumeRole方式」 の仕組み
「IAM Identity Center方式」と「AssumeRole 方式」の仕組み

各方式について比較します。

比較項目IAM Identity Center 方式AssumeRole 方式
前提条件AWS Organizations の有効化
IAM Identity Center の有効化		なし
認証の仕組みブラウザでの本人確認と
MFA によって認証する		ローカルに保存された長期認証情報と
MFA によって認証する
長期認証情報の保存なし（一時認証情報をキャッシュ）あり（アクセスキーを平文保存）
AWSベストプラクティス準拠非準拠（キーをローカルに平文保存するため）
推奨度推奨非推奨（IAM Identity Center方式への移行を推奨）

どちらの方式を選ぶか

AWS Organizations が有効、かつ IAM Identity Center の組織インスタンスが有効な環境であれば、IAM Identity Center 方式が推奨です。

一方で、個人・小規模環境などで Organizations を使っていない場合は、AssumeRole 方式を採用してください。ただし、AssumeRole 方式ではアクセスキー（長期認証情報）を平文で保存するため、AWSのベストプラクティスには沿いません。可能であればAWS OrganizationとIAM Identity Centerを有効化し、IAM Identity Center 方式を採用することを推奨します。

AWS側の設定

前章で選んだ方式の節を進めてください
▶ IAM Identity Center 方式
▶ AssumeRole 方式

IAM Identity Center 方式（推奨）

ブラウザSSOで一時認証情報を取得する方式を設定します。

前提条件

この章を進める前に以下が整っていることを確認してください。

  • AWS環境にてAWS Organizations が有効化済み
  • AWS環境にてIAM Identity Center（組織インスタンス）が有効化済み
    • 本記事で使用する「許可セット」と「AWS アカウントへのアクセス割り当て」は、アカウントインスタンスではサポートされず、組織インスタンスのみがサポートするため、必ず組織インスタンスを有効化してください。
    • 組織インスタンスの利用には AWS Organizations の有効化が前提です
  • 手元のPCに AWS CLI v2 がインストール済み

設定方法

以下の手順で設定します。

　① [AWS コンソール] IAM Identity Center ユーザーの作成
　② [AWS コンソール] 許可セット の作成
　③ [AWS コンソール] ユーザー・グループへの割り当て
　④ [AWS コンソール] MFA の設定
　⑤ [手元のPC] AWS CLI プロファイルの設定

① [AWS コンソール] IAM Identity Center ユーザーの作成

AI エージェント 専用の IAM Identity Center ユーザーを作成します。普段の作業用 ID と分けることで、AI エージェント には ReadOnly 以外の権限が決して渡らない状態を作ることができ、CloudTrail 上でも操作主体がAI エージェントかそうでないか判別可能です。

  1. IAM Identity Center コンソールを開き、左メニューの [ユーザー] をクリック
  2. [ユーザーを追加] をクリック
  3. ユーザー名とメールアドレスを入力し、[次へ] をクリック
  4. [ユーザーをグループに追加] はスキップし [次へ] をクリック
  5. [ユーザーの確認と追加] にて内容を確認し、[ユーザーを追加] をクリック
IAM Identity Center ユーザーの作成画面
IAM Identity Center ユーザーの作成画面

② [AWS コンソール] 許可セット の作成

IAM Identity Center コンソールで ReadOnly 権限の許可セットを作成します。許可セットとは、IAM Identity Center でユーザーに付与する権限のテンプレートです。

  1. IAM Identity Center コンソールを開き、左メニューの [許可セット] をクリック
  2. [許可セットを作成] を選択
  3. [事前定義された許可セット] → [ReadOnlyAccess] を選択
許可セットの作成画面
許可セットの作成画面
  1. セッション有効期間を設定
  2. 許可セットの名前を設定し、作成を完了
許可セットの確認画面
許可セットの確認画面
Tips: なぜAWS管理ポリシーの ReadOnlyAccess を選ぶのか

ReadOnlyAccess はAWSが提供する管理ポリシー（ジョブ機能）で、ほぼ全サービスの Read/List/Get 権限を含む広範なポリシーです。AI エージェントの調査範囲は状況に応じて広がるため、必要なアクションを事前に網羅しきるのが難しく、本記事では ReadOnlyAccess を採用しています。

一方で、ReadOnlyAccess は多数のサービスへのアクセスを許可するため、本番環境など取得情報に制限をかけたい場面では過剰になりがちです。権限を絞りたい場合は、ViewOnlyAccess への移行や、ec2:Describe*、elasticloadbalancing:Describe* のように対象サービスを絞ったカスタムポリシーへの移行を検討してください。

③ [AWS コンソール] ユーザー・グループへの割り当て

  1. IAM Identity Center 左メニューの [AWS アカウント] を開く
  2. 対象アカウントを選択し、[ユーザーとグループの割り当て] をクリック
  3. 割り当てるユーザーと、先ほど作成した許可セットを選択して完了
許可セットのユーザーへの割り当て画面
許可セットのユーザーへの割り当て画面

④ [AWS コンソール] MFA の設定

IAM Identity Center コンソールで MFA を有効化します。

  1. 左メニューの [設定] → [認証] タブを開く
  2. [多要素認証] の [設定] をクリック
  3. 以下の設定を推奨します
設定項目推奨値
MFA のプロンプトをユーザーに表示 『 サインインごと（常時オン） 』を選択
ユーザーはこれらの MFA タイプで認証できます 『 Authenticator アプリケーション 』にチェック
（フィッシング対策の観点から、WebAuthn / Passkey の併用が推奨ですが、
　今回は Authenticator アプリを使用しています）
登録された MFA デバイスをユーザーが持っていない場合 『 サインイン時に MFA デバイスを登録するよう要求する 』を選択
MFA デバイスを管理できるユーザー『ユーザーは自分の MFA デバイスを追加および管理できる』を有効
MFA設定画面
MFA設定画面
  1. 入力したメールアドレスにパスワード設定 URL が記載されたメールが届くので、任意のパスワードを設定

⑤ [手元のPC] AWS CLIプロファイルの設定

PowerShellにて、aws configure sso コマンドでインタラクティブにプロファイルを設定します。

> aws configure sso

コマンドを実行すると、以下の入力を求められます。[SSO start URL] には、Iam Identity Center の [設定] ＞ [アイデンティティソース] タブの [IPv4] に表示されているURLを入力します。

SSO session name (Recommended): <任意のSSOセッション名>
SSO start URL [None]: https://xxxx.awsapps.com/start
SSO region [None]: ap-northeast-1
SSO registration scopes [sso:account:access]: sso:account:access

ブラウザが起動し、SSO ログインが完了すると、認証アプリの設定に進みます。正しく設定できると、PowerShellに SSO ログイン中のアカウントとロールが表示されます。

The only AWS account available to you is: <アカウントID>
Using the account ID <アカウントID>
The only role available to you is: ReadOnlyAccess-ClaudeCode
Using the role name "ReadOnlyAccess-ClaudeCode"
CLI default client Region [None]: ap-northeast-1
CLI default output format [None]: json
CLI profile name [ReadOnlyAccess-ClaudeCode-<アカウントID>]: claude-readonly
aws configure sso コマンドの実行画面
aws configure sso コマンドの実行画面

設定完了後、~/.aws/config（Windows の場合は %USERPROFILE%\.aws\config）に以下が追加されます。

[profile claude-readonly]
sso_session = <任意のSSOセッション名>
sso_account_id = <アカウントID>
sso_role_name = ReadOnlyAccess-ClaudeCode
region = ap-northeast-1
output = json

[sso-session <任意のSSOセッション名>]
sso_start_url = https://xxxx.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

動作確認

PowerShellにて、設定したプロファイルで AWS にアクセスできることを確認します。

① SSO ログインができることの確認

> aws sso login --profile claude-readonly

ブラウザが起動し、SSO ログインが完了すると以下のように表示されます。

Attempting to automatically open the SSO authorization page in your default browser. If the browser does not open or you wish to use a different device to authorize this request, open the following URL:
https://device.sso.ap-northeast-1.amazonaws.com/
Then enter the code:
XXXX-XXXX
Successfully logged into Start URL: https://xxxx.awsapps.com/start

② 認証情報の確認

> aws sts get-caller-identity --profile claude-readonly
json{
    "UserId": "AROAXXXXXXXXXXXXXXXXX:<ユーザー名>",
    "Account": "<アカウントID>",
    "Arn": "arn:aws:sts::<アカウントID>:assumed-role/AWSReservedSSO_ReadOnlyAccess-ClaudeCode_xxxxxxxxxxxx/<ユーザー名>"
}

③ ReadOnly アクセスの確認

> aws ec2 describe-instances --profile claude-readonly --query "Reservations[*].Instances[*].[InstanceId,State.Name]" --output table
----------------------------------
|       DescribeInstances        |
+----------------------+---------+
|  i-0123456789abcdef0 | running |
+----------------------+---------+

④ 書き込み操作が拒否されることの確認
※ –dry-runオプションを付けてはいますが、実行には十分注意し、
　 リスクが大きい環境では検証用インスタンスを作成してください。

> aws ec2 terminate-instances --dry-run --instance-ids i-0123456789abcdef0 --profile claude-readonly
An error occurred (UnauthorizedOperation) when calling the TerminateInstances operation: You are not authorized to perform this operation.（以下略）
動作確認のターミナル画面
動作確認のターミナル画面
確認
terminate-instances が UnauthorizedOperation で弾かれることを確認できました。ReadOnly権限が正しく機能しています。

ここまで動作確認できたら AWS 側の設定は完了です。AI エージェント側の設定に進んでください。

▶ AI エージェント側の設定へ

AssumeRole 方式

IAM Identity Center が使えない環境向けに、AssumeRole で一時認証情報を取得する方式を設定します。個人アカウントや小規模環境では、こちらが現実的な選択肢です。

ただし、繰り返しになりますが、AssumeRole 方式ではアクセスキー（長期認証情報）を平文で保存するため、AWS のベストプラクティスには沿いません。可能であれば、IAM Identity Center 方式を採用することを推奨します。

この方式の概要と使い分け

IAM Identity Center が使えない場合の次善策です。IAM ユーザーのアクセスキーを起点に、STS（Security Token Service: AWS の一時認証情報を発行するサービス）を経由して一時認証情報を取得します。「アクセスキーの保存が必要」という点は変わりませんが、API へのアクセスは一時認証情報を経由するため、アクセスキー漏えい時の被害を大幅に低減できます。

前提条件

この章を進める前に以下が整っていることを確認してください。

  • AWS CLI v2 がインストール済み

設定方法

以下の手順で設定します。
① [AWS コンソール] IAM ロールの作成
② [AWS コンソール] IAM ユーザーの作成
③ [AWS コンソール] アクセスキーの発行
④ [AWS コンソール] MFA デバイスの設定
⑤ [手元のPC] AWS CLI プロファイルの設定

① [AWSコンソール] IAMロールの作成

AI エージェント用の ReadOnly ロール claude-readonly-role を作成します。

  1. IAM コンソール → [ロール] → [ロールを作成] を選択
  2. [カスタム信頼ポリシー] を選択し、以下の信頼ポリシーを貼り付ける
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<アカウントID>:user/claude-code-user"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}
ポイント
aws:MultiFactorAuthPresent 条件により、MFAなしのAssumeRoleは拒否されます。
  1. 権限ポリシーに ReadOnlyAccess（AWS管理ポリシー・ジョブ機能）をアタッチ
  2. ロール名を claude-readonly-role に設定
Tips: なぜAWS管理ポリシーの ReadOnlyAccess を選ぶのか

ReadOnlyAccess はAWSが提供する管理ポリシー（ジョブ機能）で、ほぼ全サービスの Read/List/Get 権限を含む広範なポリシーです。AI エージェントの調査範囲は状況に応じて広がるため、必要なアクションを事前に網羅しきるのが難しく、本記事では ReadOnlyAccess を採用しています。

一方で、ReadOnlyAccess は多数のサービスへのアクセスを許可するため、本番環境など取得情報に制限をかけたい場面では過剰になりがちです。権限を絞りたい場合は、ViewOnlyAccess への移行や、ec2:Describe*、elasticloadbalancing:Describe* のように対象サービスを絞ったカスタムポリシーへの移行を検討してください。

② [AWS コンソール] IAMユーザーの作成

claude-code-user を作成し、必要最低限の権限のみ付与します。

  1. IAM コンソール → [ユーザー] → [ユーザーを作成] を選択
  2. ユーザー名を claude-code-user に設定
  3. コンソールアクセスは不要（プログラムによるアクセスのみ）
  4. 権限はインラインポリシーで付与するため、この時点ではスキップ
  5. IAM ポリシー（インラインポリシー）の作成
    • ユーザーに付与する権限は sts:AssumeRole のみです。ReadOnly 権限はロール側に持たせます。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<アカウントID>:role/claude-readonly-role"
        }
    ]
}

③ [AWS コンソール] アクセスキーの発行

  1. 作成したユーザーの [セキュリティ認証情報] タブを開く
  2. [アクセスキーを作成] → ユースケース：[コマンドラインインターフェース (CLI)] を選択
  3. アクセスキーIDとシークレットアクセスキーを安全な場所に保存
注意
アクセスキーはこの画面でしか確認できません。必ず保存してください。

④ [AWS コンソール] MFAデバイスの設定

  1. ユーザーの [セキュリティ認証情報] タブ → [MFAデバイスを割り当てる]
  2. デバイスタイプ：[認証アプリケーション] を選択
  3. 認証アプリ（Google AuthenticatorやAuthyなど）でQRコードをスキャンし、TOTP（Time-based One-Time Password: 時刻をベースにしたワンタイムパスワード）を登録

登録完了後、MFA デバイスの ARN（arn:aws:iam::<アカウントID>:mfa/<MFAデバイス登録名>）を控えておきます。次の設定で使用します。

⑤ [手元のPC] AWS CLIプロファイルの設定

PowerShellにて、aws configure コマンドでアクセスキーを登録します。

> aws configure --profile claude-code-user

対話形式で入力を求められます。

AWS Access Key ID [None]: AKIAXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [None]: ap-northeast-1
Default output format [None]: json

次に、AssumeRole の設定を ~/.aws/config（Windows の場合は %USERPROFILE%\.aws\config）に追記します。

~/.aws/config
[profile claude-readonly]
role_arn = arn:aws:iam::<アカウントID>:role/claude-readonly-role
source_profile = claude-code-user
mfa_serial = arn:aws:iam::<アカウントID>:mfa/<MFAデバイス登録名>
region = ap-northeast-1
output = json

動作確認

PowerShellにて、設定したプロファイルで AWS にアクセスできることを確認します。

① 認証情報の確認（MFA コード入力あり）

> aws sts get-caller-identity --profile claude-readonly

MFA コードの入力プロンプトが表示されます。

Enter MFA code for arn:aws:iam::<アカウントID>:mfa/claude-code-user:

認証アプリの TOTP コードを入力すると、一時認証情報が発行されます。

{
    "UserId": "AROAXXXXXXXXXXXXXXXXX:botocore-session-1234567890",
    "Account": "<アカウントID>",
    "Arn": "arn:aws:sts::<アカウントID>:assumed-role/claude-readonly-role/botocore-session-1234567890"
}

② ReadOnly アクセスの確認

> aws ec2 describe-instances --profile claude-readonly --query "Reservations[*].Instances[*].[InstanceId,State.Name]" --output table
----------------------------------
|       DescribeInstances        |
+----------------------+---------+
|  i-0123456789abcdef0 | running |
+----------------------+---------+

③ 書き込み操作が拒否されることの確認
　※ –dry-runオプションを付けてはいますが、実行には十分注意し、
　 リスクが大きい環境では検証用インスタンスを作成してください。

> aws ec2 terminate-instances --dry-run --instance-ids i-0123456789abcdef0 --profile claude-readonly
An error occurred (UnauthorizedOperation) when calling the TerminateInstances operation: You are not authorized to perform this operation.（以下略）
AssumeRole方式の動作確認
AssumeRole方式の動作確認
確認
terminate-instances が UnauthorizedOperation で弾かれることを確認できました。ReadOnly権限が正しく機能しています。

ここまで動作確認できたら設定は完了です。次章のAI エージェント側の設定に進んでください。

AI エージェント側の設定

構築した AWS 権限設定をAI エージェントから安全に利用するための設定を行います。いずれもAI エージェント共通の観点です。

本記事では Claude Code を例に具体的な設定手順を示します。Claude Code 以外のAI エージェントをお使いの方は、お使いのエージェントで対応する機能や設定をご確認ください。

AWS CLIプロファイルの指定

セッション開始時に環境変数を設定するか、AI エージェントへの指示として明示します。

$env:AWS_PROFILE = "claude-readonly"
AWS CLI コマンドを実行する際は必ず --profile claude-readonly オプションを付けてください。
注意

AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY を直接環境変数にセットする方法は避けてください。長期認証情報が露出するリスクがあります。

認証情報を、AI エージェントの記憶領域に記載したり、AI エージェントとの会話で送信したりしないでください。AI エージェントには、会話をまたいで参照される「記憶領域」があります。この領域にアクセスキーなどの認証情報を記載すると、AI エージェントが認証情報を誤って出力したり、意図せず他の処理で参照するリスクがあります。Claude Codeの場合は CLAUDE.md がこれにあたります。他のAI エージェントでも同様の記憶領域・設定ファイルが存在する場合は注意してください。

モデルの学習利用をオフにする

AI エージェントに取得させた AWS 環境の情報（アカウントID、リソース名、IPアドレスなど）は、会話の一部としてAIサービス側のサーバーに送信され、利用するAIサービスのデフォルト設定によっては、これらの情報がモデルの改善に使用される場合があります。そのため、お使いのAIサービスのプライバシー設定から、モデルの学習利用オプションのオプトアウトを推奨します。

注意

モデル改善への利用をオフにしていても、クラウド環境の情報をAIサービスへ送信してよいかどうかは、利用プラン、組織契約、社内規程、顧客契約によって異なります。

利用前に、少なくとも以下を確認してください。

  • 利用しているプランで、入力・出力データがモデル改善に利用されるか
  • 入力・出力データの保持期間がどの程度か
  • 組織契約で Zero Data Retention などの設定を利用できるか
  • ローカル端末に保存されるセッション履歴をどのように扱うか
  • 社内規程・顧客契約上、クラウド環境情報を AIサービスへ送信してよいか

Claude Codeの場合も、アカウント種別やプライバシー設定によってデータ保持の扱いが異なります。モデル改善利用の設定だけで安全と判断せず、送信してよい情報の範囲を事前に確認してください。

Claude Code の会話データは Anthropic アカウントの設定に従います。Anthropic アカウントの設定（claude.ai または Claude デスクトップアプリ → 設定 → プライバシー →「Claude の改善にご協力ください」）をオフ にすることで、Claude Code のセッションも学習利用から除外されます。

Anthropicアカウントのプライバシー設定画面
Anthropicアカウントのプライバシー設定画面

AI エージェント側で機密ファイルの読み取りを禁止する

AI エージェントが認証情報や環境変数ファイルを誤って読み取らないよう、エージェント側の機能で読み取りを制限します。

Claude Code の場合は、.claude/settings.json の permissions.deny でファイル読み取りを禁止できます。

{
    "permissions": {
        "deny": [
            "Read(./.env)",
            "Read(./.env.*)",
            "Read(~/.aws/credentials)",
            "Read(~/.aws/sso/cache/**)",
            "Read(~/.aws/cli/cache/**)"
        ]
    }
}

ただし、このルールで防げるのは Claude Code による直接閲覧のみであり、AWS CLI が SDK 内部でファイルを参照することは止められません。あくまでも、多重的な権限設定の一つとしての設定です。

まとめ

本記事では、AI エージェントに ReadOnly 権限を与える理由と、各環境に応じた設定方法を紹介しました。

後編では、ここで構築した環境を実際に使い、トラブルシューティングを行います。具体的には、EC2＋ALB の構成をAI エージェントに相談し、出力された手順をもとに自分でコンソールから構築します。そして、わざと構築作業の中に作業ミスを仕込み、AI エージェントがトラブルシューティングできるか検証してみます。

AI エージェントが本当に役立つ局面を見たい方／構築ミスをAIがどこまで切り分けるか試したい方は、ぜひ後編もご覧ください。

ご覧いただきありがとうございました。

参考

  • Zabbix Enterprise Appliance
  • 低コスト・短納期で提供するまるごとおまかせZabbix

ITインフラ構築ソリューション

Posted by h-nakamura