COLUMN

2025.04.02 ｜ Writer：NTT東日本　白鳥翔太

Amazon Q Developer for CLIを使って、AWSのリソースをAIで作成⇒調査⇒構成図作成までやってみて、構築作業を楽にしよう

	こんにちは、白鳥です。

先日、Amazon Q Developer for CLIの大幅強化があり、CLI上でコーディング体験が大幅に向上できるようになりました。

参考：Amazon Q Developer for CLI での超高速な新しいエージェント型のコーディング体験 | Amazon Web Services ブログ

今回は本機能を使ってコーディング・・・ではなく、AWS環境の構築から運用で必要とされる業務を体験してみたいと思います。

想定する読者

AWS構築や運用に苦労している方
AWS環境の関連ドキュメントを簡単に作りたい方

Amazon Q Developer CLIエージェントについてのご相談などNTT東日本のクラウドエンジニアがお応えします。お気軽にお問い合わせください。

今回の流れ
Amazon Q Developer for CLIのインストール（Windowsの場合）: WSLのインストール; Amazon Q Developer for CLIのインストール; Amazon Q Developerへのログイン; Amazon Q Developer for CLIの環境設定
簡単な操作方法
リソース作成
AWSアカウント内部のリソース調査
環境ドキュメント及び構成図作成: パラメータシートの作成; 構成図の作成
この結果からわかるAWS構築作業における現在地の考察: 構築作業; 環境調査; ドキュメント作成; コード生成と実行
まとめ

今回の流れ

今回は、以下の流れで進めたいと思います。

Amazon Q Developer for CLIのインストール（Windowsの場合）
簡単なリソース作成
アカウント内部のリソース調査
環境ドキュメント及び構成図作成

Amazon Q Developer CLIエージェントについてのご相談などNTT東日本のクラウドエンジニアがお応えします。お気軽にお問い合わせください。

Amazon Q Developer for CLIのインストール（Windowsの場合）

Amazon Q Developer for CLIは本日現在macOSまたはLinuxでインストールできます。

Installing Amazon Q for command line

Windowsで本CLIを利用する場合には、WSLまたはDocker Desktopなどのコンテナ環境でLinux系OSの仮想環境を構築し、この環境にインストールしていきます。今回は比較的ハードルの低い、WSL環境で実装したいと思います。

事前準備

AWS CLIで利用するアクセスキー及びシークレットアクセスキー
AWS BuildersID

WSLのインストール

WSLのインストールはWindows 10 バージョン2004以上またはWindows 11の環境で実施します。Powershellを管理者権限で開き、下記のコマンドを実行します。

wsl --install

WSL のインストール | Microsoft Learn

無事WSLがインストールできたらWSLの仮想環境にログインします。

wsl ~

Amazon Q Developer for CLIのインストール

WSLの各コンポーネントを最新化します。

$ sudo apt update
$ sudo apt upgrade

AWS CLIをインストールします。

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ sudo apt install -y unzip
$ unzip awscliv2.zip
$ sudo ./aws/install

インストールできたかを下記コマンドで確認します。バージョン情報などが表示されていれば成功です。

$ aws --version
aws-cli/2.24.24 Python/3.12.9 Linux/5.15.167.4-microsoft-standard-WSL2 exe/x86_64.ubuntu.24

AWS CLIのアクセスキーとシークレットアクセスキーを入力します。

$ aws configure
AWS Access key ID [****]:
AWS Secret Access key [****]:
Default region name [****]:
Default output format [json]:

コマンドラインに従い、Amazon Q Developer for CLIをインストールします。

$ cd /tmp/
/tmp$ curl --proto '=https' --tlsv1.2 -sSf https://desktop-release.q.us-east-1.amazonaws.com/latest/amazon-q.deb -o amazon-q.deb
/tmp$ sudo chown _apt ./amazon-q.deb
/tmp$ sudo apt install -y ./amazon-q.deb

これでインストールが完了しました。

Amazon Q Developerへのログイン

次に、Amazon Q Developer for CLIの環境設定を行います。

