Firebase App Check を Rork に段階的に enforcement する — AdMob 不正検知と Crashlytics を壊さない実運用設計

DeviceCheck / Play Integrity を Rork から初期化する

Rork で吐き出したプロジェクトに @react-native-firebase/app-check を入れて初期化する最小実装は次の通りです。SwiftUI 側に直接書く必要はなく、JS 側のエントリで Firebase 初期化後すぐに呼び出します。

// app/_layout.tsx 付近で early に初期化
import firebase from '@react-native-firebase/app';
import appCheck from '@react-native-firebase/app-check';
 
async function initAppCheck() {
  const provider = appCheck().newReactNativeFirebaseAppCheckProvider();
 
  provider.configure({
    apple: {
      // App Store ビルド: App Attest
      // TestFlight や開発ビルド: DeviceCheck か debug
      provider: __DEV__ ? 'debug' : 'appAttestWithDeviceCheckFallback',
      debugToken: process.env.EXPO_PUBLIC_APP_CHECK_DEBUG_TOKEN,
    },
    android: {
      // Play Store ビルド: PlayIntegrity
      // 内部配布: debug
      provider: __DEV__ ? 'debug' : 'playIntegrity',
      debugToken: process.env.EXPO_PUBLIC_APP_CHECK_DEBUG_TOKEN,
    },
    web: { provider: 'debug', siteKey: '' },
  });
 
  await appCheck().initializeAppCheck({
    provider,
    isTokenAutoRefreshEnabled: true,
  });
}
 
initAppCheck().catch((e) => {
  // 失敗してもアプリ起動は止めない
  console.warn('[AppCheck] init failed', e);
});

ここで意図的に try/catch ではなく .catch にしているのは、App Check 初期化に何が起きてもアプリ本体の起動を止めないためです。App Check が落ちた瞬間にスプラッシュで固まる、というのは個人開発のアプリで最も避けたい状態の一つです。何度か事故を起こしたあとに落ち着いた結論は「App Check 初期化失敗時はサイレントに継続、ただし Remote Config フラグで挙動を切り替えられるようにしておく」でした。

debug token は環境変数経由で TestFlight や Internal Testing 端末にだけ配ります。GitHub の Secrets と Expo の EAS Secrets の両方に登録して、CI ビルド時に注入する形にしておくと、誤って本番ビルドに debug provider を残すリスクを下げられます。

インストール直後の数十秒をどう吸収するか

App Attest の attestation key は、新規インストールした端末の初回起動時に生成されます。この生成が終わるまでの数十秒間、getToken() は失敗し続けます。isTokenAutoRefreshEnabled: true を入れていてもリトライは SDK 側のバックオフ任せなので、起動直後に Realtime Database のリスナーを張るコードが先に走ると、その最初の接続だけが 401 で落ちます。

厄介なのは、この失敗が新規インストールのユーザにしか起きないという点です。手元の端末では再現しません。一度でも起動した端末には attestation key が残っているからです。テストで見えないまま本番に出て、新規インストール直後のセッションだけが静かに欠けていく。私が enforcement を怖いと感じる理由の半分はここにあります。

対処は、Firebase 依存の初期化の手前にゲートを一枚挟むことです。ただし無限には待たせません。取れなければ degraded モードで先へ進めます。

// lib/appCheckGate.ts
import appCheck from '@react-native-firebase/app-check';
 
const MAX_WAIT_MS = 4000;
const BACKOFF_MS = [200, 400, 800, 1600];
 
export async function waitForAppCheckToken(): Promise<string | null> {
  const startedAt = Date.now();
 
  for (const delay of BACKOFF_MS) {
    if (Date.now() - startedAt > MAX_WAIT_MS) break;
    try {
      // forceRefresh: false — キャッシュ済み token があればネットワーク往復なしで返る
      const { token } = await appCheck().getToken(false);
      if (token) return token;
    } catch {
      // attestation key の生成待ち。バックオフして再試行する
    }
    await new Promise((resolve) => setTimeout(resolve, delay));
  }
 
  return null; // degraded モードで継続する
}

forceRefresh を false にしているのは、2 回目以降の起動でキャッシュ済みトークンをそのまま使い、待ち時間をゼロにするためです。ここを true にすると、初回インストール時だけの問題を解くために、全ユーザの起動へ毎回ネットワーク往復を足すことになります。

上限を 4 秒に置いているのは、スプラッシュとして許容できる表示時間から逆算した値です。アプリごとに調整する前提の数字ですが、「ユーザが待たされたと感じる前に必ず抜ける」ことは崩さないようにしています。

