AI主権は「全部自前」ではない——Mistralの30億ユーロ、100万円PC、源内18万人が示す所有範囲

AIを海外企業に任せきりにしないため、「自前のモデル」や「ローカルLLM」が注目されています。ただし、自前という言葉を、モデル開発から半導体、データセンター、業務アプリ、保守まで全部を一社で抱えることだと考えると、導入は急に現実離れします。

2026年9月8日、フランスのMistral AIは30億ユーロを調達したと発表しました。別の国内記事では、約100万円の小型AI計算機が価格比較サイトの注目ランキング首位になったと報じられています。さらに、デジタル庁の生成AI基盤「源内」は、複数のクラウドとモデルを組み合わせながら、約18万人への展開を見据えています。

三つの動きは規模も利用者も違います。それでも共通しているのは、AI主権を「国産か外国産か」「クラウドか手元か」という二択では捉えていない点です。大切なのは、モデル、データ、実行場所、権限、運用手順のうち、どこを自分で選び直せる状態にするかです。

AIモデルの発表日と実際に業務で使える日を分けた記事では、提供、評価、運用、現場の四つの関門を整理しました。今回は、その前提となる「何を自分で持ち、何を外部へ任せるか」を考えます。

結論——主権とは所有量ではなく、選び直せる範囲です

AI主権という言葉からは、巨大モデルを国内だけで訓練し、国内製の計算機だけで動かす姿を想像しがちです。しかし、Mistralの資金調達は、主権を掲げる企業でも国際的な資本、半導体企業、クラウド企業との協力が必要なことを示しています。ローカルLLMは停止耐性とデータ管理の選択肢を増やしますが、計算機を買えば保守や評価が不要になるわけではありません。源内は複数クラウドを使いながら、データ境界と運用の正本を自分たちで管理しています。

日本企業が先に決めるべきなのは、すべてを所有することではありません。少なくとも次の四つを、自社で説明して変更できる状態にすることです。

1. どのモデルを使い、別モデルへ何日で替えられるか
2. どのデータをどの地域と環境へ置き、誰が読めるか
3. クラウド停止時に、ローカル、別クラウド、手作業のどれへ戻るか
4. 設定、権限、配布、停止を、担当者が替わっても再現できるか

主権は、国旗の付いた製品を買うことではありません。外部サービスを使っていても、データの境界、代替経路、変更手順を自分で握っていれば、選択力は残ります。反対に、自社サーバへ置いていても、特定担当者しか更新できず、モデルの出所やライセンスが不明なら、実質的な自由は小さくなります。

Mistralの30億ユーロは「一国で完結しない主権」を映します

TechCrunchによると、Mistral AIは30億ユーロ、約35億8000万ドルのシリーズDを実施し、調達後評価額は210億ユーロ超になりました。同社は欧州の技術企業による過去最大の株式調達だと説明しています。資金は計算能力の拡大、インフラ構築、商用展開、国際展開へ使う計画です。

主導したのは韓国のSamsung Electronicsです。欧州系ファンドや既存投資家だけでなく、米国の投資家も参加しています。Mistralは欧州のAI主権を象徴する企業ですが、その資本表は一国や一地域だけで閉じていません。これは矛盾ではなく、巨大な計算資源を必要とするAI産業の現実です。

Mistralは2030年までに欧州で1GWの計算能力を構築する方針を掲げ、利用者がAI問い合わせの処理地域を選べる仕組みも発表しています。さらに、自社モデルだけでなく、第三者のオープンウェイトモデルを扱っています。主権の中心を「自社モデルだけを使わせること」ではなく、「顧客がモデルと処理地域を選べること」へ置いていると読めます。

ここは日本企業にとって重要です。国産モデルを採用することには、日本語、国内商慣習、法制度、調達、相談窓口の面で意味があります。しかし、国産モデル一つへ全面固定することと、主権を得ることは同じではありません。供給停止、価格改定、性能差、対応機能、計算資源不足は、国内企業にも起こり得ます。

調達時には、モデルの国籍だけでなく、処理地域、学習利用の有無、ログ保持、暗号鍵、契約終了時のデータ返却、モデル切り替え、出力形式、評価結果の持ち出しを見ます。国内外の複数事業者を組み合わせながら、自社が切り替え条件を持つ方が、単一の「国産」へ依存するより強い場合があります。

100万円級ローカルLLM機は「出口」を買う道具です

