Amazon Q Developerでサーバレスシステムを構築してみました

生成AIを利用したアシスタントツールであるAmazon Q Developerが2025年4月に日本語に対応して以来、日本での注目度が上昇中ですが、実際のところ業務で使えるレベルなのかという点は気になりますよね。
ということで、実際にAmazon Q Developerを利用してシステムを構築してみて、どの程度実用性がありそうなのか確認してみることにしました。

Amazon Q Developerとは

ここでは詳細まで触れませんが、Amazon Q Developerとは生成AIを利用したアシスタントツールです。エラーをトラブルシューティングしたり、コードの生成やレビューを依頼したりといったことはもちろんのこと、Amazon Q Developer 機能に記載されているように、様々な機能を兼ね備えています。
機能はコンソールから利用することもできますが、IDEやCLIから利用することもできます。執筆時点でWindows上において直接動作するCLIツールはありませんが、WSLで動作させることは可能で、実際、本記事の検証を行う際にはWSL上からCLIを利用しています。
なお、本記事では、Amazon Q Developerの導入手順等のご案内は省略させていただきます。CLI導入の詳細はコマンドラインで Amazon Q Developer を使用するをご確認いただければと存じます。

総評

結論として、現時点でも使い方次第では十分に業務で利用できるものと感じました。

0→1のコード生成という点で実用性が高い
- 要件の理解度が高い
- コード生成速度が速い
- エラーも自分で判断し解決のためのコード修正ができる
- AWS製のIaC以外の言語にも対応している(Python、HTML、CSS、JavaScript等多数)
コードレビューの結果は具体的で実用性が高い
- 今後の修正計画まで具体的な対応日数まで含めて提案可能
ベストプラクティスやセキュリティ診断の結果も具体的で実用性が高い
- 今後の修正計画まで具体的な対応日数まで含めて提案可能

サーバレスシステム構築

それでは、さっそく、Amazon Q Developerを利用して環境構築をしていきます。

システム概要

今回はJSONとYAMLを相互変換可能なサーバレスシステムを構築します。Amazon Q DeveloperにCDKコードを生成させ、それをデプロイして環境を構築するという流れです。
構成図としては次のような形になります。API GatewayもCloudFront配下に配置する方がシンプルなのですが、CORS関連の対応ができるのか等も含めて確認するため、このような構成としています。

プロンプト

執筆時点で、Amazon Q DeveloperのCLIのモデルはClaude Sonnet 4でしたので、Anthropic社のプロンプトエンジニアリングの案内を参照してみました。しかしながら、本気でやり始めると際限がなくなってしまいそうでしたので、主に次の点だけ意識して作成しました。

タグ付け

プロンプトにコンテキスト、指示、例などの複数のコンポーネントが含まれる場合、XMLタグは大きな違いを生み出します。これらはClaudeがプロンプトをより正確に解析するのに役立ち、より質の高い出力につながります。
XMLタグを使用してプロンプトを構造化する

役割提示

Claudeを使用する際、systemパラメータを使用して役割を与えることで、そのパフォーマンスを劇的に向上させることができます。ロールプロンプティングとして知られるこの手法は、Claudeでシステムプロンプトを使用する最も強力な方法です。
Claudeにシステムプロンプトで役割を与える

コンテキストを上部に配置

長文の文書や入力（約20K以上のトークン）をプロンプトの上部、クエリや指示、例の上に配置します。これにより、すべてのモデルにおいてClaudeのパフォーマンスが大幅に向上します。
長文コンテキストのプロンプト作成のヒント

実際にAmazon Q Developerに入力したプロンプトは次の通りです。

プロンプト

<goal>
JSONとYAMLの相互変換機能を持つサーバレスWEBシステムを構築するCDKコードの作成
</goal>

<function>
- WEBシステムが提供する機能は次の2つとする
    1. ユーザが入力したJSONフォーマットをYAMLフォーマットに変換して出力する
    2. ユーザが入力したYAMLフォーマットをJSONフォーマットに変換して出力する
- 入力データのサイズ上限は1MBとする
- 入力されているデータをクリアする機能を提供する
- 変換結果をクリップボードにコピーする機能を提供する
</function>

<requirements>

