エージェントの記憶を失わずに GLM-5.3 へ移行する方法 (2026年)

まず、GLM-5.3 とは何かを理解することから始めましょう。それが答えを形作るからです。Z.ai は「GLM-5.3 で行ったのは、事後学習（post-training）のスケーリングだけです」と述べています。これは GLM-5.2 と同じベースモデルを使用しており、すべての向上は事後学習によるものであることを意味します。報告されている性能向上は具体的かつ本物です。Terminal-Bench 3.0 は 4.6 から 28.3 へ、DeepSWE v1.1 は 46.2 から 66.9 へ、Agents' Last Exam (CLI) は 23.8 から 28.5 へと向上し、Z.ai は「社内の Z.ai Code Bench において GLM-5.2 比で 50% の向上」を主張しています。この最後の数字について、2点補足しておきます。Z.ai Code Bench は Z.ai 独自の非公開ベンチマークであり、同社は「公開テストセットからの汚染リスクを軽減する」ためと説明しています。また、同じセクションには「GLM-5.3 は、Max effort で 39.5% に達する Claude Fable 5 には依然として及ばない」とも記載されています。重み（ウェイト）もまだ公開されていません。「安全性評価と堅牢化が完了した後、ローンチから2週間以内に重みをリリースします。」

しかし、これらはエージェントが知っていることには影響しません。モデルの入れ替えは、推論を行う主体を変更するだけであり、推論が読み込む基盤には触れません。Z.ai 自身の開発者ドキュメントのメモリに関するページでも、多くのベンダーのドキュメントよりも分かりやすくその仕組みが説明されています。「メモリにより、コーディングエージェントはタスクやセッションをまたいでコンテキストを保持できるため、繰り返しの入力を減らし、実行効率を向上させることができます。」そして、主要な例として挙げられているツールについては、「各セッションは新しいコンテキストウィンドウから始まります。セッション間で知識が引き継がれるのは、主に永続的な指示ファイルを通じてです」とあります。

したがって、引き継がれるものとそうでないものは明確に分かれます。

自動的に移行するもの（リポジトリやホームディレクトリにあるため）： 指示ファイル（CLAUDE.md、AGENTS.md、.cursor/rules など、ツールが読み込むものすべて）。パススコープのルール。スキル。MCP サーバー設定（これはサーバーを指す設定ファイルであり、モデルの機能ではありません）。Git の履歴、テストスイート、ビルドコマンド。エージェントのプロジェクトに関する知識が、差分（diff）に現れる場所に書き残されているのであれば、モデルの入れ替えはエージェントにとって不可視（影響なし）です。

移行せず、警告も出ないもの： 前のモデルが実行中のセッション内で蓄積したすべてのもの（構築した計画、除外した行き止まりのルート、1時間前に与えた修正など）。これらは「コンテキスト」であり、次にどのモデルを使用するかに関わらず、コンテキストはセッションの終了とともに消失します。ツールがローカルのツール固有のメモリ（記憶）ストアに書き込んだ内容も、そのままその場所に残ります。ディスク上には存在し続けますが、それは別のセットアップによって、またそのセットアップのために書き込まれたものであり、モデルと同時にツールも移行した場合は、まったく読み込まれなくなります。

その中間にある厄介なもの： 自動生成されたメモリファイルは、その中間に位置します。これらはファイルであるため残りますが、別のモデルとのセッションを圧縮して書き出されたものであるため、その有用性は、そのメモが永続的な事実（「API テストにはローカルの Redis インスタンスが必要」など）であるか、あるいは特定のモデルの挙動に対するリアクション（「ファイル全体を再フォーマットしないように注意する」など）であるかによって異なります。前者は残す価値がありますが、後者は、そのような癖をそもそも持っていない新しいモデルに持ち込もうとしているノイズにすぎません。

以下の順番で2つのステップを実行します。最初のステップは必須です。スキップすると、リクエストが完全に失敗します。

ステップ 1: モデル ID を変更する前に思考（thinking）設定を修正する

GLM-5.3 ではリクエスト形式のデフォルトが変更され、Z.ai はこれを破壊的変更として警告しています。発表より：「GLM-5.3 は、low、high、max の3つの思考エフォートレベルをサポートしています。GLM-5.3 では、思考の無効化（disabling thinking）はサポートされなくなりました。」ドキュメントの移行ノートには、以下のように明記されています。「移行が必要です：アプリケーションで現在 thinking.type: "disabled" を使用している場合は、モデル ID を glm-5.3 に更新する前に、これを enabled に変更し、reasoning_effort を low に設定してください。そうしないと、リクエストは失敗します。」

まず設定を変更し、その後にモデル ID を変更してください。順序を逆にすると、システム障害のように見えるリクエストエラーが発生します。また、デフォルトの reasoning_effort は max であり、Z.ai はコーディングにおいてこれを推奨していますが、これまで思考をオフにして実行していたパイプラインにそのまま適用できるものではありません。独自のコードではなく既存のツールにこれを組み込む場合、Z.ai のドキュメントによると「GLM Coding Plan は Anthropic と OpenAI の両方のプロトコルをサポート」しており、プロトコルごとに異なるベース URL が用意されています（Anthropic Messages エンドポイントは https://api.z.ai/api/anthropic です）。そのため、ツール側の変更は通常、ベース URL とキーの追加のみです。Team Plan ユーザーは、「Team Plan Key は他の Z.AI の API キーと互換性がありません」というドキュメントに記載された制限に注意してください。

