---
title: "社外レビュー前にFirebase設定を検出するチェックリスト"
description: "社外レビュー用のHTML共有前にFirebase設定を確実に検出したい担当者向け。確認すべき具体的な文字列・設定箇所と、問題発見時の対処手順が分かり、安全に共有を進められる。"
image: "https://giga-site.com/og-image.png"
canonical: "https://giga-site.com/articles/firebase-config-external-review-checklist"
markdown: "https://giga-site.com/articles/firebase-config-external-review-checklist/index.md"
category: "セキュリティ"
publishedAt: "2026-06-25"
updatedAt: "2026-06-25"
readingMinutes: 5
---
# 社外レビュー前にFirebase設定を検出するチェックリスト

社外の委託先や協力会社にHTMLデザインのレビューを依頼する前に、Firebase設定がソース内に残っていないかを確認するのは重要な工程だが、見落とされやすい。確認項目を毎回ゼロから考えるのではなく、工程ごとのチェックリストとして標準化することで、担当者が変わっても安全な共有を維持できる。

> Source HTML: https://giga-site.com/articles/firebase-config-external-review-checklist
> Article index: https://giga-site.com/articles/index.md

## なぜ危ないのか

社外レビュアーはHTMLを受け取った後、そのソースコードを詳細に確認することがある。デザイン確認のつもりで送ったHTMLにFirebaseのapiKeyやプロジェクトIDが含まれていれば、悪意がなくてもその情報が別の場所で使用されるリスクが生じる。特にFirebaseのセキュリティルールが不十分なプロジェクトでは、apiKeyさえ手に入れればFirestoreに直接クエリを発行できてしまう。

サービスアカウントキーが混入しているHTMLを社外に送るのは最も深刻なミスだ。`private_key` フィールドが含まれるJSONをHTMLにそのまま貼り付けると、受け取った側はそのキーを使ってFirebaseのAdmin権限を取得できる。AI生成コードはサービスアカウントを使うサーバー向けコードとクライアント向けコードを混同することがあるため、送信前の確認が必須だ。

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

## ソースで見る場所

チェック1：HTMLを開いて `private_key` または `BEGIN PRIVATE KEY-----` を全文検索する。ヒットがあれば即座に共有を中止し、該当のサービスアカウントキーをFirebaseコンソールで削除する。これが最優先の確認項目だ。

チェック2：`firebaseConfig` を検索し、apiKeyの値が実際の文字列（英数字とハイフンが混じった長い文字列）か、プレースホルダ（`YOUR_API_KEY`など）かを確認する。実際の値が含まれている場合は、Firebaseコンソールでセキュリティルールを確認してから共有するかどうかを判断する。projectId（`.firebaseapp.com`形式のドメイン）も同様に確認する。

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

## 安全に共有する設定

チェック1でヒットなし、かつチェック2でaplKeyがプレースホルダの場合は安全に共有できる状態だ。apiKeyが実際の値で含まれている場合は、Firebaseコンソールのセキュリティルールを確認し、全テーブルで `if true` になっていなければ許容範囲として扱える。確認に時間がかかる場合は、apiKeyをプレースホルダに置換してから共有する方が確実だ。

共有方法は認証付きのリンクを優先する。パスワードまたは特定のメールアドレス認証が必要なプレビューサービスを使うことで、リンクが誤転送されても閲覧できる人を制限できる。共有期間は48〜72時間を上限とし、レビュー完了の報告を受けたらリンクを失効させてFirebaseコンソールでアクセスログを確認する。

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

## 再発防止ルール

この2ステップのチェックをプロジェクト管理ツール（Notionのテンプレート・Trelloのチェックリスト等）に登録し、社外共有タスクに必ず紐付ける。「private_key検索」と「firebaseConfig確認」の2項目を完了しないとタスクを進めない運用ルールにすることで、確認漏れを組織的に防ぐ。

