この記事の結論
鍵が作れない原因は、2024年5月3日以降の組織に既定でかかる組織ポリシー。鍵を使わない借用方式か、1プロジェクトだけの例外で直せます。GA4をAIにつなぎ、借用で約2か月半回してから鍵に移した当社の記録つき。
目次7項目
【実践講座】Claude Code 2daysセミナー（第二の脳構築講座）の詳細を見る →
サービスアカウントの鍵が作れないのは、iam.disableServiceAccountKeyCreation という組織ポリシーが効いているためです。2024年5月3日以降に作られた組織では既定でオンです。まず鍵を作らない「借用」方式に切り替え、どうしても鍵が要るときだけ、そのプロジェクト1つに例外を作ります。
iam.disableServiceAccountKeyCreation とは？鍵の作成が止まる原因
iam.disableServiceAccountKeyCreation とは、Google Cloud の組織ポリシーの1つで、サービスアカウントの外部の鍵（JSON の鍵ファイルなど）を新しく作る操作を禁止する制約です。公式ドキュメントによると、2024年5月3日以降に作られた組織では、この制約が既定で有効になっています。何も設定していないのに鍵が作れないのは、このためです。
用語を2つ押さえておきます。サービスアカウントとは、人ではなくプログラムが Google のサービスを使うときの専用アカウントです。組織ポリシーとは、組織の管理者が組織全体やフォルダ・プロジェクトに「この操作は禁止」と決めておく仕組みで、親（組織）で決めた内容は下（プロジェクト）に引き継がれます。
公式ドキュメントには、この制約で止まったときのエラーとして次の文が載っています。
FAILED_PRECONDITION: Key creation is not allowed on this service account.
画面から鍵を作ろうとした場合も、コマンドで作ろうとした場合も、原因は同じです。原因として多い順に並べると、次のようになります。
| 状況 | 原因 | 向いている対処 |
|---|---|---|
| 2024年5月3日以降に作った組織で、初めて鍵を作ろうとした | 制約が既定で有効（いちばん多い） | 借用方式に切り替える／1プロジェクトだけ例外 |
| 組織の管理者が明示的に制約をオンにしている | 会社のセキュリティ方針 | 借用方式。例外は管理者と相談 |
| 管理された版の制約がオンになっている | iam.managed.disableServiceAccountKeyCreation（同じ働き） | 上と同じ |
なお、この制約はさかのぼって効きません。すでに作ってある鍵はそのまま使えます。止まるのは新しく作る操作だけです。
鍵を作らずに済ませる対処手順（サービスアカウントの借用）
鍵が作れないなら、鍵を使わない方法に切り替えるのが最初の選択肢です。サービスアカウントの借用（impersonation）とは、自分のGoogleアカウントのログイン情報を出発点に、サービスアカウントの短期間だけ有効なトークンをその都度発行してもらう方式です。鍵ファイルが存在しないので、漏れる鍵もありません。
GA4 の公式 MCP サーバー（AI から GA4 のデータを読むためのプログラム）を例に、手順を書きます。
- プロジェクトで3つの API を有効にする。 GA4 用に Google Analytics Admin API と Google Analytics Data API、借用用に Service Account Credentials API（
iamcredentials.googleapis.com）です。 - サービスアカウントを作る。 ロールは空欄で構いません。GA4 の権限は GA4 側で付けます。
- 自分のアカウントに「トークン作成者」のロールを付ける。 対象のサービスアカウントに対して、
roles/iam.serviceAccountTokenCreatorを自分（借用する人）へ付与します。 - GA4 の管理画面で、サービスアカウントのメールアドレスを閲覧者として追加する。 当社はプロパティ単位ではなくアカウント単位で付けています（案件が増えても付け直さずに済むため）。
- 借用つきのログイン情報ファイルを作る。 GA4 の MCP サーバーの説明にあるとおり、次のコマンドを実行します。
SERVICE_ACCOUNT_EMAILはsa-name@my-project.iam.gserviceaccount.comのような自分のサービスアカウントに置き換えます。
gcloud auth application-default login \
--impersonate-service-account=SERVICE_ACCOUNT_EMAIL \
--scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform- 表示された保存先のパスを MCP サーバーの設定に入れる。 環境変数
GOOGLE_APPLICATION_CREDENTIALSにそのパスを指定し、AI のアプリを再起動して、プロパティの一覧が取れるか確かめます。
プロジェクト1つだけ鍵の作成を許可する対処手順（組織ポリシーの例外）
借用方式は、出発点である自分のログインが切れると止まります。無人で動かし続けたい用途では、鍵の方が向くこともあります。そのときは組織全体の設定は残したまま、対象のプロジェクト1つだけ制約を外します。
- 権限を確かめる。 公式ドキュメントでは、組織ポリシー管理者のロール（
roles/orgpolicy.policyAdmin）を組織に対して持っている必要があります。 - 今の設定を確かめる。
gcloud org-policies describe iam.disableServiceAccountKeyCreation --effective --project=my-projectで、制約が効いていることを見ます。 - 例外の設定ファイルを作る。 次の内容で YAML ファイルを用意します。
name: projects/my-project/policies/iam.disableServiceAccountKeyCreation
spec:
rules:
- enforce: false- 適用する。
gcloud org-policies set-policy <作ったファイル>を実行し、もう一度手順2のコマンドで外れたことを確かめます。公式ドキュメントによると、組織ポリシーの変更が行き渡るまで最大15分かかります。 - IAM API を有効にして鍵を作る。 鍵の作成には IAM API の有効化と、サービスアカウント鍵管理者のロール（
roles/iam.serviceAccountKeyAdmin）が要ります。コマンドはgcloud iam service-accounts keys create <保存先> --iam-account=sa-name@my-project.iam.gserviceaccount.comです。鍵ファイルはこのとき一度しかダウンロードできません。 - すぐに使わず、少し待つ。 公式ドキュメントは、作った鍵を使う前に60秒以上待つ必要がある場合があるとしています。
GA4をAIにつないだとき実際に起きたこと（借用→鍵方式へ）
僕の会社では、GA4 の公式 MCP サーバーで、自社サイトと案件の LP を合わせた7つのプロパティを会話で分析しています。この接続で、この制約に正面から当たりました。経緯は社内の作業記録から転記します。
| 日付（2026年） | 起きたこと | どうしたか |
|---|---|---|
| 7月13日 | 自分のログイン情報（ADC）で動かしていた接続が失効。ログインし直すと 403 SERVICE_DISABLED | 鍵ファイル方式へ移す準備をした |
| 7月17日 | 鍵の作成が iam.disableServiceAccountKeyCreation で止まると判明 | 制約は外さず、借用方式に切り替え。Service Account Credentials API を有効にし、自分にトークン作成者を付与。権限の反映に約30秒。同日14時に接続を確認 |
| 7月28日 | ログインし直した後も、MCP サーバーが古い認証を持ったまま失敗し続けた | 再起動するまでの間は、API を直接呼ぶ手順で代わりに取得 |
| 8月中旬・8月26日 | 自分のログインが切れるたびに GA4 の取得が止まった | 「ずっとつながる状態に」という方針で、恒久策を検討 |
| 10月4日 | Google Workspace の再認証の設定で、借用方式が invalid_rapt で定期的に切れ、検索データの自動処理も止まった | 分析専用のプロジェクト1つだけ例外を作り、鍵方式に切り替え |
7月の時点では「鍵は使わない」と決めていました。鍵ファイルが無いぶん漏えいの心配がなく、既定で鍵を止めている Google の設定にも逆らわずに済んだからです。ただ、借用方式は出発点が人のログインなので、そのログインが切れると無人の定期処理まで止まります。借用に切り替えてから鍵に移すまでの約2か月半で、8月中旬・8月26日と同じ止まり方を繰り返しました（7月13日の失効も、出発点が人のログインだった点は同じです）。
最終的に選んだのは「組織全体の既定は残し、分析専用のプロジェクト1つだけ例外にする」形です。鍵を持つサービスアカウントは GA4 の閲覧しかできません。切り替えの日には、つまずきが2つありました。1つは IAM API が有効になっていなくて鍵が作れなかったこと。もう1つは、作った直後の1〜2分は Invalid JWT Signature で認証に失敗したことです。どちらも、時間を置くかAPIを有効にすれば直りました。
検討して採らなかった案も残しておきます。Workspace のログインの有効期間を延ばす案は、失効の周期が設定と合わず原因として確かではないうえ、全社のセキュリティ設定に触るので見送りました。組織の外に別のプロジェクトを作る案は、GA4 の権限を付け直す必要があり、個人のアカウントに頼る形が残るため見送りました。
鍵が作れない・認証が切れるを繰り返さない再発防止
当社で決めたルールは次の4つです。
- 方式は「誰が動かすか」で選ぶ。 人がその場で使うだけなら借用方式、無人の定期処理で止まると困るなら、例外を1プロジェクトに絞った鍵方式にします。
- 例外は分析専用のプロジェクト1つだけ。 ほかのプロジェクトは制約を有効のままにします。新しい用途で鍵が欲しくなっても、同じプロジェクトに相乗りさせず、まず借用で済まないかを考えます。
- 借用方式でログインし直したら、認証ファイルを作り直してから MCP サーバーを再起動する。 ファイルの中に古いログイン情報が残ったり、サーバーがプロセスの中に古い認証を持ち続けたりするためです。このとき出るエラーの意味と直し方はGA4 MCPの「503 Reauthentication is needed」の原因と直し方に書きました。
- 切り替えの後は、実際に1回データを取って確かめる。 「設定した」と「取れた」は別です。当社では、プロパティの一覧が返ってくるまでを完了の条件にしています。
AI と業務ツールをつなぐ仕組みそのものはMCPとは（AIと業務ツールをつなぐ仕組みと実例）で、AI 側で起きたエラーの切り分けはClaude Codeのエラー・困りごと一覧でまとめています。
業務で鍵の例外を作るときの注意（権限・保管・チーム運用）
この制約は、鍵が漏れる事故を防ぐために既定でオンになっています。外すときは、外した理由と範囲を説明できる形にしておきます。
1. 鍵に付ける権限は最小にする。 当社の鍵は GA4 の閲覧しかできないサービスアカウントのものです。編集や管理の権限を持つアカウントの鍵は作りません。
2. 鍵ファイルは決まった場所に置き、共有しない。 当社では、鍵は1台の Mac の決まったフォルダだけに置き、持ち主以外は読めない設定にして、Git の管理から外しています。チャットやメール、共有ドライブには貼りません。古い認証ファイルは控えとして残し、戻せるようにしました。
3. 漏れたときの動きを決めておく。 公式ドキュメントは、鍵の漏えいを Google Cloud が見つけたときの動きを決める制約 iam.serviceAccountKeyExposureResponse で、DISABLE_KEY（鍵を無効にする）を選ぶことを強く勧めています。鍵の有効期限を決める制約もありますが、期限切れで本番が止まることがあると注意書きがあります。
4. チームでは、例外の記録を残す。 どのプロジェクトで、いつ、誰の判断で例外にしたのかを書いておきます。担当が替わったときに「なぜここだけ鍵があるのか」が分からなくなると、外すべき例外が残り続けます。
GA4 や広告の数字を AI に読ませる仕組みを、自社の業務に合わせて組みたい場合は、下のセミナーで具体的な作り方をお伝えしています。
よくある質問
この制約がかかると、今ある鍵も使えなくなりますか？
使えなくなりません。公式ドキュメントでは、これらの制約はさかのぼって効かず、すでに作って設定してあるサービスアカウントには影響しないと説明されています。制約が止めるのは新しく鍵を作る操作なので、今ある鍵はそのまま使えます。
組織ポリシーの例外を作る権限が自分にない場合は？
鍵を使わない「借用」方式で進めるのが早道です。例外の設定には組織に対する組織ポリシー管理者のロールが要りますが、借用ならサービスアカウントへのトークン作成者ロールと、APIの有効化だけで済みます。例外がどうしても必要なら、組織の管理者に依頼します。
借用方式なのに、ときどき接続が切れるのはなぜですか？
借用の出発点が、あなた自身のGoogleのログイン情報だからです。当社では、そのログインが切れるたびにGA4の取得が止まりました。ログインし直した後は、認証ファイルを作り直し、AIのMCPサーバーも再起動しないと古い認証を使い続けます。