そのコード、AIに送る前に一回止まりませんか？ — 自分のマシンでLLMを動かす「ローカルLLM」入門と、API／ローカルの賢い使い分け

Posted at 2026-06-27

はじめに — 「便利」と「コードを外に出す不安」のあいだ

AIにコードを書いてもらうの、もうすっかり当たり前になりましたよね。

補完してもらって、レビューしてもらって、エラーの原因も聞いて…。正直、めちゃくちゃ助かってます。でも、ふと立ち止まって考えてみると、こういう瞬間ってないですか。

「この社内コード、AIに貼り付けたけど…これって、どこに送られてるんやろ」

僕はあります。便利さに乗っかってるときほど、その裏側で自分のコードが自分の手元を離れて、どこかのサーバーに渡っているという事実を、つい忘れがちなんですよね。

ここで大事なのは、これは「AIを使うな」という話では全然ないということです。そうじゃなくて、AIをどこで動かすかを、自分で選べるという話なんです。

実は2026年のいま、選択肢はぐっと増えました。クラウドのAPIに送る以外に、自分のパソコンやサーバーの中だけでLLMを動かすという道が、現実的になってきています。これを「ローカルLLM」と呼びます。

この記事では、無知の無知 ―― つまり「ローカルLLM？聞いたことはあるけど、何がなんだか」という状態の人を置いていかないように、こんなことを順番に話していきます。

ローカルLLMって、そもそも何なのか（家を借りるか建てるか、の比喩で）
出てくる用語を、3分で全部かみ砕く
「ローカル vs API」を二択で悩むのをやめて、機密性で仕分けるという考え方
結局、自分のPCで動くのか（VRAMの目安と、動かないときの逃げ道）
動かす道具は3つ（Ollama / llama.cpp / vLLM）
今日からできる一歩：たった数行でローカルに切り替えるコード
「ローカルにすれば安全」という、よくある誤解の正体

ゴールは、読み終わったあなたが「うちのこのコードはローカル、これはAPIでいい」と自分で線を引けるようになること。では、いきましょう。

ローカルLLMって何？ — 「借りる」か「建てる」か

まず、いちばん大きな絵から。

いま多くの人が使っているAI（ChatGPTやClaudeのAPI、各種コーディング支援）は、ざっくり言うと部屋を借りている状態です。すごく設備の整った部屋を、使った分だけお金を払って借りる。自分でメンテはいらない。最新設備もすぐ使える。便利です。

でも、借りている以上、荷物（あなたのコードやデータ）は、その部屋に持ち込むことになります。持ち込んだ荷物がどう扱われるかは、貸主のルール次第。信頼できる貸主は多いですが、「そもそも持ち込みたくない荷物」もありますよね。

ローカルLLMは、自分の土地に小屋を建てるほうのイメージです。最初に建てる手間（モデルのダウンロードや環境構築）はかかるけど、一度建ててしまえば、荷物は一歩も外に出ない。家の中で完結する。

ここで一つ、キーワードが出てきます。「オープンウェイトモデル」です。

LLMは、ものすごくたくさんの数字（パラメータ＝重み）のかたまりでできています。この重みのデータが公開されていて、誰でもダウンロードして自分の環境で動かせるモデルを、オープンウェイトモデルと呼びます。設計図と部品をまるごともらえる感じですね。

たとえば2026年だと、OpenAI自身が公開した gpt-oss （後で詳しく触れます）、Qwen系、DeepSeek系、Gemma系、Llama系、Mistral/Codestral系…といった家族がたくさんあります。これらは自分のマシンの中だけで動かせる。だからローカルLLMが成り立つわけです。

逆に、APIでしか使えないモデル（重みは非公開）は「クローズド／プロプライエタリ」と呼ばれます。borrowing専用、という感じですね。

ポイント：オープンウェイト＝重みが手に入る＝手元で動かせる。これがローカルLLMの大前提です。

