自宅でローカルLLMを動かしてみたローカルなら実現できる遊びとこだわり

『Software Design 2026年9月号』の第1特集「開発の新戦力ローカルLLM」から第2章「自宅でローカルLLMを動かしてみた」を公開します。本特集のほかの章では、現実的な活用法として、ローカルLLMとクラウドLLMの使い分け、ローカルLLM基盤の構築事例についても解説しています。ぜひ本誌にてご確認ください。

本記事は、筆者が実際にローカルLLMを使用した経験を紹介することで、その追体験をしてもらいつつ、ローカルLLMに関する基礎知識や構成の具体的なケースを知ってもらうものです。

筆者がローカルLLMに触れた経緯

筆者が実際にローカルLLMを使い始めたのは、今から約3年前の2023年に遡ります。もともとは文章のベクトル検索などの、多次元ベクトルのクラスタリング問題に関心がありました。これは、自然言語で書かれた文章を、意味の近さを表す多次元の数値≒ベクトルに変換し、数学的に分類・検索しようという試みの一部です。そして、この文章を高度に数値化する技術が、LLMの基礎技術そのものでした。その過程で、文章のベクトル、すなわちembeddingを計算するのに、クラウドAPIのLLMではなく、ゲーム目的で購入したローカルのNVIDIA GeForce RTX 4070というGPUを搭載したグラフィックボードとオープンウェイトモデルを使えないかと考えたのがローカルLLMに触れるきっかけとなりました。そこからllama.cppやHugging Faceを知り、ファインチューニングをローカルで試してみるにまで至ります。

このようにローカルLLMに触れるうち、RTX 4070の12GBというVRAMでは動かせるモデルが限られることに不満を抱くようになり、もう少し大きなVRAMのグラフィックボードが欲しくなりました。そこで購入したのがRadeon RX 7600 XTというAMD製のGPUを積んだVRAM 16GBのグラフィックボードです。選定理由は、NVIDIA（CUDA）一強と言われる状況に疑問を抱き、AMD（ROCm）の現状を知っておきたいと考えたことが、大きな範囲を占めていました。

ハードウェアに詳しい方には、ここまで挙げてきたグラフィックボードからもうおわかりかもしれませんが、筆者の好みはワットパフォーマンス（電力効率）重視です。そのためハイエンドのグラフィックボードではなく、せいぜいミドルハイ止まりの選択となっています。価格が高騰した現在でも、10万円でお釣りがくるか来ないかという、比較的手が出しやすいものに惹かれます。

筆者の現在の主な興味は、ローカルLLMとAIエージェントを組み合わせたコーディングにあります。このRX 7600 XTをFedoraのマシンに載せ、llama.cpp（llama-server）を自分でビルドして、OpenCodeと組み合わせ、さまざまなモデルを試すような使い方をしています。

今ローカルLLMである理由

具体的な話題に入る前にまず、筆者がなぜローカルLLMに注目するのかを解説します。

「定額でトークン無制限」時代の終焉

いくつかの理由があるのですが、1番目に挙げるべきは「定額でトークン無制限」時代の終焉《しゅうえん》でしょう。これはクラウドLLMの利用形態として、長期的に計算リソースを占有する必要のあるエージェント型が多くなってきたことが関係していると考えています。エージェントとして利用されることで、クラウド側の計算リソースが占有されひっ迫し、リソースの追加のためにコストがかかっていることは、想像に難くありません。加えて昨今のニュースや経済状況を俯瞰《ふかん》してみると、多額の資金を必要とするAI提供企業に対して、投資家からの黒字化圧力が強まっている、という推測も成り立ちます。これでは「定額でトークン無制限」を維持できるわけがありません。

またトークン単価こそ下がっていますが、タスク単位でのトークン消費量は劇的に上がっています。これはAIの能力や精度が、長大なコンテキストや思考（reasoning）モデル、マルチエージェントなど、より多くのトークンを消費する手法によって向上したことによるものです。具体的な数字で言えば、単価は1/10になったが消費量は30倍になり、結果的にかかるコストが3倍になった、くらいの感覚です。

