セッション途中でモデルを差し替えたら、エージェントは何を覚えていて何を忘れるのか

こんにちは～　浮田です。

■ TL;DR

• AgentCore ハーネスの「セッション中にモデルを切り替えてもコンテキストを失わない」を、実際に叩いて確かめました
• Claude Sonnet 4.6 → Nova Pro → Claude と往復で途中交代させたところ、会話履歴・ツール実行履歴・ファイルの3点とも引き継がれました。
• ただし「コンテキスト」は一枚岩ではありません。セッションを停止→再開すると、会話は Memory が有効なら戻り、/tmp に書いたファイルは戻りませんでした。メモリ無効だと全部消えます（切り分け表あり）
• ハマったのは、コンソールのクイック作成だとメモリが無効で作られること。画面に履歴が見えているのにモデルが何も覚えていない、という状態にしばらく混乱しました
• 結論：セッション中の会話とファイルは microVM が持っていて、モデルはどちらも持っていない。だから交代できる。microVM が終わったあとも会話を残すのが Memory の役目、という話です

■  目次

1. はじめに
2. AgentCore ハーネスのモデル切り替えとは
3. 切り替える手段は3つある
4. 検証の設計（何を「コンテキスト」と呼ぶか）
5. 実際に切り替えてみた
6. さて本題、というか本日のオチ　
7. トークン数で見るコストの感触
8. 詰まったところ
9. まとめ・次にやりたいこと
10. 参考リンク・但し書き

■ はじめに

AgentCore ハーネスの GA のリリースノートを眺めていて、一行だけ気になった箇所がありました。

Agents can switch providers mid-session without losing context, so you can plan with one model and execute with another.

計画は賢いモデルに、実行は安いモデルに。

価格性能の比較のためにプロバイダーを入れ替えることもできる、と。

便利そうなんですが、素直に疑問が湧きました。

切り替えた瞬間、相手は「別人」になるはずです。じゃあ何を引き継いでいるんだろう？　会話？　ツールで取ってきた結果？　作業中に書いたファイル？

 結論から言うと、ちゃんと引き継がれました。ただし「何が」引き継がれているかは想像と少し違って、そこが面白かったので記録を残します。  

■ AgentCore ハーネスのモデル切り替えとは

ハーネスをおさらいすると、「エージェントのループ（モデル呼び出し→ツール選択→実行→結果を戻す）と、その周りのインフラ一式を AWS が持ってくれるサービス」です。

開発者はモデル・指示・ツール・スキルを設定として宣言するだけ。2026年6月に GA しました。

モデルは Bedrock に縛られません。

（※ 設定キー名は執筆時点の API リファレンスで要確認）

たとえ話をするなら、ホテルの部屋はそのままで、担当のコンシェルジュだけ交代するイメージです。部屋に置いた荷物（ファイル）も、部屋に置いてある業務日誌（会話履歴）も残る。交代したコンシェルジュは日誌を読んでから対応する。

ただしチェックアウト（セッション停止）すると部屋は片付けられます。日誌の控えをフロント（Memory）に預けていれば、次の部屋でも続きから読める。この記事の結論はこのたとえに全部収まるので、覚えておいてください。

■ 切り替える手段は3つある

ここは事前整理として価値が高いところです。公式ドキュメントの言い方を借りると「defaults at creation time, overrides at invocation time」。作成時のデフォルトと、呼び出し時の上書きが別レイヤーになっています。

③の最小コードは公式ドキュメントのこれです。

response = client.invoke_harness(
harnessArn=HARNESS_ARN,
runtimeSessionId=SESSION_ID,
# このコールだけに効く。ハーネスのデフォルトは変わらない
model={"bedrockModelConfig": {"modelId": "us.anthropic.claude-opus-4-5-20251101-v1:0"}},
messages=[{"role": "user", "content": [{"text": "..."}]}],
)

今回の検証は②で行いました。③は未検証ですが、セッション ID を揃えてモデルだけ変える、という構造は②と同じなので、同じ結果になるはずです（第3弾で確かめます）。

■ 検証の設計（何を「コンテキスト」と呼ぶか）

ここが記事の背骨です。「コンテキストを失わない」と一口に言っても、失われうるものは複数あるはずなので、先に分解しておきます。

4番目が地味に重要でした。チャット画面に履歴が表示されていても、それがモデルに渡っているとは限りません。入力トークン数だけが真実です。

