GEMINI LABEN
IMGEOL — 旧来の画像生成モデルが非推奨となり8月17日に停止します。新しい stable もしくは preview のエンドポイントへ移行してくださいREGION — Gemini Enterprise アプリの global リージョンから、8月4日に Gemini 3.5 Flash が選択肢として外れます。リージョンとモデルを組で管理している構成は要確認ですGROK — Gemini Enterprise Agent Platform 上の Grok 4.1 モデルファミリが非推奨となり、8月20日に停止しますFSMM — File Search が gemini-embedding-2 によるマルチモーダル検索に対応しました。テキストへ書き起こす前処理を挟まずに画像を検索対象へ入れられますFLASH36 — Gemini 3.6 Flash と 3.5 Flash-Lite が GA になりました。3.6 Flash はトークン効率と計画能力を上げつつ 3.5 Flash より安い価格帯に置かれていますSAMPLING — サンプリング引数の temperature・top_p・top_k が非推奨になりました。これらを前提にした出力制御は別の手段へ置き換える設計変更が要りますIMGEOL — 旧来の画像生成モデルが非推奨となり8月17日に停止します。新しい stable もしくは preview のエンドポイントへ移行してくださいREGION — Gemini Enterprise アプリの global リージョンから、8月4日に Gemini 3.5 Flash が選択肢として外れます。リージョンとモデルを組で管理している構成は要確認ですGROK — Gemini Enterprise Agent Platform 上の Grok 4.1 モデルファミリが非推奨となり、8月20日に停止しますFSMM — File Search が gemini-embedding-2 によるマルチモーダル検索に対応しました。テキストへ書き起こす前処理を挟まずに画像を検索対象へ入れられますFLASH36 — Gemini 3.6 Flash と 3.5 Flash-Lite が GA になりました。3.6 Flash はトークン効率と計画能力を上げつつ 3.5 Flash より安い価格帯に置かれていますSAMPLING — サンプリング引数の temperature・top_p・top_k が非推奨になりました。これらを前提にした出力制御は別の手段へ置き換える設計変更が要ります
記事一覧/API / SDK
API / SDK/2026-08-01上級

temperature 非推奨で先に困ったのは、決定性ではなく多様性の側でした

temperature・top_p・top_k の非推奨化で影響が出たのは決定性ではなく多様性を作る側でした。呼び出し箇所の数え方、多様性を入力層へ移す設計、実効多様度の測り方を実測値とともに残します。

Gemini API199temperature3移行3回帰テスト2コスト設計10

プレミアム記事

8月17日の画像生成モデル停止について確認していたとき、同じ更新履歴のずっと下の方に短い一行が混ざっていました。temperature・top_p・top_k が非推奨になった、という記載です。

停止日まで明記された項目に比べると、ずいぶん静かな置かれ方でした。

私自身、最初はそれほど身構えていませんでした。個人開発で回しているパイプラインのうち Gemini を呼んでいるのは抽出系が大半で、そこは以前から temperature を 0 に固定していたためです。0 を書けなくなるだけなら、書かなければ済む。その程度の受け止めでした。

実際に手を動かしてみると、順番が逆でした。

揺れて困ったのは、値を 0 に寄せていた側ではありません。値を上げて使っていた側でした。

何箇所が動くのかを、宣言ではなく呼び出しで数える

最初にやったのは影響範囲の把握です。grep -r temperature を打つのは簡単ですが、返ってくるのは「書いた場所」であって「動かす場所」ではありません。

移行の作業量を決めるのは、その値が流れ込む generate_content 呼び出しの数です。デフォルト値を 1 ファイルにまとめてあると、宣言は 1 箇所でも呼び出しは何十箇所にもなります。逆に設定ファイルに書いた値は、コードを grep しても一生出てきません。

そこで、一段だけ間接参照を解決するスキャナを書きました。サンプリング引数を含むブロックから外へ配られる識別子を「運び手」として拾い、その運び手を包み直しただけの層も運び手とみなして、不動点まで伝播させます。

#!/usr/bin/env python3
"""scan_sampling.py — 非推奨サンプリング引数の依存を、
宣言ではなく「影響を受ける呼び出し箇所」で数える。"""
import re
import sys
from pathlib import Path
 