<CloudFront>
- ユーザはCloudFront経由でWEBシステムにアクセス可能なようにする
- CloudFrontにはWAFを割り当て、IPアドレス`x.x.x.x/32`からのみアクセス可能なようにする
- CloudFrontにはドメイン`converter.example.com`でアクセス可能なようにする
</CloudFront>

<APIGateway>
- JSONとYAMLの変換機能の提供はAPI Gatewayを利用する
- API Gatewayはカスタムドメイン`api.example.com`を利用できるようにする
- API GatewayからはランタイムがPython 3.10のLambdaを呼び出すようにする
</APIGateway>

<ACM>
- ACMで`*.example.com`のワイルドカード証明書を発行しそれをCloudFrontやAPI Gatewayで利用する
- ACMの検証はDNS検証を利用する
- DNS検証はRoute 53の既存のホストゾーン`example.com`を利用する
    - ホストゾーンIDは`MUST_REPLACE`とする
</ACM>

<S3>
- HTML、CSS、JavaScript等の静的ファイルの配置にはS3バケットを利用する
- S3バケットへのファイル配置もCDKから実行する
- システムの静的ファイルを配置するS3バケットはOACを利用しCloudFront以外からアクセスできないようにする
</S3>

</requirements>

<note>
- AWSリージョンは`us-east-1`を利用する
- コメントやWEBコンテンツに表示する文字は日本語を利用する
- CDKのデプロイは手動で実施するため、このタイミングでデプロイは実行しない
</note>

あなたはITのスペシャリストです。
上述したシステムの要件をしっかりと読み、JSONとYAMLの相互変換機能を持つサーバレスWEBシステムをAWS上で構築するCDKコードを作成してください。

初回の回答

さて、どのような回答が返ってくるでしょうか。

初回の回答1

JSONとYAMLの相互変換機能を持つサーバレスWEBシステムのCDKコードを作成します。要件に基づいて、CloudFront、API Gateway、
Lambda、S3、ACM、WAFを組み合わせたアーキテクチャを構築します。

まず、現在のディレクトリ構造を確認してから、必要なファイルを作成していきます。


🛠️  Using tool: fs_read (trusted)
 ⋮
 ● Reading directory: /home/work/json_yaml with maximum depth of 0
 ⋮
 ● Completed in 0.0s

ディレクトリが空のようですので、CDKプロジェクトの構造を作成していきます。

出だしから一般的な汎用生成AIとのチャットと異なる部分が垣間見えました。まず、最初にカレントディレクトリの構造を確認するところから始めています。そして、カレントディレクトリに何もないことが確認できたら、それを踏まえた上でCDKプロジェクトに必要な構造を作っていくという流れになりました。

初回の回答2

## 1. CDKプロジェクトの初期化とメインスタックの作成


🛠️  Using tool: fs_write
 ⋮
 ● Path: /home/work/json_yaml/package.json

+     1: {
+     2:   "name": "json-yaml-converter",
+     3:   "version": "1.0.0",
+     4:   "description": "JSONとYAMLの相互変換機能を持つサーバレスWEBシステム",
+     5:   "main": "index.js",
+     6:   "scripts": {
+     7:     "build": "tsc",
+     8:     "watch": "tsc -w",
+     9:     "test": "jest",
+    10:     "cdk": "cdk",
+    11:     "deploy": "cdk deploy --all"
+    12:   },
+    13:   "devDependencies": {
+    14:     "@types/jest": "^29.4.0",
+    15:     "@types/node": "18.14.6",
+    16:     "jest": "^29.5.0",
+    17:     "ts-jest": "^29.0.5",
+    18:     "aws-cdk": "2.87.0",
+    19:     "ts-node": "^10.9.1",
+    20:     "typescript": "~4.9.5"
+    21:   },
+    22:   "dependencies": {
+    23:     "aws-cdk-lib": "2.87.0",
+    24:     "constructs": "^10.0.0"
+    25:   }
+    26: }


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

>

さて、ここでユーザに確認が求められました。Amazon Q Developerは自分自身でファイルを生成する等のOS側操作まで行うことが可能です。必要であれば、パッケージのインストール等までAmazon Q Developerに行わせることもできます。
しかしながら、ユーザが求めていない変更が発生する可能性もあるため、適宜確認が入ります。なお、記載通りにtとするとこの確認を省略し、全て自動で行わせることも可能です。確認について許可を出すと、これ以降も必要なファイルを自動で判断し次々と作成されていきました。作成完了後、最後に次のような出力で初回の回答が完了しました。

