Azure OpenAIの閉域接続とローカルLLM、どちらが「外に出さない」を満たすか。データの所在・学習利用・不正監視・鍵・費用の5点で比較

Q: 処理を日本国内に限定できますか？

標準デプロイでは、プロンプトと応答は顧客が指定したジオグラフィ内で処理されます。ただしGlobalデプロイでは当該モデルが配備された任意のジオグラフィで、DataZoneデプロイでは指定データゾーン内で処理されることがあり、処理場所が広がります。保存データは顧客指定のジオグラフィに残ります。国内処理が要件なら、デプロイ種別の選択とプレビュー機能の扱いを確認してください。

Q: 併用する場合、何から始めればよいですか？

まず自社の業務をデータ区分で分け、外部保管禁止やインターネット非接続に当たる業務を特定します。その業務だけをローカルLLMの対象にし、それ以外はAzure OpenAIの閉域接続に載せます。ローカル側は全社向けのGPUサーバーである必要はなく、対象部門だけが使うMac StudioやDGX Spark 1台の構成で足りることが多いので、機材を買う前に社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）で置けるかを確かめてから進めると手戻りがありません。

「Azure OpenAIを閉域で使えば、機密データも大丈夫ですよね」。情報システム部門からこの相談を受けたとき、私たちはまず「閉域という言葉で何を閉じたいのか」を聞き返します。通信経路をインターネットから切り離したいのか、データの所在そのものを社内に閉じたいのか。この2つは別の要件で、Azure OpenAIのプライベートエンドポイントが満たすのは前者です。後者を求める業務にそのまま当てはめると、稟議が通ったあとで監査や取引先の確認に引っかかります。

本記事では、Microsoft Learnの公式資料（2026年10月3日確認）で確認できるAzure OpenAIの処理場所・学習利用・不正監視の仕様を土台に、Azure OpenAIの閉域接続・専用環境・ローカルLLMの3つを、データの所在・学習利用・不正監視と第三者アクセス・鍵と削除・費用の性格の5点で比較します。そのうえで、自社の要件がどれなら満たせるかを判定表にし、情報システム部門が設定で確認すべき項目をチェックリストにまとめます。なお、各社の規約と仕様は年に何度も改定されます。本記事の内容は確認日時点のものであり、契約時と年次の見直し時に必ず公式資料を再確認してください。

この記事の要点

「閉域」には、通信経路をインターネットから切り離す「閉域接続」と、データの処理・保存場所を社内に閉じる「閉域環境」の2つの意味があります。Azure OpenAIのプライベートエンドポイントが満たすのは前者です

Azure OpenAIは、プロンプトと生成結果を基盤モデルの学習に使わず、OpenAIにも提供しないと公式に明記しています。一方で、処理と保存はMicrosoftが管理するAzureのジオグラフィで行われ、不正監視で検知された場合には人のレビューのためにプロンプトが保存されます

人のレビューと保存を止めるには「modified abuse monitoring」の申請と承認が必要で、Limited Accessの追加要件を満たす顧客に限られます。承認後は自動レビューだけが行われます

「契約で社外保管が禁止されている」「インターネットに接続できない区画で使う」「事業者の従業員がアクセスし得る状態を許容できない」のいずれかに当たる業務は、閉域接続では満たせず、ローカルLLMかそれに準じる構成が必要です

現実解は二者択一ではなく併用です。規制や契約の要請がある業務だけをローカルLLMに載せ、それ以外はAzure OpenAIの閉域接続で最新モデルを使う構成が、費用と性能の両面で釣り合います

「閉域」には2つの意味がある（経路を閉じるか、所在を閉じるか）

まず言葉を揃えます。稟議書や取引先との確認で「閉域」と書かれているとき、指しているのは次のどちらかです。

意味	何を閉じるか	実現する手段	守れるもの	守れないもの
閉域接続（経路を閉じる）	自社とサービスの間の通信経路	プライベートエンドポイント、VPN、専用線	通信がパブリックインターネットに露出しない。社外からサービスのエンドポイントに到達できない	データはサービス事業者の環境で処理・保存される。事業者の運用に従う
閉域環境（所在を閉じる）	データの処理場所と保存場所	社内設置のローカルLLM、自社が管理する専有環境	データが自社の管理下から出ない。第三者の従業員がアクセスし得る状態を作らない	機材・運用・更新を自社で持つ必要がある