ITmedia AI＋は、NVIDIAの小型AI計算機「DGX Spark」が、2026年9月8日時点で価格.comのデスクトップPC注目ランキング首位になり、掲載価格が113万円だったと報じました。一般的な家庭用PCとは大きく異なる価格ですが、クラウドAIが止まる可能性や、オープンウェイトモデルの進化を背景に、ローカルLLMへの関心が高まっています。

ローカルLLMの分かりやすい利点は、一度取得したモデルと実行環境を手元に残せることです。クラウド側の障害、アカウント停止、提供地域の変更、契約終了が起きても、手元の処理経路まで同時に消えるとは限りません。機密文書を外へ送らずに要約や検索を行う構成も作れます。通信できない現場で使える可能性もあります。

ただし、100万円の機器を買うことは、AI主権の完成ではなく、ひとつの出口を買うことです。モデルの取得元、改ざん確認、ライセンス、更新、脆弱性対応、電力、冷却、保存容量、バックアップ、故障時の交換を誰かが担います。クラウド費用が見えなくなっても、社内の運用時間と設備費は残ります。

ローカル実行が向く業務は、次の三条件で考えると分かりやすいです。

• 外部送信を避けたいデータが継続的にあります
• 応答速度より、停止耐性や処理場所の固定を優先します
• モデルと機器を更新できる担当者、予算、手順があります

反対に、利用量が少なく、必要なモデルが毎月変わり、保守担当がいない場合は、クラウドの方が総費用を抑えやすいです。高性能機を買っても、評価データがなく、業務アプリへ接続できず、担当者の端末で試すだけなら、設備が新しい孤島になります。

推論時のGPUだけでなくメモリ配置とデータ移動を考えた記事でも整理したように、AIの性能は計算機の型番だけでは決まりません。頻繁に使うデータをどこへ置くか、どれだけ移動させるか、障害後に何分で戻せるかが、業務の体感を左右します。

源内はマルチクラウドでも境界を自分で持っています

デジタル庁の生成AI基盤「源内」は、2025年5月に庁内で利用を開始し、2026年度中に全府省庁の約18万人が利用可能になることを見据えた大規模実証へ進んでいます。中核はAWS上にありますが、呼び出すモデルや連携先をAWSだけへ固定せず、Google CloudやMicrosoft Azureも併用する構成です。

ここで注目したいのは、複数クラウドを使うこと自体ではありません。源内は、どこを共通化し、どこを分離し、どの変更を正本から配るかを設計しています。モデルを替えられるだけでは、運用の主権にならないからです。

源内では、省庁ごとに環境を分けるサイロモデルを採用しています。効率だけを考えれば共通基盤へ相乗りさせる方が簡単ですが、行政データの混在を避けるために分離を優先しました。利用者の認証情報から、その人のデータだけへ触れられる一時的な鍵を渡し、外部通信は許可されたドメインへ限定します。さらに、組織外のクラウドアカウントへデータを送れない境界も設けています。

この設計は、AIへ「してはいけない」と文章で頼むだけではありません。仮にAIエージェントが外部の指示へだまされても、権限とネットワークの壁によって実行できない状態を作ります。AIの判断力に安全を丸投げせず、基盤側で行動半径を制限しています。

ログについても、書き込み保護を使って改ざんしにくい形で保管し、分析へ回します。モデルが出した回答だけでなく、誰が何を実行し、どこへ接続し、どの費用が発生したかを追えるようにします。主権は自由に使えることだけでなく、誤りが起きたときに止め、調べ、戻せることを含みます。

18万人を1〜2人で支える鍵は「全部を宣言にする」ことです

ITmedia エンタープライズの記事では、源内のインフラ専任エンジニアは1〜2人で、40以上のテナントを運用しながら新機能も開発していると紹介されています。人数だけを見ると危うく感じますが、少人数で回すために、環境変更を手作業から宣言的な管理へ移しています。

管理者は、望ましい設定をYAML形式の指示書へ書き、GitHubへ登録します。管理側の仕組みは、その指示を構成の正本へ反映し、現在の状態との差だけを配布します。40のテナントへ20のアプリを手作業で配れば800回の操作が必要ですが、源内では一つの指示書から自動配布できます。新しいテナントも約30行の指示書で立ち上げられるとされています。

これは単なる省力化ではありません。変更理由と望ましい状態を、人の記憶ではなく再現可能な記録へ移すことです。担当者が交代しても、どの設定を、どのテナントへ、いつ配ったかを追えます。問題が起きれば、差分を確認し、前の状態へ戻す入口ができます。

