1. はじめに AIコーディングエージェントを組織で利用する場合、単に利用環境を提供するだけでなく、次のような情報も把握したくなります。 どのモデルが、どの程度利用されているか トークンやコストがどれくらい発生しているか ユーザーや部門ごとの利用状況に偏りがないか コード編集やGitコミットなどの開発作業につながっているか 2026年7月20日、AWS（Amazon Web Services）がAmazon CloudWatchにCoding Agent Insightsを追加したことを発表しました。 https://aws.amazon.com/jp/about-aws/wha

はじめに こんにちは。サイバーエージェント AIオペレーション室の李俊浩（@buddypia）です。 ...

G-gen の菊池です。Gemini Enterprise Agent Platform（旧称 Vertex AI）の画面で「API キーの取得」を行う際に発生するエラーの原因と、その推奨される対処法について解説します。 事象 原因 原因となる組織ポリシー サービスアカウントにバインドされた API キーとは API キーは何のために必要なのか デフォルトで作成が制限されている理由 対処の手法 2つの対処法 組織ポリシーを修正して API キーを発行する（非推奨） アプリケーションのデフォルト認証情報（ADC）を使用する（推奨） 対処の手順（ADC） 前提条件の確認 Google Cloud CLI のインストール Google Cloud CLI の初期化 ローカル認証情報の作成 ADC 構成後のプログラムへの影響 本番環境では 事象 Google Cloud コンソールにおける Gemini Enterprise Agent Platform （旧称 Vertex AI、以下 Agent Platform）の画面左側メニューに存在する「API キーを取得」ボタン、または Agent Studio の画面で「API キーの取得」ボタンを押下しました。 APIキー取得ボタン すると「組織ポリシーで API キーが許可されていない」という旨のエラーメッセージが表示され、API キーが作成できませんでした。当記事では、このエラーの原因と適切な対処法を解説します。 エラー内容 API キーは許可されていません 組織のセキュリティ ポリシーで API キーが許可されていません。代わりにアプリケーションのデフォルト認証情報（ADC）を使用してください。 原因 原因となる組織ポリシー 以前は、以下のようなメッセージが画面に表示されました。 API キーの権限に関する問題 現在、API キーを作成する権限がありません。 API キーの作成を有効にする 組織のポリシーページにアクセスし、iam.managed.disableServiceAccountApiKeyCreation ポリシーが適用されないようにオーバーライドします。 または、組織の管理にポリシーのオーバーライドをしてください。 このエラーメッセージの通り原因は、 iam.managed.disableServiceAccountApiKeyCreation （サービスアカウントにバインドされた API キーの作成を無効にする）という組織ポリシーによって、API キーの作成がブロックされていることにあります。 参考 : サービス アカウントにバインドされた API キーの作成を無効にする サービスアカウントにバインドされた API キーとは この画面で発行可能な API キーは、正式には サービスアカウントにバインドされた API キー と呼ばれるものです。 Google Cloud におけるサービスアカウントにバインドされた API キーとは、API リクエストに対して特定のサービスアカウントの ID と認可情報を提供する仕組みです。 具体的には、ユーザーが自身のプログラムやシステム（Python や Node.js など）から、Gemini API などの機能を呼び出して使用する際の「パスワード」のような役割を果たします。 この API キーを使用すると、対象のサービスアカウントが直接 API リクエストを行った場合と同様の権限で処理が実行されます。 この「サービスアカウントの権限をそのまま持ってしまう」という強力な特性が、後述する「API キーの作成が制限されている理由」に直結しています。 参考 : サービス アカウントにバインドされた API キー API キーは何のために必要なのか Agent Platform や Agent Studio のコンソール画面上で、プロンプトの作成やテストを実行するだけであれば、API キーは不要です。 コンソール画面での操作は、現在ログインしているユーザー（Google アカウント）の権限を使用して自動的に認証および認可が行われます。画面操作のみを目的としている場合、API キーが取得できなくても作業に支障はありません。 一方で API キーが必要となるのは、プログラムからの呼び出しを行う場合です。 たとえば、Python、Node.js、REST API などのプログラムコードから、自社のシステムや外部の Web アプリケーションに Gemini の機能を組み込んで呼び出す際、認証のための「パスワード」として何らかの認証情報が必要です。 API キーは画面操作のためではなく、このような Google Gen AI SDK や外部プログラムから API リクエストを送信する際の、明示的な認証手段の一つとして存在しています。 しかし、前述の通り API キーの使用には漏洩リスクが伴うため、Google Cloud では API キーに代わるより安全な推奨の認証手段を用意しています。次のセクションでは、その具体的な方法について解説します。 参考 : Gemini Enterprise Agent Platform を使ってみる 参考 : Google Cloud API キーを取得する デフォルトで作成が制限されている理由 Google Cloud ではセキュリティ強化の観点から、この API キーの作成を制限する組織ポリシーがデフォルトで適用されています。 サービスアカウントにバインドされた API キーは、漏洩した際のセキュリティリスクが非常に高いためです。 API キーはテキスト情報です。プログラムのソースコード内に直接書き込まれ（ハードコードされる）たり、誤って GitHub などの公開リポジトリにアップロードされたりすることによる漏洩事故が発生する可能性があります。 前述の通り、この API キーはサービスアカウントの権限をそのまま持っているため、万が一キーが外部に漏洩すると、第三者がその権限を悪用して、意図しないリソースの操作やデータへのアクセスを行う可能性があります。 このような重大なセキュリティ事故を未然に防ぐため、Google Cloud ではデフォルトでキーの発行をブロックする設定としており、開発環境や本番環境においては、後述するより安全な認証方法である ADC の使用を強く推奨しています。 参考 : サービス アカウントにバインドされた API キーを本番環境で使用しない 対処の手法 2つの対処法 当事象に対しては、以下の2種類のいずれかの対処法が考えられます。 組織ポリシーを修正して API キーを発行する（非推奨） アプリケーションのデフォルト認証情報（ADC）を使用する（推奨） 組織ポリシーを修正して API キーを発行する（非推奨） 当初に発生したエラーを回避するために、組織ポリシー iam.managed.disableServiceAccountApiKeyCreation を変更し、API キーの発行を許可することができます。しかし、この方法はセキュリティの観点から非推奨とされていることに留意してください。 それを理解したうえでこの手法を採用する場合、以下の記事を参照し、対処手順の組織ポリシー名を置き換えて実施してください。 blog.g-gen.co.jp この手法は設定が容易である反面、前述の通り高い漏洩リスクを伴います。特に、クライアントサイドのアプリケーション（モバイルアプリやウェブアプリなど）から直接 API を呼び出すような構成では、キーが第三者に公開されてしまうリスクがあります。 この手法を採用する場合、API キーはソースコードに直接記述するのではなく、Google Cloud や Amazon Web Services（AWS）の Secret Manager など、何らかのシークレット管理機構と併用することを検討してください。 アプリケーションのデフォルト認証情報（ADC）を使用する（推奨） API キーのハードコードによる漏洩リスクを避け、本番環境でも安全に使用できる アプリケーションのデフォルト認証情報 （Application Default Credentials、以下 ADC ）が Google Cloud が公式に推奨する手法です。ADC はアプリケーションが実行されている環境に基づいて、認証情報を自動的に検索・取得します。 ADC の認証情報は、コードを実行する環境によってそれぞれ異なる方法で設定します。例えば、Cloud Run のようなサーバーレスプラットフォームや、Compute Engine の VM などに サービスアカウント をアタッチすることで、ADC は自動的にサービスアカウントから認証情報を取得し、キー不要で API を実行できます。 この仕組みにより、コード内にパスワードや API キーを直接記述（ハードコード）する必要がなくなるほか、そもそもキーの発行が不要なので、漏洩のおそれはありません。 また ADC は、自身の Google アカウントの認証情報を使い、ローカル PC 上でも使用できます。 参考 : アプリケーションのデフォルト認証情報の仕組み 参考 : アプリケーションのデフォルト認証情報を設定する 対処の手順（ADC） 前提条件の確認 ADC を設定する方法は、コードを実行する環境によって異なります。ここでは、ローカル環境（PC 等）でコードを実行し、Google Cloud の API を呼び出す場合の設定手順を解説します。 ADC を使用する前に、前提条件として課金の有効化および Agent Platform API の有効化が完了していることを確認します。 そして、Web ブラウザ上で Google アカウントにログインした上で、以降の作業を実施します。 参考 : Gemini Enterprise Agent Platform を使ってみる Google Cloud CLI のインストール 使用するローカル環境（PC 等）に Google Cloud CLI をインストールします。インストール手順は、使用する OS に合わせて公式ドキュメントを参照してください。 参考 : gcloud CLI のインストール Google Cloud CLI の初期化 ターミナルなどのコマンドラインツールを開き、以下のコマンドを実行して Google Cloud CLI の初期設定を行います。 gcloud init 画面の指示に従って、認証を行うアカウントと対象のプロジェクトを選択します。 ローカル認証情報の作成 初期化が完了したら、以下のコマンドを実行してユーザーアカウントのローカル認証情報を作成します。このコマンドが、ローカル環境で ADC を設定するコマンドです。 gcloud auth application-default login コマンドを実行するとブラウザが起動し、Google アカウントでの認証が求められます。認証が成功すると、ローカル環境に ADC 用の認証情報ファイルが生成され、プログラムから Google Cloud の API を安全に呼び出せるようになります。 なお、Google Cloud コンソールに付属する Cloud Shell を使用している場合、ADC はあらかじめ構成されているため、このコマンドを実行する操作は不要です。 ADC 構成後のプログラムへの影響 ADC が正しく構成されていれば、プログラムのソースコード内に API キーを記述する必要はありません。 Google Gen AI SDK などを使用する場合、プログラムにクライアントの初期化処理（Python の vertexai.init() など）を記述するだけで、ライブラリが実行環境を自動判別し、適切な ADC 認証情報を適用して安全に認証を行います。 本番環境では 上記では、ローカル PC の開発環境で ADC を設定する方法を説明しました。一方、Cloud Run や Google Kubernetes Engine などのクラウドコンピューティングリソース上で稼働する本番プリケーションの場合、そのクラウドリソースに関連付けられたサービスアカウントの権限が自動的に取得されますので、コマンドの実行は不要です。 Google Cloud プロジェクトでサービスアカウントを作成し、適切な IAM 権限を付与したうえで、そのサービスアカウントを Cloud Run サービスなどに紐づけるだけで、ADC が使用できます。 もしアプリケーションが Amazon Web Services（AWS）の Amazon EC2 インスタンスや、AWS Lambda の関数上で動いている場合でも、AWS の IAM ロールと Google Cloud の IAM を紐づける Workload Identity の仕組みを使うことで、ADC を使用できます。 参考 : Workload Identity 連携 それぞれの環境に合わせた方法で ADC の前提設定をしておけば、ソースコードを変更することなく、ローカル環境からクラウド上の本番環境へとシームレスにアプリケーションを移行し、動作させることができます。 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。