ローカル AI とクラウド AI の使い分け：何を基準に選ぶか、環境を作る現実

Web サーバのアクセスログ解析ツールを作ったとき、AI バックエンドを切り替えられる設計にしました。Anthropic API・OpenAI API のようなクラウド AI と、Ollama（ローカル実行）を選択できるようにした理由は、「ログをクラウド AI に送っていいかどうか」という問いに、状況によって答えが変わるからです。

クラウド AI は便利ですが、何でも送っていいわけではありません。一方、ローカル AI を使うには環境構築のコストがかかります。この記事では、どんな情報をクラウド AI に送り、何をローカルで処理すべきかの判断基準と、実際にローカル AI 環境を構築しようとして調べてわかったことをまとめます。

クラウド AI の利点と向いている場面

Claude・ChatGPT・Gemini といったクラウド AI サービスは、環境構築なしですぐ使えることが最大の利点です。

最新モデルが常に使える — 新しいモデルが出ても、API を切り替えるだけで追従できる
インフラが不要 — GPU を調達する必要がない。従量課金で使った分だけ費用が発生する
精度が高い — 現時点では、クラウドの大規模モデルはローカルモデルを性能面で上回ることが多い

向いている場面は、送っても問題のない情報を扱うときです。

汎用的なコード生成・リファクタリング（社内固有の機密情報が含まれないコード）
ブログ記事・文書の壁打ち・構成確認
公開情報を前提とした技術調査
テストケースの雛形生成

日常のコーディング補助やコンテンツ運用の多くは、クラウド AI を使う方が速く進められます。実際、このサイトの設計・実装・記事執筆は、Claude Code や Codex のような AI コーディングエージェントとの組み合わせで進めています。

ローカル AI が必要になる理由

問題になるのは、「クラウドに送ってよいか判断が難しい情報」 を扱うときです。

送っていい情報・送ってはいけない情報

クラウド AI サービスに情報を入力すると、その内容はクラウド AI 側のサーバに送信されます。サービスによってはモデルの改善に使われる場合もあり、利用規約を確認する必要があります。

判断の目安は次のとおりです。

クラウドに送れる情報（一般的に）

公開情報・汎用コード・オープンソースと変わらないコンポーネント
公開前提のコンテンツ草稿
フレームワークの使い方などの技術質問

送る前に確認が必要な情報

実サーバのアクセスログ（IP アドレス・ユーザー行動が含まれる）
社内システムのソースコード（ビジネスロジック・DB 構造が含まれる）
設定ファイル（接続先や構成情報が含まれる）

原則として送らない情報

API キー・パスワード・秘密鍵などの認証情報
顧客の個人情報・取引情報
医療・財務・法務などの機密データ
社内の未公開情報

アクセスログは「公開情報ではないか」と思いがちですが、IP アドレスはアクセス元を特定できる情報であり、ユーザーの行動履歴を含みます。これをそのままクラウド AI に渡すことは、プライバシーポリシーやセキュリティポリシーと齟齬が生じる可能性があります。

ログ解析ツールで Ollama を選択肢に入れたのは、この状況への対応です。「ログをクラウド AI に送りたくない」というケースでも同じツールが使えるように設計しました。

使い分けの判断フレーム

整理すると次のようになります。

情報の種類	クラウド AI	ローカル AI
公開情報・汎用コード	○	△（不要）
アクセスログ・IP	要確認（規約・ポリシー次第）	○
社内ソースコード	要規約確認	○
API キー・パスワード・秘密鍵	原則避ける	クラウド AI に送らずに確認できるが、生成物や作業ログに残さない管理が必要
顧客情報・個人情報	原則避ける	クラウド AI に送らずに処理できるが、端末・保存場所・ログの管理が必要

「要確認」の情報は、利用するサービスの規約とデータ保持ポリシーを確認したうえで判断することになります。「どこまで確認すればよいかわからない」という場合は、クラウド AI に送らずに済むローカル AI を選ぶ方が判断しやすくなります。ただし、ローカル AI でもデータの置き場所、実行端末の権限、生成物やログの管理は必要です。