degraded モードで何をするかも、あらかじめ決めておきます。

忘れてはいけないのが、token が遅れて取れたときの再接続です。waitForAppCheckToken() が null を返したあとも、バックグラウンドで appCheck().getToken(false) を一度だけ再試行し、成功したら Realtime Database の接続を張り直します。この再接続を入れる前は、新規インストールのユーザだけが「アプリを一度落として開き直すまで同期されない」状態に置かれていました。数字にすると小さな割合ですが、そのユーザにとっては初対面の体験がそれで決まります。

段階的 enforcement の三段ロケット設計

App Check の enforcement を本番に投入するときに、私が定型として組んでいるのは「0%」「10%」「50%」「100%」の四つのステージです。ただし、Firebase コンソール側の enforcement は二値（未強制 / 強制）なので、トラフィック比率はサーバ側ではなくクライアント側の Remote Config フラグで段階的に切ります。

ステージは具体的に次のように設計します。

ステージ 0 — appCheckMode = "monitor"。クライアントは App Check token を取得して送るが、サーバ側 enforcement は未強制。Firebase コンソールの「リクエスト指標」で、自分のアプリの正規トラフィックがどれくらい未検証になるかを 1 週間眺める段階です。

ステージ 1 — appCheckMode = "enforce" だが、Remote Config の appCheckRolloutPercent = 10 で 10% のユーザのみ enforce 対象とします。クライアント側で自身のユーザ ID を sha256 して下 2 桁を取り、< 10 のユーザだけ Crashlytics と Realtime Database を実際に App Check 越しで使う実装にします。

ステージ 2 — 同じ Remote Config を 50 に上げます。ここで一度、Crashlytics の Daily Active Users と Crash-free Sessions の比較を取り、enforce / not enforce で差がないことを確認します。差が出ていれば必ず正規アプリのリクエストが落ちています。

ステージ 3 — 100% に上げます。同時に Firebase コンソール側を「強制」に切り替えます。

Remote Config 側のロールアウト比率を、クライアントで実際にどう判定しているかの実装例は次の通りです。

import remoteConfig from '@react-native-firebase/remote-config';
import auth from '@react-native-firebase/auth';
import sha256 from 'crypto-js/sha256';
 
export function isAppCheckEnforced(): boolean {
  const mode = remoteConfig().getString('appCheckMode'); // off | monitor | enforce
  if (mode !== 'enforce') return false;
 
  const percent = remoteConfig().getNumber('appCheckRolloutPercent');
  if (percent <= 0) return false;
  if (percent >= 100) return true;
 
  // 安定したバケット化: user uid のハッシュ下 2 桁
  const uid = auth().currentUser?.uid ?? 'anonymous';
  const bucket = parseInt(sha256(uid).toString().slice(-2), 16) % 100;
  return bucket < percent;
}

このハッシュバケット方式は、広告配信の出し分けで似たコードを何度も書いてきた感覚として、いちばん裏切らない方法だと考えています。ユーザの uid が変わらない限り、ロールアウト比率の境界を行き来しないので、A/B 観測が安定します。匿名ユーザ向けに 'anonymous' を入れているのは、ハッシュ計算がブレないようにするためで、サインアウト中のユーザもロールアウト対象に含めるか除外するかは Remote Config の別フラグで切り替えられるようにしてあります。

Crashlytics と Realtime Database を壊さない順番

App Check の対象となる Firebase 機能のうち、個人開発で最もダメージが大きいのが Crashlytics と Realtime Database です。経験上、enforcement の有効化は次の順序が安全でした。

最初に Authentication と Cloud Functions を有効化します。これらは失敗してもユーザ側のサイレントな停止が比較的少なく、API 側のエラーログで気づきやすいからです。次に Cloud Storage を入れます。画像系のアプリだと壊れたときの被害が大きいですが、目に見える「画像が出ない」障害なので逆に発見が早いという皮肉な利点があります。

その次にようやく Realtime Database と Crashlytics に手をつけます。この二つは「壊れても画面上はほぼ何も起こらない」サイレント停止系で、Crashlytics に至っては「クラッシュ通知が来ない」というむしろ良いように見えてしまう挙動になります。私が冒頭で書いた「クラッシュフリー 99.97% に喜んだ朝」がまさにこの状態でした。

これらに enforcement を入れる前には、Firebase コンソールの「App Check → リクエスト指標」で対象 API の未検証リクエスト割合が 1% 未満になるまで monitor モードで観察し、加えて Remote Config 経由のロールアウト比率を 10% から 1 段階ずつ上げます。一段上げるごとに、最低 1 日は Crashlytics のレポート到達数を前日と比べる運用にしています。前日比 20% 以上落ちていたら、何かが壊れているサインです。

