ブラウザに置いてよいキーは、サービスが「公開用」として発行し、公式ドキュメントにそう書かれているものだけです。それ以外のキーは、自分のサーバー側に置きます。公開用のキーも、データを守る設定（RLS、セキュリティルール、利用元の制限など）が前提です。この記事では、サービスごとに、公式ドキュメントに書かれていることを整理します。
この記事の位置づけ
キーが外から見えていないかを確かめる方法は、APIキーがブラウザやコードから見えていないかに書いています。この記事は、その具体編です。「見えているキーが、見えてよいものか」を、サービスごとに判断するための一覧です。漏れてしまったあとの手順は、APIキーが漏れたあと、最初にやることにあります。
公式ドキュメントの記述は、2026年10月時点のものです。仕様は変わるので、使う前に、各サービスの最新の公式ドキュメントを確認してください。
一覧
| サービス | ブラウザに置いてよいキー | 置いてはいけないキー | 置くなら、何で守るか |
|---|---|---|---|
| Supabase | publishable キー（従来の anon） |
secret キー（従来の service_role） |
RLS |
| Firebase | Web アプリ用の設定値に含まれる API キー | （この一覧では、Gemini Developer API のキー） | Security Rules、App Check |
| Google Maps | Maps JavaScript API 用のキー（制限をかけたもの） | 制限をかけていないキー | Websites の制限、API の制限 |
| Gemini | なし（公式は、キーを直接書き込まず、バックエンドのプロキシ経由で呼ぶよう案内） | Gemini API のキー | バックエンド経由で呼ぶ |
| OpenAI | 公式は、キーをコードや公開リポジトリに置かないよう案内 | OpenAI の API キー | 環境変数など |
| Stripe | 公開可能キー（pk_） |
シークレットキー（sk_）、制限付きキー（rk_） |
公開可能キーでできることが限られている |
| SendGrid | （確認した範囲では案内なし） | API キー | 環境変数、権限の範囲 |
以下、サービスごとに、公式の記述を紹介します。
Supabase
公式ドキュメントは、キーを2種類に分けています。
- publishable キー（従来の
anon）。 「Safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code.」（訳: オンラインで公開しても安全: ウェブページ、モバイルまたはデスクトップアプリ、GitHub Actions、CLI、ソースコード。）と書かれています。置く前提で作られたキーです。 - secret キー（従来の
service_role）。 サーバーなど、自分が管理する場所で使うものです。公式は「Policies never apply to a secret key, becauseservice_rolehas theBYPASSRLSattribute.」（訳: ポリシーは secret キーには適用されません。service_roleにはBYPASSRLS属性があるためです。）と書いています。RLS の対象にならないので、ブラウザに届くコードに入っていたら、RLS の設定に関わらず、データに触れられます。
公開用のキーの安全は、RLS が前提です。公式は「Write your Row Level Security policies for the anon and authenticated roles.」（訳: anon ロールと authenticated ロールに対する Row Level Security ポリシーを書いてください。）と書いています。また、公式は、anon と service_role を2026年末までに廃止する予定だと書いています。
RLS の確かめ方や、バックアップを含む本番前の確認は、Supabaseを本番で使う前に見る設定に詳しく書いています。
Firebase
Firebase は、他のサービスと考え方が違います。公式ドキュメントは、Firebase サービス向けの API キーは、プロジェクトとアプリを識別するだけだと書いています。
API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.
（訳: Firebase サービス向けの API キーは、それらのサービスに対して、あなたの Firebase プロジェクトとアプリを識別するだけです。認可は、Google Cloud IAM の権限、Firebase Security Rules、Firebase App Check によって行われます。）
そのため、Firebase のサービスに制限された API キーは、「it's safe to include them in your code or configuration files」（訳: コードや設定ファイルに含めても安全）と書かれています。データを守るのは、キーを隠すことではなく、Security Rules と App Check です。公式は「Security of your Realtime Database, Cloud Firestore, and Cloud Storage data is enforced using Firebase Security Rules...— not by keeping your Firebase API key secret.」（訳: Realtime Database、Cloud Firestore、Cloud Storage のデータの安全性は、Firebase Security Rules を使って担保されます。Firebase の API キーを秘密にすることによってではありません。）と書いています。
つまり、Firebase は、キーが見えていてもよい代わりに、Security Rules の設定が守りの本体です。ルールが緩いままだと、キーが公開用でも、データは守られません。これは私たちの整理です。
同じページには、例外も書かれています。Gemini Developer API を呼ぶためのキーは「should never be included in your code or configuration files」（訳: コードや設定ファイルに決して含めてはならない）で、公開から守る必要がある、と書かれています。Firebase の設定値と、Gemini のキーを、同じものとして扱わないでください。
Google Maps
Maps は、キーをページに置いて使う代表例です。公式ドキュメントは、キーに制限をかけるよう強く案内しています。
Restrict you API keys to prevent unauthorized usage. You are financially responsible for charges caused by abuse of unrestricted API keys.
（訳: 不正な利用を防ぐため、API キーを制限してください。制限のない API キーが悪用されて生じた請求については、利用者が金銭的な責任を負います。）
制限は2種類あります。
- アプリケーションの制限。 Maps JavaScript API などを使うウェブサイトには、「Websites」の制限を使うと書かれています。許可するサイトを指定します。公式は、参照元の文字列は、スキーム（
https://など）、ホスト名、必要ならポートを含めて、全体を指定するよう書いています。 - API の制限。 そのキーで使える API やサービスを絞ります。
つまり、Maps は、キーが見えていることを前提に、使える場所と使える API で守るサービスです。制限をかけていないキーが悪用されると、請求は利用者の責任になると、公式が書いています。
Gemini と OpenAI
生成 AI の API キーは、使われると課金が発生します。公式の案内は、どちらも「ブラウザに置かない」方向です。
Gemini。 公式ドキュメントは「Do not hardcode API keys directly in web or mobile apps. Keys compiled in client-side code can be extracted by users.」（訳: API キーをウェブアプリやモバイルアプリに直接ハードコードしないでください。クライアント側のコードに組み込まれたキーは、利用者に取り出される可能性があります。）と書いています。続けて、クライアント側のアプリを守るには「run a backend proxy server to make the actual API calls」（実際の API 呼び出しを行うバックエンドのプロキシサーバーを動かす）と案内しています。キーが漏れた場合は、他の人がプロジェクトの割り当てを消費し、想定外の請求が発生しうると書かれています。
OpenAI。 公式ドキュメントは「Avoid exposing the API keys in your code or in public repositories; instead, store them in a secure location.」（訳: API キーをコードや公開リポジトリに露出させないでください。代わりに、安全な場所に保管してください。）と書き、環境変数やシークレット管理サービスで渡すよう案内しています。また、プロジェクトの API キーには有効期限を設定し、定期的に入れ替える仕組みを作るよう勧めています。
この2つは、画面から直接 AI を呼ぶ作りにせず、自分のサーバーを間に置く、という形で守ります。AI にアプリを作らせると、動かすために、ブラウザから直接 API を呼ぶコードになることがあります。作ってもらった構成が、そうなっていないかを確かめてください。
Stripe
Stripe のドキュメントには、キーの種類と、ブラウザに置いてよいかが表になっています。
| キー | 安全に公開可能か | 公式の説明の要点 |
|---|---|---|
公開可能キー pk_... |
はい | 支払い詳細からトークンなどを作れるが、支払いの作成やアカウントデータの読み取りなど、機密性の高い操作はできない。フロントエンドのコードに含めることができる |
制限付きキー rk_... |
いいえ | 権限を管理できる。漏れた場合の被害を限定する |
シークレットキー sk_... |
いいえ | すべての API に対して無制限の権限を持つ |
公式は「アプリケーションのバックエンド外部に公開しても安全なのは、公開可能キーのみです」と書いています。ブラウザに置いてよいのは、pk_ で始まる公開可能キーだけです。
サーバー側のキーについて、公式は、制限付きキーを使うよう勧めています。権限を絞れないシークレットキーは、新しい使い方では推奨されていません。また、キーをソースコードや設定ファイルに書かず、シークレットの保管庫か環境変数で渡すよう案内しています。
SendGrid
SendGrid は、メールを送るサービスです。公式ドキュメントは、API キーを「Treat your API key like a password and store it somewhere safe.」（訳: API キーをパスワードのように扱い、安全な場所に保管してください。）と書いています。また「Never include your API Key in your code or commit it to a public location or repository like GitHub.」（訳: API キーをコードに含めたり、GitHub のような公開された場所やリポジトリにコミットしたりしないでください。）と書き、環境変数に入れるよう案内しています。
私たちが確認した範囲では、SendGrid の API キーのページに、ブラウザ向けの公開用キーの案内は見当たりませんでした。メールの送信は、自分のサーバーから行う形にしてください。キーを作るときには、権限のレベル（Full Access や Custom Access など）を選べます。何ができるキーかを、必要な範囲に絞るのが望ましいと私たちは考えます。
迷ったときの判断
キーの種類が分からないときは、次の順番で判断します。これは、私たちの整理です。
- 公式ドキュメントに、「ブラウザに置いてよい」と明記されているか。 上で見たように、サービスごとに答えが違います。作った本人の記憶や、AI の答えでは決めません。
- 明記されていなければ、ブラウザには置かない。 画面から直接呼ぶ作りになっているなら、自分のサーバーを間に置く形に変えます。
- 置いてよいキーでも、守りの設定を確かめる。 RLS、セキュリティルール、利用元の制限が効いているかを見ます。
私たちの経験
2015年、私たちは、仕事で使っていた AWS アカウントのアクセスキーを、公開の GitHub リポジトリに上げてしまいました。当時は仮想通貨のマイニングが流行っていて、拾われたキーでサーバーを大量に立てられ、不正利用の請求は7千ドル強にまで膨らみました。返金はかろうじて認めてもらえましたが、AWS の窓口から示された条件は「今回限り」でした。詳しくは、APIキーが漏れたあと、最初にやることに書いています。
この経験から、どのキーが外に出てよいかは、あとではなく、置く前に決めるものだと考えています。また、診断や本番化の中で、API キーなどの秘密情報が、フロントエンドや公開リポジトリにむき出しになっているのを、見たことがあります。動かすことが目的のとき、鍵の置き場所は後回しになりやすいのです。
wizgeek にできること
キーの置き場所や、画面から直接外部サービスを呼ぶ作りになっていないか、不安が残るときは、ご相談ください。試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。本番化の作業は別途お見積りします。
まずは、AIで作ったアプリの本番化のご相談からお問い合わせください。