オンプレは、Private AIを実現する選択肢の一つです。ただし、機器を社内に置いただけで、AI環境を自社で管理できるようになるわけではありません。
例えば、AI基盤を社内に設置しても、保守事業者によるリモートアクセスの条件が決まっていなければ、障害時に保守作業を始められない可能性があります。
反対に、緊急作業に備えて恒常的な管理権限を付与する場合は、誰が、いつ、何を操作したのかを確認できる仕組みが必要です。
設置場所だけを先に決めると、次のような条件が後回しになりかねません。
管理者権限
保守時のアクセス
更新と脆弱性対応
監視と障害対応
監査に必要な記録
データの保持と削除
HPEは、ソブリンAIを、データの保存場所だけでなく、インフラ、モデル、運用、アクセス制御、ガバナンスまで含む考え方として説明しています。詳しくは、HPEの「ソブリンAIとは」をご参照ください。
AI基盤には、サーバーやGPUだけでなく、データ、モデル、認証、ストレージ、ネットワーク、関連ソフトウェアなど、複数の運用対象があります。
構築時の担当者が決まっていても、監視、更新、障害対応まで同じ体制で続けられるとは限りません。
外部へ運用を委ねる場合も、次の役割を分けて考える必要があります。
監視する
異常を通知する
状況を切り分ける
対応方針を判断する
復旧作業を実施する
結果を記録・報告する
監視を委託していても、異常が発生した後の判断まで委託範囲に含まれるとは限りません。自社に残す判断と、外部へ任せる作業を分けることが重要です。
この段階で、すべての答えをそろえる必要はありません。判断できない項目は「未確認」として残し、確認先と担当者を決めます。これが配置方式を比較する際の出発点になります。
Private AIの配置は、次の6つの軸で検討します。
データの保存場所と適用条件
管理者・保守担当者の所在とアクセス元
認証とアクセス権限
モデル・パッチ・脆弱性管理
監査ログ・証跡・データライフサイクル
設備・人材・更新を含む継続運用
設置場所だけでなく、運用と統制を含めて確認することがポイントです。
最初に整理するのは、AIに渡すデータの種類と、そのデータが通る場所です。
確認するのは、最終的な保存先だけではありません。入力、処理、保存、バックアップ、削除の各段階に分けて確認します。
例えば、次のデータでは取り扱い条件が異なる場合があります。
AIに直接入力するデータ
RAGなどで参照させるデータ
AIが生成した情報
AIの利用に伴って記録されるログ
「国内に保存される」「社内に置かれる」という説明だけで判断してはいけません。データがどこで処理され、どこへ移動し、どこに残るのかまで確認します。
JIPDECが公開した「企業IT利活用動向調査2026 AIの活用状況と課題編」では、調査結果の分析として、AI導入後もセキュリティー対策、データ基盤、プライバシー、出力結果の信頼性が課題として残ると報告されています。
必須条件を満たさないデータがある場合は、そのデータを利用対象から外すか、配置候補を見直します。
処理経路が分からない場合は、仕様や契約を確認するまで配置候補を確定しないことが重要です。
データの保存場所が決まっても、システムを誰が管理するのかが自動的に決まるわけではありません。
自社の管理者、運用委託先、保守事業者について、どこからシステムへアクセスするのかを確認します。通常時のアクセスだけでなく、障害時の緊急アクセスやリモート保守も対象です。
具体的には、次の項目を確認します。
システムの管理主体
保守作業の担当者
管理画面へのアクセス元
緊急時のアクセス条件
作業を承認する担当者
管理操作を確認する方法
保守契約があっても、アクセス方法や承認手順が決まっていなければ、すぐに対応できるとは限りません。
外部からの管理を認められない場合は、社内だけで保守を完結できるか確認します。社内だけでは対応できない場合は、配置方式または保守条件の見直しが必要です。
Private AIでは、AIを利用する人と、環境の設定を変更する人を分けて考えます。
一般利用者、AI開発者、インフラ管理者、セキュリティー担当者、保守担当者、サービスアカウントでは、それぞれ必要な権限が異なります。
役割ごとに、アクセスできるデータと操作範囲を整理します。
併せて、次の点を確認します。
権限の申請・承認方法
保守作業時の一時的な権限
権限を確認する担当者
不要になった権限の失効方法
異動や担当変更時の見直し方法
必要な権限分離を実現できない場合は、その環境を本番候補に残せるか再検討します。製品仕様だけでは判断できない場合は、PoCで権限制御と操作履歴を確認します。
AIエージェントが社内システムで処理を実行する場合は、通常の情報参照とは分けて考える必要があります。参照権限だけでなく、処理の実行権限、承認方法、異常時の停止条件も確認してください。
AI基盤では、導入後もモデルや関連ソフトウェアの変更が発生します。
更新対象を洗い出し、次の役割を決めます。
更新情報を確認する
業務への影響を評価する
更新を承認する
作業を実施する
更新後の動作を確認する
変更内容を記録する
作業手順が用意されていても、更新による業務への影響を判断する担当者が決まっていなければ、対応が止まる可能性があります。
脆弱性が確認された場合も同様です。誰が情報を受け取り、対応の緊急度を判断し、作業の可否を決めるのかを明確にします。
作業を外部へ委ねる場合も、業務への影響を受け入れる判断まで委ねられるとは限りません。自社に残す判断と、外部へ任せる作業を分けてください。
監査に必要な記録を残せるか確認します。
対象には、AIの利用履歴、データへのアクセス、管理操作、設定変更などがあります。ただし、すべての環境で同じログが必要になるわけではありません。
利用目的、社内規程、契約、監査要件に照らして、記録する対象を決めます。
ログを取得していても、誰も確認していなければ、異常の早期発見にはつながりません。次の項目をまとめて整理する必要があります。
取得するログ
ログの保存場所
ログを確認する担当者
ログを確認するタイミング
異常時の連絡先
対応結果の記録方法
例えば、管理操作のログが残っていても、確認担当者が決まっていない場合があります。この状態では、問題が発生した後に記録をたどることはできても、異常を早期に見つける運用にはなりません。
データや生成物の保持・削除についても確認します。保持期間を一律に設定せず、データの種類、利用目的、契約、社内規程に基づいて判断してください。
最後に確認するのは、AI環境を構築できるかどうかではありません。構築した環境を継続して運用できるかどうかです。
オンプレやコロケーションでは、電力、冷却、設置場所などの設備条件が関係します。さらに、次のような運用条件を整理します。
監視する対象
監視結果の通知先
障害時の一次対応
エスカレーション先
運用担当者と代替要員
拡張・更新の方針
内製する範囲
外部へ委ねる範囲
機器、ソフトウェア、運用を別々の事業者から調達する場合は、障害時の窓口が分かれる可能性があります。どこへ連絡し、誰が全体の対応方針を判断するのかを決めておく必要があります。
HPEは「HPE ソブリンAIファクトリー」において、ソブリンAIに関する検討領域として、インフラ、エネルギー、冷却、人材、パートナーシップ、長期計画を挙げています。
配置方式を選ぶときは、最初から各方式の優劣を決めてはいけません。「社内に置ける」「初期費用を抑えられる」といった一つの条件だけで選ばないことが重要です。
|
配置方式 |
候補に残しやすい条件 |
注意して確認すること |
見直しが必要な状態 |
|
クラウド |
責任分界、保存・処理場所、取得できるログを確認できる |
外部管理者によるアクセス、サービスの変更、データの移行方法 |
必須となる保存・処理条件や監査要件を満たせない |
|
オンプレ |
設備、権限、保守、更新を自社の方針に沿って管理できる |
運用人材、障害対応、電力・冷却、更新方法 |
設備や運用体制を継続できず、外部支援でも補えない |
|
コロケーション |
施設運用とシステム運用の役割を分けられる |
入館方法、現地作業、リモート管理、障害時の窓口 |
施設運営事業者、保守事業者、自社の責任分界を明確にできない |
この表は、配置方式の順位を決めるものではありません。自社の必須条件に合わない候補を外し、追加確認が必要な候補を明らかにするためのものです。
確認結果は、単純な合計点ではなく、次の4区分に分けます。
|
判定 |
状態 |
次の行動 |
|
条件を満たす |
必須条件を満たし、運用責任も確認できている |
構成、費用、移行条件の比較へ進む |
|
条件付き |
契約変更や運用体制の追加により、対応できる可能性がある |
追加条件、担当者、費用への影響を確認する |
|
条件を満たさない |
必須条件に反し、補完方法も確認できない |
候補から外し、別の配置方式を検討する |
|
未確認 |
仕様、契約、担当者、運用方法が明らかになっていない |
確認先を決め、必要に応じてPoCで確かめる |
「未確認」を「問題なし」と扱わないことが重要です。保存場所、保守アクセス、取得できるログなどが分からない場合は、仕様書、契約書、構成資料を確認します。
この4区分は、公的機関やメーカーが定めた基準ではありません。不足している情報を可視化し、次の確認へ進むための整理方法です。
PoCでは、モデルの回答精度だけでなく、本番環境として運用できるかを確認します。
PoCを始める前に、次の条件を決めます。
利用するデータ
利用者と管理者
外部担当者によるアクセス
取得するログ
PoC終了後のデータの保持・削除
アカウントと一時環境の扱い
運用面では、権限を分離できるか、必要なログを取得・確認できるか、変更や更新を管理できるかを確かめます。
障害を検知して担当者へ連絡できるか、保守作業時のアクセスを制御できるかも確認が必要です。
PoCの終了後は、本番移行、追加検証、見送りのいずれに進むかを記録します。
固定した合格点だけで判定せず、自社で設定した必須条件を満たしたか確認してください。満たせなかった条件については、追加対策で補えるのか、配置候補を変更すべきなのかを判断します。
Private AIの配置は、確認できた項目の数だけでは決まりません。重要なのは、必須条件を満たしているか、未確認事項を誰が確認するかです。
配置判断表には、次の項目を設けます。
確認事項
自社の必須条件
確認結果
判定
根拠となる規程・契約・仕様
確認先
担当者
PoCで確認する必要があるか
検討は、次の順序で進めます。
AIの利用目的と対象データを決める
6つの判断軸で必須条件を整理する
配置方式ごとに条件を満たすか確認する
条件を満たさない候補を外す
条件付きの候補について追加対策を確認する
未確認事項を確認先またはPoCへ送る
確認結果を基に本番環境の候補を決める
根拠となる規程、契約書、仕様書、構成資料も記録します。構成やサービスが変わった場合に、当初の判断がどのような前提に基づいていたのかを確認しやすくするためです。
Private AIの配置は、「社内データをクラウドへ出せないからオンプレ」という一問一答では決まりません。
データの保存場所だけでは、管理権限、保守アクセス、モデルのライフサイクル、監査、設備、運用体制まで説明できないためです。
製品や設置場所を決める前に、6つの判断軸に沿って自社の必須条件を整理します。確認結果は、次の4区分に分けてください。
条件を満たす
条件付き
条件を満たさない
未確認
その上で、クラウド、オンプレ、コロケーションを同じ条件で比較します。判断できない項目は、仕様や契約を確認するか、PoCで確かめます。
この順序で検討を進めることで、社内説明に必要な根拠と、本番運用までに解消すべき課題を整理できます。
Private AIの配置方式を決めるには、既存環境、データの取り扱い、運用体制、設備条件を整理した上で、構成候補を比較する必要があります。
横河レンタ・リースでは、サーバーやITインフラに関するご相談を受け付けています。機器の配置だけでなく、構築後の運用や保守も含めて検討したい場合は、お問い合わせください。