APIキーの基本と安全な使い方：発行・保管・利用時にまず確認すること

2026年8月4日

APIキーの基本と安全な使い方：発行・保管・利用時にまず確認すること

APIキーは、外部サービスのAPIを使うときに「どの利用者・どのアプリからのリクエストか」を識別するための文字列です。WordPressの問い合わせフォーム連携、地図表示、決済、翻訳、メール配信、自動投稿などでよく使います。

ただし、APIキーは単なる設定値ではありません。漏れると第三者にAPIを使われ、料金の発生、データの閲覧、送信制限の消費につながることがあります。発行したら、コードに直接書かず、権限と利用範囲を絞って保管するのが基本です。

この記事では、Web制作・WordPress・サーバー運用・自動化でAPIキーを扱う初心者向けに、発行から利用、保管、失敗時の見直しまでを整理します。

APIキーは、API利用者を識別するための認証情報の一種
ブラウザに見える場所へ置くキーと、サーバー側だけで使うキーは扱いを分ける
.env やサーバーの環境変数に保存し、Gitには含めない
使えるAPI、ドメイン、IP、利用量を制限できる場合は必ず設定する
漏えいした可能性があるキーは、削除または再発行して差し替える

APIキーとは何か

APIキーは、API提供元がリクエスト元を識別するために発行する文字列です。

たとえば、Google Maps PlatformではAPIキーを使ってアプリケーションを識別し、利用するAPIを管理します。OpenAI APIでも、リクエスト時にAPIキーを送ることで、どのアカウントのプロジェクトとしてAPIを使うかを判定します。

パスワードとは少し違う

APIキーは「ログイン用パスワード」と同じものではありません。多くの場合、人間がログインするためではなく、プログラムがAPIへアクセスするために使います。

ただし、扱いはパスワードに近いです。キーを知っている人やプログラムが、許可された範囲でAPIを使えるからです。

APIキーで起きやすい問題は、次のようなものです。

GitHubなどの公開リポジトリにキーをコミットしてしまう
HTMLやJavaScriptにサーバー用の秘密キーを書いてしまう
WordPressテーマやプラグインの設定ファイルをそのまま共有してしまう
テスト用のキーを本番環境で使い続ける
退職者や外注先が使っていたキーを無効化しない

ここがポイント: APIキーは「便利な接続用コード」ではなく、外部サービスを使う権限につながる認証情報として扱います。

どこで使うのか：実務でよくある場面

APIキーは、Webサイトや自動化処理が外部サービスとやり取りするときに登場します。

WordPressや小規模なWeb制作では、次の場面が典型です。

問い合わせフォーム送信後にメール配信サービスへ登録する
住所から地図を表示する
決済サービスのAPIを呼び出す
画像生成、翻訳、要約などのAI APIを使う
サーバー上の定期処理で外部APIからCSVやJSONを取得する
Google Apps ScriptやPower Automateから外部サービスへ接続する

ここで大事なのは、「どこでAPIを呼ぶか」です。

ブラウザ側で使うキー

地図表示のように、ブラウザ上のJavaScriptからAPIを呼ぶケースがあります。この場合、APIキーは開発者ツールなどで見える前提になります。

そのため、提供元が許可している範囲で、次のような制限をかけます。

利用できるWebサイトのドメインを制限する
利用できるAPIを必要なものだけに絞る
利用量や予算アラートを設定する

Google Maps PlatformのAPIキー制限では、アプリケーション制限やAPI制限を設定できます。ブラウザに出るキーだから安全、ではありません。見える前提で、使える場所を狭くするという考え方です。

サーバー側で使うキー

決済、メール配信、AI API、管理者向けデータ取得などは、通常サーバー側で扱います。

この場合、APIキーをHTMLや公開JavaScriptに出してはいけません。WordPressならPHP側、Node.jsならサーバー処理、Pythonならバッチ処理やバックエンドで読み込みます。

