GEMINI LABEN
FLASH35 — Gemini 3.5 Flashが一般提供となり、gemini-flash-latestが指す実体になりました。日常的な生成を速く安価にこなせますAGENTS — Gemini APIのManaged Agentsがpublic previewに。Google管理の隔離Linuxサンドボックスで自律的なエージェントを構築できますMEDIA — Nano Banana 2 Lite(画像)とGemini Omni Flash(動画・会話的編集)がAI Studio・API・Enterprise Agent Platformで利用可能にTTS — gemini-3.1-flash-tts-previewの音声生成がstreamGenerateContent経由でストリーミング対応になりましたTRANSLATE — 新しい音声モデルが70以上の言語を自動判別し、話者の自然な抑揚を保ったままライブ音声翻訳を行いますSPENDCAP — AI Studioにプロジェクト単位の費用上限が導入され、支出を安全側に抑えられるようになりましたFLASH35 — Gemini 3.5 Flashが一般提供となり、gemini-flash-latestが指す実体になりました。日常的な生成を速く安価にこなせますAGENTS — Gemini APIのManaged Agentsがpublic previewに。Google管理の隔離Linuxサンドボックスで自律的なエージェントを構築できますMEDIA — Nano Banana 2 Lite(画像)とGemini Omni Flash(動画・会話的編集)がAI Studio・API・Enterprise Agent Platformで利用可能にTTS — gemini-3.1-flash-tts-previewの音声生成がstreamGenerateContent経由でストリーミング対応になりましたTRANSLATE — 新しい音声モデルが70以上の言語を自動判別し、話者の自然な抑揚を保ったままライブ音声翻訳を行いますSPENDCAP — AI Studioにプロジェクト単位の費用上限が導入され、支出を安全側に抑えられるようになりました
記事一覧/高度な活用
高度な活用/2026-07-02上級

プロンプトを直した後、過去の成果物をどこまで作り直すか — 予算で区切る計画的バックフィルの設計

プロンプト改善後に残る旧世代の生成物を、全件再生成せず予算と優先度で作り直す設計です。選定スコア・編集検知ハッシュ・置換前ゲート・再開可能なカーソルを実装コード付きで解説します。

gemini-api276バックフィル運用設計9コスト最適化25パイプライン2

プレミアム記事

個人開発で運営しているアプリのメタデータ生成パイプラインで、タグ付けプロンプトの改訂に成功した日のことでした。新しいプロンプトで生成したタグは明らかに具体的で、検索との噛み合いも良い。ようやく納得のいく形になった、と一息ついた直後に気づきました。

旧プロンプトで生成した成果物が、およそ4,200件残っている。

改善は「これから作るもの」にしか効きません。過去の成果物は旧世代のまま。ここで「全部作り直せばいい」と考えるのは自然ですが、私自身、この素朴な全件再生成で二度ほど痛い目を見ています。本記事は、その反省から辿り着いた「予算で区切る計画的バックフィル」の設計をまとめたものです。

全件再生成が最適解にならない理由

まず費用の概算です。手元のケースでは、1件あたりの入力が画像込みで平均2,800トークン、出力が約400トークン。gemini-3.5-flash 相当の単価で計算すると、4,200件の一括再生成はおよそ数ドル〜十数ドルの範囲に収まります。金額だけ見れば「一晩で流せば終わり」に見えます。

問題は金額ではありませんでした。

第一に、上書きの被害です。過去の成果物の一部には、人の手で直した箇所が含まれています。レビューで指摘を受けて手修正したタグ、法務的な理由で言い回しを変えた説明文。全件再生成はこれらを容赦なく旧に復してしまいます。私はこの事故を一度起こし、どれを手で直したのか記録がないせいで、復旧に生成費用の何倍もの時間を使いました。

第二に、品質が上がる保証のない件が混ざることです。プロンプト改訂は平均を押し上げますが、個々の件では旧出力のほうが良いケースが普通にあります。実測では、改訂後プロンプトでの再生成のうち約8%は、ルールベースの検査で旧出力より劣ると判定されました。

第三に、クォータの食い合いです。再生成トラフィックは日次の定常処理と同じプロジェクトのレート制限を消費します。深夜バッチと重なった日は、定常側が 429 を返し始めました。

観点全件一括再生成計画的バックフィル
費用一括で発生・上限なし日次予算で頭打ち
人手修正無条件に上書き編集検知でスキップ
品質の逆行混入する(実測 約8%)置換前ゲートで棄却
定常処理への影響レート制限を食い合う実行窓と速度を分離
中断・再開途中で止まると状態不明カーソルで翌日再開