用語を3分で — ここだけ読めば迷子にならない

ローカルLLMの話で人がいちばん脱落するのは、専門用語の壁です。なので先に、よく出るやつを生活のことばで言い直しておきます。ここを押さえれば、この先ずっと楽になります。

モデル … AIの本体。たくさんの数字（重み）のかたまり。
パラメータ（◯B） … モデルの規模。7B なら70億、120B なら1200億の数字。多いほど賢い傾向だけど、その分でかくて重い。
オープンウェイト … その重みが公開されていて、ダウンロードして動かせること。
推論（inference） … 学習済みモデルに質問して答えを出させること。普段使いはほぼこれ。
推論エンジン … モデルを実際に動かすソフト（Ollama・llama.cpp・vLLMなど）。エンジンがないと、ただの数字の山は動きません。
VRAM … GPU（グラボ）が持っている専用メモリ。モデルを広げて置く「作業机の広さ」。ここに載りきるかどうかが勝負。
量子化（quantization） … 重みの精度を落として、モデルを小さく軽くする圧縮のこと。写真をJPEGで軽くするのに近い。
GGUF … 量子化したモデルの保存形式（ファイル形式）。llama.cpp が広めたもので、読み込みが速い。.gguf というファイルで配られます。
MoE（Mixture of Experts） … モデルの中に専門家をたくさん用意しておいて、質問ごとに必要な専門家だけ起こして使う仕組み。全員を毎回働かせないので、規模のわりに軽く速い。
コンテキスト長 … 一度に渡せる文章の量（机に広げられる紙の枚数）。128k なら約12.8万トークン分。

この9個だけで、もう8割は読めます。わからない単語が出てきたら、ここに戻ってきてください。

「ローカル vs API」で悩むのをやめる — 機密性で仕分ける

さて、ここがこの記事の背骨です。

多くの人は「ローカルとAPI、どっちがいいの？」という二択で考えてしまいます。でも、正直に言うと、この問いの立て方自体がちょっともったいない。

正解は、たぶんこうです。どっちか一方じゃなくて、仕事ごとに仕分ける。

判断のいちばん太い軸は「そのデータ、外に出していいか」。つまり機密性です。それに品質要件・ハードウェア・負荷の波・オフライン要件・コスト構造を足して考えると、きれいに整理できます。

判断軸	ローカルが向く	APIが向く
データの機密性	社外秘コード・顧客データ・規制対象（外に出せない）	公開情報・出してOKな内容
品質要件	「そこそこ賢ければOK」な定型作業	最先端の難問・複雑な推論が必要
ハードウェア	GPUやそれなりのマシンがある	手元に重いマシンがない
負荷の波	常時そこそこ回る（使うほどお得）	たまに大量・スパイクする
オフライン要件	ネットなし・閉域・出張先でも動かしたい	常時ネットがある前提でいい
コスト構造	初期投資して以後は使い放題に寄せたい	初期ゼロ・従量で払いたい

この表のいいところは、「全部ローカル」も「全部API」も正解じゃないと気づけることです。

たとえば、社外秘のコードを読ませてリファクタ案を出すのはローカル、公開ライブラリの使い方を調べるのはAPI、みたいに1つのワークフローの中で両方を使い分けるのが、いちばん現実的でかしこい。これは後の「ハイブリッド設計」の章でコードにします。

結局、私のPCで動くの？ — VRAMの目安と、逃げ道

ここがいちばん知りたいところですよね。「で、うちのPCで動くの？」と。

ざっくりの考え方はシンプルで、モデルをVRAM（GPUの机）に広げられるかです。目安はこんな感じ。

必要なVRAM（概算）＝パラメータ数（B） × 1パラあたりのバイト数＋余白（コンテキストなどで使う分）

1パラあたりのバイト数は、精度（量子化）で変わります。