ただしここで留意すべきは、コストが3倍になったとしても、クラウドLLMのほうが安いということです。ローカルLLMの調達・維持・管理コストに昨今の価格高騰を考えると、クラウドLLMの安さが際立ちます。さらに純粋に合理性を突き詰めて、速度や精度を加味すれば、ローカルLLMはクラウドLLMの代替とはなり得ません。

オープンウェイトモデルの進化

2番目の理由は、オープンウェイトモデルの能力が向上してきたことです。オープンウェイトモデルとは、AIが学習した結果のパラメータ（重み）を公開し、誰でも自由に利用・改変できるようにしたAIモデルのことです。2025年後半から、エージェントとして利用可能な性能を持ち、かつ16GBのVRAM上でもそれなりに機能するモデルが増えてきました。「⁠それなりに機能する」とは、「⁠reasoningが機能し、精度が向上した」とも言い換えられます。ほんの1、2年前までは、実用的なコーディングをさせようとすると、小さくとも50B以上の大きなモデルを動かす必要がありました。このようなモデルを動かすためには、32GBや48GBのVRAMが必要になり、価格や消費電力からちょっと手が出しにくいものでした。しかし、それよりも小さなVRAM 16GBほどのミドルサイズのモデルでは、単純なコード補完程度はできても、プロジェクトの文脈を理解して自律的に動くにはエージェントとしての賢さ≒精度が不足しており、すぐに思考のループに陥るなどして自壊してしまっていました。それが2025年後半を境に、モデルの構造の進化や効率的な量子化技術によって、要求スペックが劇的に引き下げられたのです。執筆時点での代表的なモデルとしては、gpt-oss-20b、Qwen3.6-35B-A3B、gemma-4-26B-A4Bあたりでしょうか。またここで示したVRAM 16GBというのは、グラフィックボードとしてはミドルからミドルハイに相当する、比較的廉価で入手しやすいサイズ、というものです。つまりローカルLLMにおいて、コーディングエージェントが機能するようになってきたのが、まさに2026年現在なのです。

ローカルLLMを使ってみること自体の価値

また、蛇足かもしれませんが、もう1つだけそれらしい理由を挙げておきましょう。それは差別化です。今ITエンジニアの多くは、程度の差はあれどもその合理性に基づき、クラウドLLMを利用しています。しかしそこで最終的に成果を上げるのは、極論資本力にほかなりません。現状はまだエンジニアとしての経験がものを言う部分が大きいですが、お金さえ払えば誰でも同じような均質な成果を得られる未来は、一歩ずつ近づいています。そんな中で、ローカルLLMで得られる体験は、均質になりにくい≒差別化しやすい、ということが起こるかもしれません。これはロマンがある、ぜひ触れておきたい、そう思うのです。

ローカルLLMの構成

では、個人の環境で現実的に動かせるローカルLLMはどう構築したらよいのでしょう？　基本的なローカルLLMの構成は、グラフィックボード（GPU⁠）⁠、LLM推論エンジン、その上で動くオープンウェイトモデル、コーディングエージェントなどのAIアプリケーションの4つに分けられます（図1）。以下ではこの4つを少し詳しく解説してみます。

グラフィックボード

グラフィックボードにおいて、比較的にVRAMが多く、入手しやすいのがVRAM 16GBのラインになります。LLMを扱ううえではメモリは多いほうが有利なのですが、16GBを越えると価格上昇が急になります。GPUの選択肢としてはNVIDIA製が優勢なのですが、用途を推論に限るのならばAMDが割安なので選択肢に入ります。AMDはソフトウェア環境の構築・維持、速度に少し難がありますが、それを考えても入手容易性は魅力と言えます。

メモリサイズを優先するならば、Unified Memoryを採用している、Mac製品各種やNVIDIA DGX Sparkとその互換機も悪くない選択肢となるでしょう。Unified Memoryとは、CPUとGPUが高速なメモリを物理的に共有するしくみのことです。広大なメインメモリをそのままGPUから使えることで、速度はグラフィックボードに劣るものの、大きなモデルを動かすことができる技術です。また、ここで挙げたDGX Sparkは、そのUnified Memoryを採用した、コンパクトなデスクトップ型のAI開発向けのワークステーションです。通常のPCでは実現できない大容量と広帯域のメモリを、手元で静かに扱える機材として注目されています。さらに、このDGX Sparkと同じアーキテクチャをノートPCで使うための、RTX Sparkが発表され、2026年秋の発売が予定されています。こちらもおもしろい選択肢になるんじゃないかと期待しています。

