自社のメモリはAIモデルよりも長く保たれるべきです

人々はしばしば、どのモデルが自社を支えているのかと尋ねます。その答えは重要です。品質、コスト、制限を決定し、私はそれに1時間を費やすことを喜んで受け入れます。また、もう一つ知りたいことがあります。モデルが変わったときに組織がまだ保有しているものは何かです。

日付で考えてみましょう。もしプロバイダーが火曜日に価格を2倍にしたり、構築したエンドポイントを廃止したりした場合、翌日の水曜日の朝に自分がまだ所有しているものは何でしょうか？

多くの企業にとって正直な答えは、APIキー、請求書、そして他社のサーバー上に他社の保持スケジュールで保存されている非常に長い会話履歴、です。

私のバックグラウンドは化学です。SCADA、実験結果、オペレーター自身のメモに接続された化学プラントのグレイボックスモデルを何年も構築してきました。その経験からすぐに分かるルールがあります：条件のない数値は結果ではありません。もし誰かが先週センサーを交換し、誰も記録しなければ、画面上の読み取り値は何も説明できません。

それは実験ノートの問題です。現在では調達の問題として現れ、AI予算が決定されるシートに載ることはほとんどありません。

一つにまとめて答えられる三つの質問

より大きなコンテキストウィンドウは、モデルが単一リクエスト内でより多くの情報を使用できるようにします。永続的なストレージはリクエスト間で何が残るかを決定します。ポータビリティは、プロバイダーが変更されたときにその情報が引き続き利用可能かどうかを決定します。これらは別個のアーキテクチャ上の課題であり、100万トークンのウィンドウは皆がそれらを一つとして扱うよう促しました。

Googleの公式ドキュメントは直接的な類推を提供しています: 「コンテキストウィンドウの類推は短期記憶です。」文字通りに受け取ってください。短期記憶は失われるものです。

したがって、巨大なウィンドウを販売するすべてのベンダーは、状態を永続化する別個のものも販売しています。これらの層をそれぞれの言葉で狭く読み取り、各層が実際に何をカバーしているかを確認してください。

OpenAI はデフォルトで Response オブジェクトを 30 日間保存します；Conversation オブジェクトとその項目はその TTL の対象外です。Amazon の 30 日削除ポリシーはBedrock Session Management APIに適用され、対象はその API のみです。Anthropic のクライアント側メモリツールは有用な境界を示しています：モデルがメモリ操作を要求し、アプリケーションがストレージを制御し、同社はさらにホストエージェント向けにマネージドメモリストアも提供しています。

これらはすべて、公開された通常のエンジニアリング上の決定です。また、貴社の作業コンテキストに関する保持ルールが他社のリリースノートに記載されていることを意味し、どのルールがどのデータに適用されるかを特定できるはずです。

スイッチングコストが実際に存在する場所

テキスト生成呼び出しを別のものに置き換えるだけで、週末で済みます。だから「マルチモデルです」という言い回しが安価に聞こえるのです。高価になる層は、誰もデモを行わない部分です。

埋め込み。変更することは埋め込みモデルは通常、コーパスの再埋め込みとインデックスの移行または再構築が必要です。生成モデルの変更は生成モデルはそのような要件を持ちません。そして両者は常に混同されます—通常は移行が迅速になると約束する者によってです。2025 年の文献は標準的な手順を次のように記述しています“コーパス全体を再エンコードし、近似最近傍（ANN）インデックスを再構築することは、重大な運用上の混乱と計算コストをもたらす”；その論文の独自の貢献である Drift-Adapter は、延期埋め込み空間間の変換を学習することで再構築を延期します。いずれにせよ、移行コストは検索の検証と運用作業、そして埋め込み呼び出し自体をカバーします。

ファインチューニングされた挙動。 Cohere の 2025年9月の廃止通知はすべての調達デスクの上位に位置付けられます：”Previously fine-tuned models will no longer be accessible.” あなたが作成に費用をかけた挙動は、ホストしていたエンドポイントと共に廃止されました。全員が公開されたプロセスに従いましたが、あなたのモデルは依然として消えてしまいました。

