Firebase AI LogicのApp Checkは11月2日から必須に｜AI機能が止まるアプリの見分け方と、延期・移行の手順

2026年11月7日

Firebaseは、11月2日からFirebase AI LogicにApp Checkを自動で適用すると告知していた

Firebaseは、アプリからGeminiのAIモデルを直接呼び出せる「Firebase AI Logic」で、2026年11月2日から「Firebase App Check」を自動で適用すると公式のFAQで告知していました。10月27日のリリースノートでは、この自動適用を一時的に延期できるようになったことも発表しています。筆者が11月7日に確かめたときも、FAQの説明は同じで、延期先に選べる最も遅い日は2027年1月21日のままでした。

App Checkは、届いた呼び出しが本物のアプリと改ざんされていない端末から来たものかを確かめる仕組みです。アプリはApp Attest（iPhone）やPlay Integrity（Android）などの「証明の仕組み」（SDKでは「プロバイダ」と呼ぶ）から短時間だけ有効なトークンを受け取り、呼び出しに添えて送ります。App Checkが適用されると、有効なトークンのない呼び出しは止められます。対象には、App Checkや本番用の証明の仕組みを組み込む前に配布したアプリの版も含まれます。

この記事では、11月2日から何が変わるとされているか、どのアプリの呼び出しが止まるかを公式ドキュメントで整理し、アプリの呼び出しにトークンが付くかどうかをFirebaseのSDK（アプリに組み込むライブラリ）のソースコードで確かめます。そのうえで、自分のアプリが対応済みかを依存関係のファイルから確かめる手順と、未対応の版が残っている場合の延期と移行の進め方を紹介します。

変更の要点

延期していないプロジェクトでは、App Checkと本番用の証明の仕組みが入っていない版のアプリから、AI機能を呼び出せなくなる

自動適用の日

2026年11月2日

まだ適用していなかったプロジェクトにも、Firebaseが自動でApp Checkを適用すると告知していた。

止まる呼び出し

有効なトークンがない呼び出し

App Checkを組み込む前の版や、デバッグ用のプロバイダしかない版も含まれる。

延期先に選べる最も遅い日

2027年1月21日

Firebaseコンソールで自動適用の日を後ろへずらせる。延期先に選べる最も遅い日がこの日。

最初に確かめること

コンソールの指標と依存関係

コンソールのAPIsタブの表示、トークンのない呼び出しの割合、アプリにApp Checkが入っているかを見る。

出典: Firebase AI LogicのFAQとApp Checkのドキュメント、Firebaseのリリースノート（2026年10月27日）。2026年11月7日に確認

App Checkの扱いは、7月から段階的に厳しくなってきた

Firebase AI Logicは、アプリからGeminiを呼び出すときにFirebaseが間に入る仕組みです。GeminiのAPIキーをアプリに埋め込まずに済みますが、Firebaseが呼び出しを受け付けてGeminiへ中継する窓口を、アプリの外から呼び出されると、利用料を他人に使われるおそれがあります。App Checkは、この窓口を本物のアプリだけに開くために使われます。

Firebaseはこの数か月で、App Checkの扱いを段階的に厳しくしてきました。7月からは、FirebaseコンソールでAI Logicを新しく設定すると、最初からApp Checkが適用されています。11月2日からの自動適用は、それより前に設定したプロジェクトや、適用していなかったプロジェクトが対象です。

止まるのは、有効なApp Checkのトークンがない呼び出し

App Checkが適用されると、AI Logicは呼び出しごとに添えられたトークンを確かめます。FirebaseのSDKは、アプリにApp Checkが組み込まれていれば、AI機能を呼び出すたびに自動でトークンを取得してX-Firebase-AppCheckという項目に入れて送ります。組み込まれていなければ、この項目は付きません。トークンが付いていても、コンソールに登録していないデバッグ用のトークンのように無効なものなら、その呼び出しも止まります。

筆者は10月28日に、iOS用とAndroid用のSDKの公開ソースコードで、この部分の処理を読みました。iOS用は、App Checkが使える場合だけトークンを取得して項目に入れます。Android用は、App Checkが組み込まれていないと「AppCheck not registered, skipping」という警告をログに出して、トークンを付けずに送ります。Androidのアプリでは、このログが出ていればApp Checkが入っていないと判断できます。

