はじめに

NTT西日本エンタープライズビジネス営業部の吉田泰隆です。
本記事ではAWSが提供する生成AIアシスタント「Amazon Q」の性能を３つの観点で検証・評価してみました。
１観点１記事、合計３つの連載となりますので、最後までお読みいただけると嬉しいです。
気になる記事からの閲覧も大歓迎です。

Amazon Qでどこまでできるのか？～１.リソースコントロール編～（本記事）
Amazon Qでどこまでできるのか？～２.セキュリティ編～
Amazon Qでどこまでできるのか？～３.トラブルシューティング編～

本記事は2025年10月時点の情報に基づきます。

対象読者

本記事が想定する対象読者は以下の通りです。

Amazon Q を利用している人
生成 AI の実践的な活用方法に関心がある人
クラウドエンジニアとして生成AI に代替されないスキルを知りたい人
AWS 主要サービスを日常的に扱っている人
システム検証や検証レポートを業務に活かしたい人
生成AI の限界やリスクも含めて理解したい人

背景　

近年、生成 AI が急速に普及し、クラウドエンジニアリングの分野でも活用可能性が広がっています。
私自身も生成AIに強い関心を持ち、実際にどこまで現場で役立つのかを確かめたいと考えました。
また検証を通じて、生成AI に任せられる領域と人間のエンジニアが担うべき領域を明確化し、今後の業務に活用していくことを最終目的としています。

検証概要

AWS 環境での構築や保守・運用といった具体的なシナリオに適用できるかを以下３観点から評価します。

リソースコントロール （本記事）
セキュリティ
トラブルシューティング

冒頭「はじめに」でも述べましたが、本記事ではリソースコントロールに焦点をあてます。
１つの観点につき難易度の異なる２つシナリオで検証します。

検証条件・補足

Amazon Q Developer Pro （バージョンq 1.13.2）を利用します。
（Amazon Linux 2023にインストーラを利用して Q Developer CLIをインストール）
Amazon Qの回答をすべて記述するとかなり長いため、要所要所で「～略～」を使って省略をしています。
リソースID等の情報保護のため、「※※※」を使ってマスキングをしています。

シナリオ①「CloudWatch アラーム作成」

内容

EC2インスタンスのCPU使用率を監視するCloudWatchアラームを作成してもらいます。
※EC2は事前に構築しています。

基本的なリソース作成における自動補完の精度と安全性を確認します。

プロンプト

EC2インスタンス（i-※※※）のCPU使用率を監視し、  
80%超過時に反応するCloudWatchアラームを作成してください。通知等は不要です。

回答結果

Amazon Qの結果がこちらです。

> EC2インスタンス「i-※※※」のCPU使用率が80%を超過した時に  
反応するCloudWatchアラームを作成します。

🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:
～略～
 ⋮ 
 ● Completed in 2.312s

> CloudWatchアラームが正常に作成されました。

作成されたアラームの詳細：
• **アラーム名**: test1-1-cpu-high-alarm
• **監視対象**: EC2インスタンス i-※※※ のCPU使用率
• **閾値**: 80%
• **条件**: CPU使用率が80%を超過
• **評価期間**: 2回連続（10分間）
• **統計**: 平均値
• **監視間隔**: 5分毎
• **タグ**: test1-1

このアラームは以下の動作をします：
• 5分間隔でCPU使用率を監視
• 連続2回（10分間）CPU使用率が80%を超えた場合にアラーム状態になる
• 通知アクションは設定していないため、アラーム状態の変化のみを記録

アラームの状態はAWSコンソールのCloudWatchダッシュボードで確認できます。

CloudWatchアラームの構築が問題なく完了しました。コンソールでも確認できました。

考察

動作条件・パラメータの説明はありましたが、指定しないパラメータは生成AIによって自動補完されてしまうことがわかります。

指定したパラメータ	自動補完されたパラメータ
EC2インスタンスID 監視メトリクス閾値通知設定	アラーム名評価期間統計方法監視間隔タグ

ハンズオンレベルなら利用しても問題ないですが、本番環境では十分な注意が必要と思いました。というのも、生成AIが良かれと思って設定した値が、システムの要件と合致せず、重大なインシデントの見逃しに繋がる危険性があるためです。
具体的には、以下のようなリスクが考えられます。