初回の回答3

## 完成したCDKプロジェクトの概要

JSONとYAMLの相互変換機能を持つサーバレスWEBシステムのCDKコードが完成しました。以下が主な構成要素です：

### 📁 プロジェクト構造
json_yaml/
├── bin/                    # CDKアプリケーションのエントリーポイント
├── lib/                    # CDKスタック定義
├── lambda/                 # Lambda関数のソースコード
├── website/                # 静的ウェブサイトファイル
├── test/                   # テストファイル
├── scripts/                # ビルドスクリプト
└── 設定ファイル群


### 🏗️ アーキテクチャ構成

フロントエンド
• S3バケット（静的ファイル配信）
• CloudFront（CDN + WAF）
• レスポンシブなHTML/CSS/JavaScript

バックエンド
• API Gateway（RESTful API）
• Lambda関数（Python 3.10 + PyYAML）
• カスタムドメイン設定

セキュリティ
• WAF（IP制限: x.x.x.x/32）
• ACM証明書（*.example.com）
• OAC（Origin Access Control）

ドメイン
• ウェブサイト: https://converter.example.com
• API: https://api.example.com

### 🚀 主な機能

1. JSON ↔ YAML 相互変換
   • リアルタイム変換
   • シンタックスハイライト
   • エラーハンドリング

2. ユーザビリティ
   • 1MBサイズ制限
   • クリップボードコピー
   • キーボードショートカット
   • レスポンシブデザイン

3. セキュリティ
   • IP制限によるアクセス制御
   • HTTPS強制
   • CORS設定

### 📋 デプロイ前の設定

デプロイ前に以下の値を実際の値に置き換えてください：

1. lib/json-yaml-converter-stack.ts
   • MUST_REPLACE → Route 53ホストゾーンID
   • x.x.x.x/32 → 許可するIPアドレス

### 🛠️ デプロイ手順

bash
# 1. 依存関係のインストール
npm install

# 2. CDKブートストラップ（初回のみ）
npx cdk bootstrap

# 3. デプロイ
npx cdk deploy


### 🧪 テスト実行

bash
# TypeScriptコンパイル
npm run build

# テスト実行
npm test


このCDKコードは、要件で指定されたすべての機能を実装しており、セキュアで拡張性のあるサーバレスアーキテクチャを提供します
。デプロイ後は、指定されたIPアドレスからのみアクセス可能な高性能なJSON/YAML変換ツールとして動作します。

指示の内容について、さすがにexample.comがダミーのドメインということは理解できなかったようですが、Route 53のホストゾーンとして指定したMUST_REPLACEや、IPアドレスx.x.x.xがダミーの値であるという点は自動で判断し、書き換える必要がある旨の注意まで共有してくれました。
なお、上記の「プロジェクト構造」には記載がありませんが、しっかりした内容のREADME.mdまで初回の回答で作成されています。実際には次のような構造です。ここまで初回の回答で一気に作成してくれました。

作成ファイル

.
├── README.md
├── bin
│   └── json-yaml-converter.ts
├── cdk.json
├── jest.config.js
├── lambda
│   ├── index.py
│   └── requirements.txt
├── lib
│   └── json-yaml-converter-stack.ts
├── package.json
├── scripts
│   └── build-lambda-layer.sh
├── test
│   └── json-yaml-converter.test.ts
├── tsconfig.json
└── website
    ├── index.html
    ├── script.js
    └── styles.css

トラブルシューティング

作成されたコードを利用しデプロイを行いましたが、残念ながら初回からデプロイ成功というわけにはいきませんでした。しかしながら、人間が作業しても最初から全くエラーなしでデプロイに成功するというケースも少ないので、エラーについてどう対処していくかという点を見たいと思います。

プロンプト

`npx cdk deploy`を実行すると次のようなエラーが発生しました。
内容をよく確認し、エラーが起こらないようにコードの修正をしてください。

TSError: ⨯ Unable to compile TypeScript:
lib/json-yaml-converter-stack.ts:41:32 - error TS2551: Property 'OriginAccessControl' does not exist on type 'typeof import("/root/json_yaml/node_modules/aws-cdk-lib/aws-cloudfront/index")'. Did you mean 'CfnOriginAccessControl'?