フル精度（F16）… 約2バイト／パラ
8bit（Q8）… 約1バイト／パラ
4bit（Q4）… 約0.5バイト／パラ

なので、ものすごくざっくりの早見表がこちらです（あくまで目安。実際はKVキャッシュなどの余白で1〜数GB上振れします）。

モデル規模	4bit(Q4)概算	8bit(Q8)概算	だいたいの動かし方
3B 級	約2GB	約3GB	普通のノートPCでも狙える
7〜8B 級	約4〜5GB	約8GB	8〜12GBのGPU／Apple Silicon
13〜14B 級	約8GB	約14GB	12〜16GBのGPU
30B 級(MoE含む)	約18GB前後	約32GB	24GBクラスのGPU
70B 級	約40GB前後	約70GB	80GB GPU や複数GPU

「うち、そんないいGPUないわ…」という人、大丈夫です。逃げ道がちゃんとあります。

小さいモデルから始める … 3B〜8Bでも、要約・分類・コミットメッセージ草案・簡単な変換なら十分実用。
CPUでも動く … llama.cpp はCPUファースト設計。遅くはなるけど、量子化した小型モデルなら回ります。
Apple Silicon（Mac）は強い … メモリをCPU/GPUで共有する設計なので、メモリ多めのMacはローカルLLMと相性がいい。
クラウドGPUを“自分の箱”として借りる … 自前GPUは持たず、時間borrowで使う手も。これは「借りる」けど、貸主との契約次第で機密性をコントロールできます。

つまり、「最強の構成じゃないと無理」ではなくて、目的に合う一番小さい構成から始めるのがコツなんです。

動かす道具は3つ — Ollama / llama.cpp / vLLM

モデル（数字の山）を動かすには「推論エンジン」が要る、という話をしました。代表的なのは3つ。役割がきれいに分かれています。

エンジン	一言で	得意	苦手	こんな人に
Ollama	いちばん簡単	`pull`/`run` 一発、OpenAI互換API内蔵、Mac/Win/Linux	大人数同時アクセス	まず試したい・個人開発・ローカル開発
llama.cpp	軽さと携帯性	CPUでも動く、GGUF量子化、ノート〜スマホ〜エッジ	細かい設定は手動	非力なマシン・エッジ・最小フットプリント
vLLM	本番の量さばき	高並列スループット（PagedAttention・継続バッチング）、GPUフル活用	手軽さ、CPU/エッジ	チームで大量に捌く本番運用

ここ、実は出典つきで言えます。Red Hat Developerが2025年にNVIDIA H200で比較した検証では、vLLMは同時アクセスが増えるほどスループットが伸び、最初のトークンが返るまでの時間（TTFT）も速い。一方 llama.cpp は単一ストリームの効率と移植性が強みで、CPUやエッジまで幅広く動く、という住み分けがはっきり出ています。

そして大事なのが、Ollamaは内部で llama.cpp を使っているということ。つまり「Ollamaでお手軽に始めて、本番で並列をさばきたくなったらvLLMへ」という移行がしやすい。多くの開発者がこのハイブリッド（開発はOllama/llama.cpp、本番はvLLM）でやっています。

迷ったら、まずOllamaで一歩目。これで間違いないです。

今日の一歩 — 3コマンドと、既存コードの`base_url`差し替え

ここがこの記事の山場です。身構えなくて大丈夫。

ローカルLLMを始めるのは、想像よりずっと簡単です。Ollamaを入れたら、コマンドは基本3つ。

# 1) モデルを取ってくる（例として汎用の小型モデルを指定。:タグで量子化を選べる）
ollama pull qwen3:8b

# 2) その場で対話してみる
ollama run qwen3:8b "このコードの計算量を一言で説明して"

# 3) サーバーとして起動（多くの環境では入れた時点で常駐します）
#    既定で http://localhost:11434 で待ち受けます
ollama serve

これだけで、あなたのマシンの中にLLMが立ち上がります。コードは一行も外に出ていません。

