Chrome拡張機能でGoogle Drive APIを使う際の「OAuth 2.0クライアントID」の正しい理解

この記事を書いた理由
よくある誤解：「クライアント」は誰のこと？
OAuth 2.0の登場人物を整理する
「OAuth 2.0クライアントID」は何を識別するのか
個人使用でも登録が必要な理由
フリーウェアでコスト負担は発生するのか
実装の標準的なパターン
Chrome拡張機能特有の問題：拡張機能IDの固定
実装の具体的な手順
トラブルシューティング：よくあるエラー
まとめ
参考リンク

この記事を書いた理由

Chrome拡張機能でGoogle Drive APIを実装していて、「OAuth 2.0クライアントID」という用語に混乱したことはありませんか？私は最近、個人プロジェクトでこの実装に取り組み、いくつかの誤解に直面しました。特に「クライアント」という言葉が「ユーザー（顧客）」を連想させるため、この認証の仕組みを正しく理解するまでに時間がかかりました。

この記事では、実装中に遭遇した疑問と、その答えをまとめています。同じような混乱を経験している開発者の参考になれば幸いです。

よくある誤解：「クライアント」は誰のこと？

OAuth 2.0を初めて触るとき、多くの人が「クライアント」という用語で立ち止まります。英語の「Client」から「顧客」や「ユーザー」を連想してしまうためです。しかし、OAuth 2.0における「クライアント」は、APIにアクセスするアプリケーション自体を指します。

つまり、あなたが開発しているChrome拡張機能そのものが「クライアント」なのです。ユーザーではありません。

OAuth 2.0の登場人物を整理する

混乱を避けるために、OAuth 2.0に登場する4つの役割を明確にしておきましょう。

Resource Owner（リソース所有者）は、Google Driveのデータを持っているユーザーです。自分のデータへのアクセスを許可する権限を持っています。

Client（クライアント）は、ユーザーのデータにアクセスしたいアプリケーションです。あなたが開発しているChrome拡張機能がこれに該当します。

Authorization Server（認可サーバー）は、認証と認可を管理するサーバーです。Googleがこの役割を担い、ユーザーがログインして許可を与える画面を提供します。

Resource Server（リソースサーバー）は、実際のデータを提供するサーバーです。Google Drive APIがこれに該当します。

「OAuth 2.0クライアントID」は何を識別するのか

「OAuth 2.0クライアントID」は、あなたのアプリケーションを識別するためのIDです。ユーザーのIDでも、あなた（開発者）のIDでもありません。

具体例で考えてみましょう。Slackアプリが「SlackにGoogleカレンダーへのアクセスを許可しますか？」と聞いてきたとします。このとき、Googleは次のように処理します。

まず、このアプリケーションは「Slack」であることをクライアントIDで識別します。次に、ユーザーが「許可」をクリックしたことを確認します。そして、SlackにGoogleカレンダーへのアクセストークンを発行します。

この流れで重要なのは、Googleがアプリケーションを確実に識別する必要があるという点です。

個人使用でも登録が必要な理由

「自分しか使わないアプリなのに、なぜGoogle Cloud Consoleで登録が必要なの？」という疑問を持つかもしれません。実は、個人使用でもGoogleの仕組み上、登録が必須です。

ユーザーが認証するとき、Googleはいくつかのことを確認する必要があります。どのアプリケーションに許可を与えるのか、そのアプリは信頼できるのか、問題があった場合に誰に連絡すればよいのか、そしてAPI使用量の追跡です。

たとえ1人しか使わないアプリでも、Googleにとってはアプリケーションを識別し、管理する必要があります。これは、セキュリティとシステムの健全性を保つための仕組みです。

フリーウェアでコスト負担は発生するのか

「全ユーザーのAPI呼び出しが開発者のクォータを消費するなら、フリーウェアを公開するとコスト負担が発生するのでは？」という懸念もよく聞かれます。

しかし、Google Drive APIは完全に無料です。Google公式ドキュメントには「All use of the Google Drive API is available at no additional cost.」と明記されています。

デフォルトのクォータは1日あたり10億リクエストで、ユーザーごとに100秒あたり1000リクエストの制限があります。もしこのクォータを超えた場合でも、課金されることはありません。単に403エラーが返されるだけで、必要に応じて無料でクォータ増加を申請できます。

つまり、コスト負担の心配は不要です。

実装の標準的なパターン

多くのフリーウェアChrome拡張機能は、同じ実装パターンを採用しています。

開発者がGoogle Cloud ConsoleでOAuth 2.0クライアントIDを作成し、そのclient_idをmanifest.jsonに含めます。client_idは公開情報なので、ソースコードにハードコードしても問題ありません。

ユーザー側の作業は非常にシンプルです。拡張機能を初回起動したときにGoogle認証画面が表示されるので、「許可」をクリックするだけで完了します。

「ユーザーが自分でGoogle Cloud Consoleでプロジェクトを作成し、設定画面でclient_idを入力する」というような実装は、一般的ではありません。一般ユーザーにこの作業を要求するのは非現実的だからです。

Chrome拡張機能特有の問題：拡張機能IDの固定

Chrome拡張機能を開発していると、特有の問題に遭遇します。Chrome拡張機能には「拡張機能ID」があり、これは通常「abcdefghijklmnopqrstuvwxyz123456」のようなランダムな文字列です。

開発モードで拡張機能を読み込むと、このIDが変わる可能性があります。しかし、Google Cloud ConsoleのOAuth設定では、この拡張機能IDを指定する必要があります。IDが変わってしまうと、認証が動作しなくなります。

この問題を解決するには、manifest.jsonにkeyフィールドを追加します。これにより、どの環境でも同じ拡張機能IDを維持できます。

実装の具体的な手順

実際の実装手順を見ていきましょう。

まず、Google Cloud Consoleでプロジェクトを作成します。次に、Google Drive APIを有効化します。「APIとサービス」から「ライブラリ」を選択し、「Google Drive API」を検索して有効化してください。

OAuth同意画面を設定します。アプリ名、スコープなどを設定する必要があります。

OAuth 2.0クライアントIDを作成します。アプリケーションの種類として「Chrome アプリ」を選択し、アプリケーションIDに拡張機能のIDを入力します。

作成が完了すると、「123456789-abc.apps.googleusercontent.com」のような形式のclient_idが取得できます。

次に、manifest.jsonにOAuth設定を追加します。

{
  "manifest_version": 3,
  "name": "YourExtension",
  "version": "1.0",
  "oauth2": {
    "client_id": "123456789-abc.apps.googleusercontent.com",
    "scopes": [
      "https://www.googleapis.com/auth/drive.readonly"
    ]
  },
  "permissions": [
    "identity"
  ],
  "host_permissions": [
    "https://www.googleapis.com/*"
  ]
}

コード側では、chrome.identity APIを使って認証を実装します。

chrome.identity.getAuthToken({ interactive: true }, (token) => {
  if (chrome.runtime.lastError) {
    console.error('認証エラー:', chrome.runtime.lastError);
    return;
  }

  // 取得したtokenを使ってGoogle Drive APIを呼び出す
  fetch('https://www.googleapis.com/drive/v3/files', {
    headers: {
      'Authorization': `Bearer ${token}`
    }
  })
  .then(response => response.json())
  .then(data => {
    console.log('ファイル一覧:', data);
  })
  .catch(error => {
    console.error('API呼び出しエラー:', error);
  });
});