自律駆動する部下を雇う ― ローカル LLM の現在地を探ってみた

はじめまして。エンタープライズ第二本部 プラットフォームエンジニアリング部 2年目の菊池祥汰です。業務ではAIサポートセンターとして 生成AI / LLM 活用案件やdJグループ内の生成AI利活用推進などを行っており、プライベートでも積極的にAI課金をして試しているAIフリークです。

この記事は、社内に幾多ある勉強会のひとつである『25卒技術会』での発表内容をもとに執筆されています。

『25卒技術会』では隔週火曜日に会議室に集まり、ブックリーディングと自由テーマ発表の2軸で各々の学びを共有し合っています。このたび、外部向けの施策として自由テーマ発表から不定期でテックブログを書いていく運びとなりました。ちなみに、この会の主催者はテックブログ常連でもある同期の大岡叡さんです。今後、下記の技術会メンバーからも記事の投稿がある予定ですので、お楽しみに。

大岡 叡 ／菊池 祥汰 ／ 伊藤 真幸 ／ 植木 信輔 ／ 上原 辰徳 ／ 今橋 輝 ／ 渡邉 真太郎 ／ 段下 幸太郎

自律駆動する部下は実現するか — OpenClaw という予兆

2026 年の年明けから、OpenClaw（旧 MoltBot） と呼ばれる能動的な AI エージェントが話題になっています。

OpenClaw は、特定のディレクトリに操作権限を与えると、AI が「次に何をすべきか」を自分で考えながら、24 時間 365 日、自律的に動き続けるタイプのエージェントです。人間が一手ずつ指示するのではなく、目的だけ渡せば手段を自分で組み立てていきます。

目的を渡せば、AI が「次にすべきこと」を自分で考え、実行し、結果を見て改善する。これが 24 時間 365 日回り続ける

AI の操作をいちいち承認する操作も不要。AIの成果物を確認しレビューする人間という最大のボトルネックを排し、AI を本当に「自律駆動する部下」のように位置づけられる可能性が見えてきました。こうした動きは、すでに一人歩きを始めており、AI エージェントだけが集う SNS「Moltbook」なども話題を呼んでいます。Reddit のように投稿やコミュニティが並ぶのに、書き込むのはすべて AI エージェントで、人間は観察者としてしか入れません。サービス開始から数日で150万を超えるエージェントが集まり、その中では AI 同士が共同体や、ときに宗教めいたものまで自発的に作り始めたと報じられています。AIはチャットボットとして人間に律速されるフェーズを脱し、エージェント駆動する時代へとのシフトが始まりつつあります。

その一方で、大きなリスクがあります。それがAPI コストです。AI を長時間・高頻度で回すほど、ランニングコストは跳ね上がっていきます。これは特に金融系のユースケースでROIを測定する際に重くのしかかってきます。

必然的に、ローカル LLM が選択肢に上ってきます。通常私たちが利用している ChatGPT や Claude（本記事ではまとめてクラウド LLM と呼びます）は、各社のサーバ上の計算資源（メモリや GPU など）を使って動いています。便利な反面、入力は社外に送られ、使うほど従量課金が積み上がっていく。これを自分の手元のマシンだけで完結させようというのが、ローカル LLM の発想です。

ローカル LLM の 3 つの強み

私がローカル LLM の価値として最も強く押し出したいのは、次の 3 点です。

1. データが外部に出ていかない（セキュア） — クラウド API は入力がすべて外部に送信されます。機密情報や個人データ、API キーを扱う場合、ともすれば致命的になりえます。ローカルなら、扱うデータは自分の環境から出ません。
2. 完全自律で回しても API コストが爆発しない — 長時間・高頻度で動かすほどクラウド API の従量課金は膨らみます。最近は各種AIベンダーも投資を回収するフェーズに入ってきており、円安も加わってクラウドAPIのコスト体系はかなり向かい風です。ローカルLLMなら、追加コストは電気代だけ。円安の煽りを受けにくいだけでも儲けものです。
3. 買い切った GPU を遊ばせない — これは減価償却的な観点ですね。ゲーム用に買った GPU をAPI 利用料の節約という観点で使い回すことができれば、買い切りの出費を長く活かし続けられます。

