aiseed.dev›AI ネイティブなソフトウェア開発
3-05 / Series
3-05 № 05 · 2026

独自フレームは
逃げ場のない檻になる。

独自フレーム・独自抽象層・人的依存 ── Palantir FDE を典型例として

2026.08.04 🌐 EN

ロックインとは、移行コストが高くて動けない状態だ。

前章で、SIer 委託モデルの消滅は必然だと示した。それでも顧客はすぐには動かない。動けない理由がロックインだ。この章では、ロックインの三層を分解し、Palantir の FDE モデルをその典型として読む。そのうえで、AI ネイティブ開発がなぜロックインを生みにくいかを見る。

ロックインは三つの層でできている

SIer 委託モデルが顧客を固定するのは、三つの層が重なるからだ。

一つめは独自フレームワークだ。SIer の社内標準フレームワーク、独自パッケージ、独自運用基盤がこれにあたる。これに乗っているシステムは、SIer 自身にしか保守できない。新しいベンダーに移ろうとすると、フレームワークごと書き換えになる。

二つめは独自抽象層と Ontology だ。顧客の業務概念を、ベンダー固有のモデルで表現する。顧客マスタ、商品マスタ、業務フロー ── すべてがベンダーの独自抽象で組まれていると、移行先のシステムでは同じ意味を再現できない。意味の互換性が失われる。

三つめは人的依存だ。システムを長年保守してきたエンジニアの頭の中にしかない、暗黙の仕様がある。SIer のチームが去ると、その知識ごと消える。ドキュメントは古く、コードは難読で、新規参入者には手が出ない。

