# オンプレミス生成AIをERPにつなぐ:データを社内に置いたまま使う方法

> Source: https://netray.co/ja/onprem-genai-erp
> Language: ja
> Publisher: Netray (netray.co)
> English version: https://netray.co/erp-ai/erp-ai-agents-on-prem

ERPの原価、受注、設計情報を外部のクラウドAIに送らず、自社のGPUサーバーや閉域環境でオープンウェイトのモデルを動かす構成が現実的になっています。要点は、モデルの性能より、読み取り専用の接続、ERP権限の継承、実行クエリの可視化、書き込み時の人間承認の四つです。

生成AIを業務で使いたいという要望は強い一方で、日本の製造業では「ERPのデータを外部に出せない」という壁に当たることが多くあります。原価や見積、取引先の与信、設計図面に紐づく情報は、不正競争防止法上の営業秘密として管理されている場合が多く、クラウドAIへの送信は社内規程で禁止されがちです。

近年は、Llama、Qwen、Mistral、Gemma、gpt-oss、DeepSeek系などのオープンウェイトモデルが実用水準に達し、vLLMやOllamaで社内サーバー上に配置できるようになりました。ここでは、ERPと組み合わせる際の設計判断を、情報システム部門が上申しやすい形で整理します。

## なぜオンプレミス(自社管理)なのか

理由は大きく三つあります。第一に、機密情報の取り扱い規程です。防衛・航空宇宙・半導体関連の取引先から、情報の保管場所や取扱者を限定する要件が課されることがあります。第二に、閉域網の工場です。製造現場のネットワークは外部接続を制限しており、クラウドAIの前提が成り立ちません。第三に、利用量が増えたときのコストの予測可能性です。

一方で、オンプレミスにはGPUの調達、運用、モデル更新の負担が伴います。月に数回しか使わない用途であれば、国内リージョンのプライベート環境や、データを学習に使わない契約が確認できるサービスの方が合理的な場合もあります。この判断は、データの機密区分ごとに分けて行うのが現実的です。

## 参照アーキテクチャ

基本構成は、(1)モデルサーバー(vLLMまたはOllama)、(2)検索層(ERPのデータと社内文書のRAG)、(3)ERP接続層、(4)認証・権限・ログ、(5)利用画面、の五層です。ERPrayでは、自然言語の質問をSQLやAPI呼び出しに変換し、実行したクエリを画面に表示したうえで結果を返します。回答の根拠が見えるため、経理や監査の担当者が検証できます。

接続は読み取り専用を既定とし、本番DBに直接負荷をかけないよう、レプリカや夜間同期のビューを使います。ERPのロール(部門、拠点、会社コード)をAI側にも引き継ぎ、営業担当者が原価データを引き出せない、といった制御を維持します。

- モデルサーバー:vLLMまたはOllamaを自社GPU、またはプライベートクラウドに配置
- 検索層:ERPのマスタ・取引データと、手順書・仕様書・過去の障害対応を別々に索引化
- 接続層:読み取り専用アカウント、レプリカ、必要なテーブルのみ公開
- ログ:誰が何を聞き、どのクエリが実行されたかを保存

## ERPでの具体的な使いどころ

営業・購買では、「先月、納期遅延になった発注を仕入先別に出して」といった質問を自然言語で投げ、画面を探し回る時間を減らせます。生産管理では、遅延している製造オーダーの原因候補(部品欠品、設備、検査待ち)を一覧にし、担当者が判断する材料にできます。経理では、仕訳や差異の確認を補助しますが、確定は人間が行います。

ERPに蓄積されたカスタマイズ知識の継承も有力な用途です。アドオンの仕様、帳票の項目定義、運用手順を検索可能にしておくと、担当者交代時の引き継ぎ負荷が下がります。SAP、Infor、Oracle、Microsoft Dynamics、国産ERPなど、ERPの種類を問わず基本の考え方は共通です。

## 書き込みと承認、そしてセキュリティ

AIにERPへ直接登録や更新をさせることは、既定では行いません。必要な場合も、AIは下書きを作るだけにとどめ、人間が内容を確認して承認するフローを入れます。これにより、誤入力や、プロンプトインジェクションのような攻撃で意図しない更新が起きるリスクを下げられます。

セキュリティ面では、モデルサーバーの外向き通信の遮断、プロンプトとログの保管期限、管理者権限の分離、モデルの入手経路(署名・ハッシュ確認)の管理が必要です。個人情報を含むデータは、個人情報保護法の安全管理措置の対象になるため、マスキングやアクセス制御を併用します。

## 始め方と、導入しない方がよい場合

最初の一歩は、対象の質問(例えば「納期回答」「在庫照会」「原価差異」)を10〜20件選び、実データで正答率を測るパイロットです。機材はまず1〜2台のGPUサーバーで十分なことが多く、本格展開の前に必要な規模を見極められます。

ERPベンダー純正のAI機能が自社の範囲で足りるなら、無理に別構成を作る必要はありません。また、利用者が少なく質問も定型的であれば、AIよりもBIツールの定型レポートの方が低コストで確実です。AIは、定型化しにくい質問や、文書とデータをまたぐ検索で効果が出ます。

## FAQ

### オンプレミスの生成AIにはどの程度のGPUが必要ですか。

モデルの大きさと同時利用者数によります。数十人規模の問い合わせ用途なら、1〜2台のGPUサーバーから始められることが多いです。パイロットで実測してから規模を決めることを勧めます。

### 日本語の精度は十分ですか。

QwenやLlama系などは日本語でも実用水準にあります。ただし、社内用語や略語は事前の整備が必要です。用語集をRAGに組み込み、実データで評価するのが確実です。

### ERPの権限はAIにも反映されますか。

反映する設計にします。ERPのロールや組織単位を接続層で引き継ぎ、利用者が元々見られないデータはAIの回答にも出ないようにします。

### AIがERPのデータを書き換えてしまう心配はありませんか。

既定は読み取り専用です。書き込みが必要な場合も、AIは下書きの作成までとし、人間の承認後に実行します。

### クラウド型のAIと比べて、何を諦めることになりますか。

最先端の大規模モデルの性能や、運用負担の軽さです。機密区分が高いデータはオンプレミス、低いデータはクラウド、と使い分ける構成も検討できます。