ベンダー選定

MicrosoftとMistralが閉域AIを公式化｜クラウドに出さないAIの設計・選定軸

2026年7月23日20分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・DX

結論：フロンティアモデルは「閉域でも動く」時代に入った。判断軸はモデル選びからガバナンス設計へ移る

2026年7月21日、MicrosoftとフランスのAI企業Mistral AIが戦略提携の拡大を発表しました。Microsoftの公式ニュースルーム（news.microsoft.com）によると、今回の提携では、Mistralの最新モデル Mistral Medium 3.5 と文書処理モデル Mistral OCR 4（Mistral Document AI） を Microsoft Foundry に投入し、加えて Medium 3.5 を Copilot Studio でも利用可能にします。そして最も注目すべき点は、これらのモデルを クラウド／クラウド接続／完全遮断（fully disconnected） の3つの動作環境にまたがって展開できるとしていることです。

ここで経営者に伝えたい結論はシンプルです。「機密データはクラウドに出せない、だから生成AIは当社には無理だ」という前提が、公式に崩れ始めた ということです。世界最大級のクラウド事業者が、外部ネットワークから完全に切り離された自社サーバー環境でもフロンティアモデルを動かせる構成を、正式な製品ラインとして打ち出しました。

ただし、これは「閉域なら何でも安全に動く」という話では決してありません。むしろ選択肢が増えたことで、判断の重心は『どのモデルが賢いか』から『自社のデータ・規制・運用体制に対して、どの動作環境が妥当か』へと移ります。 本稿は、この発表を起点に、クラウドに出さないAIをどう設計し、どのベンダーとどう組み、どこで失敗しやすいかを、GXOの判断フレームとして整理します。AI導入の要件整理をこれから始める経営者・情報システム担当者が、社内検討の叩き台に使えることを狙っています。

AI ASSESSMENT

PoC の前に「そもそも使えるか」を30分で見極めませんか？

対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。

30分壁打ちを予約

何が発表されたのか（確認できた事実のみ）

まず、二次報道の憶測と一次発表を切り分けます。以下はMicrosoft公式ニュースルーム（2026年7月21日付）で確認できた範囲です。

横にスクロールして確認できます

項目	内容
発表日	2026年7月21日
提携当事者	Microsoft・Mistral AI（戦略提携の拡大）
Foundryに投入されるモデル	Mistral Medium 3.5、Mistral OCR 4（Mistral Document AI）
Copilot Studioに投入されるモデル	Mistral Medium 3.5
動作環境の幅	クラウド／クラウド接続（Azure Local）／完全遮断（fully disconnected）
インフラ投資	数十億ドル規模の投資と欧州データセンターへのNVIDIA Vera Rubin GPU配備を表明（発表による。金額内訳・具体基数は非開示）
狙う市場	規制産業・エンタープライズ（金融、製造、医療、重要インフラ等）の「主権（sovereignty）」「管理下でのフロンティアAI」

Microsoftのブラッド・スミス副会長兼社長は、欧州が「データや運用の管理を犠牲にせず、世界最高水準のAIにアクセスできるべきだ」という趣旨のコメントを、Mistralのアルテュール・メンシュCEOは「フロンティアAIをあらゆる組織の手に、かつ組織の管理下に置くのが我々の使命だ」という趣旨のコメントを、それぞれ公式発表で述べています。

注意点として、OCR 4の処理速度・対応言語数・具体的な価格・国内リージョンでの提供時期といった詳細な数値は、本稿執筆時点の公式発表では明示されていません。これらは各社の技術ブログや価格表で必ず一次確認してください。本稿では、確認できていない具体値を断定しません。

なお、報道各社（Neowin、PYMNTS、Futurum、HPCwire等）はこの提携を「Sovereign Cloud（主権クラウド）路線の延長」「欧州のAI主権戦略」と位置づけて報じています。これらは各媒体の解釈を含むため、事実（提携拡大・モデル投入・遮断環境対応）と論評（主権戦略としての意味づけ）は分けて読む必要があります。

なぜ日本の中堅企業に関係するのか：3つの動作環境という考え方

今回の発表の本質は、新しいモデルが1つ増えたことではありません。「同じモデルを、つながり方の違う3つの環境で動かせる」という設計思想が、大手プラットフォームの標準になった ことです。この3層は、日本の中堅企業がAI導入の可否を判断するときの、そのまま使える分類軸になります。