LLMの生成速度を重視する場合、NVIDIA RTX Pro Blackwellシリーズが最善の選択になるでしょう。ただしプロ用ということもあり、価格が100万円前後とお小遣いと言える範囲からは大きく逸脱するので、難しいところですね。

LLM推論エンジン

LLM推論エンジンとは、グラフィックボードやCPUの計算能力を活用し、モデルのウェイトデータを実際に読み込んでテキストの生成処理を行う、ローカルLLMにおける心臓部といえるソフトウェアです。いわば、モデルウェイトという映像データを実際の動画として画面に映す、再生プレイヤーのような役割だと考えるとわかりやすいでしょう。筆者がよく使っている推論エンジンはggml-org/llama.cpp[1]です。これはC++で書かれた推論エンジンと、そのツール、コマンド群です。特にllama-serverコマンドは、OpenAI互換のAPIとチャットWeb UIサーバーを提供してくれます。Pythonのセットアップが不要でオープンモデルの推論が実行可能です。また各種のGPUにも対応しており、日に数度のリリースが行われて、代表的なアーキテクチャに対してはビルド済みバイナリが提供されています。

競合にはOllama、LM Studio、Unsloth Studioなどがありますが、いずれもllama.cppをベースにGUIなどを追加したものです。さまざまなパラメータを調整したり、リモートで動作させたりすることを考えれば、個人的にはllama.cppを直接使うほうに軍配を上げます。

llama.cppを利用するならば、モデルは公式に提供されている形式から、専用のGGUFフォーマットに変換する必要があります。ただ自分で変換する必要はなくて、変換済みのものがHugging Faceに多数公開されています。通常はそれらを使うだけでよいでしょう。オススメはUnslothによる量子化・変換済みモデルです。Unslothの量子化は、高い圧縮率によりモデルを小さくしながらも、精度低下を抑える高度な最適化が施されており、高い評価を受けています。

オープンウェイトモデル

すでに述べたとおり、2025年後半から、量子化込みでVRAM 16GBで動き、コーディングエージェントとしてそこそこ機能するモデルが増えてきました。代表例はQwen3.6やGemma 4です。加えて2026年中盤にはGemma 4 MTP Draftersが登場し、精度を維持したまま生成速度向上が見込めるようになったのも、後押しになっていると感じています。筆者は、ある日ビルドした最新のllama.cppがMTP Drafterに対応し、これまでローカルLLMの弱点の1つだった、1文字ずつ出力されるのを観測できてしまうほど遅かった速度を、MTP Drafterがノーリスクで一気に数段階引き上げるのを目の当たりにしました。この技術的な躍進を手元で体感したときはちょっとした感動ものでした。

執筆時点でVRAM 16GBで動くモデルは、gpt-oss-20b、Qwen3.6-27B、Qwen3.6-35B-A3B、gemma-4-26B-A4B-it、gemma-4-12B-itあたりとなります。Qwen3.6-35B-A3BなどのMoE（Mixture of Experts）モデルは、20個前後のエキスパートをCPUへ逃がす必要があるので、メインメモリもそれなりに必要になります。32GBくらいあるとよいはずです。

ローカルLLMのモデル選びは極論、モデル本来のパラメータサイズとそれを削る量子化（圧縮率）のトレードオフになります。たとえば、量子化を施していないオリジナルの状態（16ビット精度）で30Bのモデルを動かそうとすると、約60GBのVRAMが要求されるため、高価な機材が必須となります。そこで量子化によって、1パラメータを16ビットから4ビットや2ビットにまで圧縮し、全体としてサイズを1/4～1/8に削ることで、ようやく16GBのVRAMで動かせるようになります。当然、このような極端な圧縮を行えば、AIの賢さ≒精度は落ちますが、2025年後半以降のモデルの基礎能力と量子化技術の向上のおかげで、2ビットという極限まで削っても下がる精度は数ポイント程度に留まり、エージェントとして十分に実用的な精度を保てるようになりました。

コーディングエージェント／AIアプリケーション