まずは、Amazon Qにログインします。

q login

すると、ログイン方法を求められます。今回は、Freeプランである”Use for Free with Builder ID”でログインします。

Amazon Q Developer Proライセンスを持っている場合は下の”Use with Pro license”を選択します。

$ q login
? Select login method >
> Use for Free with Builder ID

コマンドラインにURLが表示されるので、このURLにブラウザでアクセスします。

https://view.awsapps.com/start/#/device?user_code=XXXX-XXXX

アクセス後、コードが一致していることを確認できたら”確認して続行”をクリックします。

アクセス許可を求められるので”アクセスを許可”を選択します。

“リクエストが承認されました”という画面が表示されたらログイン完了です。

Amazon Q Developer for CLIの環境設定

環境設定は、下記のコマンドを実行します。

q doctor

本コマンドを実行すると、不足しているパッケージなどが表示されるので、表示結果のコマンドに従い、インストールします。インストールが完了したら、再度上記のコマンドを実行し、「✓ Everything looks good!（すべては問題ありません）」と表示されるまで繰り返します。

これで環境設定は完了です。実際の操作に移っていきましょう。

Amazon Q Developer CLIエージェントについてのご相談などNTT東日本のクラウドエンジニアがお応えします。お気軽にお問い合わせください。

簡単な操作方法

操作は簡単で、下記のコマンドでチャットを開始します。

$ q chat

あとはAIベースのチャットツールのように自然言語で続けることができます。

チャットを終了する場合は、下記のコマンドを入力します。

> /quit

Amazon Q Developer for CLIを終了させる場合は、下記のコマンドを実行します。

$ q logout

リソース作成

では、今回はVPCを一つ作成したいと思います。こんなプロンプトを入力しました。

Amazon VPCを作成するCLIを作ってください。VPCの要件は下記のとおりです。

リージョン：東京リージョン（ap-northeast-1）

CIDRブロック：10.0.0.0/16

サブネット：10.0.0.0/24(パブリックサブネット　ap-northeast-1a)、10.0.2.0/24(パブリックサブネット　ap-northeast-1c)、10.0.1.0/24(プライベートサブネット　ap-northeast-1a)、10.0.3.0/24(プライベートサブネット　ap-northeast-1c)

NATゲートウェイ：各パブリックサブネットに1つずつ作成

インターネットゲートウェイ：作成する

ルートテーブル：メインルートテーブルを使用せず新しいルートテーブルを作成する。プライベートサブネットのデフォルトルートは同じアベイラビリティゾーンのNATゲートウェイに向ける

セキュリティグループ：作成しない

ネットワークアクセスリスト：作成しない

その他の要件で必要なものは適宜作成してください。

しばらく待つと、出力結果が返ってきます。

東京リージョンでVPCを作成するAWS CLIコマンドを作成します。要件に従って、VPC、サブネット、インターネットゲートウェイ、NATゲートウェイ、ルートテーブルを設定します。

まず、シェルスクリプトとして実行できるファイルを作成しましょう。

Write to filesystem

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Path: /home/shiratori/create-vpc.sh

+ 1: #!/bin/bash

(後略)

“Enter y to run this tool, otherwise continue chatting”

スクリプトの案の生成が終わり、ユーザ側に作成許可を求めています。もしここで違った場合はチャットで修正指示を出します。目視で合っていそうなので、yを押していったんこのまま作成してみます。

Creating: /home/shiratori/create-vpc.sh

Completed in 0.3s

create-vpc.shというシェルスクリプトを作成しました。このスクリプトは以下の要件を満たしています：

• 東京リージョン（ap-northeast-1）にVPCを作成

• CIDRブロック：10.0.0.0/16

• パブリックサブネット：

• 10.0.0.0/24（ap-northeast-1a）

• 10.0.2.0/24（ap-northeast-1c）

• プライベートサブネット：

• 10.0.1.0/24（ap-northeast-1a）

• 10.0.3.0/24（ap-northeast-1c）

• 各パブリックサブネットにNATゲートウェイを作成

