AI APIキーの管理方法｜.env・サーバー経由・漏洩対策の基本 – devsakaso

AI APIを使い始めると、最初に必要になるのがAPIキーです。OpenAI API、Gemini API、Claude APIなど、多くのAI APIでは、リクエストを認証するためにAPIキーやアクセストークンを使います。

ただし、APIキーはただの設定値ではありません。漏洩すると、第三者に勝手にAPIを使われ、予期しない料金、使用量の急増、アカウントの悪用、データや設定への影響につながることがあります。

特にWeb開発では、フロントエンドにAPIキーを埋め込む、GitHubへ `.env` をコミットする、チーム全員で1つのキーを共有する、といった事故が起きやすいです。

この記事では、AI APIキーの管理方法を、Web開発者向けに整理します。`.env`、環境変数、サーバー経由、Git管理、チーム共有、権限分離、使用量監視、漏洩時の対応まで、公開前チェックリストとして使える形にまとめます。

生成AI全般の情報漏洩・著作権・誤回答対策は、生成AIの安全な使い方｜情報漏洩・著作権・間違いを防ぐチェックリストで扱っています。この記事では、その中でもAI APIキーの管理に絞ります。

この記事の内容は、2026年7月9日時点のOpenAI公式ドキュメントとHelp Centerをもとにしています。APIキー、プロジェクト、権限、IP allowlisting、Workload Identity Federationなどの仕様は変わることがあるため、実装前には必ず利用中サービスの公式情報を確認してください。

結論：AI APIキーはブラウザに置かず、サーバー側で環境変数として管理する

AI APIキー管理の基本は、次の5つです。

APIキーをブラウザやモバイルアプリに埋め込まない
APIキーをGitリポジトリへコミットしない
ローカルでは `.env` やOSの環境変数で管理する
本番ではホスティング環境のシークレット管理を使う
漏洩したらすぐにrevokeし、新しいキーへrotateする

OpenAIのProduction best practicesでは、APIキーをコードや公開リポジトリに出さず、環境変数やシークレット管理サービスを使うことが案内されています。また、OpenAI Help CenterのAPI key safetyでも、ブラウザやモバイルアプリのようなクライアント側環境へキーを置かないこと、リポジトリへコミットしないこと、環境変数を使うことが説明されています。

つまり、AI APIキーは次のように扱います。

場所	扱い	理由
ブラウザのJavaScript	置かない	ユーザーから見えるため漏洩する
Gitリポジトリ	コミットしない	公開・共有・履歴から漏洩する
ローカル開発	`.env` またはOS環境変数	コードと秘密情報を分けられる
本番環境	シークレット管理・環境変数	権限管理やrotateがしやすい
チーム開発	個人キー共有ではなくProjectや権限で分離	利用者・用途・環境ごとに追跡しやすい

AI APIをWebアプリで使う場合は、ユーザーのブラウザから直接AI APIへ送るのではなく、自分のサーバーを経由させます。クライアントとサーバーの役割は、クライアントサーバーシステムとはも参考になります。

AI APIキー管理で起こりやすい問題

AI APIキー管理で起きやすい事故は、だいたい次のパターンです。

問題	起きる原因	影響
ブラウザにキーが露出する	フロントエンドから直接AI APIを呼ぶ	第三者にキーを使われる
GitHubにキーを公開する	`.env` や設定ファイルをコミットする	不正利用、料金増加、キー再発行
チームで1つのキーを共有する	個人キーをチャットやドキュメントで渡す	誰が使ったか追跡しにくい
本番と開発で同じキーを使う	環境分離をしていない	テストが本番利用量や制限へ影響する
漏洩後も古いキーを使い続ける	revokeやrotate手順がない	被害が広がる
使用量の異常に気づかない	Usage監視や上限を見ていない	想定外の費用や制限超過につながる

AI APIキーは「アプリの裏側にある認証情報」です。CSSや通常の設定値と同じ感覚で扱うと危険です。

