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

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つでも今日やったら、もう「借りるだけの人」じゃないです。

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