Firebase App Checkとは｜プロバイダ選定と監視から強制への移行【2026年8月時点】

Firebase App Check は、Firebase のバックエンドへ届いたリクエストが「自分たちが配布した正規のアプリから来たものか」を確かめる仕組みで、ユーザーが誰かを確かめる Authentication とは別の層にあります。この記事で扱うのは、構成証明プロバイダの選び方、無料枠のクォータとトークンの有効期間、監視モードから強制へ切り替える段取り、デバッグトークンで起きる事故、自前バックエンドでの検証まで。数値と版番号は2026年8月時点の実測値です。

まとめ：先に監視モードで通し、強制はプロダクト単位で切る

App Check の難所は実装ではなく切り替えの判断です。SDKを組み込んだ時点では何も遮断されず、コンソールの指標に検証済みと未検証の比率が出るだけ。ここで数日から数週間ぶん見て、未検証の内訳が「古いアプリを使い続けている自社ユーザー」なのか「アプリを騙っている外部」なのかを見分けてから強制へ進みます。順番を飛ばすと、更新していない利用者を丸ごと締め出すことになります。

プロバイダはプラットフォームで決まり、選ぶ余地があるのは Apple 系だけです。iOS 14以降なら App Attest、それより前のOSも支えるなら DeviceCheck へフォールバックする構成。Android は Play Integrity、Web は reCAPTCHA Enterprise の一択。無料枠は前者が1日10,000回、後者が月10,000アセスメントです。有効期間を短くすると安全側に振れる一方、この枠の消費が早まります。

App Checkが確かめるのは誰かではなくどのアプリからかという点

最初に押さえるのは守備範囲です。取り違えると、認証と二重に作ったつもりで穴が残ります。

Authenticationが埋めない正規クライアントかの確認

Firebase の設定オブジェクトに入るAPIキーやプロジェクトIDは、Webアプリなら閲覧者が誰でも読めますし、ネイティブアプリでもバイナリから抜けます。つまり「エンドポイントへ正しい形式でリクエストを投げる」ところまでは公開情報だけで誰にでもできるということ。Firebase Authenticationの認証方式と導入手順の解説で扱っている認証は、この先で「そのユーザーが本人か」を判定する層です。

残るのが、正規ユーザーのアカウントを持った人が自作スクリプトから読み書きを繰り返す経路、あるいは公開キーだけを拾った第三者が無認証で許可された領域を叩く経路。App Check はこの2つを塞ぎます。ルールが判定するのは「このユーザーはこのドキュメントを触れるか」で、呼び出し元のアプリが本物かは見ていません。

App Checkが構成証明からトークン検証へ至る3段階の流れ

動作は3段階です。第1段階で、アプリのSDKがプラットフォーム固有の構成証明プロバイダから証明を取得します。iOSなら端末のSecure Enclaveが関与し、Androidなら Google Play が導入経路の正当性を返し、Webなら reCAPTCHA が挙動を評価する仕組み。第2段階でその証明を App Check のバックエンドが検証し、有効期限付きのトークンを発行します。第3段階で、SDKがこのトークンをキャッシュし、保護対象への各リクエストへ添付します。

公式の表現では、保護されたサービスは「現在有効な App Check トークンを伴うリクエストのみを受け付ける」もの。トークンを取れなかった端末は保護対象へ一切到達できないため、プロバイダ側の障害や設定漏れがアプリ全体の停止に化ける構造でもあります。

App Checkで保護できるプロダクトと対象外に残るサービス

2026年8月時点で公式が挙げる保護対象は10件です。Firebase Authentication（プレビュー）、Firebase SQL Connect、Cloud Firestore、Firebase Realtime Database、Cloud Storage for Firebase、Cloud Functions for Firebase、Firebase AI Logic、Maps JavaScript API（プレビュー）、Places API（プレビュー）、Google Identity for iOS。GraphQLでCloud SQLを扱うFirebase SQL Connectの実装判断は改称後の表記で一覧に載っています。

注意が要るのは Cloud Functions で、対象は呼び出し可能関数（callable）のみです。トリガー設計と第2世代の実装判断をまとめた記事で扱うHTTPリクエスト関数を守るなら、関数の中で自分で検証する形になります。

一覧に無いものは対象外です。静的配信とSPA配信の仕組みを整理した記事で扱う Hosting、プッシュ通知の FCM、Remote Config、Analytics、Crashlytics はいずれも守れません。「入れたのでバックエンドは安全」という言い方は成り立たない、と読み替えてください。

プラットフォーム別の構成証明プロバイダ4種と選定するときの基準

プロバイダはプラットフォームで自動的に絞られます。対応関係と無料の範囲は次のとおりです。

