この記事について
この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Google Identity / Google Cloud IAMの公式一次情報を確認し、OAuth 2.0とService Accountを「誰の権限で、何へアクセスするか」という初心者にも分かりやすい軸で整理しています。
情報確認基準日：2026年9月19日
Googleの認証方式・推奨構成・公式URLは変更されることがあります。本記事は上記基準日時点の公式情報を確認しています。
検証ステータス：Google Identity / Google Cloud IAM公式情報を2026年9月19日時点で確認。
まず一言でいうと
Google APIを使うとOAuth 2.0、Service Account、API Key、Access Tokenなど似た言葉が一気に出てきます。最初に覚えるポイントは1つです。
OAuth 2.0：利用者が「このアプリに、私のデータをここまで使わせる」と許可する仕組み
Service Account：サーバーやバッチ処理など、人ではない処理に与えるID
つまり、どちらが上位なのかではなく、誰としてAPIを呼ぶのかが違います。
Google全体ではどこにいる？
| 観点 | 位置づけ |
|---|---|
| 大分類 | Google API / Google Cloud / Identity |
| 分類 | 認証・認可基盤 |
| 大きな目的 | APIを「許可された主体だけ」が安全に利用できるようにする |
| OAuth 2.0の役割 | ユーザーからアプリへ限定的なアクセス許可を渡す |
| Service Accountの役割 | アプリ・VM・バッチなどのワークロードにIDを持たせる |
| 一緒に使うもの | Google Cloud Project、IAM、OAuth Scope、Access Token、ADC、各Google API |
この2つは単独で業務を完成させるサービスというより、Gmail、Calendar、Drive、Google CloudなどをAPIから安全に使うための土台のパーツです。
flowchart LR
USER[利用者] --> APP[アプリ]
APP --> AUTH{誰としてアクセス?}
AUTH -->|利用者の許可を受ける| OAUTH[OAuth 2.0]
AUTH -->|アプリ自身として動く| SA[Service Account]
OAUTH --> TOKEN[Access Token]
SA --> CRED[短期資格情報]
TOKEN --> API[Google API]
CRED --> API
IAM[IAM / 対象サービスの権限] --> API
用語を初心者向けに整理
認証（Authentication）は「あなたは誰ですか？」を確認することです。ログインして本人確認するイメージです。
認可（Authorization）は「その人・アプリは何をしてよいですか？」を決めることです。本人確認できても、すべてのデータを読めるとは限りません。
OAuth 2.0は主に認可のための標準的な仕組みです。パスワードそのものをアプリへ渡さず、「カレンダーを読むことだけ許可する」といった限定的な権限を渡せます。
Service AccountはGoogle Cloudで管理される、人間ではなくアプリや計算処理のためのIDです。
Access Tokenは、APIへ「許可を受けています」と示す短期的な通行証のようなものです。
Scopeは、OAuthで「どこまで許可を求めるか」を表す範囲です。
OAuth 2.0はどう流れる？
sequenceDiagram participant U as 利用者 participant A as アプリ participant G as Google認可画面 participant API as Google API U->>A: 機能を使う A->>G: 必要なScopeで認可を要求 G->>U: このアクセスを許可しますか？ U->>G: 許可 G-->>A: Authorization Code A->>G: CodeをTokenへ交換 G-->>A: Access Token A->>API: Access Token付きでAPI呼び出し API-->>A: 許可範囲のデータ
Webアプリなどでは大まかにこのように動きます。実装方式はアプリ種別で異なるため、Google公式はOAuthエンドポイントを独自に組み立てるより、提供される認証ライブラリの利用を案内しています。
Service Accountはどう流れる？
sequenceDiagram participant W as バッチ/サーバー participant ID as Service Account participant IAM as IAM participant API as Google Cloud API W->>ID: 実行環境に関連付けたIDを利用 ID->>IAM: 必要な権限を確認 IAM-->>W: 短期資格情報 W->>API: 資格情報付きでAPI呼び出し API-->>W: 許可された処理結果
Google Cloud上では、実行リソースへService Accountを関連付けて短期資格情報を利用する方式が代表的です。外部環境ではWorkload Identity Federationなども選択肢になります。
Service Account JSON keyも利用できますが、Googleは鍵を適切に管理できない場合のセキュリティリスクを明示し、より安全な代替手段を選べるならそちらを優先するよう案内しています。
OAuth 2.0とService Accountを比較
| 観点 | OAuth 2.0のユーザー認可 | Service Account |
|---|---|---|
| 主体 | Googleユーザー | アプリ・ワークロード |
| 人のログイン・同意 | 通常あり | 通常なし |
| 主用途 | ユーザー所有データへのアクセス | バックエンド・自動処理 |
| 権限 | Scope + ユーザー/サービス側の権限 | IAMや対象サービス側で付与された権限 |
| 資格情報 | Access Token、場合によりRefresh Token | 短期資格情報・Access Token等 |
| 長期鍵 | Client Secret等を扱う構成あり | JSON keyも可能だが代替方式を優先 |
重要なのは、「自動処理だから必ずService Account」ではないことです。APIごとの認証仕様と、アクセス対象が誰のデータなのかを確認して決めます。
仕事ではどう使い分ける？
一般利用者・事務職
たとえば自分のGoogle Calendar予定をExcelやCSVへ整理するツールなら、「自分の予定を読むことをこのツールへ許可する」というOAuth 2.0が理解しやすい例です。認可画面で要求される権限が必要以上に広くないかを見ることが重要です。
IT管理者
Service Accountを大量に作ることより、誰がどのService Accountを使え、何へアクセスできるかをIAMで管理することが重要です。長期JSON keyを安易に配布せず、最小権限と短期資格情報を優先します。
開発者
最初に「ユーザー委任か、ワークロードIDか」を決めます。その後、対象APIが対応する認証方式、必要Scope/IAM Role、実行環境を確認します。Google CloudクライアントライブラリではApplication Default Credentials（ADC）を利用すると、環境ごとに認証コードを書き換えにくい設計にできます。
Microsoftを知っている人ならどう考える？
| Google側 | Microsoft側で近い考え方 | 似ている点 | 注意する違い |
|---|---|---|---|
| OAuth 2.0ユーザー認可 | Microsoft identity platformのdelegated permissions | ユーザーがアプリへ限定的権限を委任 | Scope名、同意画面、APIごとの権限体系は異なる |
| Service Account | Microsoft Entraのworkload identity / service principalに近い | 人ではないアプリ・処理のID | GoogleのService AccountとEntra service principalは同一概念・同一管理モデルではない |
| IAM Role | Azure RBAC等に近い | リソースへの権限を役割で管理 | 権限階層・Role・対象サービスの設計は異なる |
「Service Account = Microsoftの○○そのもの」と置き換えず、人ではない処理へIDと必要最小限の権限を与える考え方が近いと理解するのが安全です。
API Keyはさらに別物
API KeyはAPI呼び出し元のProjectやアプリを識別する用途で使われますが、OAuthのようなユーザーの同意や、Service Accountのようなワークロード主体そのものとは役割が異なります。利用可否・制限方法はAPIごとに確認します。
安全に試す：ADCの状態を確認する
Google Cloud系のクライアントライブラリではADC（Application Default Credentials）がよく使われます。ADCは、実行環境から利用可能な資格情報を自動的に探す仕組みです。
ローカル開発でユーザー資格情報をADCへ設定する代表的なコマンドは次です。
gcloud auth application-default login
何を見る？ ブラウザ認証が完了し、ADC用のローカル資格情報が作られることを確認します。
成功条件は？ その後ADC対応のクライアントライブラリが、コードへTokenを直接書かずに認証情報を見つけられることです。
1か所変えるなら？ 本番環境ではこのローカルユーザー認証をそのまま持ち込まず、Google Cloud上なら実行リソースへ関連付けたService Account、外部環境ならWorkload Identity Federation等を検討します。
なお、ADC用に生成されるローカルファイルにも認証情報が含まれます。GitHubへコミットしてはいけません。
GitHubへ絶対に保存しないもの
credentials.json
token.json
OAuth Client Secret
Service Account JSON key
private key
Access Token
Refresh Token
実アカウントIDやメールアドレス
サンプルコードでは YOUR_PROJECT_ID、YOUR_PROPERTY_ID のような架空値を使います。
よくある勘違い
OAuthとService Accountはどちらが上？
優劣ではありません。主体と用途が違います。
Service Accountなら何でも無人化できる？
できません。各Google APIがどの認証方式を受け付けるか、対象サービス側でどの権限付与が必要かを確認します。Google Workspace等ではサービス固有の認可ルールもあります。
JSON keyを作れば一番簡単？
作成できる場合でも長期鍵には漏えいリスクがあります。Google Cloud上ならattached service account、外部環境ならWorkload Identity Federationなど、長期鍵を減らせる構成を先に検討します。
料金・アカウント・Project
| 項目 | 考え方 |
|---|---|
| Googleアカウント | OAuthのユーザー認可では対象ユーザーが必要 |
| Google Cloud Project | OAuth ClientやService Account、Google Cloud API利用などで必要になることが多い |
| OAuth 2.0自体の料金 | 認可方式そのものの固定料金というより、利用するAPI/サービス側の料金条件を確認 |
| Service Account自体 | 利用するGoogle Cloudリソース/API側の料金・割当を確認 |
料金や提供条件は変わるため、利用する個別APIの料金ページも基準日時点で確認してください。
結局どういう仕組み？
OAuth 2.0とService Accountは、Google APIを安全に使うときの「誰としてアクセスするか」を決める重要な部品です。
人が自分のデータ利用をアプリへ許可する → OAuth 2.0
サーバーやバッチが自分自身のIDで動く → Service Account
ここを最初に分けると、Scope、Access Token、IAM、ADCなど後から出てくる用語もつながって理解しやすくなります。
公式情報・一次情報
Google Identity — Using OAuth 2.0 for Web Server Applications
Google Cloud — Authentication for Google Cloud APIs and services
Papanda TRY：OAuth Scopeを目で比較する
架空のread-only scopeとwrite scopeをブラウザカードで左右比較し、許可する操作が増えると権限範囲も広がることを可視化するDaily Code候補にします。実client secretやtokenは使わず、最小権限を選ぶ練習にします。
結局どういうサービス？
OAuth 2.0とService Accountは何が違う？ Google API認証を整理するは、この記事で整理した役割・利用場面・注意点を押さえ、公式一次情報を確認しながら小さく試すことで理解しやすいGoogleサービスです。
