「機密資料があるからローカルAIにする」。
一見すると安全な判断ですが、保管端末が暗号化されていない、退職者の権限が残る、モデル更新を誰も行わない、バックアップが同じ部屋にしかないなら、データを社外へ出さないことだけで安全とは言えません。
一方、クラウドへ送るから危険とも限りません。
法人向けのAIサービスには、組織データを既定でモデル学習へ使わない契約、保持期間の制御、専用ネットワーク、顧客管理の暗号鍵などが用意されています。
ただし、同じ会社の製品でも個人向けチャットと法人契約、API、クラウド経由では条件が違います。
選択肢は三つです。
共有型のクラウドAI、クラウド上でネットワークやデータ境界を絞る専用クラウド、社内端末やサーバーで動かすローカルAI。
どれか一つが常に正しいのではなく、扱う情報、利用量、必要性能、担当者、復旧条件によって最適な組み合わせが変わります。
共有型クラウドAIは、提供会社がモデルと基盤を運用し、多数の顧客が論理的に分離されたサービスを使います。
常に高性能なモデルを利用しやすく、初期設備が少なく、外部サービスとの連携も豊富です。
その反面、データ処理地域、保持、ログ、機能ごとの保存を契約と設定から確認する必要があります。
専用クラウドは、VPC、Private Endpoint、専用テナント、顧客管理鍵などを使い、通信やアクセスの境界を狭める方式です。
完全なオンプレミスと同義ではありません。
MicrosoftはAzure上のModels sold by Azureについて、顧客データやプロンプトを基盤モデルの学習へ無断利用せず、Private Endpointで仮想ネットワーク内の接続を構成できると説明しています。
ローカルAIは、PC、ワークステーション、社内サーバーでオープンウェイトなどのモデルを動かします。
入力を外部サービスへ送らず処理できる一方、モデル、実行ソフト、OS、ドライバー、アクセス権、ログ、バックアップを利用者側が管理します。
導入しただけで更新や脆弱性対応が終わるわけではありません。
実務では混合構成も有効です。
公開情報の要約や一般文章はクラウド、個人情報の抽出はローカル、最終的な高度分析は匿名化後にクラウドへ渡す。
分類に応じて処理場所を変える方が、すべてを高価な専用環境へ置くより現実的な場合があります。
第一はデータ境界。どこへ送信され、どの地域で処理され、何日保持され、誰がアクセスできるかを見ます。
第二は総費用。初期設備、月額、従量料金、電力、保守、人件費、障害停止を含めます。
第三は性能と更新速度。クラウドは最新の大規模モデルを利用しやすく、ローカルは機材に収まるモデルが中心です。
第四は運用負担。ローカルでは担当者がモデル配布、パッチ、容量、監視を担います。
第五は外部連携。メール、文書、CRM、検索、音声などをつなぐ場合、クラウドサービスは選択肢が多い。
第六は可用性と復旧。インターネット障害、クラウド停止、端末故障、停電のどれを許容できるかを決めます。
第七は統制。利用者、入力可能な情報、ログ、承認、削除、監査を管理できるかです。
「学習に使わない」と「保存しない」は別です。
OpenAIは法人向けデータを既定で学習へ使わないと説明する一方、APIでは標準的に不正利用監視ログを最大30日保持し、条件を満たす組織はZero Data Retentionなどを申請できます。
機能によって保存が必要な場合もあるため、サービス全体を一文で判断できません。
Anthropicも商用製品の入力・出力を既定で学習へ使わないと説明していますが、標準保持、ZDR対象API、Covered Modelsなど条件が分かれます。
個人向けFree、Pro、Maxと、Claude for Work、APIを同じ契約として扱わないことが必要です。
Microsoft AzureやGoogle Cloudの企業向けサービスでは、基盤モデル学習への無断利用をしない方針、データ所在地、ネットワーク制御などが示されています。
ただし、ログ、セッション再開、キャッシュ、検索連携、保存型APIを有効にすればデータが残る場合があります。
確認表には、提供会社、製品名、プラン、処理地域、保存地域、標準保持期間、学習利用、オプトアウト、ZDR、暗号化、管理鍵、サブプロセッサー、削除方法、監査ログを書きます。
営業資料ではなく、契約、DPA、プライバシー文書、管理画面の設定を証拠として保存します。
個人情報保護委員会は個人データを生成AIへ入力する場合、利用目的の範囲であることを確認し、応答生成以外に扱われる可能性があるなら、機械学習へ利用されないことなどを十分確認するよう注意喚起しています。
導入方式を決めても、入力してよい情報の社内ルールは別途必要です。
共有型クラウドの費用は、人数、月額、トークン、画像・音声生成、検索やストレージの追加費用から計算します。
利用が少ない時期に費用を抑えやすく、最新モデルへ設備交換なしで移れる点が強みです。
専用クラウドでは、AI料金にネットワーク、ゲートウェイ、ログ、監視、ストレージ、セキュリティ設計、管理者の時間が加わります。
共有型より高くても、監査対応や既存クラウドとの統合が必要なら合理性があります。
ローカルAIは、PCやGPU価格だけで判断しないこと。
セットアップ、モデル検証、更新、電力、冷却、故障交換、バックアップ、アクセス管理、担当者の教育を含めます。
機材を3年間使う想定でも、性能不足で1年後に交換すれば償却計画は崩れます。
月間利用量が少なく、必要性能が高い業務はクラウドが有利になりやすい。
毎日大量に同じ処理を行い、小さなモデルで品質条件を満たし、運用担当者がいる場合はローカルの費用が安定する可能性があります。
価格比較は一回の推論ではなく、成功タスク1件当たりの総費用で行います。
少人数の制作会社が公開情報の調査、文章、画像案を扱うなら、法人向けクラウドから始め、顧客固有情報を匿名化する方法が現実的です。
最新性能と連携を得やすく、専任のインフラ担当を置かずに済みます。
顧客の個人情報や契約書を継続的に扱い、すでにAzureやGoogle Cloudを統制している会社なら、専用ネットワークと管理機能を備えたクラウドを検討します。
既存のID管理、監査、鍵管理へAIを組み込めるかが判断材料です。
製造現場や研究環境で外部接続が難しく、一定の分類・検索を大量に行い、社内に保守担当者がいるならローカルAIが候補になります。
ただし、モデル更新を止める場合の脆弱性や品質劣化、故障時の代替機まで用意します。
一社ですべてを統一する必要はありません。
情報を公開・社内・機密・要配慮のように分類し、公開情報は共有型クラウド、社内文書は法人クラウド、特定の機密処理は専用クラウドかローカルへ分ける。
境界を明文化し、誤送信を技術的に防ぐ方が安全です。
導入前には代表タスクを20件程度選び、品質、処理時間、費用、確認時間、障害時の復旧を測ります。
机上の料金表だけでなく、自社の文書と担当者で運用可能かを確かめてから範囲を広げます。
クラウドとローカルの違いは、データが社外へ出るかだけではありません。
モデル、設備、更新、監視、障害復旧の責任を誰が持つかという違いです。
専用クラウドを加えると、性能と統制の間に現実的な選択肢が生まれます。
機密性だけでローカルを選ばず、便利さだけで共有型クラウドへ寄せない。
情報分類、利用量、必要性能、担当者、復旧時間を数値化し、契約と設定を確認します。
導入方式は一度決めて終わりではなく、モデル更新、価格、法令、業務量の変化に合わせて見直す運用設計です。
.png){kind=logo}