flowchart TB subgraph Lock["SIer / FDE 型 ── 三層のロックイン"] direction TB L1["独自フレームワーク
(顧客は他に移れない)"] L2["独自抽象層・Ontology
(意味がベンダー固有)"] L3["人的依存
(エンジニアが知識を持って去る)"] L1 --> L2 --> L3 end subgraph Open["AI ネイティブ ── 標準コードと標準形式"] direction TB O1["標準ライブラリ
(誰でも読める)"] O2["標準形式
(JSON、SQL、Markdown)"] O3["AI が説明を再生成
(知識が人に固定されない)"] O1 --> O2 --> O3 end classDef good fill:#e8f5e9,stroke:#7a9a6d,color:#3a4d34 classDef bad fill:#fef3e7,stroke:#c89559,color:#5a3f1a class Open good class Lock bad

一層だけなら、別ベンダーへの切り替えで解ける場合もある。三層すべてが効くと、 移行が事実上不可能になる。SIer の高い価格は、この三層の上に乗っている。

ロックインは、移行コストが高くて動けない状態だ。三層のうち二つ以上が効くと、価格差が桁違いでも顧客は動けない。

Palantir の FDE モデルは、三層をすべて最大にしている

ロックインの三層をすべて最大化した形が、Palantir の FDE (Forward Deployed Engineer) モデルだ。ソフトウェア委託の世界で、もっとも洗練された形態として知られている。同時に、もっとも顧客を縛る形態でもある。

FDE モデルの仕組みはこうだ。

三層のロックインがすべて発生する。

結果として、Palantir に支払う額は、商品としてのソフトウェア開発よりはるかに高い。値段は競合との価格競争で決まらない。ロックイン構造によるプレミアムで決まる。

これは、SIer 委託モデルの極端な洗練形態として読める。日本の SIer も、規模は違うが、同じ三層を使って顧客を固定している。Palantir は、その仕組みをグローバル規模で、軍事・諜報・大企業向けに最適化した形だ。

Palantir FDE は、SIer 委託の最終形だ。三層のロックインを最大化した結果、顧客が払い続ける構造ができあがる。

AI ネイティブ開発は、標準的なコードを生成する

ここから先は、AI ネイティブ開発がなぜ構造的にロックインを生みにくいかを見ていく。最大の理由は、AI が標準的なコードを書くことだ。

なぜ AI は標準を選ぶのか。AI は公開された大量のコードで学習している。学習データの中で多数派なのは、標準ライブラリと標準形式だ。AI は確率的に最も書きやすい形式を出力する。結果として、出力は標準ライブラリと標準形式に偏る。

副作用が三つある。

つまり、AI ネイティブ開発を進めるだけで、自然にロックインを生みにくい構造になる。意図して避けるのではない。標準を使うほうが速いから標準になる。

別の AI、別のビルダーが引き継げる

ロックインの解け方を、もう少し具体的に見る。AI ネイティブなコードベースは、次の特性を持つ。

これが意味するのは、別の AI、別のビルダーが、最小コストで引き継げるということだ。

これは、SIer / FDE モデルでは構造的に成立しない選択肢だ。ロックイン構造を持たないことが、AI ネイティブ開発の構造的な強みになる。

AI ネイティブで作ると、別の AI も、別のビルダーも、顧客自身も引き継げる。ロックインは選択肢として用意されていない。

ロックインが残る場面と、解ける場面がある

整理する。ロックインが効き続ける場面と、AI ネイティブで解ける場面を、案件種別で分ける。

ロックインが残るのは、次の場合だ。

ロックインが解ける、または最初から無いのは、次の場合だ。

順序として、新規プロジェクトと拡張案件から先に動く。コア業務システムは、契約期限・規制対応・移行コスト評価の三つが揃ったときに初めて動く。価格差は大きくても、すべての案件が同じ速度では動かない。

業界全体の転換速度 ── 日本の多重下請け構造、雇用流動性、転換期の中間形態 ── は 3-07 で扱う。

ベンダー AI と後方互換性は、もう一つのロックインだ

ここまでは SIer 委託モデルの開発ロックインの話だ。これとは別に、ベンダー AI (Copilot 等) そのもののロックインがある。裏で動く知能を、ユーザーに無断で安価な内製モデルへ差し替えられる形だ。Microsoft の AI 責任者スレイマンは 2026 年 6 月、Anthropic への支払いを「最終的にはゼロにする」と公言した。開発ロックインが標準コードで解けても、業務フローを特定ベンダーの AI に預ければ、別の依存が生まれる。判断と道具を手元に残す原則は、こちらにも効く (→ Microsoft 365 同等環境を自前で作る)。

そして、Microsoft の最も深いロックインは、後方互換性そのものだ。古い API も古い挙動も切らずに抱え続けることで、顧客は乗り換えられない。だが同じ後方互換性が、誰も全体を把握できない複雑さと、古いコードに潜む穴を生む。実際、認証基盤 Entra ID の脆弱性 CVE-2025-55241 (CVSS 10.0) は、後方互換のために残されたレガシー API がトークンの発行元を検証していなかったことが原因で、世界中のほぼ全テナントで管理者になりすませた。M365 Copilot のゼロクリック漏えい (EchoLeak 等) も同根だ。攻撃も検証も同じ「深く理解する力」である以上 (1-01)、攻撃できる AI の時代には、こうした古い穴は、これまでより速く確実に暴かれる。だが Microsoft は後方互換性を捨てられない。捨てれば健全になるが、顧客を縛る力を失う。健全になることと、支配力を失うことが、同じ一つの行為になる。だから、檻を抱えたまま、穴を可視化され続ける (→ ブログ Fable 5 が戻ってきたら、すぐやるべきこと)。

その対抗軸が OSS だ。かつて OSS の「公開されている」は専門家にしか意味がなかった。「磨かれていて、すぐ使える」点でもプロプライエタリに劣るとされた。だが AI が隣にいれば、導入も運用も拡張も自分でこなせる。OSS とプロプライエタリの価値は逆転する。開かれていることが初めて実利になり、ロックインの効かない側に立てる。

まとめ

ロックインとは、移行コストが高くて動けない状態だ。

ロックインが解けた場面では、顧客はビルダーを必要とする。それが内製のビルダーであれ、外部のビルダーであれ、顧客は経営判断を下す経営陣 (CIO) を迎えることになる。ロックインを見抜き、抜け道を設計する力は、ベンダーの売り口の裏を読み、自社の利害を言語化し、代替の評価基準を立てる力だ。どれもリベラルアーツの守備範囲にある (1-04)。

次の章では、各社がビルダーを雇用する時代を扱う。ビルダーはどう位置づけられ、どう処遇され、どう機能するのか。

関連記事