3 分でロールバックする Remote Config フラグ設計

App Check のロールバックは「速さ」が全てです。Firebase コンソール側の enforcement を「未強制」に戻すと反映に数分かかることがあるので、クライアント側の Remote Config を一発で「全ユーザ enforce 解除」にできるようにしておくと、復旧時間が桁違いに短くなります。

ロールバック用に私が必ず置いている Remote Config フラグは次の三つです。

• appCheckMode — off / monitor / enforce の三値
• appCheckRolloutPercent — 0〜100 の整数
• appCheckEmergencyDisable — true にすると上記を完全無視して App Check 検証を即時バイパス

緊急時の手順としては、まず appCheckEmergencyDisable = true を全環境に配信し、Remote Config の fetchInterval を 0 にしているクライアントから順に App Check 経路を外させます。これに加えて、サーバ側の enforcement を「未強制」に戻し、Firebase Cloud Functions 側で App Check ヘッダ未検証でも処理を継続する fallback ルートを 24 時間だけ有効化します。

Cloud Functions 側の fallback は本番では普段は無効ですが、リカバリ用フラグとしてコードに常駐させておくと、深夜の障害でも判断が早くなります。

// functions/src/utils/appCheck.ts
import { Request } from 'firebase-functions/v2/https';
import { getAppCheck } from 'firebase-admin/app-check';
 
export async function verifyAppCheckOrFallback(req: Request) {
  const emergency = process.env.APP_CHECK_EMERGENCY_BYPASS === 'true';
  if (emergency) return { verified: false, bypassed: true };
 
  const token = req.header('X-Firebase-AppCheck');
  if (!token) return { verified: false, bypassed: false };
 
  try {
    const decoded = await getAppCheck().verifyToken(token);
    return { verified: true, decoded };
  } catch (e) {
    return { verified: false, bypassed: false, error: e };
  }
}

APP_CHECK_EMERGENCY_BYPASS は Cloud Functions の環境変数で、緊急時にだけ gcloud functions deploy --set-env-vars APP_CHECK_EMERGENCY_BYPASS=true で上書きします。普段は false のまま放置で問題ありませんが、夜中に Crashlytics が止まったときにこのレールがあるかどうかで、復旧時間が 30 分単位で変わります。

App Check と AdMob 不正検知の関係

「App Check を入れると AdMob の収益はどうなるのか」という質問は、個人開発者の Discord でよく聞かれます。私の実測値の範囲で、いくつか書き残しておきます。

現役で eCPM を測れる主要 4 タイトルで App Check を入れたとき、eCPM そのものはほぼ変動しませんでした。AdMob 側の不正クリック検知や invalid traffic フィルタは、App Check の有無とは独立に動いているという理解で運用上はぎりぎり成立します。ただし、App Check が入って以降は AdMob 側の「無効なトラフィック」割合のレポートが少しずつ下がる傾向にありました。母数が小さくなる効果なのか、AdMob 側の信頼度スコアが上がる効果なのかは外からはわかりませんが、payouts の安定感は明らかに上がりました。

一方で AdMob 自体の SDK は App Check に直接依存していないので、Realtime Database や Crashlytics を enforce しても AdMob のフィルレートはほぼ動きません。よくある誤解として「App Check を入れると AdMob が広告を出さなくなる」と思っている方がいますが、これは混同で、AdMob の挙動は App Check の enforcement と分離して考えるのが正しい整理です。

ここで個人的な判断としてお勧めしているのは、AdMob 収益が事業の柱になっているアプリほど、App Check は早く入れた方が良いという方針です。SafetyNet 後継としての Play Integrity と組み合わせると、AdMob のポリシー違反通報を受けるリスクが具体的に下がり、結果として支払いの安定性に効きます。

どの拒否がどこに出るか、そして出ないか

段階を刻んでいても、「拒否はどこを見れば見えるのか」を知らないままだと、結局は翌朝の勘に頼ることになります。厄介なのは、App Check の拒否がプロダクトごとに別々の場所へ出て——一部はどこにも出ないことです。自分のアプリで一つずつ確かめた結果を並べます。

表の下の二つは、拒否ログを探しに行くやり方では捕まりません。私が冒頭で書いた月曜の朝がまさにそれで、あのとき私は「何かが出ていないか」を探しており、探す先そのものが止まっていたのでした。

拒否は数えられません。数えられるのは到達だけです。 ここを取り違えていたあいだ、私の監視は一度も鳴りませんでした。