コーディングエージェントは、プロンプトで指示することで、ソフトウェアプロジェクトに対してさまざまな操作を実行することができます。企業により提供されるコーディングエージェントには、Claude Code、Codexなどがあります。

オープンソースのコーディングエージェントにも、OpenCode、OpenHands、SWE-agents、Aider等々、複数の選択肢があります。オープンソースのコーディングエージェントは、AIのベンダーやモデルを自由に選べることから、ローカルLLMでの利用に適していると筆者は考えています。筆者は、その中でも特に自分が試してみたかった、Playwrightのテストエージェント機能が、OpenCodeに対応していたことから、OpenCode[2]を主に使っています。

筆者のローカルLLM環境構成

筆者が実際にローカルLLMを使っている構成はすでに示しましたが、ここで再度その詳細の紹介と、理由を説明します。

ここまでで説明していなかった最も重要な点は、ローカルLLMサーバーを動かすマシンと、実作業を行うワークスペースのマシンを分けているという点です。つまりリモートでローカルLLMサーバーを動かしています（図2）。こうやって書いてみるとややこしいですね。

実作業にはWindowsのMSYS2環境を利用しています。リモートのローカルLLMサーバーは、LinuxディストリビューションのFedoraでllama-serverを動かしてLAN越しにアクセスしています。詳細な構成は次のとおりです。

作業用マシン
- OS：Windows 11＋MSYS2（MSYSTEM=UCRT64）
- AIアプリケーション
  - OpenCode（コーディングエージェント）
  - その他、自作のアプリケーション複数
- GPU：RTX 4070
- CPU：Core i9-9900K
- RAM：64GB
ローカルLLMマシン
- OS：Fedora Linux 44（Xfce）
- 推論エンジン：llama-server（ggml-org/llama.cpp）
- 主な利用モデル
  - unsloth/Qwen3.6-35B-A3B-MTP-GGUF[3]
  - unsloth/gemma-4-26B-A4B-it-qat-GGUF[4]
  - unsloth/gemma-4-12B-it-qat-GGUF[5]
- GPU：RX 7600 XT
- CPU：Ryzen 9 5950X
- RAM：128GB

ローカルLLMを実行するマシンと、実作業用のマシンを分ける最大の利点は、長い時間がかかるタスクを実行している最中でも、実作業用のマシンに負荷がかからないことです。以前、作業用マシンのRTX 4070で推論作業を実行中に、そのままWebミーティングに参加してしまい、作業用マシンでのあらゆる作業がものすごく遅くなってしまったことがありました。この構成であればAIに作業させている間に、GPUを使うゲームももちろん快適に遊べますね。

llama-serverはOpenAI互換のAPIを提供してくれるので、リモートでLLMを動かすことが簡単です。リスト1にOpenCodeでリモートのローカルLLMを利用する設定例を示します。

リスト1 OpenCodeの設定例

{ 
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama.cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama-server (LAN)",
      "options": {
        "baseURL": "http://192.168.0.2:8080/v1",
        "apiKey": "dummy"
      },
      "models": {
        "loaded-model": {
          "name": "Loaded model"
        }
      }
    }
  },
  "model": "llama.cpp/loaded-model"
}

この構成の弱点は、OpenCodeをWindowsのネイティブに近い環境で動かしていることです。OpenCodeは公式にはWSL内での実行を推奨しています。その推奨とは異なる環境で動かしていることで、AIが実行したツールが失敗し、余計な処理が必要になっているのを観測しています。いくつか取っている対策はあるのですが、公式に推奨されているWSL内で実行するほうが良い結果になりそうです。

もちろんWSLの中で動かせば、問題なく動く可能性が高いのはわかっています。しかし、筆者は昔からWindows/MSYS2のネイティブ環境をずっと使ってきました。自分が慣れ親しんだ環境でエージェントを動かし、その違いにより失敗するエージェントのケアをする。こういう倒錯した試行錯誤でこそ、エンジニアとしての本懐とも言える、奇妙な知的好奇心が満たされたりするものです。

ローカルLLMを使った作例

このようなローカルLLMを用いて、筆者がどのようなことをしてきたのかを紹介します。

E2Eテストの自動設計⁠・自動作成