サーバー側のキーは、漏れるとそのまま不正利用につながりやすいため、次のように扱います。

環境変数やシークレット管理機能に保存する
Git管理対象のコードに直接書かない
本番用、検証用、個人開発用を分ける
使わなくなったキーは削除する

発行するときに確認すること

APIキーは、発行画面で作って終わりではありません。発行直後の設定で、事故の起き方が大きく変わります。

最低限、次の項目を確認します。

キーの名前: どのサイト・処理で使うか分かる名前にする
権限: 必要なAPIや操作だけを許可する
利用元制限: ドメイン、IPアドレス、アプリなどで制限できるか確認する
利用量制限: 上限、予算、アラートを設定できるか確認する
有効期限: 期限付きキーを使える場合は運用に合わせて設定する
ローテーション: 定期的な再発行や差し替え手順を用意する

名前を付けて管理する

キー名は意外に重要です。

test や api-key-1 のような名前では、半年後に誰が何のために作ったキーか分かりません。次のように、用途が分かる名前にしておくと見直しやすくなります。

wp-contactform-mail-service-production
staging-map-display-browser-key
daily-csv-import-python-batch

名前に秘密情報を入れる必要はありません。重要なのは、対象サービス、環境、用途が分かることです。

権限は小さく始める

APIキーに権限を付けられるサービスでは、最初から広い権限を与えないようにします。

たとえば、読み取りだけで足りる処理に、削除や更新の権限を付ける必要はありません。メール送信だけに使うキーなら、顧客一覧の全操作まで許可しない方が安全です。

これは「最小権限」の考え方です。事故が起きたとき、被害範囲を小さくできます。

保管方法：コードに直書きしない

APIキーの保管で最も避けたいのは、ソースコードへの直書きです。

次のようなコードは、動作確認だけなら簡単ですが、Gitに入った瞬間に危険になります。

// NG例: APIキーをコードに直接書いている
const apiKey = "sk-xxxxxxxxxxxxxxxx";

公開リポジトリでなくても、共有ZIP、チャット添付、バックアップ、ログ出力などから漏れることがあります。

`.env` に置く例

Node.jsやPythonの小さな開発環境では、.env ファイルにキーを置き、プログラムから読み込む形がよく使われます。

# .env
API_KEY=sk-xxxxxxxxxxxxxxxx
API_BASE_URL=https://api.example.com/v1

.env はGitに含めないよう、.gitignore に追加します。

# .gitignore
.env

Node.jsでは、たとえば環境変数から読み込みます。

const apiKey = process.env.API_KEY;

if (!apiKey) {
  throw new Error("API_KEY is not set");
}

Pythonでも同じ考え方です。

import os

api_key = os.environ.get("API_KEY")

if not api_key:
    raise RuntimeError("API_KEY is not set")

.env を使う場合も、サーバー本番環境ではレンタルサーバー、クラウド、CI/CD、コンテナ基盤などの環境変数やシークレット管理機能へ移すのが基本です。

WordPressではどこに置くか

WordPressでは、APIキーをテーマファイルへ直接書くのは避けます。

現実的な置き場所は、用途によって変わります。

プラグインの設定画面に保存する
wp-config.php に定数として置く
サーバーの環境変数から読む
ホスティングサービスのシークレット機能を使う

wp-config.php に置く場合も、公開ディレクトリやバックアップの扱いに注意が必要です。共有サーバーでは、ファイル権限やバックアップ取得範囲も確認します。

例として、wp-config.php に定数を置き、プラグインやテーマ側で参照する形があります。

define('EXAMPLE_API_KEY', 'sk-xxxxxxxxxxxxxxxx');

ただし、これは「テーマに直書きするより管理しやすい」という話であって、万能ではありません。本番ではサーバー環境やチーム運用に合わせて、より安全なシークレット管理を検討します。

利用時の書き方：Authorizationヘッダーで送る例

APIキーの送り方はサービスごとに違いますが、サーバー側APIでは Authorization ヘッダーに入れる形がよくあります。