危険な実装例

まず、避けたい実装例を見ます。

フロントエンドにAPIキーを書く

次のようにブラウザ側のJavaScriptにAPIキーを書くのは危険です。

// NG: ブラウザに配信されるコードへAPIキーを書かない
const apiKey = "your_api_key_here";

await fetch("https://api.openai.com/v1/responses", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-5.5",
    input: "要約してください",
  }),
});

フロントエンドのコードは、ブラウザの開発者ツールや配信ファイルから見えます。ビルド時に難読化しても、秘密情報の保護にはなりません。

.envをGitへコミットする

ローカルでは `.env` を使うことがありますが、`.env` をそのままGitへ入れるのは危険です。

# NG: このファイルをGitへコミットしない
OPENAI_API_KEY=your_api_key_here
ANTHROPIC_API_KEY=your_api_key_here
GEMINI_API_KEY=your_api_key_here

公開リポジトリはもちろん、非公開リポジトリでも、共有メンバー、外部連携、誤公開、バックアップ、ログなどから漏れる可能性があります。

チームチャットでキーを共有する

「このキーで試してください」とチャットに貼るのも避けます。後から誰が使ったのか追跡しにくく、退職者や外部協力者のアクセス整理も難しくなります。

OpenAI Help Centerでは、個人APIキーの共有は推奨されず、チーム利用ではProject-based API keysやProject分離を使う考え方が案内されています。

安全な基本構成

WebアプリでAI APIを使う基本構成は、次のように考えます。

ブラウザは自分のサーバーのAPIへリクエストする
サーバー側だけがAI APIキーを持つ
サーバー側で入力チェック、認証、レート制限を行う
サーバーからAI APIへリクエストする
必要な結果だけをブラウザへ返す

構成イメージは次のとおりです。

Browser
  ↓ /api/ai-summary
Your Server
  ↓ OPENAI_API_KEY を使って呼び出し
OpenAI API

サーバー側のコードでは、環境変数からAPIキーを読みます。

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

export async function createSummary(text) {
  if (!text || text.length > 5000) {
    throw new Error("Invalid input");
  }

  const response = await openai.responses.create({
    model: "gpt-5.5",
    input: `次の文章を要約してください。\n\n${text}`,
  });

  return response.output_text;
}

ここでは OPENAI_API_KEY をコードに直接書いていません。OpenAI公式Quickstartでも、APIキーを作成後、環境変数としてexportし、SDKが環境変数から読む流れが案内されています。

.envと.gitignoreの基本

ローカル開発では、`.env` を使うことが多いです。

たとえば、ローカルだけで使う `.env` は次のようにします。

# .env
OPENAI_API_KEY=your_api_key_here
AI_MODEL=gpt-5.5

この `.env` はGitに入れません。代わりに `.gitignore` に追加します。

# .gitignore
.env
.env.local
.env.*.local

チームへ共有したいのは、実際のキーではなく、必要な変数名だけです。そのために `.env.example` を用意します。

# .env.example
OPENAI_API_KEY=
AI_MODEL=gpt-5.5

こうすると、チームメンバーは必要な環境変数を理解できますが、実際のAPIキーは共有されません。

Gitのignore設定は、git initと.gitignoreの使い方も参考になります。VueやNuxtの環境変数管理は、Vueの.env.localの使い方や Nuxtのenvファイルの使い方ともつながります。

サーバー経由にする理由

AI APIキーをサーバー側に置く理由は、キーを隠すためだけではありません。

サーバーを経由すると、次の制御ができます。

ログインユーザーだけにAI機能を使わせる
ユーザーごとに利用回数を制限する
入力文字数を制限する
禁止ワードや個人情報をチェックする
プロンプトをサーバー側で固定する
ログを残して失敗原因を追えるようにする
異常な連続リクエストを止める

