Linuxエンジニアの生成AI活用 第5回：機密データを守れ！「Ollama」で作る完全ローカルなLLM環境構築

こんにちは！「LINUX工房」メインライターの「リナックス先生」よ。

前回の第4回では、AIにインフラ自動化スクリプトを書かせ、Dry-Runで安全に検証する高度なディレクション技術を学んだわね。これであなたのターミナル作業は劇的に高速化したはずよ。でも、実務の現場でAIを使い倒そうとすると、必ず「セキュリティ部門からの強烈なストップ」がかかるわ。今回は、クラウドAPIの最大の弱点である「情報漏洩リスク」を根本から消し去る、完全ローカルなLLM構築術を伝授するわよ！

---

1. クラウドAPIの罠：インフラ環境におけるデータ主権の重要性

① 概念と背景（Why）

第1回から第4回まで、私たちはOpenAIをはじめとする「クラウド上のAPI」を前提に技術を学んできました。クラウドAIは信じられないほど賢く、応答も高速です。しかし、企業のインフラ環境という極めて特殊で機密性の高いフィールドにおいて、クラウドAPIの利用は「データ主権（Data Sovereignty）の放棄」と同義となります。インフラエンジニアがトラブルシューティングのために抽出したログファイルには、システムのIPアドレス、内部ネットワークのトポロジー、ミドルウェアのバージョン、時にはユーザーのセッションIDや個人情報（PII）、データベースの接続文字列など、ハッカーが喉から手が出るほど欲しい情報が平文で含まれています。

これらの情報をAPI経由で外部のサーバーに送信することは、どれほど暗号化通信（HTTPS）を用いようとも、送信先の企業（AIプロバイダー）のサーバーに自社の機密データを一時的にせよ保存させることを意味します。「APIのデータはAIの学習に使われない」という規約が存在したとしても、万が一AIプロバイダー側でデータ侵害（ハッキング）が発生した場合、あなたの企業は致命的なダメージを負います。金融、医療、政府機関、あるいは厳格なコンプライアンスを敷く大企業では、「外部にデータを出すこと自体がルール違反」なのです。

このジレンマを解決する唯一の手段が「ローカルLLM（Large Language Model）」の導入です。AIの頭脳（モデルの重みデータ）をインターネットから一度だけダウンロードし、自社のサーバーのCPUとメモリ（あるいはGPU）を使って、完全にオフラインでAIを稼働させるのです。この方法であれば、どんなに生々しいエラーログをパイプで流し込んでも、データが外部のネットワークに漏れることは物理的にあり得ません。データを自分の管理下（ローカル）に留めたままAIの恩恵を享受する。これこそが、情報セキュリティの最前線に立つインフラエンジニアが目指すべき、AI活用の最終形態なのです。

② 実践手順と完全なコード（How）

ローカルLLMを動かすためには、サーバーのリソース（特にメインメモリ：RAM）が極めて重要になります。AIを導入する前に、現在のサーバーが「AIの重い推論処理」に耐えられるかどうか、ハードウェアスペックを正確に調査するコマンドを実行します。

# 1. サーバーのメインメモリ（RAM）とスワップ領域の空き容量を確認する
free -h

# 2. CPUのコア数、アーキテクチャ、スレッド数を確認する
lscpu

# 3. ディスクの空き容量を確認する（AIモデルは数GB〜数十GBのストレージを消費します）
df -h /

③ プロによるコードの「1行・1オプション」徹底解説

• free -h：システムのメモリ使用状況を表示します。`-h`（human-readable）オプションにより、バイト数ではなく「G（ギガバイト）」や「M（メガバイト）」という人間が読みやすい単位で出力します。ローカルLLMを動かすには、最低でも空きメモリ（available）が 8GB 以上あることが望ましいです。
• lscpu：CPUのハードウェア詳細情報を出力します。ローカルでAIを動かす場合、GPU（グラフィックボード）があれば最高ですが、最近のAIモデルはCPUだけでも十分に実用的な速度で動作します。ここで「CPU MHz」や「Core(s) per socket（コア数）」を確認し、推論速度の当たりをつけます。
• df -h /：ルートディレクトリ `/` のディスク使用状況を確認します。AIモデルのファイル（ウェイト）は非常に巨大です。最低でも 20GB 程度の空き容量がなければ、モデルのダウンロード中にディスクフル（No space left on device）を引き起こし、サーバー全体が停止する危険性があります。