この比較に行き着いてから、バックフィルは「一度のイベント」ではなく「小さく回り続ける常設の工程」として設計するようになりました。

「作り直す価値」を点数にする — 選定スコアラー

全件を対象にしない以上、どの成果物から作り直すかを決める基準が要ります。私は4つの要素を重み付きで合成しています。

  1. 露出 — 実際に閲覧・使用されている頻度。使われていない成果物の改善は後回しにします
  2. 世代差 — 現行プロンプトとの版差。2世代以上前のものを優先します
  3. 品質シグナル — 低評価・報告・検索不一致など、旧出力に問題がある兆候
  4. コスト — 入力が重い件(高解像度画像など)は同点なら後ろへ
# backfill_scorer.py — 再生成候補の点数化
# 何を解決するか: 「どれから作り直すか」を人の勘でなくスコアで決める
import sqlite3
from dataclasses import dataclass
 
WEIGHTS = {"exposure": 0.4, "gen_gap": 0.3, "quality": 0.2, "cost": 0.1}
 
@dataclass
class Candidate:
    item_id: str
    exposure_norm: float   # 0..1 直近30日の使用頻度を正規化
    gen_gap: int           # 現行プロンプト版 - 生成時プロンプト版
    quality_flags: int     # 低評価・報告などの件数
    input_tokens: int
 
def score(c: Candidate, max_gap: int = 5) -> float:
    gap = min(c.gen_gap, max_gap) / max_gap
    quality = min(c.quality_flags, 3) / 3
    cost_penalty = min(c.input_tokens / 8000, 1.0)  # 重い入力ほど減点
    return (
        WEIGHTS["exposure"] * c.exposure_norm
        + WEIGHTS["gen_gap"] * gap
        + WEIGHTS["quality"] * quality
        - WEIGHTS["cost"] * cost_penalty
    )
 
def top_candidates(db: str, limit: int = 500) -> list[tuple[str, float]]:
    conn = sqlite3.connect(db)
    rows = conn.execute(
        """SELECT item_id, exposure_norm, gen_gap, quality_flags, input_tokens
           FROM artifacts WHERE gen_gap >= 1 AND human_edited = 0"""
    ).fetchall()
    conn.close()
    scored = [(r[0], score(Candidate(*r))) for r in rows]
    return sorted(scored, key=lambda x: x[1], reverse=True)[:limit]

重みは最初から正解を狙わず、まず露出を最重視に置くのが実用的です。使われている成果物の改善だけが、体感品質に直結するためです。

スコアには「閾値」も設けます。私の運用では 0.25 を下回る候補は再生成しません。全件消化を目標にすると、価値の薄い再生成に予算が流れ続けます。バックフィルは終わらせるものではなく、閾値の上が空になったら自然に止まるもの、という位置づけが長期運用では安定しました。

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

この記事の続きを読む

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

この記事で得られること
「作り直す価値」を露出・世代差・品質シグナル・コストの4要素で点数化し、上位から予算内で再生成する選定スコアラーの実装
生成時に保存したハッシュで人手修正を検知し、編集済みの成果物を上書きから守る仕組み
新旧出力を比較して悪化を弾く置換前ゲートと、日次予算で止まっても翌日そのまま再開できるカーソル設計
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

または
メンバーシップなら全記事が読み放題 →
シェア

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

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

高度な活用2026-07-10
カテゴリを30から34に増やした日 — 8,000枚を全部かけ直さない差分再分類の設計
分類カテゴリを追加したとき、既存資産を全件かけ直す必要はありません。埋め込みで影響ラベルを絞り、確信度マージンで境界資産を拾う差分再分類の実装と実測値をまとめました。
高度な活用2026-07-09
無料ユーザー一人あたりのトークン予算を決める — AdMob 収益と AI 機能のコストを釣り合わせる設計
レート制限は秒あたりを守りますが、月末の請求は守ってくれません。広告収益から一人あたりのトークン予算を逆算し、呼び出しラッパー一か所で台帳を作り、ソフトキャップで段階的に降格させ、上位1%の消費比率で濫用を検知するまでを、動くコードとともにまとめます。
高度な活用2026-07-07
構造化出力のストリーミングで、完成したフィールドから順に画面へ出す — 不完全なJSONを安全に読む部分パース
responseSchema でストリーミングすると、JSONが閉じるまで画面は真っ白なまま待たされます。不完全なJSONを安全に補完して読む部分パースと、一度出した値を後退させない逆流防止を組み、最初のフィールドまでの体感を実測とともに縮める設計を残します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →