Amazon Q Developerとは？機能・料金・使い方

Amazon Q Developerは、AWSの開発・運用作業に組み込まれた生成AIアシスタントです。
IDEでのコード生成、Kiro CLI、AWS Console、Slack/Teams、GitHub Preview、MCPサーバー連携、Java/.NET変換まで、AWS文脈の作業を一貫して短縮するために使います。
2026年に入りSWE-Bench Verified 66%という業界トップクラスのagent性能と、明治ホールディングスやBoomiといった日本・グローバル両方の事例も公開されています。

本記事では、Amazon Q Developerの位置づけ、主な機能、向いている企業、始め方、導入事例、GitHub Copilotとの違い、料金体系、注意点までを、2026年4月7日時点の公式一次情報ベースで整理します。

Amazon Q Developerとは

Amazon Q Developerは、AWSが提供する開発者向けの生成AIアシスタントです。公式ドキュメントでは、AWSアプリケーションの理解、構築、拡張、運用を支援する会話型アシスタントとして説明されています。

現在のAmazon Q Developerは、単なるコード補完ツールではありません。IDE上でコード生成やレビューを行うだけでなく、AWS Management Console、AWSドキュメント、AWS Console Mobile Application、Slack、Microsoft TeamsなどからAWSの設計・運用に関する質問もできます。

Amazon Q全体には、社内データ検索向けのAmazon Q Businessなど複数の製品があります。その中でAmazon Q Developerは、開発者、SRE、クラウド運用担当がAWS上の開発・運用作業を早く進めるための製品です。

性能面では、AWSが2025年4月に公式ブログで発表した新しいSoftware Development Agentが、SWE-Bench Verifiedで66%、SWT-Bench Verifiedで49%という業界トップクラスのスコアを示しています。あわせてDart、Go、Kotlin、PHP、Ruby、Rust、Scala、Bash、PowerShell、CloudFormation、Terraformへの対応が拡張され、AWS文脈で扱いやすい言語領域がさらに広がりました。

Amazon Q Developerの主な機能

Amazon Q Developerを理解するコツは、機能を「どこで使うか」で分けることです。IDEだけを見るとGitHub Copilotに近く見えますが、AWS Consoleやチャットアプリまで含めると、AWS運用支援の色が強くなります。

領域	主な機能	向いている担当
IDE	コード補完、チャット、実装支援、レビュー、変換	開発者、プラットフォームエンジニア
Kiro CLI	コマンドラインからのエージェント型開発支援	ターミナル中心の開発者、クラウド運用担当
AWS Console / AWSドキュメント	AWSリソース、設定、ベストプラクティス、サポート関連の質問	SRE、クラウド運用、管理者
Slack / Microsoft Teams	AWS運用、コスト、テレメトリ、トラブルシュートの相談	運用チーム、インシデント対応担当
GitHub Preview	issueやpull request上での開発・レビュー・脆弱性対応	GitHub中心の開発チーム
MCPサーバー連携	Jira、Bitbucket、Dynatraceなど外部ツールに接続して文脈を拡張	プラットフォーム、SRE、データ基盤
変換機能	Javaアップグレード、.NETのLinux移行支援	レガシー刷新、モダナイゼーション担当

この表から分かるように、Amazon Q Developerの特徴は「コードを書くAI」だけではありません。AWSの画面、コード、運用チャットを横断して使える点が、AWS中心のチームにとっての価値です。

IDEとKiro CLIで開発作業を支援する

Using Amazon Q Developer in the IDEでは、IDE内でのチャット、インライン補完、コード生成、デバッグ、最適化、言語更新などが案内されています。対応IDEは機能ごとに異なりますが、VS Code、JetBrains、Visual Studio、Eclipseなどが公式ドキュメント上で扱われています。

一方、CLIについては公式ドキュメント上でQ CLIがKiro CLIになったと案内されています。IDEの補完・変換機能と同一に扱わず、ターミナルからのエージェント型支援として分けて確認してください。

IDE機能を実務で使うなら、最初は「既存コードの説明」「単体テストのたたき台」「AWS SDKのコード例」「小さなリファクタリング」から試すのが現実的です。いきなり大規模な変更を任せるより、レビューしやすい単位で効果を見たほうが導入判断が安定します。

