◈ Agents & Manager/2026-05-25上級

Antigravity エージェントのコスト按分設計 — 複数プロダクトで実行コストをテナントに帰着させる Showback アーキテクチャ

Antigravity の AI エージェントを複数プロダクトで並行運用する際の実行コストを、テナント単位で正しく按分する Showback アーキテクチャを、4 サイト × 6 アプリの実運用ログを添えて整理しました。

antigravity⁴³⁵ agents⁹⁰ cost-attribution showback multi-tenancy production⁵⁹

✦ プレミアム記事

複数のプロダクトで Antigravity のエージェントを並行稼働させはじめてから、月末に Google Cloud と Anthropic の請求書を眺めるたびに「このコストはどのプロダクトが食ったのか、自信を持って答えられない」という気持ち悪さが残るようになりました。私は 2014 年からの個人開発で累計 5,000 万 DL のアプリ事業と、Dolice Labs の 4 サイト（Claude Lab・Gemini Lab・Antigravity Lab・Rork Lab）を並行運用していて、エージェントが触れる対象は壁紙アプリの AdMob 連動最適化から、各 Lab サイトの記事自動生成・Crashlytics トリアージまで横断します。共通のキャッシュ・共通の Gemma4 推論ノード・共通の Claude Agent SDK ジョブキューを使っているので、請求書を見ても「壁紙アプリ単独でいくら」「Claude Lab の記事生成でいくら」が分離できていませんでした。

最初は雑に「アプリ事業のほうが規模が大きいから 7 割はそっちだろう」と振り分けていたのですが、ある月に AdMob の eCPM 最適化エージェントが想定外のリトライ嵐を起こして、月予算の 71% を 1 つのテナントが吸い上げていた事故が起きました。按分が雑だと、原因の特定にもボトルネックの優先順位付けにも 1 日以上かかります。これを 2 時間以内に判定できる状態に持っていくために組み直したのが、本稿で整理する Showback アーキテクチャです。

Showback とは元々クラウド業界の用語で「実行コストをチャージはしないが、テナント別に見える化する」設計を指します。Chargeback（実際に課金まで行う）よりも一段ライトで、まずは「誰が・いつ・何に使ったか」を全部の経路で計測してダッシュボードに出すところを徹底するアプローチです。個人開発レベルでも、複数プロダクトを横断するエージェント運用ではこれが効きます。

Tenant ID をどう運ぶか — Context Propagation の設計

Showback の出発点は「すべてのコスト発生イベントに、誰のためのコストかというラベル（Tenant ID）が必ず付いている」状態を作ることです。これが抜け落ちると、月末の集計で「unattributed: ¥98,400」のような不気味な余りが残り続けて、せっかくの按分の信頼性が崩れます。

私が採用しているのは TypeScript の AsyncLocalStorage を使った Context Propagation です。エージェントの入口（HTTP リクエスト・Cron トリガー・キュー consumer のいずれか）でテナントを確定させ、そこから先のすべての非同期処理に、引数を増やすことなく Tenant ID を運びます。Next.js Route Handler から呼び出すバージョンは以下のような形になります。

// src/lib/tenant-context.ts
import { AsyncLocalStorage } from "node:async_hooks";
 
export type TenantContext = {
  tenantId: string;        // 例: "wallpaper-zen-ios" / "claudelab-net" / "internal-cron"
  productGroup: "app" | "lab" | "internal";
  invocationId: string;    // 1 リクエスト = 1 ID
  budgetCapJpy?: number;   // 月次キャップ（任意）
};
 
const storage = new AsyncLocalStorage<TenantContext>();
 
export function runWithTenant<T>(ctx: TenantContext, fn: () => Promise<T>) {
  return storage.run(ctx, fn);
}
 
export function currentTenant(): TenantContext {
  const ctx = storage.getStore();
  if (!ctx) {
    // 「unattributed」を生まないために、未設定はエラーで弾く
    throw new Error("tenant context missing — runWithTenant() で必ず包んでください");
  }
  return ctx;
}

