AIモデル・推論レベルを途中変更するときの注意点

AIエージェント運用2026.09.13

CodexやClaude Code、Google Antigravityで長い仕事をしていると、「計画は高性能モデルに任せ、実行は軽いモデルへ変えたい」「最後の確認だけ推論レベルを上げたい」と思うことがあります。画面上でモデルや推論レベルを選び直せるなら、工程に合わせて細かく切り替えた方が効率的に見えます。

しかし、長いチャットの途中でモデルを変えると、 新しいモデルがこれまでの経緯を読み直し、切り替え前とは異なる判断をする可能性があります。 モデル変更によってPrompt Cacheが外れることもあり、長い会話では要約によって細かな前提が落ちている場合もあります。

ここで、モデル変更と推論レベル変更を分けて考える必要があります。 同じ成果物を作り続ける間はモデルを維持し、別のモデルを使うなら必要な情報を渡した別タスクに分けます。 同じモデルの推論レベルを変える場合は、残りの工程が長いときだけ一度変更し、その設定を維持するのが基本です。

この記事では、チャット履歴、コンテキスト、Prompt Cacheの違いを整理し、Codex、Claude Code、Google Antigravityで確認できる情報を紹介します。そのうえで、 同じチャットを続ける場面と、別タスクへ分ける場面 を具体的に説明します。

この記事のまとめ

チャット履歴が画面に残っていても、新しいモデルが切り替え前と同じ状態で仕事を続けられるとは限りません。
Prompt Cacheが外れたときに主に増えるのは、入力の再処理、利用量、応答までの時間です。
Claude Codeでは、モデル変更後の最初のリクエストで会話履歴全体をキャッシュなしで読み直すと公式に説明されています。
Google Antigravityでもキャッシュ利用は確認できますが、モデル変更時の詳しい処理は公式情報だけでは判断できません。
同じ成果物を作る間はモデルを維持し、別のモデルを使う場合は必要な情報を渡した別タスクに分けます。
推論レベルは、残りの工程が短ければ維持し、長い後工程へ移るときだけ一度変更します。

1. チャット履歴・コンテキスト・キャッシュは、それぞれ役割が違う

モデル変更の影響を理解するには、画面に残るチャット履歴、AIへ渡されるコンテキスト、入力処理を再利用するキャッシュを分けて考えます。 この三つを同じものとして扱うと、「履歴があるのになぜ忘れるのか」「同じ会話なのになぜ利用量が増えたのか」が分かりにくくなります。

用語	何を指すか	モデル変更時に起こり得ること
チャット履歴	画面やログに残っている過去の会話	画面に表示される内容と、モデルへ渡される内容が一致するとは限りません
コンテキスト	AIが現在の回答に使う会話、ファイル、指示、ツール結果	別モデル向けに組み直されたり、長すぎる部分が要約されたりします
Prompt Cache	前回までと共通する入力の処理結果	モデルや設定が変わると再利用できず、入力を処理し直す場合があります

チャット履歴が残ることと、同じ状態で続けられることは違う

AIモデルは、アプリから渡された会話、作業指示、確認済みのファイル、コマンド結果などを使って回答します。このまとまりがコンテキストです。

同じチャットでモデルを変更した場合、多くのアプリは過去の履歴を新しいモデルへ渡します。ただし、モデルごとにシステム指示、得意な作業、使えるコンテキスト量、情報の重視の仕方が違います。 同じ履歴を受け取っても、切り替え前のモデルが立てた計画や判断基準を、新しいモデルが同じ重みで理解するとは限りません。

長い会話では、履歴をすべて渡さず、要点をまとめた文章へ置き換えることもあります。主要な決定が残っていても、最初に伝えた細かな条件や、採用しなかった案の理由が要約から落ちれば、切り替え後の判断が変わります。

キャッシュミスは、主に利用量と応答時間へ影響する

Prompt Cacheは、長い入力のうち、前回までと同じ部分の処理を再利用する仕組みです。会話が続くたびに履歴全体を最初から通常処理すると負担が大きいため、変わっていない先頭部分をキャッシュから読み、新しく追加された部分を処理します。

モデルごとにキャッシュを分ける仕組みでは、切り替え先のモデル用キャッシュがないため、変更直後に長い入力を読み直す場合があります。 キャッシュミスによって直接増えやすいのは、入力トークンの処理量、利用枠の消費、回答が始まるまでの時間です。