ローカル LLM の 3 つの強み。（1）データが外に出ない （2)API コストが爆発しない （3）買い切った GPU を遊ばせない

目指す世界 — 24 時間 365 日 動く株式エージェント

さて、この自律駆動エージェントの終着点を、私は24 時間 365 日、世界中のニュース・企業のプレスリリース・今朝の報告書を監視し続け、株の自動売買を行うエージェントだと見ています。短期投資は分刻み・秒刻みで状況が動くので、「いま買いか、買いでないか」を常に判断させたい＋低コストで回しっぱなしにしたいという需要があります。ローカル LLM の優位性は明確です。

加えて、セキュリティ面でも、ローカル LLMを用いれば自身のポートフォリオや API キーが外部に流出するリスクを、限りなくゼロに近づけられます。金融データを扱う以上、セキュリティは最優先事項です。ローカル LLM の性質と、このタスクの要件は強く噛み合います。

最も重要なのがランニングコストです。API 料金が発生すると、コストに見合うリターンを得なければならず、強気（ハイリスクハイリターン）な投資を余儀なくされてしまいます。これは運用手数料の高い投資信託を保有しているときの感覚に近く、最も忌避すべき条件です。だからこそ、追加コストを電気代だけに抑えられ、なおかつまともな回答精度が得られるのであれば、ローカル LLMは非常に合理的なブレインとなりうるでしょう —— まともな回答精度が得られるのであれば、ですが。 一方で、現実にそういった話はなかなか聞きません。なぜなのでしょう。前置きが長くなりましたが、今回の記事ではここに切り込んでいこうと思います。

ローカル LLMの現在地を探る

投資エージェントをいきなり走らせるのは無理があります。買いと判断した銘柄が上がったか下がったか、その答え合わせには数か月かかりますし、コーディングも大規模になってしまいます。

そこで本記事は、ローカル LLM の現在地を知るための実験として、物件のスペックから賃料を予測するという擬似的な経済価値判断タスクを解きます。無数の物件スペック情報から適正な価格を予測し、その予測価格と実際の価格を照合して、コスパの良い物件を検出する。スペックから想定される賃料より実際の賃料が安ければ、それはコスパが良い物件とみなし、ユーザーに提案するというものです。

両者の構造を並べると、次のように対応します。

ステップ	物件コスパ判定（題材）	株式自動売買（本命）
外部データ	ローカルにキャッシュした物件情報	株価 API・ニュース・朝の報告書
LLM の価値判断	スペックから適正賃料を予測	情報から買い/売り/様子見を判断
指標化	コスパスコア（実価÷予測）	投資シグナル
正解突合	即時	数日〜数か月後

株価予測は検証に長い期間が必要です。一方、この物件タスクは、構築と答え合わせのサイクルが短く、実装も容易です。ローカル LLM の現在地を知る、という目的にはこちらが合っていました。

道具立て — Ollama / Gemma 4

ローカル LLM 基盤には Ollama を用いました。Ollama はよく「Docker for LLM」と呼ばれます。実際、開発者は元 Docker のエンジニアで、ollama pull でモデルを取得し ollama run <model> で対話を始める操作感は Docker そっくりです。

起動すると、localhost:11434 に REST API サーバーが立ちます。OpenAI / Anthropic 互換のエンドポイントを備えているため、既存コードの接続先を差し替えるだけでローカルモデルに切り替えられます。

モデルは Gemma 4 を用いました。Google が 2026 年 4 月に公開したオープンウェイトのモデルで、Gemini と同じ研究基盤から生まれた、画像も扱えるマルチモーダルモデルです。

Gemma 4 の特徴として MoE（Mixture of Experts、混合エキスパート） の採用があります。今回の主役 26B は、総パラメータが約 26B ありながら、推論時に実際に使うのは約 3.8 B だけです。すなわち、大型モデルの賢さを、より軽い計算量で出せるというわけです。

もうひとつの個性が、量子化との相性です。Gemma 4 は、いずれ圧縮されることを見越して学習する QAT（Quantization-Aware Training、量子化を考慮した訓練）を採っています。おかげで、重みの精度を 16 bit から 4 bit へ落としても品質の劣化が小さく、必要メモリを 4 分の 1 ほどに圧縮できます。本記事でローカルに落とした 4-bit 量子化版（gemma4:26b）も、この仕組みの上に成り立っています。