以下はNode.jsの fetch を使った最小例です。

const apiKey = process.env.API_KEY;

const response = await fetch("https://api.example.com/v1/items", {
  method: "GET",
  headers: {
    "Authorization": `Bearer ${apiKey}`,
    "Accept": "application/json"
  }
});

if (!response.ok) {
  throw new Error(`API request failed: ${response.status}`);
}

const data = await response.json();
console.log(data);

入力は、環境変数 API_KEY とAPIのURLです。期待する出力は、JSON形式のレスポンスです。

{
  "items": [
    { "id": 1, "name": "sample" }
  ]
}

この例で見ておきたい点は3つです。

APIキーをコードに直接書いていない
レスポンスの成功・失敗を response.ok で確認している
ログにAPIキーを出していない

APIキーの送信方法は、Authorization: Bearer ... ではなく、X-API-Key ヘッダーやクエリ文字列を使うサービスもあります。実装前に公式ドキュメントで指定形式を確認します。

よくある失敗と直し方

APIキーまわりのエラーは、キーそのものの間違いだけでなく、制限設定や環境差で起きます。

401 Unauthorized が出る

401は、認証に失敗しているときによく出ます。

確認するポイントは次の通りです。

APIキーが空になっていないか
コピー時に前後の空白や改行が入っていないか
Bearer など、指定された接頭辞を付けているか
本番用と検証用のキーを取り違えていないか
キーが削除・無効化されていないか

最初に確認したいのは、プログラムが本当にキーを読めているかです。ただし、キー全体をログに出してはいけません。

const apiKey = process.env.API_KEY;
console.log(apiKey ? "API_KEY is set" : "API_KEY is missing");

403 Forbidden が出る

403は、キーは認識されたものの、権限や制限に引っかかっている場合に出ます。

たとえば、次のような原因があります。

利用できるAPIが制限されている
許可ドメインが現在のURLと一致していない
許可IPアドレスがサーバーの送信元IPと違う
課金設定や利用上限に達している

ブラウザ側のキーでは、localhost、本番ドメイン、サブドメインの扱いでつまずきやすいです。example.com と www.example.com は別扱いになることがあります。

CORSエラーとAPIキーエラーを混同する

ブラウザのコンソールにCORSエラーが出ている場合、APIキー以前に、ブラウザからそのAPIを直接呼べない設計になっていることがあります。

この場合、APIキーを変えても直りません。サーバー側に中継処理を置く、公式SDKを使う、ブラウザ利用が許可されたAPIに切り替える、といった見直しが必要です。

NG例と改善例

APIキーの扱いは、少しの書き方の差で安全性が変わります。

NG例: フロントエンドに秘密キーを置く

<script>
  const secretKey = "sk-xxxxxxxxxxxxxxxx";
</script>

この書き方では、ページを見た人がキーを確認できます。秘密キーとして扱うべきものなら、ブラウザには出さず、サーバー側でAPIを呼びます。

改善例: サーバー側でAPIを呼ぶ

app.get("/api/items", async (req, res) => {
  const response = await fetch("https://api.example.com/v1/items", {
    headers: {
      "Authorization": `Bearer ${process.env.API_KEY}`
    }
  });

  const data = await response.json();
  res.json(data);
});

ブラウザは自分のサーバーの /api/items を呼び、外部APIキーはサーバー側だけで使います。これなら、HTMLやJavaScriptから秘密キーが見えません。

もちろん、この中継APIにも制限は必要です。誰でも大量に呼べる状態にすると、自分のサーバー経由でAPIを使われてしまいます。

APIキー、OAuth、Basic認証の違い

API連携では、APIキー以外の認証方式も出てきます。違いをざっくり押さえると、設計を選びやすくなります。