設計上のポイントは 3 つあります。第 1 に、未設定をデフォルト値で許容しないこと。「unknown テナント」「default テナント」のような逃げ道を作ると、ある日気づくと 4 割のコストがそこに溜まります。私は最初の 1 週間、ここでよくエラーを踏みましたが、結果的に未計測パスが綺麗に洗い出されたので、デフォルト禁止は本番運用の前提として強く推奨します。

第 2 に、invocationId を必ず ULID か UUIDv7 で発行すること。後述する Showback Ledger でユニーク制約をかけて二重計上を防ぐためです。第 3 に、productGroup をエージェント側で分類しておくこと。私の場合は app / lab / internal の 3 区分にしておくと、月次レポートの軸を切り替えるときに楽になります。

コスト計測の単位 — トークン・リクエスト・副作用の 3 軸

Antigravity エージェントの実行コストは、単一の単位で測ろうとすると必ずどこかが歪みます。私は次の 3 軸で計測しています。

第 1 軸はトークン課金で、Gemini 3 Pro Thinking のような LLM 呼び出し本体のコストです。Anthropic と Google の単価は input / output で異なるので、課金単価表をテーブルに持って「呼び出し時の単価 × トークン数」を都度記録します。エージェントの再試行を含めて全部を残すので、Tier 1 へのフォールバック中の冗長な呼び出しも漏れません。

第 2 軸はリクエスト課金で、ツール側 API の都度課金（Apple Search Ads API・Crashlytics Reporting API・Stripe API など）と、Cloudflare Workers の Invocation 課金です。1 リクエスト ¥0.001 のような単位で積み上がるので、按分しないと「誰が呼んだか」が消えがちです。

第 3 軸は副作用で、エージェントが本番に書き込んだ結果のコスト（広告配信費・通知送信費・SMS / メール送信費）です。これは LLM コストの 3〜10 倍規模になることが普通なので、Showback でいちばん重要な軸です。たとえば AdMob mediation の A/B テスト用に内製のキーワード入札エージェントを動かすと、エージェント側のトークンコストは月 ¥4,200 ですが、結果として動く広告予算は月 ¥180,000 を超えます。後者を計測しないと「LLM 安いから問題なし」と判断ミスをします。

実装は薄いラッパーで十分です。Anthropic SDK と Google AI SDK を「テナント付き」で呼ぶ薄い層を作るだけで、コードの大半は元のまま動きます。

// src/lib/cost-meter.ts
import { currentTenant } from "./tenant-context";
import { writeLedgerRow } from "./ledger";
 
type Pricing = { inputPer1k: number; outputPer1k: number; currency: "JPY" };
 
const PRICING: Record<string, Pricing> = {
  "gemini-3-pro-thinking":      { inputPer1k: 0.42, outputPer1k: 2.10, currency: "JPY" },
  "claude-opus-4-6":            { inputPer1k: 2.25, outputPer1k: 11.25, currency: "JPY" },
  "gemma4-27b-onprem":          { inputPer1k: 0.00, outputPer1k: 0.00, currency: "JPY" }, // 電気代は別途
};
 
export async function meterLlmCall<T>(opts: {
  model: keyof typeof PRICING;
  inputTokens: number;
  outputTokens: number;
  result: T;
}): Promise<T> {
  const tenant = currentTenant();
  const p = PRICING[opts.model];
  const costJpy =
    (opts.inputTokens / 1000) * p.inputPer1k +
    (opts.outputTokens / 1000) * p.outputPer1k;
 
  await writeLedgerRow({
    tenantId: tenant.tenantId,
    productGroup: tenant.productGroup,
    invocationId: tenant.invocationId,
    axis: "tokens",
    model: opts.model,
    units: opts.inputTokens + opts.outputTokens,
    costJpy,
    occurredAt: new Date().toISOString(),
  });
 
  return opts.result;
}