Azure OpenAIの「閉域化」「閉域接続」は前者です。プライベートエンドポイントを設定すると、社内のクライアントからAzure OpenAIへの通信はAzureの仮想ネットワークとMicrosoftのバックボーン上のプライベートリンクを通り、パブリックインターネットへの露出がなくなります。これは重要な対策ですが、プロンプトがMicrosoftの環境で処理されることは変わりません。

一方、「データを外に出せない」という要件の多くは後者を指しています。金融機関のFISC対応、医療の3省2ガイドライン、受託契約で外部保管を禁じられたデータ、LGWAN接続系のように、ネットワーク区分そのものが規程で決まっている場合です。この区別を最初につけておくと、以降の比較が読みやすくなります。データ区分ごとの基本的な使い分けは『生成AIの情報漏洩対策2026』で整理しているので、本記事はその最後の1段「社外送信が禁止されたデータ」をどう扱うかに絞ります。

Azure OpenAIの閉域接続で実際に何が起きるか

Microsoft Learnの「Configure Virtual Networks for Foundry Tools」（2026年2月17日更新）によると、Azure OpenAIを含むFoundry Toolsのリソースは、既定ではどのネットワークからの接続も受け付けます。閉域接続にするには、まず既定の動作を拒否に変え、そのうえで許可する経路を足していきます。選べる経路は3種類です。

経路	仕組み	向く用途	注意点
仮想ネットワークのサブネット許可	サービスエンドポイントを有効にした仮想ネットワークのサブネットからの要求だけを通す。最大100ルール	Azure上の業務システムから呼ぶ場合	サービスエンドポイントは経路の最適化であり、通信はAzure内で完結する
パブリックIP範囲の許可	自社ネットワークのインターネット側IPアドレスを登録する。最大100ルール、IPv4のみ、RFC1918の私設アドレスは登録不可	オンプレミスの拠点から固定IPで呼ぶ場合	通信はインターネット経由のまま。ExpressRouteのMicrosoftピアリングではNAT IPを登録する
プライベートエンドポイント	仮想ネットワークのアドレス空間からIPを割り当て、クライアントとリソースの通信を仮想ネットワークとAzureバックボーン上のプライベートリンクに乗せる	パブリックインターネットへの露出をなくしたい場合。オンプレミスからはVPN GatewayまたはExpressRouteのプライベートピアリングで仮想ネットワークにつなぐ	パブリックエンドポイントの全接続を遮断できる。仮想ネットワークからのデータ持ち出しの防止にも使える

「閉域接続」と呼ばれるのは3つ目のプライベートエンドポイントです。オンプレミスの社内LANからであれば、VPN GatewayかExpressRouteのプライベートピアリングで仮想ネットワークにつなぎ、その先のプライベートエンドポイント経由でAzure OpenAIを呼ぶ構成になります。

設定上の細かい点も公式資料に書かれています。Azure OpenAIは他のFoundry Toolsとは異なるプライベートDNSゾーンを使うこと、クライアントはリソースのカスタムサブドメインのURLを呼び、内部の*.privatelink.openai.azure.comを直接呼ばないこと、Foundry Tools・Azure Machine Learning・Azure Searchといった信頼されたAzureサービスにはマネージドIDで例外的にアクセスを許可できること、そしてネットワーク規則を有効にしてもEntra IDかAPIキーによる認可は別途必要なことです。最後の点は見落とされがちで、「閉域接続したから認証は緩くてよい」とはなりません。

閉域接続しても残るもの（処理場所・不正監視・デプロイ種別・プレビュー機能）

経路を閉じたあとに残るのは、データの所在に関わる4点です。Microsoft Learnの「Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry」（2026年5月18日更新）から読み取れる範囲で整理します。

1. 処理と保存はMicrosoftのジオグラフィで行われる。標準デプロイでは、プロンプトと応答は顧客が指定したジオグラフィ内で処理されます。運用上の理由でジオグラフィ内のリージョン間で処理されることはあります。保存データ（アップロードしたファイル、不正監視のデータストアを含む）も顧客指定のジオグラフィに保存されます。つまり「日本のジオグラフィ内」に収めることはできますが、「自社の管理下」に収めることはできません。