Ollama で扱える主なサイズは、次のとおりです。

Ollama タグ	構成	パラメータ（推論時 / 総）	サイズ（4-bit）	コンテキスト	位置づけ
gemma4:e2b	軽量	2.3B / 5.1B	7.2 GB	128K	最小・スマホ等の省メモリハード向け（本実験では未使用）
gemma4:e4b（=latest）	軽量	4.5B / 8B	9.6 GB	128K	軽量・まず試した
gemma4:26b	MoE	3.8B / 25.2B	18 GB	256K	中型・今回の主役
gemma4:31b	Dense	30.7B / 30.7B	20 GB	256K	最大・最高性能

整理すると、Ollama と Gemma 4 の関係は次の図のようになります。Ollama がローカル LLM の実行基盤、Gemma 4 がその上で動くモデル本体です。

Ollama は実行環境、Gemma 4 はその上で動くモデル。クラウドに送らず、すべてローカル PC 内で完結する

題材アプリ「大田区コスパ物件ハンター」は、Claude Code を使った Vibe Coding で作り、UI は Streamlit でさっと組みました。物件データは各サイトの利用規約に配慮し、あらかじめローカルに保存しておいたキャッシュ（CSV）を入力として扱います。これを読み込み、各物件の相場家賃を LLM に予測させ、実賃料 ÷ 予測でコスパスコアを出すだけのアプリです。スコアが低いほど割安で、0.85 を下回った物件を「お買い得」としてユーザに提案します。

Streamlit で実装したアプリケーションUI。結果はローカル実行した gemma4:26b（直列）のもの。30 件の処理に約 10.9 時間を要した

ベースライン — 単純な線形回帰による数学的解決

LLM を並べて競わせても、「どれもそれなりに賢い」で終わってしまうと考え、賃料を専有面積と駅からの徒歩分数の 2 変数だけで説明するシンプルな線形回帰モデルを用意し、ベースラインとすることで、各 LLM の推論能力を定量的に評価しました。

評価用の 30 件とは別に訓練用サンプル 200 件を用意し、最小二乗法で式を一本だけ当てはめました。

賃料(万円) ≒ 0.1898 × 専有面積(㎡) − 0.2021 × 徒歩(分) + 11.26

間取りも築年数も使わない非常にシンプルな式での実装です。訓練 200 件と評価 30 件は 1 件も重なっておらず（out-of-sample）、LLM 側も同じ 30 件を学習していないので、比較はフェアです。

精度は MAE（平均絶対誤差）・MAPE（平均絶対誤差率）・バイアス（誤差の符号付き平均。予測が高めか低めかの偏り）の 3 つで測り、コストはローカルを電気代換算（350 W × 31 円/kWh）、API をトークン単価に統一して記録しました。

そして LLM 側にも、同じ土俵に立ってもらいます。各物件について実際に投げているプロンプトは、次の全文です。素朴に「相場を教えて」と尋ねるのではなく、データから導いたアンカー（基準値と補正係数）を持たせ、例にならって 5 ステップの計算過程（Few-shot + Chain-of-Thought）を踏ませる作りにしています。

あなたは東京都大田区の賃貸相場に詳しい不動産アナリストです。
以下の推論例(例1〜例3)と同じ形式で step1→step5 を順に計算し、最後に賃料を算出してください。
アンカーは大田区2DK/2LDK 117件の訓練データから多重回帰で抽出した実データ係数です。

# 推定アンカー (基準: 中位駅×2LDK×3-5階建×築10-20年×徒歩10分 → 0.33 万円/㎡)
## 駅tier
- 上位 (大森・大森町・蒲田・京急蒲田・洗足池): ×1.10
- 中位 (馬込・西馬込・池上・武蔵新田・千鳥町・梅屋敷・大岡山 等): ×1.00
- 下位 (雑色・矢口渡・平和島・下丸子・石川台・田園調布): ×0.90
## 間取り
- 2LDK: ×1.00 / 2DK: ×0.95
## 階建
- 1-2階建(木造想定): ×0.88 / 3-5階建: ×1.00 / 6階建以上(RC想定): ×1.17
## 築年
- 築0-10年: ×1.12 / 築10-20年: ×1.00 / 築20-30年: ×0.95 / 築30年+: ×0.92
## 徒歩
- 徒歩10分基準で ±1分あたり ∓1% (例: 徒歩6分 → +4%、徒歩14分 → -4%)

