Amazon Q Developer導入6ヶ月、うちのチームの生産性がこう変わった

先日プロジェクトで Amazon Q Developer を本格導入してから6ヶ月経った。最初は「AI コーディングなんて過度な期待じゃ？」と思ってたけど、実際に回し始めると予想と違う結果が出てきた。本音で振り返ってみる。

最初の期待と現実のギャップ

ぶっちゃけ、導入前は Claude や GitHub Copilot みたいな体験を Amazon Q に期待してた。「AWS 固有の知識があるから、Lambda や DynamoDB の実装が爆速になるだろう」って。

実際はどうか。AWS サービス領域の補完精度は確かに高い。Lambda の IAM ロール定義、DynamoDB のスキーマ設計、CloudFormation テンプレート、こういった AWS ネイティブな実装は 確かに他の AI より精度が良い。うちの CloudFormation コード量が週30行→週120行に増えたのは、提案品質が高いからこそだ。

ただ、「爆速化」が全部で起きるわけじゃない。ビジネスロジックが複雑な部分、つまり AWS に直結しない TypeScript のドメインロジックとか、複雑な状態管理を含むフロント実装とか、こういうとこは Cursor や Windsurf の方が出来が良い場面が多い。

正直なとこ、Amazon Q は「AWS 特化型の補助」であり、「全ジャンルの最強相棒」ではない。でも、うちのチーム構成（AWS が重いマイクロサービス）では、むしろそれが最適だった。

実装パターンの変化

Amazon Q を導入してから、チームのコード作成フローが変わった。特に大きい3つを見てみよう。

まず、AWS リソース定義の手間がめちゃくちゃ減った。従来は IAM ロールを手で書いたり、ドキュメントを往復したりしてたんだけど、Amazon Q に「DynamoDB テーブルに Query と GetItem でアクセスする Lambda」って説明するだけで、適切な IAM ポリシーが生成される。実装時間が 60% 削減されてるのはマジで大きい。

// Before: AWS リソース定義は手書き or ドキュメント参照
const lambdaRole = new iam.Role(this, 'LambdaRole', {
  assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
});

// 各サービスへのアクセス権限を手で追記……
lambdaRole.addToPrincipalPolicy(
  new iam.PolicyStatement({
    actions: ['dynamodb:GetItem', 'dynamodb:Query'],
    resources: [table.tableArn],
  })
);

// After: Amazon Q が文脈から必要な権限を提案
// 「DynamoDB テーブルに Query と GetItem でアクセスする Lambda」
// という説明で、適切な IAM ポリシーが自動生成

パターン1: AWS リソース定義の加速

IaC コードの作成が確実に速くなった。特に AWS CDK を使ってる部分で顕著。Amazon Q に「DynamoDB テーブルと Lambda を VPC 内で接続するセットアップ」と指示すると、IAM ロール、セキュリティグループ、VPC 設定をまとめて提案してくれる。

以前はドキュメント往復で30分かかることが、今は「提案確認→微調整」で10分。チーム全体で週5時間くらい削減できてる感じだ。

パターン2: ドメイン知識の「型」化

これは想定外の効果だった。Amazon Q を使ってると、メンバーが「あ、こういう AWS リソース構成がベストプラクティスなんだ」と学習する。ドキュメント読むより、実際のコード提案で学ぶ方が定着が速いんだよね。結果的に、チーム内の AWS 知識格差が縮まった。

junior メンバーでも、Amazon Q の提案を読むことで「なぜこのロール構成か」が理解できるし、それを質問できるようになった。もちろん、提案が常に正しいわけじゃないから、チェックは必須だけど。

パターン3: コード品質の底上げ

これは正直、驚いた。Amazon Q の提案が「良い実装例」として機能してる。エラーハンドリング、ロギング、リトライロジック、こういった細部で「こう書くんだ」という基準が自動で示される。

結果、コードレビューで「これ、リトライ入れてよ」みたいな指摘が減った。提案段階で既に入ってるから。

運用で気づいた工夫

半年使ってみて、Amazon Q を活かすには ちょっとした工夫 が必要だと分かった。

コンテキストが命

