生成AI・ML基盤

Amazon Q DeveloperをAWSチームに導入して6ヶ月、正直に振り返る

「Copilotで十分では？」と思いながら試験導入したAmazon Q Developer。6ヶ月使い続けてわかった実務での強みと限界、チームへの浸透で苦労した話をありのまま書きます。

Amazon Q Developer生成AIAWS開発効率化MLOps

Amazon Q Developerをチームに本格導入して6ヶ月が経った

正直に言うと、最初は「GitHub Copilotで十分じゃね？」と思ってた。うちのチームはAWSヘビーユーザーで、既にCopilotを使いこなしてたし、わざわざ乗り換えるモチベーションが全然なかった。

きっかけは去年の秋、SageMaker Pipelinesのデバッグ作業中に同僚がAmazon Q Developerの新機能を見せてくれたことだった。AWSサービス固有のコンテキストを理解した上でコードを補完してくれる精度が、想像以上に違った。「あ、これはAWSを使い続ける自分たちには刺さるやつだ」と直感して、チームで試験導入を決めた。

2026年現在、Amazon Q Developerは単なるコード補完ツールから大きく進化している。コードレビュー支援・セキュリティスキャン・インフラコード生成・ドキュメント自動生成まで一気通貫でこなせるようになってきて、正直これは別物だと感じている。ただ、万能ではないし、チームへの浸透も一筋縄ではいかなかった。実務目線で、良かったことも失敗したことも含めて書いていく。

2026年版Amazon Q Developerの主要機能と実測スペック

まず現時点での機能整理から。2025年後半から2026年にかけてアップデートが多かったので、去年の情報で判断してる人は注意が必要だ。

機能カテゴリ主な機能Free TierPro Tier
コードエディタ統合インラインコード補完・チャット月50回無制限
セキュリティスキャンコードのCWEスキャン・修正提案月10プロジェクト無制限
コードレビューPR差分レビュー・改善コメント生成月5回無制限
IaC生成CDK・CloudFormation・Terraform生成月50回無制限
/devエージェントマルチファイル変更・テスト生成月5タスク月250タスク
/transformエージェントJava/.NETアップグレード自動化なし含む
AWS内部ドキュメント参照re:Inventセッション・ドキュメントRAG含む含む

Pro TierはIDEプラグイン1ライセンスあたり月19ドル（AWS Builder IDで試算）。うちのチームは8名でPro契約してるので月152ドル。GitHub Copilotとほぼ同額だけど、後述するセキュリティスキャン機能を考えると費用対効果はむしろ高いと感じてる。

実際に計測したコードレビュー工数の推移を見てほしい。導入直後からじわじわ効いてきて、今は半分以下になった。

xychart-beta
  title "コードレビュー平均所要時間の推移（分/PR）"
  x-axis ["2025-12", "2026-01", "2026-02", "2026-03", "2026-04", "2026-05"]
  y-axis "分" 0 --> 80
  bar [68, 55, 42, 38, 31, 28]
  line [68, 55, 42, 38, 31, 28]

ただ注意してほしいのは、「レビュー工数」が減っただけで「レビュー品質」は別問題ということ。最初の2ヶ月はAmazon Q Developerのコメントをそのまま承認してしまうケースが出て、かえってバグが増えた時期があった。これは後でも触れる。

実際に動かしてみた：コードレビューと/devエージェント

VSCodeプラグインを入れてIDEと連携するのが基本的な入り口だ。AWS IDEプラグイン（旧名：AWS Toolkit）を入れてAWS Builder IDでサインインするだけなので、セットアップ自体は5分で終わる。

セキュリティスキャンの実運用

これが地味に一番助かってる機能だ。OWASPの脆弱性対策を意識したコードを書いていても、SQLインジェクションやハードコードされたクレデンシャルは見落としがある。Amazon Q Developerはコードリポジトリ全体をスキャンして、CWE（Common Weakness Enumeration）ベースで問題箇所を指摘してくれる。

実際にスキャンを走らせたときのPythonコードの例：

# スキャン前：ハードコードされたクレデンシャルがある例
import boto3

