◈ API / SDK/2026-06-04上級

AdMob レポートの判定は Gemini にやらせない — 構造化出力を「抽出」に限定する設計

AdMob レポートからフロア（eCPM 下限値）を決めるとき、Gemini に判定そのものをやらせるのは危険です。構造化出力は「乱れたレポートを型付きデータに抽出する」工程だけに限定し、しきい値判定は決定論的なコードに置く——その設計理由と実装を、実際の 42 グループ運用の判定ルールとともにまとめました。

Gemini API¹⁹² 構造化出力¹² AdMob⁹ アプリ収益化² 設計³

✦ プレミアム記事

AdMob のレポートからフロア（eCPM 下限値）を決める作業を自動化するとき、多くの人が最初に思いつくのは「レポートを丸ごと Gemini に渡して、各グループの新しいフロアを答えさせる」です。私も最初はそうしかけたのですが、すぐにやめました。しきい値の計算と判定を LLM にやらせると、その判定が監査できなくなるからです。フロアの設定は収益に直結する不可逆な操作で、「なぜこの値になったか」を後から再現できない仕組みは、運用に乗せてはいけません。

個人開発でアプリを運営していると、収益の大半を AdMob のメディエーションに預けることになります。その都合上、フロアの見直しは毎月避けて通れない作業です。手元では iOS・Android を合わせて 42 のメディエーショングループを抱えていて、これを勘で動かすわけにはいかないので、判定を少しずつ仕組みへ落とし込んできました。その過程で腑に落ちたのが、Gemini の構造化出力は「判定」ではなく「抽出」にこそ強い、ということです。以下では、構造化出力を抽出工程だけに限定し、判定をコードに分離する設計を、実際に運用している判定ルールとともに示していきます。

なぜ判定を LLM にやらせてはいけないのか

フロアの判定ルール自体は、実は完全に決定論的です。私が使っているルールはこうです。iOS のフロアは実勢 eCPM × 55% を基準にし、現フロア / eCPM の比率が 65% を超えていたら引き下げ、比率が 40% 未満かつマッチ率が 95% を超えていたら引き上げ、その中間（40〜65%）は維持。最小単位は $0.50。Android は実勢比ではなく一律 $0.50 固定です。

このルールは四則演算としきい値比較だけで完結します。つまり、LLM に「判断」させる余地は本来ありません。にもかかわらず LLM にプロンプトでルールごと渡すと、3 つの問題が出ます。第一に、しきい値の境界（比率がちょうど 65.0% のとき等）で出力がぶれます。第二に、同じ入力でも実行ごとに微妙に違う値が返る可能性があり、再現性が崩れます。第三に、最大の問題として、「比率 64% だから維持」という判断の根拠を、出力からは検証できない。コードなら ratio = floor / ecpm の 1 行を見れば誰でも追えますが、LLM の内部推論は追えません。

フロアの誤設定は、高すぎればフィル率が落ちて no-fill が多発し、低すぎれば eCPM が崩れます。実際、過去に Android INT のフロアを実勢に対して過剰に高く設定していたために、マッチ率が 70% 台で頭打ちになっていたことがありました。こういう「効きすぎ・効かなすぎ」を後から検証して直すには、判定が決定論的でなければなりません。

では Gemini に何をやらせるのか — 「抽出」だけ

一方で、AdMob のレポートを CSV やコピペで受け取ると、データは驚くほど乱れています。グループ名の表記ゆれ、通貨記号の有無、マッチ率が「47.53%」だったり「0.4753」だったり、列順がエクスポート設定で変わる。この乱れた入力を、型の揃った行データに整える工程こそ、Gemini の構造化出力が圧倒的に強い領域です。

ここでのコツは、出力スキーマに「判定結果」を一切含めないことです。スキーマには生の観測値（グループ名・グループ ID・実勢 eCPM・マッチ率・現フロア）だけを定義し、新フロアや「引き上げ/引き下げ」といった判断は絶対にスキーマに入れません。LLM の責務を「乱れた入力 → 型付きの観測値」に閉じ込めるわけです。

import os
from google import genai
from pydantic import BaseModel
 
class GroupRow(BaseModel):
    group_name: str
    group_id: str
    ecpm_usd: float        # 実勢 eCPM（観測値のみ）
    match_rate: float      # 0.0〜1.0 に正規化
    current_floor_usd: float
 
