Google Cloud ConsoleでAPI連携を始める方法｜有効化・認証・料金管理の基本
Googleの地図をWebサイトに表示したい、利用者のカレンダーと連携したい、画像から文字を読み取りたい。GoogleのAPIを使うと、こうした機能を自分のアプリに組み込めます。
開発を始める際は、使うAPIと実行場所を決め、プロジェクト・認証情報・権限・料金を順に確認することが大切です。APIを有効化したり、キーを発行したりするだけで、必要な設定がすべて完了するわけではありません。
この記事では、Google Cloud Consoleを使ったAPI連携の基本手順を紹介します。APIキー、OAuth 2.0、サービスアカウントの役割を整理し、小さな動作確認から公開時の管理まで見ていきましょう。
目次
１．Google Cloud Consoleで管理するものを整理する
Google Cloud Consoleは、Google Cloudのプロジェクトやサービス、権限、利用状況などを管理するWeb画面です。API連携では、対象プロジェクトでのAPIの有効化や、認証情報の設定などに利用します。
ただし、設定方法はConsoleだけではありません。サービスによっては、コマンドラインやAPI、別の開発者向け画面から設定することもできます。この記事では、Consoleを使って確認する基本的な流れを扱います。
| 管理するもの | 主な役割 | 確認すること |
|---|---|---|
| プロジェクト | リソースや設定をまとめる単位 | 開発対象のプロジェクトを選択しているか |
| APIの有効化 | 対象プロジェクトでAPIを利用するための設定 | 実装で呼び出すAPIが有効になっているか |
| 認証情報 | APIへのアクセスに必要な情報や設定 | APIと実行環境に合う方式を使っているか |
| 権限 | 誰にどの操作を許可するかを管理する | 必要な操作に絞って許可しているか |
| 請求・割り当て | 費用や利用量を確認・管理する | 課金条件、通知、利用上限を確認したか |
APIの有効化と、データへのアクセス許可は別の設定です。例えば、カレンダーのAPIを有効化しても、それだけで他の利用者の予定を取得できるようにはなりません。
２．実装前に「何を、誰の権限で使うか」を決める
最初に、追加したい機能と、アクセスするデータを具体化します。「Googleと連携する」より、「利用者が許可したカレンダーに予定を登録する」のように書くと、必要な設定を確認しやすくなります。
あわせて、APIをブラウザから呼ぶのか、自分のサーバーから呼ぶのかを決めましょう。実行場所によって、利用できる認証方式や認証情報の保管方法が変わります。
| 作りたい機能 | 検討するサービスの例 | 設計で確認すること |
|---|---|---|
| Webページに地図を表示する | Maps JavaScript API | ブラウザ向けAPIキーの制限、課金設定 |
| 利用者の予定を読み書きする | Google Calendar API | 利用者の同意、必要なアクセス範囲 |
| Googleアカウントでログインする | Google Identity Services | ログイン結果の検証、アプリ側のセッション管理 |
| サーバーで画像の文字を読み取る | Cloud Vision API | 実行環境の認証、送信する画像、利用量 |
地図の表示とルート検索など、見た目には一つの機能でも、複数のAPIや料金項目を使う場合があります。公式ドキュメントで、必要なAPIと課金単位を確認してください。
３．APIキー・OAuth・サービスアカウントを使い分ける
GoogleのAPIで使う認証情報は、すべて同じ役割ではありません。APIが対応している方式を確認し、誰のデータに、どの権限でアクセスするかに合わせて選びます。
標準のAPIキー：利用するプロジェクトを関連付ける
Google Cloudの標準のAPIキーは、リクエストを課金や割り当ての対象プロジェクトに関連付けるために使われます。利用者本人をログインさせたり、その人の非公開データへのアクセス許可を得たりするものではありません。
APIキーを受け付けないサービスもあるため、キーを作ればどのAPIでも呼べるとは限りません。また、サービスアカウントに関連付けられた認可キーは標準のAPIキーと性質が異なるため、作成したキーの種類も確認しましょう。
OAuth 2.0：許可された範囲でデータへアクセスする
利用者のカレンダーなどをアプリから操作する場合は、OAuth 2.0による認可を検討します。必要なアクセス範囲を示す「スコープ」を指定し、許可された範囲でAPIを呼び出します。
OAuthクライアントIDはアプリを識別する情報であり、それ自体がデータへのアクセス許可ではありません。実際のAPI呼び出しでは、認可の手順で取得したアクセストークンなどを使います。
また、Googleアカウントでのログインと、カレンダーなどへのアクセス許可は別です。ログインではIDトークンの検証などを行い、APIへのアクセスでは必要な認可を扱います。ログインボタンを設置するだけで、アプリ内の操作権限まで決まるわけではありません。
サービスアカウント：プログラムの実行主体として使う
サービスアカウントは、人間の利用者とは別に、プログラムなどが使うアカウントです。サーバーからGoogle Cloudの機能へアクセスする場合などに、必要な権限を付与して使います。
Google Cloud上で実行するアプリでは、実行環境にサービスアカウントを関連付け、認証ライブラリが実行環境から認証情報を取得する方法を検討します。JSON形式の秘密鍵ファイルを毎回発行することを前提にしないでください。
なお、サービスアカウントを作っても、利用者のGoogle Driveやカレンダーへ自由にアクセスできるわけではありません。対象データの共有や、そのサービスに応じた権限設定が必要です。
APIキーやアクセストークンの違いを整理したい方へ。認証・認可の基本と、認証情報を安全に管理する考え方を解説しています。
APIキー・アクセストークン・シークレットキーの違いとは？API認証と安全な管理の基本 記事を読む →４．Google Cloud ConsoleでAPI連携を始める手順
利用するAPIが決まったら、対象プロジェクトの設定を進めます。画面の名称や必要な手順はサービスによって異なるため、各APIの公式セットアップガイドも併せて確認してください。
手順１：対象プロジェクトを選択する
Google Cloud Consoleで、利用するプロジェクトを選択するか、新しく作成します。複数のプロジェクトがある場合は、表示名だけでなくプロジェクトIDも確認しておきましょう。
開発用と本番用を分ける場合は、APIの有効化、認証情報、請求設定などもそれぞれ確認します。開発用で動いた設定が、そのまま本番用にも反映されるわけではありません。
手順２：APIと請求条件を確認する
「APIとサービス」のライブラリなどから、利用するAPIを探して有効化します。似た名前のAPIや複数のバージョンがある場合は、実装で使うものと一致しているかを確認してください。
請求先アカウントの関連付けが必要か、無料で使える範囲があるかはサービスごとに異なります。「テストだから無料」と判断せず、呼び出す前に料金と利用条件を確認しましょう。
手順３：必要な認証情報と権限を設定する
APIキーを使う場合は、対応するアプリケーション制限とAPI制限を設定します。OAuthを使う場合は、アプリ情報、利用対象者、スコープ、クライアントの種類、必要なリダイレクトURIなどを設定します。
サービスアカウントを使う場合は、実行環境と必要な権限を確認します。動かないからといって、広い管理者権限を付ける前に、エラーが示す不足権限や対象リソースを調べてください。
手順４：一つの処理で動作を確認する
最初は、テスト用のデータを使って、一つの操作が成功するか確かめます。読み取りで確認できる場合は、取得結果と処理時間、エラーの有無を確認してから機能を広げましょう。
登録や更新が必要な場合も、テスト用の予定やファイルなど、影響を確認しやすい対象を使います。再実行で同じデータが二重に作られないかも確認してください。
例：Maps JavaScript APIで地図を表示する場合
Webページへ地図を表示する場合は、Maps JavaScript APIの公式手順に従い、請求設定とAPIの有効化、APIキーの作成を行います。ブラウザ向けのキーには、利用するWebサイトとAPIの制限を設定します。
開発用のURLと公開用のURLが異なる場合は、それぞれの許可設定を確認してください。公式サンプルで地図表示を確かめ、エラーがあればブラウザの開発者ツールでメッセージを確認します。
詳しい手順は、Google公式のMaps JavaScript APIセットアップガイドで確認できます。ルート検索などを追加する場合は、追加機能のAPIと課金条件も別に確認しましょう。
５．APIキーは、実行場所に合わせて保護する
認証情報の管理では、サーバーで秘密にするものと、ブラウザでの使用を前提とするものを区別します。「APIキー」という名前だけで、公開してよいかどうかを判断しないでください。
サーバー用の秘密情報は、ブラウザへ渡さない
サーバー側で使う秘密のAPIキー、OAuthクライアントシークレット、サービスアカウントの秘密鍵などは、ブラウザへ配信するコードや公開リポジトリに含めません。実行環境の設定やシークレット管理機能から読み込む方法を検討します。
.envは設定値を保存するファイルであり、置くだけで自動的に読み込まれたり、安全になったりするものではありません。読み込み方法と公開範囲を確認し、ログやエラーメッセージにも秘密情報を出さないようにします。
フロントエンドの環境変数は、秘密を隠す仕組みではない
フロントエンドのビルド時に環境変数を使っても、その値が配信するJavaScriptへ埋め込まれれば、利用者から確認できます。環境変数に移したことだけを根拠に、秘密情報を保護できたと判断しないでください。
一方、Maps JavaScript APIのようにブラウザで使うキーは、利用者から見える前提で、Webサイトの制限とAPIの制限などを設定します。この扱いを、他サービスの秘密のAPIキーにそのまま当てはめることはできません。
漏えいした秘密情報は、ファイルから消すだけで終わらせない
秘密情報を誤って公開した場合は、その認証情報の無効化や再発行を検討し、利用履歴と影響を確認します。コードから削除しても、Gitの履歴や取得済みのコピーに残っている可能性があります。
ブラウザ向けキーについても、想定外の利用があれば制限と使用状況を確認します。開発用と本番用でキーを分けておくと、用途ごとの設定や利用状況を確認しやすくなります。
６．料金は、通知・利用上限・アプリ側の制限で管理する
APIの費用は、呼び出す機能や処理量によって変わります。リクエスト数だけでなく、処理する画像や文字量などが課金単位になる場合もあるため、対象サービスの料金表を確認してください。
自分のバックエンドや保存先を使う場合は、そちらの費用も含めて考えます。API側の無料利用枠だけを見て、アプリ全体の運用費を判断しないようにしましょう。
予算の通知と、利用を止める設定は別
Cloud Billingの「通知のみ」の予算設定は、費用の状況を把握するためのものです。設定した金額に達したら、Google CloudやGoogle Maps Platformの利用が自動的に止まるわけではありません。
対象サービスでは、利用額上限を設定する「Spend cap budgets」という機能もあります。ただし、対応サービスや適用範囲などの条件があり、停止は即時ではありません。設定額を超える費用が発生する可能性も含めて、公式説明を確認してください。
呼び出し回数を、アプリ側でも管理する
費用管理では、APIの割り当て設定に加えて、利用者ごとの回数制限、入力サイズの制限、二重送信の防止なども検討します。エラー時に無制限で再試行する実装は避け、再試行する条件と回数を決めましょう。
初期の検証では、操作１回でAPIが何回呼ばれるかを確認します。ボタンの連打や画面の再描画によって、意図せず同じ処理を繰り返していないかも見ておくと、公開後の利用量を見積もる材料になります。
７．動かないときは、エラーの内容から切り分ける
API連携の失敗には、認証情報の不備、権限不足、課金設定、利用上限、入力の誤りなど、複数の原因があります。エラーが出たら、まずHTTPステータスとサービス固有のエラーコードを確認します。
すべてのエラーを「キーの間違い」と考えたり、制限を外して試したりする前に、対象プロジェクトと設定を一つずつ照合してください。
| 症状・エラーの例 | 確認すること |
|---|---|
| APIキーが無効と表示される | キーの値、削除・無効化の有無、指定方法、対応するAPI |
| 呼び出し元が許可されていない | WebサイトやIPなどの制限と、実際の実行環境の一致 |
| 権限不足と表示される | 実行主体、必要な権限、対象リソース、許可されたスコープ |
| APIが有効ではないと表示される | エラーが示すプロジェクトと、有効化したプロジェクトの一致 |
| リダイレクトURIが一致しない | 登録値と実際のURLのスキーム・ホスト・ポート・パス |
| 利用上限に達したと表示される | 対象の割り当て、呼び出し頻度、再試行の重複 |
| 課金に関するエラーが出る | 請求先アカウントの関連付けと状態、APIの課金要件 |
外部へ調査を依頼する場合は、秘密情報を除いたエラーコード、発生時刻、対象API、実行場所を共有します。APIキーやアクセストークンを、そのままスクリーンショットや質問文へ含めないようにしてください。
API連携をアプリ全体の設計につなげたい方へ。操作権限、入力条件、エラー処理、仕様書の整理方法を紹介しています。
API設計・開発・連携の基本｜認証と認可、仕様書、エラー処理を整理する 記事を読む →８．公開前に、失敗した場合の動作も確認する
APIが一度成功したら、次は入力ミス、権限不足、通信失敗、利用上限などの場合を確認します。利用者に何を表示するか、再試行してよいか、処理が途中で止まった場合にデータが残るかを整理しましょう。
GoogleがAPIを運用していても、自分のアプリのエラー処理や認証情報の管理、仕様変更への対応は必要です。APIを導入した後も、利用量や失敗の状況を確認できるようにしておきます。
- 対象プロジェクトと、実際に呼び出すAPIが一致している。
- 認証方式がAPIと実行環境に合っている。
- 認証情報の公開範囲と、必要な権限を確認している。
- 料金の通知先と、利用量を制限する方法を確認している。
- 二重送信や無制限の再試行を防いでいる。
- エラーの記録に秘密情報や不要な個人情報を含めていない。
- 利用できない場合の画面表示と復旧手順を決めている。
まずは一つのAPIで、正常な結果と失敗時の動作を確認しましょう。そのうえで、利用者や処理量を増やした場合の権限・費用・運用を見直し、必要な機能を段階的に追加していくことが大切です。
参考資料
- Google Cloud：APIとサービスの認証
- Google Cloud：APIキーの管理
- Google Workspace：認証と認可の概要
- Google Maps Platform：セキュリティに関するガイダンス
- Google Cloud：予算と予算アラートの作成・管理
- Google Cloud：利用額上限付き予算の管理
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法