SAMPLING_KEYS = ("temperature", "top_p", "topP", "top_k", "topK")
CODE_EXT = {".py", ".ts", ".tsx", ".js", ".mjs"}
CONF_EXT = {".json", ".yaml", ".yml", ".toml"}
CALL_RE = re.compile(r"generate_?[Cc]ontent")
 
CARRIER_RE = [
    re.compile(r"^\s*(?:export\s+)?(?:const|let|var)\s+([A-Za-z_]\w*)\s*[:=]", re.M),
    re.compile(r"^\s*([A-Z][A-Z0-9_]*)\s*=", re.M),                    # Python 定数
    re.compile(r"^\s*(?:export\s+)?function\s+([A-Za-z_]\w*)", re.M),
    re.compile(r"^\s*def\s+([a-z_]\w*)", re.M),
]
 
 
def carriers_in(text, seeds):
    """サンプリング引数、または既知の運び手を含むブロックから
    外へ配られる識別子名を抽出する。"""
    found = set()
    for rx in CARRIER_RE:
        for m in rx.finditer(text):
            name = m.group(1)
            tail = text[m.start(): m.start() + 400]
            if any(k in tail for k in SAMPLING_KEYS):
                found.add(name)
            elif any(re.search(rf"\b{re.escape(s)}\b", tail) for s in seeds):
                found.add(name)   # 運び手を包み直しただけの層も運び手
    return found
 
 
def scan(root):
    decl, conf, carriers = [], [], set()
    files = [p for p in root.rglob("*") if p.is_file()]
 
    for p in files:
        if p.suffix not in CODE_EXT | CONF_EXT:
            continue
        text = p.read_text(encoding="utf-8", errors="ignore")
        hits = [k for k in SAMPLING_KEYS if k in text]
        if not hits:
            continue
        rel = str(p.relative_to(root))
        if p.suffix in CONF_EXT:
            conf.append((rel, sorted(set(hits))))
        else:
            decl.append((rel, sorted(set(hits))))
            carriers |= carriers_in(text, set())
 
    # 不動点まで伝播させる(defaults -> buildConfig -> cfg の包み直しを追う)
    code_files = [(p, p.read_text(encoding="utf-8", errors="ignore"))
                  for p in files if p.suffix in CODE_EXT]
    for _ in range(5):
        grown = set(carriers)
        for _p, text in code_files:
            grown |= carriers_in(text, carriers)
        if grown == carriers:
            break
        carriers = grown
 
    direct, indirect = [], []
    for p in files:
        if p.suffix not in CODE_EXT:
            continue
        text = p.read_text(encoding="utf-8", errors="ignore")
        lines = text.splitlines()
        rel = str(p.relative_to(root))
        for i, line in enumerate(lines, 1):
            if not CALL_RE.search(line):
                continue
            window = "\n".join(lines[max(0, i - 6): i + 6])
            if any(k in window for k in SAMPLING_KEYS):
                direct.append(f"{rel}:{i}")
            elif any(re.search(rf"\b{re.escape(n)}\b", window) for n in carriers):
                indirect.append(f"{rel}:{i}")
    return decl, conf, sorted(carriers), direct, indirect
 
 
if __name__ == "__main__":
    root = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
    decl, conf, carriers, direct, indirect = scan(root)
    print(f"[declarations] code   : {len(decl)}")
    for rel, ks in decl:
        print(f"  - {rel}  {','.join(ks)}")
    print(f"[declarations] config : {len(conf)}")
    for rel, ks in conf:
        print(f"  - {rel}  {','.join(ks)}")
    print(f"[carriers]            : {len(carriers)} -> {', '.join(carriers)}")
    print(f"[call sites] 直接      : {len(direct)} -> {', '.join(direct)}")
    print(f"[call sites] 間接      : {len(indirect)} -> {', '.join(indirect)}")
    print(f"[total] 移行対象       : {len(direct) + len(indirect)}")

手元の構成を切り出した検証用ツリー(抽出2ファイル・言い換え1ファイル・共有デフォルト2ファイル・設定2ファイル)に当てたときの出力がこちらです。

[declarations] code   : 4
  - src/variation/paraphrase.py  temperature,top_k,top_p
  - src/shared/defaults.ts  temperature,topK,topP
  - src/extract/receipt.py  temperature
  - src/extract/tags.py  temperature