AWS Consoleやチャットアプリで運用を支援する

公式ドキュメントでは、AWS Management Console、AWS Documentation website、AWS website、AWS Console Mobile ApplicationでAmazon Q Developerを利用できると案内されています。コードではなく、AWSリソースや構成、ベストプラクティスを相談できる点が特徴です。

また、chat applicationsの公式ドキュメントでは、SlackとMicrosoft Teamsで、AWSベストプラクティス、トラブルシューティング、コスト、運用状況などについて質問できると説明されています。ただし、チャットアプリでの利用はFree tier limitsの対象と明記されています。

セキュリティレビューとコード参照を管理できる

code reviewの公式ドキュメントでは、セキュリティ脆弱性、シークレット検出、Infrastructure as Codeの問題、コード品質、デプロイリスク、ソフトウェア構成分析をレビュー対象として説明しています。

さらに、code referencesの公式ドキュメントでは、提案が公開コードに似ている場合に参照ログを確認でき、管理者が参照付き提案を含めるか制御できると案内されています。企業導入では、生成支援と同じくらい「何を提案させるか」「どのログを確認するか」が重要です。

Javaと.NETのモダナイゼーションを支援する

Amazon Q Developerは、Javaや.NETの変換にも使えます。JavaについてはJava applicationsの変換ドキュメントで、Java言語・依存関係のバージョンアップや、OracleからPostgreSQLへのEmbedded SQL変換が説明されています。

.NETについては、.NET applicationsの変換ドキュメントで、Windows依存の.NET FrameworkからLinux互換のクロスプラットフォーム.NETへ移行する流れが説明されています。一方、対応IDEや対象言語は機能ごとに異なるため、対象コードが公式の対応範囲に収まるかは事前に確認すべきです。

MCPサーバーで外部ツールに文脈を広げる

Using MCP with Amazon Q Developerでは、Q DeveloperがModel Context Protocol（MCP）に対応し、Jira、Bitbucket、データベース、社内APIなどの外部ツールに文脈を拡張できると案内されています。Q Developer CLIではローカルプロセスとして起動するMCPサーバーに加え、HTTP経由でリモートMCPサーバーにも接続でき、IDE側の構成はMCP configuration for Q Developer in the IDEで説明されています。

組織導入で重要なのは、ガバナンス面の制御です。MCP governance for Q Developerでは、IAM Identity Centerでサインインしているプロ層の組織に対して、管理者がMCPサーバーの利用そのものを無効化したり、利用可能なサーバーをホワイトリスト化したりできると説明されています。AWS総合研究所のSIer目線で言えば、MCP連携を有効化する前に「どのリポジトリ・チケット・観測データに繋げるか」「外部送信が許される情報の範囲はどこか」を先に決めておくことが、後からの権限是正コストを下げる近道です。

Amazon Q Developerが向いているユースケース

Amazon Q Developerが向いているのは、AWS上の開発・運用が日常業務に組み込まれている企業です。単にコード補完が欲しいだけなら他ツールでもよいですが、AWSリソース、運用、モダナイゼーションまで同じAI支援で扱いたい場合に価値が出やすくなります。

AWS中心の開発・運用を効率化したい場合

Lambda、ECS、EC2、S3、IAM、CloudWatchなどを日常的に扱うチームでは、コードとAWS設定の往復が多くなります。Amazon Q Developerは、IDEとAWS Consoleの両方で使えるため、開発者とSREが同じAWS文脈で相談しやすいのが利点です。

特に、障害調査や構成確認で毎回ドキュメント検索に戻っているチームでは、AWS画面上で質問できるだけでも導入価値があります。ただし、設定変更や権限変更の判断をAIに丸投げするのではなく、提案を人間が検証する前提で使うべきです。

レガシーJavaや.NETの刷新を進めたい場合

Javaや.NETのモダナイゼーション案件を抱えている企業では、Amazon Q Developerの変換機能が候補になります。単なる補完ではなく、古いJavaバージョンのアップグレードや.NETのLinux移行といった、工数が見えやすい領域で効果を検証しやすいからです。