プロンプトとツールの挙動。 同じ指示でも別のモデルでは異なるアプリケーションが生成されます。あるエンタープライズアプリケーションで、研究者は回帰合格率が低下したと報告したは、元のモデルで 100% だったものが、同一のプロンプトを使用した新しいモデルでは 97.3% に低下し、意図的なプロンプト再設計を行って初めて回復しました。テストシナリオは本番環境でそれぞれの頻度で現れるため、この数値はライブワークフローが失敗する頻度の推定を裏付けません。これが支える運用ルールはシンプルです：顧客に届く前に、アプリケーションレベルで自らすべてのモデルアップグレードを検証してください。

これらすべては最終的に請求書に反映され、価格ページを比較したはるか後のことです。

他の誰かがあなたのカレンダーを管理しています

廃止は公開されたスケジュールに従って実行され、スケジュールはユーザー側のものではありません。OpenAI 1 年前に通知しましたが、2026 年 8 月に Assistants API を終了する前に行われました—同ページの基準では寛大で、GPT-4.5 プレビューは約 3 ヶ月でした。Mistral の ポリシーは、GA モデルで 6 ヶ月、プレビューおよびサードパーティモデルで 1 ヶ月で、ロールリングエイリアスが「モデルの挙動や価格のサイレントアップデートにさらされる可能性がある」と警告しています。

AWS は ライフサイクル ポリシーで静かな部分をはっきり言っています。「EOL 日までにアクティブモデルへ移行してください；移行は自動的には行われません。」

あなたのロードマップには共同執筆者がいますが、計画会議には出席せず、どの四半期にいるかにも関心がありません。

価格も変動要素です

Gemini 3.7 Flash の標準料金表では、キャッシュされていない入力トークンが 50 億、課金対象の出力トークンが 10 億で、月額 $7,500 かかります。2027 年 1 月 1 日に 現在予定されている料金は、他の料金や割引を考慮しない場合、そのトークン請求額を $15,000 にしますが、あなたの製品は以前と全く同じ動作をします。

凍結された価格リストでも請求額が増えることがあります。Anthropic の 価格ドキュメントでは、最新世代のモデルで使用されるトークナイザーが「同じテキストで約 30% 多くのトークンを生成する」ことが指摘されています—これはコンテンツに依存し、該当世代に特有です—したがって、各請求書への影響は測定が必要です。請求されるトークン数を測定してください。レートカードだけでは分かりません。

ワークフローを実行する製品において有用な経済指標は、再試行や人的レビューを含む、成功裏に完了したタスクのコストです。レートカードが変わらなくても、モデルが変わればその数値は変動します。

そして、離脱に 1 年かかる立場からは、これらは交渉の余地がありません。Capgemini は 1,300 人の幹部に調査を実施しました（2026 年春、数十億ドル規模の組織）で、重要な技術サプライヤー全般について尋ねました：36% が 1 社からの移行に 12 ヶ月以上かかると答え、10 人に 1 人は代替手段が全くないと答えました。これは二次供給源のないサプライヤー関係の記述です。

調達部門へ持ち込む

私はフランスの会社を経営しており、マルセイユに登録、欧州でホスティングしていますが、抽象的な主権の演説は依然として省きます。すべての技術サプライヤーからの独立は、普通の企業にとって手の届かないものです。同じ Capgemini の調査では、59% の幹部が完全なデジタル主権は非現実的と考えており、私も同意します。

重要な依存関係を理解し管理することは小規模な仕事であり、可能です。会議で答えられる 3 つの質問があります：データはどこに保存・処理されているか、誰がアクセスできるか、別のプロバイダーで運用し続けるには何が必要か。

すべての企業は物流、支払い、クラウドストレージについて同様に質問できることを知っています。作業コンテキストについて尋ねると、欧州への依存は数値を伴った二次供給源の議論として会議に持ち込まれ、調達部門が対応できる形になります。

ここで引用される数字に対する注意点があります。企業が複数のモデルを使用していることは、プロバイダー間で作業コンテキストを移行できるかどうかについてほとんど示していません。別途テストが必要です：記録、権限、未完了の作業を別のプロバイダーに持ち越しても使用可能かどうか。

実際にモデルを交換可能にする要素

モデル間で共有インターフェースを持つことは有用で、私も構築したいと考えています。それはモデル固有の機能や依存関係を可視化すべきです。ポータビリティは、すべてのモデルが同じように動作するという見せかけを排除し、差異を平坦化する抽象化は、優れたモデルに支払った理由を静かに失わせます。