キャッシュミスが、その後も続くとは限りません。Codexの公開Issueでは、 推論レベル変更後の1回目でキャッシュヒット率が下がり、同じ推論レベルで続けた2回目には回復した例 が報告されています。ただし、回復の仕方はモデルや製品によって異なります。

また、キャッシュが外れたことだけで回答の質が下がるわけではありません。Codexのローカルアプリでモデル変更時に表示される性能低下の警告について、原因の詳しい内訳は公式に説明されていません。OpenAIは、モデルを変更するとモデル固有の指示を含むPromptの先頭部分が変わり、キャッシュミスの原因になると説明しています。 キャッシュミスは利用量や待ち時間、モデル変更は作業の連続性にも関わる問題として分けて考えます。

2. 長いチャットでモデルを変えると、作業の連続性にも差が出る

長いタスクの途中でモデルを変更したときに注意したいのは、利用量よりも、これまで積み上げた判断を保てるかです。 企画や設計では、完成物だけでなく、「なぜこの方針にしたか」「どの案を除外したか」という経緯も後の作業へ影響します。

新しいモデルは、過去の判断を履歴から読み直す

たとえば、高性能モデルを使って記事の対象読者、独自の切り口、扱わない論点を決めたとします。その後、本文作成だけ別モデルへ変更すると、新しいモデルは構成や会話履歴から方針を読み取ります。

構成に判断理由まで十分に残っていれば、作業を続けやすくなります。反対に、「この見出しで進める」「この例は使わない」といった結論だけが残っている場合、新しいモデルは背景を推測しながら書くことになります。 引き継ぐべき判断を明文化しておくほど、モデル変更後の認識のずれを抑えやすくなります。

開発でも同じです。原因調査を行ったモデルが、試した方法、除外した原因、変更してはいけない範囲を会話の中だけに持っていると、切り替え後のモデルが同じ調査を繰り返したり、以前に却下した方法へ戻ったりします。

長い会話では、要約で細かな情報が落ちることがある

コンテキストには上限があるため、長時間の作業では古い会話や大量のツール結果を整理する必要があります。Claude Codeは、コンテキストが上限へ近づくと会話を自動的に要約します。公式ドキュメントでは、システム指示やプロジェクトのルールは再読み込みされる一方、会話中に読み込んだ情報の一部は要約や再読込の対象になると説明されています。

Google Antigravityにもコンテキスト使用量の表示と、コンテキストを分けるサブエージェントがあります。Codexでも長時間の作業を続けるために会話の圧縮が使われます。 どのサービスでも、長いチャットをそのまま保存できることと、過去の細部を常に同じ精度で参照できることは別です。

モデルを変える前に、重要な決定を構成書、仕様書、作業メモへ残しておけば、会話の要約やモデル変更が起きても復元しやすくなります。

同じチャットでモデルを往復すると、判断基準も揺れやすい

たとえば、高性能モデルで記事の企画を決めたあと、本文の一部だけ軽いモデルに変更し、仕上げで元のモデルへ戻したとします。画面上の履歴は残っていても、モデルごとに文章の評価基準や重視する指示が異なるため、企画時に避けた表現が復活したり、修正の方向が変わったりする可能性があります。

キャッシュは切り替え先で作り直せますが、モデル間で判断を同じ状態にそろえることは別の問題です。同じ成果物を作るチャットではモデルを維持し、別モデルの判断が必要な場合は、目的、決定事項、対象ファイル、確認項目を渡した別タスクに分けます。

3. Codex・Claude Code・Google Antigravityで確認できる違い

モデルや推論レベルを変えたときの処理は、サービスによって異なります。 2026年9月時点で公式に説明されている範囲と、まだ確認できていない範囲を分けて見ていきます。

Codex：変更直後にキャッシュが外れても、次のリクエストでは回復した報告がある

OpenAIのPrompt Cacheは、前回までと一致するPromptの先頭部分の処理を再利用する仕組みです。OpenAIは、対象モデルを変更するとモデル固有の指示が変わるため、Codexでキャッシュミスが起こり得ると説明しています。OpenAIによるCodexの仕組みの解説

推論レベルについては、AstraのAPIに、会話の途中で推論レベルを変更してもキャッシュを維持する configuration_update が用意されています。OpenAIのモデルガイド一方、Codexの公開Issueには、推論レベルを変更した直後だけキャッシュヒット率が下がった報告があります。

