認証・ID管理

APIキーえーぴーあいきー

API認証トークンREST APIアクセス制御シークレット

APIキーについて教えて

簡単に言うとこんな感じ！

APIキーは「合言葉付きの会員証」みたいなものだよ！外部サービスのAPIを使うとき、「このアプリが使っていいよ」って証明するために渡す長い文字列のことなんだ。これがないと「あなた誰？」って弾かれちゃうってこと！

APIキーとは

APIキー（API Key） とは、API（Application Programming Interface）を利用する際に、呼び出し元を識別・認証するための文字列（トークン） のことです。Webサービスやクラウドサービスが提供するAPIにアクセスするとき、リクエストにこのキーを添えることで「正規の利用者・アプリである」ことを証明します。

たとえば、自社のシステムに「Google Maps」の地図機能を組み込む場合、Google Cloudのコンソールで発行されたAPIキーをリクエストに含めることで、Googleは「どのプロジェクト・組織が何回地図を呼び出したか」を管理できます。逆にキーがなかったり無効なキーを使うとアクセスは拒否されます。

APIキーはパスワードの一種ですが、「特定の人」ではなく「特定のアプリケーション・システム」を識別するために使われる点が特徴です。そのため、漏洩すると第三者に悪用される危険があり、厳重な管理が求められます。

APIキーの仕組みと構造

APIキーを使ったAPI呼び出しの流れは以下のとおりです。

ステップ	内容
① 発行	サービスのコンソール（管理画面）でAPIキーを生成する
② 埋め込み	アプリのコードや設定ファイルにキーを記載する
③ 送信	APIリクエスト時にヘッダーやURLパラメータにキーを含めて送る
④ 検証	サービス側がキーを照合し、有効なら処理を返す
⑤ 記録	サービス側が利用量・エラーをキーに紐付けてログに残す

渡し方の種類

APIキーをリクエストに含める方法は主に3通りあります。

① HTTPヘッダーに含める（最も一般的・推奨）
   Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxx
   または
   X-API-Key: xxxxxxxxxxxxxxxxxxxxxxxx

② URLクエリパラメータに含める（簡易的・非推奨）
   https://api.example.com/data?api_key=xxxxxxxx

③ リクエストボディに含める（一部サービスで使用）
   { "api_key": "xxxxxxxx", "query": "..." }

キーの形式

APIキーはサービスによって形式が異なりますが、一般的には以下のような特徴があります。

特徴	説明
長さ	16〜64文字程度のランダムな英数字
プレフィックス	`sk-`（OpenAI）、`AIza`（Google）など識別用の接頭辞を持つことがある
生成	暗号学的に安全な乱数で生成される
有効期限	設定しない場合は無期限（有効期限付きで発行できるサービスも多い）

覚え方

「APIキー＝アプリの社員証」 人間がIDカードで入館するように、アプリはAPIキーでサービスの扉を開けるイメージ！

歴史と背景

2000年代前半 — Web APIが普及し始める。当初は認証なしの公開APIも多かった
2006年頃 — Amazon Web Services（AWS）がAPIキーを使ったサービス認証を採用し広まる
2007〜2010年 — TwitterやGoogleがAPIキーを必須化。乱用・スパム対策が主な目的
2012年頃 — OAuth 2.0が普及し始め、「ユーザーの代理アクセス」にはOAuthを使う流れが定着。APIキーは「サーバー間通信」や「自分のデータへのアクセス」に使う用途が明確化される
2020年代 — クラウドサービスの普及とともにAPIキー管理の重要性が増す。GitHub・AWSなどでキーの誤ったコミット（ソースコードに埋め込んでGitHubに公開）による情報漏洩事故が多発し、シークレット管理ツール（AWS Secrets Manager、HashiCorp Vaultなど）が注目される

APIキー vs その他の認証方式

APIキーは唯一の認証手段ではありません。用途に応じて使い分けることが重要です。

発注担当者が知っておくべき注意点

システムを外部サービスと連携させる際、ベンダーからAPIキーを受け取ったり、自社サービスのAPIキーを発行したりするケースがあります。以下の点を必ず確認しましょう。

チェックポイント	なぜ重要か
キーをソースコードに直書きしない	GitHubなどに誤って公開されると即悪用される
環境変数やシークレット管理ツールを使う	コードと認証情報を分離するためのベストプラクティス
使わないキーは削除・無効化する	退職者のキーや旧システムのキーを放置しない
IPアドレス制限を設定する	キーが漏れても特定IPからしか使えなくすると被害を限定できる
利用量のアラートを設定する	不正利用は突然の大量リクエストで発覚することが多い

規格・RFC番号	内容
RFC 6750	OAuth 2.0 Bearer Token の使用方法。APIキーをAuthorizationヘッダーで渡す形式の基礎となる仕様
RFC 7617	HTTP Basic認証の仕様。APIキー以前の認証方式として比較対象になる
RFC 7519	JWT（JSON Web Token）の仕様。APIキーの代替・補完として使われることが多い
RFC 6749	OAuth 2.0 の認可フレームワーク全体の仕様