日本企業がマルチクラウドやローカルLLMを導入するとき、最も見落としやすいのがこの運用層です。入口を二つに増やしても、設定表が担当者のExcelへ分散し、権限変更を手で行い、モデルごとに別のログ形式を使えば、切り替えのたびに混乱します。選択肢が増えたのに、運用できる人が一人しかいなければ、主権ではなく属人化が増えます。

必要なのは、利用モデル、処理地域、データ分類、権限、費用上限、停止条件を、機械が読める設定と人が読める説明へそろえることです。すべてを源内と同じ規模で作る必要はありません。小さな会社でも、設定ファイル、変更履歴、評価セット、障害時手順を一つの場所へ集めるだけで、選び直せる範囲は広がります。

データセンターの排熱は「設備を持つ責任」を可視化します

AI基盤を自前で持つ議論では、電力や冷却が抽象的な数字になりがちです。ITmedia NEWSがデータセンター技術者へ聞いた記事は、排熱を温泉へ使う案が簡単ではない理由を、温度、立地、セキュリティの三点から説明しています。

一般的なサーバー排熱は30〜40度程度で、日本で好まれる40度以上の湯へそのまま使えるとは限りません。ヒートポンプや配管を追加すれば、設備費と光熱費が必要です。データセンターは大容量受電、通信、災害耐性、不動産費を重視しますが、温浴施設は人が訪れやすい場所を求めます。熱は遠くへ運ぶほど損失と配管費が増えるため、両方の立地条件を合わせるのも難しくなります。

さらに、不特定多数が訪れる施設を隣接させれば、物理入館とネットワークの安全対策が増えます。熱を再利用できるという良い物語だけでは、設備全体の採算と危険を説明できません。

この話は、企業内のローカルLLMにも縮小して当てはまります。計算機の購入額だけでなく、設置場所、電源、空調、騒音、保守、廃棄、災害時の復旧を持つことになります。「クラウドから離れれば費用とリスクが消える」のではなく、外部へ払っていた費用と責任の一部が、自社の設備と人へ移ります。

日本企業は業務ごとに四つの所有範囲を決めます

全社で一つの答えを決めるより、業務ごとに所有範囲を分ける方が現実的です。公開情報の要約、顧客データの検索、製造現場の制御、災害時の行政案内では、必要な速度、秘密性、停止耐性、責任が違います。

所有範囲	自社で握るもの	外部へ任せられるもの	向く場面
利用型	アカウント、入力規則、出力確認、終了手順	モデル、計算、更新、基盤	公開情報中心の低リスク業務
可搬型	評価セット、共通API、ログ形式、代替モデル	複数事業者のモデルと計算	モデル変更が多い一般業務
データ固定型	データ、暗号鍵、検索索引、権限、監査ログ	モデルまたは一部計算	顧客・社内文書の検索と要約
実行固定型	モデル、計算機、データ、ネットワーク、更新手順	部品供給や一部保守	通信困難、機密性、停止耐性を重視する現場

多くの企業は、すべてを実行固定型にする必要がありません。公開情報の下書きは利用型、社内検索はデータ固定型、工場の非常時手順は実行固定型というように分けられます。分類があれば、高価な計算機を買う業務と、クラウドの更新速度を使う業務を同じ議論へ押し込まずに済みます。

重要なのは、外部へ任せる欄を曖昧にしないことです。外部へ任せることは、責任をなくすことではありません。契約終了、障害、価格改定、仕様変更が起きたとき、何を受け取り、何日で移り、誰が利用者へ知らせるかを決めます。

30日で「選び直せるAI」へ変える手順

最初の一週間——AIの置き場所を一枚へ集めます

利用中のAIを、業務、利用者、モデル、処理地域、入力データ、管理者、月額費用、停止時の影響で一覧化します。個人契約や試用サービスも含めます。最初から完璧な台帳を作るより、重要業務で使っているのに管理者が不明な入口を見つけることを優先します。

各業務へ、利用型、可搬型、データ固定型、実行固定型のどれが必要かを仮置きします。秘密性が高いから即ローカルと決めず、データを匿名化できるか、保存しない契約を選べるか、国内リージョンへ固定できるかも比較します。

二週目——代替先より先に、受け入れ条件を作ります

