「プライベートAI」は、「SaaSアカウントで学習をオフにした」状態から「自社インフラでオープンウェイトモデルを動かしている」状態まで、あらゆる意味で使われます。これらは同じ統制境界ではありません。
中小企業にとって適切なプライベートAIのアーキテクチャは、データ、タスク、品質要件、チームがインフラを運用できる能力によって決まります。最もプライベートな選択肢が、常に最善とは限りません。最も高機能な選択肢が、そのデータに対して常に許容されるとは限りません。継続的なエンジニアリング対応が必要なら、最も安い選択肢が高くつくこともあります。
この記事は判断のための地図です。GDPRの原文、NIST AIリスクマネジメントフレームワーク、ベンダー契約とデータ統制の資料、選んだサービングエンジンのセキュリティガイダンス（例：vLLMのセキュリティ）と組み合わせて使ってください。
モデルの好みではなく、情報分類から始めてください。適切なプライバシー境界内の弱いモデルの方が、受け取るべきでないデータを与えられた最先端モデルより適切です。
5つの導入パターン
| パターン | 内容 | 候補となる用途 | 主な制限 |
|---|---|---|---|
| 法人向けSaaS | 管理者機能、SSO、保持、学習のオプトアウトを備えた法人プラン | 通常の社内業務の大部分 | データは自社環境の外へ出る |
| VPCまたはプライベートクラウド | 制御されたクラウド境界内のマネージドモデルエンドポイント | より強い分離が必要な機密ワークロード | コストとセットアップの負担が大きい |
| 自社運用推論 | 自社インフラでオープンモデルを実行する | 要配慮情報、カスタムモデル、規模の経済 | 運用負荷 |
| ローカルデバイスモデル | ノートPC、ワークステーション、エッジデバイスでモデルを実行する | オフライン、機微、低レイテンシーの狭いタスク | モデルが小さく、デバイスの制約がある |
| ハイブリッドルーティング | ユースケースごとに合う境界へ振り分ける | 機微性が混在する業務群 | 分類の規律が必要 |
個人向けの消費者アカウントでは通常、組織が一元的にガバナンスするID、保持、コネクタ、契約、監査の設定は提供されません。社内方針で、利用自体を認めるか、認める場合はどのデータまでかを定める必要があります。
組織には、1つのパターンで足りる場合も、ガバナンスされた複数方式の組み合わせが必要な場合もあります。目的は、承認済みユースケースごとに境界を選び、再検証することです。1つの製品名を永続的な保証として扱ってはいけません。
まずデータを分類する
以下の4区分は、出発点となる分類例です。名称と取扱規則は、組織の実際の情報分類と法的要件に合わせてください。
| データ | 例 | AI利用の既定境界 |
|---|---|---|
| 公開 | ウェブサイトの文章、公開文書、公開研究 | 権利、真正性、プロンプトインジェクション、利用規約を確認したうえで承認したツール |
| 社内 | 業務メモ、匿名化した例、機微でない下書き | 法人向けSaaS |
| 機密 | 顧客データ、契約書、ソースコード、財務情報、戦略 | 統制付きの法人向けSaaS、VPC、または自社運用 |
| 要配慮情報 | 健康データ、法的な秘匿特権、人事調査、規制対象記録 | 法務・セキュリティのレビュー。承認済みのローカル、VPC、自社運用、またはAIを使わない経路が必要になる場合がある |
この分類は、便利だからという理由で、公開ブログの下書きと機密の顧客レコードに同じアシスタントを使う、よくある誤りを防ぎます。
認証情報、秘密鍵、認証トークン、リカバリーコードは、モデルへ振り分けるデータ区分ではありません。プロンプト、検索コーパス、テレメトリ、モデルが使えるツールから除外してください。決定論的な連携で認証情報が必要な場合は、シークレットマネージャーと、適用範囲を狭くした実行時の注入を使います。
パターン1：法人向けSaaSを既定にする
法人向けSaaSは、運用上の複雑さが最も低い候補になる場合があります。製品名、プランで使える機能、契約条件は変わります。候補にしたプランごとに次を確認してください。
- データ使用とモデル学習に関する契約条項。
- 管理者コントロール。
- SSOとアクセス管理。
- 保持のコントロール。
- 監査ログ。
- セキュリティドキュメント。
- ベンダーサポート。
これらの統制は承認済み業務を支え得ますが、プランを購入しただけでは、特定のデータ区分やワークフローが適法または安全だと証明できません。
重要なのは設定です。チームプランを買うだけでは足りません。保持、共有、コネクタへのアクセス、承認済みワークスペース、データ規則を設定してください。
パターン2：VPCまたはプライベートクラウド
VPC／プライベートクラウドのパターンは、データがアプリケーションの外へ出ても、定義されたクラウドと契約上の境界内に留める必要がある場合の候補です。「VPC内」では、コントロールプレーン、モデルサービス、ログ、サポート、バックアップのすべての経路がその中に留まると証明できません。データフロー全体を図示し、テストしてください。
- 機密チケットを扱うカスタマーサポートアシスタント。
- 機微な文書を扱う社内ナレッジアシスタント。
- 契約書または請求書の文書抽出。
- SaaSより強いデータ分離が必要な、ドメイン固有のアシスタント。
検証すべき、起こり得る利点は次のとおりです。
- 選んだサービス設計のもとでの、より強い分離。
- ネットワーキングとログに対する、より大きな制御。
- 定義された調達要件を満たし得る証拠。
- 完全な自社運用とは異なる運用分担。
費用を見積もり、テストすべき制約は次のとおりです。
- 実測したワークロードでは、共有SaaSプランより高くなる場合がある。
- 追加の統合とプラットフォーム作業。
- モデルの選択肢が狭くなる場合がある。
- プロバイダーのインフラには、依然として依存する。
すべての中小企業の既定ではなく、中間に位置する候補の一つとして扱ってください。
パターン3：自社運用推論
自社運用とは、モデルランタイムを自ら動かすことです。vLLM、TGI、SGLang、llama.cpp、Ollama、または別のサービングスタックです。次の場合に合理的です。
- データを自社環境の外へ出せない場合。
- カスタムまたはファインチューニングしたオープンモデルが必要な場合。
- 推論量が、インフラを正当化できるほど多い場合。
- レイテンシーや可用性の要件に対して、直接の制御が必要な場合。
- 運用できる人材がいる場合。
純粋に感じるからという理由だけで自社運用してはいけません。運用コストは現実です。GPU容量、監視、更新、セキュリティパッチ、モデル評価、スケーリング、インシデント対応がかかります。
自社運用は、適した組織にとっては有力な選択肢です。MLインフラの経験がない小規模チームでは、壊れやすいサイドプロジェクトになり得ます。
パターン4：ローカルデバイスモデル
ローカルモデルは、デバイス全体、更新、テレメトリ、バックアップ、アクセスの境界を統制できる場合に、プライバシー上機微な個人作業の候補になります。
- ローカルのメモの要約。
- 非公開文書からの下書き。
- 社内スニペットの分類。
- オフラインの現場作業。
- レイテンシーが重要なエッジワークフロー。
品質のトレードオフは、タスクとモデルによって異なります。同等とも劣るとも決めつけず、代表的な要約、分類、抽出、下書きのタスクでローカル候補を評価してください。
タスク評価を満たし、ローカル環境全体の境界が承認されている場合に限って、ローカルモデルを使ってください。「デバイス上で動く」だけでは、プライバシーは証明されません。
パターン5：ハイブリッドルーティング
ハイブリッドの候補は、承認済みのデータ区分に応じてワークロードを振り分けられます。
- 公開で低リスクのタスクは法人向けSaaSへ送る。
- 機密情報の検索は、プライベートな検索拡張生成（RAG）システム内で行う。
- 要配慮情報の抽出は、データフロー全体のレビュー後、特に承認されたローカル、VPC、自社運用、またはAIを使わない経路だけで行う。
- 機微な項目を除いた後、最終的な下書きに最先端モデルを使う場合がある。
- ログと評価によって、各経路が機能しているかを判断する。
ハイブリッドルーティングは、レコードごとに異なる承認済み境界を割り当てられます。プロンプトだけの分類ではなく、強制可能なポリシーが必要です。
- ルーティング前の情報分類。
- 可能な場合の墨消し。
- 明確なモデル／ツールの許可リスト。
- どの境界を使ったかを記録するログ。
- プライベートモデルがタスクを実行できない場合のフォールバック。
意思決定フレームワーク
次の6つの質問をしてください。
- どのデータがモデルに入るか？ 公開、社内、機密、要配慮情報。
- 出力が及ぼす影響は何か？ 下書き、推奨、判断、顧客向けアクション。
- 必要な品質は何か？ 「専門家レベル」といったラベルではなく、タスク固有の精度、安全性、レイテンシー、拒否、人による確認の目標を定める。
- 必要なレイテンシーは何か？ 対話型、バッチ、リアルタイム、オフライン。
- どのような運用能力があるか？ インフラチームなし、アプリチーム、プラットフォームチーム、ML運用。
- 顧客や規制当局が求める証拠は何か？ ベンダー資料、ログ、データ所在地、監査証跡、分離。
そのうえで、データと品質の要件を満たすパターンのうち、複雑さが最も低いものを選んでください。
現時点で行わないこと
ワークロードと品質要件を測る前に自社運用してはいけません。
個人向けツールへ要配慮情報を送ってはいけません。
「オープンソース」だからプライベートだと決めつけてはいけません。導入、ログ、アクセス、データフローがプライベートな場合に限り、プライベートです。
IDを認識し、ポリシーで強制する情報分類と、既定で拒否する経路がなければ、AIゲートウェイを導入してはいけません。集中型ゲートウェイはポリシーを強制できますが、迂回、フォールバック、ログ、障害時の動作をテストした場合に限ります。
評価を無視してはいけません。プライベートでも、誤っていれば誤りです。
実用的な中小企業の出発点
以下は、レビューを前提とした、中小企業向けの導入手順の一例です。
- 一般業務用の法人向けSaaSアシスタントを1つ承認する。
- 情報分類ルールを書く。
- レビューを受けていない要配慮情報を遮断する。
- 最も価値のある機密ユースケース向けに、プライベートなRAGまたはVPCワークフローを1つ構築する。
- 品質が許容できる、範囲の狭い機微なタスクにローカルモデルを使う。
- プライバシー、カスタマイズ、またはコストが明確に正当化する場合にだけ、自社運用を再検討する。
これにより、段階的な判断経路ができます。設計およびデフォルトによるデータ保護には、目的、最小化、アクセス、保持、削除、処理者、移転、セキュリティの判断を文書化することが、なお必要です（欧州委員会のガイダンス）。
データ、リスク、運用に合わせたアーキテクチャ
プライベートAIとは、データ、リスク、運用に合わせたアーキテクチャです。複数方式の組み合わせが適切な場合もありますが、すべての経路に明示的な責任者と、検証済みの境界が必要です。
データ、影響、品質、レイテンシー、運用、証拠に基づいて選んでください。
