AIモデルの乗り換えで出力は変わるか｜検証の設計と指標の作り方

AIモデルの乗り換えでは、出力が「なんとなく変わった」という印象だけで語られがちです。本記事は、社内の定型業務でAIモデルを乗り換える検証をどう設計し、どの指標を作るかを整理します。検証環境は2026-07-29時点のAnthropic公式ドキュメントで、自社で実測した数値は使いません。

01結論：AIモデル乗り換え検証は、印象ではなく指標で判断する

結論を先に示します。AIモデル乗り換え検証は、次の3点を先に決めてから始めます。

• 比較する業務とサンプルを検証前に固定し、結果を見てから追加しない
• 出力の一致度・所要時間とトークン量・互換性の3系統で指標を作る
• 合否の基準を検証前に数値か明確な尺度で決め、判定後に動かさない

なぜ印象での判断が危険かというと、同じモデルへ同じ入力を送っても、出力は毎回まったく同じにはならないからです。Anthropicの公式移行ガイドは、temperature = 0を使っても過去のモデルで同一の出力は保証されなかったと明記しています。1回の実行結果だけで「劣化した」「良くなった」と判断すると、単なるばらつきをモデルの変化と取り違えます（出典: Anthropic公式移行ガイド、2026-07-29確認）。

モデルを乗り換えるタイミングそのものの判断基準は、『新モデルは発表当日に入れない｜導入前の検証チェックリスト』で扱っています。本記事はその前段にあたる、検証そのものの設計と指標の作り方に絞ります。

02モデル乗り換えで「なんとなく変わった」と感じる3つの原因

「なんとなく変わった」という感覚は、次の3つの原因のどれかから生まれます。原因を切り分けないまま検証を始めると、指標を作っても判定がぶれます。

1. 非決定性を1回の実行で判断してしまう：同じ入力・同じモデルでも出力は揺れます。1回の比較では、揺れなのか本当の変化なのか区別できません
2. ベースラインを凍結せずに比較する：旧モデルの出力を保存する前に切り替えを進めると、あとから比べる基準そのものが残りません
3. プロンプト以外の変更が紛れ込む：モデルを変える作業のついでにシステムプロンプトのテンプレートも更新し、どちらの変化かわからなくなる

3つ目は現場で頻発します。モデルIDを書き換えるタスクのついでに、同じファイル内のプロンプト文言も直してしまい、比較後に「モデルの差なのか文言の差なのか」を切り分けられなくなるケースです。この場合、モデル変更とプロンプト変更は別のコミット・別の検証回として分けます。

03モデル乗り換え検証の対象業務とサンプルはどう選ぶか

検証の対象は、新しく作ったテスト文ではなく、実際に運用しているプロンプトから選びます。Anthropicの公式ドキュメントも、評価は実運用のタスク分布を写し取るように設計すべきだとしています。エッジケースを含めることも合わせて勧めています（出典: Anthropic公式ドキュメント「Define your success criteria」、2026-07-29確認）。

エッジケースには、無関係な入力・極端に長い入力・あいまいで人間でも判断が割れる入力が含まれます（出典: 同ドキュメント）。得意な業務のログだけを集めると、実際には壊れている苦手な業務が検証をすり抜けます。

サンプル数についても考え方が示されています。少数を人手で丁寧に採点するより、多少ラフでも自動採点できる問いを数多く用意する方を優先する、という原則です（出典: 同ドキュメント）。

Anthropicの公式移行ガイドも、モデルを切り替えるたびに費用と応答速度を自社ワークロードで測り直すよう勧めています（出典: 同ガイド、2026-07-29確認）。

他社が公表したベンチマーク値を流用せず、自社の業務ログを基準にするという考え方です。この考え方は出力比較にもそのまま当てはまります。

この原則をモデル乗り換え検証に当てはめると、少数の代表業務だけを厳密に見るより、業務の種類ごとに複数件ずつサンプルを集め、機械的に判定できる項目を増やす設計が優先されます。

対象業務を決めたら、旧モデルの出力を先に保存しておきます。乗り換え後にしか比較できない状態を作ると、ベースラインが存在しないまま判定することになります。

04AIモデル乗り換え検証の指標をどう作るか｜4つの観点

指標は、比較して終わりではなく、あとから同じ形式で読み直せる状態まで作り込みます。次の4つの観点に分けて設計します。

①の評価方法は、業務の出力形式によって使い分けます。ラベル判定のような正解が1つに定まるタスクは、完全一致評価が向きます。自由記述の文章は、意味の近さをLLMに判定させる評価が向きます（出典: Anthropic公式ドキュメント「Define your success criteria」）。

③のトークン量は、公式のcount_tokensエンドポイントを使うと、実際にメッセージを生成せずに数えられます。このエンドポイントは、ツールや画像・ドキュメントを含めたメッセージのトークン数を、実行前に算出します（出典: Anthropic公式APIリファレンス、2026-07-29確認）。

import anthropic

client = anthropic.Anthropic()

def count_tokens(model_id: str, messages: list) -> int:
    result = client.messages.count_tokens(model=model_id, messages=messages)
    return result.input_tokens

old_tokens = count_tokens("旧モデルのID", messages)
new_tokens = count_tokens("新モデルのID", messages)
diff_ratio = (new_tokens - old_tokens) / old_tokens