ただし、変換機能は万能ではありません。ビルド可能な単位、対象IDE、行数上限に加えて、Javaは超過課金、.NETは対象範囲と最新料金を確認したうえで、まずは小さなモジュールで成功率とレビュー工数を測るのが現実的です。

向かないケース

反対に、次のようなケースでは別の選択肢を優先したほうが判断しやすくなります。

• AWSをほとんど使っていない場合
  IDEだけの補完が目的なら、Amazon Q Developer固有のAWS運用支援価値は出にくくなります。
  
  

• GitHub中心の開発体験だけを重視する場合
  issue、pull request、coding agent、GitHub CLIまでGitHub内で揃えたいなら、GitHub Copilotのほうが自然な場合があります。
  
  

• AIアプリやエージェントを自社で構築したい場合
  モデル、RAG、ガードレール、エージェント実行基盤を自作したいなら、Amazon BedrockやAmazon Bedrock Agentsを主軸に検討するべきです。

つまり、Amazon Q Developerは「AWSで作る・直す・運用する」作業を早くするための支援です。AIアプリ構築基盤や汎用コーディングツールとは役割を分けて見る必要があります。

Amazon Q Developerの始め方

Amazon Q Developerの始め方で最初に決めるべきなのは、個人検証か、組織導入かです。ここを曖昧にしたまま使い始めると、後からAWS Consoleで使えない、管理ダッシュボードが使えない、データ共有設定を揃えられない、といった問題が出やすくなります。

個人検証はBuilder IDから始める

Builder ID向けの公式ガイドでは、Builder IDは個人プロジェクト向けで、IDEとコマンドラインでAmazon Qを使える特別なAWSアカウント種別と説明されています。AWSアカウントなしでIDEから始めたい場合は、この導線が分かりやすいです。

ただし、Builder IDはAWS Management Consoleにアクセスできず、IAMロールや権限を割り当てる用途にも使えません。AWS Console上での利用や組織管理を前提にするなら、Builder IDだけで設計しないほうが安全です。

組織導入はIAM Identity Centerを前提にする

チームで使う場合は、IAM Identity Centerを前提に設計するほうが自然です。料金ページでは、Proの管理ダッシュボードやユーザー・ポリシー管理はIAM Identity Centerを使う場合の機能として整理されています。Builder IDで個人Proにしても、一部のPro管理機能は使えない点に注意が必要です。

導入前に決めるべき項目は次の通りです。

• 対象ユーザー
  全員に配る前に、開発、SRE、モダナイゼーション担当など、利用頻度が高いロールから始める。
  
  

• 対象コード
  AIに見せてよいリポジトリ、機密コード、外部公開前のコード範囲を分ける。
  
  

• レビュー導線
  生成コードをpull requestでレビューし、既存CI、静的解析、セキュリティスキャンを通す運用にする。
  
  

• 連携範囲
  GitHub Preview、Slack、Teams、AWS Consoleをどこまで許可するかを先に決める。
  
  

まずは1チーム、1リポジトリ、1ユースケースで検証し、受け入れ率、レビュー時間、変換後の修正工数を測るのが現実的です。

導入判断で詰まりやすい論点

Amazon Q Developerで詰まりやすいのは、機能そのものより導入設計です。

• Builder IDとIAM Identity Centerを混同していないか
  個人検証と組織統制では、認証・管理・課金・利用可能機能が変わります。
  
  

• Free tierとPro tierのデータ利用差分を確認したか
  サービス改善の公式ドキュメントでは、Pro tierのコンテンツはサービス改善に使わない一方、Free tierの一部コンテンツはサービス改善に使われる場合があり、環境ごとのopt-out手順が示されています。
  
  

• Preview機能を本番前提で扱っていないか
  GitHub連携は2026年4月7日時点でPreviewです。本番標準にする前に、対象リポジトリ、権限、データ処理リージョン、利用条件を確認する必要があります。

この3点を先に整理すると、導入後の手戻りを減らしやすくなります。

Amazon Q Developerの導入事例