• インターネットゲートウェイを作成してVPCにアタッチ

• 新しいルートテーブルを作成（メインルートテーブルは使用しない）

• プライベートサブネットのデフォルトルートは同じAZのNATゲートウェイに向ける

スクリプトの実行手順：

1. スクリプトに実行権限を付与します：

chmod +x create-vpc.sh

2. スクリプトを実行します：

./create-vpc.sh

スクリプトは各リソースの作成状況を出力し、最後に作成されたリソースのIDを表示します。

注意点：

• AWS CLIが設定済みであることが前提です

• 適切なIAM権限が必要です

• NATゲートウェイには料金が発生します

• スクリプト実行には数分かかる場合があります（特にNATゲートウェイの作成）

このスクリプトを実行すると、要件通りのVPC環境が東京リージョンに構築されます。

スクリプトを作成が完了したので、このまま実行してみます。

このスクリプトを実行してください

スクリプトを実行します。

（中略）

スクリプトが正常に実行され、VPC環境が東京リージョンに構築されました。以下が作成されたリソースの概要です：

• VPC ID: vpc-XXXXXXXXXXXX(CIDR: 10.0.0.0/16)

• インターネットゲートウェイ ID: igw- XXXXXXXXXXXX

パブリックサブネット:

• パブリックサブネット1: subnet- XXXXXXXXXXXX (AZ: ap-northeast-1a, CIDR: 10.0.0.0/24)

• パブリックサブネット2: subnet- XXXXXXXXXXXX (AZ: ap-northeast-1c, CIDR: 10.0.2.0/24)

プライベートサブネット:

• プライベートサブネット1: subnet- XXXXXXXXXXXX (AZ: ap-northeast-1a, CIDR: 10.0.1.0/24)

• プライベートサブネット2: subnet- XXXXXXXXXXXX (AZ: ap-northeast-1c, CIDR: 10.0.3.0/24)

NATゲートウェイ:

• NATゲートウェイ1: nat- XXXXXXXXXXXX (AZ: ap-northeast-1a)

• NATゲートウェイ2: nat- XXXXXXXXXXXX (AZ: ap-northeast-1c)

ルートテーブル:

• パブリックルートテーブル: rtb- XXXXXXXXXXXX (インターネットゲートウェイへのルート設定済み)

• プライベートルートテーブル1: rtb- XXXXXXXXXXXX (NATゲートウェイ1へのルート設定済み)

• プライベートルートテーブル2: rtb- XXXXXXXXXXXX (NATゲートウェイ2へのルート設定済み)

すべてのリソースが正常に作成され、適切に設定されました。パブリックサブネットはインターネットゲートウェイを通じてインターネットにアクセスでき、プライベートサブネットは同じAZのNATゲートウェイを通じてインターネットにアクセスできる状態です。

どうやら作成が完了したようです。念のためマネジメントコンソールでも確認してみます。

画像はVPCのリソースマップから確認できる範囲ですが、正しい設定になっているようです。（実際はすべてのリソースを目視でチェックしています）

AWSアカウント内部のリソース調査

では、AWSアカウント内部のリソースを調査してもらうことにしました。このようなプロンプトを入れています。本アカウントは先ほどのプロンプトで作成したリソースがある状態です。

当アカウントに作成されているリソース及び、利用状況を調査してください。東京リージョンだけではなく、すべてのリージョンを調査してください。

調査結果は非常に長いので最初のスクリプトの一部と最後のサマリーだけ記載します。先ほどと同様にCLIのスクリプトを作成し、調査をかけています。

（スクリプトの一部）

+ 15: echo "--- VPC ---"

+ 18: echo "--- サブネット ---"

+ 21: echo "--- インターネットゲートウェイ ---"

+ 24: echo "--- NATゲートウェイ ---"

+ 27: echo "--- EC2インスタンス ---"

+ 30: echo "--- EBS ボリューム ---"

+ 33: echo "--- Elastic IP ---"

+ 36: echo "--- セキュリティグループ ---"

+ 39: echo "--- ロードバランサー ---"