④ 現場のリアル（失敗談とノウハウ）

ローカルLLM初心者が引き起こす最悪のインシデントが「OOM（Out Of Memory）によるサーバークラッシュ」です。AIの推論は大量のメモリを貪食します。もし本番稼働中のWebサーバーやデータベースと同じサーバーで巨大なAIモデルを起動してしまうと、Linuxカーネルに搭載されている「OOM Killer」という死神が発動します。OOM Killerはメモリ不足を解消するため、一番メモリを消費しているプロセスを「強制終了（Kill）」させますが、最悪の場合、AIではなくデータベースのプロセスを殺してしまうことがあります。AIを動かすサーバーは、必ず「推論専用の独立した仮想マシン（VM）」か「開発環境」に分離すること。本番環境での相乗りは絶対に禁止よ！

---

2. 救世主「Ollama」の降臨：AIインフラ構築の革命的簡略化

① 概念と背景（Why）

かつて、ローカル環境でAIを動かすことは、インフラエンジニアにとって「終わりのない地獄」でした。Pythonの仮想環境を構築し、CUDA（NVIDIAの演算プラットフォーム）のバージョンを合わせ、巨大なPyTorchライブラリをコンパイルし、Hugging Faceからモデルの重みファイルをダウンロードして設定ファイルを書く……。途中でライブラリの依存関係が一つでも狂えば、謎のC++コンパイルエラーを吐いて数日間足止めされるのが日常でした。AIを動かす前の「環境構築」だけで挫折する人が後を絶たなかったのです。

しかし、この絶望的な状況を打破する革命的なツールが登場しました。それが「Ollama（オラマ）」です。Ollamaは、ローカルLLMの実行環境を、まるで「Docker」のように極限まで抽象化・簡略化したプラットフォームです。Pythonの依存関係も、複雑なGPUドライバーの設定も、一切気にする必要はありません。Go言語とC++で書かれた単一のバイナリがすべてを吸収し、たった1行のコマンドを打つだけで、AIの実行環境（バックグラウンドで動くAPIサーバー）が完成します。

インフラエンジニアの視点から見ると、Ollamaの素晴らしさは「systemd（Linuxのサービス管理）」と完璧に統合される点にあります。インストールした瞬間に `ollama.service` というデーモンとして常駐し、OpenAI互換のREST API（通常はポート11434）をローカルホストに提供してくれます。これにより、私たちは難しいAIの内部構造を知らなくても、あたかも「自分専用のOpenAIサーバーをローカルに建てた」かのように、いつもの `curl` コマンドでAIと対話できるようになるのです。

② 実践手順と完全なコード（How）

LinuxサーバーにOllamaをインストールし、サービスとして起動していることを確認する一連の手順を実行します。このコマンド一つで、あなたのサーバーはAIインフラへと変貌します。

# 1. Ollamaの公式インストールスクリプトをダウンロードし、そのまま実行する
curl -fsSL https://ollama.com/install.sh | sh

# 2. systemdを使って、Ollamaサービスが正常に稼働しているかステータスを確認する
sudo systemctl status ollama

# 3. Ollamaがローカルポート（11434）でリッスン（待ち受け）しているか確認する
ss -tlnp | grep 11434

③ プロによるコードの「1行・1オプション」徹底解説

• curl -fsSL … | sh：Web上のスクリプトをダウンロードし、そのままシェルに流し込んで実行する強力なコマンドです。
  • `-f`（fail）：HTTPエラー時にサイレントに失敗させます。
  • `-s`（silent）：進捗バーを隠します。
  • `-S`（show-error）：`-s` と併用し、エラー時のみ理由を表示します。
  • `-L`（location）：リダイレクトに追従します。

  この1行で、CPU/GPUの自動判別からバイナリの配置、systemdへの登録までを全自動で行います。