ローカル AI 環境の現実：GPU の選択とコスト

ローカル AI の実行環境は、大きく 2 つに分かれます。

Apple Silicon Mac — M1/M2/M3 の統合メモリ（Unified Memory）を GPU と CPU で共有する構成。Ollama が Metal（Apple の GPU API）を使って効率よく推論できる。Mac mini M2 Pro 32GB などが該当
Windows / Linux の自作 PC — 独立した GPU（VRAM を持つ）を積む構成。NVIDIA CUDA や AMD ROCm を使う

Mac の場合、「VRAM を持つ独立 GPU」はありませんが、統合メモリの広さと Apple Silicon の効率の良さで、モデルサイズがメモリ容量に収まれば実用的な速度で推論できます。

現在は Mac mini で運用しています（後述）。それとは別に、より重いモデルの実行や Linux 環境での検証を視野に、自作 PC の構成を現在検討中です。

自作 PC に GPU が必要な理由

Windows / Linux の PC で LLM を動かす場合、GPU の VRAM に収まるかどうかが速度と実用性を左右します。CPU だけで実行することもできますが、推論速度が大幅に遅くなります。

目安として、70億パラメータクラスのモデル（量子化版）なら 8〜16GB 程度の VRAM でも試せます。より大きめのモデルを実用的に扱いたい場合は、32GB 級の VRAM が候補になります。

2026年6月時点の GPU 市場と構成検討

GPU の価格は高騰しており、手頃な価格で高い VRAM を確保するのが難しい状況が続いています。現在候補として調べているのが次の 2 系統です。

NVIDIA GeForce RTX 5090（32GB VRAM）

CUDA 生態系の広さと情報量は圧倒的
新しい OSS ツールは NVIDIA 前提のものが多く、詰まりにくい
ただし価格が高く、総額が大きくなる
学習用途も視野に入れるなら有力

AMD Radeon AI PRO R9700（32GB VRAM）

32GB VRAM を比較的現実的な価格で確保できる可能性がある（2026年6月時点の調査）
コード補助のような推論中心の用途では十分に有力
ただし CUDA ではなく ROCm という AMD 向けのソフトウェアスタックを使う
CUDA 前提のツールや情報をそのまま流用できない点に注意が必要

用途の軸は「学習か推論か」です。モデルを自分でファインチューニングする学習用途まで考えるなら、CUDA まわりの情報量が多い NVIDIA が無難です。既存のモデルを動かして推論（テキスト生成）する用途が中心なら、R9700 のような VRAM 重視の選択肢も候補になります。コード補助は主に推論なので、R9700 も検討対象に入ります。

ROCm の注意点

この部分は、まだ自作 PC を構築する前の調査ベースです。実際の導入では、利用する GPU と ROCm の公式対応状況を確認する必要があります。

AMD GPU で AI ツールを使うには、ROCm という AMD 向けのソフトウェアスタックを使います。CUDA と直接互換ではないため、次のような点に注意が必要です。

対応 OS・ROCm バージョン・GPU・ツールの版の組み合わせが重要
PyTorch や vLLM は ROCm 対応版の手順が別にある
まず llama.cpp から始めると導入ハードルが低い

最初から複雑な構成を狙わず、ROCm 公式対応の OS と GPU の組み合わせを確認し、まず llama.cpp で推論環境を確立してから、必要に応じて PyTorch・Ollama・vLLM に広げていくのが安全なルートです。

実際にやっていること（Ollama）

現在のローカル AI 活用は、Apple M2 Pro（メモリ 32GB）の Mac mini で Ollama を使っています。Apple Silicon は統合メモリを GPU と CPU が共有する構造のため、32GB あればコード補助クラスのモデルを実用的な速度で動かせます。

