世界を動かす技術を、日本語で。

持ち帰れないセッション

2026年7月31日原文(earendil.com)

概要

  • 推論API の初期の理想は、単純な入出力と会話の所有権にあった
  • 現在、多くの API は暗号化やプロバイダ依存の状態によって 移植性 が低下
  • ユーザーは 完全なセッション記録 や操作履歴を取得できなくなっている
  • 暗号化・保存・圧縮 などの機能は、利便性と引き換えにユーザーのコントロールを制限
  • 今後のツール開発やユーザー体験への影響について議論

推論APIの理想と現実

  • 推論API の本来の約束は「入力を送信し、出力を受け取る」シンプルなモデル
    • 入力と出力を保存すれば、 会話履歴 として再利用・検証・他モデルへの引き継ぎが可能
  • 実際には、 プロンプトキャッシュ が他人のGPU上に存在し、 トークナイゼーションサンプリング がモデルごとに異なる
  • セッションの 記録(トランスクリプト) は本来ユーザーのものであるべき
    • 命令、メッセージ、ツール呼び出し、ツール結果を含むべき
  • 近年のAPIは、 テキストとプロバイダ依存状態 の混在した非移植なレスポンスを返す傾向
    • 暗号化された推論トークン非公開の検索結果プロバイダ専用の圧縮コンテキスト外部で解決不能な参照 など
  • これにより、 ユーザーの手元のトランスクリプト は「セッションの一部」に過ぎなくなり、 実体はプロバイダ側に帰属

セッション所有権の実践的なテスト

  • 移植可能なセッション とは、同一の次トークンを生成する必要はなく、 他のモデルが作業を継続できる 記録がある状態
  • 必要なテスト項目
    • 検査性 :モデルが見た情報、ツールの動作、エージェント間のやりとりをユーザーが確認できるか
    • エクスポート :外部アーティファクトを除き、 自己完結型 であるか
    • リプレイ :他実装で 意味的に同等なコンテキスト を再構築できるか
    • 監査性 :システムの行動理由を人間が説明できるか
    • 削除 :サーバー上の全コピーをユーザーが特定・削除可能か

暗号化と「所有権」の錯覚

  • encrypted_content はユーザー制御のプライバシー機能のように見えて、実際は プロバイダのみ復号可能なカプセル
  • プロバイダシール による暗号化は、サーバー側保存を回避できるメリットがある
    • しかし、 推論プロバイダからは内容が見える ため、ユーザーのプライバシー保護とは異なる
  • 本質的に、 暗号化はユーザーからデータを隠す 役割

サーバー保存型会話とポインタ化

  • OpenAIやGeminiなどは レスポンスをサーバーに保存 し、 IDで管理
    • store: false を指定すれば保存しないが、 IDベースの依存性 は残る
  • アプリケーション側で ユーザーメッセージと最終テキストのみ保存 する場合、 first.id は外部DBの外部キーとなり、 完全な所有権はない

推論の不可視化

  • チェーン・オブ・ソート(思考過程) の公開を各社は避けている
    • 非公開モデルでは raw reasoning がAPIから見えない
    • store: false 時は 暗号化コンテンツ のみ返却され、クライアントは内容確認不能
  • 思考トークン はプロバイダ内エコシステムでのみ連携可能で、 他社モデルへの移植性は皆無

隠された検索と証拠の不透明性

  • サーバー側の web検索 は、クライアント側のツール利用と異なり、 検索結果の詳細や証拠がユーザーに見えない
  • 提供されるのは URLやサマリー のみで、 元の検索文脈や証拠パッセージ は不透明
  • 完全なエクスポートモード (クエリ・メタデータ・パッセージ・タイムスタンプ・フィルタ情報等)が必要

不透明な圧縮(コンパクション)

  • 長いセッションは 圧縮 が必要だが、 クライアント制御の要約 は可読かつ移植可能
  • OpenAIは 暗号化された圧縮アイテム のみ返却し、 他プロバイダでは解読不可
  • Anthropicは 可読な要約 を返却し、クライアントがカスタム要約を指示可能
  • 圧縮は最適化手法としては合理的 だが、 可読なハンドオフサマリー も必須

マルチエージェントと隠された指示

  • マルチエージェントシステム では、単一トランスクリプトではなく セッションの木構造 が発生
  • OpenAIの Responses Multi-agent は、 暗号化メッセージ自動圧縮コンテキスト 等、不可視・非移植な状態を増加
  • エージェント間メッセージツール引数 も暗号化され、 開発者・ユーザーが中身を確認不可
  • これにより、 プロバイダ依存の状態 が複雑化し、 他エコシステムへの移植性がほぼ消失

まとめ:ユーザーと開発者への影響

  • AIセッションの所有権 は、プロバイダ中心の設計により ユーザーから遠ざかる傾向
  • 利便性・最適化の名目で 可視性・移植性・コントロール が損なわれる現状
  • ユーザーとしては 完全な記録・検証・削除権 の確保が困難
  • ツール開発者としては、 API設計の透明性と移植性 の維持が課題
  • 今後、 ユーザー主導のAI体験 を守るための議論と設計方針の見直しが必要