• sudo systemctl status ollama：インストールされたOllamaが、Linuxのバックグラウンドサービスとして `active (running)` 状態になっているかを確認します。
• ss -tlnp：現在サーバーで開いているネットワークポートを確認するインフラエンジニア必須のコマンドです。`11434` ポートが `127.0.0.1`（ローカルホスト専用）で開いていることを確認し、外部から勝手にAIを使われない安全な設定になっていることを担保します。

④ 現場のリアル（失敗談とノウハウ）

インターネット上のスクリプトを `curl … | sh` で直接実行することは、セキュリティの観点からは本来「非常に危険な行為」とされています。悪意のあるスクリプトをroot権限で実行してしまう可能性があるからです。Ollamaのような信頼できる超有名OSSでは許容されることが多いですが、現場のプロは必ず「一度 `curl` でファイルとして保存し、中身のシェルスクリプトをエディタで読んで、怪しい通信や破壊的なコマンドがないか確認してから実行する」という防衛手順を踏みます。便利さの裏にあるリスクを常に意識する、それがインフラを預かる者の責任よ！

---

3. オープンモデルの実行：軽量な頭脳をターミナルに宿す

① 概念と背景（Why）

Ollamaという「AIを動かすための器（エンジン）」は用意できました。しかし、これだけではまだAIは思考できません。器の中に入れる「脳みそ」、すなわち「LLMモデル（重みデータ）」をダウンロードする必要があります。現在、Meta社の「Llama 3」やGoogleの「Gemma」、Microsoftの「Phi-3」など、世界中の巨大テック企業が自社の超高性能なAIモデルを無償で公開（オープンウェイト）しています。

モデルを選ぶ際、インフラエンジニアが最も気にしなければならないのが「パラメータ数（サイズの大きさ）」です。モデルの名前の末尾についている「8B」や「70B」という数字は、脳のシナプスの数（B = Billion = 10億）を表しています。当然、70Bのような巨大なモデルは信じられないほど賢いですが、実行するには数十GB〜100GB以上のVRAM（GPUメモリ）が必要になり、一般的なサーバーでは起動すらできません。私たちが日常のログ解析やコマンド生成に使うのであれば、「8B（約80億パラメータ）」クラスの軽量モデルが最適です。これなら、16GB程度の標準的なRAMを積んだCPUサーバーでも十分に動作します。

さらに、Ollamaのモデルは「量子化（Quantization）」という高度な圧縮技術が施されています。「Q4」などの表記があるモデルは、AIの計算精度をわずかに落とす代わりに、メモリ消費量と計算速度を劇的に（1/4程度に）圧縮したものです。これにより、高価なGPUがない環境でも、ターミナル上でサクサクと動く実用的なAIアシスタントを実現できるのです。

② 実践手順と完全なコード（How）

Meta社が公開している超高性能かつ軽量なモデル「Llama 3.1（8B版）」をダウンロードし、対話モードで起動します。

# 1. Ollamaを使って、llama3.1モデルをダウンロードし、そのまま起動する
# 初回は数GBのデータのダウンロードが走るため、ネットワーク環境の良い場所で実行してください
ollama run llama3.1

# --- 以下、Ollamaの対話プロンプト（>>>）が表示されます ---
# ここでAIに対して質問を投げます
>>> Linuxの「OOM Killer」とは何ですか？1文で説明してください。
OOM (Out Of Memory) Killerは、Linuxシステムにおいてメモリが極端に不足した際に、システム全体のクラッシュを防ぐために、メモリを大量に消費しているプロセスを強制的に終了させるカーネルの保護機能です。

# 2. 対話モードを終了し、通常のLinuxターミナルに戻る
>>> /bye

③ プロによるコードの「1行・1オプション」徹底解説

• ollama run llama3.1：指定したモデルをローカルで起動するコマンドです。もしローカルに該当モデルが存在しない場合、自動的に公式のレジストリから最新のモデルデータ（数GB）を `pull`（ダウンロード）し、完了次第すぐに対話プロンプトを立ち上げます。
• >>>：Ollama専用のREPL（対話型評価環境）のプロンプトです。ここに入力されたテキストは、外部のインターネットには一切出ず、完全にあなたのサーバーのCPU/RAM内だけで計算されて回答が生成されます。
• /bye：Ollamaの対話モードを終了し、元のBashシェルに戻るための特殊コマンドです（`Ctrl + D` でも抜けられます）。