OpenAIのRate limitsドキュメントでは、rate limitはAPIの悪用や過剰利用を防ぐための仕組みとして説明されています。自分のアプリ側でも、ユーザー単位の上限、課金プラン別の上限、IPやセッション単位の制御を入れておくと安全です。

AI APIの呼び出し方そのものは、今後の openai-api-javascript や openai-responses-api で実装記事として分けます。この記事では、APIキーをどこに置き、どう守るかに集中します。

本番環境ではシークレット管理を使う

本番環境では、`.env` ファイルを手元で置くだけではなく、ホスティングサービスやクラウドのシークレット管理を使います。

たとえば、次のような場所にAPIキーを保存します。

VercelのEnvironment Variables
NetlifyのEnvironment variables
Cloudflare WorkersのSecrets
AWS Secrets Manager
Google Secret Manager
GitHub Actions Secrets
DockerやKubernetesのSecret管理

ポイントは、コードと秘密情報を分けることです。リポジトリには、APIキーではなく「どの環境変数が必要か」だけを残します。

また、ステージングと本番は分けます。OpenAIのProduction best practicesでも、staging projectとproduction projectを分け、ユーザーアクセスやrate/spend limitsを分ける考え方が案内されています。

チーム開発ではキーを共有しない

チーム開発でありがちなのが、代表者のAPIキーを全員で使い回す運用です。これは避けます。

OpenAI Help Centerでは、個人APIキーの共有は推奨されず、チーム利用ではProject-based API keysを使い、環境やチームごとにProjectを分ける方法が案内されています。

基本方針は次のとおりです。

個人のAPIキーをチャットで共有しない
開発、検証、本番でProjectやキーを分ける
必要なメンバーだけをProjectへ追加する
退職・契約終了・担当変更時にアクセスを見直す
使用量をProject単位で確認できるようにする

権限管理が使える場合は、最小権限を意識します。OpenAIのRBACドキュメントでは、組織やProject単位で、誰が何をできるかを管理する考え方が説明されています。また、API key permissionsでは、キーに権限を設定できることも案内されています。

漏洩したときの対応

APIキーが漏れた可能性がある場合は、迷わずすぐに対応します。

対応の順番は次のとおりです。

該当キーをrevokeする
新しいキーを発行する
本番・ステージング・ローカルの設定を差し替える
不要な古いキーが残っていないか確認する
Usageやログを確認する
リポジトリ履歴や共有場所から漏洩元を調べる
再発防止として `.gitignore`、権限、通知、上限を見直す

OpenAIのSafety best practicesでは、APIキーが露出、悪用、または侵害された可能性がある場合は、すみやかにrevokeし、新しいキーへ置き換えることが案内されています。

すでにGitへコミットしてしまった場合、ファイルを削除するだけでは不十分なことがあります。Gitの履歴や外部サービスのキャッシュに残る可能性があるため、まずキーを無効化し、新しいキーへ差し替えます。そのうえで、必要なら履歴の削除やリポジトリの安全確認を行います。

使用量監視と上限設定

APIキー管理では、漏洩を防ぐだけでなく、異常利用に気づける状態にしておくことも重要です。

確認する項目は次のとおりです。

Usage dashboardで使用量を定期的に見る
Projectごとの利用量を分ける
ステージングと本番の利用量を分ける
通知しきい値を設定する
rate limitやspend limitを確認する
ユーザー単位のアプリ内利用制限を入れる

OpenAIのProduction best practicesでは、Usage pageでAPI key usageを監視できることや、usage limitの通知しきい値を設定できることが案内されています。

また、OpenAIのRate limitsドキュメントでは、rate limitが悪用や過剰利用の防止、安定運用のために使われることが説明されています。AIアプリ側でも、ユーザー単位の上限や、短時間に大量リクエストされたときの停止処理を入れておくと安全です。

より強い管理が必要な場合

