情報システム部門の要件書に「オンプレミス必須」と一行で書かれていても、社内に置くべきものは一つではありません。オンプレミスのAIエージェントは、モデル・実行基盤・データと記録の三層に分け、層ごとに社内へ置く条件を決めると選べます。
この一行が「社外に出せない情報を外に出さない」という意図で書かれているなら、AIエージェントでは確かめる先が三つに増えます。モデルに送る入力、社内システムを操作するための接続、そして動いた結果を残す記録です。製品資料の「オンプレミス対応」がそのどれを指すのかは、比較表の記号だけでは読み取れません。
要件書の一行と製品資料の記載を突き合わせると、オンプレミス対応は製品に付く一つの属性ではなく、三つの層の置き場所の組み合わせだと分かります。組み合わせとして捉え直すことで、要件書の一行は、ベンダーに確かめられる三つの問いに変わります。
日本でオンプレミスのAIエージェントは、どう選べばよいのか？
製品名から比べ始めず、モデル・実行基盤・データと記録の三層それぞれに「社内に置く理由」があるかを先に決めます。理由がある層は社内に置き、理由のない層は条件付きで外に置けるかを確かめる、という順序です。この順で絞れば、比べる対象は要件を満たす構成だけに減ります。日本で選ぶ場合は、三層の置き場所を決めたうえで、データを取り扱う国と障害時の対応体制の二つを加えて確かめます。
| 層 | 中身 | 社内に置く理由になりやすいもの | ベンダーに確かめる問い |
|---|---|---|---|
| モデル | 推論を行う言語モデル | 入力や出力に、社外へ出せない情報が入る | 推論はどこで行われ、入力は学習や保存に使われないか |
| 実行基盤 | エージェントとワークフローを動かす仕組み、ツールの呼び出し、接続の設定 | 操作する基幹系が社内ネットワークの中にしかない | 社内システムへは、どのネットワークから届くのか |
| データと記録 | 認証情報、実行ログ、参照文書とその検索用の索引 | 監査で記録を自社から出す、参照文書そのものが機密 | 記録と索引はどこに保存され、誰が読めるのか |
仮に、取引先から届く注文書をAIが読み取り、基幹系に受注を登録するエージェントを考えます。モデル層に入るのは注文書の文面、つまり取引先名や担当者名です。実行基盤は社内の基幹系にある受注登録の窓口を呼び出し、データと記録の層に残るのは、読み取った文面と登録の結果です。
三層を分けるのは、層ごとに「社外に出る」の中身が違うからです。モデル層で出ていくのは入力の文面、実行基盤で問われるのは社内システムへの経路、データと記録の層に残るのは後から読める複製です。一つの層だけを社内に寄せても、残りの層を通る経路は開いたままです。
逆向きの失敗は、三層をすべて社内に寄せることです。要件は確実に満たせますが、推論用のGPU、モデルの更新、記録の保全まで自社で抱えます。理由のない層まで社内へ寄せると、要件書が求めていない運用だけが増えていきます。
データを取り扱う国については、モデルのAPIや記録の保存先が国外にあるなら、個人情報保護法の外国にある第三者への提供の規律との関係を先に整理しておきます。障害時の対応体制は、誰がどの時間帯で対応するかを確かめる問いで、運用の担い手を決める問いと地続きです。
「オンプレミス必須」の一行は、どの層に向けた要求なのか？
一行の出どころをたどれば、効いている層が分かります。個人情報や機密の取扱いから来た要件ならモデルと「データと記録」の層に、社内ネットワークの規程から来た要件なら実行基盤とモデルに、監査の要件なら「データと記録」の層に主に効きます。
| 要件の出どころ | 主に効く層 | 書き直す前に確かめること |
|---|---|---|
| 個人情報・機密情報の取扱い | モデル、データと記録 | 誰がデータを取り扱えるか、どの国で取り扱われるか |
| 社内ネットワークの規程（閉域網） | 実行基盤、モデル | 外部への通信をどこまで許すか |
| 監査・内部統制 | データと記録 | 記録を自社で保存し、求めに応じて出せるか |
| 取引先との契約・業界の基準 | 条文による | 条文が求めているのは「場所」か「管理」か |
個人情報の扱いで判断の軸になるのは、個人情報保護委員会のQ&Aです。クラウドの利用が本人の同意を要する第三者提供や委託に当たるかは、保存したデータに個人データが含まれるかではなく、クラウドの事業者がその個人データを取り扱うことになっているかで判断する、という整理です。
契約で取り扱わない旨を定め、適切にアクセス制御している場合などは、提供には当たらないとされています。ただし、利用する事業者自身の安全管理措置まで不要になるわけではありません。外国にあるサーバに保存する場合も同じ考え方を取りつつ、その国の制度を把握したうえで安全管理措置を講じることが求められます。
提供に当たるかどうかを分けるのは、置き場所の呼び名より、誰が取り扱えるかです。
契約や業界の基準から来た要件は、条文の言葉を読みます。たとえば「指定の場所以外に保管しない」とあれば場所の要件、「第三者がアクセスできない状態で管理する」とあれば管理の要件です。前者は「データと記録」の層の保存先に、後者はモデルと実行基盤を含めた権限の設計に効きます。
監査から来た要件で問われるのは、求めに応じて記録を出せるかどうかです。保存先が自社の管理下にあり、取り出す手順が決まっていれば、物理的な場所まで社内である必要があるかは条文しだいでしょう。
国の情報システムの基準も、オンプレミスを前提にはしていません。デジタル庁の「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2025年5月27日決定）は、クラウドサービスの利用を第一候補として検討するとしたうえで、データが所在する地域と準拠法に留意するよう求め、データセンタの設置場所は国内を基本としています。
要件書の「オンプレミス」が、実際には「国内」や「自社が管理する」を意味していないか。書き直す前に、条文の作り手へ確かめてください。
モデル層：ローカルLLMを社内に置けば、要件は満たせるのか？
満たせるのはモデル層の分だけです。推論が社内で完結しても、エージェントを動かす実行基盤や記録の保存先が外にあれば、入力と出力は別の経路で社外を通ります。
手元のPCで動かす小さなモデルも、社内のサーバーで動かすモデルも、どちらもローカルLLMと呼ばれます。要件書に書くときは、どの機器で、どのネットワークの内側で動かすのかまで指定しておくと、ベンダーとの解釈がずれません。
モデルを外部のAPIで使えるかどうかは、入力の中身で決まります。個人情報保護委員会は2023年6月の注意喚起で、個人データを含むプロンプトを本人の同意なく入力し、それが応答の出力以外の目的で取り扱われる場合は法に違反する可能性があるとして、提供事業者が機械学習に利用しないこと等を十分に確認するよう求めました。
入力を学習や保存に使わないことを契約で確かめられ、送る情報を業務の側で絞れるなら、モデル層を外に置く選択肢は消えません。反対に、入力から機密を外せない業務、外部への通信そのものが許されない環境、応答の待ち時間が現場の手を止める工程では、社内に置く理由が立ちます。
社内で動かすには、重みを自社の環境に置けるモデルが要ります。選択肢の一つが公開モデル（オープンモデル）です。Ollamaは公開モデルの推論を手元でもクラウドでも行える仕組みとして提供されており、MetaのLlama系統はHugging Face上でライセンス条項と利用規定に同意したうえで入手する形です。
どのモデルを選び、どこまで小さくできるかは、費用・応答時間・データの所在でモデルの置き場所を決める考え方に委ねます。モデル層の答えが出た時点で、要件書の一行のうち片づいたのは三分の一にすぎません。
実行基盤：AIエージェント基盤は、どこで動かすべきか？
操作する相手の近くに置くのが基本です。エージェントが基幹系やファイルサーバーを操作するなら、実行基盤は社内ネットワークからそれらに届く場所で動かし、接続に使う認証情報も同じ側で保管します。
実行基盤は、ワークフローの進行を管理し、ツールを呼び出し、外部システムとの接続設定を持つ部分です。これがクラウドにあると、社内の基幹系へはVPNや中継の仕組みを介して届かせる形です。社内ネットワークの規程によっては、その経路を開くこと自体が審査の対象になります。
経路の向きも、確かめておきたい点です。社内に置いた中継役が外のクラウドへ接続しに行く形なら、外から社内へ入る受け口を開けずに済む場合があります。どちらの向きに、何のための通信を通すのかを構成図に書き込めるかどうかは、製品を比べる観点の一つです。
「ChatGPTは答えます。WindyFloは働きます。」という対比で言えば、答えを返すだけのAIなら、議論はモデル層でほぼ終わります。社内システムに手を伸ばして処理を進めるエージェントになると、実行基盤の置き場所は、操作先との距離と、開ける経路の数で決まってきます。
実行基盤を社内に置けば、それに付随する部品も社内に来ます。Difyの公式ドキュメントにあるDocker Composeの手順では、APIやワーカーなどの中核サービスと一緒に、ベクトルデータベースのWeaviate、PostgreSQL、Redisといった依存コンポーネントが起動します。この構成なら、実行基盤を社内に置くことが、そのままデータと記録の層の一部を社内で運用することを意味します。
その運用を誰が担うかは、置き場所と同じ重さで決めておきます。パッチの適用、バックアップ、障害時の切り戻しが自社の仕事になるのか、提供元の支援を受けられるのか。構成図に線を引く前に運用の担い手の欄を埋めておけば、後から置き場所を動かさずに済みます。
データと記録：認証情報・ログ・参照文書は、どこに残るのか？
モデルと実行基盤を社内に置いても、ログの転送先や障害調査のための送信先、参照文書から作った索引の保存先が外にあれば、記録は社外に残ります。保存先と送信先を項目ごとに確かめるまで、この層の置き場所は決められません。
何を残すかは、国の指針から逆算できます。総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」は、検証可能性の確保として、利用時の入出力等や判断根拠等のログを合理的な範囲で記録・保存するよう示しています。データの出所や意思決定を追跡・遡求できる状態の確保も、アカウンタビリティの項目として並びます。
記録方法・頻度・保存期間等は、技術の特性と用途に照らし、事故等の原因究明、再発防止策の検討、損害賠償責任要件の立証上の重要性等を踏まえて検討する、というのが同じ指針の考え方です。業務ごとに保存期間が変わるのは、この考え方に沿った結果です。
三層の言葉に直した確認項目は、次の五つです。
- 認証情報：基幹系やSaaSへの接続に使う鍵やアカウントを、どこに保管し、誰が読めるか
- 実行ログ：入力・出力・ツール呼び出しの記録を、どこに、どの期間残すか
- 参照文書の索引：検索用に分割・変換した文書の複製を、どこに置くか
- バックアップ：記録と索引の複製を、どこへ、誰の鍵で暗号化して保管するか
- 提供元への送信：利用状況や障害の情報を外へ送る設定があるか、止められるか
参照文書の索引は、元の文書の複製として扱います。原本を社内のファイルサーバーに残していても、検索用に変換した中身が外部の保存先にあれば、機密は外に置かれているのと同じです。
個人データが社外に出る地点を業務の流れの上で特定する手順は個人データの持ち出しをどこで止めるかで、誤った処理を業務の手前で止める確認と記録の置き方はハルシネーションを前提にした確認と記録で整理しました。
三層を組み合わせると、どんな構成になるのか？
候補になる構成は、次の四つの型に整理できます。どの型が合うかは業務ごとに変わるため、同じ会社の中で業務ごとに型を変えるのも自然な選び方です。
| 型 | モデル | 実行基盤 | データと記録 | 合う要件 | 自社が引き受けるもの |
|---|---|---|---|---|---|
| A すべてクラウド | 外部 | 提供元のクラウド | 提供元のクラウド | 社外に出せない情報を扱わない業務 | 契約で取扱いを確かめる手間 |
| B 実行と記録を自社側に | 外部のAPI | 社内か自社のクラウド | 社内か自社のクラウド | 基幹系の操作が中心で、入力を絞れる業務 | 送る情報の選別 |
| C 入力で振り分け | 機密は社内、それ以外は外部 | 社内 | 社内 | 一つの業務に機密度の違う情報が混ざる | 振り分けの規則と判定の管理 |
| D すべて社内 | 社内 | 社内 | 社内 | 外部への通信が許されない環境 | GPU、モデルの更新、運用のすべて |
型Bと型Cの分かれ目は、入力を業務の側で選別できるかどうかです。注文書のように様式が決まり、機密に当たる欄を特定できるなら、その欄を伏せて外部のAPIへ送る型Bで足ります。自由記述の問い合わせのように、どこに機密が混ざるかを事前に決められない入力では、振り分けを仕組みに任せる型Cか、モデルごと社内に置く型Dが候補です。
型Cのように層をまたいで置き場所を分けるほど、境界の管理は増えます。政府情報システムについての基準ですが、デジタル庁の同じ基本方針も、クラウドとオンプレミスを組み合わせてデータを処理・保存する形態について、移行期、データの多重バックアップ、ネットワーク遅延が許容できない場合を除き、複雑化と高コスト化の要因になるとして避けるよう求めています。
分ける理由を層ごとに言葉にできる構成だけを残すと、運用は軽く保てます。
ハマダラボ（HAMADA LABS）のWindyFloは、どの置き方を選べるのか？
ハマダラボ（HAMADA LABS）のWindyFloについて、会社資料（2026年9月）は配備形態を四つ挙げています。SaaS、導入企業のクラウド、オンプレミス（社内ネットワークへの設置と運用の支援）、ハイブリッドです。三層の置き場所を考えるとき、提供元のクラウドだけに選択肢が限られないということです。
同じ資料に対応モデルの提供元として並ぶ13の名前には、クラウドのAPIで提供されるOpenAI・Anthropic・Geminiなどと並んで、Ollama・Hugging Face・LLaMAといった公開モデルの系統も含まれます。ただし、この資料はオンプレミスの構成で使えるモデルの範囲までは示していません。セキュリティや規模を重視する企業向けのエンタープライズのパッケージは、オンプレミスか専用クラウドへの設置、既存システムとの連携、全社での運用支援を内容とします。
強みとして挙げる文書処理とRAG（PDFやマニュアルに基づく質疑応答・要約・翻訳）は、参照文書の索引を持つ機能です。この機能を使う構成なら、索引をどこに保存するかがデータと記録の層の確認項目です。
公開ページでは、「ノード」をドラッグ＆ドロップでつないでAIパイプラインを組み、さまざまな大規模言語モデルを使い、APIで既存のアプリやサイトに組み込む使い方を案内しています。ハマダラボは自社を、構築で終わらず運用まで担う「AI運用パートナー」と位置づけています。
そのうえで、オンプレミスの構成でどの提供元のモデルを動かせるか、日本国内での支援の体制、データをどこに保存するかは、構成ごとに確かめていただきたい項目です。比較表の「対応」の一語で済ませず、三層の問いに沿って一行ずつ確かめてください。
三層で書き直すと、要件書の一行はどう変わるのか？
「オンプレミス必須」の一行は、層ごとの三行になります。行が分かれれば、ベンダーは行ごとに答えを返せるようになり、比較表の丸やバツにも根拠が付きます。
- モデル：個人情報や設計情報を含む入力の推論は、自社が管理する環境で行う。それ以外の入力には、学習や保存に使わないことを契約で確認できる外部のAPIを認める
- 実行基盤：基幹系を操作するワークフローは、社内ネットワークから基幹系へ届く場所で動かし、接続用の認証情報も同じ側に保管する
- データと記録：入力・出力・ツール実行の記録と参照文書の索引は自社が管理する保存先に置き、保存期間は社内規程に合わせる。提供元への送信は、中身を確認できるものに限る
三行への書き直しは、要件を緩めるための作業ではありません。守りたいものを層ごとに名指しすると、守る必要のない層まで社内に抱え込む構成を避けられます。
書き直した三行のうち、どの行が相談の中心になるかを先に決めておくと、ベンダーとの会話は短く済みます。モデルの行なら推論の場所、実行基盤の行なら社内への経路、記録の行なら保存先から確かめられます。問い合わせ窓口はWindyFloの製品ページにあります。
よくある質問
閉域網でAIエージェントを動かすとき、見落としやすいのはどこですか？
ライセンスの認証、ソフトウェアやモデルの更新の届け方、障害時の保守の経路です。どれかが外部への通信を前提にしていると、閉域網の中では動きが止まるおそれがあります。検証環境で外部への通信を遮断したまま数日動かしてみると、隠れた前提が表に出やすくなります。
国産のLLMを選べば、オンプレミスの要件は満たせますか？
開発元が国内であることと、推論が社内で行われることは別の話です。提供形態がクラウドか社内設置かをモデルごとに確かめ、実行基盤と記録の置き場所はモデルの選定とは切り離して決めます。
自社が契約するクラウドの専用環境は、オンプレミスの代わりになりますか？
代わりになるかは、提供元の担当者が環境やデータにどこまで触れられるかで決まります。管理者権限を誰が持ち、保守のためのアクセスがどう記録されるかを、契約と設定画面の両方で確かめます。国の基準も、国外のクラウドに機密性のある利用者データを置く場合の対策として、利用者自身の暗号鍵による保護と鍵管理を挙げています。規程が物理的な設置場所を指定しているなら、その条文の見直しまで含めて検討します。
国の機関向けの案件では、クラウドは使えないのですか？
一律に使えないわけではありません。政府情報システムでは、ガバメントクラウドを使わない場合、ISMAPかISMAP-LIUのクラウドサービスリストに登録されたサービスを原則として選ぶとされています。ISMAPは、政府が求めるセキュリティ要求を満たすクラウドサービスをあらかじめ評価・登録する制度です。仕様書がどちらのリストへの登録を求めているかを、最初に確かめてください。
Difyやn8nをセルフホストすれば、三層とも社内に置けますか？
実行基盤と記録は社内に置けますが、モデルは別に用意して接続する形です。n8nの公式ドキュメントは、自社のインフラやオンプレミス、プライベートクラウドで動かせるとしたうえで、技術的な専門性がなければクラウド版を、インフラと技術の体制があればセルフホストを勧めています。置き場所の自由と引き換えに運用の担い手が問われる点は、製品を問わず共通です。
オンプレミスで動かすモデルは、あとから入れ替えられますか？
入れ替えの手間は、実行環境が扱えるモデルの形式とGPUのメモリ量で決まります。入れ替えの前後で同じ試験用の入力を流し、業務で使う出力の形が保たれるかを比べる手順を用意しておくと、更新のたびの判断が速くなります。プロンプトや手順を特定のモデルの癖に寄せすぎないことも、入れ替えを軽くします。
出典
- ［1次］個人情報保護委員会「よくある質問」Q7-53（クラウドサービスの利用が第三者提供・委託に当たるかは、クラウドサービス提供事業者が個人データを取り扱うこととなっているかで判断する。契約で取り扱わない旨を定め適切にアクセス制御している場合等は提供に当たらない）・Q7-54（提供に当たらない場合も利用者自身の安全管理措置は必要）— 確認日2026年10月7日: https://www.ppc.go.jp/all_faq_index/faq1-q7-53/ ／ https://www.ppc.go.jp/all_faq_index/faq1-q7-54/
- ［1次］個人情報保護委員会「よくある質問」Q12-3（外国にあるサーバへの保存と外国にある第三者への提供、当該外国の制度等を把握した上での安全管理措置。令和3年9月更新）— 確認日2026年10月7日: https://www.ppc.go.jp/all_faq_index/faq1-q12-3/
- ［1次］個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日）別添1（1）②（個人データを含むプロンプトの入力と、機械学習に利用しないこと等の確認）— 確認日2026年10月7日: https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ ／ 別添1: https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf
- ［1次］デジタル庁「DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2025年5月27日 デジタル社会推進会議幹事会決定）— 用語（ISMAP・ISMAP-LIU・オンプレミス）、2.1 クラウド第一原則、3.1 ISMAP等クラウドサービスリストからの選定、3.2 データの所在地域と準拠法・データセンタは国内が基本・国外保管時の利用者自身の暗号鍵による保護と鍵管理、3.4 クラウドとオンプレミスを組み合わせる形態の回避 — 確認日2026年10月7日: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a612d406/20250619_resources_standard_guidelines_guideline_08.pdf
- ［1次］総務省・経済産業省「AI事業者ガイドライン（第1.2版）」本編（令和8年3月31日）— 共通の指針 6）透明性 ①検証可能性の確保（利用時の入出力等・判断根拠等のログの記録・保存、技術の特性及び用途に照らした記録方法・頻度・保存期間等の検討）、7）アカウンタビリティ ①トレーサビリティの向上 — 確認日2026年10月7日: https://www.soumu.go.jp/main_content/001064279.pdf
- ［公式］Ollama 公式サイト（”Ollama is an API for open models. Get inference locally or in the cloud”）— 確認日2026年10月7日: https://ollama.com/
- ［公式］Hugging Face「Meta Llama」組織ページ（各モデルのリポジトリでライセンス条項と利用規定に同意してアクセスする旨）— 確認日2026年10月7日: https://huggingface.co/meta-llama
- ［公式］Dify Docs「Deploy Dify with Docker Compose」（起動する中核サービスと、Weaviate・PostgreSQL・Redis等の依存コンポーネント）— 確認日2026年10月7日: https://docs.dify.ai/en/self-host/deploy/quick-start/docker-compose
- ［公式］n8n Docs「Host n8n」（自社のインフラ、オンプレミス、プライベートクラウドでのセルフホスト）・「Choose how to use n8n」（技術的な専門性がない場合はn8n Cloud、インフラと技術の体制がある場合はセルフホスト）— 確認日2026年10月7日: https://docs.n8n.io/deploy/host-n8n ／ https://docs.n8n.io/choose-how-to-use-n8n
- ［公式］WindyFlo 公式サイト（「ノード」のドラッグ＆ドロップ接続によるAIパイプライン構築、様々な大規模言語モデル（LLM）の利用、APIでの既存アプリ・サイトへの実装、お問い合わせ窓口）— 確認日2026年10月7日: https://www.windyflo.com/jp
- ［自社資料］ハマダラボ 会社資料（2026年9月）— 配備形態（SaaS・顧客クラウド・オンプレミス〔社内ネットワークへの設置・運用支援〕・ハイブリッド）、対応モデルの提供元13（OpenAI・Anthropic・Gemini・xAI・DeepSeek・Perplexity・Cohere・LLaMA・Ollama・Hugging Face・NVIDIA・Azure AI・AWS）、エンタープライズのパッケージ（オンプレミス／専用クラウドへの設置・既存システム連携・全社運用支援）、強み（文書処理・RAG）、「AI運用パートナー」という自社の位置づけ