[declarations] config : 2
  - config/profiles.json  temperature,topK,topP
  - config/batch.yaml  temperature,top_k
[carriers]            : 9 -> BASE, CFG, GEN_DEFAULTS, buildConfig, call, cfg, extract, run, variants
[call sites] 直接      : 3 -> src/variation/paraphrase.py:4, src/extract/receipt.py:4, src/extract/tags.py:2
[call sites] 間接      : 1 -> src/shared/agent.ts:3
[total] 移行対象       : 4

注目したのは最後から二番目の行です。src/shared/agent.ts には temperature も top_p も top_k も一文字も書かれていません。buildConfig() を呼んでいるだけです。それでも実際には非推奨の値が流れ込む呼び出しであり、grep だけで作業リストを組むと、ここが最後まで残ります。

数え方件数何を数えているか
grep のヒットファイル6キーワードを書いた場所。設定ファイルを含む
直接指定の呼び出し3呼び出しの前後6行にキーワードがある箇所
間接の呼び出し1運び手経由。grep では出てこない
移行対象の合計4実際に書き換えが要る箇所

宣言 6 に対して呼び出し 4。数としては近いのですが、集合が一致していません。この差を先に潰しておくと、以降の作業が「残りいくつ」で管理できるようになります。

抽出系は、ほとんど揺れませんでした

移行の本命だと思っていた抽出系から手を付けました。レシート画像から金額と店名を取り出す処理と、画像にタグを付ける処理です。どちらも temperature: 0 で運用してきました。

その 0 を落としてみて、出力がどう変わるかを見ました。

結論から書くと、目に見える変化はほとんどありませんでした。理由は考えてみれば単純で、この 2 つはどちらも response_schema を渡していたからです。

温度は出力分布の裾をどれだけ拾うかを調整します。スキーマは出力できる集合そのものを閉じます。enum で選択肢を 5 つに限定してあれば、分布がどう変わろうと 5 つの外は出てきません。数値フィールドを integer で宣言してあれば、揺れる余地は桁の中だけです。

つまり抽出系の安定は、温度ではなくスキーマが担っていました。温度 0 は、その上に重ねた気休めに近い設定だったわけです。

これは事前の想定と逆でした。私はこの経路をいちばん慎重に扱うつもりでいましたが、実際には config から 1 行消すだけで終わりました。

構造化出力を先に入れてある実装ほど、今回の非推奨化の影響は小さくなります。逆に、スキーマを渡さず温度だけで出力を締めていた実装は、ここで一度設計を戻す必要が出てきます。

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

この記事の続きを読む

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

この記事で得られること
grep が示す宣言 6 箇所に対し、実際に移行が要る呼び出しは 4 箇所。うち 1 箇所は temperature を一度も書いていないファイルにありました
多様性を入力層へ移すとキャッシュ割引 75% 時に月額 $125.28 から $82.75 へ(33.9% 減)。割引 0% では 1 ドルも変わらない理由まで分解しています
候補を均等に散らす層別巡回は 8 本中 5 本が重複。貪欲バランス選択で重複 0・最大偏り 1 に収めた実装を載せています
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

API / SDK2026-07-30
二段構成の採算を決めていたのは昇格率ではなく、昇格した集合の出力長でした
Flash-Lite を前段に置き、迷った分だけ 3.6 Flash に昇格させる二段構成。その採算を昇格率だけで見積もると外します。昇格した集合の出力長を式に入れて損益分岐点を解き直した記録です。
API / SDK2026-07-29
出力トークンが17%減ると聞いて、総額はいくら下がるのかを分解した
出力単価16.67%減と出力トークン17%減。二つの数字を足しても総額の下がり方は出ません。単価・数量・交差項への厳密分解と、エージェントループで削減率がむしろ下がった実行結果をまとめました。
API / SDK2026-07-19
静止画か短い動画か — Nano Banana 2 Lite と Omni Flash のコスト桁差で機能の置き所を決める
壁紙アプリの目玉アセットを静止画にするか短い動画にするかで手が止まったとき、決め手になったのは好みではなくコストの桁でした。Nano Banana 2 Lite と Omni Flash の単価を同じ土俵に並べ、動く意思決定関数まで落とし込みます。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →