サービスアカウントキーの作成無効｜鍵なしが無理な時だけ外す

「サービス アカウント キーの作成が無効になっています」と出て止まった自動化は、保護設定を外す前に鍵を使わない方法で動かせるかを確かめるのが先です。鍵なしで無理な時だけプロジェクト単位で例外にし、鍵で使える権限を処理に要る分だけに絞ります。外注先や社内の開発担当から外すよう頼まれた管理者にも、同じ順番が当てはまります。外し方の手順は公式の文書にありますが、足りないのは鍵なしで済むかを確かめる順番と、外すときに引き換えにするものの線引きです。処理の動く場所から鍵を使わない方法を選ぶ基準と鍵を作るなら範囲を絞る条件を、当社が2026年9月に鍵の作成を同じ保護設定で止められたときに比べた二つの案とあわせて示します。

外部の記述は Google Cloud と Firebase の公式ドキュメントを2026年10月22日に読んだ範囲に限り、画面の文言や設定の名前はその後に変わることがあります。公式の日本語表記は「サービス アカウント キー」と語の間に空白が入るため、本文では検索で使われる「サービスアカウントキー」と書き、画面とドキュメントの文言を引くときだけ公式の表記にします。当社の記録は2026年9月の1件で、外すかどうかの結論ではなく、外す前に比べた二つの案までを書きます。

「サービスアカウントキーの作成が無効になっています」は、組織のポリシーの保護設定が鍵の作成を止めているという表示である

「サービスアカウントキーの作成が無効になっています」とは、Google Cloud の組織のポリシー（2024年5月3日以降に作られた組織では初期設定で有効）にある保護設定が、サービスアカウントキーの作成を止めていることを示す表示です。サービスアカウントキーは、人ではなくプログラムが使うアカウント（サービスアカウント）として Google の API に認証するための鍵で、Google は利用者が管理する鍵ペアの秘密鍵と定義しています（Google Cloud「サービス アカウント認証情報」／2026年10月22日閲覧）。

鍵の作成が止められると、コンソールには「サービス アカウント キーの作成が無効になっています」という見出しのダイアログが出ます。ダイアログの本文は、サービスアカウントキーの作成をブロックする組織ポリシーが組織に適用されている、という趣旨です。コマンドライン（gcloud）や REST API から作ろうとした場合は、FAILED_PRECONDITION の状態で「Key creation is not allowed on this service account.」というエラーが返ります（Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」／2026年10月22日閲覧）。画面でもコマンドでも、止めているのは同じ保護設定です。

この保護設定は、社内の誰かが後から入れたものとは限りません。2024年5月3日以降に作成された組織には、鍵の作成を止める制約が初期設定で適用されています（Google Cloud「サービス アカウント キーの作成と削除」／2026年10月22日閲覧）。それより前に作られた組織でも、この制約が適用されていれば組織内のどのサービスアカウントにも鍵は作れません（Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」／2026年10月22日閲覧）。Google はこれを、組織リソースを作るときに自動で適用される組織のポリシーの束（セキュリティ ベースライン）に含めていて、鍵のアップロードの無効化と並べて例に挙げています（Google Cloud「Google Cloud セキュリティ ベースラインの制約」／2026年10月22日閲覧）。設定を変えた覚えが誰にも無いのに表示が出るのは、多くの場合このためです。

外すかどうかの分かれ道を、次の図にまとめました。上から順に鍵なしで済むかを確かめ、済まない場合だけ範囲を絞って例外にする流れです。

図の分かれ目は、エラーの種類ではなく処理の動く場所です。同じ表示が出ても、手元の端末で動かす集計と、営業時間中に社外のサーバーで問い合わせを取り込む処理では選ぶ方法が変わります。

サービスアカウントキーの代わりは、処理の動く場所で権限借用・ワークロード ID 連携・リソースに付けたアカウントから選ぶ

組織のポリシーで鍵が作れないとき、Google がまず勧めているのは鍵が本当に必要かを確かめることです。ほとんどの場合は、鍵より安全な別の方法で認証するべきだとしています（Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」／2026年10月22日閲覧）。代わり（代替）の方法をどれにするかは、Google の「ユースケースに適した認証方法を選択する」が質問に順に答える図で示しています。自分の端末で開発するならユーザーの認証情報か権限借用、Google Cloud の上で動くならリソースにサービスアカウントを付ける方法が結論です。外部で動くならワークロード ID 連携になります（Google Cloud「Google での認証方法」／2026年10月22日閲覧）。

