新しいモデルの発表を見た日の午後に、「うちも入れ替えましょう」という話が出ます。手元で少し触ってみると、たしかに良さそうに見えます。
止めにくいのは、その判断が間違って見えないからです。新しいほうが良いというのは、多くの場合そのとおりです。ただ「良い」と「いま切り替えても業務が壊れない」は、別の話です。前者は触れば分かりますが、後者は触っただけでは分かりません。
この記事は、新モデルを本番へ入れる前に何を確かめるかを、確かめる順番とセットで整理します。素材は2026-07-29時点のAnthropic公式ドキュメントで、自社で測り直した数値は使いません。
こんなふうに調べていませんか
- 新しいモデルが出るたびに、入れ替えるべきかどうかの判断がつかない
- 「触ってみたら良さそうだった」以外の材料を持っていない
- 切り替えたあとで壊れたとき、どこまで戻せばいいのかを決めていない
この記事を読み終えたときに手に入るもの
- 入れる前に確かめる4つの観点を、確かめる順番つきで持ち帰れます
- 出力・重さ・互換性を、それぞれ何で見るのかが分かります
- 導入・保留・見送りを分ける線を、結果を見る前に引けるようになります
結論30秒でわかる、この記事の結論
- 切り替えの判断は、発表の日ではなく、4つの観点を確かめ終えた日に行います。
- 4つには順番があります。動くかどうかを確かめる前に重さを計算しても、その数字は使えません。
- 不合格だったときにどこまで戻すかは、切り替える前に決めておきます。
01新モデル導入のチェックリストは、AIエージェントの運用で何を守るためのものですか？
高梨課長新しいモデルが出たので来週にも切り替えたい、と言われています。触った感じは良さそうなんですが、このまま入れていいものでしょうか。
鈴木さん触った感じが良いのは、たぶんそのとおりだと思います。ただ、そこで見えているのは出来のよさだけです。いま動いている仕組みが替えても動くかは、別に確かめないと出てきません。
高梨課長別に確かめる、というのは具体的に何をするんでしょう。
鈴木さんふだん流している仕事を、そのまま両方へ通してみます。新しく作った例文ではなく、いま流れているものを使うのがこつです。
守っているのは、モデルの出来ではありません。いま回っている業務が、切り替えた翌日も同じように回る状態です。
確かめるのは次の3点で、どれも触った感触からは出てきません。
- ふだんの定型業務のプロンプトを新旧のモデルへ同じ条件で投げ、出力の形式と内容を突き合わせる
- 定額プランならUsage limitへ到達する速さを、従量課金なら単価とトークン数の変化を見る
- 拡張思考・サンプリングパラメータ・ツール定義など、既存のプロンプトを壊す変更が入っていないかを確かめる
Anthropicの公式移行ガイドも、移行の進め方を示しています。Claude Codeで /claude-api migrate を実行すると、モデルIDの置き換えと破壊的パラメータの変更をコードベース全体へ適用でき、手動で確認すべき項目のチェックリストも生成されます（出典: Anthropic公式移行ガイド、2026-07-29確認）。
この記事のチェックリストは、その機械的な置き換えでは検出できない部分を扱います。置き換えは文字列の話ですが、ここで見るのは業務側の判断です。
02新モデルを発表当日に切り替えると、AI導入の現場では何が起きるんですか？
発表直後の切り替えが危ういのは、破壊的な変更が世代ごとに記録として積み上がっているからです。公式移行ガイドには、拡張思考のパラメータやサンプリングパラメータの廃止など、世代が変わるたびに起きた変更が一覧になっています（出典: 同ガイド）。
つまり、その一覧が手元にある状態と、無い状態があります。当日に切り替えるというのは、一覧を読む前に本番へ影響を出すことと同じ意味になります。
読む前と読んだあとで、作業そのものは変わりません。変わるのは、どこで気づけるかです。読んでいれば設定を直す段で止まり、読んでいなければ本番の出力で止まります。止まる場所が後ろへ行くほど、戻す作業は重くなります。
発表当日を避けるという言い方は、慎重にという精神論ではありません。気づく位置を前へ動かす、という手続きの話です。
この章のまとめ
急がないほうがよい理由は「新しいものは危ないから」ではありません。読めば分かるものを、読む前に本番へ通してしまうからです。
03新モデル導入の出力比較は、AIエージェントに任せている定型業務のどれから始めるんですか？
出力比較は、ふだん使っている定型業務のプロンプトをそのまま新しいモデルへ投げるところから始めます。ここで新しいプロンプトを書き下ろすと、差がモデルのせいなのかプロンプトのせいなのかを切り分けられなくなります。
そのうえで、業務を性質ごとに分けます。要約や分類のように言い回しの違いを許せる業務と、契約書のように数値や固有名詞が1文字ずれても困る業務では、合格の線がそもそも違うからです。分けずに始めると、判定のたびに基準が揺れます。
| 確認項目 | 実施方法 | 判定基準 | 記録する数値 |
|---|---|---|---|
| 形式の維持 | JSON出力を期待するプロンプトを新モデルへ投げる | パース可能な回数÷実行回数 | 実行回数・成功回数 |
| 内容のズレ | 同じ入力を旧・新モデルへ投げ、要点の一致度を人手で採点する | 一致／許容内のズレ／要修正の3段階で判定 | 各段階の件数 |
| ツール呼び出しの互換性 | tool_useの入力をパースしてから比較する | パースエラー0件 | パースエラー件数 |
| 実行時間・往復回数 | 同じタスクを何回のツール呼び出しで完了できたか数える | 旧モデル比で往復回数が増えていない | 往復回数 |
配置図にすると、表からは読み取りにくい区画が浮かびます。言い回しの自由度が高いのに、外したときの影響が大きい業務です。自動では採点しにくく、しかも見落とすと痛い場所になります。
ツール呼び出しを含む業務では、tool_useブロックの入力を文字列のまま突き合わせないようにします。公式移行ガイドは、モデル世代によってJSON内のエスケープ表現が変わりうると明記しています（出典: 同ガイド）。パースしてから値で比べれば、表記のゆれに引っかかりません。
import json
old_input = json.loads(old_tool_use_block.input_json)
new_input = json.loads(new_tool_use_block.input_json)
assert old_input == new_input # 生の文字列比較ではなく、パース後の値で比較する04出力のズレと生成AIの揺れは、導入判断でどう見分けるんですか？
同じ入力を1回だけ投げて比べても、それが揺れなのか本当の劣化なのかは分かりません。最低でも数回は同じ入力を流し、結果のばらつきを先に見ます。
ばらつきの幅そのものが広がっている場合は、モデルの劣化ではなく、こちらの設計の詰めが甘いことも疑います。指示があいまいなプロンプトは、どのモデルで動かしても答えが散るからです。
たとえに置き直すと、見分ける順番がはっきりします。まず自分の測り方が安定しているかを見て、それから相手の変化を見る、という並びです。逆にすると、測り方のぶれを相手のせいにしてしまいます。
05新モデルへ切り替えると、AI活用にかかる重さの見え方はどう変わるんですか？
自社は定額プランを契約しているため、タスク単位の金額を構造的に測定できません（実測台帳2026-07-28時点）。そこで、費用の影響は円ではなく、公式ドキュメントが定義する代理指標で見ます。
| 指標 | 測り方 | 定額プランでの意味 | 従量課金プランでの意味 |
|---|---|---|---|
| トークン数の変化 | 同じ入力をcount_tokensで新旧モデルへ数える | 出力が増えるほどUsage limitへ早く到達する | トークン数増加分がそのまま費用に乗る |
| モデル単価 | 公式料金ページのモデル別単価を比較する | 直接の請求には影響しないが上位プランへの切替判断材料になる | 総コストに直接反映される |
| 往復回数 | エージェント的タスクで何回ツールを呼んだか数える | Usage limitへ到達する速度に直結する | リクエスト回数分の課金が増える |
| キャッシュ利用率 | cache_read_input_tokensの比率を確認する | 同じ処理量でもキャッシュが効けば消費が緩む | キャッシュ読み込みは基本単価の約1割で済む |
重なりを見ると、代理指標が定額プラン専用の妥協ではないと分かります。従量課金でも同じものを数えていて、違うのは単価を掛けて円に直せるかどうかだけです。
定額と従量のどちらを選ぶかという入口の判断は、AIエージェントの料金プランは3軸で選ぶ｜定額と従量の境目で扱っています。この記事は契約プランを変えずに、モデルだけを替えたときの影響に絞ります。
06新モデルを導入すると、同じプロンプトなのに消費量が変わるのは、生成AIの側で何が変わったからですか？
代理指標が要る理由は、切り替えると前提そのものが動くからです。Claude Sonnet 5は、Sonnet 4.6と同じ入力でも、新しいトークナイザーによって約30%多いトークン数になります。これは公式料金ページの注記で確認できます（2026-07-29確認）。同じプロンプトでも、替えた瞬間に消費量が変わるということです。
系統ごとの単価差も無視できません。公式料金ページでは、系統ごとにモデル単価が数倍異なります（出典: Anthropic公式料金ページ）。
- Claude Opus系：入力$5／出力$25（100万トークンあたり）
- Claude Sonnet系：入力$2／出力$10（2026年8月31日まで。9月1日以降は入力$3／出力$15）（100万トークンあたり）
- Claude Haiku系：入力$1／出力$5（100万トークンあたり）
プロンプトキャッシュの効き方も動きます。キャッシュ対象になる最小の長さはモデルごとに違い、Claude Opus 4.8からOpus 5への移行では1,024トークンから512トークンへ下がりました。より短いプロンプトもキャッシュ対象に入っています（出典: 同ガイド）。逆に最小長が上がる移行もあり得るため、替えるたびに確かめます。
この章のまとめ
消費量が変わる原因は、書いた文章の側にはありません。数え方・単価の段・前置きの扱いという、こちらが触っていない場所が動いています。
07新モデルの導入で既存プロンプトは、生成AIの世代が変わるとどこから壊れるんですか？
高梨課長いま動いているコードは、モデルIDを書き替えればそのまま動きますか。
鈴木さん動かないことがあります。壊れる場所は散らばっているようで、実際には決まったところに集まります。
高梨課長どこを先に見ればいいでしょう。
鈴木さん拡張思考の指定、サンプリングの指定、使っているツール、それと止まった理由の扱いです。この並びで見ると、たいてい先に引っかかります。
| 壊れやすい箇所 | 症状 | 確認方法 |
|---|---|---|
| 拡張思考のパラメータ | 固定トークン数を指定する古い書き方が400エラーになる | thinkingパラメータの型を公式ドキュメントで確認する |
| サンプリングパラメータ | temperature等の指定が新モデルで拒否される | 1回のリクエストを送りエラー有無を見る |
| ツールの利用可否 | 特定のツールが新モデルで使えなくなる | 移行先モデルの対応ツール一覧を公式ドキュメントで確認する |
| stop_reasonの種類 | 想定していなかった停止理由が返り、後続処理が止まる | stop_reasonの分岐にrefusal等を追加する |
点検表を分けているのは、送ってみないと分からないものと、ドキュメントを読めば分かるものが混ざっているからです。読めば済むほうを先に消すと、実際に送る回数を減らせます。
Claude Opus 4.7以降のモデルは、temperature・top_p・top_kを指定すると400エラーを返します（出典: Anthropic公式移行ガイド）。拡張思考も同じで、旧世代の固定トークン数指定（budget_tokens）は拒否されます。thinkingパラメータをadaptive（自動）へ書き替える必要があります。
08ツールと停止理由の変更は、AIエージェントのチェックリストでどう拾うんですか？
ツールの対応状況は見落としやすい箇所です。Claude Opus 5ではweb fetchツールが利用できません（出典: 同ガイド）。旧モデルでweb fetchを使っていた処理は、移行の前に代わりの手を検討します。
止まった理由の扱いも増えています。refusalやmodel_context_window_exceededという停止理由は、旧モデルの分岐処理では想定されていないことがあります（出典: 同ガイド）。分岐を足さないまま替えると、この2つが黙って無視されます。
左右に分けて見ると、チェックリストの役目がはっきりします。表に出るものは実行すれば分かるので、リストは黙って通り過ぎるほうのために持ちます。
新しいAPI機能が加わっている場合もあります。会話の途中でシステムプロンプト相当の指示を追加できる機能は、対応するモデルが限られます（出典: 同ガイド）。気づかないまま運用ルールだけを更新すると、想定した挙動になりません。
プロンプトではなく、組織側の設定が原因で拒否されることもあります。最上位クラスの一部モデルは、データ保持設定が一定日数に満たない組織では、すべてのリクエストが拒否されます（出典: 同ガイド）。契約や設定の見落としで動かない場合がある、ということです。
09新モデル導入のチェックリストの最終判定は、AI社員の運用としてどう出すんですか？
確認する順序も結果を左右します。①出力比較→③プロンプト互換性→②コスト影響→④切り戻し基準の順で進めると、手戻りが少なくなります。プロンプトが動かないまま重さだけを計算しても、その数字は使えないからです。
| 観点 | 何を確認するか | 合格の目安 | 主な情報源 |
|---|---|---|---|
| ①出力比較 | 定型業務のプロンプトを新旧モデルへ同条件で投げ、出力の形式と内容を突き合わせる | 期待する形式を崩さず、内容のズレが許容範囲内 | 自社の定型業務ログ・実運用プロンプト |
| ②コスト影響 | 定額プランならUsage limitへの到達速度、従量課金ならトークン単価と単価そのものの変化 | 想定より早くUsage limitに達しない | 公式料金ページ・Models API |
| ③プロンプト互換性 | 拡張思考・サンプリングパラメータ・ツール定義・stop_reasonの破壊的変更の有無 | 既存コードが400エラーを返さない | 公式移行ガイド |
| ④切り戻し基準 | ①〜③のどれかが不合格だった場合に、どこまで戻すか | 戻す条件と戻し先モデルを事前に決めてある | 社内のチェックリスト運用ルール |
4つに分けるのは、どれか1つでは判定材料にならないからです。出力が良くても費用の見通しが立たなければ広げられませんし、費用が安くても既存のコードが動かなければ意味がありません（出典: Anthropic公式移行ガイド・公式モデル一覧・公式料金ページ、いずれも2026-07-29確認）。
大森部長投資の判断としては、結局どこで可否が決まるのでしょうか。
鈴木さん出た結果を、あらかじめ決めた3つのどれかに落とします。落とし先を先に決めておくと、その場で言葉を探さずに済みます。
大森部長保留と見送りは、どう違いますか。
鈴木さん残る宿題が違います。保留は原因を追う作業が残り、見送りは次の機会まで待つ判断です。同じ扱いにすると、追うはずの原因がそのまま消えます。
- 出力比較・コスト影響・プロンプト互換性のすべてが合格：本番導入へ進む
- いずれか1つが不合格：原因を特定できるまで保留し、再検証する
- 複数が不合格：今回の切り替えは見送り、次の公式アップデートを待つ
10切り戻しと承認の記録は、AI導入のどこに残しておくんですか？
不合格から保留や見送りへ進んだときは、切り戻し先のモデルIDと、いつ再検証するかを決めておきます。決めずに止めると、次に触るときも同じ確認を最初からやり直すことになります。
判定の記録には、誰が・いつ・どの観点で不合格と判断したかを残します。承認の記録が無いまま止まっていると、次の担当者には「止まっている」ことしか見えません。理由が見えないので、同じ確認をもう一度走らせます。
手順にすると、書き残す量はそれほど多くありません。多くないのに抜けるのは、止めた瞬間はまだ覚えているからです。覚えているうちは書く必要を感じないので、そのまま次の仕事へ移ります。
記録先や、誰が止めるのかという設計は、AIエージェントの承認ゲート｜止める操作4種と3層の選び方が扱う人間ゲートの考え方と同じです。判定を出す場所と、その判定を残す場所を、別々に用意しておきます。
この章のまとめ
切り戻しは、事故が起きてから考える手順ではありません。保留と決めたその日に、戻し先と再検証の時期をセットで書いておく作業です。
11チェックリストどおりに進めても、AIエージェントの運用で見落とすのはどこですか？
並びどおりに進めても、次の点は残ります。どれも、プロンプトそのものを見ていては気づけない場所にあります。
- thinkingパラメータを省略したときの既定動作の違い：Claude Opus 5は省略すると自動的に思考ありで実行されますが、これは旧世代（Opus 4.8以前）と逆の挙動です（出典: Anthropic公式移行ガイド）。max_tokensを旧モデルの設定のまま使うと、思考分を含めた出力が途中で切れます
- 新しいモデルのレート制限が別枠になっている点：新しいモデル向けの利用上限は、旧モデル群と共有されないことがあります（出典: Anthropic公式レート制限ドキュメント、2026-07-29確認）。旧モデルの実績だけを見て、上限に余裕があると判断しないようにします
- プロンプトが前提にしていた癖が変わる点：指示語の強さへの反応や、口調・冗長さの既定値は世代ごとに変わります。そのまま使い回すと、狙った挙動から少しずれます
- 公式の廃止スケジュールを見ていない点：Anthropicは旧モデルの提供終了日を「Model deprecations」ページで公開しています。Claude Sonnet 3.7は2026年2月19日に提供終了となり、公式の置き換え先はClaude Sonnet 4.6です（出典: Anthropic公式Model deprecationsページ、2026-07-29確認）。廃止日を過ぎると、そのモデルIDへのリクエストは失敗します
- 検証時点を記録していない点：挙動は今後の更新で変わり得ます。いつの時点の確認かが書いていないと、後から見た人が古い判定を最新のものとして読みます
積んで見ると、見落としの多くが下の層にあると分かります。上の層は書き替えれば直せますが、下の層は担当範囲の外にあることが多く、そもそも見にいく習慣がありません。
12新モデル導入のチェックリストは、AIエージェントの担当者がいつ回すんですか？
大森部長この確認は毎回やるものですか。それとも一度作れば済むものでしょうか。
鈴木さん一度作って終わりにはなりません。ただ、毎回ゼロから作るわけでもありません。並びは使い回して、中身だけ入れ替える形にしています。
大森部長回す合図は何になりますか。
鈴木さん新しいモデルが出たときと、いま使っているモデルの廃止が予告されたときです。あとは、任せている業務そのものが変わったときも入ります。
時間軸の右端には、切り替えたあとの再確認があります。切り替えた日で終わらせないのは、廃止の予告と業務の変更という2つの合図が、あとから来るからです。
回す間隔を日数で決めていないのは、発表の間隔をこちらで決められないからです。日数ではなく、合図が来たら回すという置き方にしておくと、間隔が空いても抜けません。
13よくある質問
新モデル導入は、発表からどのくらい期間を空けるべきですか
決まった日数はありません。この記事の4つの観点（出力比較・コスト影響・プロンプト互換性・切り戻し基準）をすべて確かめ終えた時点が、導入を検討してよいタイミングです。急ぐ業務であっても、公式移行ガイドの変更点一覧に目を通す時間は確保します。日数を先に決めてしまうと、確認が終わっていなくてもその日が来てしまいます。
新モデル導入のチェックリストは、モデルの種類を問わず使えますか
考え方の骨格（出力比較・コスト影響・プロンプト互換性・切り戻し基準）は、モデルを問わず使えます。ただし確認する項目の中身、たとえばパラメータ名やツールの表記などは、使うモデルの公式ドキュメントに合わせて読み替えてください。同じ「モデル」という言葉でも、提供元ごとに破壊的変更の出し方は異なります。
定額プランでもコスト影響は確認すべきですか
はい。定額プランでは請求額そのものは変わりませんが、切り替えでトークン数や単価が変わると、Usage limitへ到達する速さが変わります。この記事の重さの節で挙げた代理指標で確認します。請求書に出てこない変化なので、見ないと決めた場合はずっと見えないままになります。
モデル切り替えの途中で不具合が出たら、すぐ旧モデルへ戻すべきですか
影響範囲によります。一部の業務だけの不具合であれば、その業務だけ旧モデルへ切り戻し、他は新モデルのまま様子を見る運用が現実的です。戻し先と条件を事前に決めておくと、この判断で迷いません。全業務を巻き戻すかどうかは、不具合が本番出力の正確さに関わるかどうかで分けます。
新モデル導入の最終判定は誰が承認するべきですか
この記事はチェックリストの設計を扱っており、承認者を誰にするかは組織ごとに異なります。契約プランの変更や本番プロンプトの切り替えは、費用と業務への影響に直結します。送信や公開と同じように、承認の記録を残す運用にしておくほうが安全です。
14まとめ｜今日やる3つのこと
判断の材料は、触った感触ではなく、確かめた記録から作りました。確かめる順番を守ると、手戻りが減りました。そして戻し先は、戻りたくなる前に決めておく必要がありました。
今日はこの順で手をつけます
ふだん流している定型業務のプロンプトを書き出して、1か所に集める
比較の入口がここにしかないためです
公式移行ガイドの変更点一覧を開いて、自分のコードに関係する行へ印をつける
読む前に切り替えると、気づく位置が本番まで後ろへ動きます
戻し先のモデルIDと、再検証する合図を、いま書いておく
保留と決めた日に書こうとすると、たいてい書きません
着手する前に、この並びで確認しておくと抜けが減ります。
- 定型業務のプロンプトを新旧モデルへ同条件で実行し、出力の形式と内容を突き合わせた
- tool_useの入力はパースして比較し、生の文字列一致に頼らなかった
- 定額プランの場合、Usage limitへの到達速度が変わっていないか確認した
- 従量課金の場合、公式料金ページでモデル別の単価を確認した
- count_tokensで同じ入力のトークン数を新旧モデルで比較した
- 拡張思考・サンプリングパラメータ・ツール定義の変更を公式移行ガイドで確認した
- stop_reasonの分岐にrefusal等の新しい停止理由を追加した
- 不合格だった場合の切り戻し先モデルと再検証の時期を事前に決めた
- 1件のリクエストで新モデルへの切り替えを試し、想定どおり動くことを確認してから展開した
AI検索では、こう聞かれています
新しいモデルは、発表されたらすぐ切り替えていいんですか？
「新モデルを発表当日に切り替えると、AI導入の現場では何が起きるんですか？」の章で、気づく位置がどう動くかを説明しています
新モデルを入れる前に、何をどの順番で確かめればいいんですか？
「新モデル導入のチェックリストの最終判定は、AI社員の運用としてどう出すんですか？」の章に、4観点と確認の並びがあります
定額プランだと、モデル切り替えの影響は何で見るんですか？
「新モデルへ切り替えると、AI活用にかかる重さの見え方はどう変わるんですか？」の章で代理指標を挙げています
既存のプロンプトは、モデルを替えるとどこが動かなくなるんですか？
「新モデルの導入で既存プロンプトは、生成AIの世代が変わるとどこから壊れるんですか？」の章で扱っています
次に読むなら、この記事です