Amazon Q Developerの公開事例は、コード生成だけでなく、レガシー刷新、テスト拡充、セキュリティ改善、開発生産性向上に関するものが多く出ています。ここではAWS公式の顧客事例から、導入判断に使いやすいものを整理します。

Altisourceは35万行のJavaコードを刷新

Altisourceの公式事例では、Amazon Q Developerを活用して35万行以上のレガシーJavaコードをモダナイズし、開発者生産性を25%向上、コード脆弱性を54%削減、4つの新規アプリケーションを4か月で提供したとされています。さらに同事例では、MCPサーバーをJira、Bitbucket、Figma、社内データベースに接続し、Q Developerが実プロジェクトの文脈にアクセスできるようにしたことで、フルスタックでの活用が一気に進んだ点も紹介されています。

この事例で重要なのは、Q Developerを単なる補完ではなく、レガシー刷新の変換・改善プロセスとMCP連携をセットで設計している点です。Javaモダナイゼーション案件では、行数、脆弱性、レビュー工数のようにKPIを置きやすいため、PoCの効果を測りやすくなります。

明治ホールディングスは段階展開で80〜90%の生産性向上

国内の事例として明治ホールディングスのAmazon Q Developer導入事例が公開されています。同社のグループDX推進部AWS事務局では、300以上のAWSアカウントを20名のメンバーで管理する体制下で、ドキュメント・設計資料の自動生成、Infrastructure as Code開発の効率化、運用・トラブルシューティングの高度化を段階的に進め、AWS事務局全体で80〜90%の生産性向上を実現したと紹介されています。導入後は30名超が継続的にQ Developerを活用しているとのことです。

国内SIer目線で参考になるのは、いきなり全社展開ではなく、AWS運用事務局という限定スコープから入り、効果の出た領域から横展開している点です。AWSアカウント数が多く管理工数が膨らんでいるチームでは、Q DeveloperをCCoE/AWS事務局のIaCレビューやランブック整備から始めると、PoC段階で測りやすいKPIが取れます。

Boomiは20%の生産性向上と自動生成コード比率20%

Boomiの公式事例では、開発者が時間の40%を反復的なコード作成・テスト作業に費やしていた状況に対してAmazon Q Developerを導入し、開発生産性を20%向上、開発者の自発的な利用率40%、生成されたコードのうち約20%がQ Developer由来という結果が報告されています。あわせて手動テスト時間を25%削減見込み、テストカバレッジ完了までの時間を20%短縮、開発コストを15%削減できる見通しも示されています。

iPaaSのような統合基盤を提供するチームでは、コネクタ実装やテストパターンが反復的になりやすいため、Q Developerが効きやすい代表例です。「テスト自動生成」「ボイラープレート削減」「コードレビューの一次パス」のように、効果が金額換算しやすい領域から検証するのが現実的です。

Audibleはテスト拡充とJDK 17移行で活用

Amazon Q Developer customersページでは、Audibleがレガシーシステムのテストカバレッジ拡充とJDK 17移行にAmazon Q Developerを活用した事例が紹介されています。同ページでは、あるコードパッケージのカバレッジを約10%から100%へ引き上げ、5,000件超のテストケース移行を効率化し、100件あたり平均1時間、全体で50時間超を削減したと説明されています。

この事例は、AIコーディング支援の使いどころが「新機能を一気に作る」だけではないことを示しています。既存テストに似たテストを増やす、見落としやすい境界値を洗い出す、古いテストフレームワークを更新する、といった地味だが効果の大きい領域に向いています。

Alerce GroupはJavaアップグレード工数を短縮

同じAWS公式のcustomersページでは、Alerce GroupがJavaベースのモノリシックアプリケーションをJDK 11からJDK 17へ移行する際にAmazon Q Developerの変換機能を利用し、手作業なら3〜4週間かかっていたチーム作業を9時間まで短縮したと紹介されています。

このような事例を見ると、Amazon Q Developerは新規開発だけでなく、既存システムの保守・アップグレードで効果を出しやすいことが分かります。自社で試すなら、まず「古いJavaサービス1つ」「テストケース移行1単位」のように、成果を測りやすい対象から始めるのがよいでしょう。

Amazon Q DeveloperとGitHub Copilotの違い

