AIのモデルを替えるたびに起きたことと、比べてから替える決まり

2026年3月から10月にかけて、5秒バトルの AI 審判、LifeRewind の物語の生成、AIBloom の記事の生成で、Gemini のモデルや思考の設定を何度も替えました。替えたときや、替える前に比べたときに、判定の過剰解釈、400 エラー、混雑を示す 503 の連続、出力の型の崩れに当たっています。きっかけは、モデル名や設定の小さな変更でした。10月には、本番と同じプロンプトと引っかけを含む問題で候補を比べてから替える形になり、AIBloom ではそれを「切り替える前に必ずローカルで比較評価する」という運用の決まりとして文書に書きました。

軽いモデルに替えて、12分で戻した

2026年3月3日、5秒バトルの AI 審判のモデルを gemini-2.5-flash から gemini-2.5-flash-lite に替えました。コミットの件名の末尾は「（様子見）」です。12分後には元に戻していて、件名は「Geminiモデルをgemini-2.5-flashに戻す（liteは過剰解釈が多すぎた）」です。どんな回答をどう誤って判定したのか、何回試したのかは、記録に残っていません。

AI 審判は、プロンプトで判定の決まりを渡しています。音声で「犬猫豚」のようにつながった答えを分けること、漢字の誤変換は読みが合えば正解にすること（例として柿→牡蠣）、パーティゲームなので寛容に判定すること、です。AI 審判のモードでは、正しいと判定された項目の数が、そのままラウンドの点数（最大3点）になります。

思考の設定は、世代ごとに書き方が違った

5秒バトルでは、Gemini が答える前に考える量を設定で0にしていました。

3月2日、AI 審判のデバッグの途中で、この設定（thinkingConfig）の置き場所を、生成の設定（generationConfig）の外に移しました。AI のコーディング支援と書いたこのコミットの本文には、「Gemini 2.5 Flash の仕様では thinkingBudget は generationConfig 外に置く必要がある」とあります。翌3日のコミットは、この設定を「非対応フィールドによる400エラー」として消し、2分後に generationConfig の中へ戻しています。置き場所は1周して、最初の位置に戻りました。

書き方の違いは、モデルの世代の間にもありました。10月に書き直した共用のサーバー処理には、次のコメントがあります。

 * - Gemini 2.x は thinkingLevel を 400 で拒否するので thinkingBudget のみ
 * - Gemini 3.x は thinkingLevel を使う（3.5-flash-lite は thinkingBudget: 0 を 400 で拒否）

5秒バトルも10月に、モデル名から設定を組み立てる形にしました。

function buildThinkingConfig(model: string) {
  if (model.startsWith('gemini-2.')) return { thinkingBudget: 0 };
  if (NO_MINIMAL_THINKING_MODELS.includes(model)) return { thinkingLevel: 'low' };
  return { thinkingLevel: 'minimal' };
}

NO_MINIMAL_THINKING_MODELS は、いちばん軽い段階の minimal を受け付けないモデルの一覧です。

プレビュー版の 503 で、比べられなかった

3月6日の夜、LifeRewind と Butterfly Effect の物語の生成で、思考量（thinkingBudget）を0から256まで変えて比べました。多くの値は6つの入力を2回ずつ、12回流しています。モデルは、プレビュー版の gemini-3.1-flash-lite-preview です。残った結果のファイルを数えると、8・32・64・256 の4つは12回すべて失敗し、失敗のほとんどは 503 でした。16 は最初の12回で8回成功しましたが、32 とあわせて流し直した比較では、どちらも12回中0〜2回しか成功していません。エラーの文は「This model is currently experiencing high demand.」で、混雑を示すものです。失敗が設定によるものか、その時間帯の混雑によるものかは分けられず、比較になっていません。

翌7日の朝8時前後に、指定を思考の段階（thinkingLevel）の4つに替えて、同じ12回を流し直しました。4つとも12回すべて成功し、平均の応答時間は minimal 3.15秒、low 3.80秒、medium 5.96秒、high 6.88秒でした。既定には low を選んでいます。選んだ理由は記録にありません。

同じプレビュー版のモデルは、AIBloom でも4月14日に、その呼び出し方では使えず 503 や 429 を返し続けるとして、一部の呼び出しを gemini-2.5-flash に替えています。Chronicle AI では4月20日に、失敗したトピックを止めておく時間を24時間から6時間に短くしました。コミットの理由は「503 輻輳系の失敗は時間帯依存が強いため、6h 後に再試行する方が復旧しやすい。」です。6時間は4月の時点の設定です。10月8日からの新しい公開の仕組みでは、503 や時間切れのような一時的な失敗は数えず、休ませもしません。採点や検査で落ちたときなど、記事の中身の失敗のときに、そのトピックを翌日まで休ませます（3回続くと7日）。

思考が出力の枠を使い切った

3月8日、SubTrim で、明細の文から登録の候補を作る AI の機能について、Gemini（gemini-3.1-flash-lite-preview）と OpenAI の gpt-5-nano・gpt-5-mini を比べました。3つの通知文を渡し、JSON として読めるか、サービス名・金額・プラン・分類などが合うかの7項目を機械で照合します。1回の満点は21点です。gpt-5-nano は5回のうち4回が19点、Gemini は8回で1〜15点でした。