+ 42: echo "--- RDSインスタンス ---"

+ 45: echo "--- S3バケット ---"

+ 50: echo "--- Lambda関数 ---"

+ 53: echo "--- CloudFront ディストリビューション ---"

(スクリプトの一部ここまで)

まとめ

アカウントには、東京リージョン（ap-northeast-1）に先ほど作成したVPC環境のみが存在しています。他のリージョンには主要なリソースは確認されませんでした。現在、課金が発生する主なリソースはNATゲートウェイ（2つ）です。EC2インスタンスやRDSなどの他の主要なコンピューティングリソースは存在しません。

レポートは出力してくれましたが、一点注意が必要でした。調査したリソースはVPCやEC2、RDSといった主要なコンポーネントを抽出しておりましたが、それ以外のものについては指示を出してあげる必要がありそうです。何のサービスがあって、調査してほしい、という点については把握しておくか、何らかのコンテキストをプロンプトで補助する必要がありそうです。

環境ドキュメント及び構成図作成

それでは、これからドキュメント作成を行っていきましょう。よく使うドキュメントはパラメータシートと構成図があります。

パラメータシートの作成

パラメータシートは下記のプロンプトを試してみました。ThinkingでPythonコードを作成し、出力しています。足りないライブラリもインストールして出力しています。

調査結果をもとに、東京リージョンのパラメータシートをxlsx形式で出力してください。

パラメータシートをXLSX形式で作成するために、まずExcelファイルを作成するためのPythonスクリプトを作成し、実行します。

Write to filesystem

(中略)

東京リージョンのAWSリソースに関するパラメータシートをXLSX形式で作成しました。このExcelファイルには、調査結果に基づいて以下のシートが含まれています：

1. VPC情報

• VPC ID、名前、CIDRブロック、リージョン、状態などの基本情報

2. サブネット情報

• サブネットID、名前、CIDRブロック、アベイラビリティゾーン、タイプ（パブリック/プライベート）、パブリックIP自動割り当て設定

3. インターネットゲートウェイ

• IGW ID、名前、接続先VPC、状態

4. NATゲートウェイ

• NAT ID、名前、サブネット、状態、パブリックIP、プライベートIP

5. ルートテーブル

• ルートテーブルID、名前、関連付けサブネット、デフォルトルート、メインルートテーブルかどうか

6. Elastic IP

• Allocation ID、名前、パブリックIP、プライベートIP、関連付け

7. セキュリティグループ

• セキュリティグループID、名前、VPC ID、説明

8. Lambda関数

• 関数名、ランタイム、メモリ、説明

9. 課金リソース概要

• リソースタイプ、数量、リージョン、課金に関する備考

パラメータシートは /home/shiratori/parameter_sheet.xlsx に保存されました。このファイルをダウンロードして、リソース管理や設計ドキュメントとして活用できます。

VPCのシートのみを共有しますが、このような形で出力されています。

設定ごとにシートが分かれ、パラメータも見やすく表示されています。「VPC情報」はセル結合され、人手で作ったような整形もされています。

構成図の作成

構成図はpptxで出力してもらいました。こちらも必要なライブラリをインストールしてくれます。

調査結果をもとに、東京リージョンの構成図をpptx形式で出力してください。

東京リージョンの構成図をPPTX形式で作成するために、Python-PPTXライブラリを使用します。まず必要なライブラリをインストールし、構成図を作成するスクリプトを作成します。

（中略）

東京リージョン（ap-northeast-1）のAWS構成図をPPTX形式で作成しました。このプレゼンテーションには、調査結果に基づいた以下のスライドが含まれています：

1. タイトルスライド

• タイトル: AWS 東京リージョン (ap-northeast-1) 構成図

• サブタイトル: VPC: vpc-XXXXXXXXXXXX (10.0.0.0/16)

2. VPC構成図スライド

• VPC全体の視覚的な図表

• 2つのアベイラビリティゾーン（ap-northeast-1a、ap-northeast-1c）の表示

• 各アベイラビリティゾーンに配置された以下のリソース：