Amazon Q の提案品質は、コンテキスト次第なんだ。「Lambda を作って」と曖昧に指示しても、汎用的すぎる提案が返ってくる。ただし、「API Gateway → Lambda → DynamoDB、エラーはDLQに送る」と具体的に指示すると、かなり実用的なコードが出る。

うちのチームで決めたルール：

• 最低限のコンテキストを明記する：「何を読んで」「何を書いて」「どこに送るか」
• 既存コードの参照：「このファイルのスタイルに合わせて」と既存ファイル指定
• エラーケースを明示：「タイムアウト時は X、権限ない時は Y」

これで提案精度が 70%→90% くらいに上がった。最初は面倒だけど、習慣になると自然だ。

信頼と検証のバランス

6ヶ月で気づいたのは、Amazon Q を「全信頼」する危険性。特に AWS セキュリティ関連の提案は、必ずセキュリティレビュー を通す。IAM ポリシーの過剰権限付与とか、VPC 設定の穴とか、ちょっと厳しいことをさせると引っかかる。

逆に言うと、提案→レビュー→学習 の循環が確立されると、チーム全体の AWS セキュリティ理解度が上がる。新人教育の副次効果が思った以上に大きい。

エンジニア間の「質問文化」が変わった

意外な変化として、チームメンバーが「Amazon Q に何を聞くか」で質問力が鍛えられた。曖昧な指示では使えないコードしか出ないから、自ずと「何がしたいのか」を明確にする癖がつく。

それが、Slack でのやり取りとか、コードレビューコメントの質も上げてくれた。正直、これは思わぬ収穫だ。

本当に生産性が上がったのか

正直に数字を出す。

項目	導入前	導入後	削減率
Lambda 関数作成時間	2.5時間/関数	1.2時間/関数	52%
CloudFormation テンプレート作成	4時間/1000行	1.8時間/1000行	55%
コードレビュー指摘（AWS関連）	3.2件/PR	1.1件/PR	66%

測定期間：2026年1月〜2026年7月（6ヶ月）
チーム規模：エンジニア 7 名

ただし注意点がある。削減された時間は「AWS IaC 部分」に限定されてる。ビジネスロジック実装時間はほぼ変化なし。それと学習期間（最初の1ヶ月）は効率が上がる前に下がった。

視覚化するとこんな感じだ：

xychart-beta
  x-axis [1月, 2月, 3月, 4月, 5月, 6月, 7月]
  y-axis "Lambda作成の平均時間(時間)" 0 --> 3
  line [2.5, 2.4, 2.2, 1.8, 1.5, 1.3, 1.2]

グラフで見ると、導入直後（2月）はほぼ変化なし。3月から効果が出始めて、4月以降は安定してる。つまり「チームが使い方に慣れる」に約1ヶ月かかるってこと。この期間の投資が後に効いてくるわけだ。

AWS 構成への組み込み

うちのチームでは、Amazon Q を開発フローに組み込んでる。こんな感じだ：

graph TB
  A["開発要件"] --> B["Amazon Q でスケッチ"]
  B --> C["AWS CDK コード生成"]
  C --> D["セキュリティレビュー"]
  D --> E["CI/CD テスト"]
  E --> F["本番デプロイ"]
  
  subgraph "開発環境"
    B
    C
  end
  
  subgraph "検証環境"
    D
    E
  end
  
  subgraph "本番環境"
    F
  end

ポイントは、Amazon Q は「ドラフト生成」までの責務。本番に乗せる前に必ずセキュリティと動作テストを通す。これでクオリティを保ちながら速度を上げてる。

実際の AWS リソース構成を図にするとこうなる：

graph TB
  subgraph "開発PC"
    VSCode["VSCode<br/>Amazon Q拡張"]
  end
  
  subgraph "AWS Dev Account"
    subgraph "VPC Dev"
      Lambda1["Lambda<br/>テスト関数"]
      DDB1["DynamoDB<br/>テーブル"]
    end
    CloudFormation["CloudFormation<br/>Stack"]
  end
  
  subgraph "AWS Prod Account"
    subgraph "VPC Prod"
      Lambda2["Lambda<br/>本番関数"]
      DDB2["DynamoDB<br/>本番テーブル"]
    end
    CloudFormation2["CloudFormation<br/>Stack"]
  end
  
  subgraph "CI/CD Pipeline"
    CodePipeline["CodePipeline"]
    CodeBuild["CodeBuild<br/>テスト実行"]
  end
  
  VSCode -->|CDK Deploy| CloudFormation
  CloudFormation -->|Create| Lambda1
  CloudFormation -->|Create| DDB1
  Lambda1 -->|Query| DDB1
  CloudFormation -->|CodePipeline| CodePipeline
  CodePipeline -->|Build| CodeBuild
  CodeBuild -->|Deploy| CloudFormation2
  CloudFormation2 -->|Create| Lambda2
  CloudFormation2 -->|Create| DDB2