AIへのプロンプトにFirebase設定の扱いについて制約を加える習慣もつける。「Firebase設定はすべてプレースホルダで記述し、実際のapiKeyやprojectIdを含めないこと。サービスアカウントキーは一切使用しないこと。」の一文を毎回のプロンプト冒頭に入れるだけで、生成物に実際のキーが含まれる頻度を大幅に下げられる。

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

## よくある質問

### Firebase設定を含むHTMLを送ってしまった後の対処法を教えてください。

サービスアカウントキーが含まれていた場合はFirebaseコンソールで即座に削除する。apiKeyのみの場合はFirestoreのセキュリティルールを確認・修正し、全許可になっているルールがあれば認証必須に変更する。その後レビュアーに状況を説明し、受け取ったHTMLを削除するよう依頼する。

### チェックリストをpdfやWordに出力して共有できますか？

チェックリストはどのフォーマットで配布しても構わないが、チェック完了の記録が残る形式が望ましい。Notionのデータベース・Googleフォームでのチェック結果記録・スプレッドシートのチェックボックスなど、誰がいつ確認したかを追跡できる仕組みを選ぶことを推奨する。

### チェックをレビュアー側に依頼することは適切ですか？

Firebase設定の危険性を理解しているエンジニアであれば補完的なチェックを依頼できるが、主体は送信者側が行うべきだ。レビュアーに確認を委ねる運用は責任の所在を曖昧にするため、送信前に送信者が必ずチェックリストを消化することを原則とする。

## 関連記事

- [社外レビュー前に外部フォーム送信先を検出するチェックリスト](https://giga-site.com/articles/external-form-action-external-review-checklist/index.md)
- [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設定を防ぐAIプロンプトと公開前スキャン](https://giga-site.com/articles/firebase-config-prompt-scan/index.md)
- [社外レビュー前にAPIキー直書きを検出するチェックリスト](https://giga-site.com/articles/hardcoded-api-key-external-review-checklist/index.md)
- [社外レビュー前にフィッシングに見える文言を検出するチェックリスト](https://giga-site.com/articles/phishy-copy-external-review-checklist/index.md)

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "社外レビュー前にFirebase設定を検出するチェックリスト",
  "description": "社外レビュー用のHTML共有前にFirebase設定を確実に検出したい担当者向け。確認すべき具体的な文字列・設定箇所と、問題発見時の対処手順が分かり、安全に共有を進められる。",
  "datePublished": "2026-06-25",
  "dateModified": "2026-06-25",
  "mainEntityOfPage": "https://giga-site.com/articles/firebase-config-external-review-checklist",
  "url": "https://giga-site.com/articles/firebase-config-external-review-checklist",
  "inLanguage": "ja",
  "image": "https://giga-site.com/og-image.png",
  "articleSection": "セキュリティ",
  "author": {
    "@type": "Organization",
    "name": "ギガサイト便"
  },
  "publisher": {
    "@type": "Organization",
    "name": "ギガサイト便"
  },
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Firebase設定を含むHTMLを送ってしまった後の対処法を教えてください。",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "サービスアカウントキーが含まれていた場合はFirebaseコンソールで即座に削除する。apiKeyのみの場合はFirestoreのセキュリティルールを確認・修正し、全許可になっているルールがあれば認証必須に変更する。その後レビュアーに状況を説明し、受け取ったHTMLを削除するよう依頼する。"
      }
    },
    {
      "@type": "Question",
      "name": "チェックリストをpdfやWordに出力して共有できますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "チェックリストはどのフォーマットで配布しても構わないが、チェック完了の記録が残る形式が望ましい。Notionのデータベース・Googleフォームでのチェック結果記録・スプレッドシートのチェックボックスなど、誰がいつ確認したかを追跡できる仕組みを選ぶことを推奨する。"
      }
    },
    {
      "@type": "Question",
      "name": "チェックをレビュアー側に依頼することは適切ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Firebase設定の危険性を理解しているエンジニアであれば補完的なチェックを依頼できるが、主体は送信者側が行うべきだ。レビュアーに確認を委ねる運用は責任の所在を曖昧にするため、送信前に送信者が必ずチェックリストを消化することを原則とする。"
      }
    }
  ]
}
```