Gemini API のタスク別 Temperature ベストプラクティス — 翻訳・要約・コード生成・チャットそれぞれの最適値

import { Callout } from '@/components/ui/callout';

Gemini API を使いはじめて最初に「これは効くな」と気付くパラメータが temperature です。同じプロンプトでもこの値が 0.0 か 1.0 かで応答の雰囲気がまったく変わります。一方で「結局いくつにすればいいの？」という質問に答えてくれる資料は意外と少なく、temperature=0.7 とデフォルトのまま動かしている実装をよく見かけます。

私自身、複数のサービスで Gemini を使ってきて、タスクごとに「ここはこの値が安定する」という肌感覚が見えてきました。ここではそれを再現性のある形でまとめます。コード例は Python と TypeScript の両方を載せています。

Temperature とは何を制御しているのか

技術的には、Temperature は次の確率分布の鋭さを制御するパラメータです。

• temperature=0.0 — 最も確からしいトークンを毎回選ぶ（決定論的）
• temperature=1.0 — モデルが学習した分布のまま選ぶ
• temperature>1.0 — 分布が平坦になり、低確率のトークンも出やすくなる

これを実用的な言葉に翻訳すると、「低い＝安定・退屈、高い＝創造的・不安定」という対立軸になります。タスクの性質に応じて、この軸のどこに寄せるかを決めるのが temperature 設計の本質です。

タスク別ベストプラクティス

私が現場で使っている目安をまとめます。値は単一の正解ではなく、目的と評価基準に応じて微調整してください。

翻訳タスク: temperature=0.1〜0.3

翻訳は意味の再現性が最優先で、創造性は不要です。私は 0.2 を起点にしています。

from google import genai
 
client = genai.Client()
 
def translate_to_japanese(text: str) -> str:
    response = client.models.generate_content(
        model="gemini-2.5-pro",
        contents=f"以下の英文を自然な日本語に翻訳してください。\n\n{text}",
        config={"temperature": 0.2},
    )
    return response.text

0.0 まで下げると逐語訳になりがちで、文脈に応じた語彙選択が失われます。0.2 あたりが「正確かつ自然」のスイートスポットです。逆に 0.5 を超えると、原文に無いニュアンスが滑り込みやすくなります。

要約タスク: temperature=0.2〜0.4

長文記事の要約では、0.3 を中心にしています。要約は「情報の圧縮」が本質なので、温度は低めに保ちつつ、自然な日本語にするための余白を少しだけ持たせる感覚です。

import { GoogleGenAI } from '@google/genai';
 
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
 
async function summarizeArticle(article: string): Promise<string> {
  const response = await ai.models.generateContent({
    model: 'gemini-2.5-pro',
    contents: `次の記事を 200 字以内で要約してください。\n\n${article}`,
    config: { temperature: 0.3 },
  });
  return response.text ?? '';
}

長尺コンテンツの自動要約パイプラインでは、要約結果のばらつきを少なくしたいので低めに振ります。一方、SNS 投稿用の短いキャプション生成では 0.5〜0.7 まで上げると、人間が手で書いたような表現の幅が出ます。

コード生成タスク: temperature=0.0〜0.2

コード生成は再現性が命です。同じ要件で何度呼び出しても同じコードが返ってきてほしいので、ほぼ 0.0 で固定します。

def generate_function(spec: str) -> str:
    response = client.models.generate_content(
        model="gemini-2.5-pro",
        contents=f"以下の仕様で Python の関数を実装してください。型ヒント必須。\n\n{spec}",
        config={"temperature": 0.0},
    )
    return response.text

私が運営している Dolice Labs シリーズ（Claude Lab、Gemini Lab など）でコード例を生成するときも temperature=0.0 を基本にしています。0 だと「面白みがない」と言われることもありますが、コードに面白みは要りません。動くこと、テストが通ること、保守性が高いことが価値です。

