生成AI関連
ローカルLLM入門：機密情報を外部に送らずに生成AIを活用する選択肢
前回の記事では、ローカルLLMの基本的な考え方、クラウドLLMとの違い、業務利用でのメリットと注意点を整理しました。
ローカルLLMは、外部サービスに送信しづらいデータを扱う場合や、閉域環境で生成AIを活用したい場合に検討しやすい選択肢です。一方で、実際に使い始めるには、モデルの取得、実行環境、応答速度、メモリ使用量、アプリケーションからの呼び出し方など、具体的に確認すべき点があります。
本記事では、ローカルLLMの実行環境として広く使われているOllamaを取り上げます。CLIからモデルを呼び出す方法と、PythonからOllamaを呼び出してアプリケーションに組み込む方法を確認しながら、前回の記事で詳しく扱えなかったモデル選定や運用上の注意点も補足します。
なお、本記事の目的は本番環境の構築ではなく、検証環境でローカルLLMの特性を把握することです。業務データを扱う場合は、社内のセキュリティルールやライセンス条件を確認したうえで検証してください。
Ollamaは、オープンウェイトのLLMをローカル環境で扱うためのツールです。モデルの取得、実行、管理をCLIから行えるほか、ローカルAPI経由でアプリケーションから呼び出せます。
Ollamaを使うと、次のような操作を比較的少ない手順で行えます。
なお、Ollama自体はLLMのモデルではありません。Ollamaは、Llama、Gemma、Qwen、Mistralなどのモデルをローカル環境で扱うための実行・管理ツールと捉えると理解しやすくなります。
Ollamaの公式ドキュメントでは、CLI、REST API、Pythonライブラリ、JavaScriptライブラリが案内されています。最初の検証ではCLIで動作確認し、その後にAPIやPythonライブラリから呼び出す流れにすると、問題を切り分けやすくなります。
| 利用方法 | 主な用途 |
|---|---|
| CLI | モデルの取得、対話、動作確認 |
| REST API | 任意のアプリケーションからHTTPで呼び出す |
| Pythonライブラリ | Pythonアプリケーションや検証スクリプトに組み込む |
| JavaScriptライブラリ | WebアプリケーションやNode.js環境から利用する |
Ollamaをインストールする前に、検証環境の前提を確認しておきます。ローカルLLMは、同じモデルを使っていても、PCやサーバーの性能によって応答速度や同時実行性能が大きく変わります。
特に確認したい項目は次のとおりです。
OllamaはmacOS、Windows、Linuxに対応しています。また、GPUを使える環境では推論速度の面で有利になることがあります。公式ドキュメントでは、NVIDIA GPU、AMD GPU、AppleのMetalなどに関する対応情報も案内されています。
ただし、手元のPCでモデルが動作したとしても、その結果をそのままチーム利用や本番利用の性能見積もりに使うのは適切ではありません。本番利用を検討する場合は、想定する利用者数、入力文量、出力文量、同時実行数、応答時間を別途測定する必要があります。
Ollamaのインストール方法はOSによって異なります。公式サイトからインストーラーを取得する方法のほか、Linuxではインストールスクリプトを使う方法も案内されています。
詳細な手順は、Ollamaの公式ドキュメントを確認してください。ダウンロードページを確認し、各OSに合った方法でインストールをしてください。
Download Ollama
インストール後、まず利用するモデルを取得します。本記事のデモでは、CPUや個人PCでも試しやすい超軽量モデルとしてgemma3:270mを使います。利用可能なモデルは時期によって変わるため、実際に検証する際はOllama Libraryでモデル名、サイズ、ライセンス、説明を確認してください。
モデルを事前に取得する場合は、次のコマンドを使います。
ollama pull gemma3:270m
インストール済みのモデル一覧は、次のコマンドで確認できます。
ollama ls
不要になったモデルは、次のように削除できます。
ollama rm gemma3:270m
モデルは大きいものだと、数十GBから数百GBになることがあります。複数のモデルを比較する場合は、ストレージ容量にも注意してください。
最初のデモでは、CLIからローカルLLMを呼び出します。ここでは、ローカルLLMの品質を厳密に評価する前段階として、モデルが取得できること、応答が返ること、応答速度の目安を確認することを目的にします。
まず、デモ用のモデルを起動します。ここでは、CPUや個人PCでの検証を想定し、gemma3:270mを使います。
ollama run gemma3:270m
対話モードに入ったら、次のようにプロンプトを入力します。
社内FAQの回答案を作る用途で、ローカルLLMを検証するときの確認観点を1つだけ挙げてください。
下記のようにCLI上で回答が返ってくれば、モデルの取得と推論ができていることを確認できます。
CLIでの検証では、少なくとも次の点を意識・記録しておくと後続の比較に役立ちます。
| 観点 | 確認内容 |
|---|---|
| 応答速度 | 依頼を入力してから回答が出始めるまでの時間 |
| 出力品質 | 指定した条件や形式を守れているか |
| 安定性 | 同じ依頼で極端に結果が変わらないか |
| リソース使用量 | メモリやGPU使用率が想定内か |
| モデルサイズ | モデルの容量が検証環境に合っているか |
また、起動中のモデルや使用状況は次のコマンドで確認できます。
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gemma3:270m e7d36fb2c3b3 325 MB 100% CPU 4096 4 minutes from now
ollama psでは、モデルの実行状態、プロセッサ、コンテキスト長などを確認できます。コンテキスト長を大きくすると、長い入力を扱いやすくなる一方で、必要なメモリも増えます。その他のCLI操作については、OllamaのCLI Referenceを参照してください。
次に、PythonからOllamaを呼び出します。CLIで動作確認できたモデルを、アプリケーションの一部として利用するイメージです。
Ollamaには公式のPythonライブラリがあります。ここでは、uvを使って小さな検証用プロジェクトを作成します。
Pythonコードで指定するモデルは、事前にOllamaへ取得済みである必要があります。指定できるモデル名は、ollama lsで確認できます。未取得の場合は、先に次のようにモデルを取得してください。
Ollamaが起動していない場合は、別のターミナルで次のコマンドを実行します。
ollama serve
次に、app.pyを作成します。
import os
from ollama import Client
DEFAULT_MODEL = os.getenv("OLLAMA_MODEL", "gemma3:270m")
DEFAULT_HOST = os.getenv("OLLAMA_HOST", "http://localhost:11434")
def ask_ollama(text: str, model: str = DEFAULT_MODEL, host: str = DEFAULT_HOST) -> str:
client = Client(host=host)
response = client.chat(
model=model,
messages=[
{
"role": "user",
"content": text,
},
],
)
return response.message.content
if __name__ == "__main__":
text = "Ollamaについて簡潔に教えてください。"
print(ask_ollama(text))
次のコマンドで実行します。
uv run app.py
この例では、短い質問を受け取り、Ollama経由でモデルの回答を取得する小さな関数を作成しています。実際のアプリケーションに組み込む場合は、HTTP APIの1処理として呼び出す、バッチ処理で複数件の問い合わせを処理する、社内ツールの補助機能として回答案を生成する、といった形が考えられます。
なお、OllamaのローカルAPI自体には、取得済みモデルごとの利用可否を細かく制御する標準的な権限設定はありません。共有環境で利用する場合は、使わせたいモデルだけを配置する、アプリケーション側でモデル名を固定する、Ollamaを直接公開せずバックエンドやリバースプロキシ経由で呼び出す、といった設計が必要です。
また、アプリケーションに組み込む場合は、CLIで使う場合よりも確認項目が増えます。
| 観点 | 確認内容 |
|---|---|
| タイムアウト | モデルの応答が遅い場合に処理を止められるか |
| エラーハンドリング | Ollamaが停止している場合やモデルがない場合に扱えるか |
| 同時実行 | 複数ユーザーからのリクエストに耐えられるか |
| ログ | 入力データや生成結果をどこまで記録するか |
| 出力形式 | 後続処理で扱いやすい形式にできるか |
業務アプリケーションに組み込む場合は、生成結果をそのまま確定情報として扱うのではなく、下書き、分類候補、確認補助として利用する設計が現実的です。特に問い合わせ分類や回答案作成では、人が確認する前提を置くことで、誤分類や不正確な回答による影響を抑えやすくなります。
OllamaでローカルLLMを検証する際は、どのモデルを使うかが重要です。同じOllama上で動かす場合でも、モデルによって必要なメモリ、応答速度、日本語の扱いやすさ、出力品質が変わります。
Ollamaで利用できるモデルは、Ollama Libraryで確認できます。各モデルのページでは、モデルの概要、サイズ、コンテキスト長、対応モーダル、更新日、ライセンスなどを確認できるため、検証前に利用候補を見ておくとよいです。
モデル選定では、少なくとも次の観点を確認します。
この中でも、最初に見ておきたいのはモデルサイズとコンテキスト長です。
パラメータ数が大きいモデルは、一般に高い性能を期待しやすい一方で、必要なメモリ等が増えます。小さいモデルは動作させやすい一方で、複雑な推論、長文の理解、厳密な出力形式の維持では限界が出ることがあります。
コンテキスト長は、モデルが一度に参照できる入力や会話履歴の長さに関わります。OllamaのContext lengthでは、VRAMに応じたデフォルトのコンテキスト長や、コンテキスト長を大きくすると必要メモリが増えることが説明されています。
長い文書を扱いたい場合でも、コンテキスト長を大きくすれば常に解決するわけではありません。入力が長いほど必要なメモリが増え、応答速度にも影響します。また、長文のすべてを正確に扱えるとは限らないため、文書の分割、要約、検索、RAGの設計も合わせて検討する必要があります。
最初の検証では、モデルサイズ、応答速度、出力品質のバランスを見ながら比較すると判断しやすくなります。
| 観点 | 小さめのモデル | 大きめのモデル |
|---|---|---|
| 動作環境 | 一般的なPCでも試しやすい | GPUや十分なメモリが必要になりやすい |
| 応答速度 | 速くなりやすい | 遅くなりやすい |
| 出力品質 | 単純な分類や要約に向く | 複雑な推論や長文処理で有利になりやすい |
| 検証コスト | 比較しやすい | 検証環境の準備が重くなりやすい |
進め方としては、次のような順序にすると課題を切り分けやすくなります。
Ollamaを使うと、手元の環境でローカルLLMを動かしやすくなります。しかし、ローカルで動いていることと、業務利用として安全に運用できることは別の問題です。
まず、モデルの取得時には外部通信が発生します。モデルのダウンロード元、ライセンス、利用規約、配布条件を確認してください。オープンウェイトのモデルであっても、商用利用、再配布、改変、生成物の扱いに条件がある場合があります。
次に、OllamaのAPIを不用意に外部へ公開しないことが重要です。OllamaのローカルAPIは、初期検証では手元のアプリケーションから呼び出す用途が中心です。社内ネットワーク上で共有する場合は、認証、アクセス制御、ネットワーク分離、ログ管理を設計する必要があります。
また、入力データと生成結果の扱いにも注意が必要です。ローカルLLMであっても、プロンプト、入力ファイル、生成結果、ログに機密情報や個人情報が含まれる可能性があります。端末の管理、ログの保存期間、閲覧権限、バックアップ対象を明確にしておきましょう。
特にRAGと組み合わせる場合は、検索対象文書の権限管理が重要です。利用者が本来アクセスできない文書の内容を、生成AIの回答経由で取得できる構成は避ける必要があります。ローカルLLMは外部送信を抑えやすい一方で、社内の権限設計や監査設計まで自動で解決してくれるわけではありません。
業務検証では、次のような観点を事前に決めておくと評価しやすくなります。
| 観点 | 確認内容 |
|---|---|
| 品質 | 正確性、網羅性、形式遵守、再現性 |
| 性能 | 応答速度、同時実行数、リソース使用量 |
| セキュリティ | 入力データ、生成結果、ログ、API公開範囲 |
| 運用 | モデル更新、障害対応、監視、バックアップ |
| 法務 | ライセンス、利用規約、社内規程との整合 |
ローカルLLMは「クラウドLLMより常に安全」というものではありません。安全性は、モデルの実行場所だけでなく、データの流れ、アクセス制御、ログ、運用体制によって決まります。
CLIとPythonからOllamaを呼び出せるようになると、次の検討対象が見えてきます。
1つ目は、評価データの整備です。問い合わせ分類であれば、過去の問い合わせ文と正解カテゴリを用意し、モデルごとの正答率や出力形式の安定性を比較します。議事録要約であれば、人が作成した要約と比較し、重要な論点が落ちていないかを確認します。
2つ目は、RAGとの組み合わせです。社内文書を参照した回答を行いたい場合、LLM単体ではなく、検索システム、ベクトルデータベース、権限管理、回答評価を含めた設計が必要になります。前回の記事でも触れたとおり、最初から「社内文書を何でも質問できるAI」を目指すと複雑になりやすいため、対象業務を限定して検証することが重要です。
3つ目は、本番向けの推論基盤です。Ollamaは検証や小規模利用の入口として扱いやすい一方で、同時実行数、監視、スケーリング、GPU利用効率などを重視する場合は、vLLMなど別の推論基盤が適することもあります。本番導入では、Ollamaで得た評価結果をもとに、要件に合った構成を改めて選定します。
4つ目は、クラウドLLMとの使い分けです。機密情報を含む定型処理はローカルLLM、公開情報を使った調査や高度な推論はクラウドLLM、社内文書検索はRAGと組み合わせるなど、用途によって最適な構成は変わります。ローカルLLMを導入すること自体を目的にせず、業務要件に対してどの構成が合理的かを判断することが大切です。
本記事では、Ollamaを使ってローカルLLMをCLIとPythonから呼び出す方法を確認しました。
Ollamaを使うと、ローカルLLMの検証を比較的少ない手順で始められます。まずCLIでモデルが動作することを確認し、その後にPythonから呼び出すことで、アプリケーションに組み込む際のイメージを具体化できます。
一方で、ローカルLLMの実務利用では、モデルが動くことだけでなく、モデル選定、メモリ使用量、応答速度、コンテキスト長、ライセンス、API公開範囲、ログ管理を確認する必要があります。
本記事の要点は次のとおりです。
ローカルLLMは、クラウドLLMをそのまま置き換えるものではなく、生成AIを利用する場所と管理方法を広げる選択肢です。Ollamaで小さく検証し、対象業務に合うモデル、構成、運用ルールを確認してから、RAGや本番向け推論基盤へ広げていく進め方が現実的です。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