そして、ここからが一番うれしいところ。Ollamaは「OpenAI互換」のAPIを持っています。 どういうことかというと、いまOpenAIのSDKで書いているコードの base_url（接続先）を、ローカルのアドレスに差し替えるだけで、ほぼそのまま動くんです。

まずPythonの例です。

# pip install openai
from openai import OpenAI

# 接続先をローカルのOllamaに向けるだけ。api_keyはダミーでよい（ローカルなので）
client = OpenAI(
    base_url="http://localhost:11434/v1",  # ← ここを差し替えただけ
    api_key="ollama",                       # ローカルでは中身は使われない
)

resp = client.chat.completions.create(
    model="qwen3:8b",  # ローカルに入れたモデル名
    messages=[
        {"role": "system", "content": "あなたは簡潔に答えるコードレビュアーです。"},
        {"role": "user", "content": "次の関数のバグを1つだけ指摘して: def avg(xs): return sum(xs)/len(xs)"},
    ],
)
print(resp.choices[0].message.content)

TypeScript（Node.js）でも同じ発想です。

// npm i openai
import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://localhost:11434/v1", // ← 接続先をローカルに変えるだけ
  apiKey: "ollama",                      // ローカルでは中身は問わない
});

const resp = await client.chat.completions.create({
  model: "qwen3:8b",
  messages: [
    { role: "system", content: "あなたは簡潔に答えるコードレビュアーです。" },
    { role: "user", content: "この正規表現の意図を1行で説明して: ^\\d{3}-\\d{4}$" },
  ],
});

console.log(resp.choices[0].message.content);

何が起きたか、わかりますか。いまの開発資産（SDKの使い方、プロンプト、後処理）を捨てずに、接続先だけを“手元”に向けたんです。

これが、ローカルLLM導入のいちばん現実的な入り口です。「全部作り直し」じゃない。「送り先を変えるだけ」。だから今日から試せる。

curlで生のAPIを叩いて確かめることもできます。

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:8b",
    "messages": [{"role": "user", "content": "1行で自己紹介して"}]
  }'

ちなみにvLLMでも、サーバーを立てればOpenAI互換で同じように喋れます。

# GPUのある環境で（pip install vllm 済み前提）
vllm serve Qwen/Qwen3-8B --port 8000
# → http://localhost:8000/v1 に対して、上のPython/TSと同じコードで接続できる

つまり、入口（Ollamaで手軽に）も本番（vLLMで並列に）も、アプリ側のコードはほぼ共通。これが「互換エンドポイント」のありがたさです。

量子化の読み方 — 品質とサイズのダイヤル

モデルを配布ページで探すと、Q4_K_M とか Q8_0 とか、呪文みたいな表記に出会います。これが量子化（圧縮）のレベルです。怖がらなくて大丈夫。サイズと品質のダイヤルだと思えばいい。

表記の例	精度	サイズ感	品質	だいたいの用途
F16 / BF16	フル精度	一番でかい	一番高い	評価の基準・潤沢なGPUがある時
Q8	8bit	約半分	ほぼ無劣化	品質を落としたくない時
Q5	5bit	さらに小さい	高品質	品質とサイズの良いとこ取り
Q4_K_M	4bit	小さい	実用十分	ローカルの定番バランス
Q3 / Q2	3〜2bit	とても小さい	劣化が見え始める	とにかく載せたい・非力なマシン

最初の一本なら、Q4_K_M あたりが鉄板です。多くの場合、サイズが大きく減るわりに、体感の品質低下は小さい。

ただし、ここは正直に言っておきます。量子化すると、確実に少しは賢さが落ちます。 どれくらい落ちるかはモデルとタスク次第で、カタログの数字だけでは分かりません。だから次の章の「自分のコードで実測」が効いてくるわけです。

