APIキーをサイトのコードに書いてもいいですか？
シークレットキーは書いてはいけません。ブラウザが実行するもの — HTML、JavaScript、CSS — はすべて訪問者に送られるため、ページに貼ったシークレットキーは公開した瞬間に公開情報になり、圧縮しても三つの文字列に分割しても何も変わりません。一方、ページに置くことを前提としたキーもあります。提供元はそれをパブリック用のキーと明示し、公開されても安全なように権限を絞っています。すでに公開中のページにシークレットキーがある場合は、ページを直す前に提供元でキーを再発行してください。ページを非公開にしても、すでに配信されたものは取り消せません。
ページが秘密を保持できない理由
ブラウザは実行するものすべてを受け取る必要があります。これは特定のホスティングやフレームワークの欠陥ではなく、ページを配信するということの意味そのものです。訪問者の端末は、コードを渡されなければあなたのコードを実行できません。そのため、ブラウザに標準で付いている開発者ツールだけで中身は読めてしまい、専門知識も追加のソフトも要りません。圧縮、base64エンコード、断片の連結によるキーの組み立ては、いずれも組み立て後の値を誰かが眺めるまでの時間しか持ちません。しかもその値は、送信されるリクエストの中身としてネットワークタブがそのまま見せてしまいます。
つまり重要な区別は、隠れているか見えているかではありません。二種類の資格情報の違いであり、提供元がその名前を教えてくれます。パブリック用のキーはページに置くために設計されたもので、決済サービスの公開可能キー、アナリティクスの測定ID、自分のドメインに限定した地図のキーなどが該当します。これらは設計上公開されるもので、提供元側で権限が囲われているため、フロントエンドのコードに置くのは正しく、危険ではありません。シークレットキーはまったく別物です。通常はアカウントの権限をそのまま持つため、カードへの課金、顧客情報の読み取り、あなたの名前でのメール送信、API予算の消費までできてしまいます。それをページを開いた誰にでも渡してしまうことが本当の間違いであり、「このアドレスはまだ誰も知らない」は防御になりません。公開直後のサイトや公開リポジトリを継続的に巡回し、まさにこれを探しているスキャナーが存在します。
すでに公開されているなら、片付ける前に再発行する
つい、その行を削除して再公開したくなります。先にやるべきことは別です。非公開にしても、すでに配信されたものは取り戻せません。古いバージョンはCDNのエッジキャッシュ、検索エンジンのキャッシュ、アーカイブサービス、訪問者のブラウザに残り得ます。ページがリポジトリにあるなら、キーはコミット履歴に残り、後のコミットで行を消しても前のコミットは完全に読める状態のままです。露出を実際に終わらせる唯一の手順は、提供元で資格情報を無効化することです。キーの正しさを確認しているのは、提供元だけだからです。
- 古いキーを失効または更新して動かなくする — 隣に二つ目のキーを作るだけでは何も変わりません。
- 代わりのキーを発行し、ページから読めない場所に置く。実務上はサーバー側の設定を意味します。
- 露出していた期間全体について提供元の利用ログや監査ログを読み、自分が行っていない呼び出しを探す。
- そのキーで金銭を動かせる、あるいは顧客情報に届く場合は、心当たりのない請求を確認し、提供元の規定と自分の義務に従って影響を受けた相手に連絡する。
- そのうえでページを直す — 修正の確認は編集画面を信じるのではなく、公開済みページを取得してレスポンスの中を古い値で検索する。
キーを置くべき場所と、公開中のページで見つけたこと
うまくいく形は、ページが秘密をいっさい持たないことです。ページは自分が管理するものを呼び出し、そちらがキーを保持して外部への通信を行い、訪問者のブラウザはあなたとしか通信しません。多くの場合それを自分で運用する必要はありません。提供元のホスト型ウィジェットや、マネージドのバックエンドサービスが、この用途でのサーバーの役目を果たします。それ以上が必要かどうかは別の問いで、サイトにバックエンドは必要かが実際の境界を扱っています。
自分たちでホスティングを運用して、この点について直感に反することを学びました。AgentCeres — agentceres.com のAI Growth Officer — はエージェントが顧客のために作ったページをホストしており、そのすべてのページは、ページからのネットワークリクエストを一切禁止するコンテンツセキュリティポリシーとともに配信されています。そうしたページに埋め込まれたキーは、そのページからは使うことすらできません。コードは動き、計算し、遷移できますが、送信先がどこにもないのです。この封じ込めは訪問者をページから守ります。そして、訪問者からキーを隠すことについては何もしません。人が無料で手に入ると思い込んでいるのは、まさにこちら側の半分です。
2026-09-17、顧客が公開したページを読み進めていて、JavaScriptが決済サービスの有効なシークレットキーを変数に代入しているページを見つけました。同じファイルの下の方には、顧客の身分証番号が直接書き込まれた検索用の関数もありました。どちらも推測ではなく、公開中のページを取得して確認しています。特別なことは起きていません。オーナーがそのキーを必要とする機能を頼む際にチャットへキーを貼り、それがページに書き込まれた、というだけです。ここから出てきた教訓こそ持ち帰る価値があります — 自分のページを書く相手には、コードアシスタントを含め、有効な秘密情報を決してチャットに貼らないこと。相手にとって自然な振る舞いは、コードのある場所でそのキーを使うことなのです。
同じ点検で、逆方向の漏えいも見つかりました。ほとんど誰も確認しないので、知っておく価値があります。生成されたページは、会員エリアを頼まれるとログインや登録のフォームを含めます。認証を行うサーバーが背後に存在しない場合でも同じで、そうしたページのフォームはすべてフォーム受信側に接続されます。その結果、そこにパスワードを入力した訪問者は、それを平文で保存され転送されていました。2026年9月の二件では、第三者の実在するメールアドレスとパスワードが含まれ、オーナーの受信箱にはごく普通の問い合わせのように届いていました。現在は資格情報らしいフィールド名を検出し、保存・送信・表示のいずれよりも前にその値を除去しています。また新しく公開されるページでは、そもそもそのフィールドを送信できないようにしています。誰がページを作ったかに関係なく、一般的な教訓は変わりません。ページは両方向に漏れ得ます。あなたのキーは外へ、訪問者のパスワードは内へ。
よくある質問
- パブリック用のAPIキーをサイトに置くのは安全ですか？
- はい。そのために存在するキーであり、それを必要とするフロントエンドの機能に他の選択肢はありません。単に許されているだけでなく安全だと言えるのは、二つの条件があるからです。提供元がそのキー種別にできることを制限していること、そして提供元が用意している制限 — 通常はキーが応答するドメインの指定 — をあなたが設定していることです。制限をかけなくてもパブリック用キーがアカウントを危険にさらすことはありませんが、他人のサイトから使われて費用があなたに請求される可能性があります。
- 環境変数に入れれば秘密のままにできますか？
- それを読むコードがサーバー上で動く場合だけです。これは最もよくある誤解です。フロントエンドのビルドツールは、公開用の接頭辞が付いた環境変数 — NEXT_PUBLIC_、VITE_、REACT_APP_ とその同等物 — をビルド時にバンドルへ意図的に埋め込みます。変数はプロジェクト設定の中では非公開でも、値は配信するJavaScriptに焼き付けられ、結局そこに直接書いたのと同じようにページへ入ります。
- キーが露出しましたが、提供元には想定外の利用が見えません。それでも再発行は必要ですか？
- 必要です。静かなログが示すのは「まだ誰も使っていない」ことであり、「誰も持っていない」ことではありません。自動スキャナーは、何かに使うよりずっと前にキーを収集するのが普通です。再発行にかかるのは今の数分で、代わりに残るのは見張りでは閉じられない期限のないリスクです。きれいなログは過去についての良い知らせとして扱い、将来についての判断としては扱わないでください。
この作業、任せてみませんか？
AgentCeres はマネージド型の AI マーケティングチームです。スペシャリストが下書きを作り、何を公開するかはあなたが承認します。14日間無料トライアル、月額 $39 から。