より重い作業は、状態を所有することであり、どのプロバイダーも単独の管理者になるべきではありません。破綻する順序で 4 つの項目があります。

あなたの管理下にある権威ある記録。 メッセージ、取得されたソース、承認、実行チェックポイント。外部システムで完了したことや安全に再試行できることを記録します：メールは送信されたが確認が保存されなかった場合、これを知らない復旧手順はメールを二度送信してしまいます。再構築できないプロバイダーの状態は依存関係です。インシデントが自動で文書化する前に、明示的に一つの記録として書き留めておきましょう。

すべてのベクトルに対するソース。 ベクトルはコンパイルされた成果物で、チャンクはソースコードです。ソース文書とそのバージョン、文書 ID、チャンク境界、チャンク生成バージョン、埋め込みモデルのバージョンと次元、インデックスバージョン、そしてテキストを生成した処理を保存します。保存されたテキスト断片だけではテーブルや画像、OCR 結果を再構築できません。すべてを保持することで、再インデックスは計画的な移行となり、私が約束できるだけの安心感を提供します。

ソース、推論、決定を区別するレコード。メモリは、ソースが言ったこと、モデルが推論したこと、そして人が承認したことを分離しなければなりません。木曜日に支払うと約束したクライアント、支払いが遅れるというモデルの推測、金曜日への延長に合意したことは、ステータスが異なる3つのレコードであり、システムはどれを実行できるかを把握する必要があります。各レコードは、その起源、範囲、アクセスルール、現在のステータス（修正済みか上書きされたかを含む）を持つ必要があります。トランスクリプトには証拠が含まれていることがありますが、再生するだけではどの結論が現在も有効で、どの決定が依然として有効かを確実に特定できません。

実際にテストしたポータビリティ。テスト可能にする方法は2つあります：エクスポートとリストアの演習、そしてアプリケーションが達成すべきことを定義する評価スイートです。すると「切り替えられるか」という測定が誰でも実行できる指標となります：置換が品質、権限、レイテンシ、コストに関する要件内で代表的なワークフローを継続できるかどうかです。そして、再利用が許可されたトレーニングデータとそのバージョン、チューニング設定、受け入れテストを保持します。これにより再学習が可能になりますが、同一の挙動が保証されるわけではなく、ファインチューニングされたモデルIDは、あなたが一度も会ったことのない人物が設定した日付で期限切れになります。

次に、ホストされたセッション、プロンプトキャッシュ、プロバイダーによる取得を必要に応じて活用してください。これらは多くの場合優れたものですが、原則として拒否することはそれ自体が高コストです。要件は、これらが保持するレコードが回復可能であり、アクセスおよび保持ルールをそのまま保ったまま他所で使用できることです。計算リソースはレンタルし、レコードの管理権を保持しましょう。

私もアーキテクチャを過大評価すべきではありません。プロダクト・マーケット・フィットに達する前に、6週間早く出荷することはどんな抽象化層よりも効果的であり、顧客がいないうちに3つの検索バックエンドを構築するスタートアップは、実質的に博物館を作っているようなものです。その取引が適切かどうかは、製品と最終的な再構築のコスト次第です。原材料を回復可能に保ち、ショートカットはショートカットのままにしましょう。

変化した部分

AIが質問に答えるだけだった頃は、コンテキストが失われることは不便でした。プロンプトを再入力して先に進んでいました。現在では、会議の予約、チケットの作成、CRMへの操作まで行い、コンテキストが欠如すると顧客のシステム内で作業が重複したり未完了のまま残ったりします。

モデルベンダーは卓越したものを構築し、私はそれらを日々利用しています。私が述べている責任は、間に位置するプラットフォームを構築する私たちにあります。依存関係を可視化し、何が承認され何が完了したかの信頼できる記録を保持することです。

完了したすべてのワークフローは、組織に再利用可能な何か—検証済みの結果、追跡可能な履歴を持つ決定、次のタスクへのより明確な出発点—を残すべきです。その蓄積された価値は、それを生み出したモデルよりも長く存続すべきです。

水曜の朝にまだ所有しているものは何か、問いかけてみてください。