# 推論例(この5stepフォーマットを必ず踏襲)
## 例1: 蒲田駅 徒歩6分 / 2LDK 55㎡ / 築8年 / 8階建
  step1 駅tier   = 0.33×1.10 = 0.363  (蒲田=上位)
  step2 間取り   = ×1.00     = 0.363  (2LDK)
  step3 階建     = ×1.17     = 0.425  (8階建 → RC想定)
  step4 築年     = ×1.12     = 0.476  (築8年 → 築0-10年)
  step5 徒歩     = ×1.04     = 0.495  (徒歩6分 → +4%)
  賃料 = 0.495 × 55 = 27.2万円
  推定家賃: 27.2万円

## 例2: 池上駅 徒歩10分 / 2DK 42㎡ / 築22年 / 7階建
  step1 駅tier   = 0.33×1.00 = 0.330  (池上=中位)
  step2 間取り   = ×0.95     = 0.314  (2DK)
  step3 階建     = ×1.17     = 0.367  (7階建 → RC想定)
  step4 築年     = ×0.95     = 0.349  (築22年 → 築20-30年)
  step5 徒歩     = ×1.00     = 0.349  (徒歩10分 → 基準)
  賃料 = 0.349 × 42 = 14.7万円
  推定家賃: 14.7万円

## 例3: 雑色駅 徒歩14分 / 2DK 40㎡ / 築32年 / 2階建
  step1 駅tier   = 0.33×0.90 = 0.297  (雑色=下位)
  step2 間取り   = ×0.95     = 0.282  (2DK)
  step3 階建     = ×0.88     = 0.248  (2階建 → 木造想定)
  step4 築年     = ×0.92     = 0.228  (築32年 → 築30年+)
  step5 徒歩     = ×0.96     = 0.219  (徒歩14分 → -4%)
  賃料 = 0.219 × 40 = 8.8万円
  推定家賃: 8.8万円

# 推定対象物件
- 間取り: {間取り}
- 専有面積: {専有面積(㎡)}㎡
- 最寄り駅: {最寄り駅} {徒歩N分}
- 築年数: {築N年}
- 階建: {階建}

上記5stepを順番に計算し、**最終行に厳密に**
`推定家賃: <数値>万円` (小数1桁) の形式で1値だけ出力してください。

※ プロンプト冒頭のアンカー（基準 0.33 万円/㎡ と各補正係数）は、線形回帰ベースラインの訓練に使った 200 件と同種の サンプルに多重回帰をかけ、統計的に抽出した実データ係数です。つまり、ベースラインと同じ訓練データの知識を LLM 側にも与えたうえで勝負させています。

実験

検証環境は以下のとおりです。

• OS: Windows 11 Home / CPU: Intel Core i7 14700KF / RAM: 32 GB / GPU: GeForce RTX 5060 Ti（VRAM 16 GB）
• Python: 3.13 / 主要ライブラリ: ollama pandas streamlit
• 評価データ: ローカルにキャッシュした大田区 2DK/2LDK の物件情報 30 件（全実験で固定）

最初は、VRAM 16 GB に余裕で収まる軽量モデル gemma4:e4b（9.6 GB）から試したのですが、賃料予測の手前の簡単な質問でつまづきました。試しに「大田区で有名な駅を 1 つ教えて」と聞いてみたところ、gemma4:e4b は自信満々にこう答えました。

大田区で特に有名な駅の一つは、大田駅（おおたえき）です。
（中略）東急大井町線などが乗り入れており、大田区の主要な交通結節点の一つとなっています。
その他、エリアの特性によっては、新大田駅なども利用される大きな駅です。

