目次

2026年11月2日から、Firebaseはプロジェクト内の Firebase AI Logic に対して App Checkを自動強制できます（未強制の場合）。2026年10月27日のFirebaseリリースノートによれば、目的はFirebase AI Logic経由でGemini APIに到達する経路を保護することです。有効なApp Checkトークンを持たないリクエストは遮断され、対象には本番attestationを未実装のリリース済みアプリも含まれます——未完成のローカルビルドだけではありません。

本ガイドは、その期間向けの移行・切り分けチェックリストです。呼び出し経路の確認 → 一時延期の要否 → 本番attestationの実装 → リクエスト／App Check指標の監視 → 強制の有効化または確認。対象は常に Firebase AI Logic であり、あらゆるGemini API呼び出しではありません。Firebase AI Logicを経由しない直結のGemini APIトラフィックは別面であり、今回の11月2日自動強制の通知が狙う対象ではありません。

各プロジェクトの強制開始タイミングは、Firebaseコンソールの Security > App Check とリアルタイムのリクエスト指標で確認してください。参考情報。

予定の強制日で何が変わるか

Firebaseの2026年10月27日リリースノートは、2026年11月2日からFirebase AI Logic向けにApp Checkを自動強制できること、およびApp Check未実装のリリース版が残る場合に自動強制を一時延期できることを述べています。Firebase AI Logic FAQも同じ暦日を繰り返し、ハードストップを明示します。2027年1月21日以降は、Firebase AI Logicの自動強制を延期できなくなります。

公式文言は、具体的なUTC時刻や固有のタイムゾーン名を公表していません。「11月2日」を暦日として読む方が、真夜中のカットオフを捏造するより安全です。

強制がオンになると、FAQの失敗モードは明確です。有効なApp CheckトークンなしでFirebase AI Logicへ向かうリクエストは遮断され、本番attestationプロバイダを実装していないリリース版からのトラフィックも含みます。そのため「開発環境ではdebugトークンで動くが、ストア版だけ失敗する」という分裂が起き得ます——多くのチームが報告する典型パターンです。

手順1 — 呼び出し経路がFirebase AI Logicか確認する

強制日を動かす前に、失敗トラフィックが本当に Firebase AI Logic クライアントSDK／Firebase AI Logic経路経由か、App Checkをこの製品で通さないバックエンドからの素のGemini Developer API／Agent Platform Gemini API呼び出しかを切り分けます。

実務上の確認例：

  • クライアント初期化がFirebase AI Logic SDKの入口であること（モバイル、Web、Flutter、Unityなど）。App Checkを完全に迂回するサーバ専用Geminiクライアントではないこと。
  • プロジェクトでFirebase AI Logicが有効で、失敗面がその製品経由でGeminiへ達するアプリであること。
  • エラー時刻が Security > App Check > APIs のAI Logic行の強制状態と整合し、無関係なAPIキー・クォータ・モデル名404ではないこと。

呼び出しがFirebase AI Logicを一切使わないなら、この11月2日App Check自動強制のプレイブックは誤りです。その経路は公式ドキュメント側で別途切り分けます。

関連するDigIntoAI記事（Gemini APIのリクエスト保存デフォルト変更。App Checkとは別題）：Gemini API、新規有料プロジェクトでGenerate Contentリクエストを既定保存。

手順2 — 一時延期は移行バッファのみ

エンドユーザーがApp Check未実装ビルドに残っている場合、Firebaseは自動強制の一時延期を許可します。

  1. Firebaseコンソールを開く。
  2. Security > App Check > APIs へ移動。
  3. Firebase AI Logic の行を見つける。
  4. 行末の Enforces 日付ピッカー（編集コントロール）を使う。
  5. 2027年1月21日以前の強制日を選び、保存する。

FAQは明確です。2027年1月21日が選択可能な最終日であり、以降はFirebase AI Logicの自動強制を延期できません。

延期は長期の「検証オフ」レシピではありません。延期中かつ未強制のあいだ、公式ドキュメントはGemini APIアクセスが濫用に脆弱なままであると警告します。バッファはattestationの出荷とユーザー移行に使い、その後に強制を戻す（または選んだ日付の発火を待つ）用途です。日付ピッカーは永久オフスイッチではありません。

