生成AIのローカルLLMと外部APIの選び方：機密データ・品質・総費用の比較

社内の資料や顧客の情報を扱う業務に生成AIを使うとき、「機密情報があるから社内で動かしたい」「事業者のAPI（プログラムからAIを呼び出す仕組み）の料金を抑えたい」という要望から検討が始まることがあります。検討では、どちらの方式が優れているかより先に、業務とデータの条件に合う配置を考えます。

ローカルLLMでも、推論（入力から回答を作る処理）はAPIで呼び出せます。例えばOllamaは、初期設定では同じ機器の中（127.0.0.1）からの接続だけを受け付けるAPIを用意しています（Ollama：FAQ）。比べるのは「APIを使うかどうか」ではなく、モデルがどこで動き、誰が運用するかです。

表は横にスクロールできます →

クラウド上の自己運用は、自社の建物に機器を置くオンプレミスとは異なり、事業者がモデルを運用する外部APIとも異なります。併用は、これらを業務ごとに組み合わせる方法で、どれかより上位の方式ではありません。組み合わせる場合は、どの業務をどの方式で扱うかの振り分けと、両方の運用が必要になります。

ローカルLLMを購入・構築することが結論とは限りません。外部API、クラウド上の自己運用、併用のほか、今の手順の改善や、導入を見送ることも選択肢に含めて比べます。

モデルを社内に置いても、情報が外部へ送られないとは限りません。生成AIを使う業務では、次の経路ごとに、送り先と残る場所を確かめます。

1. 入力：利用者が入力する文章や添付のファイル
2. 参照資料：検索や埋め込み（文章を検索用の数値に変換する処理）に使う資料と、その保存先
3. 推論：モデルが動く場所
4. 出力：回答の表示先と保存先
5. ログ・監視：入力や回答の記録と、監視・分析のサービス
6. 保存・バックアップ：会話の履歴、ファイル、バックアップの置き場所
7. 連携先：回答を書き込む業務システムや、外部の検索・ツール

Difyやn8nを社内で運用していても、接続するモデルや埋め込み、検索、監視が外部のサービスなら、その経路の情報は外部へ送られます。基盤の運用の分担はDify・n8nのセルフホスト運用で扱っています。ローカルで動かす実行ソフトにも、外部のモデルや検索を使う機能がある場合があります。例えばOllamaは、手元で動かすモデルとは別にクラウドで動くモデルを提供しており、クラウドの機能を使わない設定も用意しています（Ollama：FAQ）。使う機能と設定を確かめます。

外部APIでは、次の4つを別々に確かめます。「学習に使われない」ことと「保存されない」ことは同じではありません。国内の地域を指定しても、すべての処理が国内で行われるとは限りません。

• 学習利用：入力や回答が、モデルの学習や改善に使われるか
• 保持：監視や機能のために、どの記録がどのくらいの期間残るか
• 処理・保存の地域：処理する場所と、保存する場所
• アクセス権：誰がデータを閲覧・管理できるか

例えばOpenAIのAPIでは、送ったデータは、共有を選ばない限り学習や改善に使われないとされています。一方で、不正な利用を監視するための記録（監視ログ）は既定で最大30日保持され、会話の状態など、機能が動くために保存するデータの扱いは機能ごとに異なります。

監視ログから顧客のコンテンツを除外するZero Data Retention（ZDR）やModified Abuse Monitoring（MAM）には、OpenAIの事前の承認などの条件があります。対象外の機能や例外もあるため、使う機能ごとの保存の条件は別に確認します。地域の指定には利用できるかの確認が必要で、地域での保存に対応していても、地域での処理に対応するとは限らないと説明されています（OpenAI：Data controls）。

Microsoft Foundryでは、配置の種類がGlobalやDataZoneの場合、指定した地域の外で処理されることがあり、保存するデータは指定した地域に置かれると説明されています（Microsoft Learn：Foundryのデータとプライバシー）。OpenAIとMicrosoft Foundryの説明は、いずれも事業者ごとの仕様の例で、ほかのAPIにそのまま当てはまるとは限りません（確認日：2026年10月現在）。

社内の規程や取引先との契約で外部へ送れない情報は、方式を選ぶ前に確認します。氏名などを置き換えて匿名化しても、それだけで規程や契約の条件を満たすとは限りません。入力してよい情報の区分は企業のAI利用ルールブックで扱っています。

方式を比べるときは、同じ業務・同じ入力・同じ期待する結果で比べます。一般的なベンチマークの点数だけで採用を決めず、実際の業務の資料や問い合わせに近い題材で確かめます。すべての方式で同じモデルを使う必要はありませんが、業務の条件はそろえます。

確認する項目は次のとおりです。

• 期待する結果と、重大な誤りの条件（金額や期限の誤り、根拠のない断定など）
• 日本語と、社内の用語の扱い
• 決まった形式での出力（項目の抽出など）や、外部のツールの呼び出し
• 人の確認・修正にかかる時間
• 入力の長さや、同時に使う人数による待ち時間
• 権限の外にある情報を答えないこと
• 失敗したときに、人の手順へ引き継げること

