この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
API利用元の識別や割当などに使われる文字列資格情報です。ユーザーのデータへの同意・認可を扱うOAuthとは役割が異なります。
情報確認基準日：2026-09-19
まず結論
API利用元の識別や割当などに使われる文字列資格情報です。ユーザーのデータへの同意・認可を扱うOAuthとは役割が異なります。
| 用語 | 実務で確認すること |
|---|---|
| Identity | 人かワークロードか |
| Credential | 何を秘密として扱うか |
| Scope / Role | 何を許可するか |
| Token | 有効期限と保存方法 |
flowchart LR Principal[ユーザー / Workload] --> Auth[認証] Auth --> Credential[資格情報] Credential --> API[Google API] Scope[Scope / Role] --> API
実務でのポイント
認証と認可を分け、ユーザーOAuthとService Accountも用途を分けます。API Keyだけでユーザーの非公開データへアクセスできる、といった誤解を避けます。
セキュリティ
Access Token、Refresh Token、API Key、client secret、Service Account鍵を公開GitHubへ保存しません。可能な限り短命な資格情報と最小権限を利用します。
公式情報
次に何をすればよい？
利用するAPIの公式認証ガイドで推奨方式を確認し、必要なscope/roleだけを設定します。
個別一次情報の深掘り
API keyは主にprojectを識別してAPI利用を関連付けるcredentialで、ユーザー本人のOAuth認可やService Account identityの代替ではありません。利用API、HTTP referrer/IP等のrestrictionを設定し、不要なkeyを削除します。
Google公式一次情報
Papanda TRY：API key restrictionチェッカー
実keyではなく架空設定JSONを読み、「API restrictionなし」「application restrictionなし」をPowerShellで警告するDaily Codeを作ります。API keyとOAuth tokenを同じcredentialとして扱わないことも出力に明示します。
結局どういうサービス？
API利用元の識別や割当などに使われる文字列資格情報です。ユーザーのデータへの同意・認可を扱うOAuthとは役割が異なります。
補強監査メモ
認証・ID・API基盤の記事では、人間のユーザー認可とワークロードの認証を混同しないことを最優先にします。OAuth 2.0、API key、Service Account、Access/Refresh Token、ADCは同じ「鍵」の別名ではなく、目的・主体・寿命・保管方法が異なります。
実務チェック
誰がPrincipalか（人・サービス・外部ID）を先に決める。
必要最小限のscope / role / permissionを選ぶ。
長期秘密鍵をコードや公開GitHubへ置かない。
tokenをログへ出さない。
本番では公式の推奨認証方式とローテーション/失効手順を確認する。
401/403は「認証できない」と「権限が足りない」を分けて切り分ける。
Microsoft経験者への読み替え
Microsoft Entra IDのアプリ登録、OAuth/OIDC、managed identity、RBAC等の経験は概念理解に役立ちますが、Google側のPrincipal、Service Account、IAM Role、ADC、scopeは対応関係を個別に確認します。
