オンプレミスとは何か:文書を外部に出さずにAIを使う方法の完全整理
オンプレミス(On-Premise)とは、外部事業者のクラウドではなく顧客が自ら管理する社内サーバーにモデルとシステムを設置して運用し、処理対象のデータが組織の境界を越えないように構成する方式です。
オンプレミスが要件になる理由
文書を外に出せない組織があります。
クラウドサービスが一般化し、多くのソフトウェア導入の議論はどのサービスを使うかから始まります。ところが金融と公共では、その前に別の問いが置かれます。この文書を外に出せるのか、という問いです。与信審査の書類には個人の所得と口座の情報が入り、被害救済の申請書には被害者の身元と事件の内容が入ります。こうした文書を外部サーバーへ送る構成は、社内規定と監督規定の両方で引っかかります。
したがってこれらの組織にとってオンプレミスは複数の選択肢の一つではなく、通過しなければならない要件です。性能がどれほど優れていても社内設置が不可能なソリューションは検討リストから先に外れます。導入検討の最初の関門が技術評価ではなく配備方式の確認になる理由がここにあります。
オンプレミスの正確な定義:クラウド方式と何が違うのか
クラウド方式とオンプレミス、三つの軸の違い
第一に、対象が異なります。クラウド方式で顧客が管理するのは要求と応答の規格だけです。オンプレミスではサーバーと演算装置、コンテナ環境、ストレージ、アクセス権限までが顧客の管理範囲に入ります。管理するものが増える代わりに、統制できる範囲もそれだけ広がります。
第二に、目標が異なります。クラウド方式の目標は速くつないで使うことです。オンプレミスの目標はデータを外に出さずに運用規模の処理量を安定して支えることです。前者は導入速度を優先し、後者は統制可能性を優先します。
第三に、成果指標が異なります。クラウド方式は応答時間と処理量の上限を見ます。オンプレミスはこれに加えて閉域網での設置可否、必要な演算装置の仕様、モデル更新の手続、監査ログの要件、障害対応の体制を併せて見ます。実際の構成では推論と文書処理の全過程が社内網で実行され、権限管理と処理履歴の記録、運用環境と検収環境の分離が併せて提供されます。
二つの方式は置き換えの関係にはありません。初期検証は外部呼び出しで速く進め、運用段階で社内設置に移す経路が一般的です。したがって検討時点で確認すべきは今使う方式ではなく、同じエンジンで両方の方式が提供されるかどうかです。
導入を決める前に確認するオンプレミスの5つの要件
実際の構築に入るオンプレミスの5つの要件
第一に、閉域網で設置が完結することです。設置の過程で外部リポジトリに接続して構成要素をダウンロードする仕組みであれば、インターネットが遮断された環境で作業が止まります。必要なイメージとモデルの重みを搬入媒体で移して設置できるかの確認が必要です。
第二に、必要な演算装置の仕様が明確であることです。視覚言語モデルを用いた処理は演算量が大きく、加速装置なしでは実用的な速度が出ません。月間処理量とピーク時間帯の集中度を基準に必要な規模を算定し、増設の経路も併せて確認しておくとよいでしょう。
第三に、モデル更新の手続が統制可能であることです。外部モデルは事業者の判断で更新され、性能が予告なく変わります。社内設置では新しいバージョンを検証したうえで承認手続を経て反映し、必要であれば以前のバージョンに戻せる必要があります。
第四に、監査対応の要件を満たすことです。誰がどの文書をいつ処理し、どの値が修正されたかが記録として残る必要があります。役割別のアクセス制御と処理履歴の保管は、金融と公共の監査で繰り返し求められる項目です。
第五に、運用人員の負担を計算することです。社内設置は顧客がサーバーとコンテナ環境を併せて抱える方式です。監視ツールと障害通知、定期点検の手順が併せて提供されるか、供給側の遠隔支援の範囲がどこまでかを契約前に整理してください。
オンプレミスの実際の適用方法
配備構造を階層に分けます
設置の設計は機能を階層に分けるところから始まります。文書を受け取る応用層、認識と構造化を行うモデル層、結果と原本を保管するデータ層、業務システムとつなぐ連携層に区分しておくと、以降の増設と交換が容易になります。
実際の構成ではコンテナを基盤に各層を配置し、演算装置の資源はモデル層にのみ割り当てる方式が一般的です。関係データベースに処理履歴と結果のメタデータを置き、原本ファイルはオブジェクトストレージに置き、作業待ち行列とキャッシュを別に運用する構成が広く用いられます。
検収環境と運用環境を分離します
社内設置の利点はデータが外に出ないことだけではありません。検収環境を運用環境から分けておけるという点も、実務では大きな意味を持ちます。新しい様式が届いたときに検収環境で抽出基準をまず試し、結果を確認したうえで承認手続を経て運用に反映する流れを作ることができます。
この構造が整うと、運用中の変更が事故につながる危険が減ります。逆に二つの環境を分けなければ、様式を一つ追加するたびに運用性能が揺らぐ余地が生まれます。
国内環境におけるオンプレミス
韓国でオンプレミス要件を生む最も直接的な規定はネットワーク分離です。業務網とインターネット網が分離されていれば外部API呼び出し自体が遮断されるため、社内設置以外の選択肢がありません。
金融分野では電子金融監督規定と金融保安院のガイドラインに沿った構成が求められます。公共分野では機関ごとの保安指針と個人情報の処理基準が追加で適用されます。いずれの領域も個人情報の国外移転が事実上不可能である点が共通の条件です。
もう一点考慮すべきは国産の文書形式です。閉域網の中で韓国製ワープロ文書を変換するには、関連する処理の構成要素も併せて社内に設置されている必要があります。この部分が抜けると、設置は終わったのに実際の受付文書を開けないという事態が生じます。
よくあるご質問
可能です。必要な構成要素とモデルを搬入媒体で移して設置する方式で進めます。設置の過程で外部接続が必要かどうかを事前にご確認ください。
可能です。同じエンジンが両方の方式で提供される場合、検証段階の抽出基準とスキーマをそのまま移行できます。
処理量によって異なります。視覚言語モデルの推論には加速装置が必要であり、月間の文書量とピーク時の集中度を基準に算定します。導入検討の際に実際の物量をお知らせいただければ、構成案を併せて検討できます。
新しいバージョンを検収環境でまず評価し、承認手続を経て運用に反映します。問題が生じた場合は以前のバージョンに戻せるよう構成します。
発生しません。推論と文書処理がすべて顧客の社内網で実行されるため、原本が組織の外に出ることはありません。
アクセス権限と処理履歴が記録として保管され、運用環境と検収環境を分離して変更手続を統制できます。監査対応に必要な項目は導入時に併せて定義します。