def get_s3_client():
    return boto3.client(
        's3',
        aws_access_key_id='AKIA...',  # Q Developerが即座に指摘
        aws_secret_access_key='xxxxx'
    )

# Amazon Q Developerの修正提案
def get_s3_client():
    # IAMロールまたはIAM Identity Centerを使用するよう提案
    return boto3.client('s3')  # 環境変数・インスタンスプロファイルを自動利用

VSCode上でコマンドパレットから Amazon Q: Run Security Scan を実行するだけで、リポジトリ全体を解析してくれる。

# CLIから実行する場合
$ q scan --scope repository

Running security scan...
Scanning 234 files across 18 languages

Found 3 critical issues:
  [CWE-798] Hardcoded credentials in src/config/aws.py:15
  [CWE-89] Potential SQL injection in src/api/users.py:87
  [CWE-732] Overly permissive file permissions in scripts/deploy.sh:23

Found 8 high severity issues...
Total scan time: 47s

コンテナセキュリティ対策と組み合わせてCI/CDパイプラインの中に組み込むと、コードがマージされる前に自動で止めることもできる。うちでは今それをやっていて、マージ前のセキュリティスキャンがブランチ保護ルールになっている。個人的には、これだけでPro Tierの月額を回収できてると思ってる。

/devエージェントの体験談

これは正直、まだ検証中の部分も多い。チャットで「このBugを修正して」「このテストを書いて」と依頼すると、複数ファイルにまたがって変更を提案してくれる機能だ。

User: Lambda関数でDynamoDBのページネーション処理を書いて。
      エラーハンドリングとリトライも含めて。
      既存のdynamodb_client.pyと整合性を保つようにして。

Amazon Q Developer:
  動作確認しました。以下のファイルを変更します：
  - src/handlers/get_items.py (新規作成)
  - src/utils/dynamodb_paginator.py (新規作成)
  - tests/test_get_items.py (新規作成)
  - src/handlers/__init__.py (更新)

実際にこれを実行すると、既存コードのスタイルやimport規則に合わせたコードを生成してくれた。完璧ではないが、「たたき台」としては十分すぎる品質だった。ただ、ユニットテストのモック設定が微妙にズレてたりするので、鵜呑みにするのは危険。あくまで叩き台と捉えて人間がレビューするのが今のところ正解だと思う。

チームへの浸透で失敗した話

導入して最初の1ヶ月は正直グダグダだった。何が問題だったか整理しておく。失敗を先に共有しておくと、同じ轍を踏まずに済むと思うので遠慮なく書く。

失敗1：ガイドラインなしにリリースした

とにかく「使ってみよう」でスタートしたら、Amazon Q Developerの提案をそのままコミットするメンバーが出てきた。生成AIの提案は正しそうに見えて間違ってることがある（特に新しいAWS APIの使い方）ので、「必ずレビューを通す」「セキュリティスキャン以外の提案は即採用しない」というルールを明文化するのが先だった。

失敗2：Free Tierの上限に引っかかってモチベが下がった

Free TierはIDEのインライン補完が月50回（体感すぐ使い切る）なので、チームで試す前にPro Tierの稟議を通しておくべきだった。途中でQuotaに引っかかって「やっぱり使えない」と感じたメンバーがいて、その信頼回復に時間がかかった。

失敗3：AWSドキュメントRAGに過信しすぎた

Amazon Q DeveloperはAWSの内部ドキュメントを参照した回答ができるが、2026年現在もハルシネーションは起きる。特に「このパラメータの正確なデフォルト値は？」みたいな質問への回答は、公式ドキュメントで確認する習慣を維持する必要がある。「AWSのことはAmazonが一番知ってるはず」という油断が一番怖い。

これらを踏まえて作ったチームの運用フローがこれ：

flowchart TD
    A[開発者がコードを書く] --> B{Amazon Q Developerに相談？}
    B -- Yes --> C[提案を受け取る]
    C --> D{提案の種類は？}
    D -- セキュリティスキャン結果 --> E[高優先度で対応。原則全対応]
    D -- コード補完・生成 --> F[コードの意図を理解した上でレビュー]
    D -- IaC生成 --> G[実際のAWSコンソールで動作確認]
    F --> H[PR作成]
    G --> H
    E --> H
    H --> I[人間レビュアーがチェック]
    I --> J{CIパイプラインでQ Developerスキャン実行}
    J -- Critical検出 --> K[ブロック。要修正]
    J -- 問題なし --> L[マージ]
    B -- No --> H

