---
title: "Firebase設定を防ぐAIプロンプトと公開前スキャン"
description: "Firebase設定をAI生成HTMLに含めさせないためのプロンプト設計と、公開前のスキャン方法を知りたい開発者向け。プロンプトの書き方・スキャンコマンド・CI組み込み手順まで一連の流れを判断できる。"
image: "https://giga-site.com/og-image.png"
canonical: "https://giga-site.com/articles/firebase-config-prompt-scan"
markdown: "https://giga-site.com/articles/firebase-config-prompt-scan/index.md"
category: "セキュリティ"
publishedAt: "2026-06-25"
updatedAt: "2026-06-25"
readingMinutes: 5
---
# Firebase設定を防ぐAIプロンプトと公開前スキャン

Firebase設定がHTMLに混入するのを防ぐには、AIへのプロンプトに制約を加えることと、生成後にスキャンを実施することの2段階が有効だ。特にサービスアカウントキーの混入はプロンプトの工夫だけでなく、スキャンで確認を取るまで安心できない。実践的な手順とコマンドを解説する。

> Source HTML: https://giga-site.com/articles/firebase-config-prompt-scan
> Article index: https://giga-site.com/articles/index.md

## なぜ危ないのか

AIはFirebaseを使ったHTMLを生成する際、動作デモのために本物の設定値を使おうとする傾向がある。特にユーザーがプロジェクト固有の情報（プロジェクト名やURLなど）をプロンプトに含めると、AIがその情報を推測してapiKeyやprojectIdらしき文字列を生成することがある。生成された値が実際のキーでなくても、本物に似た形式の文字列が含まれることでスキャンの判断が難しくなる。

サービスアカウントキーの混入はより深刻で、AIがサーバー向けコードとクライアント向けコードを区別せずに生成した場合に起こりやすい。Firebase Admin SDKを使うNode.jsコードの一部がHTMLの`<script>`タグに混入し、`private_key`が文字列として含まれるケースがある。この状態のHTMLをそのまま公開またはメール送信した場合、Admin権限のキーが外部に露出する。

- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく

## ソースで見る場所

`grep -n 'private_key\|BEGIN PRIVATE KEY' index.html` を実行してサービスアカウントキーの有無を確認する。次に `grep -n 'apiKey.*:.*[A-Za-z0-9_-]{20,}' index.html` でapiKeyに実値が設定されていないかをチェックする。どちらもヒットがなければキーの混入リスクは低い。これらのコマンドをシェルスクリプト化しておくと毎回の手間が省ける。

`firebaseConfig` オブジェクト全体をまとめて確認したい場合は `grep -A 10 'firebaseConfig' index.html` を実行する。`-A 10` でマッチ行から10行後まで表示されるため、設定オブジェクトの内容を一覧できる。プレースホルダ文字列（`YOUR_`で始まるもの）のみが含まれていれば安全な状態だ。

- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する

## 安全に共有する設定

プロンプトに「Firebase設定はすべてプレースホルダで記述する。`apiKey: 'YOUR_FIREBASE_API_KEY'`のように具体的な値を使わない。サービスアカウントキー（private_keyを含むJSON）は絶対に生成しない。」という制約を入れる。この3行の制約文が生成物の品質を大きく変え、スキャンで実値が検出されるリスクを大幅に下げる。

スキャン通過後はアクセス制限付きの共有リンクで配布する。受け取る人数が少ないほど漏えいリスクが下がるため、必要なレビュアーだけをリストアップして認証を設定する。Firebaseコンソールにアクセスできる場合は、共有期間中にFirestoreのアクセスログを定期的に確認し、想定外のアクセスがないかをモニタリングする。

- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する

## 再発防止ルール

Firebase関連のHTMLプロンプトテンプレートをMarkdownファイルとして管理し、Gitリポジトリに含める。テンプレートの先頭ブロックにセキュリティ制約をコメントで記録し、チームメンバーが参照できるようにする。テンプレートの変更もGitの差分として追跡できるため、制約が意図せず削除されたときに気づける。

CI/CDに `grep -r 'BEGIN PRIVATE KEY' ./src/` を含むジョブを追加し、プルリクエスト時に自動実行されるようにする。検出時はビルドを失敗させ、マージをブロックする。これにより手動スキャンの漏れをCIが補完する二重チェック体制ができる。

- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する

## よくある質問

### プロンプトでプレースホルダを指示したのに、AIが実際のapiKey形式の文字列を生成することはありますか？

