aiseed.dev›AIネイティブな仕事の作法 — ソフトウェア開発編
転換編 3-04 / Essay
転換編 3-04 № 04 · 2026

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

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

2026.08.04 🌐 EN

ロックインとは、移行コストが高くて動けない状態だ。SIer 委託モデルには三層のロックインがあり、Palantir の FDE モデルはその極致を示す。対して AI ネイティブ開発は、標準コードと標準形式で進めることで、ロックインそのものを最小化する。

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

ロックインの三層

SIer 委託モデルが顧客を固定するのは、三つの層の合わせ技だ。

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

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

(3) 人的依存 ── システムを長年保守してきたエンジニアの頭の中にしかない、暗黙の仕様。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-06で扱う。

なお、ここまでは 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)。

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

関連記事