なお、App Checkのライブラリは、Apple向けSDKでは12.15.0から、Androidのfirebase-aiでは17.13.0から、AI Logicのライブラリに自動で含まれるようになりました（各SDKの変更履歴による）。Appleは12.15.0より前、Androidのfirebase-aiは17.13.0より前の版では、App Checkを自分で依存関係に加えます。Apple向けのAI Logicのライブラリは、12.5.0で製品名がFirebaseAIからFirebaseAILogicに変わり、13.0.0で古い名前は削除されています。製品名がFirebaseAILogicでも、12.14.x以前ならApp Checkは含まれないため、版で見分けます。どの版でも、本番用の証明の仕組みを使えるようにして、Firebaseコンソールにアプリを登録しないと、有効なトークンは発行されません。

Flutterのアプリには、もう一つ確かめることがあります。firebase_aiプラグインの3.11.0以前は、App Checkを有効にしていても、AI Logicを初期化するときにappCheck: FirebaseAppCheck.instanceを明示的に渡さないとトークンが付きません。3.12.0でアプリに登録済みのApp Checkを自動で使う処理が加わり、この指定は不要になりました。

// firebase_ai 3.12.0 で FirebaseAI.googleAI() などに加わった行（3.11.0との差分から抜粋）
    appCheck ??= app.getService<FirebaseAppCheck>();
    auth ??= app.getService<FirebaseAuth>();

Webアプリの本番用の証明はreCAPTCHA Enterprise、UnityはAppleとAndroidの仕組みに対応しています。Firebaseの説明では、延期していないプロジェクトの場合、どの環境でも、有効なトークンのない呼び出しが11月2日から止まります。

対応済みかどうかは、依存関係とコンソールの指標で確かめられる

アプリ側の組み込みは、依存関係のファイルとソースコードから確かめられます。筆者は、Flutterのpubspec.lock、AndroidのGradleのファイル、Xcodeのproject.pbxprojを読んで、App Checkの組み込み状況を表示するシェルスクリプトを作りました。ファイルを読んで依存関係の名前と版、プロバイダを登録するコードを探すだけで、ファイルの書き換えや通信はしません。Flutterのアプリでは、AndroidとiOSの依存関係をプラグインが加えるため、pubspec.lockとDartのコードだけを見ます。結果は組み込み漏れを見つけるための目安で、正しく動くかどうかは、コンソールの指標とデバッグ版の動作で確かめます。

#!/bin/sh
# Firebase AI Logic を使うプロジェクトで、App Check の組み込み状況を依存関係とコードから確かめる（ファイルを読むだけ）
set -f  # find に渡す *.dart などを、シェルに展開させない
dir="${1:-.}"
echo "== $dir"
has() { find "$dir" -type f \( $1 \) -exec grep -lE "$2" {} + 2>/dev/null | head -1; }

if [ -f "$dir/pubspec.lock" ]; then
  # Flutter: ネイティブの依存関係はプラグインが加えるので、pubspec.lock と Dart のコードだけを見る
  ver() { awk -v p="  $1:" '$0==p{f=1} f&&/version:/{gsub(/"/,"",$2);print $2;exit}' "$dir/pubspec.lock"; }
  ai=$(ver firebase_ai); ac=$(ver firebase_app_check)
  echo "Flutter: firebase_ai ${ai:-なし} / firebase_app_check ${ac:-なし}"
  [ -z "$ac" ] && echo "  注意: firebase_app_check が依存関係にない"
  if [ -n "$(has '-name *.dart' 'FirebaseAppCheck\.instance\.activate')" ]; then
    echo "  App Check の有効化: あり"
  else
    echo "  注意: FirebaseAppCheck.instance.activate の呼び出しが見つからない"
  fi
  if [ -n "$ai" ] && [ "$(printf '%s\n3.12.0\n' "$ai" | sort -V | head -1)" != "3.12.0" ]; then
    if [ -n "$(has '-name *.dart' 'appCheck: *FirebaseAppCheck\.instance')" ]; then
      echo "  firebase_ai が 3.12.0 より前: appCheck を明示的に渡している"
    else
      echo "  注意: firebase_ai が 3.12.0 より前で、appCheck を明示的に渡すコードが見つからない"
    fi
  fi
  exit 0
fi

# Android: Gradle の依存関係と、プロバイダの登録コード
if [ -n "$(has '-name *.gradle -o -name *.gradle.kts -o -name libs.versions.toml' 'firebase-ai')" ]; then
  if [ -n "$(has '-name *.gradle -o -name *.gradle.kts -o -name libs.versions.toml' 'firebase-appcheck')" ]; then
    echo "Android: firebase-ai と firebase-appcheck の記述あり"
  else
    echo "Android: firebase-ai あり（firebase-appcheck の記述なし。firebase-ai 17.13.0 以降は自動で含まれる。それより前の版では追加が必要）"
  fi
  [ -n "$(has '-name *.kt -o -name *.java' 'installAppCheckProviderFactory')" ] \
    && echo "  プロバイダの登録: あり" || echo "  注意: installAppCheckProviderFactory の呼び出しが見つからない"