個人開発や小さな検証では、環境変数とサーバー経由から始めるのが現実的です。一方、本番サービスや法人利用では、もう少し強い管理を検討します。

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

Project単位で開発・本番を分ける
API key permissionsで必要な権限だけにする
IP allowlistingでアクセス元を絞る
Workload Identity Federationで長期APIキーを持たない構成にする
CI/CDではシークレット管理を使い、ログへ出さない
定期的に不要キーを棚卸しする

OpenAIのIP allowlistingでは、許可したIPアドレスや範囲からのAPIリクエストだけを受け付ける設定が案内されています。キーが漏れても、許可外のネットワークから使われにくくする追加防御になります。

また、Workload Identity Federationでは、長期APIキーを保存せず、外部IDトークンから短期のOpenAIアクセストークンへ交換して認証する仕組みが案内されています。これは個人開発の最初の一歩というより、クラウドやCI/CDなど本番運用で検討する高度な選択肢です。

実装時のチェックリスト

AI APIキーを使う前に、次を確認します。

APIキーをブラウザ側コードに書いていない
APIキーをモバイルアプリに埋め込んでいない
`.env`、`.env.local`、秘密設定ファイルをGitに入れていない
`.env.example` にはキーの値ではなく変数名だけを書いている
本番環境ではシークレット管理や環境変数を使っている
サーバー側でAI APIを呼び出している
ユーザー入力の文字数や内容をチェックしている
ユーザー単位の利用上限を設けている
開発・検証・本番でProjectやキーを分けている
チームメンバーに個人APIキーを共有していない
Usageや請求通知を確認できる状態にしている
漏洩時のrevoke・rotate手順を決めている

このチェックリストは、AI APIを使う記事全体から参照できる安全運用の土台になります。

よくある質問

.envに入れれば安全ですか？

`.env` はコードへ直書きするより安全ですが、それだけで完全に安全になるわけではありません。`.env` をGitに入れない、本番ではホスティング環境のシークレット管理を使う、ログへ出さない、漏洩時にrotateできるようにする、という運用が必要です。

フロントエンドだけのサイトでAI APIを使えますか？

APIキーを隠す必要があるため、基本的にはサーバー側の処理が必要です。静的サイトだけで直接AI APIを呼ぶと、キーが見えてしまいます。サーバーレス関数、API Routes、Cloudflare Workersなどを挟む構成を検討します。

APIキーをチームメンバーに渡してもいいですか？

個人キーの共有は避けます。Project、メンバー招待、権限管理、Project-based API keysを使い、誰がどの環境で使うのかを分けます。

GitHubへコミットしてすぐ消せば大丈夫ですか？

大丈夫とは言えません。履歴や外部連携に残っている可能性があります。まず該当キーをrevokeし、新しいキーへ差し替えます。その後、履歴や公開範囲を確認します。

キーは定期的にrotateするべきですか？

チームや本番サービスでは、必要に応じてrotateできる運用を用意しておくのが安全です。漏洩が疑われる場合は、定期サイクルを待たずにすぐにrevoke・再発行します。

まとめ

AI APIキーは、AI機能を動かすための重要な認証情報です。便利な設定値ではなく、漏洩すると費用、悪用、運用停止につながる秘密情報として扱います。

基本は次のとおりです。

APIキーをブラウザやモバイルアプリに置かない
APIキーをGitへコミットしない
ローカルでは `.env` や環境変数、本番ではシークレット管理を使う
AI APIはサーバー側から呼び出す
開発・検証・本番でProjectやキーを分ける
Usage、rate limit、spend limit、通知を確認する
漏洩時はすぐrevokeし、新しいキーへrotateする

次に進むなら、OpenAI APIをJavaScriptで呼び出す記事へ進むと、今回のAPIキー管理を前提に、Node.jsから安全にAI APIを使う流れを実装できます。Function CallingやStructured Outputsを使う場合も、APIキー管理は最初に固めておくべき土台です。