クラウドファーストからデータ所在地ファーストへ — エンタープライズ AI 購買のシフト

本記事は、そのシグナルと、2026 年に AI を購入するエンタープライズにとってそれが何を意味するのかを追います。

クラウドファースト時代と、それがうまく機能した理由

2023 年を通じて、そして 2024 年初頭にかけて、エンタープライズの AI 購買はより広範なクラウドソフトウェアのパターンを踏襲していました。ベンダーがマネージド LLM API を提供し、deployer はそれに統合し、推論はベンダーのインフラ上で行われ、deployer のコンプライアンス部門はベンダーの認証(SOC 2、ISO 27001、GDPR に整合する DPA)を十分な証跡として受け入れました。これは調達が簡単で、評価が迅速で、過去 10 年間にわたるエンタープライズの SaaS 購買方法によく適合していました。

2024 年 3 月の a16z のエンタープライズ調査は、クラウドファースト末期の状況を捉えていました:エンタープライズの 72% がモデルへのアクセスに API を使用し、半数以上が自社のクラウドサービスプロバイダーがホストするモデルを使用しており、新しい要件に適合する製品については「以前は成約まで 1 年以上を要していた取引が、2 ~ 3 か月で進められている」とされています^[3]。2024 年半ばの時点ですら、新しい要件は既に取引曲線を歪め始めていました。

何が壊れたか

EU AI Act は 2024 年 8 月に発効しました。禁止された AI 実践は 2025 年 2 月 2 日に効力を発し、ガバナンスおよび GPAI 義務は 2025 年 8 月 2 日に、透明性義務は 2026 年 8 月に到来する予定であり、調達アーキテクチャを再形成する高リスク deployer 義務は 2027 年 12 月 2 日から適用されます^[1]。2026 年 5 月 7 日の omnibus 政治合意は、2027 年 12 月 2 日のマイルストーンを再確認し、新たな禁止事項を追加しました^[2]。これにより、調達チームが期限の延期を期待する余地は失われました。

本法は、AI システムのprovider(提供者)とdeployer(導入者)を区別しています。Deployer 義務には、人間による監督、モニタリング、ログ保持、そしてこれらの能力を要求に応じて実証することが含まれます^[1]。重要なのは、義務が LLM ベンダーではなく deployer —— 銀行、病院、機関 —— に課されるという点です。

この一つの法的事実こそが、アーキテクチャを反転させたものです。Deployer 義務は、ベンダー認証によっては充足できません。クラウドファースト調達は、ベンダーの認証が deployer のコンプライアンス態勢の代理指標になると仮定していました。所在地ファースト調達は、その仮定が成り立たなくなったときに deployer が行うことです。

それを裏付けたシグナル

2026 年における 3 つのシグナルが、所在地ファーストが法域を越えた方向性であり、欧州固有の現象ではないことを裏付けました。

NIST AI RMF Critical Infrastructure プロファイル、2026 年 4 月 7 日。^[4]米国における重要インフラ運営者を対象とした AI RMF deployer 義務の、連邦レベル初のスコーピングです。概念ノート段階であり、最終化されてはいませんが、方向性は明確です:米国連邦調達は、EU が成文化したのと同じ deployer 義務のフレーミングに向かっています。

OECD AI Policy Toolkit、2026 年 6 月 3 日。^[5]OECD 流に言えば「原則は決着した。ボトルネックは実装である」ということです。Toolkit のフレーミングは、EU および米国の軌道と十分に一致しており、多国籍エンタープライズが最も厳格な法域に向けて一度設計すれば、他の法域も充足できる程度になっています。

a16z 取引サイクル圧縮の継続。2024 年の調査^[3]が初期の形を捉えました。2026 年には、deployer 義務要件に適合する製品は数週間で調達を通過する一方で、適合しない製品は依然として 1 年以上を要します。市場のシグナルは、調達決定そのもののスピードに表れています。

所在地ファーストはアーキテクチャ的にどのような形か

シグナルが収斂するアーキテクチャには、4 つの特性があります:

1. Deployer に対してローカルな推論。ユーザーのデバイス上、または deployer が運用するサーバー上のいずれか。プロンプトとレスポンスは deployer の境界を離れません。
2. Deployer が保有する、コンテンツを含まない監査ログ。すべての管理アクションは、タイムスタンプとアクターとともに deployer の SIEM に記録されます。監査行にはプロンプトもレスポンスも記載されません。行が証跡であり、コンテンツは deployer 自身の保存ポリシーに従って保持されます。
3. Deployer の IdP を介した認証。Microsoft Entra ID または Google Workspace に対する OIDC。既存のアクセス制御がそのまま適用されます。
4. ベンダー側テナントなし。ベンダーはランタイムを運用せず、データを目にせず、コンプライアンス態勢の障害点にもなりません。

クラウド LLM API は、特性 1 ~ 3 を労力をかければ実装できます。特性 4 は構造的に実装できません —— ランタイムを運用することがクラウド LLM API たる所以だからです。所在地ファーストは、それをベンダー選定基準ではなくアーキテクチャ上の制約として扱います。

2026 年に AI を購入するエンタープライズにとってこれが意味するもの

3 つの具体的な含意があります。

第一に、ベンダーアンケートは再構成が必要です。Deployer が 2024 年に問うた質問はベンダーの認証についてのものでした。2026 年に問う質問は、上記の導入アーキテクチャ特性についてのものです。テンプレートをまだ書き直していない調達チームこそが、購買サイクルの停滞を報告しているチームです —— 詳細なパターンについてはオンプレミス AI の導入が調達段階で停滞する理由をご参照ください。

第二に、最も厳格な法域がアーキテクチャを決定します。多国籍 deployer が EU AI Act の 2027 年 12 月 2 日の義務^[1]に合わせて設計すれば、米国、英国、日本、シンガポールの要件にも違反しません —— 義務ごとの対応付けについてはEU AI Act コンプライアンス記事をご参照ください。OECD Toolkit^[5]が文書化している法域間の収斂こそが、単一のアーキテクチャを実現可能にしているものです。

第三に、調達サイクルの計算が変わりました。所在地ファーストに適合する製品は 2 ~ 3 か月で成約し、適合しない製品は 12 か月以上を要します^[3]。2026 年に AI を購入するエンタープライズは、シートあたり単価よりも先にアーキテクチャ適合性を評価すべきです —— 9 か月の調達遅延は、いかなるシートあたり単価差よりも高くつくからです。

参考文献

1. European Commission.「AI Act — Regulatory framework on AI.」digital-strategy.ec.europa.eu。2026-07-22 閲覧。
2. European Commission.「AI Act omnibus political agreement, 7 May 2026.」digital-strategy.ec.europa.eu。2026-07-22 閲覧。
3. Andreessen Horowitz.「State of Generative AI in the Enterprise.」a16z.com/generative-ai-enterprise-2024。2024 年 3 月 21 日公開。2026-07-22 閲覧。
4. NIST.「AI Risk Management Framework.」nist.gov/itl/ai-risk-management-framework。2026-07-22 閲覧。Critical Infrastructure 概念ノートは 2026 年 4 月 7 日に公表されました。
5. OECD AI Policy Observatory.「AI Policy Toolkit.」oecd.ai/en/wonk。2026-07-22 閲覧。2026 年 6 月 3 日公開。

関連記事

• 2026 年における EU AI Act:オンプレミス導入がコンプライアンスにもたらす変化
• オンプレミス AI の導入が調達段階で停滞する理由(そしてそれを解消するフレーミング)
• 2026 年の OECD AI Policy Observatory が示す、法域を越えた AI ルール
• すべての記事 →