2. 学習には使われないが、不正監視で保存されることがある。プロンプト・生成結果・埋め込み・学習データは、他の顧客にもOpenAIなどのモデル提供元にも提供されず、顧客の許可や指示なしに基盤モデルの学習には使われないと明記されています。Azure OpenAIのモデルはMicrosoftのAzure環境でホストされ、OpenAIが運営するChatGPTやOpenAI APIとは一切やり取りしません。モデル自体はステートレスで、プロンプトはモデル内に保存されません。ただし、不正監視（abuse monitoring）は別です。自動レビューは既定で行われ、自動レビューの段階ではプロンプトは保存されませんが、検知された場合に人のレビューのために保存されるデータストアがあります。このデータストアは顧客リソースごとに論理分離され、顧客のリソースがあるジオグラフィに置かれます。人のレビューは不正監視システムが検知した場合に限られ、権限を持つMicrosoft従業員がSecure Access WorkstationとJust-In-Time承認を経て行います。

3. デプロイ種別で処理場所が広がる。「Global」と「DataZone」というデプロイ種別では、処理場所が標準デプロイより広がります。Globalでは当該モデルが配備された任意のジオグラフィで処理されることがあり、DataZoneでは指定されたデータゾーン内（米国のリソースなら米国内、EU加盟国のリソースならEU内）で処理されます。保存データは顧客指定のジオグラフィに残りますが、処理場所は変わります。「日本国内で処理する」ことが要件なら、デプロイ種別の選択がそのまま適合性を左右します。

4. プレビュー機能は条件が異なることがある。保存を伴う機能（Files API、Responses API、Assistants、Stored completionsなど）のデータは顧客テナントのリソース内に同一ジオグラフィで保存され、AES-256で暗号化され、顧客管理キーも選べ、顧客がいつでも削除できます。一方で、プレビュー段階の機能やモデルは、これらの条件や不正監視の扱いが異なる場合があると明記されています。業務で使う機能がプレビューかどうかの棚卸しが必要です。

4点のうち、閉域接続の設定で解消されるものは1つもありません。経路の対策と所在の対策は独立している、というのがここでの結論です。

modified abuse monitoringとは何か（人のレビューと保存を止める申請）

残るもののうち、2点目の「不正監視で保存され、人がレビューし得る」は、多くの規制業種で最初に問題になります。Microsoft Learnの「Foundry Models sold by Azure abuse monitoring」（2026年5月13日更新）によると、不正監視はコンテンツ分類、不正パターンの検出、レビューと判定、通知と措置の4つで構成され、レビューには自動レビューと人のレビューがあります。

機微性や機密性の高いデータを扱う顧客、あるいはMicrosoftによる保存と人のレビューを許可できない顧客は、Limited Accessの追加要件を満たせば「modified abuse monitoring」を申請できます。承認されると、人のレビューのための保存と人のレビューは行われなくなります。自動レビューは引き続き行われることがあり、重大または繰り返しの不正が検知された場合はアクセス制限の対象になり得ます。高度なモデルでは申請の要件がより厳しい場合があるとも書かれています。

承認後に保存が無効になっているかは、Azure portalのリソース概要のJSONビュー、またはAzure CLIで、ContentLoggingの値がfalseになっていることで確認できます。この属性は保存が無効のときだけ表示されるため、表示されていなければ保存は有効です。監査対応では、この確認結果を証跡として残しておくと説明が早くなります。

ここで押さえておきたいのは、modified abuse monitoringは「申請して承認を受ける」ものであり、設定画面で切り替えるものではないことです。稟議の段階で「閉域接続すれば人のレビューはない」と書いてしまうと、後から要件不一致になります。

5点比較表: Azure OpenAI閉域接続・専用環境・ローカルLLM

ここまでの整理を、3つの構成で5点比較にまとめます。「専用環境」は、クラウド事業者が顧客専有で提供する閉域の環境を一般的に指す言葉として使い、個別製品の仕様には踏み込みません。