手順3 — プラットフォーム別に本番attestationを実装する

すでにリリース済みのアプリ向けに、FAQの移行順は次のとおりです。必要なら延期 → できるだけ早く本番attestationプロバイダを実装 → リクエストを監視 → 強制。FAQに列挙されたプロバイダ：

プラットフォーム本番attestationプロバイダ（記載どおり）
AppleプラットフォームDeviceCheck、App Attest、またはreCAPTCHA Enterprise
AndroidPlay IntegrityまたはreCAPTCHA Enterprise
WebreCAPTCHA Enterprise
Flutter上記プロバイダをサポート（reCAPTCHA Enterprise含む）
Unity上記プロバイダをサポート（FAQではreCAPTCHA Enterpriseは近日対応と記載）

出荷プラットフォームに合うプロバイダを実装し、当該スタックの現行App Check手順に従い、新ビルドを出してエンドユーザーを未attestationバイナリから移行させます。FAQは、App Check実装時にlimited-use tokensを有効にしておくと、後から replay protection（ワンタイムトークン）へ拡張しやすいとも述べます——任意の強化であり、ベースライン強制の代替ではありません。

この製品の公式リストにないattestationベンダーは、当該FAQの行列には含まれません。

手順4 — 安全と判断する前にリクエストとApp Check指標を見る

attestation出荷後、ほぼすべての直近リクエストがverifiedクライアントから来るまでトラフィックを監視します。FAQの判断は定性的です。直近リクエストのほぼすべてがverifiedなら、強制へ進む方が安全です。単一端末のテストではなく、当該プロジェクトのFirebaseコンソールApp Check／リクエスト表示を使います。

揃えるべきシグナル例：

  • Firebase AI Logicにおけるverifiedとunverifiedの比率。
  • 古いストアビルドがなおunverified量を生んでいるか。
  • attestation済みビルドの段階ロールアウトが未attestation集団を置換しているか。

数値が健全に見えてから、そのユーザー基盤向けに強制を「オンのままにしてよい」と扱うのが妥当です。

手順5 — 強制を有効化または確認する

Firebase AI LogicのApp Checkが未強制なら、attestationカバレッジが許容できる段階で強制します。11月2日以降にFirebaseがすでに自動強制し（延期なし）、APIsタブの Enforces 状態を確認して監視を続けます。

FAQの注意：予定日までに強制せず延期も設定しない場合、Firebaseが自動強制し得ます。延期計画なしの待機は、リリース済み・未attestationユーザーを遮断する経路です。

強制を維持したままのローカル開発

ローカル作業のために強制を切る必要はありません。FAQは、Firebase AI LogicでApp Checkが強制されていても、App Check debug provider を使いながら製品の強制を維持できると述べます。本番保護を残しつつ、開発機ではdebugトークンを使える——エミュレータ実行のためだけにプロジェクト全体を開放延期に置くより望ましい運用です。

チェックリスト（短縮）

  1. 失敗呼び出しが Firebase AI Logic 経由であること（無関係なGemini経路ではないこと）を確認。
  2. 未attestationの旧ビルドが残る場合のみ、Enforces を 2027年1月21日以前へ一時延期（バッファ）。
  3. Apple／Android／Web／Flutter／Unity向けにFAQ記載の本番attestationを実装し、出荷・移行。
  4. verified／unverified指標を監視し、カバレッジが許容できるまで待つ。
  5. Firebase AI LogicのApp Check強制を有効化または確認。ローカルはdebug provider、強制はオンのまま。
  6. 延期は永久オフではない——強制オフ中は濫用リスクが残る。

対象の整理

対象は Firebase AI Logic であり、インターネット上のあらゆる Gemini API 呼び出しではありません。延期は移行バッファであり、許可ウィンドウを過ぎても App Check を長期オフにはできません。強制開始の UTC 時刻は公式に示されていません。コンソール文言が動いた場合は、Firebase リリースノートと Firebase AI Logic App Check FAQ が優先されます。

計画された自動強制ウィンドウでの運用上の問いは単純です。クライアント経路はFirebase AI Logicか、各出荷プラットフォームは記載どおりの本番attestationプロバイダで有効なApp Checkトークンを提示しているか、Security > App Check の強制状態と指標は期待どおりか——それだけです。