AIのベンダーロックイン回避は、設計ではなく値段の問題だ

AI のベンダーロックインを回避する方法として国内で流通している処方は、おおむね3点に収まる。抽象化レイヤー（モデルゲートウェイ）を挟んで呼び出し先を差し替え可能にする。1つの提供事業者への集中を避ける。契約に Exit 条項とデータ所有権を書き込む。どれも間違っていない。ただしこの3点は、ロックインがすでに存在する状態を前提に書かれている。本稿が元記事から取り出したいのは、その前提が今どうなっているかという時間軸の話である。結論から言えば、AI のベンダーロックインはこの3点が守ろうとしている層にはまだ生まれておらず、生まれるとしたら3点が届かない場所に生まれる。

AI のベンダーロックインは、いまどれだけ現実なのか

ほとんど現実になっていない。Dwarkesh Patel は 2026 年 8 月の論考で、クラウド事業者の利益率が高いのは1つのクラウドから別のクラウドへ移ることに時間と費用がかかるからだと整理している。そのうえで AI モデルについてこう書く。

“But currently there is no switching cost for AI models.”

（だが現時点では、AI モデルにスイッチングコストは存在しない。出典: Dwarkesh Patel by Dwarkesh Patel、2026-08-08）

この指摘は観察としても裏づく。Every の執筆アプリ Spiral はトークン課金で動いており、Sonnet 5 はSonnet 4.6 より同等の出力で約30%多くトークンを使うと告知されていた。これが Spiral に入れない大きな理由になり、Spiral は次のリリースまで 4.6 で走らせると決まっている。一方、別の社内プロダクトで Sonnet 5 に差し替えたときは書式の崩れが増え、回答品質も落ちたため、数日のテストで 4.6 に戻した。報告したのは Spiral のゼネラルマネージャー Marcus Moretti である。ただし、日次ループで回す製品の健全性レポートのような反復・範囲限定のタスクでは Sonnet 5 が十分に機能するとも書いている（新AIモデルへの乗り換えは何を根拠に決めるのか ― 2日ほどの締め切りに対し監査と下書きを90分で終えたビズオプスのマルチモデル運用）。

ここで注目すべきは判断の内容ではなく、判断の可逆性である。コストの悪化は告知で事前に分かり、品質の悪化は社内プロダクトで試して分かり、差し戻しは数日で済んでいる。用途別の使い分けを決める基準そのものについてはClaude と GPT、業務での使い分けをどう決めるかで扱ったが、ここで言いたいのはもっと単純なことだ。差し戻せるのは、戻せない何かがモデル側に積もっていないからである。 調達の交渉力がいま強いなら、それは設計が優れているからではなく、市場がまだその段階にあるからだと見たほうがよい。

ロックインはなぜ抽象化レイヤーで防げないのか

生まれる場所が API ではなく重みの中だからである。

Dwarkesh の論考は、継続学習――セッションの境界を越えて実運用のフィードバックをモデルに取り込み続ける仕組み――が実装された後に何が変わるかを8項目の予測として並べたものだ。前提として彼は、セッションごとに Markdown ファイルを書き残すだけの仕組みでは、AI が人間並みの水準で仕事を丸ごとこなせるようにはならないと述べている（この前提の原文と訳はAI ベンダーの乗り換えはいつまで可能なのか — 継続学習が生むロックインへの8つの予測にある）。

8項目のうち本稿が扱うのは、ロックインに直接関わる1項目とその帰結である。継続学習が入ると、使い込むほどモデル自体が自分の組織とのやり取りを通じて良くなっていく。そうなると乗り換えは、自分の組織の文脈を数ヶ月分持っている社員を解雇して、ゼロから教育し直す未経験者に置き換える行為に等しくなる――というのが彼の比喩だ。そしてロックインが成立した後は、提供事業者は相応に厚い利益率を要求できるようになる。

この構造に対して、呼び出し先を差し替えられるようにする抽象化レイヤーは何もしない。差し替えの手間を下げる設計は、差し替えた先に資産が移るかどうかには関与しないからだ。Exit 条項とデータ所有権も同じで、自分の組織が入れたデータは返してもらえても、そのデータから提供事業者のモデルが得た学習は返ってこない。契約で守れるのは入力であって、学習ではない。

