連載の現在地:Phase 3「安全」(1 / 4本目) — 悪用や情報漏えいのリスクを潰す
1. 公開 → 2. 費用と安定 → 3. 安全 → 4. 品質 → 5. 自動化
こんな悩みの人へ
APIキーを、うっかりGitHubに上げてしまわないか不安。ブラウザで動くアプリに、キーをどう持たせればいいか分からない。万一漏れたら何から手をつければいいかも、まだ決めていない。そんな方に向けた記事です。
結論
この悩みの対策に、Cloudflareの導入は必須ではありません。 必要なのは新しいサービスではなく、4つの習慣です。キーはサーバー側の環境変数かシークレットにだけ置くこと。Gitに入らない仕組みを作ること。キーを用途ごとに分け、上限と権限を絞ること。そして、漏れたときの手順を先に決めておくことです。
AI GatewayのようにキーをCloudflare側で預かる機能もありますが、この4つは、その導入の有無にかかわらず必要です。権限管理・監査・ローテーションの要件に応じて、管理サービスを追加します。
なぜAPIキーは漏れるのか
よくあるのは、コードの中に直接書いてしまうケースです。試作のときに書いたキーが、そのままコミットされます。あとで消しても、Gitの履歴には残ります。
ブラウザ側に渡してしまうケースもあります。フロントエンドのコードに入れたキーは、ビルドしても読めます。「環境変数に入れた」つもりでも、ビルド時に埋め込まれる設定なら同じことです。
共有の過程で広がることもあります。チャット、スクリーンショット、画面共有、ログ出力と、人の手を通るたびに、漏れる場所が増えていきます。
解決策の比較
方法 | 費用 | 手間 | 向いている状況 |
|---|---|---|---|
環境変数・シークレット + Gitの防止策 | 無料 | 少ない | すべてのケースで最低限必要 |
クラウドのシークレット管理サービス | 小さい | 中くらい | キーの数が多い、チームで管理する |
パスワード管理ツールで共有 | 有料が多い | 少ない | チーム内でキーを受け渡す機会がある |
AI GatewayなどでキーをCloudflareに預ける | 無料〜 | 少ない | すでにAI Gatewayを使っている場合の追加策 |
どれを選ぶか
一人で開発しているなら、環境変数またはシークレットと、Gitの防止策を基本にします。チームでキーを使い回している場合は、それに加えてパスワード管理ツールで受け渡します。サーバーやサービスが多いなら、シークレット管理サービスでまとめて管理します。
手順
1. キーの置き場所を決める
ローカル開発では .env に書き、最初のコミットの前に .gitignore へ入れておきます。本番では、ホスティング先のシークレット機能を使います(例:Workersなら wrangler secret put、Vercelなら環境変数の設定画面)。そして、ブラウザで動くコードには、キーを入れません。 必ず、サーバー(またはWorkers)を1枚はさみます。
[ブラウザ] --質問だけ--> [サーバー / Workers] --APIキー付き--> [LLM API]
キーはここ(環境変数・シークレット)にだけ置く# .gitignore
.env
.env.*
.dev.vars
.dev.vars.*2. Gitに入らない仕組みを作る
GitHubでは、Secret scanning が漏えいの検出を、Push protection がpush時のブロックを担当します。公開リポジトリのスキャンは、無料で自動的に実行されます。組織の非公開・内部リポジトリでは、GitHub TeamまたはEnterprise Cloudで、GitHub Secret Protectionの有効化が必要です。利用できる場合は、リポジトリの「Settings」→「Security」の設定で、Push protectionを有効にしてください。
手元でも、コミット前に検査するツール(gitleaksなど)を入れておくと安心です。
また、これまでのコミット履歴にキーが混ざっていないか、手元のターミナルで一度検索しておくと安心です。
# 全ブランチの履歴から、「sk-」に続いて長い英数字が並ぶ文字列を追加・削除したコミットを探す簡易確認
git log --all -p -G "sk-[A-Za-z0-9_-]{20,}"OpenAIやAnthropicのキーは sk- から始まります。ほかのサービスのキーは、管理画面に表示される先頭の文字列に置き換えて検索します。これは簡易確認で、すべての形式のキーを見つけられるわけではありません。結果にはキーがそのまま表示されるので、画面共有中には実行しません。見つかった場合は、履歴を消すより先に、手順4のとおりキーを無効化します。
3. キーを分け、上限と権限を絞る
キーは、開発用と本番用、さらにアプリごとに分けます。こうしておけば、1本漏れても、影響する範囲が小さく済みます。
プロバイダーの管理画面では、予算通知と、利用できる場合はリクエストを停止する上限を設定します。通知だけの予算設定を、強制的に止める仕組みと混同しないようにしてください。権限を選べるプロバイダーなら、使う機能だけに絞っておきます。
4. 漏れたときの手順を決めておく
漏れに気づいたら、最初の30分で次の順に動きます。
- キーを無効化する。 管理画面から削除または無効化します。まず止めることを優先します。
- 新しいキーを発行して、差し替える。 本番のシークレットを更新し、アプリが動くことを確認します。
- 利用履歴を確認する。 心当たりのない利用がないか、使用量の画面で確認します。
- 漏れた経路をふさぐ。 Gitの履歴に残っている場合、履歴を書き換えても、すでに複製された可能性があります。キーの無効化が本当の対策です。
- 必要なら、プロバイダーに連絡する。 不正利用があった場合は、サポートに相談します。
チームで開発している場合は、次の文面をWikiやチャットの固定メッセージに貼っておくと、いざというときに迷いません。
【APIキーが漏れたかもしれないとき】
気づいた人が、すぐに
#〇〇チャンネルで「キー漏えいの疑い」と書き込む(確証がなくてよい)担当者(〇〇)が、管理画面でキーを無効化する。不在なら気づいた人が無効化してよい
新しいキーを発行し、本番のシークレットを差し替えて動作を確認する
使用量の画面で、心当たりのない利用がないか確認する
漏れた経路(Git・チャット・ログなど)と対応内容を記録する
キーを無効化しても怒られません。止めるのが先です。
〇〇の部分は、自社の担当者や連絡先に書き換えて使います。
更新日:2026-11-03
つまずきやすい点
「環境変数に入れたから安全」とは限りません。Viteの VITE_ やNext.jsの NEXT_PUBLIC_ のように、名前の頭によって、ブラウザ側に埋め込まれる変数があります。
ログにキーが出ていないかも確認しましょう。エラー時にリクエスト全体をログに出力していると、ヘッダーに入ったキーまで記録されます。
意外と見落としがちなのが、AIツールに貼ってしまうケースです。コードの相談で、AIに .env の中身ごと貼ってしまうのも、漏れる経路の一つです。
次に出やすい悩み
キーの置き場所が固まったら、次は「キーは守れても、公開したAPIそのものが悪用される」問題と、AIに読ませる文章を経由した攻撃に目を向けます。キーは安全でも、公開したAPIを大量に叩かれているなら「ボットにAPIを食いつぶされる」を、万一の漏えいに備えて金額の上限も持たせておきたいなら、Phase 2の「LLM APIの請求額が読めない」を読んでみてください。AIに外部の文章を読ませる機能を作るなら、「プロンプトインジェクションへの備えが分からない」もあわせて確認しておくと安心です。
「社内のどこに、どのキーがあるか把握できていない」という状態からでも大丈夫です。キーの棚卸しを含めた、社内のIT運用の整理はIT顧問でご相談いただけます。
よくある質問
Q. 環境変数に入れれば、APIキーは利用者から見えませんか？
ブラウザ向けに公開される環境変数には注意が必要です。本文で挙げたVITE_やNEXT_PUBLIC_のような接頭辞を持つ変数は、配信されるコードへ値が含まれる場合があります。秘密のキーはサーバー側で保持し、ビルド結果やログにも混ざっていないか確認します。
Q. APIキーをGitへ入れてしまったら、ファイルを消すだけで十分ですか？
漏えいした可能性のあるキーは、まず失効させ、新しいキーへ切り替えます。ファイルを削除しても、過去のコミットやコピーに値が残る場合があります。利用履歴と請求への影響を調べ、Gitへの混入を防ぐ設定や検出の仕組みを見直します。
Q. 開発用と本番用で、同じAPIキーを使ってもよいですか？
環境や用途ごとに分け、必要な権限と利用上限に絞ると、漏えい時の影響を抑えやすくなります。開発用の作業で本番のデータや権限に触れない構成にしてください。Workersを使う場合はシークレットの設定も参照できます。
Q. AIツールへコードを相談するとき、.envも渡してよいですか？
実際のAPIキーや認証情報は渡さず、ダミーの値に置き換えた設定例を使います。コードだけでなく、エラーログ、画面共有、スクリーンショットにも秘密が含まれていないか確認します。誤って共有した場合は、共有先から消すだけで終えず、キーの失効と利用履歴の確認を行います。
執筆者情報
IT顧問、AI・業務アプリ開発、SESを通じて、企業のIT活用を支援しています。代表の藤澤 昌隆は、2007年からシステム開発・運用に携わり、アクセンチュアでの業務ITコンサルティングを経て、2019年にパブロフ株式会社を設立しました。
AI活用の支援事例として、営業工程を支える7つの業務別AIアプリの構築を公開しています。アプリの開発に加え、入力・出力の形式、評価基準、テストケースの整備にも取り組んでいます。
記事の内容に関するご質問や誤りのご指摘は、お問い合わせ窓口へお寄せください。