Amazon Q Developerを検討するときに比較対象になりやすいのがGitHub Copilotです。両者はどちらもAIコーディング支援ですが、得意な文脈が違います。

観点	Amazon Q Developer	GitHub Copilot
主な役割	AWS開発・運用に埋め込まれたAI支援	IDEとGitHub中心のAIコーディング支援
主な利用場所	IDE、Kiro CLI、AWS Console、AWSドキュメント、Slack、Teams、GitHub Preview	IDE、GitHub.com、GitHub Mobile、GitHub CLI、Windows Terminal
向くケース	AWSリソース、運用、Java/.NET変換まで同じ導線で扱いたい	GitHub上のissue、pull request、coding agentを中心にしたい
個人向け有料	Proは月額19ドル/ユーザー	Proは月額10ドル、Pro+は月額39ドル
無料枠	Free tierで月50 agentic requests、Javaアップグレードは料金ページ上で月1,000 LOC	Freeで月50 premium requests、月2,000 inline suggestion requests

なお、JavaアップグレードのFree tier上限はAWS公式内で表記が分かれています。Amazon Q Developer pricingでは月1,000 LOCですが、Java transformation Quotasではper job 1,000、per month 2,000と案内されているため、導入前にPricingとQuotasの最新記載を確認してください。

GitHub公式のplansページとCopilot requestsの公式ドキュメントでは、Copilot Free、Pro、Pro+などのプランとpremium requestsの考え方が案内されています。2026年4月7日時点では、Copilot Freeは50 premium requests、Copilot Proは300 premium requests、Pro+は1,500 premium requestsを含む形です。

選び方を単純化すると、AWS運用やAWSリソース相談まで含めるならAmazon Q Developer、GitHub上の開発体験を中心にしたいならGitHub Copilotです。両方を使う企業では、AWS担当チームはQ Developer、GitHub中心のアプリ開発チームはCopilot、という役割分担も現実的です。

Amazon Q Developerの注意点

Amazon Q Developerは便利ですが、導入前に注意すべき点もあります。特に見落としやすいのは、名称、Preview機能、データ利用、生成コードの責任範囲です。

• CLI名称がKiro CLIに変わっている
  Amazon Q Developerを調べていても、CLI手順ではKiro CLIが出てきます。古いQ CLI記事と混ざりやすいため、公式ドキュメントの更新日と導入手順を確認する必要があります。さらに、Kiro自体は独立製品としてspec-driven developmentを軸にした別サブスクリプションを持つため、「Kiro CLIを入れる＝Kiro本体に乗り換える」ではない点も整理しておくべきです。
  
  

• GitHub連携はPreviewとして扱う
  Amazon Q Developer for GitHubはPreviewです。対象リポジトリ、権限、データ処理リージョン、利用条件を確認してから試すべきです。
  
  

• Free tierとPro tierでデータ利用が違う
  Free tierで広げる前に、サービス改善への利用とopt-out手順を確認する必要があります。機密コードを扱う場合は、Pro tierや組織管理の前提を先に決めるべきです。
  
  

• 生成コードをそのままマージしない
  Q Developerはレビューを支援しますが、最終判断を代替するものではありません。pull request、CI、静的解析、セキュリティレビューを通す運用に組み込むべきです。

つまり、Amazon Q Developerは「導入すれば自動で安全になる」製品ではありません。効果を出すには、対象タスク、レビュー導線、管理設定をセットで設計する必要があります。

Amazon Q Developerの料金体系

Amazon Q Developerの料金は、2026年4月7日時点でFree tierとPro tierの2段構成です。Amazon Q Developer pricingでは、Free tierはゼロコスト、Pro tierは1ユーザーあたり月額19ドルと案内されています。

代表的な差分は次の通りです。

項目	Free tier	Pro tier
価格	無料	月額19ドル/ユーザー
agentic requests	月50回	上限付きでFreeより拡張
IDE pluginsとCLI	利用可	利用可
Javaアップグレード	料金ページ上は月1,000 LOC	月4,000 LOC/ユーザー相当をpayer account単位でプール
管理機能	なし	IAM Identity Center利用時にadmin dashboardとuser/policy management
reference tracking	あり	あり
suppress public code suggestions	あり	あり
サービス改善への利用	opt-out可能	自動opt-out
IP indemnity	なし	あり