環境は次のとおりです。

• 日付：2026年9月2日
• 作成方法：コンソールの「ハーネスをクイック作成」（harness_a6o97 ）
• モデル：Claude Sonnet 4.6（global.anthropic.claude-sonnet-4-6）→ Nova Pro（オンデマンド）
• ツール：設定上は 0 個。ただし microVM 標準装備の Shell と File Operations は使える
• メモリ：前半は無効（クイック作成のデフォルト）、後半で有効化

■ 実際に切り替えてみた

● 仕込み（Claude Sonnet 4.6）

新しいセッションを開いて、まず挨拶。入力 925 トークン。「こんにちは」1行で 925 トークンも載っているのは、システムプロンプトとツール定義とハーネス内部の指示が乗っているからです。初回は microVM の起動も含みます。

次に名前と数字を伝えました。

私の名前は浮田です。好きな数字は 57 です。このあとモデルを切り替える実験をするので、覚えておいてください。

続けてファイルを書かせます。

/tmp/memo.txt に「harness test 20260820」と書き込んで、書けたか確認してください。

Agent trace を開くと、Shell(command: "echo ... > /tmp/memo.txt") で書き込み、「書き込めました。続いて確認します」と言ってから File Operations(command: "view") で読み出す、という2手でした。Shell の結果は stdout / stderr / exit_code の3点セットで返っていて、モデルはこの生データを見て次を決めています。

ちなみに同じ指示を別の回に出したら、echo と cat を && で繋いで Shell 1回で済ませたり、cat を Shell で叩いたりと、毎回組み立てが違いました。どのツールをどう使うかは、実行のたびにモデルが決め直しています。

この時点で
入力: 3292

出力: 167

合計: 3459

レイテンシー: 5205ms　でした。

● 切り替え（→ Nova Pro）

右ペインのモデル欄の ✎ を押すと、プロバイダー → モデル → 推論タイプの3列モーダルが出ます。Amazon → Nova Pro → オンデマンドを選んで「適用」。待ち時間なし、再デプロイなし、セッション ID もそのまま。

同じセッションのまま質問します。

私の名前と好きな数字は何でしたか？　また /tmp/memo.txt の中身を読んで教えてください。

① 会話履歴は覚えているか → ✅

　お名前：浮田さん／好きな数字：57

即答でした。

② 前のモデルが叩いたツールの結果は残っているか → ✅（ただし一工夫必要でした）

実はこれ、名前とファイルの質問だけでは確認できません。

名前を答えたのは会話履歴（軸①）、ファイルを読めたのは microVM（軸③）で説明がついてしまい、「ツールの実行結果を知っていた」証拠が別に要ります。質問を投げてから設計ミスに気づきました。

そこで実験を組み直しました。Nova に date +%s%N を実行させます。出力はその瞬間のナノ秒タイムスタンプ会話にもファイルにも存在せず、再実行すれば必ず別の値になる、ツールの実行結果にしか存在しない情報です。

Shell(command: "date +%s%N") → 1788347984056472402

そして Claude Sonnet 4.6 に切り替え戻して、聞きます。

さっき実行した date コマンドの出力は何でしたか？ツールは使わず、会話の記憶だけで答えてください。

Claude の回答は、ツールを一切呼ばずに：

先ほどの date +%s%N の出力は：1788347984056472402 でした！

一字一句正確でした。前のモデルのツール実行結果が、会話履歴の一部として次のモデルにそのまま渡っています。

ついでに Nova → Claude という逆方向の切り替えも、これで確認できたことになります。

③ 前のモデルが書いたファイルは読めるか → ✅

File Operations(command: "view") → harness test 20260820。

同じ microVM にいるので当然といえば当然ですが、ここは正直びっくりしました。モデルが変わっても作業机は同じです。

ちなみに Nova Pro は <thinking>〜</thinking> を生テキストのまま出力してきました。Claude は出していなかったので、ハーネスが揃えてくれるのは「セッション」であって「モデルの作法」ではないんですね。

■ さて本題、というか本日のオチ

ここからが、この記事のいちばん書きたかった部分です。

「全部引き継がれました」で終わると、じゃあ何をしたら失われるのか分かりません。

そこで モデルを変えずにセッションを変える 対照実験をしました。

● 対照実験1：新しいセッション（メモリ無効）

「新しいセッション」ボタンから、前のセッションを停止して新規作成。