「大田駅」も「新大田駅」も、実在しません。しかも、その架空の駅に「東急大井町線が乗り入れる交通結節点」というもっともらしい乗り入れ情報まで添えています。典型的なハルシネーションですね。地名すらこの調子では、複雑なスペックから経済価値を判断させるのは到底無理だということで、軽量モデルは早々に候補から外れました。

同じ質問を、ひとつ上の gemma4:26b に投げると、答えが変わります。

大田区で最も有名な駅といえば、蒲田駅（かまたえき）です。
大田区の最大のターミナル駅であり、JR、京急、東急といった複数の路線が乗り入れる交通の要所です。

概ね意図どおりの回答が得られました。最低限の精度を求めるには、 26b が要るようです。

gemma4:26b は「蒲田駅」と正答。乗り入れ路線も正確な回答になっている。

ところが、 gemma4:26b を手元の RTX 5060 Ti で動かそうとして、最初の壁にぶつかります。gemma4:26b は 4-bit 量子化でも約 17 GB あり、VRAM 16 GB にわずかに収まりません。Ollama は収まらない分（約 35 %）を RAM 側に退避させ、その部分を CPU で計算します。結果、GPU と CPU を行き来する構成になり、計算時間が大幅に増えてしまいました。

ここで重要なのは、VRAM 不足が線形の劣化ではなく崖だということです。

理由は、LLM の推論がメモリ帯域に律速されるからです。推論の中身は、膨大な重みをメモリから読み出して計算する処理の繰り返しで、ボトルネックは計算量よりも読み出しの速さにあります。GPU の VRAM はこの読み出しが桁違いに速い一方、CPU 側へ退避した層は、それよりずっと帯域の狭いシステム RAM を経由します。

約 17GB のモデルが 16GB の VRAM に収まらず、Ollamaによって自動的にモデルの 約 35% が RAM/CPU へ退避する結果に。処理速度は VRAM 容量を超えた瞬間に崖のように急落する

私の PC のスペックはごくごく一般的なゲーミング用ですので、ローカル LLM を前提とした十分な VRAM を積んだ GPU でないとまともな推論能力は得られないというのが 2026 年 6 月時点の現在地となりそうです。

が、さすがにこの結果では終われないので、急遽 Google AI Studio から Gemma 4 の API を叩く形に切り替えました。これにより、Google 側が用意した計算資源を借りて、Gemma 4の26Bと31Bという大きめのモデルを（無料で）動かすことができます。一旦手元のハードの制約を外し、モデルそのものの実力を見にいきました。

結果と考察 — Gemma 4 vs Gemini

評価 30 件での実測をまとめます。ベースライン（線形回帰）は MAE 2.826 / MAPE 19.62 % / バイアス +0.092 でした。

モデル	実行環境	時間	コスト	MAE	MAPE	バイアス
線形回帰ベースライン	—	—	—	2.826	19.62%	+0.092
Gemini 2.5 Flash-Lite	API・並列×8	10.6 秒	2.10 円	3.177	17.42%	−2.203
Gemini 2.5 Flash-Lite	API・直列	64.9 秒	2.15 円	3.127	17.28%	−2.167
Gemini 3.5 Flash	API・並列×4	93.6 秒	29.61 円	3.157	17.11%	−2.283
Gemini 3.5 Flash	API・直列	約 5.3 分	28.97 円	3.340	18.24%	−2.367
Gemma 4 31B Dense	AI Studio・直列	約 27 分	0 円	3.317	18.25%	−2.39
Gemma 4 26B a4b	AI Studio・直列	約 1.4 時間	0 円	3.213	17.58%	−2.24
Gemma 4 26B	ローカル・直列	約 10.9 時間	118.21 円	11.566	71.14%	−6.604

同じ 30 件でも、実行環境によって所要時間は大きな差になる。最速のクラウド並列と最遅のローカル直列の開きは、約 3,700 倍

比較対象とするクラウドLLMは、Google 系列のモデルでそろえました。先述の通り、Gemma 4 は Gemini と同じ研究基盤から生まれたモデルなので、ある程度公平な比較と言えるでしょう。選んだのは次の 2 つです。