クラウド型：モデルもデータもクラウド事業者の環境で処理する。導入が速く、スケールしやすいが、データが自社の管理境界の外に出る。
クラウド接続型（ハイブリッド）：自社設備（Azure Localのようなオンプレ機器）でAIを動かしつつ、更新・管理・一部連携でクラウドとつながる。管理は自社寄りだが、接続点が存在する。
完全遮断型（閉域）：外部ネットワークから切り離された自社環境の中だけでAIを動かす。データは一切外に出ないが、更新・運用・監視をすべて自社（または委託先）で完結させる責任が生じる。

多くの経営者は、この3つを「クラウドか、オンプレか」という二択で捉えがちです。しかし実務では、業務やデータの種類ごとに3層を使い分ける のが現実解になります。たとえば、社外公開資料の要約はクラウド型で速く回し、契約書や設計図面、患者情報を扱う処理だけを閉域型に寄せる、という設計です。この使い分けの線引きこそが、AI導入プロジェクトで最初に決めるべきことであり、モデル選定よりはるかに上流の意思決定です。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

クラウド型と閉域型の比較：どちらが「上」ではなく、どの業務にどちらが妥当か

「閉域のほうが安全だから閉域にすべき」という短絡は、多くの場合コスト過剰と運用破綻を招きます。逆に「クラウドが速くて安いからすべてクラウド」も、規制業務では通りません。判断は業務単位で行います。以下は、GXOが導入相談で使っている比較軸です。

横にスクロールして確認できます

比較軸	クラウド型	クラウド接続型（ハイブリッド）	完全遮断型（閉域）
データの管理境界	事業者側に出る	自社寄り・接続点あり	完全に自社内
導入の速さ	速い	中	遅い（設計・調達が重い）
初期コスト	低い	中〜高	高い（GPU等の設備投資）
運用負荷	事業者が吸収	分担	ほぼ全て自社／委託先
モデル更新	自動・随時	半自動	手動・計画的（更新設計が必須）
規制対応（金融・医療・公共）	要個別確認	条件付きで可	適合させやすい
障害時の事業継続	事業者依存	一部自社で継続可	外部障害の影響を受けにくい
向く業務	公開情報の処理、社内問い合わせ、下書き生成	機密度が中程度の基幹連携	機密情報・個人情報・契約・設計・製造・医療データ

この表で強調したいのは、閉域型の「安全」は無料ではない という点です。データが外に出ない代わりに、モデルの更新、脆弱性への対応、ログ監視、利用者教育、障害復旧のすべてを自社側の責任として引き受けることになります。「クラウドに出さない」と決めた瞬間に、運用の重心が自社に移る——ここを見落とすと、導入はできても運用で止まります。データ基盤の設計と運用体制まで含めて考えたい場合は、データ活用基盤の構築支援の観点もあわせて検討してください。

誰が読むべきか

この記事は、次のいずれかに当てはまる経営者・事業責任者・情報システム担当者に向けています。

契約書、図面、原価、人事、患者・顧客の個人情報など、外に出せないデータ を扱っており、生成AIの活用を諦めかけている。
「クラウドAIは情報漏えいが不安」という理由で、社内のAI活用が実験段階から進んでいない。
監査、取引先、業界団体、あるいは官公庁から、データの取り扱いや管理体制の説明 を求められる立場にある。
ベンダーから「オンプレAI」「プライベートLLM」「主権AI」を提案されたが、言われるまま契約してよいか判断できない。
PoC（試験導入）はクラウドで動いたが、本番では機密データを載せられず止まっている。

逆に、扱うデータが公開情報中心で規制も緩い企業は、無理に閉域化する必要はありません。その場合はクラウド型で速く回すのが合理的です。自社がどの層に該当するかを見極めること自体が、この記事から得るべき最初の価値です。

閉域AIを検討する前のチェック軸（発注前の棚卸し）

ベンダーに相談する前に、社内で次の順番で整理しておくと、提案の質と見積もりの妥当性が段違いになります。順番が重要です。上から順に潰してください。

