ソブリン AI のラストワンマイル：モデルの自社運用だけで終わらせないために

**ソブリン AI（Sovereign AI／主権 AI）**の議論は、多くの場合モデルの話で始まり、モデルの話で終わります。GPU を調達し、DeepSeek、Qwen、Llama などのオープンウェイトモデルを自社の閉域網やプライベート VPC にデプロイし、それで「AI の主権を確保した」とみなすアプローチです。

しかし半年ほど運用すると、多くの現場が見えない壁に突き当たります。モデルは確かにファイアウォールの内側で動いているのに、業務が一向に前に進まないのです。

社員は相変わらず顧客情報の断片を個人のチャット画面に貼り付け、エージェントはセッションのたびにゼロから会話を始め、業務手順（SOP）は特定のエンジニアのプロンプトファイルや外部クラウドの SaaS ドキュメントに散在したままになります。さらに、エージェントに本番データベースへの直接書き込みを許可しようとすれば、セキュリティ部門が即座にストップをかけます。エージェントがいつ、どの重要レコードを上書きしたのか、誰がその変更を承認したのかを証明できないからです。

これがソブリン AI における「ラストワンマイル」の課題です。MIT の NANDA イニシアチブが発表したレポートでは、企業の生成 AI パイロットの約 95% が明確な収益効果を生んでいないと報告されています。原因はモデルの性能不足ではなく、学習とコンテキストの断絶にあります。汎用ツールは企業固有の業務手順を蓄積できず、エージェントの成果をガバナンスの効いた組織資産へと変えられないのです。

モデルの重み（ウェイト）を自社で持つだけでは、**推論の主権（Inference Sovereignty）**しか得られません。AI を現場で機能する持続的な業務基盤にするには、ワークスペースの主権（Workspace Sovereignty）——すなわち構造化データ、再利用可能なスキル、実行境界、そして「何を正式な事実とするか」を決める人間の最終承認権を自社の管理下に置くことが不可欠です。

なぜ「モデルだけの自社運用」は本番環境で失速するのか

大規模言語モデル（LLM）は本来ステートレス（状態を持たない仕組み）です。トークンを受け取り、トークンを返し、そして忘れます。顧客台帳、プロジェクトの経緯、標準業務手順（SOP）、承認ステータスといった、エージェントを時間とともに賢く実用的にする要素はすべて、モデルの外側に存在します。

プライベートな推論環境だけに投資し、エージェントが働くための主権型ワークスペースを用意しない場合、次の 4 つのボトルネックがすぐに表面化します。

モデルが自社のデータセンターにあっても、業務知識が外部ベンダーのメモリ機能に閉じ込められていたり、データ破損のリスクからエージェントに書き込みを禁じていたりするなら、それはソブリン AI ではありません。「社内専用のチャットボット」にすぎないのです。

ラストワンマイルを埋めるには、エージェントと人間が実際に協働するワークスペースの層まで主権を広げる必要があります。

主権の柱 1：モデルからの独立——エージェントをステートレスにし、スキルをワークスペースに置く

真の主権とは、特定のモデルやツールにロックインされない自由を意味します。2026 年現在、モデルの首位は数か月ごとに入れ替わり、用途によって最適なエージェントも異なります。機密データの処理には社内 LLM、ソフトウェア開発には Claude Code や Codex、エディタ内では Cursor や OpenCode、あるいは社内サーバー上の DeepSeek ハーネスを使い分けるのが現実的です。

もしエージェントごとに記憶と手順を持たせてしまえば、モデルを入れ替えるたびに組織の記憶がリセットされてしまいます。『AI をチームで機能させるには』で詳しく述べたとおり、解決策は明快です。エージェントをステートレスにし、記憶と手順はチームに持たせるのです。

Busabase では、この原則がアーキテクチャとして組み込まれています。

• 型付き Bases と Docs：すべてのエージェントが作業前に参照する構造化データと背景ドキュメントを保持します。
• Playbooks（SKILL.md とカスタムプロンプト）：ワークスペース内の第一級ノードとして管理されます。接続されたどのエージェントも、タスクを始める際はまず Playbooks カタログを検索し、チームの標準手順に従います。
• AirApps（ワークスペース内アプリ）：ワークスペースの生きたデータ上で直接動く業務 UI（CRM、レビュー画面、進捗ボードなど）を提供し、人間が迷わず確認・操作できるようにします。
• オープンな接続プロトコル（MCP・OpenAPI・CLI・Agent Skill）：特定の内蔵モデルを強制しません。MCP 対応クライアントでも /api/v1 の REST API 経由でも、まったく同じ契約で読み書きできます。

社内の基盤モデルを次世代モデルへ更新しても、エンジニアが別のコーディングエージェントに乗り換えても、業務ロジックを書き直す必要はありません。新しいエージェントは同じ SKILL.md を読み、同じ Base を参照し、前のエージェントが止まった場所から作業を引き継ぎます。

主権の柱 2：物理境界と運用の主権——ローカル PC から完全オフライン環境まで

データ主権は、デプロイできる物理的な境界によって決まります。外部ベンダーの管理プレーンへ常時通信しなければ動かないワークスペースは、インターネットから隔離された研究施設、厳格な金融ネットワーク、オフライン環境では使えません。

Busabase は単一のオープンコアエンジン（busabase-core）で構築されており、API やデータモデルを一切変えることなく、あらゆる主権レベルで稼働します。