公開Issueで報告された例（キャッシュヒット率）	変更前	変更後1回目	変更後2回目（同じ推論レベル）
GPT-5.6 Luna：MediumからLow	99.0%	65.3%	98.7%
GPT-5.6 Luna：MediumからXHigh	98.5%	65.0%	97.6%
Astra：Highへ変更	99.64%	12.05%	96.17%
Astra：Mediumへ変更	99.00%	0.00%	99.15%

GPT-5.6 Lunaの数値は推論レベル変更時の報告、Astraの数値はWindows版Codexのローカルログを調べた報告によるものです。いずれも個別の利用環境で計測された数値であり、Codex全体の固定値ではありません。バージョンやモデルによって結果が変わる可能性もあります。

表の数値は、入力全体に占めるキャッシュヒット率です。 GPT-5.6 Lunaの「65.3%」は、キャッシュの65.3%を失ったという意味ではありません。変更直後にキャッシュされなかった部分が約1%から約35%へ増えています。この例では、共通部分の9,984トークンはキャッシュされたまま、会話側で追加されていた5,120トークンが変更直後に再利用されませんでした。

二つの報告に共通するのは、 キャッシュヒット率の低下が続いたのではなく、変更直後のリクエストに集中し、同じ推論レベルで続けた次のリクエストでは96〜99%台へ戻ったこと です。GPT-5.6 Lunaの報告では、以前に使った推論レベルへ戻した際、大幅な低下が見られなかった例もあります。長いタスクで推論レベルを変更するなら、一回だけ切り替え、その後も同じ設定で作業する方がキャッシュを利用しやすくなります。

モデル変更では、キャッシュの作り直しに加えて、作業を担当するモデル自体が変わります。ローカルアプリの警告も踏まえ、 同じ成果物を作る途中ではモデルを維持し、別モデルを使う場合は別タスクに分ける のが安全です。

GPT-6 Astraの推論強度や料金、向いている仕事は、「GPT-6 Astraは何がすごい？できること・料金・推論強度を実例で解説」で詳しく紹介しています。

Claude Code：モデル変更と多くの推論レベル変更でキャッシュが外れる

Claude Codeは、モデル変更時の処理を公式ドキュメントで明確に説明しています。 モデルごとにキャッシュが分かれており、/modelで切り替えた次のリクエストは、同じ会話内容でも履歴全体をキャッシュなしで読み直します。

多くのモデルでは、推論レベルを途中で変更した場合も同じです。一部のモデルと利用方法ではキャッシュを維持できる例外がありますが、基本方針として、Claude Codeはモデルと推論レベルをセッションの最初に選ぶよう案内しています。Claude CodeのPrompt Caching解説

Claude Codeでは、キャッシュが温かい間にモデルを変更すると確認が表示されます。これは会話が消えるという警告ではなく、変更後1回目のリクエストで長い入力の再処理が起きることを知らせるものです。そのモデルを使い続ければ、新しいモデル向けのキャッシュを次のリクエストから利用できます。会話がコンテキスト上限へ近づくと自動圧縮も行われるため、長時間のタスクでは重要な判断をCLAUDE.mdや作業ファイルへ残しておくと引き継ぎやすくなります。

Google Antigravity：モデル変更機能はあるが、キャッシュの詳細は未確認

Google Antigravityでは、Gemini、Claude、GPT-OSSなどから推論モデルを選べます。選択したモデルは会話内で維持され、現在のAntigravity CLIには、 一回の依頼だけ別モデルへ送り、その後は元のモデルへ戻る /model 機能 も用意されています。Google Antigravityの変更履歴

Antigravity CLIの利用状況には、通常の入力とキャッシュから読み込んだ入力が分けて表示されます。このため、Antigravityでも長い会話の処理にキャッシュが使われていることは確認できます。

一方、モデル変更時にどの範囲のキャッシュが外れるかは、Antigravityの公式ドキュメントで詳しく説明されていません。Gemini APIで明示的に作るキャッシュは、利用するモデルを指定して作成します。さらに、GeminiからClaudeのように提供元が異なるモデルへ切り替える場合、それぞれのモデル内部のキャッシュを共有することは難しいと考えられます。