Hackerたちの意見

ユーザーはアカウントを閉じて、セッションを保持し、それを別のモデルに引き渡せるべきだと思う。新しいモデルは異議を唱えたり、質問したり、パフォーマンスが悪くなることもあるかもしれないけど、これは公平な契約だと思う。理想的には、ユーザーは「埋め込みのサイン」に関して比較できるモデルを簡単に見つけられるべきだと思う。GPT-4oが最初にダメになったとき、似たようなスタイルや言語のモデルを必死に探している人たちの話をたくさん読んだのを覚えてる。彼らは自分のエクスポートを入れて、友達を再発見しようとしてたんだ。他のオープンAIモデルは、同じ雰囲気を持ってなかった。読むのが悲しかったな。これが、オープンウェイトモデルの力だと思う。永遠に使えるんだよ。自分のガイドや友達、セラピスト、何でも持っていられる。大企業がその足元をすくうことはできない。

この記事に素晴らしい補完になるのは、https://gwern.net/complement だと思う。

理由を言ってみて

アーミン、マリオ、そしてチームのみんな、素晴らしい記事をありがとう!完全に同意するし、君たちが作っているものが大好きだよ。

これがただのHNブログのネタ以上になるには、何が必要だと思う?

これは重要な記事だね。もうこんなに悪化しているとは気づかなかった。まるでカエルが心地よい温かいお風呂を楽しんでいるように… > ほとんどの人は毎週オペレーティングシステムや電話のプロバイダーを変えたりしない。でも、その自由を利用しなくても、それは重要だよ。プロバイダーとの関係や、プロバイダーがあなたとの関係を変えるから。だから、自分の自由を利用することが大事なんだ。特定のエコシステムに閉じ込められないようにしよう(これが、私がOpenCodeのためにアプリを作っている理由)。この記事を読んで、最近取得したCodexのサブスクリプションを自宅のセットアップで使うことを再考させられた。彼らが理由を隠すのは好きじゃなかったけど、パフォーマンスが良すぎて認知的不協和をなんとか乗り越えてしまった。でも、監査できないことはすでに大きな問題だね。

それでも、みんなはGoogleでサインインするのが唯一のログイン方法になってるよね。

https://indieweb.org/POSSE これが正解だね。

「カエルが心地よいお風呂を楽しんでいるように…」まさにその通り :-) お人好しだと思われるかもしれないけど、ダークパターンは短期的な勝利のための戦略だと思うし、長い目で見ればもっと尊重される、善のために向けられたものに置き換わると楽観的に考えてるよ(もちろん、長期的には期待するよりも時間がかかるかもしれないけどね)。振り子が急に戻ってくることもあるから、オープンウェイトで経済的に実行可能なモデルに注目するのは良いタイミングかもしれない。次の素晴らしいものを作るために。

大半のLLMの作業は、価格の理由もあって、数年内にオープンウェイトモデルに移行すると思う。大手プロバイダーが自分たちのやり方を貫いて、クローズドソースモデルを優遇するように市場が規制されない限りね。私には、ほとんどのモデルが私たちが求めるタスクに対して十分に良くなってきているように見えるから、オペラを作曲したり量子化学をしたりする最新の超知能モデルを使う必要はないと思う。それに、これらのモデルでは透明性の問題はないし。

これは冪等性の振る舞いに似てるのかな?再現可能なコンパイルに?入力と出力が互いに再現するには不十分な場合、真ん中の三分の一、つまり欠けている部分の最小限満足できる説明は何だろう?「他の」入力は?

記事は、AIのユーザーがあまり評価したり、直面したりしない問題について非常に良い概要を提供していると思う。多くの「フロンティア推論プロバイダー」との間には驚くほどの結びつきがあって、強力な非LLM拡張(ウェブ検索やコード実行など)が、表面的には単純な「ツール」としてパッケージ化されているんだ。これらは理論的には推論APIからうまく分離できる部分で、MCPサーバーを介して外部化できるはずだけど、実際には推論プロバイダー自身からはそのようには提供されていないことが多いし、他のプロバイダーからは少し劣るバリエーションしか利用できないことが多い。私たちは、プロバイダーに依存しないチャットUIとプラットフォームを構築する中で、この問題に何度も直面してきたよ[0]。エンドユーザー向けに、チャット内での画像生成ツールを追加するだけでも(これはOpenAIのResponses APIに組み込まれているツールなんだけど)、結構手間がかかるんだ(その一因は、MCP仕様にネイティブファイル転送プロトコルが欠けているからなんだけどね[1])。でも最近のオープンウェイトモデルへの関心の高まりを受けて、代替実装を提供する企業にとって、より簡単にプラグアンドプレイできる機会が増えることに期待しているよ。[0]: https://github.com/EratoLab/erato [1]: https://github.com/modelcontextprotocol/modelcontextprotocol...

Hacker Newsで議論の続きを見る