class ExtractedReport(BaseModel):
    rows: list[GroupRow]
 
client = genai.Client(api_key=os.environ["YOUR_GEMINI_API_KEY"])
 
raw_report = open("admob_mediation_report.txt", encoding="utf-8").read()
 
resp = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=(
        "次の AdMob メディエーションレポートを、各グループ 1 行に正規化して抽出してください。"
        "match_rate は 0.0〜1.0 に変換。判定や推奨値は出力しないこと。観測値のみ。\n\n"
        + raw_report
    ),
    config={
        "response_mime_type": "application/json",
        "response_schema": ExtractedReport,
    },
)
 
report: ExtractedReport = resp.parsed

プロンプトに「判定や推奨値は出力しないこと」と明示しているのが肝です。スキーマで縛ったうえで、自然言語でも責務を限定する。これで Gemini は「抽出器」として安定して動きます。

✦

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

この記事の続きを読む

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

この記事で得られること

✦Gemini 構造化出力を「抽出」に限定し、しきい値判定をコードに置く分離設計の理由と実装

✦実運用の 42 グループ向けフロア判定ルール（eCPM×55%・比率しきい値）の決定論的な実装例

✦LLM にしきい値計算をやらせると監査不能になる仕組みと、それを回避する型付きスキーマ設計

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

✦

この記事を購入する

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

または

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

判定はコードに置く — 監査可能な決定関数

抽出された型付きデータに対して、判定は普通の Python 関数で行います。ここが監査の要です。

from dataclasses import dataclass
 
@dataclass
class FloorDecision:
    group_id: str
    current: float
    proposed: float
    action: str       # "raise" / "lower" / "hold"
    reason: str       # 根拠を文字列で残す（監査用）
 
def decide_floor_ios(row) -> FloorDecision:
    ratio = row.current_floor_usd / row.ecpm_usd if row.ecpm_usd else 0
    target = round(row.ecpm_usd * 0.55 / 0.5) * 0.5    # 55% 基準・$0.50 刻み
 
    if ratio > 0.65:
        return FloorDecision(row.group_id, row.current_floor_usd,
                             max(target, 0.5), "lower",
                             f"ratio {ratio:.0%} > 65%")
    if ratio < 0.40 and row.match_rate > 0.95:
        return FloorDecision(row.group_id, row.current_floor_usd,
                             max(target, 0.5), "raise",
                             f"ratio {ratio:.0%} < 40% & mr {row.match_rate:.0%} > 95%")
    return FloorDecision(row.group_id, row.current_floor_usd,
                         row.current_floor_usd, "hold",
                         f"ratio {ratio:.0%} in 40-65% band")
 
decisions = [decide_floor_ios(r) for r in report.rows]

reason フィールドに判断根拠を文字列で残しているのがポイントです。後から「このグループはなぜ維持だったのか」を問われたら、ratio 64% in 40-65% band という機械的な根拠が即座に出ます。LLM にやらせていたら、この一行は決して得られません。判定ロジックを変えたいときも、テストを書いて関数を直すだけで済み、プロンプトを「育てる」必要がありません。

抽出の正しさをどう担保するか

判定をコードに寄せても、抽出が間違っていたら元も子もありません。そこで抽出結果には、コード側で軽いサニティチェックを通します。

def sanity_check(row) -> list[str]:
    issues = []
    if not (0.0 <= row.match_rate <= 1.0):
        issues.append(f"{row.group_id}: match_rate 異常 {row.match_rate}")
    if row.ecpm_usd < 0 or row.ecpm_usd > 200:
        issues.append(f"{row.group_id}: eCPM 異常 {row.ecpm_usd}")
    if row.current_floor_usd < 0:
        issues.append(f"{row.group_id}: 負のフロア")
    return issues

マッチ率が 1.0 を超えていたら、Gemini が「47.53%」を 47.53 のまま入れた可能性が高い。eCPM が異常値なら通貨記号の誤読を疑う。抽出は LLM、その妥当性検証はコードという、前のセクションと同じ「LLM は曖昧な入力に、コードは決定論的な検証に」という役割分担です。インプレッションが 20 未満のグループは判定対象から外す、といった運用上のフィルタも、ここでコードとして明示します。