現在のモデルで扱う代表課題を十件選び、正しさ、根拠、禁止事項、所要時間、費用、人の確認時間を記録します。正常な入力だけでなく、欠損文書、古い規程、似た商品名、権限外の依頼も含めます。

代替モデルを探す前に、この十件へ合格できる条件を決めます。評価条件がなければ、別のモデルへ替えられても、業務へ戻せるか判断できません。可搬性とはAPIを差し替えられることではなく、同じ完了条件で再評価できることです。

三週目——一つだけ縮退訓練を行います

重要業務を一つ選び、主なクラウドAIを使えない状態にします。別モデル、ローカル小型モデル、読み取り専用、従来検索、人の手作業の順に、どこまで業務を続けられるかを試します。

測るのは、最高性能ではありません。停止を知るまでの時間、代替へ移る時間、守れた業務の割合、利用者へ知らせる時間、復旧後に差分を戻す時間です。ローカル機器があるなら、起動、モデル更新、権限、バックアップから実際に使えるかを確認します。

四週目——変更を一つの宣言へします

利用モデル、処理地域、データ分類、権限、費用上限、停止条件を、一枚の変更票へまとめます。可能な設定はコードや構成ファイルへ移し、レビュー後に配布します。手作業が残る場合も、誰がどの画面で何を変更し、どの証跡を保存するかを固定します。

経営会議では、国産比率やローカル台数だけを成果にしません。モデル変更に必要な日数、データ移行に必要な時間、属人設定の件数、代替経路で守れた業務の割合、復旧時間を追います。数字が改善すれば、外部サービスを使っていても主権は強くなっています。

導入前に答える十二の質問

1. この業務で守りたいのは、秘密性、停止耐性、速度、価格、法令のどれですか。
2. モデル名と版を記録し、変更時に同じ評価を再実行できますか。
3. 入力、ログ、検索索引、生成物は、どの地域へ保存されますか。
4. 暗号鍵と削除権限を誰が持っていますか。
5. 学習や品質改善へ利用される範囲を説明できますか。
6. 主サービス停止時に、何へ何分で戻りますか。
7. ローカル機器の更新、冷却、故障、バックアップを誰が担当しますか。
8. 外部モデルを替えても、業務アプリとログを使い続けられますか。
9. AIエージェントが触れられる利用者、ネットワーク、クラウドアカウントを物理的に制限していますか。
10. 設定の正本と変更履歴は、個人端末ではなく共有管理されていますか。
11. 担当者が休んだ日に、別の人が停止と復旧を再現できますか。
12. 契約終了時に、データ、評価結果、ログ、設定の何を持ち出せますか。

十二問すべてへ一度に答えられなくても構いません。答えられない項目を、次の調達と訓練の順番へ変えることが大切です。高価なモデルや機器を選ぶ前に、選び直すための情報と手順を持っているかを確かめます。

主な出典

• TechCrunch「Mistral raises €3B as sovereign AI becomes big business」
• ITmedia AI＋「100万円のPCが注目ランキング1位に？　ローカルLLMブームを生んだ『3つの条件』」
• ITmedia エンタープライズ「行政機関18万人を支える『源内』」
• ITmedia NEWS「データセンターの排熱で温泉を作ろうが難しい3つの理由」

結論——次に買うものより、次に替えられるものを決めます

Mistralの30億ユーロ調達は、AI主権を掲げる企業でも、国際資本と複数地域の技術を組み合わせる必要があることを示しました。100万円級のローカルLLM機への関心は、クラウド以外の出口を持ちたい需要を映します。源内は、複数クラウドと複数モデルを使いながら、データ境界、権限、変更の正本を自分たちで握る実装例です。データセンターの排熱問題は、設備を持てば電力、冷却、立地、安全まで責任が広がることを教えます。

したがって、日本企業に必要なのは「全部自前」という合言葉ではありません。業務ごとに、モデル、データ、実行場所、運用手順のどこを握り、どこを信頼できる相手へ任せ、どの条件で切り替えるかを決めることです。

次のAI予算を決める会議で、「何を買うか」だけでなく、「それが明日使えなくなったら、何を残してどこへ移るか」を一枚に書けるでしょうか。答えを書ける組織は、クラウドを使っていても選択権を持てます。答えを書けない組織は、どれだけ高価な自前設備を持っていても、自由を一人の担当者と一台の機械へ閉じ込めてしまいます。AI主権の最初の一歩は、所有物を増やすことではなく、選び直せる境界を今日決めることです。