中小規模の自動化に当てはめると、次の表になります。前提と向かない場面の列は、公式の記述をもとに当社が整理したものです。

表は横にスクロールできます。

自分の端末から動かすなら、権限借用で鍵を持たずに済む

権限借用とは、ログイン済みのユーザーなどがサービスアカウントとして認証し、その権限を使うことです。借用する人には、サービスアカウントのトークンを作る権限が要ります。借用で得る短期の認証情報は有効な時間が数時間程度に限られ、自動では更新されないため、サービスアカウントキーのような長期の認証情報よりリスクが低いとされています（Google Cloud「サービス アカウントの権限借用」／2026年10月22日閲覧）。

手元で動かす集計や、API を試しに呼んでみる段階なら、まずこの方法を検討します。サービスアカウントを使う理由が特に無ければ、Google の図のとおり自分のアカウントの認証情報で済ませる道もあります（Google Cloud「Google での認証方法」／2026年10月22日閲覧）。どちらも鍵のファイルが手元に残らないので、保管と入れ替えの心配がそもそも生まれません。

Google Cloud の上で動くなら、処理を動かすリソースにサービスアカウントを付ける

処理そのものを Google Cloud の上に置くなら、処理を動かすリソースにサービスアカウントを付ければ鍵のファイルは要りません（Google Cloud「Google での認証方法」／2026年10月22日閲覧）。夜間に表計算へ売上を書き込む処理のように人の操作なしで動かしたいものは、手元の端末から Google Cloud の上へ移すことが鍵を持たないための選択肢になります。移す手間と鍵を持ち続ける手間のどちらが軽いかは、処理の数と、入れ替えを続けられる人がいるかで変わります。

社内のサーバーや他社のクラウドで動くなら、ワークロード ID 連携を先に調べる

ワークロード ID 連携（公式名は Workload Identity 連携）は、社内のサーバーや他社のクラウドで動く処理に、鍵の代わりに外部の ID を使って Google Cloud へのアクセスを与える仕組みです。GitHub や GitLab のようなデプロイのサービス・AWS・Azure・OIDC や SAML 2.0 に対応した ID プロバイダで使えます（Google Cloud「Workload Identity 連携」／2026年10月22日閲覧）。

コードをデプロイのサービスで動かしている場合や、他社のクラウドに処理を置いている場合は、鍵を作る前にこの連携を調べます。Google の図でも外部で動く処理はこの連携を使う結論になっていて、鍵を作るのは外部の ID プロバイダが連携に対応していない場合に限られます（Google Cloud「Google での認証方法」／2026年10月22日閲覧）。

当社が比べたのは、鍵を使わない案と、範囲を絞って鍵を使う案だった

当社も2026年9月、Search Console の数字を自動で取る仕組みを作る途中で、鍵の作成だけがこの初期設定で止められました。検索の数字で改善を判定する運用は順位改善を1語ずつ観察した記録にまとめていて、その数字を取る作業を自動にしようとした場面です。外す前に確かめたのは、鍵なしで済むかどうかでした。

比べた案は二つです。一つ目は権限借用で、鍵を作らずに人のアカウントのログインから短期の認証情報を得る案です。二つ目はプロジェクト単位の例外で、そのプロジェクトでだけ鍵を作れるようにし、鍵で使える権限を検索の数字の閲覧だけに絞る案です。

二つの案を並べると、違いはそれぞれで何を手元に持つことになるかに出ます。自分の端末から使う権限借用では鍵を持たない代わりに、処理が人のログインに結び付きます。例外の案では人のログインから切り離せる代わりに、鍵の保管と入れ替えと、漏れたときに使える権限を自社で持つことになります。どちらが合うかは処理の置き場所と動かし方で変わるので、次の節からはこの二つを判断の基準として使います。

鍵なしにこだわるより、鍵を作って範囲を絞るほうが筋の通る場面もある

鍵を使わない方法は、どの処理にも同じ手間で入るわけではありません。自分の端末から使う権限借用は人のアカウントのログインを起点にするので、人が操作しない時間に動く処理ではログインの状態をどう保つかという別の管理が生まれます。ワークロード ID 連携は、処理の動く環境に連携に対応した ID の仕組みがあって初めて使えます（Google Cloud「Workload Identity 連携」／2026年10月22日閲覧）。