AppleはApp Attestとフォールバック用DeviceCheckの2択

Apple 系だけ選択が発生します。App Attest は Xcode 12.5以降が前提で、iOS 14以降の端末で使えます。iOS 13以下も含む案件なら、公式が示すとおり「iOS 14以降で AppAttestProvider を作り、それより前は DeviceCheckProvider へフォールバックする」書き方です。なお watchOS では使えません。

設定で落ちやすいのが2点あります。まず Xcode で App Attest のケーパビリティを追加したうえで、.entitlements の App Attest 環境を production にすること。公式は「App Check は現時点で App Attest のサンドボックス環境で生成されたトークンを受け付けない」と明記しており、開発ビルドのまま強制を試すと自分のアプリが弾かれます。もう1点は既存アプリへの後追い導入で、Apple がクォータ到達を避けるため段階的なユーザー移行を推奨しているところ。

AndroidはPlay IntegrityでPlay外配布の端末が抜ける

Android は Play Integrity です。前提として、アプリを Google Play Console へ登録し、Firebase プロジェクトと紐付けておきます。実測した依存は Firebase BoM 34.17.0 と firebase-appcheck-playintegrity 19.4.0 でした。

落とし穴は配布経路です。Google Play で公開していないアプリは PLAY_RECOGNIZED のラベルを受け取れず、Play 外配布を含む構成では設定を分ける必要があります。社内配布のみの業務アプリや独自ストア経由の配信は、この前提から外れるところ。

WebはreCAPTCHA Enterprise一択で250ドメインが上限

Web は reCAPTCHA Enterprise を使います。作成するのはWebタイプのキーで、各ドメインを列挙し、チェックボックス形式のチャレンジは選択しません。利用者へ画像認証を出す種類の仕組みではない、と理解しておくと設計を誤りません。

制約が2つあります。1つは「App Check は250を超えるドメインで配信されるWebアプリに対応しない」という上限で、顧客ごとの独自ドメインを配るマルチテナント構成は正面から当たります。もう1つは localhost を本番用キーへ追加しないこと。誰でも手元でアプリを動かせる状態になります。

無料枠のクォータとトークンTTLが費用と体感速度を決める仕組み

App Check そのものに利用料はありませんが、下敷きのプロバイダ側で費用が出ます。設計変数はクォータと有効期間の2つです。

Play Integrityは日次1万回reCAPTCHAは月1万回の無料枠

公式が示す数字は次のとおりです。Play Integrity は Standard 利用階層で1日あたり10,000回の呼び出し。reCAPTCHA Enterprise は月10,000アセスメントまで無償で、超えた分はプロジェクトへ課金されます。DeviceCheck と App Attest は Apple が設定するクォータに従う扱いです。

数え方を取り違えないでください。消費されるのは構成証明の回数で、Firestore の読み取り回数や関数の実行回数ではありません。トークンは有効期間中キャッシュされ、その間の全リクエストで再利用されます。日次アクティブ端末が1万を超えていても、1端末あたりの構成証明が1日1回なら枠に収まる関係。無料枠とBlaze超過単価の実額をまとめた記事では費用膨張を抑える手段として App Check を挙げていますが、守る対象の課金と守る手段の課金は別に見積もってください。

既定1時間のトークンTTLと半分の時点で更新される挙動の設計

トークンの有効期間（TTL）は30分から7日までの範囲で設定でき、既定は1時間です。ライブラリはTTLの約半分で更新をかけるため、既定のままなら1端末あたり約30分ごとに1回の構成証明が走る計算になります。

短くする側の効果は、盗まれたトークンが使える窓が狭まること。代償として構成証明の頻度が上がり、クォータの消費が早まるうえ、アプリの体感速度にも影響します。長くする側は逆で、枠と速度に余裕が出るかわりに窓が広がるということ。順序としては、まず既定の1時間で監視モードを回し、構成証明回数と無料枠を突き合わせます。決済や個人情報の更新のような経路だけ後述のリプレイ対策で締めるほうが、全体のTTLを詰めるより副作用が小さく済みます。

5つの指標を読みながら監視モードから強制へ移していく段階の手順

SDKを入れた直後は何も遮断されません。指標を読んで、強制へ進む時期を自分で決めます。

Verifiedと4つの未検証区分が示すクライアント側の実像

指標は5区分です。Verified は有効なトークンを伴うリクエストで、強制後に許可されるのはこの区分だけ。Outdated client はトークンが付いておらず、公式の説明では「App Check SDK を追加する前の、古いバージョンのアプリからのものである可能性がある」もの。Unknown origin も同じくトークンが無く、Firebase SDK から来たようには見えないリクエストです。Invalid は無効なトークンを伴い、アプリを騙る非正規クライアントの疑いを示します。Reused token は既に使われたトークンの再提示です。