比較点	Azure OpenAI 閉域接続	専用環境（閉域のクラウド専有環境）	ローカルLLM（社内設置）
データの所在	Microsoftが管理するAzureのジオグラフィ内。標準デプロイでは指定ジオグラフィ、Global/DataZoneでは処理場所が広がる	事業者が管理する専有区画。所在と専有の範囲は契約で決まる	自社の建物内または自社が管理するデータセンター。処理も保存も自社管理下
学習利用	基盤モデルの学習に使わない、OpenAIに提供しないと公式に明記	事業者の規約・契約次第。学習利用なしの明記を契約で確認する	そもそも外部に出ないため学習利用は発生しない
不正監視と第三者アクセス	自動レビューは既定で実施。検知時は人のレビューのために保存され、権限を持つMicrosoft従業員が閲覧し得る。modified abuse monitoringの承認で人のレビューと保存を停止	事業者の運用次第。監視の有無、閲覧権限、ログの扱いを契約で確認する	第三者のアクセスは発生しない。ただし社内の監視・ログ設計は自社で持つ必要がある
鍵と削除	保存データはAES-256で暗号化、顧客管理キーも選択可、顧客がいつでも削除可。プレビュー機能は条件が異なる場合あり	契約で確認。鍵の管理主体と削除の証跡を確認する	鍵も削除も自社で管理。返却・廃棄時の消去手順を自社で定める
費用の性格	従量課金が基本で、利用量に比例する。予約や割引の仕組みはあるが、使わない月も固定費がかかる機材とは性格が違う	専有のため固定費の性格が強い。契約単位で決まる	初期費用（機材）と固定の運用費。利用量が増えても追加費用は電気代と保守にとどまる

比較表で見えるのは、Azure OpenAIの閉域接続は「学習利用」と「鍵と削除」で十分な保証を持つ一方、「データの所在」と「不正監視と第三者アクセス」では事業者の管理下にある、ということです。これが要件に合うかどうかは、次の判定表で確かめます。

要件別の判定表: どれなら満たせるか

「外に出さない」という言葉の中身を、よく出てくる6つの要件に分解しました。自社の規程・契約・取引先の要求から該当するものを拾い、どの列で満たせるかを確認してください。

要件	Azure OpenAI 閉域接続	閉域接続＋modified abuse monitoring	ローカルLLM
通信経路をインターネットに露出させない	満たす（プライベートエンドポイント）	満たす	満たす（社内LANのみ、または完全閉域）
入力を基盤モデルの学習に使わせない	満たす（公式に明記）	満たす	満たす
事業者の従業員がプロンプトを閲覧し得る状態を作らない	満たさない（検知時に人のレビューあり）	満たす（承認後は人のレビューと保存なし。自動レビューは残る）	満たす
処理と保存を日本国内に限定する	標準デプロイで指定ジオグラフィに限定できる。Global/DataZoneは不可	同左	満たす
契約・規程でデータの外部保管そのものが禁止されている	満たさない（事業者の環境に保存される）	満たさない	満たす
インターネットに接続できない区画（LGWAN接続系など）で使う	満たさない（Azureへの経路が必要）	満たさない	満たす（完全閉域またはネットワーク分離）
最新のフロンティアモデルの性能が業務に必要	満たす	満たす	満たさない場合がある（オープンウェイトモデルの範囲内）

上から4行目までが要件のすべてなら、Azure OpenAIの閉域接続、必要に応じてmodified abuse monitoringの申請で足ります。5行目と6行目のどちらかが該当するなら、ローカルLLMでなければ満たせません。最後の行は逆方向の制約で、ローカルLLMを選ぶと性能面で妥協が必要になる業務があります。この表の2方向の制約が同時に効く組織は少なくなく、それが次の併用構成につながります。

規制業種ごとの要件の読み方は、金融機関を『金融機関のローカルLLM導入』、自治体を『自治体のローカルLLM』、医療機関を『医療機関のローカルLLM』で扱っています。

ローカルLLM側に残るもの（ローカルにすれば安全ではない）

判定表の右列が有利に見えますが、ローカルLLMは「第三者のアクセスが発生しない」代わりに、「自社で守らなければならないもの」が増えます。Azure OpenAIでは事業者側が担っている、推論サーバーの認証と露出対策、モデルファイルの供給網の検証、脆弱性修正の適用、アクセス制御、ログと監査の設計が、すべて自社の仕事になります。

とくに、推論サーバーの既定設定のまま社内に置いて認証なしで待ち受けている状態、持ち込んだモデルファイルの検証をしていない状態、閉域にした結果として更新が止まっている状態の3つは、相談の現場で繰り返し見かけます。これらは「ローカルだから安全」という思い込みと表裏の関係にあります。7つに分解した残るリスクと対策は『ローカルLLMは本当に安全か』に、インターネットにつながない構成で困る作業とその対処は『生成AIをオフラインで使う2026』にまとめています。

比較の公平性のために言えば、Azure OpenAIの不正監視は「事業者が第三者として見得る」という要件上の論点であると同時に、有害な利用を検知する仕組みでもあります。ローカルLLMでは、その役割も自社で設計することになります。