AIは制約を守る確率が高いが、会話が長くなると指示が薄れることがある。制約をプロンプトの先頭に置き、具体例（`apiKey: 'YOUR_FIREBASE_API_KEY'`）を提示する形式にすると遵守率が上がる。生成後のgrepスキャンで常に二重確認することが重要だ。

### Firebase Emulatorを使ったローカルデモのHTMLはスキャン不要ですか？

Firebase Emulatorのlocalhostエンドポイントを使っていればapiKeyは実際のプロジェクトに接続しないが、HTMLの設定オブジェクトに本番プロジェクトのapiKeyが同時に書かれているケースがある。共有前は本番設定の有無を確認するスキャンを必ず実施する。

### スキャンで `private_key` が検出されたが、それがサンプルテキストの場合でも対処が必要ですか？

文字列が `BEGIN PRIVATE KEY-----` を含む本物のPEM形式であれば緊急対処が必要だ。単に `private_key` というキー名がJSONのプレースホルダとして書かれているだけであれば、そのキーの値がプレースホルダかどうかを確認する。値が本物の秘密鍵形式でなければ共有は許容できる範囲だが、混乱を避けるためにキー名ごと削除するのが安全だ。

## 関連記事

- [AI生成HTMLにFirebase設定が残っていないか確認する方法](https://giga-site.com/articles/firebase-config-check/index.md)
- [Firebase設定を含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/firebase-config-risk-countermeasure/index.md)
- [社外レビュー前にFirebase設定を検出するチェックリスト](https://giga-site.com/articles/firebase-config-external-review-checklist/index.md)
- [APIキー直書きを防ぐAIプロンプトと公開前スキャン](https://giga-site.com/articles/hardcoded-api-key-prompt-scan/index.md)
- [外部フォーム送信先を防ぐAIプロンプトと公開前スキャン](https://giga-site.com/articles/external-form-action-prompt-scan/index.md)
- [フィッシングに見える文言を防ぐAIプロンプトと公開前スキャン](https://giga-site.com/articles/phishy-copy-prompt-scan/index.md)

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Firebase設定を防ぐAIプロンプトと公開前スキャン",
  "description": "Firebase設定をAI生成HTMLに含めさせないためのプロンプト設計と、公開前のスキャン方法を知りたい開発者向け。プロンプトの書き方・スキャンコマンド・CI組み込み手順まで一連の流れを判断できる。",
  "datePublished": "2026-06-25",
  "dateModified": "2026-06-25",
  "mainEntityOfPage": "https://giga-site.com/articles/firebase-config-prompt-scan",
  "url": "https://giga-site.com/articles/firebase-config-prompt-scan",
  "inLanguage": "ja",
  "image": "https://giga-site.com/og-image.png",
  "articleSection": "セキュリティ",
  "author": {
    "@type": "Organization",
    "name": "ギガサイト便"
  },
  "publisher": {
    "@type": "Organization",
    "name": "ギガサイト便"
  },
  "mainEntity": [
    {
      "@type": "Question",
      "name": "プロンプトでプレースホルダを指示したのに、AIが実際のapiKey形式の文字列を生成することはありますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AIは制約を守る確率が高いが、会話が長くなると指示が薄れることがある。制約をプロンプトの先頭に置き、具体例（`apiKey: 'YOUR_FIREBASE_API_KEY'`）を提示する形式にすると遵守率が上がる。生成後のgrepスキャンで常に二重確認することが重要だ。"
      }
    },
    {
      "@type": "Question",
      "name": "Firebase Emulatorを使ったローカルデモのHTMLはスキャン不要ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Firebase Emulatorのlocalhostエンドポイントを使っていればapiKeyは実際のプロジェクトに接続しないが、HTMLの設定オブジェクトに本番プロジェクトのapiKeyが同時に書かれているケースがある。共有前は本番設定の有無を確認するスキャンを必ず実施する。"
      }
    },
    {
      "@type": "Question",
      "name": "スキャンで `private_key` が検出されたが、それがサンプルテキストの場合でも対処が必要ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "文字列が `BEGIN PRIVATE KEY-----` を含む本物のPEM形式であれば緊急対処が必要だ。単に `private_key` というキー名がJSONのプレースホルダとして書かれているだけであれば、そのキーの値がプレースホルダかどうかを確認する。値が本物の秘密鍵形式でなければ共有は許容できる範囲だが、混乱を避けるためにキー名ごと削除するのが安全だ。"
      }
    }
  ]
}
```