まずはローカルLLMでPlaywrightのテストエージェントを使った話を紹介しましょう。Playwrightのテストエージェント（Playwright Test Agents[6]は、テストの設計、実装、維持をAIにやらせるための機能です。これを試したくてOpenCodeを採用した、というのはすでに書いたとおりです。テストエージェントは設計を担当するプランナー、実装を担当するジェネレータ、維持を担当するヒーラーの3つのサブエージェントから構成されています。

導入は非常に簡単で、導入したいプロジェクトに対して次のコマンドでPlaywrightとテストエージェントをセットアップするだけです。

$ npm init playwright@latest 
$ npx playwright init-agents --loop=opencode

ここで実際にやっていることは、前述の3つのサブエージェントを定義するファイルの作成です。その後OpenCodeを起動し、/initコマンドでAGENTS.mdを作ります。あとは各サブエージェントに対して指示を出すだけです。次のプロンプト例はプランナーを使って、拙作のnvgd[7]というDevOps向けのHTTPサーバーのUIの一部に対して、テストを計画・設計させたときのものです。

> @playwright-test-planner OPFSプロトコルのE2Eテストを計画して

このようなアバウトな指示でも、ローカルLLMがソースコードを読み取ってそれなりの計画を作ってくれました[8]（リスト2）。

リスト2 ローカルLLMで作成したテスト計画（抜粋）

# OPFS E2E Test Plan

## Application Overview

OPFS（Origin Private File System）プロトコルのE2Eテスト計画。NVGDサーバー（http://127.0.0.1:9280）の/opfs/パスで提供されるファイルシステムUIのテスト。OPFSはブラウザのnavigator.storage.getDirectory() APIを使用し、Secure Context（localhost/HTTPS）で動作する。テストはChromium、Firefox、WebKitの3ブラウザで並列実行。

## Test Scenarios

### 1. 01-navigation

**Seed:** `tests/seed.spec.ts`

#### 1.1. OPFSページが正常に読み込まれる

**File:** `tests/opfs/01-navigation.spec.ts`

**Steps:**
　1. http://127.0.0.1:9280/opfs/ にアクセス
　　- expect: タイトルが"OPFS: /"である
　　- expect: h1に"OPFS: Origin Private File System"が表示される
　　- expect: パンくずリストに"(Root)"が表示される
　2. ページタイトルを確認
　　- expect: ページタイトルが"OPFS: /"である
　3. h1要素の内容を確認
　　- expect: h1要素に"OPFS: Origin Private File System"が含まれる
　4. パンくずリストの内容を確認
　　- expect: パンくずリストに"(Root)"が表示される

#### 1.2. サブディレクトリのナビゲーション（クリック）
（..略..）

このあとの手順はジェネレータに実装させ、エラーがあったらヒーラーに直させるという手順になります。ただ正直に言いますと、この後に一発で全部のテストケースを実装できたわけではありません。というのも、一度のセッションで全部実装させるには、現時点のローカルLLMでは精度と速度が足らず、何回もやりとりを繰り返すことになったためです。1セッションで実装するテストケースは1個ずつにする、というような工夫が要りそうです。LLM自体が万能の魔法ではないと実感することで、逆にどうすれば実用に耐えうる使い方ができるかという、設計を楽しむ余地が残されている、と考えることもできますね。

翻訳専用モデルのクライアント

次は、翻訳用にファインチューニングされたモデルをローカルLLMとして動かし、それにアクセスするクライアント、すなわち簡易なエージェントを作った作例です。使用したモデルはwebbigdata/C3TR-Adapterで、これはGemma 2を日英・英日の翻訳に特化してファインチューニングしたモデルです[9]。このモデルが公開されたのは約2年前なのですが、当時の筆者は飛びついてクライアントを作成しました。それがkoron/c3tr-client[10]です。

ここで注目してほしいのは反復翻訳機能です。ここで言う反復翻訳というのは、翻訳する際に相互に翻訳を繰り返して、翻訳後の文の内容を検証する一連の作業のことです。やっていることは、目的の言語への訳文の変化がなくなるまで相互に翻訳を繰り返すだけなのですが、あらためて考えてみるとAIにおける「ハーネス」にほかなりません。