副作用軸も同じ形のラッパーで実装します。axis: "side_effect" を別行で書き込んで、ledger は 3 軸すべてを同じテーブルに溜めます。同一テーブルにしておくと、後述の月次レポートで SUM(cost_jpy) GROUP BY tenant, axis の素直なクエリでまとめられて運用が楽になります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Tenant ID を AsyncLocalStorage で安全に伝播させる TypeScript ミドルウェアの実装と、Antigravity エージェントの 3 つの実行レイヤー（プロンプト・ツール呼び出し・副作用）へ漏れなく差し込む構成

✦月間 ¥320,000 規模のエージェント実行コストを 17 個のテナント（4 サイト + 6 アプリ + 7 内製ジョブ）へ自動按分する Showback Ledger のスキーマと、Cloudflare D1 + Workers Cron で月次レポートを生成する具体実装

✦個人開発 12 年・累計 5,000 万 DL の現場で実際に起きた『1 テナントが月予算の 71% を吸い上げていた』事例の検知から、48 時間以内にトークン消費を 42% 削減した按分→ボトルネック分析の流れ

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

Showback Ledger のスキーマ設計

私は Cloudflare D1 を使っていますが、Postgres でも SQLite でも同じスキーマで動きます。ledger は append-only の単一テーブルで、後から消したり書き換えたりしません。

CREATE TABLE IF NOT EXISTS cost_ledger (
  id                INTEGER PRIMARY KEY AUTOINCREMENT,
  invocation_id     TEXT NOT NULL,
  tenant_id         TEXT NOT NULL,
  product_group     TEXT NOT NULL CHECK (product_group IN ('app','lab','internal')),
  axis              TEXT NOT NULL CHECK (axis IN ('tokens','requests','side_effect')),
  model             TEXT,
  units             REAL NOT NULL,
  cost_jpy          REAL NOT NULL,
  occurred_at       TEXT NOT NULL,
  created_at        TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE (invocation_id, axis, model, units, occurred_at)
);
 
CREATE INDEX idx_ledger_tenant_time ON cost_ledger (tenant_id, occurred_at);
CREATE INDEX idx_ledger_axis_time   ON cost_ledger (axis, occurred_at);

ユニーク制約は意図的に複合キーで貼っています。再試行や at-least-once 配信で同じ計上が 2 回走ったときに INSERT OR IGNORE で落とせるようにしたかったからです。本番運用を 7 ヶ月続けて、この複合キー設計だけで月平均 1.2% の重複計上を黙って吸収できていることが確認できています。

書き込みは非同期キューに逃がす実装を推奨します。エージェント本体のレスポンスタイムに ledger 書き込みを直列で混ぜると、Cloudflare D1 の遅延ピーク時にエージェント全体が引きずられます。私は Cloudflare Queues に逃がして、ピーク時で 38 ms かかっていた書き込みを 0.4 ms に短縮しました。10 倍速くなったとは言いませんが、95 パーセンタイルでの体感は大きく改善しました。

月次按分レポートと閾値アラート

ledger が貯まれば、レポートは素直な集計クエリで作れます。私が毎月 1 日 9:00 JST に Cloudflare Workers Cron で回している月次レポート生成は以下のような構造です。

// src/cron/monthly-attribution.ts
export default {
  async scheduled(_evt: ScheduledEvent, env: Env) {
    const now = new Date();
    const firstOfThisMonth = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth(), 1));
    const firstOfLastMonth = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth() - 1, 1));
 
    const rows = await env.DB.prepare(`
      SELECT tenant_id, product_group, axis,
             SUM(cost_jpy) AS cost_jpy,
             COUNT(DISTINCT invocation_id) AS invocations
      FROM cost_ledger
      WHERE occurred_at >= ? AND occurred_at < ?
      GROUP BY tenant_id, product_group, axis
      ORDER BY cost_jpy DESC
    `).bind(firstOfLastMonth.toISOString(), firstOfThisMonth.toISOString()).all();
 
    // 総額に対するシェアを後段で計算しておく
    const total = rows.results.reduce((s, r: any) => s + r.cost_jpy, 0);
    const report = rows.results.map((r: any) => ({
      ...r,
      share_pct: total > 0 ? (r.cost_jpy / total) * 100 : 0,
    }));
 
    // しきい値判定 — 単一テナントが月予算の 40% を超えたら slack 通知
    const HEAVY_TENANT_THRESHOLD = 40;
    const heavy = report.filter(r => r.share_pct >= HEAVY_TENANT_THRESHOLD);
    if (heavy.length > 0) {
      await notifySlack(env, "showback-heavy-tenant", heavy);
    }
 
    await env.DB.prepare(
      "INSERT INTO monthly_report (year_month, payload_json) VALUES (?, ?)"
    ).bind(firstOfLastMonth.toISOString().slice(0, 7), JSON.stringify(report)).run();
  },
};