覚え方：量子化＝荷物を圧縮して小屋に入れる作業。入るようになるけど、ぎゅっと潰しすぎると中身が傷む。ちょうどいい圧縮はQ4あたり。

モデルの選び方 — 「家族」で押さえて、自分のコードで実測する

「結局どのモデルがいちばんいいの？」 ―― これ、いちばん聞かれます。でも、いちばん答えが陳腐化しやすい質問でもあるんです。

正直に言うと、「いま最強」は数週間で入れ替わります。 だから僕がここで「◯◯の××版が最強」と書いても、あなたが読む頃には古い。なので、家族（シリーズ）で覚えて、最後は自分のコードで実測するのがいちばん賢い付き合い方です。

2026年時点で、コーディング用途でよく名前が挙がるオープンウェイトの家族はこのあたり。

Qwen Coder 系 … ローカルコーディングの実用本命としてよく挙がる。サイズ展開が豊富。
DeepSeek 系 … 推論・数学寄りのコーディングで評価が高い。MoEで効率がいい。
gpt-oss（OpenAI） … 後述。オープンウェイトで扱いやすく、ツール利用が強い。
GLM 系 / Kimi 系 … エージェント的・長い作業で名前が挙がる。
Codestral（Mistral）系 / Gemma 系 / Llama 系 … 軽量〜汎用で選択肢が広い。

その中で、出典つきで安心して具体例にできるのが gpt-oss です。OpenAIがGPT-2以来はじめて公開したオープンウェイトモデルで、ライセンスはApache 2.0。公式の数字はこうなっています。

gpt-oss-20b … 総21Bパラメータ／1トークンあたり活性3.6BのMoE。コンテキスト128k。16GBメモリのマシンで動くよう作られていて、ローカルやエッジ向き。
gpt-oss-120b … 総117Bパラメータ／活性5.1BのMoE。単一80GB GPUで動作し、コア推論でo4-miniに近いとされる。

ここで注目したいのが「総パラメータは大きいけど、1回に活性するのは数B」というMoEの効きかたです。規模のわりに動かしやすい。ローカルでMoEが好まれる理由がここにあります。

そして大事な結論。モデル選びは、リーダーボードの順位を眺めるだけで決めないこと。あなたの言語・あなたのタスク・あなたのハードウェアで、小さく実測する。 その方法は、次のevalの章で具体化します。

ハイブリッド設計 — 機密性ルーターで、賢く振り分ける

「ローカルとAPIを仕分ける」と言いました。これをコードにすると、ぐっと現実になります。

考え方はシンプルです。まず、その内容を外に出していいか（機密区分）を判定して、出せないものはローカル、出していいものはAPI、と振り分ける。下のコードは、その最小の骨格です（判定ロジックはダミーで、実運用では自社ルールに置き換えてください）。

// 機密区分。実運用では自社の分類基準に合わせる
type Sensitivity = "public" | "internal" | "secret";

// ざっくりの判定（例）。本番はもっと厳密にするが、考え方はこれ
function classify(text: string): Sensitivity {
  const secretHints = [/api[_-]?key/i, /password/i, /秘密/, /社外秘/, /顧客/];
  if (secretHints.some((re) => re.test(text))) return "secret";
  // 自社ドメインやリポジトリ名などが混ざるなら internal 扱い、など
  if (/example-corp|internal-repo/i.test(text)) return "internal";
  return "public";
}

// 区分ごとに「どこで動かすか」を決める。secret は絶対に外へ出さない
function routeBaseUrl(s: Sensitivity): { baseURL: string; model: string } {
  switch (s) {
    case "secret":
    case "internal":
      // 機密はローカル一択
      return { baseURL: "http://localhost:11434/v1", model: "qwen3:8b" };
    case "public":
      // 公開してよい内容だけ、品質の高いAPIに出す選択肢を持つ
      return { baseURL: "https://api.example-llm.com/v1", model: "frontier-model" };
  }
}