AWSインフラとの統合構成

うちのチームが実際に使っているAmazon Q Developer統合構成をまとめておく。CodeCatalyst・CodePipeline・SecurityHubとの連携が肝になっている。

graph TB
    subgraph Developer_Environment["開発者環境"]
        IDE["VSCode / JetBrains IDE"]
        Plugin["Amazon Q Developer Plugin"]
        IDE --> Plugin
    end

    subgraph AWS_Account["AWSアカウント（開発・本番統合管理）"]
        subgraph CICD_Pipeline["CI/CDパイプライン"]
            CC["AWS CodeCatalyst"]
            CP["CodePipeline V2"]
            CB["CodeBuild Fleet"]
            CC --> CP --> CB
        end

        subgraph Security_Hub["セキュリティ統合"]
            SH["AWS Security Hub"]
            QScan["Q Developer Security Scan"]
            GD["GuardDuty"]
            QScan --> SH
            GD --> SH
        end

        subgraph Knowledge_Base["ナレッジ統合"]
            QKB["Q Developer\nCustomization"]
            S3Internal["S3\n（社内コードbase）"]
            CW["CloudWatch Logs\n（エラーログ）"]
            S3Internal --> QKB
            CW --> QKB
        end

        subgraph Notification["通知・レポート"]
            SNS["Amazon SNS"]
            Slack["Slack Webhook"]
            SNS --> Slack
        end
    end

    Plugin -- コードスキャン依頼 --> QScan
    Plugin -- カスタムコンテキスト参照 --> QKB
    CB -- スキャン結果 --> QScan
    SH -- Critical Alert --> SNS

    style Developer_Environment fill:#e8f4f8,stroke:#2196F3
    style CICD_Pipeline fill:#fff3e0,stroke:#FF9800
    style Security_Hub fill:#fce4ec,stroke:#E91E63
    style Knowledge_Base fill:#e8f5e9,stroke:#4CAF50
    style Notification fill:#f3e5f5,stroke:#9C27B0

Amazon Q Developer Customization（社内コードの学習）

これが個人的に一番気に入っている機能だ。社内のコードリポジトリやドキュメントをS3に配置して「カスタマイゼーション」として登録すると、補完精度が社内コーディング規約に寄ってくる。

セットアップ手順はこんな感じ：

# カスタマイゼーションの作成
aws qbusiness create-application \
  --display-name "my-team-customization" \
  --role-arn arn:aws:iam::123456789:role/QDeveloperCustomRole

# S3からコードをインジェスト
aws qbusiness create-data-source \
  --application-id <app-id> \
  --index-id <index-id> \
  --display-name "internal-codebase" \
  --configuration '{
    "s3Configuration": {
      "bucketName": "my-internal-code-bucket",
      "inclusionPrefixes": ["src/", "docs/"]
    }
  }'

導入前後で「社内ライブラリの使い方が正しく補完される」頻度が大きく変わった。以前はプロジェクト固有のヘルパー関数が補完候補に出てこなかったのが、カスタマイゼーション設定後は自然に使ってくれるようになった。好みは分かれるかもしれないけど、うちのチームには刺さった。

インシデント対応ワークフローとも組み合わせて、CloudWatch Logsのエラーログを参照コンテキストとしてQ Developerに食わせることで、「本番のこのエラーログの原因は？」という質問に対して、自社固有のスタック情報を踏まえた回答が返ってくるようになった。マジで助かったのはこのケースで、深夜の障害対応中に「このLambdaのCold Startエラー、このログパターンから原因わかる？」と聞いたら、過去の類似インシデントのコンテキストを踏まえた回答が返ってきたことがあった。眠い頭で一人でドキュメント漁るよりずっと早かった。

GitHub CopilotやCursorとの使い分け、正直どうなのか