Freeは個人検証や小規模な試用に向いています。一方、組織展開、管理者統制、IP補償、変換機能の利用枠を重視するならProが前提になります。

Javaアップグレードの超過課金と.NET変換の確認点

料金ページでは、ProのJavaアップグレードは月4,000 LOC/ユーザー相当がpayer account単位でプールされ、超過分は1 LOCあたり0.003ドルと説明されています。たとえばProが10ユーザーなら月40,000 LOCが含まれ、50,000 LOC使った場合は超過10,000 LOC分が課金対象になります。

.NET変換については、公式ドキュメント上でVisual Studio向けのC# in .NET applicationsとして説明されています。一方、料金表の行数課金はJava upgradesを中心に書かれているため、.NET変換を大規模に使う場合は、最新の料金ページと該当ドキュメントを確認したほうが安全です。

課金開始の条件

Amazon Q Developer Proは、IAM Identity Centerのグループに入れただけで全員分が即課金される設計ではありません。料金FAQでは、サブスクリプション起動アクションを行ったユーザーだけが課金対象になると説明されています。

ただし、サブスクリプションを月途中でキャンセルした場合の扱い、Javaアップグレードの超過課金、.NET変換の対象範囲は別途確認が必要です。PoCでは、対象ユーザーと変換対象リポジトリを絞り、AWS BudgetsやCost and Usage Reportで行数利用を見ながら広げるのが現実的です。

Amazon Q Developer活用を業務AI運用につなげるには

Amazon Q Developerは、AWS開発と運用の生産性を上げる入口として有効です。ただし、開発チームの便利ツールで止めるのか、業務システム連携や実行ログまで含めたAI活用基盤に広げるのかで、設計すべき範囲は変わります。

特に、AWS環境でPoCを進めたあとに全社展開する場合は、対象業務、権限管理、既存システム接続、実行ログの管理が後から課題になりやすいです。ここを曖昧にしたまま広げると、個人利用や一部チームの効率化で止まりやすくなります。

AI総合研究所のAI Agent Hub資料では、AWS上で進めたAI活用を前提に、業務システム連携、管理ダッシュボード、実行導線の整備をどう進めるかを整理しています。Amazon Q Developerの活用を、開発支援で終わらせず業務実装へつなぐ判断材料としてご確認ください。

Amazon Q Developerのまとめ

Amazon Q Developerは、AWS開発・運用に組み込まれた生成AIアシスタントです。IDEやKiro CLIでのコード支援だけでなく、AWS Console、AWSドキュメント、Slack、Teams、GitHub Preview、MCPサーバー連携まで含めて、AWS中心の作業を短縮するために使います。SWE-Bench Verified 66%、SWT-Bench Verified 49%という業界トップクラスのagent性能と、Dart・Go・Kotlin・Rust・Terraformなどへの対応拡張により、対象領域は2026年に入って大きく広がりました。

導入判断で重要なのは、個人検証と組織展開を分けることです。個人検証はBuilder IDで始められますが、管理機能やAWS Console利用を前提にするならIAM Identity Centerを軸に設計する必要があります。また、Javaアップグレードと.NET変換の対象範囲、GitHub Preview、Free tierのデータ利用、ProのJava行数上限と超過課金、MCPサーバーのガバナンス制御は、導入前に確認すべき論点です。Kiro本体は別製品扱いになるため、CLI移行と本体乗り換えは切り分けて検討してください。

実例として、明治ホールディングスはAWS事務局という限定スコープから段階展開し80〜90%の生産性向上を、Boomiはテスト自動化とボイラープレート削減で20%の生産性向上を出しています。GitHub中心の開発体験を重視するならGitHub Copilot、AWS運用やAWSリソース相談まで同じAI支援に寄せたいならAmazon Q Developerが候補になります。まずは1チーム、1リポジトリ、1ユースケースで検証し、受け入れ率、レビュー時間、変換後の修正工数を見てから横展開するのが、SIer目線での安全な広げ方です。