- 推論APIは暗号化された推論・検索結果・圧縮状態・サブエージェントのメッセージをプロバイダー内部に隠すことで、ユーザーが保持する会話履歴を完全なセッションではなく、一部しか見えない複製にしている
- セッションの可搬性とは、別のモデルで同じ出力を再現することではなく、既存プロバイダーのID参照や復号なしに検査・エクスポート・再生・監査・削除できる、意味的に完全な記録を確保することを指す
- OpenAI、Anthropic、Googleの保存型レスポンスと非公開推論、ホスト型検索、不透明な圧縮は、同一エコシステム内での継続性を高める一方、別のプロバイダーが引き継げないプロバイダー封印状態を蓄積する
- マルチエージェントでは委任内容やエージェント間メッセージまで暗号化され、自動圧縮と隠れた指示が組み合わさることで、誤ったファイル修正や機密漏えいが起きてもどのような作業を指示されたのか監査しにくい
- 可搬なAPIはローカルのイベントログを基準記録とし、保存を明示的な選択にしなければならない。また、検索・圧縮・エージェント通信・成果物の読める完全な記録と、ユーザー管理下での**蒸留（distillation）**を許容すべきである
推論APIが変えるセッション所有権
- 初期の推論APIの約束は、入力を送り出力を受け取った後、その両方を保存しておけば、会話を検査・保管・再生したり、別のモデルへ渡したりできるというものだった
- この抽象化は最初から完全ではなかった
- プロンプトキャッシュはプロバイダーのGPU上に存在する
- モデルごとにトークン化が異なり、サンプリングも意図的に再現されない
- それでも、指示、メッセージ、ツール呼び出しとその結果を含む意味的記録はユーザーが所有でき、十分な能力を持つ別のモデルが既存の作業を理解して引き継ぐことができた
- 最近のAPIは、テキストとともにプロバイダー依存の状態を返す
- 課金されるが、不透明な暗号文や限定的な要約としてしか返ってこない推論トークン
- モデルが見た原文をクライアントが受け取れないWeb検索
- 元のプロバイダーしか復号できない圧縮コンテキスト
- アプリケーションからは見えないサブエージェントの指示とメッセージ
- 別環境では解釈できないファイル・ベクトルストア・コンテナ・キャッシュ参照
- プロバイダーのサーバーに保存されたIDでしかアクセスできないレスポンスと会話状態
- それぞれにはユーザー利便性や品質のための理由があるが、組み合わさると、ローカル記録はセッション全体ではなく、プロバイダーが運用状態を所有するセッションの部分ビューになる
セッション可搬性を判断する5つの基準
- 可搬であるとは、モデルを替えても次のトークンが同じでなければならないという意味ではない
- モデルごとに能力、学習された傾向、コンテキストウィンドウ、ツール利用の仕方が異なり、出力自体も非決定的である
- エクスポートされた記録には、新しいモデルが作業を続けられるだけの理解可能な情報が必要であり、以前のプロバイダーがIDを参照したり暗号文を解いたり、検索結果や要約を復元したりする必要があってはならない
- 検査（Inspection）: モデルが見た情報、ツールが実行した作業、エージェント同士がやり取りした内容をユーザーが見られなければならない
- エクスポート（Export）: 個別にダウンロードできる通常の成果物を除けば、セッション自体が完結していなければならない
- 再生（Replay）: 別実装でも意味的に等価なコンテキストを再構成できなければならない
- 監査（Audit）: システムが特定の行動を取った理由を、事後に人間が説明できなければならない
- 削除（Deletion）: セッションが依存するサーバー側の複製をすべて特定し、削除できなければならない
- サーバーデータのキーであるレスポンスIDは会話履歴ではなく、ユーザーが解けない暗号文もユーザー管理下にはない
- URLの引用一覧だけでは、検索過程でモデルのコンテキストに実際に入った証拠資料の代わりにはならない
ユーザーが解けない暗号化
encrypted_contentという名前は、ユーザー制御型のプライバシー保護機能のように見えるが、一般にクライアントは読めず、プロバイダーだけが開けられるカプセルである- プロバイダーが鍵を選び、自社モデル向けに復号し、どの環境で再生できるかも決めるため、より正確な名称は**プロバイダー封印状態（provider-sealed state）**である
- プロバイダー封印は実際のプライバシー上の利点をもたらす可能性がある
- OpenAIは
store: falseで暗号化された推論をクライアントへ返し、次回リクエスト時に中間状態を保存せずメモリ上で復号できる - とくにZero Data Retentionの顧客にとっては、サーバー側の会話保存を要求する方式よりよい
- OpenAIは
- しかしこの暗号化は、推論プロバイダーに対してデータを隠すのではなく、ユーザーにだけ隠す
保存型会話が記録をポインタに変える仕組み
- OpenAI Responses APIはデフォルトでレスポンスを保存し、ドキュメント上ではレスポンスオブジェクトを最低30日保持する
store: falseを使えばデータはOpenAIサーバーに保存されず、従来のcompletions方式に近くなる- Gemini Interactions APIも
store: trueがデフォルトである- 有料プランではインタラクションを55日保持する
- 無料プランでは1日保持する
- サーバー保存は、アプリケーションが送るデータ量を減らし、隠れた推論やツール状態を維持し、キャッシュルーティングを容易にする
- しかしローカルアプリケーションがユーザーメッセージと最終テキストしか記録しない場合、
previousResponseIdで使われるレスポンスIDは、制御できない外部データベースへの外部キーになる
公開されない推論記録
- 主要AI研究所は、生の思考過程（chain of thought）を公開しない理由があると考えており、非公開重みモデルの推論トークンを通常APIには露出しない
- OpenAIでは、保存型レスポンスの過去の推論を
previous_response_idで復元できるstore: falseでは、クライアントがencrypted_contentを保持し、次のリクエストで再送しなければならないreasoning.context: "all_turns"で後続生成に使えても、保存された推論は依然として不透明である
- Anthropicは、暗号化された完全なthinkingを
signatureフィールドとして返す- 有効化できる読み取り可能なthinkingテキストは、生の思考過程ではなく、別モデルが作成した要約である
- ツール使用ターンでは、thinkingブロックを変更せずに返さなければならない
- thinkingブロックはそれを生成したモデルに結び付いているため、モデルを切り替えるときは削除しなければならず、Anthropic内部でも移植を目的としていない
- こうした方式は同じエコシステム内での継続性は提供するが、別プロバイダーのモデルが解釈できる可搬な会話記録は作れない
ホスト型検索が残す記録の穴
- クライアント側の検索ツールは、クエリ、検索時刻、結果URLとタイトル、抽出された一節を記録できる
- ユーザーは順位や一節を検査し、ページを再取得したりコピーを保存したりして、別モデルに同じ証拠を渡せる
- ホスト型検索では、プロバイダーが非公開のツールループを実行する
- OpenAI、Google、Anthropicは検索行動、引用、選択的な出典URLを提供するが、回答生成に使われた完全なテキストコンテキストは提供しない
- URLの内容は変わりうえ、モデルにはもっと短い一節しか渡されていなかった可能性もあり、安定した再生記録にはならない
- 次のモデルが特定の出典を比較したり、論争のある数値を再検証したりしようとしても、結果順位、抽出一節、フィルタリングされた資料、前のモデルが見た正確な証拠を受け取れない
- 引用ページを再取得しても、当時使われたデータを正確に再現できないため、次のリクエストが別の場所へ移った後も、以前のプロバイダーがセッションの一部として残る
- ホスト型検索には、クエリ、結果メタデータ、検索一節、タイムスタンプ、保存されたコンテンツを含む完全忠実度エクスポートが必要であり、簡潔な引用だけが唯一の記録になってはならない
不透明なコンテキスト圧縮
- 長いエージェントセッションには圧縮が必要であり、クライアントが制御する読み取り可能な要約は、損失があっても検査・編集・移送できる
- OpenAIのサーバー側圧縮は、人間が解釈するために作られていない暗号化されたcompaction項目を返す
/responses/compactは、クライアントがそのまま再送しなければならないcanonical next context windowを返す- OpenAIは圧縮された意味を引き継げるが、他プロバイダーは暗号文と最近のコンテキストの一部しか受け取れない
- 不透明な圧縮は技術的に不可避ではない
- Anthropicのサーバー側圧縮は、読み取れる
contentフィールドを持つcompactionブロックを返す - クライアントはカスタム要約指示を与えられ、結果を検査したり別モデルへ渡したりできる
- どのプロバイダーでもクライアント側圧縮は可能である
- Anthropicのサーバー側圧縮は、読み取れる
- OpenAIの封印成果物は、通常の要約よりモデル固有状態をよく保持し、元のモデルでは高い性能を示せるかもしれないが、選択的な最適化として提供しつつ、読める引き継ぎ要約も併せて提供すべきである
マルチエージェントの隠れた委任と通信
- マルチエージェントシステムでは、1つの記録ではなくセッショングラフとエージェント間のメッセージフローが存在するため、可搬性の問題はさらに大きい
- OpenAI Responses Multi-agentベータは、
multi_agent_call、multi_agent_call_output、agent_message項目を追加するspawn_agentの例にあるmessage引数は暗号化されている- エージェント間メッセージは
encrypted_contentしか含まない - Multi-agentを有効にすると、クライアントが要求しなくても、すべてのエージェントにサーバー側の自動圧縮が適用される
- 推論要約はサポートされず、開発者が編集や削除のできないルートおよびサブエージェント指示も注入される
- その結果、封印された委任とメッセージ、個別に自動圧縮されたコンテキスト、隠れた推論、プロバイダーホスト型オーケストレーションが、1つの移送不能な状態の束を形成する
- 2026年6月、オープンソースのCodexクライアントには
Encrypt multi-agent v2 message payloadsの変更が適用された- Responses APIが親モデルのツール引数を暗号化する
- Codexが暗号文を渡すと、APIが子モデル向けに内部で復号する
- Codexの
InterAgentCommunication.contentは空であり、正確な作業指示は読める実行記録や履歴に残らない
- 子エージェントが誤ったファイルを編集したり秘密を漏らしたり、別作業を重複させたり誤った前提に従ったりしても、ユーザーは何を指示されていたのか確認できない
- Codex公開イシューは、暗号化転送とは別に、読める監査用コピーを保存するよう求めている
- これは最小限の設計であり、エージェント間の平文メッセージがデフォルトであるべきだ
セッションを移す自由が必要な理由
- ほとんどのユーザーがセッション途中でモデルを切り替えないとしても、移動可能性はユーザーとプロバイダーの関係を変える
- セッション移行が必要になる状況には、モデル廃止、サービス障害、価格変更、次のリクエストを阻むポリシー、機密フェーズのローカル実行、監査人による事後再構成が含まれる
- エージェントがセッションを長大化させることで、コーディングや研究のセッションには数日分の意思決定と証拠が積み上がり、個人アシスタントには数年分の履歴が蓄積されうる
- ユーザーが別の場所で続行できるなら、プロバイダーはモデル品質、価格、信頼性、信頼を巡って競争しなければならない
- 蓄積されたコンテキストを1つのプロバイダーしか解釈できないなら、ユーザーが離れにくくなる不利なインセンティブ構造が生まれる
可搬な推論APIの原則
- ローカルのイベントログが基準記録であるべきだ
- サーバー保存はそれを複製または高速化してよいが、クライアントはサーバーIDの参照なしにセッションを再構成できなければならない
- 保存は明示的な選択であるべきだ
store: falseは使いやすく文書化され、可能ならデフォルトであるべきだ- 保存が必要な機能は、利用時点でそれを明示すべきだ
-
不透明な項目が意味を独占してはならない
- 暗号化された推論、圧縮、ツール署名は、同じプロバイダーで品質向上のために含めてもよいが、読めるプロバイダー中立の引き継ぎ表現も提供すべきだ
- ホスト型ツールは完全忠実度ログを残すべきだ
- 正確な入力と出力、証拠、フィルタリング、出典、タイムスタンプ、コンテンツハッシュを記録しなければならない
- サブエージェント通信は監査可能であるべきだ
- 各エージェントの正確な作業、メッセージ、結果、系譜、モデル、ツール権限を読める形で保存しなければならない
- 圧縮は検査可能であるべきだ
- 読める要約、要約生成に使った指示、何が捨てられたかを理解できる系譜を返さなければならない
-
成果物はエクスポート可能であるべきだ
- ファイル、コンテナ出力、検索スナップショット、生成メディアは、コンテンツアドレス型のローカルアーカイブとしてダウンロードできなければならない
蒸留とモデル階層の依存性
- 米国の一部の大手非公開重み研究所は、外部蒸留に対して敵対的な姿勢を強めている
- Anthropicは2026年2月の投稿で、DeepSeek、Moonshot、MiniMaxの活動を
distillation attacksと呼んだ- 商用規約は顧客が出力を所有すると定めつつ、競合AIモデルの訓練にサービス出力を使う行為を禁じている
- 同時に自社の投稿では、先端研究所が自社モデルに適用する場合、蒸留を広く使われる合法的な訓練手法として認めている
- Anthropicはモデル開発のためにボットで公開Webデータを収集し、書籍を裁断してスキャンしてきた。OpenAIも自由にアクセス可能な公開インターネット上のコンテンツで訓練していると述べ、それをフェアユースだと主張してきた
- 両社は、内部でより小さなモデルを作る際には蒸留を通常手法として扱っている
- OpenAIは、強力なOpenAIモデルの出力で小型のOpenAIモデルを微調整する自社APIの蒸留ワークフローも提供していた
- 人間がインターネットに載せた膨大な成果物からは機械が学習できるべきだと主張しながら、研究所が作った出力からは他の機械が学習してはならないとする道徳的非対称性がある
- 蒸留によって、高価なフロンティアモデルの能力を、より小さく、安価で、高速なモデルへ移せる
- ローカル・オフライン・制約のあるハードウェア、またはユーザー管理下の環境で実行できる
- 競争を増やし、APIが消えても能力を保存し、一般的な作業の計算量とエネルギー使用を減らせる
ユーザーに保証されるべき最低限の自由
- ユーザーは、アカウントを閉じた後でもセッションを保存し、別のモデルへ渡せるべきだ
- 新しいモデルが異なる判断を下したり質問したり、性能が低かったりしてもよいが、前のモデルが見たユーザー履歴・証拠・計画・委任作業の代わりに暗号文しか受け取れないようであってはならない
- 状態保持型APIそのものが問題なのではなく、より高い性能がユーザー制御の低下と結び付くことが問題である
- サーバー保存はオプションであるべきであり、ホスト型ツールは観測可能で、圧縮は読めて、エージェント通信は監査可能でなければならない
- 非公開推論にも少なくとも可搬な引き継ぎ記録が必要であり、蒸留は、より高い障壁を正当化するタブーではなく、能力をより広く利用可能にする道であるべきだ
1件のコメント
Hacker News のコメント
この記事は、思っていた以上に状況がすでに深刻になっていることを示している。自由は実際に活用してこそプロバイダーとの関係も変わるため、特定のエコシステムに依存しないことが重要。
性能が高く推論過程を隠す Codex を苦労して受け入れてきたが、監査不能性がすでに大きな問題なので、個人向けサブスクリプションを考え直すようになった。そのため OpenCode 用のスマートフォンアプリも作っている
独自ツールの使用履歴はセッションのポータビリティを壊すため、意図的に除外している
ほとんどの AI ユーザーがあまり評価していない問題をよく整理した記事だ。最先端の推論プロバイダーは Web 検索やコード実行のような非 LLM 機能を単なるツールのように包装しているが、実際には強い参入障壁と結合を生み出している。
理論上は推論 API から切り離して MCP サーバーとして外部化できるが、プロバイダーがそのように提供することはまれで、代替事業者の機能は概して弱い。オンプレミスかつプロバイダー非依存のチャットプラットフォーム https://github.com/EratoLab/eratoを作る中で、チャット内の画像生成のように単純に見える機能でさえ実装が難しく、MCP にまだ基本的なファイル転送仕様がないことも原因だ: https://github.com/modelcontextprotocol/modelcontextprotocol...
オープンウェイトモデルへの関心が高まるにつれ、より簡単に差し替え可能な代替実装が増えることを期待している
画像生成は MCP で実装せず、独自ツールを書けばよい。Fal のような画像・メディア推論プロバイダーや、Web 検索・ディープリサーチのプロバイダーは十分に存在する
コンテキストのためのオープン標準やファイル形式が必要かもしれない。公開モデルがポータビリティのために同じ形式に合わせ、他のプログラムからもクエリできるよう SQLite ベースにできるのか気になる
実際には会話にはノイズが多く、コンテキストから除いたほうがよい場合が多い。リポジトリのメモ用ディレクトリに、AI が学んだこと、完了した作業、残作業を Markdown ファイルとして記録させ、次の会話で別のモデルが引き継げるようにしている。
必要なら先にメモを自分で編集することもできる
すべてのチェックに通ったときに戻ってくればよいので、チャットインターフェイスの不要な会話に悩まされにくくなる
したがってプロバイダーは人為的に依存を作ろうとしており、本質的には独占禁止法の対象だ。しかし現在の米国では FTC が弱体化しており、容認されている
今は回避策があっても、自由な移動をさらに難しくするインセンティブは十分にあるため、AI 企業がサービス劣化の土台を置き始めた点が懸念される
2つの現象を区別すべきだ。1つ目は、ユーザーが検査したり移したりできない隠れた状態が増えることで、これは明らかに悪い。2つ目は、機能実装と API がプロバイダーごとに分かれることで、移植が不可能になるのではなく難しくなる問題だ。
OpenAI Completions API が事実上の標準のように使われていた時代は終わりつつあり、閉じた部分を除けば新しい Responses API のほうがよい場合もある。すべてのプロバイダーを1つにまとめる統一抽象化を、製品・ライブラリ・SDK が追求し続ける必要はない。
データベースでも統一抽象化は漏れが生じ、技術ごとの実装を受け入れるようになったように、モデルプロバイダーも同じになるだろうし、セッションの一部だけがポータブルでもよい
まだ荒削りだが、セッションデータを自分で保存し、git に似たモデルで管理する https://github.com/pantoniou/fyaiを開発している
アカウントを閉じてもセッションを保存し、別のモデルに渡せるという契約は妥当だ。理想的には、埋め込みの特性が似たモデルも簡単に見つけられるべきだ。
GPT-4o が最初に終了したとき、エクスポートした会話を入れて昔の友人を取り戻そうと、似た話し方や性格のモデルを探していた人たちがいたが、他の OpenAI モデルは同じ感覚を与えられなかった。オープンウェイトモデルは永久に保存できるので、案内役・友人・相談相手を大企業が一方的に奪えないという強みがある
この議論を HN ブログのネタ以上に発展させるには、何が必要なのか気になる
現在のモデルはコンテキストウィンドウが限られているため、どこかの時点で内容を忘れるので、セッションの価値はそれほど高くない。将来、相互作用によってモデル自体が実際に学習し変化するなら、その変化は別のモデルへ移植できないため、この問題は大きな意味がないと思う
この記事と合わせて https://gwern.net/complementを読むと、優れた補完資料になる