さらに厄介な帰結がある。Dwarkesh は、企業がこの種のロックインを避けようとするだろうと認めたうえで、次の問いを置いている。ロックインを受け入れるか、それともセッションを重ねるごとにモデルが自分向けに良くなるという価値を取り逃がすか、という選択だったらどうするのか。彼の見立てでは、実運用での利用がモデル改善の主な経路になるなら、提供事業者はセッションを学習に使わせる利用者や企業に補助を付けて優遇し、逆に学習に使わせない企業には最上位のモデルを渡さないと言うかもしれない。飴と鞭の両方で、学習を許させようとするだろうということだ。

断っておくと、これは実装前の予測である。継続学習はまだ動いていない。Dwarkesh 自身は、継続学習が機能する時点までには他にも多くが変わっており最も重要な変化はおそらく最も予測しにくいと断ったうえで、上に挙げた予測については今の時点でも明らかに見えると書いている。本稿はこの確度の評価に踏み込まない。それでも予測として読んで効くのは、ロックイン回避が無料の防御策ではなくなるという点だ。回避には諦めるものがある。それは設計の問題ではなく値段の問題である。

持ち出せる蓄積と持ち出せない蓄積は、何が違うのか

持ち出しやすさと蓄積の強さは、逆に並ぶ。元記事を2本並べると、その構図が出てくる。

1本は Hermes である。Nous Research の共同創業者 Karan Malhotra について、Behind the Craft の著者で聞き手の Peter Yang は、自分のエージェントが自分についての文脈を十分に蓄積しているので、モデルを入れ替えても Hermes の人格の違いをほとんど感じないと書いている。Yang はこの回の要点を、パーソナルエージェントの「パーソナル」とはモデルのことではなく、エージェントが持つ会話の記憶と共に築いたスキルのことだ、とまとめている。モデルは交換可能で、保全すべきは文脈のレイヤーだという整理である。Yang は 6 ヶ月以上の利用を経て整えた自分の soul.md――エージェントの性格設定ファイル――を、他の AIエージェントにも貼り直せる形で全文公開している（AIエージェントを乗り換えたら蓄積データは引き継げるのか — Hermes に学ぶ記憶レイヤーの設計）。

出典の性質は書いておく必要がある。この号はポッドキャストの告知で、収録の目次と Yang による要点整理の冒頭までしか本文に含まれていない。収録の逐語記録はない。したがって確認できるのは、Yang が書いた「Karan はモデルを入れ替えても違いをほとんど感じない」という記述までで、Karan 本人の発言の逐語は確認できない。計測された比較ではなく、「モデルは交換可能で、文脈が大事」という整理も Yang の言葉だ。

もう1本は Every の実践だ。オペレーション責任者の Arielle Shipper とグロース責任者の Austin Tedesco は、どちらもコードを書かないまま、週次の指標をチーム全員が使えるサイトにまとめた。Arielle 側の Codex に、最新のワイヤーフレームと改訂とその理由を1つの Markdown ファイルへまとめさせ、Slack 経由で Austin に送る。Austin は自分の Codex にそれをレビューさせ、Slack で返す。着想からホスティング済みのサイトと共有リポジトリまで4〜5日だった、と Arielle は語っている（複数AIモデルの使い分けをどう設計するか——「Fable=CEO」の組織図とエージェント出力が人間に読めなくなる問題）。

論拠の重さは揃っていない。前者は Yang が伝える本人の実感で、計測はされていない。後者は観察された所要日数である。それでも2つに共通しているのは、価値を担っているとされる資産がどちらも持ち出せる形式で置かれていることだ。Markdown の引き継ぎ資料は完全に持ち出せる。soul.md のような性格設定ファイルも、貼り付け先を選ばない形で持ち出せる。そしてこの「セッションごとに Markdown ファイルを書き残す」形式こそ、Dwarkesh が前提として、それだけでは仕事を丸ごとこなす水準には届かないと切り捨てたものである。

ここから先は本稿の読みになる。モデルを入れ替えても何も変わらないという、Yang が伝える Karan の実感は、文脈レイヤーに価値があることの証拠として整理されているが、同じ事実は逆からも読める。入れ替えた側に蓄積が載っていなかったということでもある。どちらの読みが正しいかは、継続学習が入るかどうかで決まる。入らなければ Yang の整理が続く。入れば、soul.md を持ち出しても同じエージェントには戻らなくなる。