ステップ 2: ファイルの外部に存在していた情報の棚卸しを行う

これは多くの人がスキップしがちですが、1週間後に大きな代償を払うことになるステップです。切り替える前に、リポジトリに向き合い、4つの質問に対する答えを書き出してください。頭の中ではなく、ファイルに書き出すのです。

エージェントが知っていた、どこにも書かれていない情報は何か？ コミットする代わりにチャットで修正したすべてのルール。セッションの途中で伝えた「うちではそういうやり方はしない」というすべての指摘。唯一の記録が、間もなく終了するセッションだけであるなら、それは失われます。

何を採用しないと決め、それはなぜか？ 却下されたアプローチは、あらゆるプロジェクトにおいて最も価値が高く、最も失われやすい知識です。新しいモデルは、あなたがすでにキューベースのバージョンを試して断念したことを知らないため、再び熱心にそれを提案してきます。却下した事実とその理由を書き留めてください。その理由こそが、同じ無駄なループを止めるものだからです。

どの指示がプロジェクトではなく、古いモデル向けのものだったか？ これらは今すぐ整理してください。特定のモデルの癖を回避するためだけに存在する指示は、良くてもお荷物であり、最悪の場合は新しいモデルを誤った方向へ導きます。新しいモデルに対して、存在しない問題への対策を強いることになるからです。Z.ai のメモリに関するページには、関連する警告が記載されています。エージェントは「それらを読み、従おうとしますが、ルールが曖昧、不明確、または矛盾している場合、厳格な準拠は保証されません。」古い回避策が山積みになっている状態こそが、指示が矛盾する原因そのものです。

複数のマシンに分散しているものは何か？ ノート PC とデスクトップの両方で作業している場合、ツールが生成したメモリがマシンローカルであるかどうかを確認してください。ほとんどの場合、ローカルに保存されています。モデルの入れ替えは、エージェントが蓄積した知識の半分が片方のコンピュータにしか存在しないことに気づく絶好の機会です。これは、Claude Code がマシン間で記憶を忘れてしまう理由で解説しているのと同じ問題であり、自然に解決することはありません。

この棚卸しリストがリポジトリ内のファイルとして存在していれば、モデルの入れ替えは純粋に設定変更だけで済みます。これを行わないと、数ヶ月間ツールにアウトソーシングしていた記憶を、自分の記憶力に頼って思い出す羽目になります。

上記の棚卸しは効果的であり、一度は行うべきです。しかし、モデルを切り替えるたびにそれを行うべきではありません。GLM-5.3 のリリース頻度を見る限り、今や「切り替えるたび」とは「数週間ごと」を意味します。代替案は、エージェントの知識を実行中のモデルの属性として扱うのをやめ、どのモデルからでも読み取れる独自の「家」を与えることです。

それこそが MemoryLake の役割です。ツールが接続するメモリ（記憶）レイヤーであり、プロジェクトに関する知識を1箇所に集約し、その背後にあるモデルをいつでも交換可能なパーツにします。今日 GLM-5.3 に切り替え、来月また別のモデルに戻したとしても、メモリは移動しません。なぜなら、メモリは最初からモデルの内部にはなかったからです。セットアップは3つのステップで完了します。

ステップ 1: API キーを作成する

MemoryLake にサインインし、API キーを作成します。これはツールがメモリを読み書きするために使用する認証情報であり、特定のエディタに依存しない唯一のセットアップ要素です。現在のツール選択よりも長生きするレイヤーを構築することが目的であるため、これは重要なポイントです。

ステップ 2: 最初のメモリをアップロードする

先ほど作成した棚卸しリストに加えて、プロジェクトを実際に説明するドキュメント（アーキテクチャのメモ、決定ログ、オンボーディング資料、これまで誰も書き留めてこなかった設計上の制約など）をアップロードします。こここそが「なぜそれを却下したのか」を記録する場所です。なぜなら、それらは新しいモデルが最も必要とし、かつ最も推測しにくい情報だからです。内容は短く、事実のみを記載してください。メモリレイヤーの価値は、長さではなく、検索性の高さによって決まります。

ステップ 3: AI とエージェントを接続する

実際に使用しているツールを接続します。MemoryLake は MCP および API 経由でメモリを提供するため、Claude Code、Codex、OpenClaw などのネイティブ MCP サポートを持つエージェントは、MCP サーバーを指定するだけで接続できます。それ以外のツールも、API を通じて同じメモリを読み取ることができます。これらのツールのいずれかで GLM-5.3 を実行している場合、この接続によってモデルの入れ替えは非常にシンプルなものになります。エージェントは、読み込みを行うモデルが変更されただけで、昨日と同じメモリを読み込み続けます。MCP 側の手順については、MCP を使用してクロス AI メモリを設定する方法を参照してください。