同じ入力でもモデルが変わればトークン化のされ方が変わるため、旧モデルのトークン数を使い回さず、新旧それぞれで数え直します。差分比率が大きいほど、Usage limitへ到達する速度や1回あたりの費用が変わる可能性が高まります。

キャッシュを使っている業務では、指標にキャッシュ利用率も加えます（出典: Anthropic公式ドキュメント「Prompt caching」、2026-07-29確認）。プロンプトキャッシュのヒット有無は、レスポンスのusageフィールドで確認できます。cache_read_input_tokensとcache_creation_input_tokensの両方が0なら、そのプロンプトはキャッシュされていません。

キャッシュ対象になる最小の長さもモデルごとに異なります（出典: 同ドキュメント、2026-07-29確認）。たとえばClaude Opus 5・Fable 5・Mythos 5は512トークン、Claude Sonnet 5等は1,024トークンが最小のキャッシュ対象長です。モデルを乗り換えると、これまでキャッシュされていたプロンプトが対象外になる、あるいは新たに対象になることがあります。

05差分の合否判定｜モデル切り替えで結果をどう見るか

指標を集めても、合否の線引きが後から決まる状態では判定になりません。良い成功基準には4つの条件があります。具体的・測定可能・達成可能・関連性があることです（出典: Anthropic公式ドキュメント、2026-07-29確認）。

この考え方をモデル切り替えの判定に当てはめると、「品質が落ちていないこと」ではなく「分類ラベルの一致率が何%以上であること」のように、数値か明確な尺度まで具体化します。判定の3段階を、検証前にあらかじめ決めておきます。

判定者が採点するときは、どちらのモデルの出力かを伏せた状態で見る運用にすると、先入観による採点のブレを減らせます。どちらのモデルかを知った状態で採点すると、新モデルの出力を無意識に甘く見る、あるいは厳しく見るという傾向が生まれやすくなります。

合否の基準を検証中に動かすと、判定そのものが意味を失います。結果を見てから「この程度のズレなら許容範囲にしよう」と基準を緩めると、その検証はモデルの比較ではなく結論に合わせた後付けの説明になります。

06業務のログを使ってモデル乗り換えを判定する4つの代替指標

自社は定額プランを契約しているため、タスク単位の円建てコストは構造的に測定できません（実測台帳2026-07-28時点）。この場合、業務のログから次の4つの代替指標を組み立てます。

• 所要時間：業務の開始から完了までの経過秒数をログに残す
• トークン量：count_tokens APIで新旧モデルのトークン数を数え、差分比率を記録する
• 往復回数：ツール呼び出しを伴う業務で、完了までに何回のやり取りが発生したかを数える
• キャッシュ利用率：cache_read_input_tokensとcache_creation_input_tokensの比率から、キャッシュがどれだけ効いているかを記録する

これらはどれも、モデルを乗り換える前から仕組みとして記録しておく必要があります。乗り換えた後に慌てて計測を始めると、旧モデルの値と比較できません。

ログの取り方は難しくありません。業務を実行するスクリプトに、開始時刻・終了時刻・ツール呼び出し回数を記録する処理を1か所ずつ足すだけです。count_tokensの結果とキャッシュ関連のusageフィールドも同じログへ書き出しておくと、あとから4指標をまとめて集計できます。

定額と従量課金のどちらの契約形態を選ぶかという入口の判断は、『AIエージェントの料金｜定額と従量を分ける判断軸3つ』で扱っています。本記事は契約形態を変えないまま、乗り換え検証の指標だけを設計する場面に絞ります。

07モデル乗り換え検証でつまずきやすい5つの落とし穴

設計どおりに進めても、次の5つは見落としやすい点です。

• ベースラインを凍結し忘れる：旧モデルの出力を保存する前に切り替えを進めてしまい、あとから比較する基準が残らない
• 1回の実行結果だけで判定する：非決定性を考慮せず、たまたま出た1回の出力を「変化した」と結論づける
• 判定者が採点中にどちらのモデルかを知っている：先入観が採点結果に混ざり、指標の信頼性が下がる
• 得意な業務だけで検証する：エッジケースを含めずにサンプルを選び、実際には壊れている業務が検証をすり抜ける
• 合否基準を結果を見てから動かす：検証前に決めた数値や尺度を、結果を見た後に緩めたり厳しくしたりする

出力の中身が事実として正しいかどうかまで踏み込んで判定したい場合は、『ハルシネーション対策｜誤り5類型と関門4か所の対応表』の誤り類型が判定基準として使えます。形式が保たれていても、事実関係が誤っているケースは①の一致度指標だけでは拾えません。

08チェックリスト

• 比較する業務とサンプルを検証前に固定し、結果を見てから追加しなかった
• 旧モデルの出力をベースラインとして保存してから切り替えを進めた
• 同じ入力を複数回実行し、非決定性によるばらつきを確認した
• 出力の一致度・所要時間とトークン量・互換性の指標をそれぞれ用意した
• count_tokens APIで新旧モデルのトークン数を数え、差分比率を記録した
• 合否の判定基準を検証前に数値か明確な尺度で決め、判定後に動かさなかった
• 判定者がどちらのモデルの出力かわからない状態で採点した（可能な場合）
• 定額プランの場合、円ではなく所要時間・トークン量・往復回数・キャッシュ利用率で比較した
• 検証結果と判定基準を記録し、あとから参照できる場所に残した

09FAQ