併用構成が現実解になる場合（規制業務だけローカル、それ以外はAzure閉域）

判定表で「外部保管禁止」や「インターネット非接続」に該当する業務がある一方、「最新モデルの性能が必要」な業務も抱えている組織は、二者択一をしないのが現実的です。

業務の区分	置き場所	理由
契約・規程で外部保管が禁止されたデータを扱う業務	ローカルLLM（社内設置）	閉域接続では要件を満たせない
社内情報を扱うが外部保管は禁止されていない業務	Azure OpenAI 閉域接続（必要ならmodified abuse monitoring）	学習利用なし・鍵と削除の保証があり、最新モデルを使える
公開情報や一般的な調べもの	法人契約のクラウド	閉域接続の構成を使うまでもない

併用で重要なのは、利用者から見て「どの業務ではどちらを使うか」が迷わず分かることです。入口を2つ用意しても、現場が判断に迷えば楽なほうに流れ、結局は規制対象のデータがクラウド側に入ります。データ区分と使ってよい環境の対応表を規程に落とし、チャットUIの側でも業務別に入口を分けておくと、運用が安定します。

ローカルLLM側の規模は、併用であれば全社向けのGPUサーバーである必要はありません。規制対象の業務に関わる部門だけが使う前提なら、Mac Studio 1台やDGX Spark 1台の構成で足りることが多く、置けるかどうかは機材を買う前に確かめられます。社内に置く前の確認項目は『ローカルLLMを社内サーバーとして置く前に確認する10項目』、少人数の会社での現実的な構成は『中小企業のローカルLLM2026』を参照してください。

費用の性格の違い（従量と固定）

費用は金額の大小より先に、性格の違いを押さえます。Azure OpenAIは利用量に比例する従量課金が基本で、予約などの仕組みはあるものの、使った分だけ払う構造です。ローカルLLMは機材の初期費用と固定の運用費が中心で、利用量が増えても追加費用は電気代と保守にとどまります。

この性格の違いから、損益の分岐は「どれだけ使うか」で決まります。『オンプレLLMは本当に安いのか』で整理しているとおり、オンプレミスが有利になるのは高稼働が前提で、オンデマンドのクラウドとの比較で1日約5時間、3年コミット割引との比較で1日約8.9時間の稼働が損益分岐の目安です。最大の隠れコストは運用人件費で、専任0.3人でも年250万円前後、3年で750万円になり、単一GPUサーバーではハード代を超えることもあります。

ただし、本記事の文脈では費用の比較の前に要件の判定があります。「外部保管禁止」の業務を抱えているなら、Azure OpenAIがいくら安くても選べません。費用の比較が意味を持つのは、判定表で両方が候補に残った業務だけです。併用構成でローカル側を小さく抑えるのは、この費用の性格の違いを踏まえた設計でもあります。

情シスが確認する設定チェックリスト

稟議や監査の説明に使えるよう、確認項目を並べます。Azure側は本記事で参照した公式資料に基づく項目、ローカル側は別記事の要点です。

Azure OpenAI 閉域接続側

ローカルLLM側

要件が「外部保管禁止」または「インターネット非接続」のどちらに由来するかを特定し、完全閉域かネットワーク分離かを決めた
推論サーバーの待ち受けと認証、モデルファイルの検証、更新の手順を設計した（『ローカルLLMは本当に安全か』）
設置場所・電源・騒音・担当者を確認した（『ローカルLLMを社内サーバーとして置く前に確認する10項目』）

共通

データ区分ごとに使ってよい環境を規程に書き、利用者の入口を業務別に分けた
個人データを含むプロンプトを入力する業務では、個人情報保護委員会の注意喚起に沿って学習利用の有無と利用目的の範囲を確認した
規約・仕様の確認日を記録し、契約時と年次見直し時の再確認を予定に入れた

まとめ

「閉域」には通信経路を閉じる閉域接続と、データの所在を閉じる閉域環境の2つの意味があり、Azure OpenAIのプライベートエンドポイントが満たすのは前者です
Azure OpenAIは学習利用なし・OpenAIへの非提供を公式に明記していますが、処理と保存はMicrosoftのジオグラフィで行われ、不正監視で検知された場合は人のレビューのためにプロンプトが保存されます。これを止めるにはmodified abuse monitoringの申請と承認が必要です
「外部保管そのものが禁止」「インターネットに接続できない区画で使う」のどちらかに当たる業務は、閉域接続では満たせずローカルLLMが必要です。逆に最新モデルの性能が必要な業務はローカルで妥協が生じることがあります
現実解は併用です。規制業務だけをローカルLLMに載せ、それ以外はAzure OpenAIの閉域接続で最新モデルを使い、入口を業務別に分けます
ローカルLLMは第三者のアクセスが発生しない代わりに、認証・供給網の検証・更新・ログ設計を自社で持ちます。費用は従量と固定の性格が違い、比較は要件の判定で両方が残った業務にだけ意味があります

