ひとことで言うと
Amazon Bedrock の上に構築され、AWS の高品質なコンテンツで強化された開発者向けアシスタントです。AWS のアーキテクチャやリソースについての質問に答えるほか、IDE の中ではコード補完・生成・セキュリティスキャン・言語アップグレードまでを担当します。
要するに、常駐している外部の熟練エンジニアです。隣で書きかけの行を先読みして続きを打ち（インライン補完）、頼めば自分でファイルを開いて直して差分を見せ（エージェント型コーディング）、出来上がったものを規約と脆弱性の観点で読み直します（コードレビュー）。あなたのアプリの中で動く部品ではなく、あなたの作業机の側に居る人——ここが Bedrock との決定的な違いです。
なぜ生まれたか
汎用の LLM にコードを書かせると、生成物そのものより周辺の検証が重くなります。AWS の API は版によって書き方が変わるので古い形を平気で出しますし、生成されたコードは人がレビューしていない量で増えるため、SQL インジェクションやハードコードされた資格情報がそのまま入り込みます。さらに、公開コードから学んだモデルの出力が既存の OSS に似ているときのライセンス上の扱いを、開発者は自分では判定できません。
Amazon Q Developer は、この3つを別々の仕組みで塞いでいます。AWS のコンテンツでモデルを強化して古い書き方を減らし、生成AIとルールベースの自動推論を組み合わせた検出器でレビューし、参照ログで類似元とライセンスを開示します。
| 生成AIをコードに使うと起きること | Q Developer 側の受け皿 |
|---|---|
| AWS API の書き方が古い・存在しない | AWS コンテンツで強化されたモデル＋回答への参照付与 |
| レビューされないコードが増える | コードレビュー（SAST・シークレット検出・IaC・品質・デプロイリスク・SCA） |
| 生成物が OSS に似てしまう | 参照ログにライセンスと参照元を記録。管理者は参照付き提案を組織全体で無効化できる |
| 社内ライブラリ・独自流儀を知らない | インライン補完を社内ライブラリ・独自アルゴリズム・企業のコードスタイルに合わせられる |
| 会話が長くなりコンテキストが溢れる | /compact で会話履歴を要約して圧縮する |
| 古い言語ランタイムから動けない | 変換（Java のバージョン・依存アップグレード、Oracle → PostgreSQL の埋め込み SQL 変換） |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| コード補完 | インライン補完。既存コード・コメント・ファイル名も文脈に使われる | D2 |
| 機能実装・リファクタリング | チャットからエージェント型コーディング。ファイルを直接更新し、差分で確認して取り消せる | D2 |
| 単体テスト生成 | チャットの機能として提供（旧 /test） | D5 |
| ドキュメント生成 | README 等の新規作成・既存更新（旧 /doc） | D2 |
| セキュリティ・品質レビュー | チャットからレビュー依頼。自動レビューを有効にすると書きながら評価される（旧 /review） | D5 |
| 言語・依存のアップグレード | Java の変換ジョブ。Visual Studio では .NET の変換もある | D2 |
| 埋め込み SQL の移行 | Java アプリの Oracle → PostgreSQL 向け埋め込み SQL 変換 | D2 |
| 外部ツール接続 | MCP サーバを IDE から利用（VS Code / JetBrains / Eclipse / Visual Studio すべて対応） | D2 |
| AWS の相談 | マネジメントコンソール・AWS ドキュメントサイト・コンソールモバイルアプリ内のチャット | D2 |
| チャットツールからの利用 | Microsoft Teams / Slack（AmazonQDeveloperAccess マネージドポリシー） | D2 |
試験でどう問われるか
Q Developer はアプリの部品ではなく開発者の道具なので、アーキテクチャ図の中に置かれる形では出ません。出るのは D2 の「アプリ統合パターンと開発ツール」 と、D5 の「生成AI固有のエラーパターンの認識」 の2箇所です。前者は「開発を速くする手段」、後者は「生成されたコードの品質をどこで担保するか」という問われ方になります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 開発生産性を上げたい | 「開発チームの実装速度」「既存コードのリファクタリング」が主語 → Q Developer | Amazon Q Business（相手が従業員の業務データ）／Bedrock（自分のアプリに組み込む生成AI） |
| 生成AI が書いたコードの脆弱性を早期に見つけたい | 「SQL インジェクション」「ハードコードされた資格情報」「IaC の設定不備」 → Q Developer のコードレビュー（SAST・シークレット検出・IaC・SCA） | Bedrock Guardrails（実行時の入出力フィルタであって、ソースコードの静的解析ではない）／「プロンプトで安全に書けと指示する」 |
| 生成コードのライセンスリスク | 「OSS に似た提案が混ざるのを組織として止めたい」 → 参照ログ＋管理者による参照付き提案のオプトアウト（開発者側では戻せない） | Guardrails のコンテンツフィルタ／「人力で目視確認する運用を敷く」 |
| レガシー Java の移行 | 「Java のバージョンと依存を一括で上げたい」「Oracle 依存の埋め込み SQL を PostgreSQL へ」 → 変換ジョブ | Bedrock でモデルに全ソースを投げて書き直させる案（コンテキストウィンドウ溢れの典型） |
| 会話が長くなって挙動が崩れた | コンテキストウィンドウの限界が近い → /compact で履歴を要約圧縮／新しいタブで会話を切る | 「モデルを大きいものに替える」（D5 では原因の特定が問われる。溢れは切り分けの対象） |
| 社内の独自ライブラリを使ってほしい | インライン補完を社内ライブラリ・独自アルゴリズム・企業コードスタイルに合わせる | 「ファインチューニングした基盤モデルを Bedrock に載せる」（要件が IDE の補完なら過剰） |
| 外部ツール・データに繋ぎたい | IDE から MCP サーバを使う | 「Q Developer の API を自作アプリから呼ぶ」（Q Developer は開発者向けアシスタントで、アプリ組み込み用の推論 API ではない） |
| チャットでの操作を安全にしたい | エージェント型コーディングは既定で有効。</> アイコンでオフにできる／変更は差分で確認して取り消せる | 「IAM でファイル編集を止める」（IDE 内の挙動は IAM の対象ではない） |
1問拾える境目: コードレビューの既定スコープは「プロジェクト全体」ではなくアクティブなファイルの git diff の差分です。差分が無ければそのファイル全体、ファイルが開いていなければプロジェクト内の変更を探します。CI に組み込む前提で「毎回フルスキャンが走る」と読むと外れます。またレビュー対象からは未対応言語・テストコード・オープンソースコードが除外されます。
実務でどう使うか
- IDE によって使える機能が違います。 チャット・エージェント型コーディング・MCP サーバ・インライン補完は VS Code / JetBrains / Eclipse / Visual Studio の4つすべてで使えますが、インラインチャットは Visual Studio で非対応、変換は Eclipse で非対応です。「全社の IDE を統一していない」環境では、この差が運用ルールに直撃します
- レビューにはサイズのクォータがあります。 自動レビューは入力アーティファクト・ソースコードとも 200 KB、ファイル／プロジェクトのレビューは入力アーティファクト 500 MB・ソースコード 50 MB です。モノレポでは自動レビューが実質的に効かない規模になります
- 変換ジョブにもクォータがあります。 同時実行はユーザーあたり1ジョブ、AWS アカウントあたり25ジョブ。月あたりのジョブ数は Pro が1,000、無料枠が100で、無料枠は1ジョブ1,000行・月2,000行の上限が付きます。IDE の変換と Visual Studio の .NET 変換で同時実行枠を共有します
- エージェント型コーディングは、低リスクと判断したシェルコマンドを自分で実行することがあります。 提案されたコマンドを都度承認する運用にしたいなら、その前提で設計します。ファイル変更は差分表示と取り消しがあるので、そちらは事後で戻せます
- 参照ログのオプトアウトは方向が一方通行です。 管理者が Amazon Q Developer コンソールで参照付き提案を無効化すると、開発者は IDE 側のチェックボックスを操作できても効きません。逆に Lambda のコードエディタでは参照そのものが未対応で、参照を伴う提案は最初から省かれます
- 会話のコンテキストはセッション内だけです。 タブは同時に10枚まで開けますが、別の会話にはコンテキストが引き継がれません。長い作業を複数タブに分けると、前提を毎回言い直すことになります
- 日本語でそのまま会話できます。 IDE のチャットは日本語を含む複数の自然言語を自動判別して応答します
試験には出ないが現場で効く点: インライン補完はファイル名も文脈として使います。test_ で始まるファイルと handler.py では出てくる提案の性格が変わります。仮の名前で新規ファイルを作ってから書き始めると、提案の質がその名前に引きずられます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Q Business | 相手が違います。Q Developer は開発者、Q Business は業務データを使う従業員。ユーザーガイドから別物で、公式も冒頭で注意書きを置いています |
| Amazon Bedrock | Bedrock は自分のアプリに組み込む API。Q Developer はその API の上に AWS が作った完成品で、アプリから呼ぶものではありません |
| Kiro | 試験ガイドでは Q Developer が Machine Learning、Kiro は Developer Tools に分類されています。カテゴリが違うことが切り分けの手がかりになります |
| AWS Transform | Java アップグレード向けのエージェント型 AI として公式が別に案内しています。IDE の中で完結する変換ジョブが Q Developer 側 |
| Bedrock Guardrails | Guardrails は実行時の入出力。コードレビューはソースコードの静的解析。生成コードの脆弱性はレビュー側の担当です |
| Bedrock Model Evaluations | あちらはモデルの出力品質の評価（D5）。Q Developer のレビューは成果物のコードの評価。同じ D5 でも対象が違います |
| CloudWatch Logs Insights / X-Ray | 本番の生成AIアプリの挙動を追う道具（D2 2.5・D5）。Q Developer は書いている最中の側 |
想起チェック
Q1. 「生成AIで書いたコードに脆弱性が混ざるのを、デプロイ前に検出したい」。Bedrock Guardrails が答えにならない理由は？
Guardrails は実行時のモデル入出力をフィルタする仕組みで、ソースコードを解析しません。必要なのは Q Developer のコードレビュー（SAST・シークレット検出・IaC・SCA）で、生成AIとルールベースの自動推論の両方で動きます。
Q2. Q Developer のコードレビューを頼んだのに、想定より狭い範囲しか見ていません。何が起きていますか。
既定はアクティブなファイルの git diff の差分だけを見ます。差分が無ければファイル全体、ファイルが開いていなければプロジェクト内の変更を探します。全体を見せたければ明示的にプロジェクト全体のレビューを依頼します。
Q3. 「OSS 由来の類似コードが提案に混ざるのを、組織として禁止したい」。開発者ごとの設定で足りますか。
足りません。 管理者が Amazon Q Developer コンソールで参照付き提案を無効化すると、開発者は IDE のチェックボックスを操作しても効かなくなります。個人設定は管理者のオプトアウトを上書きできません。
Q4. Java 8 のアプリを最新版へ上げたい。「全ソースを Bedrock のモデルに渡して書き直させる」案の弱点は？
コンテキストウィンドウに収まりません。 Q Developer の変換ジョブは、Java のバージョンと依存のアップグレードを行数クォータの管理下でジョブとして回します。1ジョブあたりの行数上限は無料枠で1,000行です。
Q5. 長いチャットの途中から Q Developer の応答が噛み合わなくなりました。まず何を試しますか。
/compact で会話履歴を要約圧縮するか、新しいタブで会話を切ります。コンテキストウィンドウが上限に近づいたときのための機能です。なおタブをまたいでコンテキストは引き継がれません。