async function ask(prompt: string) {
  const sens = classify(prompt);
  const route = routeBaseUrl(sens);
  // ここで route.baseURL に向けて OpenAI 互換クライアントを作って呼ぶ
  console.log(`[router] sensitivity=${sens} -> ${route.baseURL}`);
  // ...実際の呼び出しは前章のクライアントと同じ
  return route;
}

ポイントは、「外に出していいか」を構造（コード）で先に決めてしまうこと。人間の気合いで「これは送っていいかな…」と毎回判断していると、必ずどこかで漏れます。だから、ルールにして自動で振り分ける。

ただし ―― ここはあとの安全章で念押ししますが ―― この振り分けロジックの“境界”は、最後は人間が設計・承認するものです。AIに「いい感じに振り分けといて」と丸投げする部分ではありません。

ローカル品質をどう確かめる — 小さなevalハーネス

「ローカルでもちゃんと使えるの？」を、感想じゃなくて数字で確かめる。これ、地味だけどいちばん効きます。

やることはシンプル。自社の代表的なタスクを10個くらい用意して、ローカルとAPIで同じ問題を解かせ、合否を見る。下はPythonの最小骨格です。

# 同じテストケースを「ローカル」と「API」に投げて、合否を並べて比べる最小ハーネス
from openai import OpenAI

# 代表タスク（自社の実作業から10個ほど。ここではダミー2件）
CASES = [
    {"q": "次のSQLにSQLインジェクションの懸念があるか一言で: \"...\"", "must_include": ["ある", "懸念"]},
    {"q": "この関数名をスネークケースに直して: getUserOrders", "must_include": ["get_user_orders"]},
]

def run(client: OpenAI, model: str):
    passed = 0
    for c in CASES:
        out = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": c["q"]}],
        ).choices[0].message.content or ""
        # 決定的チェック（含むべき語が入っているか）。最終判断は人間が見る前提
        ok = all(k in out for k in c["must_include"])
        passed += int(ok)
        print(f"[{'OK' if ok else 'NG'}] {c['q'][:24]}... -> {out[:40]}")
    print(f"== {model}: {passed}/{len(CASES)} 合格 ==")

local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
run(local, "qwen3:8b")
# api = OpenAI(base_url="https://api.example-llm.com/v1", api_key="...")
# run(api, "frontier-model")

この「決定的チェック（含むべき語が入っているか）」は荒い手法ですが、最初の足切りには十分です。微妙な品質差は、最後に人間がサンプルを目で見て判断する。合否ラインを決めるのは人間、形式的なチェックを回すのはコード、という分担ですね。

これをやると、「思ったよりローカルでいけるやん」も「ここはAPIに任せたほうがいいな」も、自分のコードで腹落ちします。借りものの順位表より、よっぽど信頼できます。

「ローカル＝安全」は誤解 — 守られるもの、守られないもの

ここは大事なので、テンション落として、正確に話します。

ローカルLLMの話をすると、「ローカルにすれば全部安全」という空気になりがちです。でも、これは危険な誤解です。守られるものと、守られないものを、ちゃんと分けて理解しておきましょう。

ローカルにすると守られること

入力したコードやデータが、外部のサーバーに送られない（データ主権）。
ネットがなくても動く（閉域・オフライン）。
使うほどに従量課金が増えない（コスト構造）。

ローカルにしても、別途守らないといけないこと

モデルの供給元 … ダウンロードしたモデル自体が信頼できるか。重みやスクリプトには供給元のリスクがあり得ます。素性の確かな配布元から取る。
AIが書いたコードの実行 … ローカルだろうとAPIだろうと、AIが生成したコードをそのまま実行するのは別の危険です。サンドボックス（隔離環境）で動かす原則は変わりません。
不可逆な操作 … 送信・課金・公開・削除・デプロイのような取り返しのつかない操作は、ローカルモデルが提案しても最後は人間が承認する。モデルが手元にあることと、判断を手放していいことは、まったく別の話です。
出力の正しさ … ローカルモデルもハルシネーション（もっともらしい嘘）をします。むしろ小型・量子化で精度が下がることもある。出力の検証は引き続き必要です。