40% 閾値は経験則ですが、4 サイト + 6 アプリの規模で運用していると、健全な月は最大テナントが 25〜32% に収まります。40% を超えたら「異常」と判断して即座に深掘りに入ります。ここでの「異常」とは、必ずしも障害ではなく、想定外のリトライ・想定外のキャッシュミス・想定外のプロンプトサイズ膨張のいずれかが裏で起きているサインです。

実運用の数値 — 4 サイト × 6 アプリでの按分実例

具体的な数値を出します。直近の 1 ヶ月（2026 年 4 月分）の Antigravity エージェント関連の総コストは ¥316,800 で、Showback Ledger からの按分結果は次の通りでした。

アプリ事業（壁紙 Zen・癒し系 3 本・引き寄せ系 2 本）合計: ¥189,400（59.8%）
Lab 事業（Claude / Gemini / Antigravity / Rork の 4 サイト）合計: ¥98,200（31.0%）
内製ジョブ（バックアップ・Crashlytics トリアージ・スケジュール監視）: ¥29,200（9.2%）

軸別の内訳を見ると、トークン課金が ¥48,200（15.2%）、API リクエスト課金が ¥21,800（6.9%）、副作用（広告配信費・通知送信費の按分相当）が ¥246,800（77.9%）でした。LLM のトークン代は思っているより小さく、副作用が圧倒的に大きいことが数字で見えてきます。

トラブル検知の例も 1 件紹介します。2026 年 3 月のある日、Showback ダッシュボードで「壁紙 Zen iOS の AdMob 最適化エージェント」が月初 7 日で月予算の 71% を吸い上げていることが見えました。深掘りすると、Apple Search Ads API のレート制限到達後に 30 秒間隔のリトライが暴走していて、ツール呼び出し回数が想定の 12 倍になっていました。原因がわかれば対処は早く、48 時間以内にリトライバックオフを exponential + jitter に直して、トークン消費を 42% 削減できました。

Showback がなければ、月末の請求書を見て「全体としてはまだ予算内だな」と思ったまま見過ごしていた可能性が高い事象です。テナント別に按分が見えていたからこそ、月初 7 日の段階で気付けたのが大きかったと感じています。

私の判断と次にやること

ここまでが現状の実装ですが、改善余地は残っています。私が次の四半期で取り組もうと考えているのは、(1) 副作用軸の按分精度を上げる（広告配信費の按分は現状「キャンペーン名 → テナント」の単純マッピングなので、共有予算の按分に揺れがある）、(2) Showback から Chargeback への段階移行（Lab 事業を Stripe メンバーシップで黒字化する過程で、コスト感を内部的にも持ちたい）、(3) 月次の異常検知をルールベースから IQR ベースの統計検知へ移す、の 3 点です。

エージェントを複数プロダクトで運用している方には、まず Tenant Context の伝播だけでも入れることを強く推奨します。Ledger スキーマや月次レポートは後から足せますが、Context が抜けたまま走ったコストは遡及できません。私自身、最初の 3 ヶ月のデータは Context 未整備で「unattributed」が 18% も出てしまい、結局その期間の分析は諦めました。

最後になりますが、ここまで読んでいただきありがとうございました。複数のプロダクトでエージェントを走らせている個人開発者の方の参考になれば嬉しいです。