皆さんはどうしてます？うちのチームも最初「Copilotと併用するの？」でかなり議論になった。現時点での僕の結論はシンプルで、「AWSの文脈が絡むかどうか」で使い分けるのが一番しっくりきてる。

xychart-beta
  title "ツール別・用途別満足度スコア（5点満点・自チーム主観評価）"
  x-axis ["AWS IaC生成", "セキュリティスキャン", "汎用コード補完", "テスト生成", "ドキュメント生成", "エラー診断"]
  y-axis "満足度" 0 --> 5
  bar [4.5, 4.8, 3.6, 3.9, 3.8, 4.2]

AWS固有の作業（IaC生成・セキュリティスキャン・AWSサービス連携コード）では圧倒的にAmazon Q Developerが強い。一方、汎用的なアルゴリズム実装や非AWS技術（例：Rustの所有権周り、複雑なSQL最適化など）は、まだCopilotやCursorのほうが賢いと感じる場面もある。グラフを見ると「汎用コード補完」だけスコアが落ちてるのが正直なところを表してると思う。

VSCode・Cursor・Windsurfの使い分けについても別記事で書いたので、興味があればあわせて読んでほしい。うちは今、「AWSリソース操作・セキュリティ周りはQ Developer、それ以外の汎用コードはCursor」という棲み分けで落ち着いてる。

シナリオAmazon Q DeveloperGitHub CopilotCursor
CDK・CloudFormationコード生成◎△○
セキュリティスキャン・CWE検出◎××
Python・TypeScript汎用補完○◎◎
AWS障害ログ診断◎×△
テスト生成（unit/integration）○○◎
マルチファイル一括変更○△◎
社内コードのカスタマイゼーション◎○○
価格（Pro/月）$19/user$19/user$20/user

まとめ

6ヶ月使ってきた正直な感想は「AWSを主戦場にしているチームには本当に合っている」だ。ただ、導入すれば魔法のように改善するわけではなく、ガイドラインの整備・CI/CDへの統合・カスタマイゼーション設定と、ちゃんと「育てる」コストがかかる。やっぱりツールは使い手次第というのは変わらない。

6ヶ月を振り返って、特に重要だったポイントは3つだった：

  • セキュリティスキャン機能はFree TierでもCI統合する価値がある：Critical指摘の精度が高く、マージ前のゲートとして機能する。これだけでも導入するメリットがある
  • カスタマイゼーションは早期設定が正解：社内コードを学習させるほど精度が上がる。最初の2〜3週間で設定しておけばよかったと後悔している
  • 「提案を疑う文化」が先、ツールは後：AIの提案を鵜呑みにするチームの文化があると逆効果になる。レビュープロセスを先に整備してからロールアウトすべきだった

次のアクション案：

  1. まずFree TierでCIパイプラインにセキュリティスキャンを組み込んでみる（CodePipeline V2との連携はこちらを参照）
  2. チームのコーディング規約ドキュメントをS3に置いてカスタマイゼーション登録する
  3. 1ヶ月後に「Q Developerのコメントがどれだけ採用されたか」を計測してROIを判断する

まだ全員が満足してるわけじゃないし、/devエージェントの精度向上待ちな部分もある。ただ、AWSの深い文脈理解とセキュリティスキャンの組み合わせは、他のツールには現時点では真似できていない領域だと思う。AWSネイティブな開発をしているチームであれば、一度は試してみる価値は十分にある。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

生成AI・ML基盤

Bedrock Flows を本番で6ヶ月使って見えてきたこと【2026年版】

生成AI・ML基盤

Inferentia2・Trainium2を本番導入して6ヶ月、GPUコスト70%削減できた話

生成AI・ML基盤

Bedrockで5モデル実測比較｜Claude・Llama・Mistralを本番で動かして気づいたこと

生成AI・ML基盤

Bedrock Agentsの本番運用で学んだ、マルチステップ設計の地雷｜状態管理とメモリ問題の実装パターン

生成AI・ML基盤

SageMaker Canvasをチームに導入して6ヶ月、正直しんどかった話と意外な発見

生成AI・ML基盤

Bedrock Flows本番運用3ヶ月で気づいた、LLMワークフロー自動化の地味だけど痛い落とし穴

← 記事一覧に戻る