1.意図しない監視条件による障害の見逃し
瞬間的なCPUスパイクや短時間でも負荷が続くことが問題となるシステムであれば、障害の兆候を完全に無視してしまう可能性があります。
2.運用・管理上の混乱
一般的に、作成するリソースにはシステムや案件ごとに命名規則があります。ルールから外れたリソースが自動で作成されると、誰が何のために作ったのか分からなくなり、棚卸しやコスト管理、自動化処理の妨げになるなど、運用上の大きな混乱を招きます。

もちろん、詳細パラメータを事前に指定しなかったこちら側の非でもありますが、厳密な監視要件や運用ルールが求められる本番環境では、生成AIによる設定を安易に受け入れてはいけません。利用するにしても、構築する前の第三者レビューは必須です。

シナリオ②「VPCエンドポイント作成」

内容

シナリオ①よりも、さらに複雑にしてみます。 EC2がS3にインターネットを経由している状態から、インターネットを経由しない接続に構成を変更（ゲートウェイVPCエンドポイント作成・ルートテーブルの修正）してもらいます。
※EC2とS3バケットは事前に構築しています。

さらに、バケットポリシーを以下のように設定しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyListBucket",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::※※※"
        }
    ]
}

これによって、S3オブジェクト一覧の取得をすべてのユーザーに対して拒否させ、一筋縄ではいかないようにしました。

複雑な構成変更と問題解決能力、セキュリティ考慮の自律性を確認します。

プロンプト

EC2「i-※※※」がS3「※※※ 」へのアクセスをインターネット経由なしにしたいので、  
エンドポイントを作ってバケットの中身のリスト表示をできるようにしてください。

回答結果

まず、以下の設定変更を実施しました。
1. S3用VPCエンドポイントの作成
2. IAMロールとポリシーの作成
3. EC2インスタンスへのIAMロールアタッチ

> EC2インスタンス「i-※※※」がS3バケット「※※※」に  
インターネット経由なしでアクセスできるよう、VPCエンドポイントを作成します。

まず、インスタンスのVPC情報を確認してから、S3用のVPCエンドポイントを作成します。
～略～
 ● Completed in 0.965s

> 次に、ルートテーブル情報を確認します。
～略～
 ● Completed in 1.1s

> EC2インスタンスが配置されているサブネット（subnet-※※※）は、
パブリックルートテーブル（rtb-※※※）に関連付けられています。
S3用のVPCエンドポイントを作成します。
～略～
 ● Completed in 1.271s

> VPCエンドポイントが正常に作成されました。
次に、EC2インスタンスがS3バケットにアクセスできるよう、  
IAMロールを確認し、必要に応じて作成・アタッチします。
まず、インスタンスに現在アタッチされているIAMロールを確認します。
～略～
 ● Completed in 1.4s

> インスタンスにIAMロールがアタッチされていないようです。
S3にアクセスするためのIAMロールを作成し、インスタンスにアタッチします。
まず、IAMロールを作成します。
～略～
 ● Completed in 0.850s

> 次に、S3の読み取り権限ポリシーを作成してロールにアタッチします。
～略～
 ● Completed in 0.833s

> 次に、インスタンスプロファイルを作成し、ロールを追加します。
～略～
 ● Completed in 0.834s


> 最後に、インスタンスプロファイルをEC2インスタンスにアタッチします。
～略～
 ● Execution failed after 1.10s:

An error occurred (InvalidParameterValue)  
when calling the AssociateIamInstanceProfile operation:  
Value (EC2-S3-Access-Profile) for parameter iamInstanceProfile.name is invalid.   
Invalid IAM Instance Profile name

> インスタンスプロファイルのARNを使用して再試行します。
～略～
 ● Completed in 1.235s

この段階で終了すれば、バケットポリシーが修正されておらず、エンドポイント経由でのアクセスができません。 Amazon Qも解けないかと思ったのですが、、、

> 設定が完了しました。S3バケットの内容を確認してみましょう。
～略～
> S3のAPIを正しく使用します。
🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: s3api
Operation name: list-objects-v2
Parameters: 
- bucket: "※※※"
Profile name: default
Region: us-east-1
Label: S3バケットの内容を確認
 ⋮ 
 ● Execution failed after 0.849s:

An error occurred (AccessDenied)   
when calling the ListObjectsV2 operation: User: arn:aws:iam::※※※:  
root is not authorized to perform: s3:ListBucket on resource:  
"arn:aws:s3:::※※※" with an explicit deny in a resource-based policy



> バケットポリシーでアクセスが拒否されているようです。バケットポリシーを確認してみましょう。
～略～
 ● Completed in 0.805s

> バケットポリシーでListBucketアクションが拒否されています。
VPCエンドポイント経由でのアクセスのみを許可するようにバケットポリシーを更新します。