Googleの開発者フォーラムでは、モデル変更後も過去の会話を参照できたという報告と、履歴をうまく引き継げなかったという報告の両方があります。現時点では、 Antigravityがモデル変更を機能として提供していることと、長い会話を常に同じ品質で引き継げることを分けて考える 必要があります。

4. 同じ成果物ではモデルを維持し、推論レベルは長い工程の境目で変える

実務では、モデルと推論レベルで判断基準を分けます。 モデルは成果物やタスクの単位で選び、推論レベルは同じモデルでどれだけ綿密に考えさせるかに合わせて選びます。推論レベルごとに向く仕事は、「Reasoning effortとは？ChatGPT・Claude・Geminiの推論レベルで何が変わるか」で詳しく紹介しています。

変更したい場面	おすすめの進め方
同じ成果物の作業中にモデルを変えたい	現在のモデルを維持します
難しい判断だけ別モデルへ相談したい	必要な前提と判断したい点を渡した別タスクにします
推論レベルを変えたいが、あと一、二回で終わる	現在の推論レベルで完了させます
推論レベル変更後も長い工程が続く	一度だけ変更し、その推論レベルを維持します
現在の仕事と関係が薄い依頼へ移る	新しいチャットやタスクを開始します
長い会話で修正や失敗が積み重なった	決定事項を整理し、新しいタスクへ引き継ぎます

同じ成果物を作る間は、モデルを維持する

モデルを変えると、新しいモデルは会話履歴から目的や判断基準を読み直します。切り替え先の方が高性能でも、それまでの経緯を同じように解釈するとは限りません。文章のトーン、採用した方針、修正時の優先順位が変われば、性能の高さを成果物へ生かしにくくなります。

同じ記事、資料、プログラムを作り続ける間は、開始時に選んだモデルを維持します。 現在のモデルでは対応しにくいと分かった場合は、目的、決定事項、対象ファイル、完成条件を整理したうえで、新しいモデルを使う別タスクへ引き継ぎます。

推論レベルは、変更後に残る作業量で決める

Highで計画を作ったあと、誤字修正や短い追記だけが残っているなら、MediumやLowへ変更しても節約できる範囲は限られます。変更直後にはキャッシュヒット率が下がる可能性もあるため、 あと一、二回で終わるなら、現在の推論レベルで完了させます。

一方、企画や設計が終わり、その後に大量の本文作成、資料整理、実装が続く場合は、同じモデルの推論レベルを下げる選択肢があります。この場合は、工程ごとに往復せず、一度変更した推論レベルを後工程が終わるまで維持します。

難所と独立したレビューは、別タスクへ分ける

長いチャットの途中で、一回だけ最上位モデルへ変更して難しい判断をさせ、すぐ元のモデルへ戻すと、二つのモデルが同じ成果物を順番に担当することになります。難所だけ別モデルに任せたい場合は、 判断に必要な情報をまとめ、独立したタスクとして相談します。

たとえば記事のレビューなら、次の情報を渡します。

記事の目的：誰に何を伝え、読後にどうなってほしいか
決定事項：採用した切り口、扱わない論点、その理由
確認対象：完成稿、元資料、比較表など
確認項目：論理のつながり、事実関係、独自性、読みやすさなど

開発では、仕様、変更対象、現在分かっている原因、試した方法、満たすべきテストを渡します。 別タスクへ渡す情報を短く整理すれば、元の長い会話に別モデルを差し込まず、必要な判断やレビューだけを依頼できます。

まとめ

モデル変更と推論レベル変更では、守りたいものが異なります。 モデルを維持する目的は、同じモデルに判断や修正を積み重ねさせ、成果物の一貫性を保つことです。推論レベルを一定期間維持する目的は、切り替え直後のキャッシュミスを何度も発生させず、作業に必要な検討量を保つことです。

同じ成果物を作る間は、モデルを変更しない。

別のモデルを使うなら、必要な情報を渡した別タスクにする。

推論レベルは、長い作業単位の境目で一度だけ変更する。

推論レベルの変更後1回目にキャッシュが外れても、同じ設定で続けた2回目にはキャッシュヒット率が回復した報告があります。そのため、細かな金額を毎回計算するより、短い後工程では現在の設定を保ち、長い後工程へ移る場合だけ推論レベルを変更する方が実践しやすくなります。

一回の入力消費ではなく、完成までにかかった利用量、時間、修正回数、成果物の品質を見て、次のタスクで使うモデルと推論レベルを選びます。