読み方は分岐します。Outdated client が多い状態は「自社ユーザーの端末でアプリが更新されていない」ことを示すため、強制を入れれば正規の利用者が落ちます。一方 Invalid と Unknown origin の比率が高い状態は、外部からの直接呼び出しが実際に起きている裏付け。公式の指針も、ほぼすべてが検証済みなら強制へ進み、古いクライアントの割合が大きければ更新を待つ、という組み立てです。まだ公開していないアプリなら、最初から強制で始めるほうが早いとされています。

強制の切り替えはプロダクト単位で旧バージョンのアプリが落ちる

強制はプロダクトごとに個別に有効化します。Firebase AI Logic、SQL Connect、Realtime Database、Cloud Firestore、Cloud Storage、Authentication などをそれぞれ切り替える形で、一括で切るスイッチではありません。依存の浅いところから順に上げてください。

切り替え前に必ず確認すべきなのは、公式が明言している破壊的な影響です。「リリース済みのアプリに App Check を強制すると、App Check SDK を組み込んでいない以前のバージョンのアプリが壊れる」。ストアの審査期間と利用者の更新速度を考えると、SDK入りバージョンの配布から強制まで数週間は空くのが普通でしょう。順番としては影響の小さい Storage や Realtime Database から始め、落ちれば起動直後から使えなくなる Authentication は最後に回します。

デバッグトークンの運用と自前バックエンド側でのトークンの検証

ここからは実装側です。ローカル開発とCI、自前バックエンドをどう通すかを扱います。

デバッグトークンを発行する手順とCIで扱うときの安全な置き場

ローカルでは構成証明が通らないため、デバッグプロバイダを使います。Webなら App Check の初期化より前に self.FIREBASE_APPCHECK_DEBUG_TOKEN を true にし、開発者ツールへ出力されたトークンをコンソールの「デバッグトークンを管理」から登録する流れ。CIでは逆順で、コンソールで先にトークンを作り、暗号化シークレットへ置いて環境変数から読ませます。ローカル検証環境の組み方はLocal Emulator Suiteによるローカル再現とCI組み込みの解説にまとめています。

ここが最も事故になるところです。公式は「デバッグトークンとデバッグビルドは非公開に保つこと」と繰り返し警告しており、有効なトークンとデバッグプロバイダの組み合わせがあれば未検証の端末からバックエンドへ到達できてしまいます。禁止事項は3つ。リポジトリへのコミット、本番ビルドへの同梱、チャットへの貼り付け。漏れた疑いが出た時点で即座に削除してください。強制を有効にした本番プロジェクトへ登録済みのトークンが1本残れば、そこが抜け道になります。開発用と本番用でプロジェクトを分ける価値は、この一点だけでも十分あるところ。

自前バックエンドでのトークンの検証とリプレイ対策のベータ制約

Firebase 以外のバックエンドも守れます。公式の表現では「自己ホストのバックエンドのような、Google 以外のカスタムバックエンドリソース」が対象です。検証経路は2つ。Node.js・Python・Go なら Admin SDK の verifyToken() にトークンを渡すだけです。それ以外の言語ではJWKSエンドポイント https://firebaseappcheck.googleapis.com/v1/jwks から公開鍵を取り、アルゴリズムが RS256、型が JWT、発行者が自プロジェクトの App Check、有効期限内、対象者が projects/{project_number} と一致することをJWTライブラリで確かめます。

通常のトークンは有効期間中に何度でも使えます。抜き取られたトークンの再利用を止めるのが消費型の検証で、verifyToken() へ { consume: true } を渡し、返り値の alreadyConsumed が真なら拒否する形。ただし制約が2つあります。公式は「リプレイ対策のベータは Node.js SDK のみに対応する」と注記しており、Python や Go では選べません。加えて往復が1回増えるため、公式自身も機微なエンドポイントに限った適用を推奨しています。決済の確定や権限の変更に絞り、ルール設計とGCS直接操作の判断を整理した記事で扱うアップロード制限のようにルール側で条件化できる部分は先にそちらへ寄せてください。

受託開発でApp Checkを入れる条件と導入を見送る3つの場面

制約を踏まえ、案件でどう扱うかを言い切ります。

App Checkを設計段階から入れるべき受託案件の3つの条件

次の3条件のどれかに当たるなら、リリース後の追加ではなく設計段階から組み込んでください。第1に、クライアントSDKから直接 Firestore や Storage を読み書きする構成の案件。バックエンドAPIを経由しない設計は、公開キーで到達できる面が広いからです。第2に、従量課金のプロダクトを利用者数の読めないB2Cアプリで使う案件。第3に、AI推論やSMS送信のように1回あたりの単価が高い機能を持つ案件です。

