JTP Technology Port

    技術や情報、そして人々が集まる"港"

誰でも使いこなせるAmazon Q Developer [中編]ユースケースのご紹介

Amazon Q Developerを使って「実際にどんなことができるのか?」を知りたい方に向けて、実際のプロンプトとともに活用例をご紹介します。アーキテクチャ検討やCDKコード作成、コマンド実行など、AIがどのように開発や運用をサポートしてくれるのかを解説します。また、人が行うべき作業との切り分けポイントも併せてご紹介します。

 

 

はじめに

こんにちは、JTPのAWSエンジニア、太田です。

前回の記事では導入手順編ということで、Amazon Q Developerが利用できる環境をセットアップしました。

チャット画面が表示されればいよいよAIに作業をお願いできる…とはいえ、最初は「そもそも何をやってくれるの?」というイメージがあまりないと思います。

そこで今回は、私が実際にAmazon Q Developerを使う中で「これをやってくれるのはありがたい!」と感じたシーンをまとめてみました。ぜひ参考にしてみてください。

この記事で分かること

この記事ではAmazon Q Developerに以下の作業をお願いしてみます。どのようにお願いすればよいのか、どういった成果物が出来るのか、という感覚が身に付けば幸いです。

  • アーキテクチャ検討(要件定義~基本設計)
  • AWS CDKコード作成(詳細設計)
  • コマンド実行(構築~試験)
  • 人間が行うべき作業と、AIに任せられる作業の区別

今回の記事は以下全3編のうち、

  • 中編: ユースケースのご紹介
  • 後編: 学習用データ可視化アプリケーション作成

中編の内容となります。

もしAmazon Q Developerがまだ導入できていない!という方は、前編の記事 をご覧ください。

アーキテクチャ検討(要件定義~基本設計)

「AWSを使ったシステムを作りたい!でもこのサービスはあまり知識がないからどの機能をどう使えば何が実現できるのか分からない!」という風に頭を悩ませた経験、一度はあるのではないでしょうか。

そんなときはAmazon Q Developerに最初から聞いてみるのもアリです。

 

Amazon Q Developerでの構成検討

<入力した内容>

ウェブサイトをAWS上で公開したいです。

現行システムではユーザーが入力した情報を元にPostgreSQLに対しクエリをするページになっているのですが、AWS上で同じことをやる場合どういった構成になりますか?

 <出力された内容>

AWS上でPostgreSQLを使用したウェブサイトを公開する場合、いくつかの構成パターンがあります。主な3つのアプローチをご紹介します:

  1. 基本構成(EC2 + RDS)
    最もシンプルで従来型に近い構成:
    • Amazon EC2: ウェブアプリケーションサーバー
    • Amazon RDS for PostgreSQL: マネージドPostgreSQLデータベース
    • Application Load Balancer (ALB): 負荷分散とHTTPS終端
    • Amazon VPC: ネットワーク分離
    • Amazon Route 53: DNS管理(オプション)

    インターネット

    Route 53 (DNS)

    ALB (HTTPS)

    EC2 (パブリックサブネット)

    RDS PostgreSQL (プライベートサブネット)

    メリット: 既存アプリの移行が容易、フルコントロール
    コスト: 中程度(EC2とRDSの常時稼働)

  2. コンテナ構成(ECS/Fargate + RDS)
    モダンでスケーラブルな構成:
    • Amazon ECS with Fargate: コンテナ実行環境(サーバーレス)
    • Amazon RDS for PostgreSQL: データベース
    • ALB: 負荷分散
    • Amazon ECR: コンテナイメージ保管

    インターネット

    ALB

    ECS Fargate (コンテナ)

    RDS PostgreSQL

    メリット: 自動スケーリング、メンテナンス負荷低減
    コスト: 中〜高(トラフィック次第)

  3. サーバーレス構成(Lambda + RDS Proxy)
    完全サーバーレスでコスト最適化:
    • Amazon API Gateway: APIエンドポイント
    • AWS Lambda: アプリケーションロジック
    • Amazon RDS Proxy: コネクションプーリング
    • Amazon RDS for PostgreSQL: データベース
    • Amazon S3 + CloudFront: 静的コンテンツ配信

    インターネット

    CloudFront (静的コンテンツ) / API Gateway (API)

    Lambda関数

    RDS Proxy

    RDS PostgreSQL

    メリット: 使用量ベースの課金、自動スケーリング
    コスト: 低〜中(アクセス量が少ない場合は最安)

推奨事項
小〜中規模サイト: 構成1(EC2 + RDS)が最も移行しやすい
成長が見込まれるサイト: 構成2(ECS Fargate + RDS)が柔軟性とスケーラビリティのバランスが良い
アクセスが不定期: 構成3(Lambda + RDS)がコスト効率的

共通のセキュリティ考慮事項
• RDSは必ずプライベートサブネットに配置
• セキュリティグループで最小限のアクセスのみ許可
• AWS Secrets Managerでデータベース認証情報を管理
• AWS WAFでWebアプリケーション保護(オプション)

現在のシステム構成(言語、フレームワーク、トラフィック量など)を教えていただければ、より具体的な推奨構成をご提案できます。

かなりざっくりした聞き方をしましたが、しっかり実装できそうな構成を考えてくれました。しかも各パターンのどれを選ぶべきかという基準も書いてくれています。

とはいえここまでは普通の生成AIツールでも回答してくれる内容ですよね。Amazon Q Developerならではの強みは一体どこにあるのか?というと、PC上のファイルを簡単に読み書きしてくれるということです。

<入力した内容>

この構成を図にして、.mdファイルに保存してください。

 <出力された内容>