Ollama は LLM のダウンロード・管理・実行を CLI で行えるツールで、OpenAI 互換の API サーバを立てる機能があります。既存のアプリやスクリプトの AI バックエンドを、コードをほとんど変えずにローカルに切り替えられるのが便利な点です。

ログ解析ツールでは次のように切り替えています。

python3 ai_report.py --api ollama --model qwen2.5-coder:32b

アクセスログを含む解析を「クラウド AI に送らずに実行したい」というケースで使います。レポートの品質や応答速度はクラウド AI の大規模モデルに及ばないことがありますが、「自分のサーバのログをクラウド AI に送らなくて済む」という安心感は実用上の価値があります。

もう一つ、特に役立っているのが 開発環境の準備作業 です。

本番データベースのダンプを開発環境に取り込んだ直後、クラウド AI のコーディングエージェントを起動する前に、個人情報をマスクする必要があります。顧客名・メールアドレス・電話番号などをランダムな値に書き換えるスクリプト案を Ollama に生成させ、内容を確認してから実行する、という流れです。この作業に個人情報が含まれるデータをクラウド AI に送るわけにはいかないため、ローカルで完結できることが重要です。

同様に、ソースコードに機密情報（APIキー・パスワード・接続文字列など）が混入していないか調べる作業にも使えます。コーディングエージェントを使い始める前の「クラウド AI に渡しても問題ないか」を確認する用途です。

ただし、速度はクラウド AI より遅いのが正直なところです。Mac mini M2 Pro 32GB では、大きめのモデルを使うと応答に時間がかかります。精度と速度を両立させたい場面ではクラウド AI には及びませんが、「クラウド AI に送れない情報を扱う」という局面では速度を許容して使うことになります。

エディタ連携では Continue（VS Code / JetBrains の拡張）を試しています。OpenAI 互換 API を向ければ Ollama とつながり、コード補助をローカルで動かせます。

クラウド AI とローカル AI を両方持つ構成

クラウド AI とローカル AI は「どちらか」ではなく、情報の性質に応じて使い分けるのが現実的です。

場面	使うもの
コード生成・文書作成・技術調査（機密情報なし）	Claude / ChatGPT などのクラウド AI
アクセスログ・サーバ内情報の解析	Ollama（ローカル）
DB ダンプの個人情報マスク処理	Ollama（ローカル）
ソースコードへの機密情報混入チェック	Ollama（ローカル）
社内ソースコードのリファクタ・解析	ローカル（または規約確認済みのクラウド）
顧客情報を含む処理	クラウド AI は避ける。ローカルでも管理前提で扱う

クラウド AI とローカル AI の違いは、精度だけではありません。速度、コスト、情報管理、運用負荷のトレードオフで考える必要があります。現時点では大規模なクラウドモデルの方が出力品質や速度で有利な場面が多い一方で、「機密情報を扱う場面でも AI を活用したい」というニーズが出てきたとき、ローカル AI がある構成は選択肢を広げます。

逆に「精度よりも情報セキュリティ」という判断が業務上に存在するなら、ローカル AI の環境構築コストは正当化できます。

まとめ

クラウド AI とローカル AI の使い分けは、「何の情報を扱うか」で決まります。

公開情報・汎用コード → クラウドでよい
ログ・社内コード・個人情報 → クラウド AI を避ける。ローカル AI でも管理前提で扱う

ローカル AI 環境の構築は、GPU コストと ROCm などの環境構築ハードルを考えると、誰でもすぐ始められるものではありません。大きめのモデルを実用的に扱うなら 32GB 級の VRAM が候補になり、AMD GPU を使う場合は ROCm の対応状況を確認する必要があります。

まず Ollama を Mac や Windows 機で試し、ユースケースが明確になってから専用機を検討する順番が合理的です。

「自社の情報はどこまでクラウド AI に送っていいか」「ローカル AI の導入を検討したい」という相談は、AI 活用支援からどうぞ。