Google の図も、外部で動く処理の ID プロバイダが連携に対応していない場合は、サービスアカウントキーを作るという結論を残しています（Google Cloud「Google での認証方法」／2026年10月22日閲覧）。鍵の管理のベスト プラクティスも、新しい鍵の作成を組織のポリシーで禁止したうえで、より安全な方法が使えないと分かったプロジェクトにだけ例外を認める形を書いています（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）。鍵を作ること自体が誤りなのではなく、確かめずに作ることと範囲を絞らずに作ることが問題になります。

鍵を作るほうが筋が通るのは、処理の動く環境が次の三つにそろって当てはまるときです。

• 処理が人の操作なしに決まった時間に動く
• 処理を Google Cloud の上に置けない
• 処理の動く環境に、連携に対応した ID の仕組みが無い

一つでも当てはまらないなら、鍵を使わない方法がまだ残っています。たとえば社内の小さなサーバーで営業時間中に問い合わせを取り込む処理は、一つ目と二つ目には当てはまりやすい一方で、三つ目は環境によって分かれます。連携の仕組みを新しく用意する手間が処理一つの規模に見合わないと判断する場合もあり得ます。その判断をしても、一つのプロジェクトの中で権限を処理に要る最小限に絞ることと、入れ替えの日と入れ替える人を決めることは省けません。前者は次の節で、後者は入れ替えの節で書きます。

つなぐ相手のサービスから鍵のファイルしか受け付けないと言われた場合も、まず連携の方法が無いかを先方に聞きます。相手の都合に合わせて保護を外すのではなく、上の条件がそろうかで決めます。

鍵なしで無理な時だけプロジェクト単位で例外にし、漏れたときに使える権限を処理に要る分だけに絞る

制約を外す方法は二つあり、組織全体で適用をやめるか、プロジェクトだけを適用から除外するかです（Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」／2026年10月22日閲覧）。Google は、ほとんどのプロジェクトにこの制約を適用したままにし、鍵が本当に必要なプロジェクトだけを除外するよう勧めています。除外の仕組みはタグで、組織全体を「適用」にしたまま、除外したいプロジェクトかフォルダにだけ「適用しない」の値を付けてポリシーのルールで外します（Google Cloud「サービス アカウント キーの作成と削除」／2026年10月22日閲覧）。

組織全体で外すと、保護が外れるのは鍵を必要とするプロジェクトだけではなくなります。鍵が要るのが一つの処理だけなら、外す範囲もその処理のプロジェクトだけにとどめます。画面の操作は公式の文書に任せます。除外の単位は、鍵の作成と削除のページではプロジェクトかフォルダとされています（Google Cloud「サービス アカウント キーの作成と削除」／2026年10月22日閲覧）。トラブルシューティングのページは、除外するサービスアカウントごとにタグを付ける形で書いています（Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」／2026年10月22日閲覧）。

例外にしたプロジェクトでも、鍵が持つ権限は処理に要る最小限に絞ります。漏れたサービスアカウントキーは、漏れたパスワードより攻撃者にとって価値が高い場合があります。人のアカウントと違い、サービスアカウントには2段階認証のような追加のログイン確認がないためです（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）。人のアカウントでこの確認をどの順で有効にするかは、二段階認証の義務化対応の記事に書きました。

鍵を持つ人はサービスアカウントとして Google の API に認証できるので（Google Cloud「サービス アカウント認証情報」／2026年10月22日閲覧）、漏れたときに相手ができることはサービスアカウントに付けた権限で決まります。数字を読むだけの処理なら、閲覧だけの権限にしておけば漏れても相手ができることは読み取りまでに収まります。表計算へ書き込む処理のように書き込みが要る場合も、書き込める先をその処理の分だけに限ります。例外のプロジェクトに置くのも、その鍵を使う処理に要るものだけにします。

引き換えにするのは、鍵の保管と、漏れたときの範囲を自社で持つことです。保護設定が止めていた役目を、例外にした範囲だけは自社が引き受けることになります。AI エージェントに渡す権限の決め方は主題が別なので権限設計の記事に譲り、ここではクラウドの鍵に絞ります。

組織ポリシーを変えられる人が社内にいないなら、外す前にその役割を誰が持つかを決める

組織全体で制約を外すには、組織のレベルで組織ポリシー管理者のロールが必要です。このロールは組織にしか付与できず、プロジェクトのロール一覧には出てきません（Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」／2026年10月22日閲覧）。組織のポリシーの制約を変える権限は、プロジェクトのオーナーのロールにも編集者のロールにも含まれていません（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）。プロジェクトだけを除外する場合も、タグを使って除外するのは組織ポリシーの管理者です（Google Cloud「サービス アカウント キーの作成と削除」／2026年10月22日閲覧）。プロジェクトを任された外注先や社内の開発担当が自分では外せないのは、この作りのためです。