そしてもう一つ、公平に言っておきたいこと。「APIは危険、ローカルは安全」という単純な対立ではありません。 信頼できるAPI提供者は、データの取り扱いについて正当なポリシーや契約（学習に使わない、保持期間、リージョンなど）を用意しています。だから本当の問いは「ローカルかAPIか」ではなく、「この特定のデータを、この特定の相手に預けていいか」なんです。

封じ込めの4原則をまとめると、こうなります。

既定で外に出さない（機密は手元、と先にルール化）
供給元を確かめる（モデルもコードも、素性の確かなところから）
実行は隔離する（AIが書いたコードはサンドボックスで）
不可逆は人間ゲート（取り返しのつかない操作は承認制）

人間とAIの役割分担

ローカルLLMを入れても、設計の主役が人間であることは変わりません。むしろ、はっきりします。

工程	人間が決める（What / Why）	AIに任せる（How）
データの機密区分	どこからが社外秘か、出していい境界はどこか	分類の下書き・候補出し
ローカル/APIの仕分け	何をどこで動かすかの方針	ルーティング実装の素案
モデル選定	品質ライン・コスト上限・ハードの前提	候補比較・VRAM見積もり・実測スクリプト
品質評価	合否ラインと「これは許せない失敗」	evalハーネスの実装・採点の一次処理
安全境界	不可逆操作の承認、供給元の可否	危険操作の洗い出し・チェックの自動化
運用	SLO・撤退の判断	監視・ログの集計・異常の要約

合言葉は、いつもの通りです。「何を・なぜ」は人間、「どう」はAI。

やりがちな落とし穴6つ＋撤退ライン

最後に、僕も含めてみんながハマりがちなところを、先回りで。

#	落とし穴	どうする
1	いきなり最大モデルを狙ってVRAM不足で挫折	まず3B〜8Bの量子化版から。動く成功体験を先に
2	量子化を攻めすぎて品質が崩れる	Q4_K_M を基準に。攻めるなら必ず実測で確認
3	「ローカル＝安全」と思考停止	供給元・実行隔離・不可逆ゲートは別途必要
4	リーダーボードの順位だけで選ぶ	自分のコードで小さくeval。順位は参考まで
5	全部ローカル or 全部APIの二択にする	機密性で仕分けるハイブリッドが基本
6	単一ユーザー前提のまま本番に出す	並列が要るならvLLMへ。Ollamaは開発向き

撤退ライン（ここまで来たら一度止まる）

ローカルの品質が、自社の合否ラインに何度試しても届かない → そのタスクはAPI（または併用）に戻す。意地を張らない。
運用・GPUのコストが、API従量より高くついている → 規模が出るまではAPIでよかった、と素直に見直す。
機密区分が曖昧なまま運用が始まっている → 一度止めて、境界を人間が引き直す。

「やめる・戻す」は失敗じゃないです。始める前に、戻り方を決めておく。これがいちばん強い。

プロンプト例 — そのまま使える4本

ローカルLLMの導入と運用で、AIを「調べ係・下書き係」として使うためのプロンプトです。いずれも最終判断は人間が握る前提で書いています。

① モデル選定の壁打ち

あなたはローカルLLM導入の相談相手です。最終決定は私がします。
前提：
- 用途：[例]社内コードのレビュー補助と要約
- 主な言語：[例]TypeScript / Python
- 使えるハード：[例]VRAM 16GBのGPU 1枚 / メモリ32GB
- 機密性：社外秘コードを含むため外部APIに出せない
このとき、ローカルで現実的に動くオープンウェイトモデルの候補を3つ、
それぞれ「家族名・想定サイズ・推奨量子化・概算VRAM・得意/不得意」を表で。
最後に「まず試す1本」と、その理由を1段落で。断定せず、実測で確かめるべき点も挙げて。