🛠️  Using tool: fs_write (trusted)
 ⋮ 
 ● Path: /tmp/bucket-policy.json

+     1: {
+     2:   "Version": "2012-10-17",
+     3:   "Statement": [
+     4:     {
+     5:       "Sid": "AllowVPCEndpointAccess",
+     6:       "Effect": "Allow",
+     7:       "Principal": "*",
+     8:       "Action": [
+     9:         "s3:ListBucket",
+    10:         "s3:GetObject"
+    11:       ],
+    12:       "Resource": [
+    13:         "arn:aws:s3:::※※※",
+    14:         "arn:aws:s3:::※※※/*"
+    15:       ],
+    16:       "Condition": {
+    17:         "StringEquals": {
+    18:           "aws:sourceVpce": "vpce-※※※"
+    19:         }
+    20:       }
+    21:     },
+    22:     {
+    23:       "Sid": "DenyDirectInternetAccess",
+    24:       "Effect": "Deny",
+    25:       "Principal": "*",
+    26:       "Action": "*",
+    27:       "Resource": [
+    28:         "arn:aws:s3:::※※※",
+    29:         "arn:aws:s3:::※※※/*"
+    30:       ],
+    31:       "Condition": {
+    32:         "StringNotEquals": {
+    33:           "aws:sourceVpce": "vpce-※※※"
+    34:         }
+    35:       }
+    36:     }
+    37:   ]
+    38: }
 ⋮ 
 ↳ Purpose: VPCエンドポイント経由のアクセスを許可するバケットポリシーを作成
Creating: /tmp/bucket-policy.json
 ⋮ 
 ● Completed in 0.0s
～略～
Label: VPCエンドポイント経由のアクセスを許可するバケットポリシーを設定
 ⋮ 
 ● Completed in 1.4s

> 設定が完了しました。

想定した構築を実施して終了！ではなく、EC2からS3へのアクセスできるかの試験まで実施していました。その後、バケットポリシーを更新し、課題をクリアしました。
作成したVPCエンドポイントはこちらになります。

考察

単なる構築作業で終わらず、実際の動作確認まで自動実行した点が特筆すべき点です。エンジニアからすれば当然の工程なのですが、こちらから指示していないことを自ら実行にうつした点は正直驚きました。
また、S3バケットポリシーも「S3へのアクセスをプライベートネットワーク経由に限定したい」という要求に対して的確な回答となっているのも非常に良い点で、セキュリティを遵守する能力があることも評価できました。（セキュリティに関しては、次回投稿で焦点を当てます。）

（補足）バケットポリシーの解説

第1ステートメント（4～21行目）：VPCエンドポイント経由のアクセス許可

項目	内容
効果	許可（Allow）
対象者	すべてのユーザー（Principal: "*"）
許可アクション	s3:ListBucket：バケット内のオブジェクト一覧取得 s3:GetObject：オブジェクトの読み取り
対象リソース	指定されたS3バケットとその配下のすべてのオブジェクト
条件	アクセス元が特定のVPCエンドポイント（vpce-※※※）である場合のみ

第2ステートメント（22～36行目）：直接インターネットアクセスの拒否

項目	内容
効果	拒否（Deny）
対象者	すべてのユーザー（Principal: "*"）
拒否アクション	すべてのアクション（Action: "*"）
対象リソース	同じS3バケットとその配下のすべてのオブジェクト
条件	アクセス元が指定されたVPCエンドポイント以外の場合

リソースコントロール編まとめ

複雑な構成変更と予期しないエラーへの対応を含むシナリオでしたが、Amazon Qは「構築→テスト→エラー検知→原因分析→修正→再テスト」という一連のエンジニアリングプロセスを自律的に実行しました。これは単なる構築ツールではなく、真のアシスタント機能を具備していると考えます。
ただし、バケットポリシーの自動変更など、セキュリティに関わる重要な変更も自動実行してしまうため、権限管理や承認プロセスの整備が不可欠です。

次回予告

次はセキュリティ編です。シナリオ②のバケットポリシーでも少し関連がありますが、ベストプラクティスに準拠した設計がAmazon Qでできるのか？ぜひ、次回をお楽しみに！

免責事項

本記事は検証・評価を目的とした技術記事です。
本記事を使用して本番環境でのAmazon Qを利用したリソース変更作業を推奨するものではありません。
本記事の内容を参考にした結果生じるいかなる損害についても、筆者および所属組織は一切の責任を負いかねます。
読者の責任において、適切なリスク管理の下でご活用ください。