INSIGHT
ローカルAIを選ぶ前に——会社が引き受ける管理は何か
外へ送らない選択で、自社が新たに引き受ける管理は何か。
「機密情報を外へ出したくないので、AIを社内に置こう」。会議では分かりやすい案です。ただし、社内端末や自社サーバーで動かせば、情報管理の仕事が消えるわけではありません。利用者を誰が追加し、モデルや周辺部品を誰が更新し、容量不足や障害を誰が検知し、どの版へ戻すのか。外部の提供者が担っていた仕事の一部を、会社が引き受けます。
ここでいうローカルAIは、モデルの実行環境を社内端末、自社サーバー、または自社が管理する環境へ置く構成を指します。AIを使って作った通常の社内アプリを指す言葉ではありません。選定では、置き場所の印象より、必要な管理を継続できるかを見ます。
ローカルで動かす選択は、管理をなくす選択ではなく、会社が管理者になる範囲を増やす選択です。
最初に、どこまでが「社内」かを描く
モデル本体を社内へ置いても、更新ファイルを外部から取得し、外部の認証を使い、利用状況を送信し、検索機能が社外サービスへ接続していれば、すべてが社内で完結しているわけではありません。次の流れを一枚にします。
- 入力が届く端末とネットワーク
- モデル本体、追加学習データ、検索用データの保存場所
- 出力、会話履歴、操作ログの保存先
- 認証、監視、更新、遠隔保守の接続先
- 文書検索、外部検索、メール送信などの追加機能
- バックアップと復旧データの保管場所
「インターネットから切り離した」という説明も、更新時の持込み、保守端末、USB媒体、管理者の遠隔接続まで確認して初めて範囲が分かります。目的が特定の機密情報を外へ送らないことなら、その情報が入力からログ、バックアップ、廃棄までどこを通るかで確かめます。
外部通信を止められても、すべての資料をAIへ取り込んでよいと決まるわけではありません。取引先から受け取った資料の利用目的や契約上の条件、社内の閲覧権限は別に残ります。「社内で動かすから」という理由で、入力対象の確認を省かないようにします。
外部サービスと自社運用の責任を表にする
外部の管理サービスでも、利用者の権限や入力情報の扱いは会社側に残ります。自社実行では、そこにモデル、基盤、更新、監視、復旧の仕事が加わります。候補構成ごとに責任表を作ります。
| 管理項目 | 決める内容 |
|---|---|
| 利用と管理権限 | 申請、承認、棚卸し、退職・異動時の削除 |
| モデルと周辺部品 | 入手先、版、更新試験、脆弱性対応、戻す版 |
| データ | 保存場所、暗号化、ログ、バックアップ、削除 |
| 容量と監視 | 同時利用、応答時間、空き容量、異常の通知先 |
| 障害対応 | 停止判断、代替手順、復旧目標、連絡先 |
| 廃止 | 端末、モデル、認証情報、ログの処理 |
欄に「情報システム部」とだけ書かず、通常時と休日に実行できる担当、必要な権限、外部保守先を記載します。担当が決まっていても、管理画面に入れない、戻す版を持っていない、バックアップから復元したことがないなら、責任を引き受けられたとはいえません。
責任表は部署名を埋めるためではなく、その担当者が停止・更新・復旧を実行できるかを確かめるために使います。
権限と環境を、用途の影響で分ける
社内にあるから全社員へ同じ権限を渡してよいわけではありません。使う権限、検索資料を登録する権限、モデルや設定を変える権限、ログを見る権限、外部接続を追加する権限を分けます。共有アカウントでは、誰が機密文書を登録し、誰が設定を変えたかを追えません。
試行、開発、本番も分けます。公開情報で試す環境と、顧客情報を検索する本番環境が同じ保存先を使えば、試行の担当者が本番情報へ届く場合があります。設定変更を本番へ反映する前に、通常の質問、回答できない質問、権限外の質問、悪意ある入力を使って確認し、承認した版だけを移します。
英国NCSCなどが2023年11月に公表したGuidelines for secure AI system development: Secure deployment は、自組織でホストする場合を含め、API、モデル、データへのアクセス制御、環境分離、資産保護、インシデント対応を扱っています。これは複数機関による安全な導入の指針であり、日本での一律の法的義務、ローカル構成の安全保証、費用の優位性を示す資料ではありません。
更新、容量、復旧は、導入前に一度動かす
ローカル運用は、設置した日より更新する日に難しさが表れます。モデル、実行ソフト、ドライバー、検索部品のどれかを変えると、応答品質、速度、対応するファイル、ログの形式が変わることがあります。更新前に対象版と理由を記録し、代表業務と例外で試し、戻す版と手順を用意します。
容量も平均利用だけで決めません。月末の一斉利用、大きな文書の登録、バックアップ処理が重なる時間を試します。応答が遅いときに待たせるのか、利用を制限するのか、別の手順へ切り替えるのかを業務側と決めます。
復旧では、バックアップが存在することと、業務を再開できることを分けます。設定、検索用データ、権限、ログを復元し、別の担当者が代表業務を完了できるところまで試します。使えない時間、失われ得るデータの期間、代替手順を関係者へ共有します。
更新計画とバックアップの有無ではなく、更新を戻せること、復旧後に仕事を再開できることを確認します。
選定会議では、情報と運用を一緒に合意する
構成比較には、機密情報を外へ送るかだけでなく、必要な応答時間、利用人数、更新頻度、停止時の影響、代替手順、保守できる時間、外部支援の条件を載せます。ローカル、外部の管理サービス、両方を使う構成について、各管理項目を誰が担うかを横に並べます。
上司や関係者と合意するのは、「ローカルなら安全」という結論ではありません。対象業務と情報範囲、会社が担う管理、外部へ残る接続、サービス目標、停止条件、復旧責任、見直し日です。管理できない欄があれば、用途を公開情報に絞る、接続を減らす、管理サービスへ任せる、自社運用の体制を整えてから始めるという選択ができます。
ローカルAIの置き場所だけでなく、更新と復旧を担える体制で選ぶ
ローカルAIは、情報の流れを自社で制御しやすくする有力な構成です。同時に、権限、更新、容量、監視、障害、復旧、廃止を会社が引き受ける範囲が増えます。
通信と保管先を描き、外部と自社の責任を表にし、更新と復旧を実際に試す。そこで残った仕事を継続できるなら、ローカルという選択を運用へ変えられます。構成の名前より、担当者が日常と障害時に実行できることが判断の中心です。