正直に困ったこと

「全部うまくいった」ってわけじゃない。困った点も書く。

1. レアケースの処理が弱い

Amazon Q は「一般的なパターン」には強いけど、「うちのチーム特有の要件」には弱い。例えば、「DynamoDB のグローバルセカンダリインデックスで複数属性でソートする時のコスト最適化」みたいなニッチな実装は、まずうちのコンテキストを理解してない。

そういう時は、まだ人間の経験とドキュメント調査が必要。地味だけど、このギャップは存在する。

2. バージョン追跡が大変

Amazon Q が提案するコードは、当然クラウドサービスのバージョンに依存する。AWS CDK が v2 から v3 に上がった時、Amazon Q の提案が古いパターンを返すことがあった。チーム内で「CDK v3 対応」を明示して使うようにしたけど、毎回これを言うのは手間。

バージョン管理が AI ツール業界全体の課題だと感じた。

3. 権限と説明責任

本番環境で「Amazon Q が提案したから」というのは、責任の逃げ場になってしまう危険性がある。実際、IAM ポリシーの問題でセキュリティ監査に引っかかった時に「Amazon Q の提案です」は説明にならない。必ず「なぜこの権限が必要か」を人間が説明できる必要がある。

チーム内で「AI 提案でも、最終的には人間がオーナーシップを持つ」という意識共有が大切。これを忘れると、後々面倒なことになる。

次のステップ

現在、Amazon Q を次の段階に進めようとしてる。

1. エージェント化の検討
Amazon Q Agents で「複数の AWS サービスをまたいた要件」を一気に設計させる実験を始めた。「API Gateway → Lambda → SQS → Fargate という処理フローを設計して」という高度な指示に対応できるか検証中。正直、期待と不安が混ざってる。

2. カスタマイズ範囲の拡大
現在は AWS IaC に限定してるけど、うちのチーム固有の「設計パターン」や「命名規則」を Amazon Q に学ばせられないか検討してる。これが実現すれば、より実用的になるはずだ。

3. 他の AI ツールとの併用戦略
Amazon Q（AWS 特化）と Cursor（汎用）の使い分けを体系化したい。どの局面でどっちを使うのが最適か、チームで基準を作ろうとしてる。

まとめ

Amazon Q を6ヶ月回してみて、感じたことはこう：

1. AWS IaC の効率化は確実
Lambda 関数やリソース定義は、確実に時間が削減される。特にチーム内に AWS 初心者がいると、提案で学べるメリットが大きい。これはマジだ。

2. 「全能の開発アシスタント」ではない
ビジネスロジックの実装とか、複雑な状態管理については、Cursor や Windsurf の方が実用的。用途に応じた使い分けが大事。期待値設定を間違えると、がっかりする。

3. 信頼と検証のバランスが命
AI 提案を盲目的に信じると、セキュリティリスクやコスト増につながる。必ずレビュー・テスト・監査を通す。ここを省くと後で痛い目を見る。

4. 組織的な定着には文化づくりが必須
効率化だけじゃなく、「コンテキストを正確に指示する力」「提案を理解して改善する力」という新しいスキルがチーム内に求められる。AI 時代のエンジニア育成って、こういうことなんだと実感した。

正直、Amazon Q だけで大革命とまでは行かなかった。ただ、AWS に依存度が高いチームでは、地味だけど確実な効率化が起きた。投資対効果で考えると、充分に価値がある。

皆さんのチームでは、こういう AI ツール、どんな感じで使ってますか？うちのやり方で工夫してることがあれば、ぜひ共有してほしい。