• Gemini 2.5 Flash-Lite（軽量クラウドモデル） — Gemma 4 とベンチマーク帯がほど近く、「同じくらいの賢さなら、ローカルとクラウドのどちらが割に合うか」というコスト対効果と、ローカルの代替になりうるかを見る役です。
• Gemini 3.5 Flash（最新ハイエンド） — つい先日、2026 年 5 月 19 日の Google I/O 2026 で GA になったばかり。「コストをかけて上位モデルにすれば、差は埋まるのか」という上限を確認する役です。世代の 3.1 Pro 比で大半のベンチマークを上回りながら、価格は約 25 % 安く、出力は約 4 倍速いとされています。並列4件になっているのは1分あたりのレート制限がGemini 2.5 Flash Liteよりも厳しいため。

考察を 3 点 挙げます。

まず、Ollamaローカル実行は、実行時間もコストも突出して重い。 同じ 30 件に対して、Gemini 2.5 Flash-Lite は並列で 10.6 秒・約 2 円。ローカルの 26B は約 10.9 時間・118.21 円。速度で約 3,700 倍、コストで約 60 倍の差です。VRAM溢れが発生するような欲張りなモデル選定を行った場合、という枕詞はつきますが、「追加コストは電気代だけだから安い」という直感には反する結果となりました。

一方で、これは「VRAM に収まらなかったとき」の数字でもあります。仮に RTX 4090（VRAM 24 GB）のように、gemma4:26b（約 17 GB）がまるごと載る GPU だったらどうでしょう。ここでは、AI Studio 版の 26B と同じ約 1.4 時間で終わると仮定して、電気代を試算します。

計算式は 消費電力(kW) × 時間(h) × 31 円/kWh（東京電力 従量電灯B 第2段階）です。時間を 1.4 時間に固定し、消費電力の前提だけを 3 通り変えてみると、以下の表のようになります。

消費電力（PC 全体の目安）	計算式	30 件の電気代
350 W（本実験のローカル機と同じ前提）	0.35 × 1.4 × 31	約 15 円
450 W（RTX 4090 の TDP＝GPU 単体ピーク）	0.45 × 1.4 × 31	約 20 円
600 W（4090 を積んだ PC 全体の高負荷時）	0.60 × 1.4 × 31	約 26 円

RAM 退避したケースに対して、4 分の 1 以下にとどまります。しかも 1.4 時間はクラウド側の所要時間で、フル GPU ならさらに速く・安くなる可能性が高い。とはいえ、Gemini 2.5 Flash-Lite が 2.1 円に収まることを鑑みると、「ローカル LLM は電気代だけだから安い＝APIコストをGPU投資によって回収できる」という神話は完全に否定されたと言えるでしょう。

同じ 30 件を Gemini 2.5 Flash-Lite の並列実行で処理した結果。所要時間は 10.6 秒

ふたつ目。どの LLM も、面積と徒歩だけの線形回帰（MAE 2.826）に、MAE で勝てていません。 何十億ものパラメータを持つ最新モデルが、2 変数のごく単純な式に及びませんでした。

一方で、指標MAPEを変えると景色は反転します。率で見る MAPE では、LLM 群はそろって 17 % 台に収まり、ベースラインの 19.62 % を下回りました。平均誤差では負け、率で見れば勝っている。 MAE は高額物件の絶対誤差に引っ張られ、MAPE は安い物件の外れも対等に扱います。どちらの物差しを採るかで、勝者がそのまま入れ替わるわけです。これは、「どの指標で測るか」を決めることが、結論そのものを決めてしまう、という実務的な教訓ですね。

MAE で負けた理由はおそらく、賃料というタスクがそもそも面積に対してほぼ線形で、「避けられない複雑さ」が低いからでしょう。タスクが単純なとき、単純なモデルが分散の大半を説明してしまいます。そこに LLM を持ち込むと、かえってノイズを上乗せする結果に終わってしまいます。

最後に、最新・高価なモデルほど効く、とは限らないことが浮き彫りになりました。 Gemini 3.5 Flash は、Gemini 2.5 Flash-Lite 比約 14 倍のコスト（約 30 円）をかけて、精度はほぼ横ばいでした。少なくともこの物件タスクでは、価格に見合う上積みは得られなかった、ということです。

