はじめに
Amazon Q Developerが登場して、AWSのちょっとした仕様調査やコーディングがかなり楽になりましたよね。MCPサーバとの連携も簡単で、開発効率が格段に向上している方も多いのではないでしょうか。
しかし、私の観測範囲では個人レベルでの利用は広がっているものの、組織やチーム単位での導入ができているところはまだ少ないでは？と感じています。その理由として、統制面での不安、ほぼ利用必須のIAM Identity Centerとのやや複雑な連携設定があると推測しています。
この記事では、Q Developerの有償プラン（Pro Tier）を組織に導入する際の統制面と設計面でのTipsをお伝えします。CCoEや情報システム部門として組織全体への導入を検討している方、自チーム内での導入を推進したい方、そしてセキュリティ部門や法務部門への説明責任がある方に向けて知見を提供できればと思います。
※本記事では、IAM Identity Centerを「IIC」と略記します。また、Q Developerは特に断りがない限り、IDE統合版とCLI版の両方を指します。
Q Developer Proの統制
Q Developerには無料プラン（Free Tier）と有償プラン（Pro Tier）がありますが、組織での利用を考える際、料金以上に重要なのが統制面での違いです。
無料プランの場合、月50回のチャット制限などの機能制限もありますが、それより重要なのがデータの取り扱いです。オプトアウト設定を行わない限り、ユーザーの質問内容がAWSによって参照・学習に利用される可能性があります。オプトアウト設定はAWS Organizationsの管理アカウントで行う必要があり、設定漏れがあると企業の機密情報が意図せずAWSに渡ってしまうリスクがあります。
一方、Pro Tierは月額19USD/ユーザとそれなりの費用がかかりますが、統制面では圧倒的に安心です。最も重要な違いは、オプトアウト設定なしで、デフォルトでAWSがユーザーの質問内容を参照しないことです。つまり、特別な設定をしなくても企業のプライバシーが自動的に保護されます。
また、Pro Tierには知的財産（IP）補償も付帯しています。これは、Q Developerの生成物が第三者の知的財産権を侵害したとして法的に争われた場合、AWSが法的防御を提供し、損害賠償も負担するというものです。BedrockではTitanやNovaなどのAWS製モデルでしか利用できない補償ですが、Q Developerでは標準で適用されます。このIP補償の詳細はService Termsに明記されています。
さらにもう一つの重要な統制機能として、プロンプトログの自動取得機能（監査証跡の記録）があります。この機能を有効化することで、ユーザのプロンプト内容、AIからの回答、タイムスタンプ、ユーザーIDなどの詳細な利用ログがS3バケットに自動で保存されます。
| 項目 | 無料プラン（Free Tier） | 有償プラン（Pro Tier） |
|---|---|---|
| AWSデータ収集 | オプトアウトにより無効化可能 | デフォルトで無効化 |
| IP補償 | なし | あり |
| プロンプトログ記録 | なし | あり（S3バケット保存） |
組織での本格的な活用を推進する場合、Pro Tierの選択が望ましいです。
認証基盤であるIICの設計
Q Developerのユーザー認証には、Builder IDまたはIAM Identity Center（IIC）ユーザーを使用できます。Builder IDは無料・有料プランどちらでも利用可能ですが、IICユーザーは有料プラン限定となります。
ただし、組織での利用を考える場合、必ずIICを選択すべきです。Builder IDではユーザー管理が個人任せになってしまい、組織としての統制が効きません。また、Builder IDの場合、マネジメントコンソールにアクセスできないためマネジメントコンソール上に生えているQ Developerを利用できなかったり、自組織のリポジトリを読み取ってカスタマイズされた回答を提供する機能なども利用できないなど、機能面でも制約があります。
組織インスタンス vs アカウントインスタンス
IICには「組織インスタンス」と「アカウントインスタンス」という2つの形態があり、Q Developer導入時にはどちらを選ぶかが重要な設計判断となります。
組織インスタンスは、AWS Organizations配下の複数AWSアカウントに対するSSOログイン機能を提供する、IICの標準的な利用形態です。ただし、Organizations管理アカウント（または委任アカウント）での操作が必須となります。
しかし現実問題として、1つのOrganizationsを複数部署で共用しているケースや、リセラーやCCoEからAWSアカウントの提供を受けているケースでは、開発者が管理アカウント上のIICを自由に操作できない状況が多く存在します。
そのような制約がある環境では、アカウントインスタンスという選択肢があります。アカウントインスタンスは、特定のメンバーアカウント内に閉じたユーザー管理を可能にするIICの機能です。アカウントインスタンスでは、権限セットの作成はできず、AWSマネジメントコンソールへのログイン機能は提供されませんが、Q DeveloperやQuichkSightなどのAWSのSaaSサービス専用のユーザー管理機能を担っています。
細かい補足情報
- Q Developerはバージニア北部リージョンとフランクフルトリージョン限定のサービスですが、東京リージョンなどの異なるリージョンに設定したIICとも連携できます。
- Organizations内で組織インスタンスとアカウントインスタンスを併用できます
- Organizations管理されていないスタンドアロンのアカウントでは、アカウントインスタンスを利用できます。
理想は組織インスタンスを使うこと
組織全体での統一的な管理を考えれば、組織インスタンスの利用が強く推奨されます。
また、Q DeveloperはAWSの認証情報を使ってAWSアカウントに接続し、実際のリソース情報やコスト情報を元にした回答を生成できます。これにより、コスト最適化の具体的な手法の提案（例：「EC2インスタンスi-xxxxxは過去30日間のCPU使用率が低いので、より小さなインスタンスタイプへの変更を検討してください」など）や、既存リソースの構成に基づいた新機能の実装方法など、システム構築や運用における具体的な課題に対して、より実践的なAI活用が可能です。
組織インスタンスを利用することで、IIC経由で適切な認証情報を取得でき、Q Developerの機能をフル活用できます。（アカウントインスタンスの場合、権限セットが使えないためAWS認証情報を取得できません。）
実際、AWSも組織インスタンスの利用を推奨しており、AWS公式ドキュメントにもその旨が記載されています。
We recommend that you deploy an organization instance rather than account instances to minimize the number of management points.
一方、アカウントインスタンスでは一部の機能（マネジメントコンソール上でのQ Developerなど）が利用できず、組織レベルでの管理機能が限定的になってしまいます。
そのため、組織的な制約やリセラー・CCoEからの利用制限がない限り、組織インスタンスを選択すべきです。
導入時のTips
マネジメントコンソール上でQ DeveloperでPro Tierを利用する方法
ここまでIDE統合版とCLI版のQ Developerの話を中心にしてきましたが、マネジメントコンソール上でも手軽にQ Developerを使うことが出来ます。
マネジメントコンソール上のQ DeveloperはデフォルトではFree Tierに自動設定されますが、以下の条件を全て満たすことでPro Tierで利用することが出来ます。
- 組織インスタンスのIICユーザでマネジメントコンソールにログインすること
- IICの組織インスタンスで「ID強化セッション」を有効化（抜けがちな設定）
- Q Developerへのユーザ登録が完了していること（サブスクリプションの有効化）
- 管理アカウント上でQ Developerプロファイルの組織共用を有効化（メンバーアカウント利用時）
特に2番と4番の設定は見落としがちです。ID強化セッションはデフォルトで無効になっており、明示的に有効化する必要があります。
ID強化セッションは名前からは想像しにくいですが、簡単に言うと「Q DeveloperがIIC経由でアクセスしたユーザーを正しく認識できるようにする仕組み」です。この機能を有効化することで、マネジメントコンソール上でIICユーザーがQ DeveloperのPro Tierを利用でき、過去のチャット履歴にアクセスしたり、過去の会話から再開したりできるようになります。（あくまでマネジメントコンソール上のQが対象です）
ID強化セッションの詳細については、以下のAWS公式ブログでも解説されています。
https://aws.amazon.com/jp/blogs/devops/implementing-identity-aware-sessions-with-amazon-q-developer/
4番の設定では、管理アカウントで作成したQ Developerプロファイルをメンバーアカウントに共有することで、IICユーザーがメンバーアカウントにログインした際にも、マネジメントコンソール上でQ DeveloperをPro Tierで利用できるようになります。
Q DeveloperへのIICユーザー紐づけ（サブスクリプション有効化）で時間がかかる場合の対処法
Q DeveloperにIICユーザーを紐づける際、ステータスが「保留中」になるケースがあります。マネジメントコンソール上にも「ユーザーがサブスクリプションに正常にアクセスできるようになるまでに最大24時間かかることがあります」と表示されます。
実際の検証では約2時間でアクティブになりましたが、保留中の状態が続く場合でも、Q Developer CLIでユーザーログインを実行することで即座にアクティブ化できます。この方法を使えば、24時間待つ必要がありません。
さいごに
Q Developer Pro Tierは月額19USD/ユーザとコストはかかりますが、統制面の安心感とIICとの連携により、組織レベルでの安全なAI活用を実現できます。管理アカウントのIICが使えない場合でも、メンバーアカウント内に完結するアカウントインスタンスを利用した形から始められるため、組織の制約に関係なく導入を進められるはずです。この記事が皆さんの組織でのQ Developer導入の参考になれば幸いです。