• パブリックサブネット（10.0.0.0/24、10.0.2.0/24）

• プライベートサブネット（10.0.1.0/24、10.0.3.0/24）

• NATゲートウェイ（各パブリックサブネットに1つずつ）

• インターネットゲートウェイとインターネットへの接続

3. ルートテーブル設定スライド

• パブリックルートテーブル（rtb- XXXXXXXXXXXX）の詳細

• 関連付けられたサブネット

• ルーティング設定（ローカルとインターネットゲートウェイへのルート）

• プライベートルートテーブル1（rtb- XXXXXXXXXXXX）の詳細

• 関連付けられたサブネット

• ルーティング設定（ローカルとNATゲートウェイ1へのルート）

• プライベートルートテーブル2（rtb- XXXXXXXXXXXX）の詳細

• 関連付けられたサブネット

• ルーティング設定（ローカルとNATゲートウェイ2へのルート）

4. リソース詳細情報スライド

• 各リソースの詳細情報を表形式で表示

• VPC、サブネット、インターネットゲートウェイ、NATゲートウェイ、Elastic IPなどの情報

• リソースID、名前、IPアドレス、アベイラビリティゾーンなどの詳細

このプレゼンテーションは /home/shiratori/architecture.pptx に保存されました。このファイルをダウンロードして、インフラストラクチャの説明や設計レビュー、ドキュメンテーションなどに活用できます。

途中ライブラリのインストールに失敗し、何度かコマンド実行許可を得るダイアログが表示されましたが、出力することができました。

出来上がった構成図はこんな感じです。

AWSアイコンにはなっていないのと、レイアウトがずれてはいますがいったん出来上がっているように見えます。このままお客さまに見せると確実に叱られる図になっているので、PowerPointは適宜修正が必要です。

Amazon Q Developer CLIエージェントについてのご相談などNTT東日本のクラウドエンジニアがお応えします。お気軽にお問い合わせください。

この結果からわかるAWS構築作業における現在地の考察

これらの結果から、AWSの構築作業におけるAmazon Q Developerの現在地を考察したいと思います。あくまで現時点におけるデモ利用をもとにした考察のため、今後の基盤モデルの進歩や、コンテキスト・プロンプトの工夫などで大きく変わる可能性もあります。

構築作業

構築作業については、正しくパラメータを要件で伝えることでほぼ間違いなく動くコードを作成してくれると思います。これはCLIのドキュメントが充実していることと、Thinkingによって伝えてない要件についても要件に外れない範囲で埋めてくれることを確認できました。また、実行する前に確認が入ることで、漏れていた要件を埋めることもできるので、より詳細な要件を詰めることにも使えます。今回はCLIでしたが、コードベースで記述できるので、別の案件で再利用することもできます。今回は試していませんが、CloudFormationやCDKでも作成、管理することも可能ではないかと思います。

環境調査

環境調査については、現時点では少し補助が必要であると考えます。調査対象のリージョンやリソースを絞ることで一覧を作ることはできると思いますが、未知のリソースを発見するには難しい印象を受けました。Cost ExplorerやAWS Configで出力された結果をもとに、対象のリソースを調査するといったことはできそうなので、また機会があれば試してみたいと思います。

ドキュメント作成

リソース一覧をもとにパラメータシートを作る点は、個人的には想像以上の出来だと思いました。指定のフォーマットへの整形や、追加情報などは必要になりますが、簡易ドキュメントとしてはかなり実用的なレベルに達しているのではと思います。

コード生成と実行

今回Amazon Q Developer自体が処理のためにスクリプトを自動で生成し、CLIを実行していきました。この機能に関してはほかにももっと試してみたいところですが、公式ブログを読む限り、gitやnpmといった一般的なコマンドも実行して処理をしていくので、こうしたAWS環境の構築や調査だけではなく、アプリケーションの開発の高速化にも役立てるのではと思います。

Amazon Q Developer CLIエージェントについてのご相談などNTT東日本のクラウドエンジニアがお応えします。お気軽にお問い合わせください。