抽出された行が「全グループ揃っているか」を照合する

行単位のサニティチェックと並んで、私自身が実運用で取りこぼしに気づいてから足したのが、行数そのものの照合です。Gemini の抽出は値の正しさだけでなく、グループの取りこぼしでも失敗します。レポートの末尾が途中で切れていたり、似た名前のグループを 1 行にまとめてしまったりすると、42 あるはずのグループが 41 行で返ってくる。値はどれも妥当に見えるので、前節のサニティチェックは素通りしてしまいます。

そこで、抽出後に「想定しているグループ ID の集合」と照合します。

EXPECTED_GROUP_IDS = {...}  # 運用中のグループ ID を定数で持つ
 
def reconcile_rows(report) -> list[str]:
    got = {r.group_id for r in report.rows}
    missing = EXPECTED_GROUP_IDS - got
    unexpected = got - EXPECTED_GROUP_IDS
    issues = []
    if missing:
        issues.append(f"抽出漏れ: {sorted(missing)}")
    if unexpected:
        issues.append(f"未知のグループ ID: {sorted(unexpected)}")
    if len(report.rows) != len({r.group_id for r in report.rows}):
        issues.append("group_id の重複あり（同一グループを 2 行に分割した可能性）")
    return issues

missing は取りこぼし、unexpected は表記ゆれを別グループと誤認した痕跡、重複は 1 グループを 2 行に割ってしまったサインです。グループ構成は月単位ではほとんど変わらないので、既知の集合を定数で持っておくだけで、抽出の「数」の異常をほぼ確実に捕まえられます。値の検証（前節）と件数の照合（本節）の二段を通して初めて、抽出結果を判定に渡してよい状態になります。

書き込みは人間に残す — パイプラインの終端設計

抽出と判定が終わっても、AdMob の編集画面へフロア値を打ち込む最後の一手は人間に残しています。AdMob の編集画面はボタン ID が動的で、自動入力は入力欄の取り違え事故を起こしやすいためです。パイプラインの出力は「グループごとの提案値と根拠の一覧」までとし、人間がそれを見て入力する。入力後に、抽出と同じ仕組みで編集画面の実値を読み返し、提案値と一致するかを照合します。

この終端設計により、「Gemini が抽出 → コードが判定 → 人間が書き込み → コードが実値を照合」という、各工程の責務が明確に分かれたパイプラインになります。LLM が関わるのは最初の抽出だけで、収益に直結する判定と不可逆な書き込みは、それぞれコードと人間が握る。これが、収益データを扱う自動化で私が推奨する基本形です。

実際の運用ではどれくらいの規模を捌くか

この分離設計で月次に処理しているのは、iOS・Android 合わせて 42 グループ分のレポートです。Gemini への投入は 1 回で全グループ分のテキストを渡し、抽出は数秒で 1 グループ 1 行に正規化されます。そこから先の判定はコードなので一瞬で、42 グループ全件の「提案値＋根拠」一覧が即座に揃います。

直近の月次では、この一覧をもとに引き上げ 3 件・引き下げ 2 件・残り維持、という結果になりました。インプレッションが 20 未満のグループは判定対象から外しているため、データの薄いグループに振り回されません。重要なのは、この「5 件だけ動かす」という判断が、すべて ratio の数値根拠付きで残っていることです。来月、別の人（あるいは未来の自分）がこの判断を見直すとき、根拠の文字列をたどるだけで再現できます。LLM に丸投げしていたら、この再現性は得られませんでした。

この設計が効く範囲

最後に、この「抽出と判定を分ける」設計が効くのは、AdMob のフロア決定に限りません。判定ルールが決定論的に書ける一方で、入力データが乱れている——この条件を満たす業務は、構造化出力で抽出し、判定をコードに置くと、速くて監査可能な自動化になります。レビューのセンチメント分類のように判定自体が曖昧なタスクは LLM に寄せ、しきい値や四則演算で決まる判定はコードに寄せる。この線引きを最初に決めることが、LLM を業務に組み込むときの設計の出発点だと考えています。

まずは自分が LLM に投げているプロンプトを 1 つ見直して、「これは抽出か、判定か」を切り分けてみてください。判定だった部分をコードに移すだけで、出力の再現性と監査可能性が一気に上がるはずです。