2026 年に入ってから、手元で運用している壁紙・癒し・引き寄せ系のアプリ群のうち 7 本が Gemini API を直接叩く構成に変わりました。最初の数本は素朴に各アプリ内に API キーと呼び出しコードを散らしていたのですが、4 本目あたりで「先月の Gemini 課金、どのアプリで使った分なのか分からない」という小さな事故が起き、ここで一度立ち止まって全体を作り直しています。
複数アプリを並行運営している個人開発者であれば、おそらく同じ景色を見たことがあるはずです。アプリごとに API キーがあり、アプリごとにモデル名がハードコードされ、コストはまとめて Google Cloud の請求書に積まれる。表面的には動いているのに、運用の解像度がどんどん落ちていく状態です。
そこで頼りになるのが「Gemini API コントロールプレーン」という発想です。私自身が 12 ヶ月ほど運用してきた構成をもとに、その実装を一通り整理しておきます。Firebase Remote Config と軽量な中継関数（Cloud Functions または Cloudflare Workers）で実装できる、個人開発の規模感に合わせたミニマム構成です。
なぜ「中央管理層」を一枚挟むのか
複数アプリ運用の文脈で Gemini API を直接呼ぶと、最終的にぶつかる問題はだいたい次の 3 つに収束します。
- モデルバージョンの一斉切り替えができない。
gemini-2.5-flashをgemini-3.1-flashに上げたいだけなのに、アプリ 7 本ぶんのストア審査を待つ必要があります - アプリ別のコスト按分ができない。GCP の請求書はプロジェクト単位で見えますが「壁紙アプリのオンボーディング生成」と「引き寄せ系アプリの日替わりメッセージ」の比率は分かりません
- 異常検知のしきい値をアプリ単位で持てない。突発的に呼び出しが跳ねたとき、それが個別アプリの暴走なのかポートフォリオ全体のトレンドなのか判定できません
これらは全部「アプリと Gemini API の間に薄い中央管理層を 1 枚挟むだけ」で解消します。アプリは中央管理層に対して「テキスト生成して」「画像説明して」とだけ言い、モデル選択・コスト集計・レート制御は中央側が責任を持つ、という構造です。
商用 SaaS の世界でいう「LLM Gateway」や「Model Router」と同じ発想ですが、累計 5,000 万 DL 規模のアプリ事業を一人で回している前提だと、Portkey や LiteLLM のような専用ミドルウェアは少し大げさになります。Firebase Remote Config と Cloudflare Workers だけで充分実用に耐える、という結論に私は落ち着きました。
3 層構造：Config / Routing / Telemetry
コントロールプレーンが担うべき責務は、整理すると次の 3 層に分かれます。
| レイヤ | 役割 | 主な実装 |
|---|---|---|
| Config | どのアプリにどのモデル設定を渡すか | Firebase Remote Config（条件付き値配信） |
| Routing | リクエストの実際の宛先決定とフォールバック | Cloudflare Workers（軽量中継） |
| Telemetry | usage_metadata の収集と日次集計 | BigQuery + Google Sheets（按分レポート） |
この分離が曖昧だと、たとえばモデル切り替えのロールバックを「Worker のコードを書き換えてデプロイし直す」ことになり、即応性が落ちます。私の運用ではどの層もデプロイなしで設定変更できることを必須要件にしています。
Config 層：Remote Config の条件付き値
Firebase Remote Config はクライアント向けの A/B テスト用途で語られがちですが、ここでむしろサーバー側で読みに行く設定ストアとして使います。値はバージョン管理され、変更履歴と即時ロールバックが標準でついてくるので、個人開発の運用速度に合います。
具体的には、アプリごとに次の JSON を 1 つの Remote Config パラメータ gemini_app_config として持ちます。
{
"wallpaper_app": {
"model": "gemini-3.1-flash",
"fallback": "gemini-2.5-flash",
"max_tokens": 1024,
"rate_limit_per_minute": 30,
"rollout_percent": 100,
"budget_jpy_per_day": 800
},
"healing_app": {
"model": "gemini-3.1-flash",
"fallback": "gemini-2.5-flash",
"max_tokens": 512,
"rate_limit_per_minute": 20,
"rollout_percent": 25,
"budget_jpy_per_day": 300
},
"attraction_app": {
"model": "gemini-2.5-flash",
"fallback": "gemini-2.5-flash-lite",
"max_tokens": 768,
"rate_limit_per_minute": 15,
"rollout_percent": 100,
"budget_jpy_per_day": 200
}
}rollout_percent は後述する段階導入の判定値で、budget_jpy_per_day は Telemetry 層と連動してサーキットブレーカーの根拠になります。
Remote Config の REST API は管理者用の OAuth 2.0 トークンが必要で、レート制限も厳しめなので、Worker からは 5 分キャッシュ前提で読みに行きます。実装は次のとおりです。
// worker/config.ts
type AppConfig = {
model: string;
fallback: string;
max_tokens: number;
rate_limit_per_minute: number;
rollout_percent: number;
budget_jpy_per_day: number;
};
let configCache: { value: Record<string, AppConfig>; expiresAt: number } | null = null;
export async function getAppConfig(env: Env, appId: string): Promise<AppConfig> {
if (configCache && configCache.expiresAt > Date.now()) {
return configCache.value[appId];
}
const token = await getRemoteConfigAccessToken(env);
const res = await fetch(
`https://firebaseremoteconfig.googleapis.com/v1/projects/${env.GCP_PROJECT}/remoteConfig`,
{ headers: { Authorization: `Bearer ${token}` } }
);
const body = await res.json<RemoteConfigResponse>();
const raw = body.parameters.gemini_app_config.defaultValue.value;
const parsed = JSON.parse(raw) as Record<string, AppConfig>;
configCache = { value: parsed, expiresAt: Date.now() + 5 * 60 * 1000 };
return parsed[appId];
}ここで重要なのは、Worker 側にモデル名やバジェットの「デフォルト値」を持たせないことです。Worker は判定ロジックだけを持ち、値そのものは必ず Remote Config から取りに行く構造にしておくと、後で値だけ変えたいときの摩擦がなくなります。
Routing 層：呼び出しと段階導入
アプリは Worker のエンドポイント /v1/generate に対して appId 付きで叩きます。Worker 側で Config を引いて、rollout_percent を見ながら新モデルか旧モデルかを決め、Gemini API に転送します。
// worker/router.ts
export async function generate(req: GenerateRequest, env: Env): Promise<GenerateResponse> {
const cfg = await getAppConfig(env, req.appId);
await assertWithinBudget(env, req.appId, cfg.budget_jpy_per_day);
await assertRateLimit(env, req.appId, cfg.rate_limit_per_minute);
const useNewModel = hashUser(req.userId) % 100 < cfg.rollout_percent;
const model = useNewModel ? cfg.model : cfg.fallback;
const t0 = Date.now();
const result = await callGemini(env, model, req.prompt, cfg.max_tokens);
const elapsed = Date.now() - t0;
await emitTelemetry(env, {
app_id: req.appId,
model_used: model,
rollout_branch: useNewModel ? "new" : "fallback",
prompt_tokens: result.usageMetadata.promptTokenCount,
output_tokens: result.usageMetadata.candidatesTokenCount,
elapsed_ms: elapsed,
timestamp: new Date().toISOString(),
});
return { text: result.text, model };
}hashUser(req.userId) % 100 < cfg.rollout_percent の判定が肝で、同じユーザーは常に同じ分岐になります。これがないと「セッション中にモデルが切り替わって応答スタイルが急に変わる」体験事故が起きます。
私の運用では新モデルの段階導入は必ず 5 → 25 → 100 の 3 段階で、各段階を最低 48 時間止めます。48 時間は深夜帯と昼間帯を最低 1 周することと、AdMob のレポート反映遅延（最長 24 時間）に合わせた数値です。
Telemetry 層：usage_metadata の集約と按分
callGemini の戻り値に含まれる usageMetadata がコスト按分の生命線です。次のような形で BigQuery のテーブルに 1 行ずつ書き出します。
CREATE TABLE gemini_usage (
timestamp TIMESTAMP NOT NULL,
app_id STRING NOT NULL,
model_used STRING NOT NULL,
rollout_branch STRING NOT NULL,
prompt_tokens INT64 NOT NULL,
output_tokens INT64 NOT NULL,
elapsed_ms INT64 NOT NULL
)
PARTITION BY DATE(timestamp);ここから日次でアプリ別コストを按分するクエリは次の形になります。価格は gemini_pricing ビューにモデル別 1M トークン単価を持たせています。
SELECT
DATE(timestamp, "Asia/Tokyo") AS jst_date,
app_id,
model_used,
SUM(prompt_tokens) AS in_tokens,
SUM(output_tokens) AS out_tokens,
ROUND(
SUM(prompt_tokens) / 1000000.0 * p.input_usd_per_1m +
SUM(output_tokens) / 1000000.0 * p.output_usd_per_1m,
4
) AS usd_estimated
FROM gemini_usage u
JOIN gemini_pricing p USING (model_used)
WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY jst_date, app_id, model_used, p.input_usd_per_1m, p.output_usd_per_1m
ORDER BY jst_date DESC, usd_estimated DESC;このクエリを Google Sheets の Apps Script から朝 7 時に叩いて、ポートフォリオ全体のアプリ別 Gemini 課金見積もりを 1 シートに溜め込んでいます。GCP の請求書が月末にしか出ないのに対し、こちらは前日分が翌朝 7 時に見えるので、運用判断が 1 ヶ月単位から 1 日単位に縮まりました。