点が低い回の出力を見ると、出力の上限220トークンのうち200トークン以上を思考に使い、答えは「Here is the JSON」のような前置きの数トークンで途切れて、JSON まで届かなかった回があります。README の結論は「Gemini を使うなら GEMINI_THINKING_LEVEL=low が minimal / medium よりマシでしたが、品質はまだ OpenAI fallback より弱いです。」でした。この AI の機能は、3月27日に公開版の画面から外しています。

出力の型も変わった

10月2日、5秒バトルの AI 審判を gemini-3.5-flash-lite に替える前の比較で、このモデルは出力の型を指定しないと、正誤の欄を真偽値ではなく文字列の "false" で返すことがありました。結果の画面は isValid が真になる項目を数えて点数にするので、文字列の "false" は「あり」と数えられてしまいます。出力の型（responseSchema）を指定すると、22回の呼び出しで174項目すべてが期待どおりになりました。指定しないときは、174項目のうち2項目がずれていました。

比べてから替える

5秒バトル

10月2日、私は5秒バトルについて「回数・品質・速度などから最適なモデルを選択してほしい」と頼みました。AI の作業者は、本番と同じ判定のプロンプトで候補のモデルを比べました。問題には「赤い食べ物」のような易しいお題に加えて、「ラーメンの種類」に「うどん、そば、パスタ」と答えるような引っかけを入れ、回答の1項目ずつの判定を期待値と照合しています。引っかけの組の結果は次のとおりです。

易しい組では、gemini-2.5-flash が「お寿司のネタ」の「柿、ハマチ、エビ」の柿を不正解にしました。プロンプトが正解の例に挙げている、柿→牡蠣の誤変換です。3月に12分で外した 2.5-flash-lite は、このとき「no longer available to new users」の 404 を返す呼び出しがありました。

私の了承のあと、既定を gemini-3.5-flash-lite、予備を gemini-3.5-flash にしました。混雑の 503 と10秒の時間切れでは、予備のモデルに回します。ただし、比較のスクリプトは作業用の一時フォルダーに置かれ、結果は作業のログにしか残っていません。

その後、予備の gemini-3.5-flash は10月10日に廃止され、呼び出しは gemini-3.6-flash へ自動で転送されるようになりました。3.6-flash は10月2日の比較でも流していて、引っかけの組は66項目中66でしたが、混雑の 503 が多く、応答も 3.5-flash より遅めでした。10月7日には Google から、これからのモデルは temperature などの指定を送ると 400 エラーで拒否するという通知が来ていました。10月16日に確かめた公式の説明では、既定の gemini-3.5-flash-lite と 3.6-flash は、temperature をもう受け取っても使っていません。5秒バトルが送っていた temperature は、その時点ではどちらのモデルでも使われていなかったことになります。

10月16日に、予備を gemini-3.6-flash と直接書き、temperature を送らないように直しました。10月19日には、今の本番と同じ設定（出力の型あり、temperature なし）で、10月2日と同じ問題を既定と予備に流し直しました。今度は、比較のスクリプトと結果をリポジトリに入れています。

どちらも全項目が期待どおりで、予備は 3.6-flash のままです。3.6-flash では、混雑の 503 が1回ありました。各モデル22回の判定なので、まれにしか起きない誤りまでは見分けられません。

AIBloom

前日の10月1日には、AIBloom でも同じ形の比較をしています。私は、新しいモデルへ自動で切り替えるのが危ないなら、ローカルで各モデルに記事を書かせて比べてほしいと頼みました。AI の作業者は、同じ元記事4本から、モデルと元記事の読み方の組み合わせごとに記事を作りました。3回目の比較では、元記事の URL を直接読ませる gemini-3.5-flash-lite が4本とも書き終え、1本9〜11秒でした。検索で調べながら書くそれまでの gemini-2.5-flash は27〜34秒、gemini-2.5-flash-lite は4本中2本で記事の冒頭の設定の欄が欠けていました。新しい gemini-3.8-flash は、別に試した回も含め、混雑の 503 などで1本も書き終えられませんでした。

作業者が元記事と突き合わせた評価では、gemini-3.1-flash-lite の記事に元記事を読まずに書いたものがあり、8本中3本に元記事に無い内容が入っていました。

決まりとして残したもの

AIBloom の運用ルールの文書には、モデルの切り替えについて次の決まりがあります。

• 新モデルへの自動切替はしない（*-latest の別名も使わない）
• 切り替える前に必ずローカルで比較評価する
• 生成した記事は元記事と突き合わせて事実を確かめる

比べるためのスクリプトはリポジトリに入れ、生成した記事は git の管理外のフォルダーに出します。5秒バトルでは、思考の設定をモデル名から組み立て、出力の型を指定し、503 と時間切れのときは次のモデルに回す形になっています。共用のサーバー処理でも、思考の設定はモデル名から組み立てます。

各作品の制作の記録は、過去の制作の一覧に載せています。英会話アプリのイエタでは、決まった問題を流して別のモデルに採点させてから、モデルを替えました。その比べ方と結果は、イエタで固定の問題を別のモデルに採点させてモデルを選んだ制作ノートに書いています。AI に作業させた結果を別の仕組みで確かめる考え方は、改善ループのゲート設計についての制作ノートにまとめました。