41     const oac = new cloudfront.OriginAccessControl(this, 'OAC', {
                                  ~~~~~~~~~~~~~~~~~~~

  node_modules/aws-cdk-lib/aws-cloudfront/lib/cloudfront.generated.d.ts:2558:22
    2558 export declare class CfnOriginAccessControl extends cdk.CfnResource implements cdk.IInspectable {
                              ~~~~~~~~~~~~~~~~~~~~~~
    'CfnOriginAccessControl' is declared here.
lib/json-yaml-converter-stack.ts:43:49 - error TS2339: Property 'OriginAccessControlOriginType' does not exist on type 'typeof import("/root/json_yaml/node_modules/aws-cdk-lib/aws-cloudfront/index")'.

43       originAccessControlOriginType: cloudfront.OriginAccessControlOriginType.S3,
                                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/json-yaml-converter-stack.ts:44:27 - error TS2339: Property 'Signing' does not exist on type 'typeof import("/root/json_yaml/node_modules/aws-cdk-lib/aws-cloudfront/index")'.

44       signing: cloudfront.Signing.SIGV4_ALWAYS,
                             ~~~~~~~
lib/json-yaml-converter-stack.ts:153:25 - error TS2339: Property 'S3BucketOrigin' does not exist on type 'typeof import("/root/json_yaml/node_modules/aws-cdk-lib/aws-cloudfront-origins/index")'.

153         origin: origins.S3BucketOrigin.withOriginAccessControl(websiteBucket, {
                            ~~~~~~~~~~~~~~

    at createTSError (/root/json_yaml/node_modules/ts-node/src/index.ts:859:12)
    at reportTSError (/root/json_yaml/node_modules/ts-node/src/index.ts:863:19)
    at getOutput (/root/json_yaml/node_modules/ts-node/src/index.ts:1077:36)
    at Object.compile (/root/json_yaml/node_modules/ts-node/src/index.ts:1433:41)
    at Module.m._compile (/root/json_yaml/node_modules/ts-node/src/index.ts:1617:30)
    at node:internal/modules/cjs/loader:1895:10
    at Object.require.extensions.<computed> [as .ts] (/root/json_yaml/node_modules/ts-node/src/index.ts:1621:12)
    at Module.load (node:internal/modules/cjs/loader:1465:32)
    at Function._load (node:internal/modules/cjs/loader:1282:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14) {
  diagnosticCodes: [ 2551, 2339, 2339, 2339 ]
}

回答

エラーを確認しました。CDK v2でのCloudFrontとOrigin Access Control (OAC)の実装方法が間違っています。正しいCDK v2の構文に
修正します。


🛠️  Using tool: fs_write
 ⋮
 ● Path: lib/json-yaml-converter-stack.ts

  40, 40:     // Origin Access Control (OAC)
- 41    :     const oac = new cloudfront.OriginAccessControl(this, 'OAC', {
- 42    :       description: 'OAC for JSON-YAML Converter Website',
- 43    :       originAccessControlOriginType: cloudfront.OriginAccessControlOriginType.S3,
- 44    :       signing: cloudfront.Signing.SIGV4_ALWAYS,
+     41:     const oac = new cloudfront.CfnOriginAccessControl(this, 'OAC', {
+     42:       originAccessControlConfig: {
+     43:         name: 'OAC for JSON-YAML Converter Website',
+     44:         description: 'OAC for JSON-YAML Converter Website',
+     45:         originAccessControlOriginType: 's3',
+     46:         signingBehavior: 'always',
+     47:         signingProtocol: 'sigv4',
+     48:       },
  45, 49:     });


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

>

このように、エラーについても自動で判断し、「これが原因のためこのように修正します」といった対応を行ってくれます。また、エラーの修正を行った部分に関連して修正が必要な部分についても全て自動で判断し、それらもあわせて修正してくれます。
今回発生したエラー対応全てについては載せきれませんが、CDKデプロイに関する部分で2回、アプリケーション部分で2回、合計4回のやり取りで全てのエラーが解消しました。CORS部分については1回だけのやりとりで解消したので、CDK自体のコード以外についても考慮し対応できるようです。
もっとシンプルなエラーの解消方法がありそうと感じた部分もありましたが、エラーから全て自動で判断してトラブルシューティングを完遂させたのは非常に優秀だと感じます。

WEBシステム確認

それでは、完成されたWEBシステムにアクセスしてみましょう。

デザインも整っているような感じがします。さらに、特に要件に追加していませんが、入力フォームにデフォルトでJSONの例が入力されていたり、使用方法、制限事項まで付け加えたりしてくれています。
肝心の変換機能はどうでしょうか。デフォルトで入力されていたJSONをYAMLに変換してみましょう。

正常に変換できました。今回、最大サイズは1MBに制限していますので、それ以上のサイズのJSONを変換しようとしてみます。

フォームの下のカウントが赤文字になり、変換ボタンを押せなくなりました。
次に、無効なJSONを変換してみましょう。

エラーとなりましたが、理由も表示してくれています。
YAMLからJSONへの変換はどうでしょうか。

正常に変換できました。その他、「コピー」ボタンや「クリア」ボタンも正常に動作していました。
一部、「入力フォーマットを選択（自動検出も可能）」との記載がありながら動作しない等の部分もありましたが、全体として指示した要件は守られていました。

所感

一部、エラー等もありましたが、こういった構成を1～2時間程度で「とりあえず動く」という段階まで持っていけるのは素直に素晴らしいと感じました。
元々同じようなコードが存在するのであれば別ですが、全くのゼロベースでコーディングしてくださいと言われたら、お恥ずかしながら、私は1～2時間でこの段階まで持っていける自信がありません。
もちろん、人間による確認や調整は必要となりますが、0→1の生成という観点だと非常に優秀というのが正直な感想です。

コードレビュー

せっかくなので、Amazon Q Developerが作成したコードについて、自分自身でレビューさせてみます。
なお、Amazon Q DeveloperのCLIはデフォルトだとカレントディレクトリのREADME.mdを自動的にコンテキストに追加しますので、その情報も利用されています。
ちなみに、今回はCLIのため利用しませんでしたが、IDEと統合したAmazon Q Developerだと/reviewという機能もありますので、IDEの場合はそちらを利用することも可能です。

プロンプト

<goal>
各種コードをレビューした結果をマークダウン形式のファイルとして出力する
</goal>

<note>
- 対象のコードはカレントディレクトリ配下の次のファイルとする
    - lib/json-yaml-converter-stack.ts
    - lambda/index.py
    - website/index.html
    - website/script.js
    - website/styles.css
- 診断結果は日本語で出力する
</note>

あなたはITのスペシャリストです。
上述した要件をしっかりと読み、コードレビューを実施してください。

回答

コードレビューが完了しました。コードレビュー結果.md ファイルを作成し、以下の内容で包括的なレビューを実施しました：

## レビューのハイライト

### 🟢 優れている点
• サーバレスアーキテクチャの適切な設計
• 基本的なセキュリティ対策の実装
• 適切なエラーハンドリング
• レスポンシブデザインとユーザビリティ

### 🟡 改善が必要な点
• 設定値のハードコーディング
• モニタリング・ログの不足
• セキュリティヘッダーの追加
• パフォーマンス最適化

### 🔴 重要な修正点
• WAF設定の強化
• 入力値サニタイゼーション
• XSS対策の実装
• タイムアウト処理の追加

## 総合評価: ⭐⭐⭐⭐ (4/5)

基本設計は非常に優秀で、実用的なアプリケーションとして十分機能します。提案した改善点を段階的に実装することで、エンタープ
ライズレベルの品質に到達できます。

特に優先度の高い項目（設定の外部化、セキュリティ強化）から着手することをお勧めします。

作成された結果ファイルは360行以上で指摘事項が細かく的確です。さらに、次のように今後の計画まで立ててくれていました。

結果ファイルから抜粋

## 優先度別実装計画

### 🔴 高優先度（即座に対応）

1. ハードコーディングされた設定値の外部化
2. セキュリティヘッダーの追加
3. 入力値サニタイゼーションの強化
4. エラーログの構造化

### 🟡 中優先度（1-2週間以内）

1. モニタリング・アラートの設定
2. パフォーマンス最適化の実装
3. テストコードの追加
4. ドキュメントの更新

### 🟢 低優先度（1ヶ月以内）

1. ダークモード対応
2. 追加機能の実装
3. CI/CD パイプラインの構築
4. 詳細なパフォーマンス分析

「コードレビューして」という依頼から3分程度でここまで診断してくれますので、実用性はあるものと存じます。

ベストプラクティス・セキュリティ診断

続いて、Amazon Q Developerが作成したコードについて、ベストプラクティスに準拠しているかといったことや、セキュリティに問題がないかを診断させてみます。

プロンプト

<goal>
各種コードがベストプラクティスに準拠しているか、また、セキュリティに問題がないか診断し、結果をマークダウン形式で出力する
</goal>

<note>
- 対象のコードはカレントディレクトリ配下の次のファイルとする
    - lib/json-yaml-converter-stack.ts
    - lambda/index.py
    - website/index.html
    - website/script.js
    - website/styles.css
- 診断結果は日本語で出力する
</note>

あなたはITのスペシャリストです。
上述した要件をしっかりと読み、ベストプラクティス診断、セキュリティ診断を実施してください。

回答

JSON ⇄ YAML変換ツールのベストプラクティス・セキュリティ診断を完了しました。診断結果を診断結果.mdファイルに出力いたしまし
た。

## 診断結果のハイライト

### 🔴 最優先対応項目
1. ハードコードされた設定値 - ホストゾーンIDやIPアドレスが本番環境で要置換
2. 入力検証不足 - Lambda関数での厳密な入力検証が必要

### 🟡 高優先度対応項目
1. 外部CDN依存 - Subresource Integrity (SRI)の追加が必要
2. CSP未設定 - Content Security Policyの実装が必要
3. 監視・ログ設定不足 - CloudWatch Logs、X-Rayトレーシングの設定が必要

### ✅ 良好な実装
• WAFによるIP制限とHTTPS強制
• Origin Access Control (OAC)の適切な使用
• 適切なCORS設定
• レスポンシブデザインとアクセシビリティ対応

診断結果には、各項目の詳細な改善案とコード例、段階的なアクションプランも含まれています。本番運用前に最優先項目から順次対
応されることをお勧めします。

診断結果は400行以上にもわたり、それら全てが具体的な指摘、かつ、的外れの指摘はほぼありませんでした。全ては載せきれませんが、診断の最後に、次のようなアクションプランまで用意してくれています。

結果ファイルから抜粋

## 推奨アクションプラン

### フェーズ1: 緊急対応（1-2週間）
1. **設定値の環境変数化**
   - ホストゾーンID、許可IPアドレスの環境変数化
   - AWS Systems Manager Parameter Storeの活用

2. **入力検証の強化**
   - Lambda関数での厳密な入力検証実装
   - サニタイゼーション処理の追加

### フェーズ2: セキュリティ強化（2-4週間）
1. **CSP実装**
   - Content Security Policyの設定
   - SRIの追加

2. **ログ・監視強化**
   - 構造化ログの実装
   - CloudWatch Alarmsの設定
   - X-Rayトレーシングの有効化

### フェーズ3: 運用改善（1-2ヶ月）
1. **環境分離**
   - 開発・ステージング・本番環境の分離
   - 環境別設定の実装

2. **パフォーマンス最適化**
   - Lambda関数のメモリ・タイムアウト調整
   - フロントエンドの最適化

### フェーズ4: 機能拡張（継続的）
1. **ユーザビリティ向上**
   - ダークモード対応
   - アクセシビリティ強化

2. **運用効率化**
   - 自動テストの実装
   - CI/CDパイプラインの構築

コードレビューと同様、わずか数分でここまで指摘してくれますので、十分に実用性はあるものと存じます。

最後に

AIは指数関数的に進化していくといった説もありますが、ITエンジニアの役割が大きく変わる時代がすぐそこに来ているのかもしれないということを肌で感じた検証でした。
もちろん、最終的に人間が確認したり調整したりする必要はありますが、今後、業務を進めていく上でもAIの重要度が増していくのは間違いなさそうというのが率直な感想です。
AWS以外からも開発をアシストするAIは多数発表されていますが、Amazon Q DeveloperはAWS公式という強みがありますので、引き続き動向を注視していきたいと思います。

クロスパワークラウドブログ

AWSの運用・導入、システム開発・アプリケーション開発のことならクロスパワーのクラウド

Amazon Q Developerでサーバレスシステムを構築してみました

目次

Amazon Q Developerとは

総評

サーバレスシステム構築

システム概要

プロンプト

初回の回答

トラブルシューティング

WEBシステム確認

所感

コードレビュー

ベストプラクティス・セキュリティ診断

最後に