APIキー・アクセストークン・シークレットキーの違いとは？API認証と安全な管理の基本
API連携を始めると、「APIキー」「アクセストークン」「シークレットキー」という言葉が登場します。
どれも認証やアクセス制御に関係しますが、名前だけで役割や安全性を判断することはできません。特に、APIキーにも外部へ公開してはいけないものがあります。
この記事では、それぞれの違いと、API連携で間違えやすい管理方法を整理します。
目次
APIとは？サービス同士をつなぐ窓口
APIは、プログラムから別のソフトウェアの機能やデータを利用するための仕組みです。
例えば、学習アプリからAIに質問を送る、Googleカレンダーに予定を登録する、決済サービスで支払いを処理するといった場面で使われます。
APIの提供元は、必要に応じて認証情報を確認し、リクエストを受け付けるか判断します。
ここで区別したいのが、認証と認可です。
- 認証：アクセスしている相手が誰なのかを確認すること。
- 認可：その相手に、どの操作を許可するか判断すること。
「ログインできること」と「すべてのデータを変更できること」が別であるように、APIでも相手の確認と操作権限の確認を分けて考えます。
ただし、APIキーが識別する対象は、サービスによってアプリケーション、プロジェクト、アカウントなど異なります。必ずしも人間の利用者本人を識別しているわけではありません。
3つの用語は、完全に別々の分類ではない
まず、大まかな違いを確認しましょう。
| 用語 | 主な役割 | 公開・保管の考え方 |
|---|---|---|
| APIキー | APIの利用元の識別や、アクセス権限の確認など | 提供元が公開可能と明示したものを除き、秘密として扱う |
| シークレットキー | 秘密に保つ鍵や認証情報。用途はサービスによって異なる | 外部へ公開しない |
| アクセストークン | APIなどの保護された機能・データへのアクセス権を表す | 認証情報として保護し、権限・期限・保管方法を確認する |
大切なのは、これらが必ずしも互いに独立した分類ではないことです。
例えば、Stripeでは秘密のAPIキーを「Secret API key」と呼びます。つまり、APIキーであり、同時に秘密にすべきキーでもあるということです。
APIキーは、見られてもよい情報とは限らない
APIキーは、APIの利用元を識別したり、アクセスを許可したりするために使われます。
ただし、できる操作はサービスやキーの種類によって異なります。漏洩すると、不正なAPI利用、予期しない課金、データへのアクセスにつながる場合があります。
例えば、Gemini APIの公式資料は、APIキーをパスワードのように扱うよう案内しています。
一方、Stripeの公開用キーのように、ブラウザや配布するアプリでの利用を想定したものもあります。
「APIキーだから公開してよい」ではなく、「このサービスの、この種類のキーは公開可能か」を確認することが基本です。
シークレットキーの用途はサービスごとに違う
シークレットキーは、秘密として管理する鍵や認証情報を指す名称です。
APIへのアクセスに使うもの、アプリケーションの認証に使うもの、メッセージの改ざんを検出するために使うものなどがあります。APIキーと必ずセットで発行されるわけではありません。
また、暗号化と署名・MACは別の仕組みです。
- 暗号化：内容を第三者に読まれないようにする。
- デジタル署名・MAC：改ざんの有無や、対応する鍵を持つ相手が生成したことを検証する。
署名やMACを付けても、それだけで内容が隠れるわけではありません。
例えばStripeでは、API用のキーとWebhookの署名検証用シークレットが区別されています。同じサービス内でも、目的に合う認証情報を使う必要があります。
アクセストークンは、許可された操作を行うための情報
アクセストークンは、APIなどの保護されたリソースへのアクセス権を表す情報です。
OAuth 2.0では、例えば「利用者が許可した範囲で、アプリがカレンダーを操作する」といった仕組みに使われます。利用者のパスワードを連携先アプリに渡さず、権限を委譲できます。
ただし、利用者本人の操作を伴わず、サービス間で取得するトークンもあります。権限や有効期間は、提供元の仕様を確認してください。
よく使われるBearerトークンは、原則として持っている相手が利用できる認証情報です。有効期限があっても、漏洩してよいわけではありません。通信にはHTTPSを使い、ログなどにも残さないようにします。
安全なAPI連携の進め方
1．公式資料で認証方式を確認する
コードを書く前に、次を確認します。
- 必要なのはAPIキーか、アクセストークンか。
- ブラウザで使える認証情報か、サーバー専用か。
- 読み取りだけで足りるか、書き込みも必要か。
- 有効期限や更新・失効の方法は何か。
認証情報の送信方法も共通ではありません。指定されたHTTPヘッダーなど、提供元の方法に従います。
2．秘密情報はサーバー側で管理する
秘密のAPIキーを使うWebアプリでは、例えば次のように処理します。
- ブラウザが自分のサーバーへリクエストする。
- サーバーが利用者と操作権限を確認する。
- サーバーが秘密のキーを使って外部APIを呼ぶ。
- 必要な結果だけをブラウザへ返す。
サーバー側には、利用者の確認や回数制限も必要です。キーを隠していても、誰でも無制限に呼べる中継APIでは、不正利用を防げません。
3．環境変数と.envファイルを正しく使う
環境変数は、ソースコードにキーを直接書かずに、実行環境へ設定を渡す方法の一つです。
ローカル開発では、.envファイルに値を保存し、対応するツールで読み込むことがあります。ただし、.envファイル自体は暗号化された保管庫ではありません。
Gitの管理対象から除外し、アクセス権限にも注意します。本番環境では、ホスティング先のシークレット管理機能などを利用します。
また、フロントエンド向けの環境変数が、ビルド時にJavaScriptへ埋め込まれる場合もあります。環境変数に入れたという理由だけで、ブラウザから見えなくなるわけではありません。
4．必要な権限だけを与える
一覧の取得だけが目的なら、削除や更新の権限まで与える必要はありません。
対応しているサービスでは、キーの権限、利用できるAPI、アクセス元などを制限します。設定できる制限はサービスによって異なるため、公式資料で確認します。
認証情報を公開してしまったら
GitHubにキーを載せてしまった場合、最新のファイルから文字列を消すだけでは不十分です。過去の履歴やコピーに残っている可能性があります。
まず、漏洩した認証情報の失効・ローテーションを優先します。そのうえで、新しい認証情報への切り替え、不正利用や課金の確認、必要な履歴の整理を進めます。
GitHubの公式資料でも、秘密情報を含む履歴の削除に先立ち、認証情報の失効やローテーションを検討するよう案内しています。
よくある質問
APIキーとアクセストークンは、どちらが安全ですか？
名前だけでは比較できません。
権限の範囲、有効期限、漏洩時の失効方法、保管場所、通信方法を含めて判断します。
アクセストークンが切れたら、必ずリフレッシュトークンで更新できますか？
必ずではありません。
OAuth 2.0でも、リフレッシュトークンの発行は任意です。利用する認可フローやサービスの仕様によっては、再認可や別の取得手順が必要です。
.gitignoreに.envを書けば、すでに公開したキーも消えますか？
消えません。
.gitignoreは、すでに追跡されているファイルや過去の履歴を自動で削除するものではありません。公開済みのキーは漏洩したものとして対処します。
API連携では、名前よりも権限と扱い方を確認する
APIキー、シークレットキー、アクセストークンには、それぞれ用途があります。ただし、呼び方だけで公開可否や安全性は決まりません。
実装前には、何を許可する認証情報なのか、どこに保管するのか、漏洩時にどう止めるのかを確認しましょう。
この3点を押さえることで、単に動くだけでなく、安心して運用できるAPI連携に近づきます。
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法