順序は、SDK組み込みとデバッグトークン整備を済ませた状態でリリースし、監視モードで実データを取ってから強制へ進む形。JSONツリー同期の仕組みと転送量課金の解説のように課金が転送量のプロダクトでは、監視期間中の指標が被害見積もりの材料になります。

App Checkの強制を見送って監視のままに置く3つの場面

反対に、次の3つでは強制を入れません。1つ目は、Google Play 以外の経路で配布する Android アプリが利用者の一定割合を占める案件で、Play Integrity の前提から外れる端末が弾かれます。2つ目は、顧客ごとの独自ドメインで配信するマルチテナントのWebアプリで、ドメイン数が250に近いか今後超える見込みがある案件。3つ目は、旧バージョンを使い続ける利用者が多く強制更新を要求できない業務アプリです。医療機関や工場のように端末更新の裁量が現場に無い環境では、Outdated client の比率が下がりません。

これらでも SDK の組み込み自体は行い、監視モードで置いてください。指標だけでも「どの経路からどれだけ非正規の呼び出しが来ているか」の実測値になります。なお強制を入れないなら、セキュリティルールと関数側の検証が唯一の防壁になるところ。その厳格さを一段上げる作業を同時に見積もってください。

内製化を前提にした引き継ぎで渡す4点と受託側で相談できる範囲

引き継ぎで渡す資料は4点です。プラットフォーム別のプロバイダ構成と対象OSの下限、デバッグトークンの発行と失効の手順書、プロダクト別の強制状況の一覧、そして監視モード期間に取った5指標の推移。最後の1点があると、発注元が自分で強制のタイミングを判断できます。逆に渡してはいけないのがデバッグトークンの実物で、手順書には「コンソールで各自が発行し、共有しない」と明記してください。Firebase をバックエンドに据えたアプリの設計とリリース前のセキュリティ設定の詰めは、スマホアプリ開発でご相談を受けています。

よくある質問

App Check の導入検討で問い合わせの多い5点をまとめます。

Firebase App Checkの利用に料金はかかりますか？

App Check 自体に個別の料金設定はなく、費用が出るのは下敷きのプロバイダ側です。reCAPTCHA Enterprise は月10,000アセスメントを超えた分が課金され、Play Integrity は Standard 利用階層で1日10,000回の枠を持ちます。消費されるのは構成証明の回数で、リクエスト数とは一致しません。

App CheckはFirebase Authenticationの代わりになりますか？

なりません。答える問いが違います。Authentication は「利用者は誰か」を確かめ、App Check は「正規のアプリから来たか」を確かめます。正規ユーザーが自作スクリプトで大量に呼ぶ経路は認証だけでは止まらず、未ログインで許可した領域への外部アクセスは App Check がなければ塞げません。

Firebase Hostingやプッシュ通知もApp Checkで守れますか？

守れません。公式の保護対象一覧に Hosting・FCM・Remote Config・Analytics・Crashlytics は含まれていません。Cloud Functions も呼び出し可能関数のみが対象で、HTTPリクエスト関数を守るなら関数の中で自分で検証する実装になります。守れる範囲を最初に線引きしてから、残る面の対策を別に立ててください。

強制を有効にすると既存ユーザーのアプリは動かなくなりますか？

App Check SDK を組み込んでいないバージョンは動かなくなります。公式も、リリース済みアプリへ強制を適用すると以前のバージョンが壊れると明記しています。SDK入りバージョンを配布し、Outdated client の比率が下がるのを待ってから強制へ進んでください。プロダクト単位で切れるので、影響の小さいものから上げるのが安全です。

ブラウザの開発者ツールからトークンを抜き取られませんか？

抜き取り自体は起こり得ます。だからこそ有効期間が設けられており、既定の1時間なら盗まれたトークンが使える窓もそこまで。窓を消したいエンドポイントには消費型のリプレイ対策を個別に適用します。ただしベータで Node.js SDK のみの対応、かつ往復が1回増えるため、機微な処理に限って使う前提で設計してください。

関連記事

• Firebase Authenticationとは：「利用者は誰か」の側を担う認証方式と料金です。
• Firebaseの料金：抑えたい従量課金の内訳と無料枠を超えた後の単価です。
• Cloud Functions for Firebaseとは：保護対象が callable 限定である関数側の設計です。
• Cloud Storage for Firebaseとは：不正アップロードをルールで条件化する書き方です。
• Firebase Local Emulator Suiteとは：デバッグトークンと併用するローカル再現環境です。