ちなみに最新のGemma 4では、ファインチューニングなしに翻訳が可能です。しかも140以上の言語に対応し、音声入力にも対応しているらしいです。本当にものすごく進化していますね。

ローカルLLMは、クラウドLLMよりも速度は圧倒的に遅いですが、意外としっかりした振る舞いをします。しかし精度と速度の問題はあるので、本格的に利用するには、エージェントやそのハーネスの設計で工夫のしがいがありそうです。

実際にローカルLLMを使ってみて⁠、どう思ったか

2026年7月の執筆時点において、実際にローカルLLMを使ってみて、筆者がどのように感じたかを書きます。

まず何より、1年前に比べて、圧倒的にコードが書けるようになっていました。ローカルLLMとして動くreasoningモデル自体は、2025年の初頭から登場していました。しかし当初はいまいちだったと言わざるを得ません。でも今年は状況が一変しています。もちろんクラウドLLMに比べれば問題はあるものの、現時点でもはるかにコードが書けるようになっています。しかも、これまでの進歩の速度を考えれば、来年や再来年にはどうなってしまうのか、と期待をしてしまいます。

次に、速度をはじめとした実利を求めると、NVIDIA製GPUと比べるとAMD製のGPUはやはり弱いと思い知らされます。特にCUDAというソフトウェア環境の充実は、NVIDIAの大きな強みです。AMDにおいてCUDAと同等のレイヤーになるのがROCmですが、CUDAほどには多くの環境に提供されておらず、自分でビルドが必要だったりと一手間余分に必要です。そのためか推論エンジンにおいてもROCmへの最適化などが遅れ、ハード性能だけではなくソフトウェアでも一歩劣っている状況が、2026年現在でも続いています。

VRAMは32GBくらいあると、モデルの選択肢が広がり、遊べる≒試せることが増えそうです。16GBでは、強めの量子化を使っても20B程度までの中型モデルが、利用できる限界です。しかしオープンウェイトのモデルには、30Bから40Bのものもラインナップとして提供されがちです。そのあたりのモデルを試して比較したい、という気持ちになります。そこで今はNVIDIA RTX PRO 4500 Blackwellを購入するか迷い始めています。

最後に、実際にローカルLLMを触ってみたことで、Transformerの構造的な弱点を実感できました。Transformerはその動作において、大きく分けてPrefillとDecodeという2つの段階から成っています。PrefillというのはTransformerが文字を出力し始める準備段階で、Decodeは実際に1文字ずつ出力する段階です。どちらもコンテキストが長くなると、コンテキスト長nに対して、O(n2)の計算量がかかり、非常に遅くなっていきます。

KVキャッシュを利用していて、用途がチャットであれば、この計算量を実感することは少ないです。しかし特にコーディングエージェントでの利用で、ファイルを読んで一気にコンテキストが大きくなったときなどは、Prefillが終わって1文字目が出力≒Decodeされるまで、待ち時間は10分や20分にも至ります。マシンのファンは唸《うなり》を上げ、熱い空気を吹き出します。しかし画面は通信中を示したまま静止しています。このローカルLLMにおける「計算リソースの限界と対峙《たいじ》している時間」は、クラウドLLMの裏側にある莫大なインフラの暴力、すなわち資本力を生々しく実感できる瞬間です。まぁ家事をしたり本を読んだり動画を観賞したりできちゃうんですけどね。

このようなO(n²)のアルゴリズムを、サービスとして大規模に提供することを考えると、ITエンジニアとしては軽くめまいを覚えます。クラウドLLMが提供しようとしている「均質で圧倒的なパワー」は、このTransformerという巨大な大食漢を、想像もつかないほどの資本の力で養っていることで得られるものです。ローカルLLMを自ら運用し、その限界と構造的な弱点を実際に体感したからこそ、筆者はクラウドLLMのいびつな安さと、その裏にあるインフラのすごさに思いを馳せることができました。巨大な資本の力に頼るだけでなく、ローカルLLMの限界と向き合いつつハックし続けること。これからのエンジニアの、小さいけれどもユニークな「差別化」になるのかもしれません。それはそれとして、クラウドLLM提供企業の収益性・持続性については、ちょっと心配になってしまいますね。個人的にはTransformerとは別のアプローチに期待するところです。