平均の点数で、重大な誤りを相殺しません。業務の評価表と本番へ進む条件は生成AIを業務へ組み込む方法で、社内の資料を検索して答えるRAGの評価は社内ナレッジを活用するRAGシステムの構築で扱っています。RAGは、ローカルLLMでも外部APIでも構成できます。

ローカルLLMやクラウド上の自己運用では、機材（クラウドでは仮想マシンとGPUの選定・契約）と運用を自社や委託先で担います。必要なメモリーやGPUのメモリー（VRAM）は、モデルの大きさだけでなく、入力の長さや同時に処理する件数でも変わります。例えばOllamaでは、必要なメモリーは、同時に処理する数と扱う入力の長さに応じて増えると説明されています（Ollama：FAQ）。人数や業務の名前だけから、必要な機材は決められません。対象の業務と同時に使う条件で試して確かめます。

運用では、次の分担を決めます。

• 利用者の権限と、APIの鍵の管理
• モデルと実行ソフトの更新と、更新する前の確認
• ログの保存先、保存の期間、閲覧できる人
• 障害のときの復旧と、代わりの手順
• 利用の上限（同時に使う人数、入力の長さ、使ってよい業務）
• 社内のネットワークへの公開の範囲

実行ソフトのライセンスと、モデルのライセンスは別に確認します。ダウンロードできる公開のモデルでも、商用での利用、用途、表示などの条件はモデルごとに異なります。Hugging Faceでも、モデルのライセンスはリポジトリごとに示され、使う前に確認するよう案内されています（Hugging Face：Licenses）。

外部APIでは機材の運用は事業者が担いますが、契約、利用の上限、鍵と権限、ログの扱い、障害や仕様の変更のときの代わりの手順は、自社で決めます。

費用は、同じ比較期間、同じ業務の件数、入力と出力の長さ、同時に使う人数、求める品質と人の確認の条件をそろえて比べます。次の表は、方式ごとに確認する項目です。料金は事業者や契約で変わるため、この記事では金額は載せません。

表は横にスクロールできます →

支出（購入費・利用料・委託費）と、社内の作業時間は分けて数えます。機器の購入費と、その減価償却費を同じ合計に入れると、二重に数えることになります。金額が分からない項目は0円にせず、確認できた小計とは別の欄に残します。比較の条件がそろわない提案を、小計だけで安い順に並べることはしません。

次は、条件から候補を絞る検討例です。試験の結果や導入の実績ではなく、記録の書き方を示す例です。

• 条件：入力は社外に公開済みの資料。社内の規程で、外部APIの利用が認められている。
• 候補：外部API。機材と運用の担当がいる場合は、ローカルLLMも比べる。
• 未確認：出力の保存先、利用の記録の保持、利用者の権限。
• 次の確認：規程の承認者が送り先を確認し、同じ下書きの作業で試す条件と、人が確認する箇所を決める。

• 条件：契約と社内の規程で、資料を外部へ送ることが認められていない。抽出した項目は人が確認する。
• 候補：社内のサーバーで動かすローカルLLM。規程と契約で認められる範囲なら、クラウド上の自己運用も比べる。
• 未確認：必要な品質、機材と運用の担当、モデルのライセンス、ログの保存先。
• 次の確認：同じ資料の抽出の作業で限定して試し、品質・待ち時間・運用の担当を確かめる。

外部へ送れないからといって、ローカルLLMの採用がすぐに決まるわけではありません。品質や運用の担当の条件を満たせなければ、見送りや今の手順の改善も選びます。障害や能力の不足のときに、機密のデータを自動で外部APIへ送る仕組みにはしません。切り替えが必要な場合は、送ってよい情報と承認の手順を先に決めます。

• 条件：社内の規程集など、規程で外部へ送れない資料を参照して答える問い合わせと、公開されている情報の要約の、2つの業務がある。
• 候補：外部へ送れない資料を参照する業務は、社内の環境で動かすローカルLLM。クラウド上の自己運用は、その環境への送信と保存が規程と契約で認められる場合に限って比べる。公開の情報を扱う業務は、規程と契約で利用が認められた外部API。
• 未確認：業務を振り分ける方法、誤って送らない仕組み、両方の運用の担当、合計の費用。
• 次の確認：業務ごとに認める送り先を決めて記録し、振り分けの仕組みを試す。

方式を決める前に、次の項目を記録します。項目を埋めたことは、合格を意味しません。必須の条件に未確認の項目が残る場合は、未確認のまま記録します。

表は横にスクロールできます →

判断は、「範囲を限って試す」（対象の業務と利用者を限る）、「確認を続ける」（未確認の項目を確かめてから決める）、「見送る」（今の手順の改善を含めて、別の方法を選ぶ）のいずれかとし、根拠と判断した人を記録します。

最後に、方式を選ぶときによくいただく質問にお答えします。