2026-09-04  ·  llm · ollama · ai · claudecode · 個人開発

ローカルLLMに何を任せて、何を任せないか（実測つき）

クラウドのLLMを使っていると、トークン量が気になってきます。 「軽い作業はローカルLLMに逃がせば節約できるのでは」と考えるのは自然です。

手元のマシンで Ollama を動かし、実際に振り分けてみました。 結論は「効く作業と、やると逆に高くつく作業がはっきり分かれる」でした。 その線引きを、実測値つきで書きます。

使った環境

• Ollama on ローカルGPUマシン（HTTP API で呼ぶ）
• qwen3.6:35b（MoE）— 長文の一括処理
• qwen3.6:27b（dense）— 短文・定型
• bge-m3 — 埋め込み

呼び出し側は Node の薄いラッパを1本書いただけです。

const HOST = process.env.OLLAMA_HOST ?? "http://192.168.x.x:11434";

export async function chat(prompt: string, opts: ChatOptions = {}) {
  const res = await fetch(`${HOST}/api/chat`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      model: resolveModel(opts.model),
      messages: [...(opts.system ? [{ role: "system", content: opts.system }] : []),
                 { role: "user", content: prompt }],
      stream: false,
      think: opts.think ?? false,          // 思考トークンは基本不要
      options: { temperature: opts.temperature ?? 0.7 },
    }),
  });
  const data = await res.json();
  return { text: data.message.content.trim(), tokens: data.eval_count };
}

think: false は忘れないでください。既定で思考を出すモデルだと、 必要のない推論トークンを延々と吐きます。

---

効いた作業

1. 長文の一括翻訳 — これが本命

技術ドキュメント10章・882行を英訳させました。

記事1本（217行、出力2030トークン）で32.6秒でした。

構造が完全に保存されたのが大きい。 プロンプトでこう縛りました。

- Preserve the markdown structure exactly: headings, tables, code blocks, lists.
- Do NOT translate content inside code blocks. Keep code identical.
- Keep relative markdown links exactly as they are (e.g. [text](03-architect.md)).
- Keep the tone factual and plain. No hype words
  (revolutionary, seamless, supercharge, unlock, effortless).
- Output ONLY the translated markdown. No preamble.

禁止語を名指しで並べたのが効きました。 これを書かないと "revolutionary" や "seamless" が湧いてきます。

検証は機械でやります。原文と訳文で構造の数を比べるだけです。

def stats(t):
    return (len(re.findall(r'^#{1,3} ', t, re.M)),   # 見出し
            t.count("```") // 2,                      # コードブロック
            len(re.findall(r'^\|', t, re.M)),         # 表の行
            len(re.findall(r'\[[^\]]+\]\([^)]+\)', t)))  # リンク

一致しなければ訳し漏れか勝手な追加が起きています。

2. 記事の重複検査（埋め込み）

記事を書き足していくと、前に書いたことの焼き直しになりがちです。 bge-m3 で埋め込みを取り、コサイン類似度で機械的に弾きます。

0.945  a.md <> b.md   ← 言い換えただけの焼き直し。検出できる
0.805  記事1 <> 記事3  ← 話題が近い。許容範囲
0.591  記事2 <> 記事3  ← 別物

閾値 0.85 を超えたら公開しない、というルールにしています。 実際に1本、0.855 で引っかかったので構成を切り直しました。 書いている本人には「別のことを書いている」ように見えるので、機械の判定が要ります。

3. 見出し案・タイトル案の量産

10案出させて1案選ぶ、という使い方なら十分です。

---

やると逆に高くつく作業

販売コピーや記事本文の新規執筆

ここが一番の学びでした。下訳を読んで書き直すぶん、自分で書くより高くつきます。

実際に出てきた出力です。

* Claude Codeによる5つのAIエージェント分工体制：3ヶ月間で10本の個人アプリを完遂した開発プロセス
* 並列処理で開発効率化：Claude Codeを活用し、5つの役割分担で3ヶ月に10本アプリをリリースする方法
* 個人開発の速度革命：Claude Codeで構成する5人格ワークフローが3ヶ月で10本の実用アプリを生んだ理由

「速度革命」「駆使した」「完遂した」。日本語の誇張表現が混ざります。 禁止語リストを日本語でも書けば減りますが、根本的には「何を言わないか」の判断が要る作業で、 そこは指示に落としきれません。

そして経済的にも合いません。下訳を全文読み（入力トークン）、書き直す（出力トークン）。 最初から書けば出力トークンだけで済みます。削減どころか増えます。

短い文章

27bモデルで147トークンの出力に12.3秒。短文はレイテンシが支配的で、 待ち時間のほうが体感コストになります。数十トークンなら自分で書いたほうが速い。

---

線引き

実測から出した基準です。

一行でまとめると、「出力を読まずにファイルへ流し込めるか」 です。

読まずに済むなら委譲が効きます。全文読んで直すなら、最初から自分で書くほうが安い。 翻訳は前者です。構造の一致という機械的な合格判定があるので、全文を目で追う必要がありません。

失敗しないための実装上の注意

投げっぱなしにしないこと。 一度、10章ぶんの翻訳が走っていないことに 数分気づきませんでした。ログだけ空のまま残り、失敗したことが分からなかったためです。

原因を nohup のせいだと書きかけましたが、これは誤りです。nohup はむしろ 親や端末が消えても子を生かすための仕組みで、落ちる理由になりません。実際の原因は 別（& の付け忘れ、プロセスグループごとの kill、実行環境側の後始末）でした。

教訓は原因の特定より単純です。完了を確認できない投げ方をしない。 ジョブの管理は、結果を待てる呼び出し側の仕組みに任せます。

タイムアウトは長めに。 長文の一括処理は数十秒かかります。 既定の数秒でアボートすると、モデルは動いているのに結果が捨てられます。

モデルは別名で呼ぶ。 fast / big / coder / embed のような別名を ラッパ側で解決すると、モデルを入れ替えても呼び出し側を触らずに済みます。

まとめ

• 長文の一括翻訳は効く。構造の一致で機械検証できるのが大きい
• 埋め込みによる重複検査は、書いている本人には見えないものを見つける
• 新規の文章執筆は任せない。読んで直すぶん自分で書くより高くつく
• 短文はレイテンシ負けする
• 判断基準は「出力を読まずにファイルへ流し込めるか」

---

Claude Code に設計・実装・レビューを別々の人格として分担させ、GitHub Issue と ブランチを軸に並列開発を回すための設定一式を MIT で公開しています。 コピーして ./setup.sh を叩けば動きます。技術スタックには依存しません。

https://github.com/quintetkit/quartet

このワークフローだけで実際にツールを 1 つ作りました。Issue の分割から PR、 レビュー、マージまで記録が全部残っています。うまくいかなかった箇所も消していません。

https://github.com/quintetkit/mdlinkcheck

UI 設計人格・レビュー基準・Issue 単位の並列実行スクリプト・実践ガイド 10 章を 足したものは製品ページにあります。