このロールを自分に付けてから外す、という流れ自体が権限の変更です。社内に専任の管理者がいない場合は、組織の管理者の権限を持つ人が自分にロールを付けて、そのまま外して作業を終えることもできてしまいます。外したあとにロールを誰が持ち続けるのか、次に例外を頼まれたら誰が判断するのかを決めずに進めると、例外を作った理由がどこにも残りません。

先に決めるのは、組織のポリシーを変えてよい人・例外を認めるかを判断する人・例外を作ったプロジェクトと理由を書き残す場所の三つです。小さな会社なら同じ人が兼ねてもよく、その場合も書き残す場所だけは決めておきます。

外注先から外すよう頼まれたら、どこで動く処理かから聞き返す

外注先から「組織のポリシーを外してほしい」と頼まれたときは、すぐに外さずに次を聞き返します。

• その処理はどこで動くか（自分の端末・Google Cloud の上・社内のサーバーや他社のクラウド）
• 鍵を使わない方法を検討したか、使えないならその理由は何か
• 鍵を作るのはどのプロジェクトで、その鍵にどの権限を付けるか
• 鍵を作業の後に消すのか、続けて使うのか（続けるなら入れ替えを誰が持つか）

答えがそろえば、外すかどうかを社内で判断できます。権限と入れ替えの欄が空いたままなら、外すのは保留にします。聞き返すのは作業を止めるためではなく、どこで動く処理かを確かめて外注先が鍵なしの方法を選び直せるようにするためです。

鍵を作ったら、入れ替え（ローテーション）の日と有効期限の要否を作った日に決める

鍵の入れ替え（ローテーション）とは、今の鍵を新しい鍵に置き換え、古い鍵を無効にすることです。Google は、サービスアカウントキーを含め、管理しているすべての鍵を定期的に入れ替えるよう勧めています（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）。入れ替えの日を後で決めようとすると、鍵を作った人が異動や退職でいなくなったあとに、誰も日付を知らない鍵が残りやすくなります。

有効期限は、組織のポリシーで新しく作る鍵に付けられます。サービスアカウントキーには初期設定では有効期限がなく、付ける値は1時間から2,160時間（90日）までの選択式です。Google は必要を満たす最短の期限を使うよう勧める一方で、期限を付けると本番の停止につながる場合があるとも注意しています（Google Cloud「IAM サービス アカウントの使用を制限する」／2026年10月22日閲覧）。

使い分けについて、Google のベスト プラクティスは有効期限を一時的なアクセスのためのものとしています。鍵でしか認証できない社外のツールを使う場合などが向き、本番で動く処理には期限を付けずに期限のない鍵を入れ替えで管理するよう書いています（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）。決まった時間に動き続ける処理に期限を付けると、期限の日に処理が止まって初めて気づくことになります。

鍵を作った日に決めるのは、次の三つです。

• 一時的なアクセスか、本番で動き続ける処理か（一時的なら有効期限を付ける）
• 次に入れ替える日と、入れ替える人
• 入れ替えたあとに古い鍵を無効にしたことを、誰が確かめるか

三つ目を決めておかないと、新しい鍵に替えたまま古い鍵が使える状態で残ります。Google の定義でも入れ替えは古い鍵を無効にするところまでを指すので（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）、無効にした日までを記録して一回と数えます。

サービスアカウントキーの作成無効についてよくある質問

Q. サービスアカウントキーと API キーは何が違いますか？

別の認証情報です。サービスアカウントに結び付いていない API キーは、請求と割り当てのためにプロジェクトを示すだけです。サービスアカウントキーは、サービスアカウントと、それが属するプロジェクトを識別します（Google Cloud「Google での認証方法」／2026年10月22日閲覧）。今回の表示で止まっているのはサービスアカウントキーの作成なので、API キーの扱いとは分けて考えます。

Q. JSON の鍵ファイルはどこに置けばよいですか？

コンソールや gcloud で作ったサービスアカウントキーは JSON ファイルになり、Google はできる限りファイル システムに保存しないよう勧めています。ディスクに置くしかない場合は、ファイルへのアクセスを絞ったうえでアクセスの監査を設定し、ディスクを暗号化するとしています（Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」／2026年10月22日閲覧）。共有のフォルダやコードと一緒に管理する場所に置かないことも、この考え方から出てくる線引きです。置き場所に迷う時点で、鍵なしの方法に戻って考え直す価値があります。

