はじめに
こんにちは、インシュアランス本部の黒木です。
昨今、生成AIの技術が急速に発展し、開発現場でもさまざまなAIツールが活用されるようになってきました。当社でも業務効率化や生産性向上を目的に、複数のAIサービスを導入・検証しています。そんな中、Amazon Q Developerというサービスを知りました。実際に業務で使えるか検証してみることにしました。
「AWSのサービスだし、ポチッと有効化すればすぐ使えるだろう」 当初はそう軽く考えていました。しかし、実際に使い始めるまでには想像以上のハードルがありました。
この記事では、機能の素晴らしさではなく、企業内で検証を開始するまでの過程で直面した「社内ポリシー」「費用管理（請求）」「権限設定」という3つのリアルな壁と、その乗り越え方を共有します。これから企業で導入を検討されている方の道しるべになれば幸いです。
Amazon Q Developerとは
Amazon Q Developerは、AWSが提供する開発者向けのAIアシスタントサービスです。コード補完やコードレビュー、技術的な質問への回答など、開発業務を幅広くサポートしてくれます。
無料版か有料版か
Amazon Q Developerには無料版と有料版（Pro）があります。 個人の実験なら無料版で十分ですが、企業での利用となると話は別です。
- 学習データへの利用: 入力したコードが学習に使われないか？
- セキュリティ: 通信やログの管理はどうなっているか？
これら企業としてのガバナンス要件を満たすためには、管理機能が充実しているPro版が良さそうだと判断しました。
Pro版導入に立ちはだかる「3つの壁」
意気揚々とPro版の導入を進めようとしましたが、そこで3つの壁に直面しました。
第1の壁：社内申請とIdentity Centerの準備
まず最初に直面したのが、社内のAI利用に関する許可申請です。当然ながら、AIサービスにコードを送信することは情報漏洩のリスクを伴います。 JMDCにはセキュリティチェックを担当する専門部署が存在し、新しいツールを導入する際にはリスク評価や安全な設定について「安全に利用できるか」という観点でチェックをしていただいてから検証ステップに進むことになります。
Pro版を有効にするユーザーを管理するためには、AWS IAM Identity Center（以下、IIC）が必要ですが、 今回は機能検証を目的とした導入のため、会社全体ではなく特定のAWSアカウント内でのみ有効化する「アカウントインスタンス」を採用することにしました。
参考：IAM アイデンティティセンターを使用した開始方法 https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/getting-started-idc.html
しかし、IICの作成には通常の権限では不十分で、権限の緩和申請が必要になります。情報システム部門に相談し、協力を得ながらこれらの準備を進めることになりました。 （詳細な権限設定については、AWSドキュメントのIAM Identity Center前提条件をご参照ください。）
第2の壁：料金負担（請求先）の問題
やっと機能の有効化について目途が立ち、いざ開始！というところで社内処理上の懸念が浮上します。「Pro版の請求はどこにいくのか」という懸念です。 Amazon Q Developerはユーザー単位で有効化される機能です。もし、組織インスタンスのIICで有効化すると、組織管理側へ請求が行ってしまう可能性があります。事前に部内での予算確保は実施済みでしたが、組織管理側へ請求が行ってしまうと通常の処理フローでは部としての予算で処理できず、社内の決裁ルートが複雑になり他部署へも余計な負担をかけてしまうことになります。 調査の結果、アカウントインスタンスIICを作成してその中で有効化すれば、そのアカウントが属する組織への請求にできることが判明します。機能検証の影響範囲を限定的にするために採用したアカウントインスタンスIICでしたが、予算管理上もスムーズに処理できるという思わぬメリットもありました。
第3の壁：有効化したのにメニューが出ない（SCPの罠）
必要な準備を整え、ようやくPro版を有効化できました。「これでやっと使える！」と思った矢先、ここで最後の壁が立ちはだかりました。Proユーザーの追加ができないのです。 本来であればAmazon Q Developerのコンソール画面上でユーザーごとのサブスクリプションの管理やダッシュボードによる状況の確認ができるのですが、各メニューが表示されません。
AWSのサポートへの問い合わせも行いながら調査してみると、AWS Organizationsのサービスコントロールポリシー（SCP）レベルでの権限設定も必要だということが判明しました。
組織全体のガバナンスとして、認可されていないサービスやアクションへのアクセスがSCPによって制限されていたため、Amazon Q Developerに関連する操作権限（q:* や organizations:Describe* 関連など）が不足していたようです。
再度、情報システム部門に相談して権限の調整を行ってもらい、ようやくチームメンバーをProユーザーとして追加できるようになりました。
まとめと感想
Amazon Q Developer Pro版を使い始めるまでには、技術的な設定だけでなく、社内の承認プロセスや権限管理など、多くのステップが必要でした。 セキュリティや情報ガバナンスを維持しながら、新しい技術を検証・導入するのは簡単ではありません。しかし、これらのプロセスは決して無駄ではなく、安全に新技術を活用するために必要なステップだと実感しました。 今回の導入プロセスでは、セキュリティ部門や情報システム部門の協力が不可欠でした。技術的な相談に快く応じてくれ、スムーズに進められたことに感謝しています。 新しい技術を試したいエンジニアと、安全なAI利用を促進しているセキュリティ部門。両者が協力することで、安全かつ効率的に新技術を導入できます。Amazon Q Developerの導入を通じて、改めてそのことを実感しました。 これから導入を検討している方の参考になれば幸いです。
最後までお読みいただきありがとうございました。
JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！フロントエンド / バックエンド / データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co
まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co
★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！
