APIキーとIAM認証の違い

投稿日：

AIエージェントを整理整頓しているときの覚書。
Gemini 3.5 Flashと対話。


1. APIキーとは

APIキーは、特定のアプリケーションやプロジェクトを識別するために発行されるシンプルな文字列。
APIの呼び出し時に、リクエストヘッダーやクエリパラメータにキーを付与して送信する。

基本的に一度発行すると、手動で無効化や再生成（ローテーション）をしない限り、同じキーが使われ続ける。

一言でいうとAPIキーは、簡易的な「通行証（プロジェクト識別子）」のようなもの。
手軽に導入できますが、紛失や漏洩時のリスク管理には注意が必要。


Google AI Studioで生成したAPIキーを本番環境で使うことのリスク

  • データ漏洩とプライバシーのリスク（無料枠の場合）
    送信したプロンプトやデータ（個人情報や社内機密など）が、Googleのモデル学習や改善に利用される可能性がある。
  • キー漏洩時の不正利用・高額請求リスク
    シンプルなAPIキー認証であるため、キーが一度流出すると権限の細かい制限や制御ができず、第三者に悪用されやすくなる。
  • レート制限（クォータ）によるエラー頻発
    大規模なトラフィックに耐えられる設計になっておらず、ユーザー増に伴い「429 Too Many Requests（リクエスト過多）」エラーが発生しやすくなる。
  • SLA（サービス品質保証）やサポートの不在
    あくまでプロトタイプ向けツールであるため、システムの稼働率保証がなく、万が一の障害発生時に迅速なテクニカルサポートを受けられない。
  • 企業向けセキュリティ統制（ガバナンス）の欠如
    詳細なアクセスログ（監査ログ）の取得や、プライベートネットワーク制限（VPC）、詳細なアクセス権限（IAM）の管理ができない。



2. IAM（Identity and Access Management）認証とは

IAM認証は、クラウド環境や社内システムにおいて、ユーザーやサービスの「アイデンティティ（身元）」を厳密に管理し、詳細な権限を設定するための仕組み。

多くのIAMシステムでは、セキュリティを高めるために、数分〜数時間だけ有効な一時的な認証情報（トークン）を発行してアクセスする。

一言でいうとIAM認証は、より高度な「身分証明書と権限のセット」。
導入や設定には設計が必要だが、堅牢で柔軟なアクセス制御を実現できる。


OpenID Connect（認証）とOAuth 2.0（認可）との関係

多くのモダンなクラウドIAM（Google Cloud IAM、Microsoft Entra IDなど）は、OpenID Connectで「誰か」を確認し、OAuth 2.0で一時的なアクセス権（アクセストークン）を発行・検証することで、安全なIAM認証を実現している。

IAMは組織のポリシーや権限のルールを定義・管理する「司令塔」。
OAuth 2.0およびOIDCは、その指令に基づいて一時的なトークンを発行し、セキュアに通信を行うための標準規格。


「gcloud login（ユーザー認証）」と「sa-key.json（サービスアカウントキー認証）」の違い

比較項目

gcloud auth login
（ユーザー認証 / キーレス）

sa-key.json の作成
（サービスアカウント認証 / キーベース）

認証の主体（「誰」が）

人間（開発者、運用担当者）

プログラム・システム（サーバー、CI/CDツールなど）

主な呼び方

ユーザー認証、キーレス認証、ブラウザ認証

サービスアカウントキー認証、キー（鍵）ベース認証

認証の手法

ブラウザが起動し、Googleアカウントのログイン画面から認証する

作成した秘密鍵（JSONファイル）をプログラムに直接読み込ませる

鍵（JSONファイル）の保持

なし（固定の鍵ファイルは作成されない）

あり（永続的な秘密鍵ファイルがローカルに保存される）

主な用途

・開発者個人のPCでのローカル開発やデバッグ
・gcloud コマンドによる手動操作

・サーバーやアプリケーションの自動実行
・GitHub ActionsなどのCI/CD環境からのデプロイ

流出時のセキュリティリスク

極めて低い（流出する「鍵ファイル」自体が存在しないため）

非常に高い（Gitへの誤コミットやPCのウイルス感染で鍵が盗まれるリスク）

Googleの推奨度

強く推奨（人間が操作する場合はこの方法が標準）

非推奨 [1.3.2]
（現在は鍵を使わない「Workload Identity」などへの移行が推奨）


3. APIキーとIAM認証の比較表

比較項目

APIキー

IAM認証

識別の対象

アプリケーション / プロジェクト
（「何」がアクセスしているか）

具体的なユーザー / サービスアカウント / ロール
（「誰・何」がアクセスしているか）

権限の粒度

粗い
（APIの利用可否レベル）

非常に細かい
（「このデータベースのこのテーブルのみ読み取り許可」など）

認証情報の寿命

長期的（静的）
（手動で更新するまで有効）

短期的（動的）なケースが多い
（一時的なセッショントークンなどを使用）

セキュリティ強度

低い〜中程度
（漏洩時のリスクが高い。キーを知っていれば誰でも使えてしまう）

高い
（MFA、IP制限、有効期限の設定、ポリシーによる制限などが可能）

監査・ログ

限定的
（「このキーが使われた」ことしか分からないことが多い）

詳細
（「誰が」「いつ」「どのアクションを」「成功/失敗したか」まで追跡可能）

主な用途

公開APIの利用、外部サービスの組み込み、シンプルな開発時

クラウドインフラの管理、社内システム、セキュリティが重視されるマイクロサービス間通信




▼ 関連記事