つまり経営が向き合っているのは「ロックインされないための設計をどう組むか」ではなく、自分の組織の学習をどちらの側に置くかという配分の判断である。強い蓄積を取りに行くなら持ち出せない形になり、持ち出せる形を守るなら蓄積は弱いままになる。内製か、購入か ― 自前のAIハーネスへの投資をどう判断するかでは、投資判断の単位を個別ツールから「乗り換えられる設計」に引き上げるべきだと書いた。本稿が足すのは、その設計で守れる範囲には原理的な上限があるという一点だ。

自前で持つ側の蓄積は、何を引き受けることになるのか

保守の負担である。持ち出せる形式で資産を持つ選択は、無料ではない。

Anthropic のエンジニア Thariq Shihipar のチームは、Claude Code のシステムプロンプトを8割以上削ってもコーディングのテスト結果を損なわなかった。指示文の大半が、なくても成績を落とさない状態になっていたということだ。そして Anthropic は、新しいモデルに合わせてプロンプトを変更し、エージェント周りの指示を見直す必要があるかもしれないと述べている。Every の Katie Parrott はこの構図をこうまとめる。

“Skills preserve assumptions about the model they were written for. Try them freely but treat each new model release as a reason to prune.”

（スキルには、それが書かれた時点のモデルに関する前提が保存されている。自由に試してよいが、新しいモデルのリリースのたびに、不要なスキルを刈り込む機会と捉えるべきだ。出典: Every by Katie Parrott、2026-07-29）

この一文の出所はモデル更新で社内プロンプトが壊れる「プロンプト負債」——Opus 5移行で誰がスキルを再検証するのかである。症状が出てから原因をモデル側と自分たちの指示側に切り分ける手順については、AIモデルの評価基準の作り方、ベンチマーク56点のモデルが業務で勝つで扱った。本節で足すのは、症状が出る前に回す刈り込みを誰がいつ担うかである。

ここで決めるべきことは2つに絞れる。1つは主体だ。刈り込みを担えるのは、まずその資産を書いた持ち主である。スキルやエージェント定義には、書かれた時点のモデルについての前提が埋まっている。どの一文がどのモデルの挙動を見越して置かれたかを知っているのは書いた人間だけで、動作の良し悪ししか見えない第三者には、残すべき一文と負債になった一文の区別がつかない。全社の AI 推進部門に棚卸しを集約すると、この区別のつかない担当者が何十本もの資産を前にすることになる。

もう1つは起動の単位である。Parrott が置いている単位は暦ではなく、新しいモデルのリリースごとだ。四半期ごとの定期棚卸しにすると、世代交代の直後に壊れた資産が次の棚卸しまで放置される。逆にリリースを起点にすれば、刈り込みは提供事業者のスケジュールに従って起動する。

この負担を見積もると、前節の配分判断は現実的な天秤になる。学習を提供事業者に渡せば、刈り込みの一部は向こう側の仕事になる。渡さなければ、資産は自分の組織に残るが、モデルが世代交代するたびに刈り込みの費用を払い続ける。どちらが安いかは業務によって違う。

まとめ: 全社一律の「ロックイン回避」を決めるのをやめる

経営が次に決めるべきことは2つである。

第一に、学習許諾の判定単位を業務ごとに分けること。 セッションを提供事業者の学習に使わせるかどうかを全社一律のポリシーで決めると、諦めるものの大きさが業務ごとに違うという事実が消える。競争優位に直結する難しい業務ほど、強い蓄積を取りに行く価値が高く、同時に持ち出せなくなる痛みも大きい。この取引を業務単位で判断できる体制があるかを、次の調達サイクルで確認する価値がある。現状の契約書にこの条項の居場所がないなら、それは判断していないのではなく、既定値のまま渡していることになる。

第二に、「渡さない」を選んだ業務について、刈り込みを誰が・どの起動条件で担うかを決めること。 保守負担を誰の予算と人員で担うかを問う審査項目は、すでに前掲の内製化の論考に置いた。本稿が足すのは、その審査項目に主体と起動の単位を入れることである。主体は資産の持ち主、起動の単位はモデルのリリースごとだ。ここに人と時間を置かない限り、持ち出せる形式で資産を持っているという状態は、使えない資産を持っているという状態に静かに変わる。

契約と設計の実務として今日何を見るかは、内製か、購入か ― 自前のAIハーネスへの投資をどう判断するかの3つの審査項目が出発点になる。本稿が言えるのは、そこに学習許諾の欄が足りていないということだ。AI のベンダーロックインの回避は、抽象化レイヤーを挟んだかどうかでは測れない。測れるのは、何を諦めるかを業務ごとに決めた記録が残っているかどうかである。