データ分類が終わっているか：全データを一律に「機密」とするのは設計として最悪です。公開可・社内限・機密・要規制の4段階程度に棚卸しし、「本当に閉域が必要なデータ」がどれだけあるかを数量で把握します。閉域化すべきは全体の一部であることがほとんどです。
なぜ外に出せないのかの根拠：法令なのか、契約上の守秘義務なのか、業界慣行なのか、単なる社内の不安なのかを言語化します。根拠が「なんとなく不安」であれば、クラウド型でも要件を満たせる可能性があります。
利用目的とモデルの重さの整合：要約・分類・下書き程度なら軽量モデルで足り、GPU投資を抑えられます。「フロンティアモデルを閉域で」は最も高コストな選択なので、その重さが本当に必要かを問い直します。
更新をどう回すか：閉域モデルは自動更新されません。誰が、どの頻度で、どんな手順でモデルと脆弱性対応を更新するのか。この運用設計がないと、導入直後から陳腐化と脆弱化が始まります。
ログ・権限・監査の設計：誰がどの情報にアクセスし、何を入力・出力したかを追える状態か。閉域にしても、内部からの不適切な利用は防げません。権限設計とログ設計はセキュリティ再構築の観点で別途詰める必要があります。
運用担当の有無：情報システムが0〜1名の体制で、GPUサーバーの運用・監視・障害対応まで自前で背負えるのか。背負えないなら、運用込みで委託できるベンダーを最初から選定条件に入れます。

このチェックを飛ばして「閉域AIを一式ください」とベンダーに投げると、過剰な設備を提案され、運用で行き詰まる のが典型的な失敗です。GXOがAI導入アセスメントで最初に行うのも、この上流の棚卸しです。

経営者が見落としやすい失敗パターン

導入相談の現場でよく見る「判断ミス」を挙げます。自社に当てはまらないか点検してください。

失敗1：閉域＝安全という思い込みで運用を軽視する。ネットワークを切れば安全になると考え、更新・監視・権限・教育の予算を取らない。結果、古く脆弱なモデルを使い続けるか、内部の誤用でデータが漏れる。閉域化は「境界の防御」であって「運用の免除」ではありません。
失敗2：全データを閉域に寄せて費用が跳ねる。データ分類をせず、公開情報の処理までGPUサーバーで動かそうとして初期投資が肥大化する。閉域が必要なのは一部だけ、が原則です。
失敗3：モデルの新しさで選び、運用寿命を考えない。「最新のフロンティアモデルが閉域で動く」という魅力に引っ張られ、更新設計のないまま導入する。半年後には更新されないモデルが社内に取り残される。
失敗4：ベンダーが売れる構成に誘導される。特定クラウドやハードに紐づいた提案を、比較検討なしに受け入れる。ロックインの度合いと乗り換えコストを、契約前に必ず確認する。
失敗5：PoCは動いたが本番で止まる。試験導入をクラウドの緩い条件で通し、本番で機密要件に直面して頓挫する。最初から本番のデータ要件で設計すべきです。

これらはいずれも、技術ではなく判断の順番と体制設計 の問題です。だからこそ、ベンダー選定より前に、第三者の目で構想を点検する価値があります。

ベンダーに必ず聞くべき質問テンプレート

閉域・オンプレAIを提案してきたベンダーには、契約前に次を確認してください。回答が曖昧なら、要件が固まっていないか、売りたい構成が先行しているサインです。見積もりのセカンドオピニオンが必要な局面でもあります。

このモデルの更新は誰が・どの頻度で・どうやって 行うのか。更新費用は見積もりに含まれるか。
完全遮断構成で、脆弱性が公表されたとき、パッチ適用までのプロセスと所要時間 はどうなるか。
提案構成は特定のクラウド・GPU・製品にどの程度ロックインされるか。将来別モデルへ乗り換える際のコストは。
ログ・権限・監査 の機能は標準で付くのか、追加開発か。誰が何を入出力したか追跡できるか。
障害・災害時の事業継続とデータ復旧 の設計はどうなっているか。
運用・監視を委託した場合の月額 と、自社運用に切り替える場合の条件は。
見積もりの内訳で、初期（設備・構築）と継続（運用・更新・保守） はそれぞれいくらか。継続費が過少に見積もられていないか。

最後の質問は特に重要です。閉域AIの見積もりは、初期の設備費に目が行きがちですが、本当のコストは継続の運用・更新費 に潜みます。ここが薄い見積もりは、後から追加費用で膨らむ典型です。

OCR 4（文書処理AI）について一言：帳票処理の自動化は別テーマ

今回Foundryに入る Mistral OCR 4（Mistral Document AI）は、契約書・請求書・帳票といった文書からの情報抽出を担うモデルです。バックオフィスの入力業務を圧縮する用途で関心が高い領域ですが、「閉域で動くフロンティアモデル」という本稿のテーマとは検討の筋が異なります。 文書処理AIの精度検証、既存の会計・基幹システムとの連携、抽出誤りの業務影響といった論点は、それ自体で一本の検討に値します。帳票・文書処理の自動化設計は別途詳しく扱うため、ここでは「同じ提携の中に、機密文書を外に出さずに処理する道筋も含まれている」という事実の指摘にとどめます。