② データ機密性の分類ルール作り

次のデータ/プロンプトを、外部APIに送ってよいかの観点で
public / internal / secret の3区分に分類するルール案を作って。
- 各区分の定義と、判定に使える具体的な手がかり（語・パターン）
- 迷う境界例を3つと、その扱い
- 「これは必ず secret（外に出さない）」の明確リスト
注意：これは案です。境界の最終決定と承認は人間が行います。
過剰に出してOK寄りに倒さないこと。迷ったら厳しい側に寄せて。

③ ハイブリッド・ルーティングのレビュー

以下の「ローカル/API振り分けコード」をレビューして。観点：
- secret/internal の内容がAPI側に漏れる経路がないか
- 分類が甘くて機密が public 判定される穴がないか
- ログやエラーメッセージに機密が載って外に出ないか
- フォールバック時に意図せず外部へ出ないか
指摘は「該当箇所・なぜ危険か・修正案」の形で。
判断が分かれる点は『人間が決めるべき』と明記して、勝手に握りつぶさないで。
[ここにコードを貼る]

④ ローカル品質の評価セット設計

私の代表業務を10個渡すので、ローカルモデルとAPIモデルを
公平に比較する小さなeval設計を提案して。
- 各タスクの「合格条件」を、できるだけ機械的に判定できる形で
- 機械判定が難しいものは、人間が見る採点ルーブリック（0/1/2）で
- 量子化の影響が出やすそうなタスクの目星
合否ラインは私が決めます。あなたは測る道具の設計に徹して。

この4本に共通するのは、AIに「調べる・下書きする・チェックする」はやってもらうけど、「決める」は人間が持つという線引きです。ローカルにしてもAPIにしても、ここだけは変わりません。

おわりに — 道具を所有するということ

ここまで読んでくれて、ありがとうございます。

最初の問いに戻りましょう。「そのコード、AIに送る前に一回止まりませんか？」 ―― この記事を読んだいま、その「止まる」は、不安や思考停止じゃなくて、選べるから止まるに変わっているはずです。

これは社外秘だから手元で。これは公開情報だからAPIで品質を取りに行く。そうやって自分で線を引けるようになること。それが、この記事のいちばん渡したかったものです。

僕がローカルLLMにぐっと惹かれるのは、これが「道具を借りるだけの人」から「道具を所有する人」への一歩だからなんですよね。借りるのが悪いんじゃないです。でも、自分の土地に小屋を建てて、その中で安心して手を動かせる状態を持っておくのは、積み上がっていく資産だと思うんです。コードも、インフラも、それを設計できる自分の理解も。Code as Capital ―― 稼ぐ力は、こういう所有の積み重ねから生まれる気がしています。

そしてもう一つ。今日「うちのこれはローカル、これはAPI」と線を一本引いておくのは、明日の自分への小さなプレゼントです。半年後、機密データの扱いで冷や汗をかきそうになったとき、「あ、ここは手元で動くようにしてあったわ」と過去の自分に救われる。そのとき、きっと言うと思うんです。「あざっす」って。責める軸じゃなくて、思いやりの軸で、未来の自分に置き手紙を残しておく。

完璧な構成じゃなくていいんです。まずは小さく。

今日からの4ステップ

Ollamaを入れて、小さめのモデルを1本 ollama pull する
いま書いているコードの base_url を http://localhost:11434/v1 に差し替えて、動くのを確かめる
自社の代表タスクを3つだけ、ローカルとAPIで解かせて見比べる
「これは外に出さない」リストを1枚、人間の手で書く

このうち1つでも今日やったら、もう「借りるだけの人」じゃないです。

あなたのコードが、あなたの手元で動く。その感覚、ぜひ一度味わってみてください。ほな、また。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up