ちょっと見た目はイケてないかもしれませんが、誰かに共有できる最低限のドキュメントにはなっているのではないでしょうか。「Mermaidで書いて」とお願いすればより見やすいドキュメントになると思います。

また、これとは逆に

<入力した内容>

AWSで〇〇するサービスを作りたいです。

Memo.txtにメモがあるので、それを踏まえて構成を考えてください。

というお願いをした場合も自動でファイルの内容を読み取ったうえで返答をしてくれます。

個人用~小規模のプロジェクトで実際に検証として手を動かしながら構成を固めていくという場合、作業と同時にドキュメント作成を進められるというのは非常に時間の削減につながることと思います。

…見ているだけだとよくわからないですよね。ですのでぜひお手元で、以前携わったプロジェクトの構成であったり、学習用途で触ってみたいサービスが使える構成などをAmazon Q Developerに作らせてみてください。

気づいたら10分後には「作成お願いします!」と言っているかも…?

 

AWS CDKコード作成

Amazon Q DeveloperはAWSとの相性が抜群なので、当然AWS CDKを使ってIaCでリソースを管理したい場合、とても役に立ちます。

<入力した内容>

aws-architecture.md の構成を作成するAWS CDKコードをTypeScriptで書いてください。

先ほどのEC2+RDSの構成をゼロからCDKコードとして起こしてもらった例です。作成までにかかった時間は約20秒。ここから軽微な修正をするにしても、構成検討から10分もかからないうちにリソース作成の準備が出来てしまいそうです。

もっとも実案件でこのまま本番利用できるか?というと手放しにハイとは言えないのが正直なところです。

一方、「ちょっとした検証環境を作りたい!」といった場合なら、細かい設定値はAIにお任せ、かつIaCを利用することで利用後の片付けが楽になり、開発ペースが大幅に上がることでしょう。

実際私も社内勉強会で利用する環境を、構成検討~CDKコード作成までAmazon Q Developerにお願いして3日で作成してもらいました。普段コードを書かない私にとって、今後決して手放すことのできないツールになった瞬間です…。

 

コマンド実行(構築~試験)

「めったに使わないコマンド、いざ必要な時になると書き方が分からない…!」

こんなお悩み、よくあるのではないでしょうか。

次の例は、「tracerouteを実行して!」とお願いした場合のものです。Tracerouteくらいは打てるよ!という方も、入ってないからインストールからする必要があるとなると急にどのコマンドを打ったらいいかわからなくなる…なんてこと、ありますよね。

Amazon Q Developerを使えばコマンド実行→結果を分析→ネクストアクションを考えるところまで一気通貫で行ってくれます。AWS CLIと組み合わせてCloudWatchのログを読み取ってもらい障害の分析を行うという使い方も非常に便利です。

ただコマンドを考えてもらうだけではなく、実環境や実行結果に即してコマンドを作成・実行してもらえるという点で、チャットツールに差をつける大きなポイントになると思います。

人間が行うべき作業と、AIに任せられる作業の区別

ここまでAmazon Q Developerが役に立つケースを紹介してきました。自分が使うならこういうときに使えそうだ、と皆様もイメージが湧いてきたのではないでしょうか。

ですが何でもかんでもAIに任せるわけにはいきません。時には人が介入したほうがよいケースもあります。

  • インプットとなる情報の用意
    これはAIツール全般に言えることですが、AIは皆様の入力をすべて考慮できるわけではありません。やり取りが長くなったり、自然言語で一度に多くの情報を与えると取りこぼしが増えてしまいます。
    構成検討や設計段階ではゼロからAIに考えてもらうより、人が考えた内容をテキストにまとめてそれを入力として渡すやり方のほうがAIも上手く動いてくれます。
     
  • 出力結果のレビュー
    こちらもAIに共通することですが、出力の内容には誤りが含まれていたり、指示したはずのことが漏れていることが多くあります。
    作成したファイルの中身を確認する、実行しようとしているコマンドを確認する…
    Amazon Q Developerはファイルの読み書きやコマンド実行をすべて行ってくれるからこそ、これらの習慣を忘れないようにしたいものです。
     
  • 作業の記録
    Amazon Q Developerを利用すると、人が実際に手を動かす時間が大幅に減ります。このことは「人が作業の内容をよく理解しないまま進んでいく」というリスクに繋がります。
    「あのコマンドを打ったら解決したんだよな」というとき、チャット履歴を後から見返すことはできますが、本筋からそれた話題や、行ってみたが意味がなかった作業などが多くある履歴から1行を探し出すというのはかなり難しいです。
    ただ「今まで話した内容をまとめてファイルに保存してください」とか、「このコードで作成されるリソースを一覧化してください」とお願いすれば1分もかからずに作業内容をまとめることができます。
    区切りのいいタイミングでセーブする感覚で記録を残して振り返ることを忘れないでください。

 

これらのポイントを抑え、AIにお願いするべきところはAIに、人が行うべきことは自分の手で行うと、より効率的にAmazon Q Developerを利用できるのではないでしょうか。

最後に

今回はAmazon Q Developerが役に立つシーンと、その場合の注意点をお伝えいたしました。

「こんな記事読んでる場合じゃない!早速触りたい!」と思っていただけたのならうれしいです。

次回、後編の記事では私がデータ分析アプリをAmazon Q Developerを用いて作成してみます。より具体的にAmazon Q Developerの使い方を知りたいという方はぜひご覧ください。

 

本記事の内容は、公開時点での内容のものです。
実際に導入を検討する際は、各製品・サービスの情報は、公式サイトのドキュメント等をご参照ください。

JTP Technology Port 新着記事