同じ Nova Pro のまま同じ質問。

お探しのファイル /tmp/memo.txt は存在しないため、あなたの名前と好きな数字を特定できませんでした。

全部忘れて、逆に聞き返されました。入力 906 トークン。直前のターンの 8,125 と比べると9分の1で、履歴が何も渡っていないことが数字で分かります。

● 対照実験2：停止したセッションを再アクティブ化（メモリ無効）

「前のセッションは停止していますが、再度呼び出せば再びアクティブ化できます」と案内が出たので、旧 ID 52a6ec3a-… を貼り直して同じ質問。

チャット画面には過去の会話が全部表示されています。
数分前に Claude が乱数を言い当てた回答も、すぐ上に見えている。
その状態で、

申し訳ありませんが、ユーザーの要求を満たすために必要な情報を得ることができませんでした。/tmp/memo.txt は存在しないようですし、提供されたツールにはユーザーの情報にアクセスする機能がありません。お手数ですが、直接お名前と好きな数字を教えていただけますか？

と聞き返されました。入力 892 トークン。ファイルも消えています（再アクティブ化で microVM が入れ替わった）。画面に履歴が見えていても、モデルには渡っていない。

● 原因：クイック作成はメモリが無効  

公式ドキュメント（Memory）にはこう書いてあります。

By default, the harness provisions an AgentCore Memory instance automatically ... it remembers what happened in previous turns, even after the underlying microVM session has expired.

ところがハーネスの編集画面を開くと、「メモリを有効にする」トグルが OFF でした。
コンソールのクイック作成はメモリなしで作られるようです。
プレイグラウンドの設定パネルにもメモリ項目が出ていなかったのですが、これは「無効だから項目ごと非表示」だったわけです。

● 対照実験3：メモリを有効にして、もう一周

トグルを ON にすると「新しいメモリを作成（ハーネスで管理）」が選ばれ、戦略はセマンティック＋要約、短期メモリの有効期限 30 日。保存するとハーネスの バージョン 2 が作られ、「プロビジョニングに 3〜5 分かかります」。

 左メニューの「メモリー」に harness_a6o97-Rz3Dr95yL6 というリソースが「作成中」で現れました。Managed by 列にハーネス ID がリンクされていて、ハーネス所有のメモリだと一目で分かります。
 

READY 後、新しいセッションで種を蒔き直し（名前・57・memo.txt round2）、停止して、旧 ID を貼り直して同じ質問。
 

 もちろんです！…残念ながら、現在ファイルが存在しませんでした❌　先ほどのセッションで作成したファイルは、環境のリセットなどにより削除されてしまったようです  

 先ほどの会話で書き込みに成功していましたが、環境が変わったため（セッションのリセットや一時ファイルの削除など）、ファイルが消えてしまったようです。

■ 切り分け表

注目すべきはこの表の「停止→再開・メモリ有効」列です。会話だけ戻って、/tmp のファイルは戻らない。

つまり：

• セッションが生きている間は、会話履歴もファイルも microVM の中にある（公式ドキュメントでも、microVM 上の ephemeral context に会話履歴が含まれると説明されています）
• microVM が終了すると、どちらも消える。会話履歴を microVM の外に保持して再開後に戻すのが AgentCore Memory（無効なら誰も持っていない）
• /tmp に書いたファイルは今回戻りませんでした。Session Storage や EFS / S3 Files を /mnt 配下にマウントすれば永続化できると公式にありますが、今回は未検証
• モデルはどれも持っていない。毎ターン、セッション側の履歴を読み直してから働く

だからモデルを交代させても何も失わないんです。

コンシェルジュが変わっても、フロントの記録と部屋の荷物は残っている。

● 対照実験3：メモリを有効にして、もう一周

トークン数で見るコストの感触

当初は「高いモデル単独／安いモデル単独／計画は高い・実行は安い、の3パターンを回して円で比較」まで書くつもりでしたが、今回はプレイグラウンドでの単発検証なので、きちんとした比較は boto3 から同条件で回せる次の記事に譲ります。ここでは取れた数字だけ置いておきます。

この表から言えることは2つあります。

「切り替えれば安くなる」は単純ではありません。切り替え後のモデルはそれまでの履歴を丸ごと入力として受け取るので、後半を安いモデルにしても、入力トークンは前半の分だけ積み上がった状態で始まります。

