Claude CodeとローカルLLMの併用設計｜何を手元に逃がすかの基準
Claude Code の使用量制限や機密データを理由にローカル LLM の併用を考えるとき、先に正すべき前提がある。これは Claude Code のセッションにローカルモデルを直接つなぐ話ではない。設計・検証・原因特定という判断はクラウドの Claude Code に残し、大量で定型の推論バッチだけを手元の Ollama へ逃がす——性能でモデルを分担するのではなく、判断の影響度と物量で作業を分担する、という役割分担である。本稿は公開ツール「国会議事録 AI要約」の実運用構成でこれを整理する。
ローカルに逃がす基準 — 判断は上限性能に、物量は手元に
分担の基準は性能ではない。逃がしてよいのは、大量・定型・毎回同じ形の推論である。国会議事録の要約は、一つの会議を発言者境界で数十チャンクに割り、それを Map→Reduce→Analysis の順に処理する。会議数が増えれば推論は数百回に達するが、一回ずつの形は変わらない。判断の余地がなく物量だけが大きいこの部分は、使用量制限の外に置ける手元の GPU に逃がすのが素直である。
逆にクラウドの Claude Code に残すのは、判断の影響度が高い作業だ。パイプラインの設計、出力バリデーションの検証、そして推論が壊れたときの原因特定——ここを誤ると全体に波及する。上限性能が要るのはこの少数の局面であり、物量が要るのはバッチのほうである。だから「判断は上限性能のクラウドに、物量は手元のローカルに」置く。
この考え方は、推論コストを判断の不可逆性・影響度に比例させる配分と同根である（モデルと effort の配分計画で詳述している）。ローカル併用は、その配分をクラウドとローカルの境界にまで延長したものにすぎない。
実構成 — Ollama 推論サーバ × Claude Code
実際の構成は単純である。LAN 内に置いた GPU ワークステーションで Ollama を動かし、バッチ本体（Python）がそこへ REST で要約を投げる。国会議事録 AI要約では、chunk・reduce・analysis の3フェーズすべてを単一モデルに統一した（2026年6月の運用時点で gpt-oss:120b、以下のモデル名・パラメータは 2026-07-16 に確認したもの）。モデルをフェーズごとに切り替えないので、VRAM 上のモデル入れ替えも起きない。
設計上の勘所は、モデル名を実装側にハードコードしないことである。推論に使うモデルは設定ファイル（config.toml）に一つ書くだけにし、差し替えはそこだけで完結するようにした。これにより、後述するモデル選定のやり直しがコード変更を伴わずに回せる。なお、GPU の機種や VRAM 容量といった機材スペックの詳細は本稿では扱わない——手法は機材に依存せず、依存させない設計にしているからである。
この構成で Claude Code が担うのは、推論そのものではなく、パイプライン自体の設計・実装・デバッグである。連携が最も効いたのはデバッグだった。バリデーションが大量に失敗したとき、筆者は Claude Code に「憶測で対処せず、失敗した実チャンクを設定違いで投げ直して根本原因を再現で特定してほしい」と依頼した。ローカルモデルの失敗を、クラウドの Claude Code に再現調査させる——これが両者を直接つながずに連携させる、現実的な接点である。
品質と速度の実際
品質は、ベンチマークの表ではなく自分の実データで測った。モデル選定は、サイズの異なる複数の会議の全チャンクを実際に流し、空出力率・字数の逸脱・所要時間を集計して決めている。この評価で gemma4:26b は複数会議の全チャンク検証で約50%が空出力となり却下した。nemotron-3-super:120b は出力が冗長で、ウォーム状態でも2〜5倍遅く、空出力や途中切れも出たため見送った。安定性と字数適合が最良だった gpt-oss:120b を採用している（いずれも運用当時の実測である）。
速度面で効いたのは、推論モデルへ思考量を最小化する指示（think="low"）を送る設定だった。この推論モデルは既定だと密度の高いチャンクで思考が生成枠を使い切り、本文が空になる。思考を約100字に抑えることで、空出力を回避しつつ約2.4倍高速になり、要約品質は維持できた。数値はこの運用での実測であり、他の環境・モデルに一般化できるものではない。速度差や料金の横比較は測っていないため、ここでは述べない。
向かない処理・落とし穴 — 静かに失敗する
ローカル運用で本当に怖いのは、エラーで落ちてくれないことである。壊れたときに例外ではなく空文字列が返るため、気づかないまま大量のバッチが無内容で埋まる。実際に踏んだ静かな失敗が二つある。
一つは思考の枯渇だ。前述のとおり、推論モデルは既定のままだと思考で生成枠を使い切り、本文を出力しないまま打ち切られる。二つ目は入力長の超過である。チャンク要約を結合した全体要約の入力が上限（当初 num_ctx 8192）を超えると、先頭からサイレントに切り捨てられ、プロンプトすら届かず空レスポンスが連発した。これを 32768 へ引き上げて解消した。重要なのは、この二つが症状は同じ「空レスポンス」でも原因が別物だという切り分けである。思考枯渇を疑って生成枠だけ広げても、入力超過側は直らない。
だからローカルに逃がす処理には、出力が空・字数逸脱・非日本語などを弾くバリデーションと、失敗時のリトライを必ず挟む。定型・大量だからこそ、一件の静かな失敗が全体を汚す前に機械で止める必要がある。失敗が続くときに調査のモデルや effort を段階的に上げる規約そのものは、別記事で単独に扱う。
よくある質問
ローカルモデルはどう選ぶのか。 公開ベンチマークの表ではなく、自分の実データの全量で選ぶのがよいと考えている。国会議事録では、単発の数チャンクでは見えなかった約50%の空出力が、複数会議の全チャンク評価で初めて表面化した。信頼性は物量で測らないと見逃す。
クラウドとどちらが安いのか。 コストは実測していないため断定しない。要点は金額比較ではなく、大量・定型の推論を使用量制限の外へ出せるという構造にある。
まとめ
Claude Code とローカル LLM の併用は、性能でモデルを競わせる話ではない。判断の影響度が高い設計・検証・原因特定はクラウドの Claude Code に残し、大量・定型の推論バッチだけを手元の Ollama へ逃がす——判断は上限性能に、物量は手元に、という役割分担である。ローカルは静かに失敗するため、モデルは実データの全量で選び、出力にはバリデーションとリトライを必ず挟む。この境界を先に決めておくことが、併用を運用可能にする出発点だと考えている。