AI推論APIにおけるセッションのポータビリティ：課題とコミュニティの視点

ポータビリティの問題

現代の推論APIは、ユーザーが所有するトランスクリプト（対話記録）がAIセッションを完全に捉えているという考え方から離れつつあります。プロバイダーは現在、テキストと、暗号化された推論トークン、隠された検索エビデンス、元のプロバイダーのみが復号できる圧縮されたコンテキスト・ブロブといった、サーバー側に留まる不透明な状態（opaque state）を混在させて返しています。その結果、ローカルに保存されたトランスクリプトは、運用状態がプロバイダーのサーバーに残ったままのセッションの、部分的なビューに過ぎなくなっています。

プロバイダーがいかにポータビリティを損なわせているか

プロバイダーは各不透明な機能についてユーザー中心の正当な理由を挙げていますが、それらが合わさることで所有権が侵食されています。例として以下が挙げられます：

ユーザーに課金されるが、役に立たない要約を伴う暗号化されたブロブとしてのみ返される推論トークン。
モデルはソース資料を見ているが、クライアントには引用やスニペットしか返されないウェブ検索。
「不透明であり、人間が解釈することを意図していない」と説明される暗号化された圧縮アイテムを放出するサーバーサイドの圧縮。
他のモデルでは検査や再生ができない、暗号化されたペイロードとして隠されたサブエージェントの指示とメッセージ。
プロバイダーの環境内でのみ解決（resolve）できるファイル、ベクトルストア、コンテナ、キャッシュのリファレンス。
プロバイダーのサーバーに完全に保存されたIDによってキー付けされた会話状態。これにより、レスポンスIDがユーザーが制御できないデータベースへの外部キーとなってしまう。

ポータビリティのための実用的なテスト

この記事では、セッションが本当にポータブルであるかを評価するための5つの具体的なテストを提案しています：

検査 (Inspection): ユーザーは、モデルが見たもの、ツールが行ったこと、エージェント同士が何を話したかを見ることができるか？
エクスポート (Export): ダウンロード可能な通常のアーティファクトを除いて、セッションは自己完結しているか？
再生 (Replay): 別の実装が、エクスポートされたデータから意味的に同等のコンテキストを再構築できるか？
監査 (Audit): 人間が、システムがなぜそのアクションを取ったのかを事後的に説明できるか？
削除 (Deletion): ユーザーは、セッションが依存しているすべてのサーバー側のコピーを特定して削除できるか？レスポンスIDや暗号文は、データがサーバー上に存在するか、ユーザーが復号できないため、これらのテストに合格しません。

コミュニティの反応

Hacker Newsのコメント欄では、同意と代替的な視点の両方が強調されていました：

あるユーザーは、隠された推論が監査可能性を損なうため、この記事を読んでCodexのサブスクリプションの使用を再考させられたと指摘しました。
別のユーザーは、ClaudeとCodexのセッション間での切り替えに成功したと報告し、コンテキストの圧縮と同等の品質低下は許容できると述べました。
あるコメント：「ClaudeとCodexのセッションを、問題なく頻繁に継続させているよ。」
複数のコメント主は、プロバイダーが内部動作への詮索を避けるために、意図的に実装の詳細を隠していると主張しました。
対照的な見解として、長く重要な会話については、単一のプロバイダーに留まり、他では新しく始めることが許容されるという主張がありました。
MCPサーバーを介してツールを外部化したり、カスタムエージェント状態データベース（例：個別のMCPアクセス可能なデータベース）を構築したりすることで、コントロールを取り戻せると指摘する人もいました。
他には、どのモデルでも読み取れるMarkdown要約を含むノートディレクトリを維持したり、監査のためにマイクロプロンプトをログに記録するミドルウェアを使用したりするといった、実用的な回避策が提案されました。
数名は、オープンウェイトモデルは企業によって引き剥がされることがないため、永続性を提供し、ユーザーがガイド、セラピスト、または友人を無期限に保持することを可能にすると強調しました。
あるコメント主は、規制がクローズドソースに有利にならない限り、コストと透明性が原動力となってオープンウェイトモデルへの移行が進むだろうと警告しました。
別のユーザーは、探索には強力なモデルを、実行には小さなモデルを使用するといった、セッション途中でのコスト主導のモデル切り替えについて強調しました。

ポータブルなAPIに向けて

この記事では、ポータビリティを回復するために推論プロバイダーとエージェントビルダーが採用すべき7つのルールを挙げています：

ローカルのイベントログを正典（canonical）として扱うこと。サーバーのストレージはそれをミラーリングしてもよいが、クライアントはサーバーIDを参照することなくセッションを再構築できなければならない。
ストレージを明示的にすること：store: false は容易で、文書化されており、好ましくはデフォルトであるべきである。保持を必要とするあらゆる機能は、使用時にこれを宣言しなければならない。
いかなる不透明なアイテムも、意味の唯一の担い手であってはならない：暗号化された推論、圧縮、およびツール署名は、読み取り可能なプロバイダー中立的なハンドオフ表現に付随させることができる。
ホストされたツールには、完全な忠実度のエビデンスをログに記録することを求める：洗練された回答や引用だけでなく、正確な入力、出力、フィルタリング、プロベナンス（出所）、タイムスタンプ、およびコンテンツハッシュ。
すべてのエージェントについて、正確で読み取り可能なタスク、メッセージ、結果、リネージ（系統）、モデル、およびツール権限を永続化することで、サブエージェントの通信を監査可能にする。
検査可能な圧縮を返す：読み取り可能な要約、それを作成するために使用された指示、および何が破棄されたかを理解するのに十分なリネージ。
ファイル、コンテナ出力、検索スナップショット、および生成されたメディアなどのアーティファクトを、コンテンツアドレス型のローカルアーカイブにエクスポートできるようにする。

蒸留とモデルレイヤーのロックイン

セッションのポータビリティに加えて、この記事はモデルレイヤーにおける関連するロックインについても言及しています。主要なラボは、顧客が競合するモデルをトレーニングするためにサービスを使用することを禁止しながら、出力の所有権を主張していますが、彼ら自身は内部的に蒸留（distillation）を使用しています。この記事は、蒸留に対するデフォルトの態度は敵対からサポートへと転換すべきであると論じています。なぜなら、蒸留は高価なフロンティア能力を、ローカル、オフライン、またはユーザーの制御下で動作する、より小さく、より安価で、より高速なモデルに変えることができ、それによって競争を促進し、APIが消滅したときにも能力を維持できるからです。

結論

核心となる緊張関係は、不透明でサーバーに縛られた状態に依存するプロバイダー主導のパフォーマンス最適化と、検査、エクスポート、再生、監査、および削除に対するユーザー主導のニーズとの間にあります。ポータビリティがなければ、ユーザーが蓄積したコンテキストは単一のエコシステムに閉じ込められ、プロバイダーが品質、価格、信頼性、および信頼性で競合するインセンティブを弱めることになります。ポータブルなセッションを実現するには、明示的なストレージ、すべての不透明な機能に対する読み取り可能なハンドオフ、完全な忠実度のツールログ、監査可能なサブエージェント通信、およびエクスポート可能なアーティファクトが必要です。これらのステップにより、ユーザーはアカウントを閉じてセッションを維持し、新しいモデルが同意しなかったりパフォーマンスが悪かったりする場合でも、それを別のモデルに渡すことができるようになるのです。