ただし、UI コンポーネントの初期デザインなど「複数の候補を見たい」場合だけは 0.5〜0.7 に上げ、3〜5 候補を生成して人間が選ぶワークフローにします。

対話・チャットボット: temperature=0.7〜0.9

対話エージェントでは「同じ質問を 2 回したら同じ答え」だとロボットっぽくなり、ユーザー体験を損ないます。0.8 を中心にすると、応答の表現が適度に揺れて自然な会話感が出ます。

def chat_response(user_message: str, history: list) -> str:
    response = client.models.generate_content(
        model="gemini-2.5-pro",
        contents=[*history, {"role": "user", "parts": [{"text": user_message}]}],
        config={
            "temperature": 0.8,
            "top_p": 0.95,
        },
    )
    return response.text

ここで重要なのは、top_p も合わせて調整することです。Temperature が高くても top_p=0.95 などで上位候補に絞れば、品質を保ちながら多様性が出せます。

創作・ブレインストーミング: temperature=0.9〜1.2

詩・物語・キャッチコピー生成のような創作タスクでは、1.0 前後まで上げます。多様な発想を引き出したい場合は 1.2 まで上げて、人間が選別する流れにすると効果的です。

ただし、1.5 を超えると意味が崩れた応答が混じるようになるので注意が必要です。Gemini 2.5 系では 1.0 が安全圏の上限と感じています。

分類・抽出タスク: temperature=0.0

「このメッセージはポジティブ／ネガティブ／中立のどれか」のような分類、エンティティ抽出、構造化データ生成では 0.0 以外の選択肢はありません。再現性が品質そのものなので、温度を上げる理由がありません。

タスクと温度の対応表（早見用）

Temperature を「測る」習慣を持つ

数値の目安はあくまで起点で、自分のプロンプトとデータに対してどの値が最適かは実測するしかありません。私は新しいパイプラインを組むときに、必ず次のような評価スクリプトを走らせます。

import statistics
 
def evaluate_temperature_stability(prompt: str, target_temp: float, n_trials: int = 5):
    """同じプロンプトを n 回呼んで、応答の長さ・類似度を観察する"""
    responses = []
    for _ in range(n_trials):
        r = client.models.generate_content(
            model="gemini-2.5-pro",
            contents=prompt,
            config={"temperature": target_temp},
        )
        responses.append(r.text)
    
    lengths = [len(r) for r in responses]
    print(f"Temperature: {target_temp}")
    print(f"  応答長: 平均={statistics.mean(lengths):.0f}, 標準偏差={statistics.stdev(lengths):.0f}")
    print(f"  ユニーク応答数: {len(set(responses))} / {n_trials}")
    return responses

これを temperature=0.0, 0.3, 0.7, 1.0 で走らせて応答長のばらつきとユニーク率を見ると、自分のタスクの「適正温度ゾーン」が肌感覚として身に付きます。

よくある勘違い

実装現場で時々見かける勘違いを2つ整理しておきます。

勘違い1: Temperature を下げれば必ず精度が上がる

0.0 にすると確かに再現性は上がりますが、複雑な推論タスクでは「正しい答えに辿り着く前に最初の候補にロックインされる」現象が起きます。難しい数学問題や多段階推論では 0.3〜0.5 のほうがむしろ正解率が上がることがあります。

勘違い2: Temperature だけが応答品質を決める

実際には top_p（核サンプリング）、top_k（トップk個に絞る）、max_output_tokens、システムプロンプトの設計、すべてが組み合わさって最終的な応答が決まります。Temperature は重要ですが、唯一のパラメータではありません。

次のアクション

まずは現在の実装で temperature がどの値になっているかを確認してみてください。デフォルトのままなら 1.0 です。本記事の表に従って、タスクに応じて 0.0〜0.3 に下げるだけで、応答の安定感が大きく変わるはずです。実測スクリプトを 1 回走らせれば、自分の用途に最適な値が見えてきます。