よくある質問

Q. Azure OpenAIを閉域接続すれば、機密データを入力しても問題ありませんか？

要件によります。閉域接続（プライベートエンドポイント）で守れるのは通信経路で、プロンプトがMicrosoftの管理するAzureのジオグラフィで処理・保存されることは変わりません。学習利用なしは公式に明記されていますが、不正監視で検知された場合は人のレビューのために保存され得ます。「契約や規程でデータの外部保管そのものが禁止されている」データは、閉域接続では要件を満たせません。

Q. Azure OpenAIに入力したデータはOpenAIに渡りますか？

Microsoft Learnの公式資料では、プロンプト・生成結果・埋め込み・学習データはOpenAIなどのモデル提供元には提供されず、モデル提供元のモデル改善にも使われないと明記されています。Azure OpenAIのモデルはMicrosoftのAzure環境でホストされ、OpenAIが運営するChatGPTやOpenAI APIとはやり取りしません。これは2026年10月3日の確認時点の内容で、規約は改定されるため契約時に再確認してください。

Q. 不正監視で人がプロンプトを見ることはあるのですか？

あります。自動レビューは既定で行われ、その段階ではプロンプトは保存されませんが、検知された場合は人のレビューのために保存され、権限を持つMicrosoft従業員がSecure Access WorkstationとJust-In-Time承認を経て閲覧し得ます。これを許容できない場合は、Limited Accessの追加要件を満たしたうえでmodified abuse monitoringを申請します。承認後は人のレビューと保存が行われず、自動レビューのみになります。

Q. 処理を日本国内に限定できますか？

標準デプロイでは、プロンプトと応答は顧客が指定したジオグラフィ内で処理されます。ただし「Global」デプロイでは当該モデルが配備された任意のジオグラフィで、「DataZone」デプロイでは指定データゾーン内で処理されることがあり、処理場所が広がります。保存データは顧客指定のジオグラフィに残ります。国内処理が要件なら、デプロイ種別の選択と、プレビュー機能の扱いを確認してください。

Q. ローカルLLMにすれば、こうした確認は不要になりますか？

第三者のアクセスや処理場所の確認は不要になりますが、代わりに推論サーバーの認証と露出対策、モデルファイルの供給網の検証、脆弱性修正の適用、アクセス制御、ログと監査の設計を自社で持つことになります。推論サーバーを既定設定のまま認証なしで置く、持ち込んだモデルを検証しない、閉域にした結果として更新が止まる、の3つは実際によく起きています。「ローカルだから安全」にはなりません。

Q. 併用する場合、何から始めればよいですか？

まず自社の業務をデータ区分で分け、「外部保管禁止」「インターネット非接続」に当たる業務を特定します。その業務だけをローカルLLMの対象にし、それ以外はAzure OpenAIの閉域接続に載せます。ローカル側は全社向けのGPUサーバーである必要はなく、対象部門だけが使うMac StudioやDGX Spark 1台の構成で足りることが多いので、機材を買う前に社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）で「置けるか」を確かめてから進めると、手戻りがありません。

主な参考資料: Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry（Microsoft Learn）、Foundry Models sold by Azure abuse monitoring（Microsoft Learn）、Configure Virtual Networks for Foundry Tools（Microsoft Learn）、OpenAI API「Your data」、個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」

TodoONadaでは、Azure OpenAIの閉域接続で足りる業務と、ローカルLLMでなければ満たせない業務の切り分けから、併用構成の設計・ローカル側の構築・運用までを支援しています。ローカル側の規模感を確かめる最初の一歩として、DGX SparkやMacを貴社オフィスに設置して2週間で判定する社内設置の実現性検証（30万円〜・税別・機材貸出料込み）と、機材のみの短期貸出（1週4.5万円〜・税別）を承っています。「うちの要件はどちらの列に当たるのか」という判定の相談だけでも歓迎します。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。