1つだけ明確な制限があります。MemoryLake は、あなたやエージェントが保存した内容のみを記憶します。前のモデルの終了したセッションに遡ってそこで話された内容を復元することはできませんし、開発ルールを書き留めることの代わりにはなりません。これは「再説明の手間」を省くものであり、「意思決定」そのものを代行するものではありません。

実用上の違いは、1回目ではなく、3回目や4回目のモデル変更時に現れます。

モデルの選択が「後戻り可能」になります。 現在、多くのチームはモデルの切り替えを「重大な決断」として扱っています。なぜなら、元に戻すにはコンテキストを再度構築し直す必要があるからです。コンテキストがモデルの外部にあれば、あるリポジトリで GLM-5.3 を1週間試用し、以前使用していたモデルと比較して、どちらの方向にもコストを支払うことなく元に戻すことができます。GLM-5.3 の重みがローンチ時点でまだ2週間先であることを考えると、選択肢を残しておくことには明らかな価値があります。

ベンチマークが意思決定のすべてではなくなります。 Terminal-Bench の数値は、モデルの実力をリアルに示してくれます。しかし、そのモデルが「あなたの課金モジュールがシステムの根幹を支えていること」を知っているかどうかについては、何も教えてくれません。この2つを切り離して考えるチームは、プロジェクト知識の損失を心配することなく、モデル自体の純粋なメリットに基づいて評価できるため、より優れたモデル選定が可能になります。

トークン消費量がシンプルな理由で減少します。 Z.ai 自身は GLM-5.3 の効率性について、「あらゆるエフォートレベルにおいて、GLM-5.2 よりも大幅に強力なエージェント型コーディング結果を提供しつつ、出力トークンの消費を抑える」と表現しています。取得されたメモリも、もう一方の端から同じ方向へと後押しします。開発ルールを検索できるエージェントは、すべてのプロンプトにそれらを貼り付ける必要がありません。もしアシスタントにコンテキストを何度も再説明しているのであれば、その習慣には測定可能なコストがかかっています。

次々と押し寄せるモデルのアップデートに振り回されなくなります。 今四半期だけで、注目すべきコーディングモデルのリリースはこれで4、5回目です。新しいリリースを「移行作業」ではなく「純粋なアップグレード」として体験できるチームは、知識レイヤーをベンダーのセッションストアに依存させるのをやめたチームだけです。

一度に変更する変数は1つだけにします。 モデルを切り替えるか、ツールを切り替えるかのどちらかにし、同じ日の午後に両方を行うのは避けてください。パフォーマンスが低下した際、どちらの変更が原因であるかを特定できるようにするためです。

切り替え後に指示ファイルを再確認します。 特定のモデル向けの回避策は、気づかないうちに蓄積されていきます。新しいモデルへの移行は、これらを削除する絶好の機会です。不要な回避策を削除することで、残されたルールへの準拠率が目に見えて向上します。

思い込みを排除し、読み込まれた内容を検証します。 どのようなツールを使用していても、通常はセッションに読み込まれた指示ファイルやメモリファイルの一覧を表示する方法があります。切り替え後に一度確認してください。ルールファイルが静かに読み込みに失敗している状態は、モデルが指示に従わなくなった状態とまったく同じように見えます。

永続的な事実とセッション内でのリアクションを区別します。 「npm ではなく常に pnpm を使用する」は永続的な事実です。「ファイル全体を書き換えるのをやめる」は、特定のモデルの挙動に対するリアクションです。これらを同じ場所に整理してしまうと、指示ファイルが形骸化する原因になります。

思考エフォートレベルを意図的に設定します。 GLM-5.3 のデフォルトは max であり、Z.ai はコーディングにおいて max を推奨しています。ワークロードが主に短い検索である場合、low が存在するのには理由があります。また、thinking: disabled のセットアップから移行した場合は、ドキュメントに記載されている通り low が同等の開始点となります。

却下されたアプローチを第一級の項目として書き留めます。 あなたがすでに除外したアプローチは、それが読み取り可能な場所に書き残されていない限り、今後使用するすべてのモデルが再び提案してきます。この1つの習慣は、どのような設定チューニングよりも多くの時間を節約します。

GLM-5.3 は、あなたのセットアップがポータブル（移植可能）であるかどうかを測る、非常に分かりやすいテストになります。ツール側を変更する必要は一切ないため、答えは明白です。モデルを切り替えてもエージェントのプロジェクトに関する知識が維持されるなら、それは永続的な場所に書き残されていたということです。もし維持されないなら、それは単にセッションの中に一時的に存在していただけにすぎません。

モデル ID を変更する前に思考設定を修正し、一度棚卸しを行い、その結果を現在のベンチマークで首位に立っているモデルに依存しない場所に保管してください。そうすれば、近いうちにやってくる次のリリースは、1週間かけて再説明する手間ではなく、設定ファイルの1行を変更するだけで済むようになります。複数のモデル移行を同時に検討している場合は、コンテキストを失わずに AI モデルを切り替える方法で一般的なパターンを解説しています。また、Kimi K3 や GPT-5.6 に特化した移行ガイドも用意しています。