方式	主な使いどころ	初心者が見るポイント
APIキー	サーバー間連携、外部APIの利用者識別	キーの保管、権限、利用元制限が重要
OAuth 2.0	ユーザーの許可を得て、別サービスのデータへアクセスする	アクセストークン、更新トークン、同意画面を理解する
Basic認証	簡易的な保護、管理画面や検証環境の入口	HTTPSなしでは使わない。APIの本格的な権限制御には弱い

APIキーは実装しやすい一方で、「ユーザーごとの同意」や「細かい権限委任」には向かないことがあります。Googleの一部APIやSNS連携のように、ユーザーのアカウント情報へアクセスする場合はOAuthが使われることが多いです。

APIキーで足りるのは、主に次のようなケースです。

自社サーバーから外部サービスへ定期的にアクセスする
サイト単位、アプリ単位で利用量を管理したい
ユーザー本人の個別データではなく、サービス提供側のAPI機能を使う

漏えいしたかもしれないときの対応

APIキーが漏れた可能性がある場合、まず無効化または再発行します。

「実際に悪用された証拠がないから様子を見る」は危険です。公開リポジトリやログに出たキーは、すでに第三者に取得された前提で扱います。

対応の順番は次の通りです。

対象キーを無効化、削除、または再発行する
本番環境、検証環境、CI/CD、WordPress設定などの参照先を差し替える
Git履歴、ログ、バックアップ、共有ファイルに残っていないか確認する
API提供元の利用履歴や請求状況を確認する
必要に応じて利用制限、予算アラート、通知設定を追加する

GitHubでは、シークレットを誤ってコミットしないためのSecret scanningやPush protectionの仕組みが提供されています。チームで開発する場合は、こうした検出機能も使います。

実務でのチェックリスト

APIキーを新しく使い始める前に、次の項目だけでも確認しておくと事故を減らせます。

そのAPIキーは本番用か、検証用か
ブラウザに見えてよいキーか、サーバー側だけで使うキーか
Gitに含まれない場所で管理しているか
利用できるAPIや権限を絞っているか
ドメイン、IPアドレス、アプリ制限を設定できるか
利用上限や請求アラートを設定しているか
ログやエラー通知にキーを出していないか
使わなくなったキーを削除する担当とタイミングが決まっているか

特に初心者が見落としやすいのは、「動いたから完了」にしてしまうことです。APIキーは、接続できた後の管理が本番です。

まとめ：APIキーは小さく作り、見える場所に置かない

APIキーは、外部サービスをプログラムから使うための入口です。WordPress、Web制作、自動化、サーバー運用では避けて通れません。

最初に覚えるべき実務の判断軸は、次の3つです。

どこで使うか: ブラウザ側か、サーバー側か
何ができるか: 読み取り、送信、更新、削除などの権限
どこから使えるか: ドメイン、IP、アプリ、環境の制限

APIキーの扱いで迷ったら、まず「このキーが漏れたら何ができてしまうか」を考えると判断しやすくなります。次に見るべきなのは、発行画面の制限設定、コード内の保管場所、ログへの出力有無です。そこを押さえれば、API連携は安全に試しやすくなります。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

APIキーの基本と安全な使い方：発行・保管・利用時にまず確認すること

APIキーの基本と安全な使い方：発行・保管・利用時にまず確認すること

APIキーとは何か

パスワードとは少し違う

どこで使うのか：実務でよくある場面

ブラウザ側で使うキー

サーバー側で使うキー

発行するときに確認すること

名前を付けて管理する

権限は小さく始める

保管方法：コードに直書きしない

.env に置く例

WordPressではどこに置くか

利用時の書き方：Authorizationヘッダーで送る例

よくある失敗と直し方

401 Unauthorized が出る

403 Forbidden が出る

CORSエラーとAPIキーエラーを混同する

NG例と改善例

NG例: フロントエンドに秘密キーを置く

改善例: サーバー側でAPIを呼ぶ

APIキー、OAuth、Basic認証の違い

漏えいしたかもしれないときの対応

実務でのチェックリスト

まとめ：APIキーは小さく作り、見える場所に置かない

参照リンク

`.env` に置く例