そこで、実処理とは別に、検証結果を「落とす」のではなく「返す」だけの呼び出しを一本だけ用意します。Cloud Functions の enforceAppCheck を false にしたまま、request.app が埋まっているかどうかを構造化ログに書くと、検証の成否がエラーではなくデータとして手元に残ります。

// functions/src/appCheckHeartbeat.ts
import { onCall } from 'firebase-functions/v2/https';
import { logger } from 'firebase-functions';
 
export const appCheckHeartbeat = onCall(
  // 到達を数えるための経路なので、ここだけは落としません
  { enforceAppCheck: false },
  async (request) => {
    logger.info('app_check_heartbeat', {
      // App Check token が検証できたときだけ request.app が入ります
      verified: request.app !== undefined,
      enforced: request.data?.enforced === true,
      version: request.data?.version ?? 'unknown',
    });
    return { ok: true };
  },
);

クライアント側は、セッションに一度だけ、結果を握り潰して呼びます。届かないこと自体が観測対象なので、ここで例外を投げてはいけません。

// lib/appCheckHeartbeat.ts
import functions from '@react-native-firebase/functions';
import { nativeApplicationVersion, nativeBuildVersion } from 'expo-application';
import { isAppCheckEnforced } from './appCheckGate';
 
let sentThisSession = false;
 
export async function sendAppCheckHeartbeat() {
  if (sentThisSession) return;
  sentThisSession = true;
 
  try {
    await functions().httpsCallable('appCheckHeartbeat')({
      enforced: isAppCheckEnforced(),
      version: `${nativeApplicationVersion}(${nativeBuildVersion})`,
    });
  } catch {
    // 届かないことが観測対象です。ここでは何もしません
  }
}

翌朝はこの一本だけを引きます。未検証だったセッションが、アプリのバージョン別に割れて出てきます。

gcloud logging read \
  'jsonPayload.message="app_check_heartbeat" AND jsonPayload.verified=false' \
  --project "$FIREBASE_PROJECT_ID" --freshness=24h \
  --format='value(jsonPayload.version)' \
  | sort | uniq -c | sort -rn

出力の先頭に古いビルド番号が並んでいれば、原因は enforcement ではなく、そのバージョンがまだ市中に残っていることです。先頭が最新ビルドなら、debug provider か初回起動の窓を疑います。App Check コンソールの未検証リクエスト数はバージョンで割れないので、この心拍ログが実質的に唯一の割り方でした。

代償も書いておきます。心拍はセッションごとに callable を 1 回増やします。ロールアウトの二週間だけ全数で回し、落ち着いたら Remote Config の比率で 10% に落とす運用にしております。本番の実処理系は enforceAppCheck: true のままで、緩めるのはこの一本だけです。

メトリクス監視とアラート設定

enforcement を 100% に上げた翌日からの一週間で、私が必ず追うメトリクスは次の四つです。

第一に Crashlytics の Daily Crash-free Users。前週比で 0.05% 以上下がっていたら、App Check 由来のリクエストブロックを疑います。Crashlytics のレポート自体が App Check で落ちていれば数値が動かないので、必ず到達セッション数と一緒に見ます。

第二に Remote Config の fetchAndActivate 成功率。Cloud Logging で remoteconfig.googleapis.com/v1/projects/.../fetch の 200 比率が 99% を割っていれば、Remote Config 自体のリクエストが App Check で落ちている兆候です。

第三に AdMob の ad_request → impression 比率。これは App Check と独立とはいえ、もし Realtime Database 経由で広告制御フラグを引いている場合、Realtime Database 側が App Check で落ちると間接的にフィルレートが下がります。

第四に App Check コンソールの「未検証リクエスト数」。enforcement 100% でこの数値が継続的に出続けているなら、debug provider 未設定の社内端末か、古いバージョンのアプリが残っている可能性が高いです。どちらなのかは前節の心拍ログがバージョン別に割ってくれるので、まずそこを開きます。古いバージョン側は強制アップデート設計を別途用意するのが本筋ですが、当面の運用としては Remote Config の appCheckMinVersion フラグで対象を絞り込むのが現実的です。

これらをスプレッドシートにまとめて、毎朝 7 分だけ眺める運用を 1 ヶ月続けると、App Check の本番投入が「怖くない作業」に変わります。逆に言えば、ここを見ずに enforcement だけ全開にすると、月曜の朝に「Crashlytics が静かで素晴らしい」と勘違いする側に回ります。

App Check はうまく入れれば、AdMob の支払いの安定と Firebase バックエンドのコスト削減に同時に効く、個人開発にとって珍しく相性の良い投資先です。実装の参考になれば嬉しいです。