AI翻訳は実際にどれほど「思考」しているのか？

Geminiは次々と新たな価値をもたらしてくれます。ほとんどの言語において、標準のままでも最高峰の翻訳LLMです。その思考機能を活かせば、慣用表現やアニメの小ネタ、独自のブランドボイス™といった最難関の課題でも解決できます。

問題は、思考には時間がかかることです。思考にはコストも発生し、トークンごとに課金されます。開発者としては、その両方をコントロールしたいところです。

Gemini 2.5では簡単でしたが、Gemini 3では一筋縄ではいかなくなりました。

Transeptのラボで分かったことをご紹介します

Gemini 3での変更点

Gemini 2.5には、推論トークン数の上限を数値で指定するthinkingBudgetがありました。しかし、Gemini 3ではこれが廃止され、代わりにthinkingLevelが導入されました。これはminimal、low、medium、highの4段階から選ぶカテゴリ型の設定です。これら2つのパラメータは排他的であり、現行のSDKでGemini 3モデルに両方を送信すると400エラーが返されます。

これにより、実際の運用における「コスト管理」の意味合いが変わります。以前は、支払ってもよい金額に厳密な上限を設けられました。現在は、「medium」がどの程度かをモデルが自分で判断し、その分だけトークンを消費します。

理由はおそらく、モデルが人間と同じように、タスクの難易度に応じて思考の長さを調整するよう事後学習されているからでしょう。そのため、一律の上限を設けてしまうと、この適応能力が損なわれてしまうのです。

では、low、medium、highでは実際にどれほどのトークンが消費されるのでしょうか？

検証データ

以下は、実際の翻訳トラフィック2週間分から抽出したサンプルデータです。3種類のGemini 3モデルにわたる約1,000件の呼び出しを対象としています。思考トークン数のデータには、最も信頼性の高い情報源である各レスポンスのusageMetadata.thoughtsTokenCountを使用しています。

モデル別の思考トークン数

15,725という数字は誤記ではありません。Flashモデル、しかもmedium設定での1回の翻訳呼び出しで、実に1万5,000トークンもの推論が行われていたのです。

通常、こうしたトークンの急増は、Geminiが生の思考トークンを出力に漏らしてしまうことで発生します。ご存じのとおり、モデルの「思考」は、モデルが本当に「考えている」ことそのものではなく、きれいに整えられた要約にすぎません。LLMの真の推論プロセスは、むしろ意識の流れに近いものです。

ただし、今回のケースで注目したいのは、Geminiが「pure steel rejects lacquers and paints（純鋼は漆や塗料を受け付けない）」という一行を含む文学作品の一節を、英語からウクライナ語へ訳しながら、のんびりと思案を巡らせていたことです。納得のいく出力が得られるまで、12通りほどの候補をしらみつぶしに試し、まるで声に出して確かめるかのように検討を重ねていました。

数週間後の追記：あの15,725という数値は、Geminiが一度きりの熱意を見せた例外ではなく、複雑なタスク特有のパターンでした。

トラフィックの増加に伴い、特にgemini-3.1-flash-liteで同じ数値が何度も記録されるようになりました。15,724～15,729という疑わしいほど狭い範囲で何十件もの呼び出しが集中しており、そのほぼすべてがLiteモデルによる用語集の監査タスクです。興味深いことに、それらは最も高コストになるとは考えにくいlowの思考設定で実行されていました。

11回もまったく同じ数値に達するモデルは、表現を選んでいるのではなく、上限に突き当たっています。lowの思考は約1万5,700トークンで飽和状態に達します。liteのような小型モデルは思考効率が劣るため、難度の高いタスクを与えられると大量のトークンを消費してしまいます。一方で大型モデルではそうした現象は起きず、各トークンが正解に向けた有意義なステップになりやすい傾向があります。

さらに、この飽和にはコストの面でも問題があります。Gemini 3では、思考トークンがmaxOutputTokensの枠を消費します。思考に1万5,700トークンを費やした呼び出しには、回答を出力する余裕がほとんど残りません。しかし、思考トークンはすべて出力トークン料金として請求されます。1万6,000トークンの予算枠では、小さなドキュメントであっても約半数のケースで監査結果が空（finishReason=MAX_TOKENS）になってしまい、調査に乗り出すことになりました。

予算枠を引き上げても、対症療法にしかならず根本的な原因は解決しません。監査の予算をlow設定で3万2,000トークンに拡大したところ、思考が上限まで達した後でも出力用に約1万6,000トークンが確保できるため、空のレスポンスは出なくなりました。しかし、思考トークン数が減ったわけではありません。Gemini 3では思考量に上限を設けられないため、依然として約1万5,700トークンが消費されます。予算枠を増やしたことで、回答の行き場ができたにすぎません。

1万6,000トークンもの過剰な思考（thinkingmaxxing）に対する唯一の実質的な解決策は、タスクのスコープを縮小することでした。

minimalは、約2,000トークンの上限として機能する唯一の設定です。ただし、Liteモデルでのみ利用できます。

タスクタイプ別の思考トークン数（FlashとPro、いずれもmedium設定）

単純な翻訳では、Proの思考量はFlashよりも少なく、その差は2倍近くにおよびます。ProがFlashの思考量を上回るのはリライト作業のときだけです。推論量はタスクの難易度に応じて変化するものであり、モデルのマーケティング上の階層とは関係ありません。

Proが翻訳のベンチマークで優れた結果を出せるのは、まさに必要な場面でより深く思考できる能力を備えているからだといえます。

実践的なポイント

• Gemini 3モデルではthinkingBudgetを設定しないでください。無視されるか、エラーが発生します。
• mediumの上限は固定されていません。呼び出しごとの思考トークン数は、2,000ではなく90パーセンタイルで約4,000トークンを見込んでおくのが現実的です。
• コストに厳密な上限を設けたい場合は、可能な限りminimalを使用してください。出力を途中で停止しても課金は発生するため、あまり意味がありません。
• 呼び出しごとに課金している場合は、すべてのレスポンスでusageMetadata.thoughtsTokenCountを確認してください。この数値はレスポンス本文には含まれませんが、請求書には記載されます。
• 設定がmediumの場合、Proは単純なタスクでは中央値より思考量が少なくなり、難易度の高いタスクでは思考量が増える傾向があります。LiteやFlashにはこのような変動は見られません。

つまり、Proは一般的なLLMの水準を超えた校正や推敲に最も適したモデルです。まさにそうした場面でProの創造性が発揮されます。一方、下書きの翻訳にはFlashのほうが向いています。

ただし、それには時間もコストもかかります。Transeptでは、最も難易度の高い部分にのみProを適用するスマートな校正ロジックによって、Proにかかるコストを抑える方法を見出しました。また、計画の立案や判断にはProを使用し、実際の実行作業はより小規模なモデルやファインチューニングされたモデルに任せています。

こうすることで、すべてがうまく機能します。