もう1つ。ハーネス自体は無料ですが、メモリを有効にした時点で AgentCore Memory の従量課金（短期イベント／長期レコード／取得）が始まります。モデル料金・Runtime の CPU/メモリ秒課金と合わせて、「ハーネスは無料」であって「エージェントを動かすのが無料」ではありません。

■ 詰まったところ

● ① クイック作成はメモリ無効で作られる

• 症状：停止→再開したセッションで、画面に履歴が見えているのにモデルが何も覚えていない
• 最初の誤解：「再アクティブ化」がうまくいっていないのだと思った
• 切り分け：入力トークン 892 ＝履歴がモデルに渡っていない。ハーネス編集画面でメモリトグルが OFF
• 本当の原因：公式の「デフォルトで有効」は CLI（agentcore create）や API の話。コンソールのクイック作成は無効
• 回避策：作った直後に「ハーネスを編集 → メモリ」を確認する。プレイグラウンドの設定パネルに「メモリ」セクションがなければ無効のサイン
• なお CLI の agentcore create ウィザードは Memory を選ばせてくれるので、この罠はクイック作成固有です

● ② プレイグラウンドで変えたモデルは保存されない

• 症状：Nova Pro に切り替えて検証したあと、プレイグラウンドを開き直したら Claude Sonnet 4.6 に戻っていた
• 本当の原因：プレイグラウンドの設定パネルは呼び出し時オーバーライド（上の表の②）。ハーネス本体のバージョンは変わらない
• 回避策：恒久的に変えたいなら「ハーネスを編集」から。逆に A/B のつもりで編集画面を触ると新バージョンが作られて待たされるので、用途で使い分ける

● ③ 設定変更の反映にはバージョンとエンドポイントの切替ラグがある

• 症状：メモリを ON にして保存しても、すぐにはテストできない（「ハーネスをテスト」がグレーアウト）
• 本当の原因：更新は「バージョン 2 を作成 → DEFAULT エンドポイントを 2 に向け直す」の2段階。マネージドメモリのプロビジョニングで 3〜5 分
• 回避策：左メニュー「メモリー」のステータスが「作成中」→「アクティブ」になるのを待つ。モデル変更が即時だったのと同じ感覚で触ると「反映されてない？」と焦る

■ まとめ・次にやりたいこと

「セッション中にモデルを切り替えてもコンテキストを失わない」これは本当でした。

会話もツールの結果もファイルも、全部そのまま次のモデルに渡ります。

ただ、検証していて一番の収穫だったのは、動いた／動かなかったよりも、ハーネスが持っていてくれるのは「セッション」であって「モデルの頭の中」ではないと分かったことでした。

しかもそのセッションも一枚岩ではありません。セッション中は会話もファイルも microVM の中にあり、microVM が終わったあとに会話を持ち越すのが Memory、と持ち主と寿命が違う。

言われてみれば当然なのですが、私は最初「切り替えてもコンテキストが維持される」を「モデルが記憶を引き継ぐ」と読んでいました。実際にはそうではなくて、会話もツールの結果もファイルもセッション側に積まれていて、モデルは毎回そこを読みに来る「交代要員」にすぎません。だから交代できるんだ、と腑に落ちました。

これは要するに、状態を実行主体から切り離すという設計の原則を、そのままエージェントに持ち込んだものと理解できます。ステートレスなアプリケーションと同じ話をしているんですね。

さて、モデルを差し替えられることは分かりました。次に気になるのは「じゃあこれ、誰に使ってもらうのか」です。コンソールのプレイグラウンドは AWS アカウントの中にあるので、社内の非エンジニアにそのまま渡すわけにはいきません。

■ 後片付け

検証が終わったらハーネスを削除します。マネージドメモリは DeleteHarness でカスケード削除されるのがデフォルト（deleteManagedMemory=false を渡すと残せます）。

左メニュー「メモリー」から消えていることを確認して終わりです。

■ 参考リンク・但し書き  

※ この記事は 2026年9月2日時点の挙動に基づきます。AgentCore まわりは更新が速く、対応プロバイダー・リージョン・コンソールの挙動は今後変わる可能性があります。実際に試す際は公式ドキュメントをご確認ください。

• AgentCore harness（公式ドキュメント）
• Models and instructions — defaults at creation, overrides at invocation
• Memory（ハーネスのメモリ）
• Observability and cost controls — Understand harness costs
• Amazon Bedrock AgentCore harness is now generally available（AWS ブログ）