特に厳格なセルフホストおよびオフライン環境において、運用上の自立性を支えるのは次の 3 つの設計です。

1. 外部通信ゼロ（Zero Phone-Home）：Busabase は起動時も運用時も、外部サーバーへ通信（「里帰り通信」）を行いません。オンライン端末で約 489 MB のオールインワンイメージを docker save で tar ファイル化し、SHA-256 ハッシュを検証して閉域網へ持ち込み、docker load するだけで、一度もインターネットに触れたことのないサーバー上でそのまま稼働します。
2. 公開鍵によるオフラインライセンス検証：商用セルフホスト版のアクティベーションは、外部 API へのリクエストではなく、署名付きライセンスキーの「貼り付け」で完結します。ビルドに組み込まれた公開鍵を使ってローカルで署名検証を行うため、パケットは 1 つも外へ出ません。
3. 期限切れ時は読み取り専用へ移行（データロックアウトなし）：主権とは、ベンダーの課金システムにデータを人質に取られないことでもあります。万一ライセンスが期限切れになっても、インスタンスは安全に読み取り専用モードへ切り替わるだけで、全レコード、ドキュメント、スキル、エクスポート機能には引き続きアクセスできます。

主権の柱 3：ガバナンスと説明責任の主権——「何を正とするか」を人間が決める

2026 年のエンタープライズ AI ガバナンスにおいて、監査人や事業責任者が問う最も重い質問は「データベースがどのサーバーにあるか」ではありません。EU AI 法、GDPR 第 30 条、金融リスク管理基準のもとで問われるのは、**「自律型エージェントがこの業務レコードを書き換えたとき、誰が承認し、どんな根拠があり、変更前後の差分を証明できるか？」**という一点です。

従来のアクセス制御は「書き込み権限（Permission）があるか」しか見ません。しかし『エージェントの書き込みに権威を持たせるには』で論じたとおり、書き込めることと、その内容が正しいことは別問題です。書き込み権限を持つエージェントでも、ハルシネーションによって契約更新日を誤記したり、コンプライアンス状態を上書きしたりするリスクは常につきまといます。

Busabase は書き込みの境界そのものにガバナンスの主権を組み込んでいます。

エージェントがワークスペースのコンテキストと Playbooks を読み取る
        ↓
エージェントが変更を提案 → Change Request として着弾（説明＋フィールド単位の差分＋作成者）
        ↓
権限ポリシーで分岐：信頼された軽微な更新は即時マージ、重要な変更は Inbox で人間の承認待ちへ
        ↓
人間がレビューして承認 → 正本（Canonical）レコードへマージされ、改ざん不能なコミット履歴が残る

• リスクに応じた段階的コントロール：日常的な低リスク更新は write 権限で即座にマージしつつ、裏側ですべてのコミット差分を記録します。一方、契約条件の変更、公開ページの更新、共有スキルの書き換えなど重要な書き込みには、changeRequest 権限または autoMerge: false を適用し、責任者がフィールド単位の差分（Diff）を確認してワンクリックで承認するまで Inbox に留め置くことができます。
• 検証可能な来歴（Provenance）：すべての正本レコードには、どのエージェントが提案し、どのフィールドがどう変わり、誰が承認してマージしたかという完全な監査証跡が残ります。生ログを grep することなく、レコードの履歴タブを開くだけで監査の問いに即答できます。

これこそが、単なるデータベースをAI エージェントのためのシステム・オブ・レコード（System of Record for AI Agents）へと変える仕組みです。エージェントを締め出すのではなく、「エージェントの提案」と「組織の公式な事実」のあいだにレビュー可能な境界を設けることで、安全性とスピードを両立させます。

ソブリン AI 導入チームのための 4 つの点検リスト

社内の AI アーキテクチャを承認・本番展開する前に、次の 4 つの問いで検証してみてください。

• 来期、主力 LLM を別のモデルに入れ替えたら、どれだけの手順を作り直すことになるか？ プロンプトや業務ルール、コンテキストが特定ベンダーの専用画面に閉じ込められているなら、移行コストは甚大です。
• チャットが終わったあと、エージェントの成果物はどこに残るか？ 「チャット履歴の中」や「人間がコピペして別ツールに移す」状態なら、エージェントの働きは組織の資産になっていません。
• 外向けの LAN ケーブルを抜いた状態でも、ワークスペースとライセンス認証はそのまま動くか？ 閉域サブネットやオフライン環境で、外部通信なしに業務が回るかを確認してください。
• 半年後の監査で、あるレコードの変更を「どのエージェントが提案し、誰が承認したか」証明できるか？ 重要な変更すべてにフィールド単位の差分と承認履歴が残る仕組みが必要です。

自社のマシンから始める

Busabase は AI エージェントのためのオープンソースのデータベース＆ワークスペースです。エージェントと人が同じ構造化データ、ドキュメント、スキル、アプリを共有し、重要な書き込みはレビューを経て信頼できるレコードになります。

手元のマシンで 1 分もかからずに、ソブリン AI のワークフロー全体を試すことができます。

npx busabase server

組織のセキュリティ境界に合わせて、最適な導入パスを選べます。

• 個人・完全オフライン利用：Busabase Desktop をダウンロードするか、MIT オープンソース版をローカルで起動。
• 社内セルフホスト・閉域網導入：セルフホスト概要およびオフラインインストール手順を参照。
• 複数チームのクラウド協働：Busabase Cloud を無料で始める（必要に応じてローカルインスタンスをトンネル接続可能）。