④ 現場のリアル（失敗談とノウハウ）

ローカルモデルをCPUだけで実行すると、回答が1文字ずつ「ポツ……ポツ……」と非常にゆっくり出力されることがあります。これは、巨大なモデルデータがメインメモリからCPUへ転送される際の「帯域幅（通信の太さ）」がボトルネックになっている証拠です。もしサーバーのメモリが足りず、ディスクの「スワップ領域（仮想メモリ）」にモデルが押し出されてしまうと、出力速度は「1分間に1単語」レベルまで絶望的に低下し、実質的に使い物にならなくなります。現場でローカルLLMを導入する際は、必ず `htop` や `top` コマンドを別の画面で開き、AI推論中のメモリ消費量とスワップ発生状況をモニタリングして、システムが破綻していないか監視するのがプロの運用よ！

---

4. aichatとローカルLLMの結合：セキュアな自動化環境の完成

① 概念と背景（Why）

Ollama単体でも対話は可能ですが、インフラエンジニアの目的は「AIとおしゃべりすること」ではありません。第3回で学んだ「パイプでログを流し込む処理」や、第4回で学んだ「要件定義プロンプトでスクリプトを生成させる処理」を、そのままローカル環境で再現できなければ意味がありません。

そこで、第2回で導入したOSSの強力なターミナルAIツール「aichat」の出番です。aichatの素晴らしい点は、その接続先（APIエンドポイント）をOpenAIなどのクラウドから、たった今ローカルに構築したOllamaへ簡単に切り替えられることです。Ollamaは裏側で「OpenAIと全く同じ形式の通信（REST API）」を受け付けるように設計されているため、既存の自動化スクリプトやAIツールの設定をほんの少し書き換えるだけで、シームレスにローカルLLMへと移行できます。

これにより、「完全にインターネットから切断された閉域網（クローズドネットワーク）のサーバー」であっても、パイプラインを用いた高度なログ解析やコマンド生成が可能になります。顧客データ、パスワード、機密のインフラ構成図など、絶対に外に出せない情報をAIに渡しても、一切のセキュリティリスクが発生しません。これこそが、セキュリティと利便性を両立させた、インフラエンジニアのための「究極のAI自動化要塞」の完成なのです。

② 実践手順と完全なコード（How）

`aichat` の設定ファイルを修正し、接続先をクラウド（OpenAI）からローカル（Ollama）へ切り替えます。そして、機密性の高いシステム情報をローカルAIに解析させます。

# 1. aichatの設定ファイル（config.yaml）を上書きし、Ollamaを使用するように変更する
cat << 'EOF' > ~/.config/aichat/config.yaml
clients:
  - type: ollama
    api_base: "http://localhost:11434"

model: ollama:llama3.1
EOF

# 2. パイプを使って、サーバーの機密情報（ネットワーク設定など）をローカルAIに解析させる
# ※この情報は一切外部インターネットには送信されません
ip addr show | aichat "このネットワーク設定情報を解析し、現在アクティブなIPアドレスと、そのネットワークインターフェース名を簡潔に教えてください。"

③ プロによるコードの「1行・1オプション」徹底解説

• type: ollama：aichatに対して、接続先のAIプロバイダーがOllamaであることを明示します。これにより、aichatはOllama固有のAPI仕様に合わせて通信を最適化します。
• api_base: “http://localhost:11434”：ここがセキュリティの要です。接続先を「ローカルホスト（あなた自身のサーバー）」の「11434番ポート（Ollamaのデフォルトポート）」に指定しています。外部への通信は一切発生しません。
• model: ollama:llama3.1：デフォルトで使用するAIの脳みそを、先ほどダウンロードした `llama3.1` に指定します。
• ip addr show | aichat “…”：システムの心臓部であるネットワーク構成情報を出力し、それをパイプでaichat（裏側はローカルのOllama）に渡し、解析させています。

④ 現場のリアル（失敗談とノウハウ）