肝心の良コスパ物件判定ですが、コスパスコア（実賃料 ÷ 予測相場）が 0.85 を下回る物件を「お買い得」として抽出したところ、安定して動いたモデルはどれもほぼ同じ顔ぶれを拾いました。筆頭は JR 京浜東北線・蒲田駅 徒歩 4 分の 2DK（実賃料 8.5 万円／予測相場 11.2 万円＝スコア約 0.76）で、これに鵜の木・パレスフロラシオンの 2DK が続き、お買い得はおおむね 3 件前後でした。もちろん今回取り扱った物件のスペックは限定的ですので詳細を吟味する必要はありますが、第一層の捌きとしては十分に絞り込めているのではないでしょうか。引っ越しを検討している同僚に試してもらってFBをもらっていけば、案外実用的なアプリとして運用できるかもしれません。

現在地の見立てと展望

実験を踏まえ、ローカル LLM の現在地の見立てを述べます。

現時点での結論として、実用的なのは Google AI Studio から Gemma 4 を叩く形でしょう。学習利用という枷こそあれど、無料で使え、Google 側の計算資源を用いて大きめのモデルも問題なく動きます。少なくとも、家庭用 GPU で 17 GB 級のモデルと格闘するよりは、ずっと現実的な選択肢でしょう。ただし、この無料枠がいつまで続くかは分かりません。AI企業は投資を回収するフェーズに入っており、利益にならない計算資源をどこまで無料で使わせてもらえるかは完全にGoogle側の経営判断に委ねられています。

次点は Gemini 2.5 Flash Lite などの軽量・高速モデル を用いることでしょう（この記事の執筆中に EOL が発表されてしまいましたが……移行先は Gemini 3.1 flash Lite ですかね）。Gemma 4 は、Gemini 2.5 Flash-Lite のような軽量・高速なクラウドLLMと比べて、推論力では一段劣る印象でした。費用対効果を考えると、軽量なクラウドLLMは安くてリターンの大きい投資であると考えます。少なくとも私ならこの選択肢を選ぶでしょう。

繰り返しになりますが、今回の検証はローカルLLMの「現在地を探る」ことを目的としています。ビッグテックによるLLMの開発競争は、さながら米露の宇宙開発の様相。ローカルLLMについても、量子化や知識蒸留技術の進歩によって（なんならムーアの法則的な計算資源面の改良にも期待しつつ）、さらなる軽量化・ベンチマークスコア向上が期待されます。特に今回題材に挙げた Gemma 4 については Gooole がかなり意欲的に開発を進めているので、今後とも注視していきたいです

今後の課題としては、本命のタスクである株式投資エージェントによるベンチマークでしょうか。今回、最新の Gemini 3.5 Flash も同じ土俵で回しましたが、賃貸予測タスクでは割高なだけで、明確な上積みはありませんでした。ただ、3.5 Flash の本領は、エージェントや金融まわりの複雑なタスクにあるとされています（金融エージェント向けのベンチマーク（Finance Agent v2）では、前世代の Gemini 3.1 Pro を大きく上回ったと報告されています）。だとすれば、その差が出るのは今回のような単純な題材ではなく、株式投資エージェントのような複雑な経済価値判断を要するシーンのはずです。時間を見つけて本来の戦場できちんと測っていきたいです。

おわりに

24 時間 365 日稼働し続ける「眠らない部下」には、電気代という無視できない額の請求書がついてまわります。1 kWh あたり 31 円のこの国で GPU を本気で減価償却しきろうと考えたとき、行き着く先はソーラーパネルを導入することしかないかもしれませんね。

データを手元に、計算を手元に、最後は電力まで手元に。ローカル化の旅は、案外その先まで続いているのかも……。

2026/06/04追記

なんて話をしていたら、Googleが「Gemma 4 12B」をリリースしましたね。今回のモデルはVRAM 16 GBで動くというところがプッシュされているようです。AI開発戦争は秒進分歩。ローカルLLMの 「本当の現在地」 については、ぜひ皆さんのほうで検証いただけますと助かります。

なんて間の悪い！！

---

私たちは一緒に働いてくれる仲間を募集しています！

電通総研 キャリア採用サイト 電通総研 新卒採用サイト

執筆：@kikuchi.s
レビュー：@miyazawa.hibiki
（Shodoで執筆されました）