fi

# Apple: Swift Package（project.pbxproj と Package.resolved）か CocoaPods（Podfile.lock）の製品と版、プロバイダの登録コード
if [ -n "$(has '-name project.pbxproj -o -name Podfile.lock' 'FirebaseAI')" ]; then
  lock=$(has '-name Podfile.lock' 'FirebaseAI'); resolved=$(has '-name Package.resolved' 'firebase-ios-sdk')
  v=""
  [ -n "$lock" ] && v=$(grep -oE '^  - FirebaseAI(Logic)? \([0-9.]+\)' "$lock" | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
  [ -z "$v" ] && [ -n "$resolved" ] && v=$(awk '/"identity" *: *"firebase-ios-sdk"/{f=1;next} f&&/"identity"/{exit} f&&/"version"/{gsub(/[",]/,"",$3);print $3;exit}' "$resolved")
  if [ -n "$(has '-name project.pbxproj' 'productName = FirebaseAppCheck;')$(has '-name Podfile.lock' '^  - FirebaseAppCheck \(')" ]; then
    echo "Apple: FirebaseAppCheck あり（Firebase Apple SDK の版: ${v:-読めない}）"
  elif [ -n "$v" ] && [ "$(printf '%s\n12.15.0\n' "$v" | sort -V | head -1)" = "12.15.0" ]; then
    echo "Apple: Firebase Apple SDK $v（12.15.0 以降は FirebaseAILogic に App Check が含まれる）"
  elif [ -n "$v" ]; then
    echo "Apple: Firebase Apple SDK $v / 注意: 12.15.0 より前で、FirebaseAppCheck が追加されていない"
  else
    echo "Apple: 注意: SDK の版を読めない。12.15.0 より前なら FirebaseAppCheck の追加が必要"
  fi
  [ -n "$(has '-name *.swift -o -name *.m' 'setAppCheckProviderFactory')" ] \
    && echo "  プロバイダの登録: あり" \
    || echo "  プロバイダの登録: なし（実機では既定の DeviceCheck を使う。App Attest を使うなら登録が必要）"
fi

スクリプトをcheck-ai-logic-app-check.shとして保存し、sh check-ai-logic-app-check.sh プロジェクトのフォルダのように実行します。複数のアプリを1つのリポジトリに置いている場合は、アプリごとのフォルダを渡します。筆者が用意した10個の小さなサンプルに対して実行した結果が次のとおりです。firebase_ai 3.11.0でappCheckを渡していないFlutter、App Checkを有効にしていないFlutter、プロバイダの登録がないAndroid、FirebaseAppCheckを追加していない12.14.0のiOS（Swift PackageとCocoaPodsの両方）で、それぞれ注意が表示されました。iOSはPackage.resolvedかPodfile.lockからFirebase Apple SDKの版を読み、12.15.0以降ならApp Checkを含むと判定します。iOSでプロバイダを登録していない場合は、実機では既定のDeviceCheckが使われるため、注意ではなく情報として表示します。macOS 27.0.1の標準のシェルで、2026年10月28日に確認しています。

== flutter-old
Flutter: firebase_ai 3.11.0 / firebase_app_check 0.4.3
  App Check の有効化: あり
  注意: firebase_ai が 3.12.0 より前で、appCheck を明示的に渡すコードが見つからない
== flutter-new
Flutter: firebase_ai 5.0.0 / firebase_app_check 0.5.1
  App Check の有効化: あり
== flutter-full
Flutter: firebase_ai 5.0.0 / firebase_app_check 0.5.1
  注意: FirebaseAppCheck.instance.activate の呼び出しが見つからない
== android-noappcheck
Android: firebase-ai あり（firebase-appcheck の記述なし。firebase-ai 17.13.0 以降は自動で含まれる。それより前の版では追加が必要）
  注意: installAppCheckProviderFactory の呼び出しが見つからない
== android-noprovider
Android: firebase-ai と firebase-appcheck の記述あり
  注意: installAppCheckProviderFactory の呼び出しが見つからない
== ios-ok
Apple: FirebaseAppCheck あり（Firebase Apple SDK の版: 読めない）
  プロバイダの登録: あり
== ios-spm-13.1.1
Apple: Firebase Apple SDK 13.1.1（12.15.0 以降は FirebaseAILogic に App Check が含まれる）
  プロバイダの登録: あり
== ios-spm-12.14.0
Apple: Firebase Apple SDK 12.14.0 / 注意: 12.15.0 より前で、FirebaseAppCheck が追加されていない
  プロバイダの登録: なし（実機では既定の DeviceCheck を使う。App Attest を使うなら登録が必要）
== ios pods 13.1.1
Apple: FirebaseAppCheck あり（Firebase Apple SDK の版: 13.1.1）
  プロバイダの登録: なし（実機では既定の DeviceCheck を使う。App Attest を使うなら登録が必要）
== ios pods 12.14.0
Apple: Firebase Apple SDK 12.14.0 / 注意: 12.15.0 より前で、FirebaseAppCheck が追加されていない
  プロバイダの登録: なし（実機では既定の DeviceCheck を使う。App Attest を使うなら登録が必要）

アプリに組み込んでいても、利用者の手元に古い版が残っていれば、その版からの呼び出しにはトークンが付きません。古い版がどのくらい使われているかは、Firebaseコンソールの「App Check」画面にある、AI Logicのリクエストの指標で確かめます。

Firebaseは、最近の呼び出しのほとんどがVerifiedならApp Checkを適用してよい、Outdated clientが多ければ利用者が新しい版へ移るのを待つ、という目安を示しています。Outdated clientが多いまま適用されていて、古い版のAI機能が動かなくなっているなら、次の節で、延期や適用の解除ができるかを確かめます。

未対応の版が残るなら、延期できるかを確かめてから移行する

延期の操作はFirebaseコンソールで行います。「Security」→「App Check」→「APIs」タブを開き、「Firebase AI Logic」の行の右端にある「Enforces:」の日付を、編集ボタンから選び直して保存します。選べる最も遅い日は2027年1月21日です。FAQの延期の手順は、まだ適用されていないプロジェクトで自動適用を後ろへずらすためのもので、11月7日時点でも11月2日より前の書き方のままです。

まず、この行の状態を見ます。「Unenforced」（未適用）で日付と編集ボタンが出ていれば、日付を選び直して自動適用を延期できます。延期中はApp Checkが適用されないため、そのあいだは中継の窓口を他人に使われる余地が残ります。

「Enforced」（適用済み）になっている場合、公式の手順では、日付を変えるだけでは適用は外れません。適用を外す手順はAI LogicのApp Checkのページにあり、「Enforces:」の日付で延期したうえで、行を開いて指標のグラフの下にある「Set up」から「Unenforced (monitoring only)」を選びます。Firebaseはこの操作を「強く推奨しない」としていて、外した場合はできるだけ早く適用し直すよう求めています。この手順も11月2日より前の書き方で、自動で適用されたあとにも使えるかは書かれていません。

日付と編集ボタンが出ていなければ、公式資料に書かれた延期と解除の手順は、どちらもこの日付の操作から始まるため、そのとおりには進められません。App Checkと本番用の証明の仕組みを入れた版の配布を急ぎ、古い版を使っている利用者にアプリの更新を案内します。

新しい版でApp Checkを組み込むときは、トークンを1回だけ使える「使い捨てトークン」を使う設定（useLimitedUseAppCheckTokens）も一緒に有効にしておくと、あとから「リプレイ保護」を適用できます。リプレイ保護は、盗んだトークンを使い回す攻撃を防ぐ追加の保護で、Apple向けSDK 12.2.0以降、Android BoM 34.14.0以降（App Check 19.1.0以降）、Web 12.14.0以降、Flutter BoM 4.15.0以降、Unity 13.12.0以降が必要です。

開発中のアプリは、デバッグ用のプロバイダを使えばApp Checkを適用したまま動かせる

App Checkを適用すると、シミュレーターやエミュレーターで動かす開発中のアプリも、そのままでは呼び出しを止められます。開発用には「デバッグ用のプロバイダ」を使います。デバッグ版のアプリが最初に起動したときにログへ出すデバッグ用トークンを、Firebaseコンソールに登録すると、その端末からの呼び出しが通るようになります。

App Checkが適用されていない状態でも、Firebaseが悪用されやすいと判断した一部のモデルは、すでにトークンのない呼び出しを403 - PERMISSION_DENIED（To access this model, you must enforce Firebase App Check.）で拒否しています。開発中にこのエラーが出たら、App Checkを適用し、デバッグ用のプロバイダを設定すると、エラーが出なくなります。

いま確かめる3つのこと

AI機能をすでに配布しているアプリでは、まず指標のOutdated clientの割合を見るところから始めると、延期が必要かどうかを、指標を見たその日のうちに決められます。新しくAI機能を作るアプリなら、最初からApp Checkとデバッグ用のプロバイダを入れておけば、App Checkが適用された状態のまま開発を進められます。