AI業界で微妙なことが起きています。大規模言語モデルを販売する企業がその周りにプラットフォームを構築しています。プラグインマーケットプレイス。エージェントフレームワーク。ワークフロービルダー。メモリレイヤー。ナレッジ検索システム。
表面的にはこれは便利に見えます。1つのベンダーですべて。1つの請求書。1つの統合。
その下には、エンタープライズソフトウェアで最も古い戦略があります：ロックインを生み出す垂直統合。
プラットフォームクリープパターン
仕組みはこうです。まずモデル品質でLLMプロバイダーを選びます。それは正当な購買決定です。しかし、そのプロバイダーがワークフロービルダーをリリースします。無料で、緊密に統合されており、そのモデルとうまく機能します。そこでいくつかのワークフローを構築します。
次にプラグインマーケットプレイスを出します。ワークフローがそのエコシステムにしか存在しないプラグインに依存するようになります。次にドキュメントを独自フォーマットで保存するナレッジ検索システムが来ます。次にインフラに紐付いたメモリシステム付きのエージェントフレームワーク。
6ヶ月後、オーケストレーションロジック、ビジネスナレッジ、ワークフロー定義、ガバナンスポリシーのすべてが、プラットフォーム能力ではなくモデル品質で選んだプラットフォームに組み込まれています。
モデルを選んだつもりが、ベンダーを得ていました。
エンタープライズチームにとって重要な理由
リスクは理論的ではありません。AIプラットフォームがLLMプロバイダーである場合、エンタープライズチームは3つの具体的な問題に直面します：
1. プラットフォームを切り替えずにモデルを切り替えられません。 競合プロバイダーからより良いモデルが発売された場合 — これは今や四半期ごとに起こります — 選択に直面します：改善を無視するか、ワークフロースタック全体を再構築するか。ほとんどのチームは無視を選びます。競合が自由に実験する間、AI品質は停滞します。
2. ガバナンスがプロバイダー固有です。 設定した承認ゲート、監査証跡、PII検出、コンプライアンスコントロールはそのプロバイダーのプラットフォームに紐付いています。別のモデルに移行すると、すべてを失います。モデルにロックインされているだけでなく、ポータブルでないガバナンスフレームワークにロックインされています。
3. ナレッジ資産が閉じ込められています。 アップロードしたドキュメント、構築したRAGパイプライン、チューニングした検索設定 — これらは独自システムに存在します。移行はすべてを再インデックスし、検索品質を再テストし、新しいプラットフォームのチャンキング戦略が結果を劣化させないことを祈ることを意味します。
分離の原則
解決策は契約的ではなく、アーキテクチャ的です。オーケストレーションレイヤーとモデルレイヤーは独立すべきです。
これは、ワークフロー定義、ガバナンスポリシー、ナレッジソース、ビジネスロジックがLLMを交換可能な実行エンジンとして扱うレイヤーに存在すべきことを意味します。ClaudeからGPT-4、Geminiに切り替えたい時、プラットフォームではなくモデルパラメータを変更します。
JieGouは初日からこの原則に基づいて構築されました。実際にはこのようになります：
レシピはモデル非依存です。 JieGouレシピはプロンプト、ガバナンスルール、ナレッジソース、出力フォーマットを定義します。モデルは構造的依存関係ではなく設定パラメータです。今日Claudeで動作するのと同じレシピが、明日はGPT-4で、来週はGeminiで動作します。書き直し不要。ビジネスロジックの再テスト不要。
ガバナンスはポータブルです。 JieGouの10層ガバナンススタック — RBAC、承認ゲート、PII検出、信頼度しきい値、監査証跡、ブランドボイスコントロール、コンプライアンスポリシー、部門スコーピング、信頼エスカレーション、品質モニタリング — はモデル所有ではなくプラットフォーム所有です。モデルを切り替えても、すべてのガバナンスルールはそのままです。
ナレッジソースはプロバイダー非依存です。 ドキュメント、RAGパイプライン、検索設定はJieGouのナレッジレイヤーに保存されます。選択したモデルに接続します。プロバイダーを切り替えても再インデックスは不要です。
BYOMは実際の柔軟性を意味します。 JieGouは9プロバイダーをサポートしています — Anthropic、OpenAI、Google、およびOpenAI互換エンドポイント経由の6つのオープンソース/セルフホストオプション。ワークフローの各ステップで異なるモデルを使用できます。同じワークフロー内でClaudeを推論に、GPT-5-nanoを分類に、Llama 4を大量抽出に使用できます。
ポータビリティが可能にすること
オーケストレーションレイヤーが独立していれば、ロックインされたチームにはできないことが可能になります：
- 合成ベンチマークではなく、実際のワークロードでモデル品質を比較するベイクオフの実行
- ワークフローを再構築せずに安価なタスクを安価なモデルにルーティングしてコストの最適化
- APIキーを追加し、レシピに割り当てて実行するだけで初日から新しいモデルを採用
- プロバイダーが、作業を失わずに離脱できることを知っているため強い立場からの交渉
- 重要インフラのマルチベンダー戦略を義務付けるコンプライアンス要件の充足
テスト
現在のAIプラットフォームについて3つの質問をしてみてください：
- LLMプロバイダーが明日価格を倍にしたら、ワークフローを再構築せずに今週中に競合に切り替えられますか？
- 競合があなたのユースケースで20%良いスコアのモデルをリリースしたら、1時間以内にテストできますか？
- 規制当局がモデルプロバイダーの独立性を実証することを要求したら、アーキテクチャを見せられますか？
これらのいずれかに「いいえ」と答えた場合、プラットフォームがプロバイダーになっており、ロックインは既に始まっています。
結論
モデル品質は収束しています。上位3-4プロバイダーの差はリリースごとに縮小しています。エンタープライズAIの差別化要因は、もはやどのモデルを使用するかではなく、すべてのモデルをどれだけ柔軟に使用できるかです。
最高のAIプラットフォームはすべてのAIモデルで機能します — 単一プロバイダーにロックインするものではありません。
JieGouはオーケストレーションとモデルを分離しているため、次の四半期にどのLLMがベンチマークをリードしても、レシピ、ガバナンス、ナレッジはポータブルなままです。