マルチランタイムセッション
会話履歴を保ったままスレッド途中でランタイムを切り替えます。
SnaSession 1 つは生涯の中で複数の RuntimeSession をマウントできます。 runtime chain は、そのセッションに適用されたすべてのランタイム設定の 順序付き記録です。会話履歴は正規化されています。ランタイムネイティブの 形式は replay ごとに派生するため、ランタイム切り替えは respawn として 処理されます。
切り替え
// Claude Code で開始
await client.agent.start(sessionId, {
provider: "claude-code",
model: "claude-sonnet-4-6",
});
// ...ターンが進行し、履歴が積み上がり...
// 会話を保ったまま Codex に切り替え
await client.agent.restart(sessionId, { provider: "codex", model: "gpt-5.4" });provider フィールドに新しい runtime id を渡した agent.restart() は
現在のプロセスを終了し、新ランタイムで respawn し、正規化履歴を新ランタイムのネイティブ
形に replay します。セッションレコード、イベントカーソル、runtime chain
はすべて維持されます。
Resume vs restart
| 操作 | プロセス | 履歴 |
|---|---|---|
restart | 同じ設定で respawn | replay しない (warm restart) |
resume | 同じ設定で respawn | 再構築して再注入 |
restart (ランタイム変更) | 新設定で respawn | 新ランタイム用に再構築 |
長いアイドル後やランタイムが終了したときは resume を使います。
アプリがランタイム切り替えを必要とするときは、provider フィールドに
新しい runtime id を渡して restart します。
なぜ重要か
ほとんどの「エージェントプラットフォーム」抽象は、会話をランタイムごとの 一時的状態として扱います。プロセスを失うとスレッドも失います。SNA では 正規化履歴が基準です。すべてのランタイムは replay 対象であり、記憶の 保管者ではありません。
注意
- ホスト型ツールの状態は引き継がれません。 Codex の画像生成、
web_search といったホスト型ツールはランタイム側に存在します。前回
呼び出しの
tool_resultは履歴にありますが、次のターンが前回の OpenAI 会話 id を期待する場合、その状態は失われています。 - モデル固有のトークンは replay で一部失われます。 Claude の拡張
thinking
signatureは Claude→Claude replay では保持されますが、 Codex に切り替えると破棄されます(対応する概念がないためです)。 - コストアトリビューションはターンごとに正確に維持されます。 3 層 アトリビューション (provider × modelProvider × model) がブロック単位で 記録されるため、事後分析でランタイム別の使用量を明確に分けられます。