Q. Firebase で同じエラーが出たら、同じ考え方でよいですか？

同じ考え方で判断できます。Firebase の Admin SDK は、Cloud Run や Cloud Functions for Firebase など Google の環境で動かす場合、鍵のファイルではなくアプリケーションのデフォルト認証情報で初期化するよう強く勧められています。鍵のファイルを使う方法は、Google 以外のサーバー環境向けとして書かれています（Firebase（Google）「サーバーに Firebase Admin SDK を追加する」／2026年10月22日閲覧）。Google の環境で動かすなら鍵を作らずに済み、Google 以外のサーバーで動かすなら、この記事の順で鍵なしの方法から確かめます。

Q. 個人の Google アカウントで使っていても、同じ制限がかかりますか？

かかる場合があります。プロジェクトの上に組織リソースがなければ組織のポリシーはかからず、組織があれば2024年5月3日以降に作られた組織には初期設定でかかります（Google Cloud「サービス アカウント キーの作成と削除」／2026年10月22日閲覧）。組織リソースは、Google Workspace や Cloud Identity のアカウントをドメインに関連付けると自動で作られます。Google はこれとは別に、新しく試用を始める利用者向けにも組織リソースを自動で作り、すべての組織リソースに組織のポリシーの束を自動で適用するとしています。Google アカウントで登録した利用者に「スタンドアロン組織」が自動で作られる場合があることも書かれています（Google Cloud「Google Cloud 組織リソースを設定する」／2026年10月22日閲覧）。個人のアカウントで始めたプロジェクトでも、同じ表示が出たなら意味と判断の順はこの記事と同じです。

SAIの視点：鍵の作成を止める初期設定は、外し方より先に鍵なしで済むかを問う設定だった

当社で止まったのは鍵の作成だけで、その止まり方がそのまま「この処理に鍵は要るのか」という問いとして働きました。二つの案の中身は前の節に書いたとおりです。外し方を調べる前にこの問いに答えようとすると、処理の動く場所・結び付くログイン・漏れたときに使える権限を並べることになります。この並べ方をすると、鍵を使わない案と範囲を絞って鍵を使う案の違いが見えます。エラーの表示は外し方を探す入口に見えますが、実際には確かめる順番を先に示している表示です。

AI導入支援で業務に組み込む自動化を作るときは、AI導入の進め方の小さく実装する段階で、どの処理がどこで動きどの鍵と権限を持つかを一覧にします。入れ替えの日と入れ替える人を運用の文書に残すところまでは、FDE伴走開発で一緒に作ります。鍵の管理そのものを預かるのではなく、自社で判断して回せる状態を目指す支援です。

鍵のファイルでつないでいる自動の処理を一覧に書き出し、横に入れ替える人の名前を添えてみてください。名前の欄が空く処理が、最初に鍵なしへ移せるかを確かめる候補です。そのうえで作りたい（または動いている）自動化の目的・つなぐ先のサービス・組織のポリシーを変えられる人が社内にいるかをお問い合わせから送ってもらえれば、鍵なしで済む処理と例外が要る処理を分けるところから話します。鍵が漏れた疑いがあって調べる段階なら、セキュリティの専門の事業者や IPA・JPCERT/CC などの公的な相談先が向いています。

出典と確認日

外部の出典はいずれも2026年10月22日閲覧。当社の記録は2026年9月に自社の自動化を作る途中で鍵の作成が止められた1件で、外すかどうかの結論や効果を示すものではない。

• Google Cloud「サービス アカウントに関する組織のポリシーエラーのトラブルシューティング」
• Google Cloud「サービス アカウント キーの作成と削除」
• Google Cloud「Google Cloud セキュリティ ベースラインの制約」
• Google Cloud「IAM サービス アカウントの使用を制限する」
• Google Cloud「サービス アカウント キーを管理するためのベスト プラクティス」
• Google Cloud「サービス アカウント認証情報」
• Google Cloud「サービス アカウントの権限借用」
• Google Cloud「Workload Identity 連携」
• Google Cloud「Google での認証方法」（「ユースケースに適した認証方法を選択する」の節）
• Google Cloud「Google Cloud 組織リソースを設定する」
• Firebase（Google）「サーバーに Firebase Admin SDK を追加する」