2026年8月19日更新：初版。研究内容は本日付時点のものです。
言語モデルをブラウザのタブではなく、自分のハードウェア上で実行する理由は 4 つあり、そのうちの 1 つだけがイデオロギー的なものです。プライバシー: ローカル モデルに渡すドキュメントはマシンから決して外に出ません。これは、クライアント コード、契約、患者データ、未リリース製品に関するすべてのやり取りです。コスト構造: クラウド AI は従量制で、エージェント ワークロードはトークン カウントを十分に速く増加させるため、高性能ワークステーションは自己資金で賄えます。所有するハードウェアは電気代で稼働します。可用性: レート制限がなく、停止もなく、火曜日にワークフローを変更する廃止通知メールもありません。そして制御: 検証したモデルは、別の決定をするまで実行し続けるモデルです。
一方で、最先端のクラウドモデルは依然として高い能力を備えており、長期的なエージェント業務においてはその差は顕著です。ローカルモデルが同等の能力を発揮できるのは、チャット、要約、単一ファイルのコード、ドキュメントの質疑応答といった限定的な作業に限られます。これは、ほとんどの人が1日を通して行っている業務の大部分を占めています。もし、あらゆるコストで最大限の能力を求めるのであれば、クラウドを利用するのが良いでしょう。しかし、プライバシー、コスト、あるいは制御性を重視するのであれば、ローカル環境は現状でも十分に実用的であり、このページはそのための道しるべとなるでしょう。
その枠組みに基づいてハードウェアの予算を決めましょう。ローカルAIへの投資は、何よりもまずメモリの決定が重要になります。16GBのVRAMまたは32GBの統合メモリで、上記の制限された作業を処理できる7～8Bクラスに対応できます。24～32GBのVRAM、または48GBの統合メモリで、エージェントコーディングがデモではなくなる30Bクラスに到達します。96～128GBの統合メモリで、最先端の品質に近づく100B以上のモデルを実行できます。過剰に購入しても気づかないほどのスピードアップになりますが、不足すると、目的のモデルクラスがまったくロードされません。ローカルAIに最適なノートPCとローカルAIに最適なデスクトップPCのボードでは、マシンをティア別にランク付けしています。このページでは、それらのマシンで実行できるものについて説明します。
ソフトウェア面はハードウェアほどスムーズに成熟していません。現在検索結果で推奨されているツールの約3分の1は既に使われなくなっており、それらを推奨しているページのほとんどはそれに気づいていません。
このページでは、2026年8月時点での動作状況とハードウェア構成を追跡しています。現時点では、中立的で検証可能な指標であるGitHubのスター数を基準にランキングしていますが、ツールがクローズドソースでスター数がない場合はその旨を明記しています。表中のツール名はすべて、公式ダウンロードページへのリンクとなっています。各プラットフォームを検証する過程で、「ガイド」欄には、具体的なセットアップ手順と独自の数値データが追加されます。
このページには3つのルールがあります。まず、ローカルモデルとローカルエージェントを区別します。いくつかの製品はユーザーのマシン上で動作しますが、推論呼び出しはすべてベンダーのクラウドに送信されます。これはプライバシー保護のための措置であり、オフライン機能ではありません。そのため、これらのツールは削除するのではなく、ページ下部に別途記載しています。次に、すべての項目に現実的なハードウェア最小要件を記載します。「ノートパソコンで動作する」というだけでは、メモリ容量の数値が示されていないため意味がありません。最後に、FAQでは、削除された項目とその日付を記録しています。
おすすめ商品
最優秀ローカルLLMランタイム：オラマ
デフォルトの回答であり、他のほとんどのツールが通信するものです。MIT ライセンスで、GitHub のスターは約 179,000 個あり、現在は CLI に加えてデスクトップ GUI も提供されています。1 つのコマンドでモデルを取得し、localhost 上に OpenAI 互換のエンドポイントを公開し、2026 年 1 月に Anthropic Messages API との互換性を追加しました。これにより、人々は現在、ローカル モデルに対して Claude Code を指示しています。最小要件: 3B モデルの場合は 8GB システム RAM、7-8B の場合は 16GB、30B クラスの場合は 24GB VRAM。
ハードウェアのベンチマークに最適：LM Studio
クローズドソースなのでスター数は表示されませんが、それでもその価値はあります。LM Studio は llama.cpp と MLX の両方をバンドルし、マシンを使用するのではなく測定する場合に重要なコントロール、つまり GPU オフロード レイヤー、量子化の選択、コンテキストの長さ、マルチ GPU 動作を公開します。2025 年 7 月以降、商用利用は無料です。これは、ワークステーションとラップトップのボードにあるトークン/秒の数値のほとんどの背後にあるツールです。最小要件: 16GB RAM、興味深い動作をするには 24GB VRAM または 32GB 統合メモリ。
最適な基盤エンジン: llama.cpp
このページにある他のほとんどすべては llama.cpp の下流にあります。 MIT ライセンスで、約 124,700 のスターがあり、1 日に複数のタグ付きビルドが公開されています。ハードウェアのユーザーにとって重要なのは、特定の理由からです。バックエンドのリストは膨大で、CUDA、ROCm、Metal、Vulkan、SYCL、CANN、OpenCL をカバーしており、ベンダーのエンジニアが最適化を直接貢献しています。ビルド 8688 の Intel Arc のプリフィル改善は、約 5 倍の価値があり、すべての Ollama および LM Studio ユーザーは何もインストールせずにそれを利用できました。最小要件: CPU のみで動作し、8GB の RAM が使用可能です。
最高のローカルファーストデスクトップアプリ：1月
Apache 2.0、約44,100スター、2026年7月時点でv0.8.4。Janはllama.cppをバンドルしているので、他にインストールする必要はなく、ネットワークケーブルが抜かれていても動作します。このカテゴリのアプリのうち、Ollamaフィールドを持つクラウドクライアントがいくつあるかを確認するまでは、これは低いハードルのように聞こえます。これは、ターミナルを決して開かない同僚に渡すのに最適です。Document RAGが弱点です。最小要件: 8GB RAM。
最高のローカルドキュメントRAG: AnythingLLM
MIT の評価は約 64,800 スターです。ベクター データベースをバンドルし、設定なしでチャンキングと埋め込みを処理するため、デスクトップ クラスで最もすぐに使えるドキュメント チャットとなっています。隠すつもりのない 2 つの点があります。2026 年 3 月に CVSS 9.6 と評価された脆弱性があり、モデル自身のストリーム レスポンスによってリモート コード実行がトリガーされる可能性がありましたが、バージョン 1.11.2 で修正されているため、使用する前にアップデートしてください。また、ローカル ファーストとして宣伝されているアプリでは、テレメトリがデフォルトで有効になっていますが、設定で無効にできます。最小要件:ドキュメント作業には 16GB RAM。
最適なセルフホスト型マルチユーザー：Open WebUI
約149,000個のスターと、最も詳細な取得設定機能を備え、v0.11.0は2026年7月に出荷予定です。デスクトップアプリではなく、自己ホスト型サーバーなので、Dockerがエントリーポイントとなります。構築する前に知っておくべきことが1つあります。2025年4月にライセンスがBSD-3からOSI承認されていないカスタムライセンスに変更され、Open WebUIのブランドを削除することを禁止する条項が追加されました。ただし、30日間の期間で50ユーザー未満の場合は例外となります。小規模で変更せずに実行すれば、何も変わりません。最小要件：別のランタイムとコンテナ用に4GB。
最高のローカルコーディングエージェント：クライン
Apache 2.0、約63,900スター。Clineは、OllamaとLM Studio専用に構築されたコンパクトなシステムプロンプトや、モデルファミリーごとのネイティブツール呼び出しなど、競合他社よりもローカルパスで多くの実際のエンジニアリングを行ってきました。クラウドが依然として優位に立っている点について、Cline自身のドキュメントは異例なほど率直です。最小要件： 24GBのVRAMまたは36GBの統合メモリ、コンテキストを32K以上に設定してください。
最高のオフラインターミナルコーディング：Aider
Apache 2.0、約48,300スター、そしてアーキテクチャ的に最も信頼性の高いローカルオプションであるのには、理解する価値のある理由があります。AiderはJSONツール呼び出しを一切使用しません。プレーンテキストからdiffと全ファイル編集フォーマットを解析することで、ローカルモデル上のほとんどのエージェントを壊すまさにその障害モードを回避します。注意点はメンテナンスです。コミットの96%は1人の作者によって書かれており、リリースサイクルは2026年に1回の安定版リリースにまで縮小しています。最小要件： 24GB VRAMまたは36GB統合メモリ。
最高のセルフホスト型エージェントプラットフォーム：OpenHands
MIT、約84,500スター。OpenHandsはローカルモデルを適切に文書化し、さらに便利なことに、問題がセットアップにあるのではないことを教えてくれます。ドキュメントには、エージェントがチャットボットのように動作したり、ツールが常に失敗したりする場合は、モデルが制限であると記載されています。22Kのコンテキストを最小として要求し、32Kを推奨します。最小要件：量子化モデルの場合は24GBのVRAM、または64GBの統合メモリ。
最高の無料オフラインサプライズ：GitHub Copilot CLI
2026 年 4 月以降、Copilot CLI は Ollama、vLLM、および Foundry Local に対して実行されます。GitHub 認証はオプションであり、Copilot サブスクリプションは不要です。COPILOT_OFFLINE を設定すると、すべてのテレメトリとネットワーク接続が停止し、サブエージェントはローカル プロバイダーを継承します。ほとんどの比較記事では、依然としてクラウド専用として記載されています。分割に注意してください。IDE 拡張機能は、独自のキーを使用する場合でも、インライン補完をクラウドに送信します。最小要件:コンテキスト ウィンドウが 128K のモデル、つまり 32GB VRAM または 64GB 統合メモリ。
ベンダー支援型サーバー最優秀賞：Lemonade
Apache 2.0ライセンス、約5,400個のスターを獲得しており、ハードウェアへの忠誠心ではなく、その性能に基づいて推奨できる唯一のベンダー関連ツールです。AMDのエンジニアがメンテナンスを担当しており、NVIDIA CUDA、Apple Metal、Vulkan、通常のCPUに加え、RadeonおよびRyzen AI NPUでも動作します。約2週間ごとにリリースされ、2026年4月にデスクトップアプリをElectronからTauriに移行しました。最小要件： 16GB RAM、NPUパスの場合はRyzen AI 300シリーズ以降。
ファイルシステム全体を対象とした最高のローカルRAG：Nexa AI ハイパーリンク
クローズドソースで無料です。デバイス上のファイルシステム全体をインデックス化し、インライン引用で回答します。このツールがリストに掲載されている理由は、コンシューマー向けハードウェアでの高速化数値を公開している唯一の新しいローカルRAGツールだからです。RTX 5090では、インデックス作成が約3倍、推論が約2倍高速化され、1GBのフォルダの処理時間が約15分から4～5分に短縮されます。最小要件：最新のRTX GPU、16GB RAM。
ランタイム：モデルを実際に実行するものは何か
これがエンジンです。次の2つの表にあるものはすべて、これらのいずれかと通信するフロントエンドです。GitHubのスター数順に並んでいます。
| ランタイム | 星 | ライセンス | 最小ハードウェア | 加速 | ガイド |
|---|---|---|---|---|---|
| オラマ | 〜179,000 | マサチューセッツ工科大学（MIT） | 8GB RAM（3B）、16GB（7～8B）、24GB VRAM（30Bクラス） | CUDA、ROCm、Metal、Vulkan | 近日発表 |
| ラマ.cpp | 〜124,700 | マサチューセッツ工科大学（MIT） | 8GB RAM、CPUのみで動作します | CUDA、ROCm、Metal、Vulkan、SYCL、CANN、OpenCL | 近日発表 |
| MLX / mlx-lm | 〜27,500 | マサチューセッツ工科大学（MIT） | Apple Silicon、16GB統合メモリ | Metal; CUDAバックエンドは2026年に追加予定 | 近日発表 |
| LMスタジオ | クローズドソース | 独自開発、商用利用無料 | 16GB RAM、24GB VRAMまたは32GB統合 | llama.cppとMLXをバンドルします | 近日発表 |
| vLLM | 生産サービス | Apacheの2.0 | 24GB VRAM リアルな床 | CUDA、ROCm | 近日発表 |
デスクトップアプリとローカルRAG
読者がインストールするアプリ。特に注意すべきは「ローカル優先」列です。この列では、お使いのマシン上でモデルを実行するソフトウェアと、Ollama URL用のフィールドを追加するソフトウェアが区別されています。
| アプリ | 星 | ライセンス | 地元優先 | 最小ハードウェア | ガイド |
|---|---|---|---|---|---|
| WebUIを開く | 〜149,000 | カスタム品であり、OSI承認品ではありません。 | サーバーとして使用可能（デスクトップではない） | コンテナ用に別途ランタイムと4GBが必要 | 近日発表 |
| なんでもLLM | 〜64,800 | マサチューセッツ工科大学（MIT） | 対応可能。テレメトリはデフォルトで有効。 | RAM 16GB | 近日発表 |
| XNUMX月 | 〜44,100 | Apacheの2.0 | はい、llama.cpp をバンドルします | RAM 8GB | 近日発表 |
| LMスタジオ | クローズドソース | プロプライエタリ | はい | 16GB RAM、24GB VRAMは興味深い | 近日発表 |
| ムスティ | クローズドソース | 独自規格、無料プラン | はい、Ollama、MLX、llama.cpp をバンドルします | RAM 8GB | 近日発表 |
| Nexa AI ハイパーリンク | クローズドソース | 独自開発、無料 | はい、デバイス上でのインデックス作成 | 最新のRTX GPU、16GB RAM | 近日発表 |
コーディングとエージェントツール
これらは、ページ上で最もハードウェア負荷の高い項目です。なぜなら、エージェントによる処理には大きなコンテキストウィンドウと長時間のセッションが必要となるからです。32GBのVRAMまたは64GBの統合メモリが、これがデモではなくなる限界点だと考えてください。
| ツール | 星 | ライセンス | ローカル パス | 最小ハードウェア | ガイド |
|---|---|---|---|---|---|
| オープンハンズ | 〜84,500 | マサチューセッツ工科大学（MIT） | LM Studio、Ollama、vLLM、SGLang | 24GB VRAMまたは64GB統合メモリ、32Kコンテキスト | 近日発表 |
| クライン | 〜63,900 | Apacheの2.0 | Ollama、LM Studio、OpenAI互換 | 24GB VRAMまたは36GB統合 | 近日発表 |
| グース | 〜52,900 | Apacheの2.0 | Ollama一流企業。現在はLinux Foundation。 | 24GB VRAMまたは36GB統合 | 近日発表 |
| 助けます | 〜48,300 | Apacheの2.0 | Ollama、OpenAI互換。ツール呼び出しなし | 24GB VRAMまたは36GB統合 | 近日発表 |
| ゼッド | バージョン1.0、2026年4月 | Apacheの2.0 | LM Studio、Ollama、llama.cpp | 24GB VRAMまたは36GB統合 | 近日発表 |
| GitHub コパイロット CLI | クローズドソース | 独自開発のため、購読は不要です。 | オラマ、vLLM、ファウンドリー・ローカル | 32GB VRAMまたは64GB統合メモリ、128Kコンテキスト | 近日発表 |
ベンダーの取り組み
すべてのシリコンおよびOSベンダーがローカルAI向けの製品を出荷しており、その名称が紛らわしく、廃れ率も高いため、このカテゴリは独自の項目として扱うべきである。2026年を通してのパターンは一貫している。ベンダーはサードパーティスタックとの競争をやめ、サードパーティスタックに製品を提供し始めた。NVIDIAは自社のローカルAI製品を両方とも廃止し、現在はOllama、llama.cpp、およびComfyUIの最適化を公開している。AMDはLM Studioと共同ブランドを展開している。Qualcommは他社のアプリを移植することでNPU機能を出荷した。
OllamaやLM Studioではできない、ベンダーツールができることの一つは、NPUへのアクセスです。llama.cppにはNPUバックエンドがないため、SnapdragonやRyzen AIマシンでは、これらのツールはニューラルエンジンを0%しか使用しません。40～60 TOPSの料金を支払ったとしても、それを使用するのはベンダーパスだけです。ただし、期待値を調整してください。NPUは現在、70億モデル程度が上限で、メリットはスループットではなく、常時稼働の小規模モデル作業におけるバッテリー寿命です。ディスクリートGPUは、速度の点で常にNPUを上回ります。
| ベンダー | それは何ですか | タイプ | 必要なハードウェア | ステータス | ガイド |
|---|---|---|---|---|---|
| AMDレモネード | サーバー、GUI、SDK。スター数約5,400、Apache 2.0ライセンス。 | アプリ＋サーバー | 16GB RAM、NPUにはRyzen AI 300+を使用。NVIDIA、Apple、CPUでも動作します。 | 活動中、約2週間ごとに発送 | 近日発表 |
| Intel OpenVINO GenAI | ランタイムとSDK；約10,700スター | SDK | Core Ultra、Arc A/Bシリーズ、16GB RAM | アクティブ、2026年8月時点で2026.3 | 近日発表 |
| Apple Foundationモデル | OSによって公開されるデバイス上のモデル | OSフレームワーク | Apple Silicon; 既にインストール済み | 有効。WWDC 2026で全てのプロバイダーに開放。 | 近日発表 |
| マイクロソフト・ファウンドリー・ローカル | ローカル推論SDKおよびCLI。スター数約2,400。 | SDK | Windows、macOS、Linux、NPU/GPU/CPU | 一般公開予定：2026年4月；厳選モデルカタログ | 近日発表 |
| AMD ガイア | Ryzen AI向けローカルLLMアプリ。約1,400スター、MIT | アプリ＋SDK | Ryzen AI 300シリーズ以上（最小要件）、RAM 16GB（推奨64GB） | アクティブ、v0.20.0 2026年6月 | 近日発表 |
| インテル AI プレイグラウンド | デスクトップアプリ；約900個の星 | アプリ | Arc Aシリーズ 8GB+、Arc Bシリーズ、Core Ultra | 2年経ってもまだベータ版のままだが、活発に活動している。 | 近日発表 |
| クアルコム GenieX | Snapdragon NPU向けオンデバイスGGUFランタイム | ランタイム | Snapdragon X / X Elite、8 Elite | 開発者向けプレビュー版、2026年7月 | 近日発表 |
| NVIDIA プロジェクト G-Assist | システム制御用のデバイス内8Bアシスタント | アプリ | RTX 20シリーズ以降、6GB VRAM | アクティブだが、まだプレリリース版と表示されている | 近日発表 |
名称に関する注記。NVIDIAの「RTX AI Garage」は製品名のように聞こえますが、実際は製品ではなく、ブログシリーズです。Microsoftのスタックは何度も名称変更されています。Copilot Runtime APIはWindows AI APIに、Azure AI FoundryはMicrosoft Foundryに、そしてDirectMLは現在、セキュリティ修正のみを行うメンテナンスモードになっています。Qualcomm AI Hubは、物理デバイスをリモートでプロビジョニングするクラウドサービスであり、ローカルで実行するものではありません。
よく壊れるもの
ローカルモデルが「動作しない」という報告のほとんどは、モデルの問題ではなく、設定の問題です。特に以下の4つの問題が大きな割合を占めており、ハードウェアに関心のある人であれば、シリコンのせいにする前にこれら4つの問題を知っておくべきです。
1. Ollama はデフォルトで 4,096 トークンのコンテキストを使用します。この制限を超えてもエラーは発生せず、静かに切り捨てられ、エージェント ループは静かに終了します。本格的なハーネスでは、より多くのトークンが必要です。OpenHands は最低 22K、推奨は 32K、Codex は 32K、Copilot CLI は 128K、Cline は 262,144 に設定しています。この設定は、おそらくオンラインで見かける障害報告の最も一般的な原因です。
2. KVキャッシュの量子化は、特にツール呼び出しの性能を低下させます。これは、一般的な出力品質が目に見えて低下する前に発生します。llama.cppのドキュメントには、この点について直接警告が記載されています。エージェントを実行している場合は、これを無効にしてください。
3. ツールの数は、緩やかな傾斜ではなく、急激な増加です。上記では、およそ 5 または 6 つのツールが対象範囲にあります。一部のモデルは、有効な JSON ツール呼び出しを静かに停止し、代わりにレスポンスボディに XML を埋め込むようになります。ハーネスはこれを「ツールが使用されていません」と読み取ります。ある人気のあるエージェントは、デフォルトで 11 個のツールを出荷し、2026 年初頭まで推奨モデルを壊しました。実際的な結果は直感に反します。多数の MCP サーバーに負荷をかけることは、最前線モデルとは異なり、ローカルモデルでは積極的に有害です。
4. Q4_K_Mは実用的な最低値です。これ以下では、ツール呼び出しの信頼性が全体的な品質よりも急速に低下するため、モデルは音は正常に聞こえるものの、実際には何も機能していません。
メモリが制約となる
このページに掲載されているすべてのツールにおいて、実行できる内容を決定するのは、アクセラレータが認識できるメモリ容量です。これらは、エージェント関連の作業で最もよく挙げられる組み合わせであり、私たちがラボで検証しようとしている組み合わせでもあります。
| Hardware | モデル | フットプリント | 報告されたスループット |
|---|---|---|---|
| RTX 5090、32GB | Qwen3.6-35B-A3B Q4_K_M | 〜21GB | 160～180トーク/秒、262Kコンテキスト |
| RTX 5090、32GB | Qwen3-Coder-30B-A3B Q4_K_M | 〜19GB | 24GBクラスで50～90トークン/秒 |
| RTX 5090、32GB | デブストラル・スモール 24B Q4_K_M | 〜14GB | ツール呼び出し専用に設計されています |
| RTX PRO 6000、96GB | GPT-OSS 120B MXFP4 | 〜63GB | ワークステーション用カード1枚に搭載された100BクラスのGPU。当ラボのレビュー対象製品です。 |
| RTX PRO 5000搭載ノートパソコン、24GB GDDR7 | Qwen3-Coder-30B-A3B Q4_K_M | 〜19GB | これまでテストした中で最大のノートパソコン用GPU（ThinkPad P16 Gen 3）；30Bクラスは余裕をもって収まる |
| 96～128GB統合型、Mシリーズ | gpt-oss-120b Q6_K | 〜93GB | 14～20トークン/秒。オープンウェイトモデルの中で最もクリーンなツール呼び出しJSON。 |
マーケティングでは触れられていないので、あえて言っておきますが、最も負荷の高いオープンウェイトモデルはワークステーションモデルではありません。GLM-5.2はパラメータ数が約744Bで、FP8では744GB程度のメモリを必要とします。これは8基のGPUを搭載したデータセンターノードに相当します。Kimi K2とDeepSeek V4も同じカテゴリーに属します。これらのモデルをデスクトップPCで実行するように指示するガイドは誤りです。
上記のスループット数値は、公開されている第三者機関のテスト結果およびベンダー資料に基づくものであり、StorageReviewのラボテスト結果ではありません。各プラットフォームがガイド作成プロセスを経ていくにつれて、これらの数値はStorageReview独自の数値に置き換えられる予定です。
クラウドファーストツール、そしてそれらがここにランクインしていない理由
ほとんどのAIユーザーは、人気があり使いやすいオンラインAIツールに精通しています。ローカルエージェントはローカルモデルではありません。これらはそれぞれユーザーのマシン上で動作しますが、推論呼び出しはすべてベンダーのクラウドに送信されます。
| ツール | ローカルモデルのサポート | お願い |
|---|---|---|
| カーソル | いいえ | 公式ドキュメントによると、すべてのリクエストはCursorサーバーを経由してルーティングされ、カスタムキーは主要なクラウドプロバイダーでのみ機能し、タブ補完は常にCursorモデルを使用する。2026年にSpaceXに買収された。 |
| デビン・デスクトップ（旧姓ウィンドサーフ） | いいえ | 2026年6月に名称変更。すべてのモデルはクラウド上でホストされています。 |
| Google 反重力 | いいえ | ドキュメントには、Ollama、LM Studio、またはカスタムエンドポイントを使用できないことが明記されています。 |
| ジェミニ CLI | いいえ | 地域的なサポートはコミュニティフォークでのみ存在する |
| コド | いいえ | 「オンプレミス」とは、クラウドモデルと呼ばれる自己ホスト型インフラストラクチャを指します。 |
| IDE 内の GitHub Copilot | 一部 | チャットはローカルモデルを使用できます。インライン補完は、独自のキーを使用する場合でもクラウドベースのままです。 |
| AI言語モデルを活用してコードのデバッグからデータの異常検出まで、 | いいえ | デスクトップアプリとモバイルアプリは、OpenAIのクラウドモデルのクライアントです。OpenAIのオープンウェイトgpt-ossモデルはローカルでも実行されますが、ChatGPTアプリではなく、上記のランタイムを介して実行されます。 |
| クロード | いいえ | ClaudeアプリとCoworkはAnthropicのクラウドモデル上で動作します。Claude CodeはOllamaのAnthropic互換APIを介してローカルモデルを参照できますが、これは機能するものの、サポート対象外の構成です。 |
| 一般的なエージェントアシスタント | いいえ | このクラスのツールはあなたのマシン上で動作しますが、推論にはクラウドモデルに依存します。 |
「CursorをOllamaに接続する」というガイドはよく見かけますが、Cursorの公式ドキュメントはそれらと矛盾しています。オフラインでの操作が必須条件であれば、この点が決定的な違いとなります。
画像や動画の生成についてはどうでしょうか？
ローカル画像生成は、ローカルAI分野における最大規模のコミュニティの一つです。ComfyUIだけでも、GitHubのスター数で上記のツールのほとんどを凌駕しており、ローカル動画生成は、最もVRAMを消費するコンシューマー向けワークロードとして台頭しています。この分野は、既存のカテゴリに4つ目のカテゴリを追加するのではなく、独自のランキングを作成するに値するものであり、実際に作成されます。それまでは、このページに記載されているハードウェアロジックがそのまま適用されます。画像および動画処理は、言語モデルよりもさらにメモリを多く消費するため、同じ階層構造が適用されます。
このページの使い方
3つのルールがあります。まず、ランキングは今のところGitHubのスター数に基づいています。理想的ではありませんが、中立的で検証可能であり、テストしていないものをテストしたふりをする必要もありません。クローズドソースのツールには、架空のスコアを与えるのではなく、その旨を明記します。独自のテストで明確なお気に入りが見つかり次第、測定結果を反映するように順位が変わり、その旨をお知らせします。次に、すべての項目に最小メモリ容量が記載されています。これは、モデルがロードされるかどうかを決定する数値だからです。最後に、「ガイド」欄は約束です。各プラットフォームについて、当社のハードウェアでの数値に基づいた実践的なセットアップ手順書を作成し、公開時にここにリンクを掲載します。
ローカルLLMツールに関するよくある質問
どのローカルLLMツールから始めるべきでしょうか？
ターミナル操作に慣れているならOllama、コントロール付きのウィンドウ操作を好むならLM Studio、そしてすぐに使えて追加インストールが不要なものが欲しいならJanがおすすめです。3つとも無料で、完全にオフラインで動作し、内部的にはllama.cppを使用しているため、モデルの動作は同じです。違いはインターフェースだけで、速度に差はありません。
NVIDIA ChatRTX、GPT4All、Continue.devはどうなったのですか？
それらは、驚くほど多くの同業他社とともに姿を消しており、これは古い推奨事項に従う前に知っておくべき最も重要なことです。NVIDIA ChatRTX は2026 年 1 月 21 日に非推奨となり、リポジトリはアーカイブされ、サポート フォーラムはロックされ、代替案は発表されていません。GPT4Allは最も厄介なケースです。12 か月コミットがなく、最後のリリースは 2025 年 2 月ですが、リポジトリはアーカイブされておらず、スターの数も大きいため、まだ稼働しているように見えます。限られた量子化フォーマットしかサポートしておらず、最新のモデル リリースのほとんどをロードできません。Continue.dev は、2 年間にわたりローカルモデルコーディングの標準推奨ツールでしたが、Cursor に買収され、2026 年 6 月にサービスを終了しました。Roo Code は2026 年 5 月にサービスを停止し、Voidは2026 年 6 月にアーカイブされ、Twinny は2025 年 11 月に、Reor は2026 年 3 月にサービスを終了しました。Khojは2026 年 4 月にホスト型サービスを終了しましたが、セルフホスト型は存続しています。ベンダー側では、Intel IPEX-LLMは 2026 年 1 月にアーカイブされ、既知のセキュリティ問題があり、移行パスが公開されていないため、フラグが立てられました。NVIDIA RTX AI Toolkit は2025 年 11 月に非推奨となりました。
ローカルLLMを実行するには、どれくらいのVRAMが必要ですか？
チャットの場合、システムRAMが8GBあれば3Bモデルが動作し、16GBあればCPU単体で7～8Bモデルが許容範囲内で動作します。実用的な速度を求めるなら、VRAMまたは統合メモリにモデルを配置する必要があります。16GBで7～14Bクラス、24GBでQ4の30Bクラス、32GB以上でエージェントコーディング作業がストレスなく行えるようになります。それ以上になると、帯域幅よりも容量が重要になるため、96～128GBの統合メモリを搭載したマシンでは、市販のグラフィックカードでは処理できないモデルが動作します。
ローカルのLLMツールは私のNPUを使用しますか？
通常はそうではありません。llama.cppにはNPUバックエンドがないため、OllamaとLM StudioはSnapdragonまたはRyzen AIマシン上でニューラルエンジンを0%のままにして、代わりにCPUまたはGPUで実行します。現在NPUにアクセスするには、ベンダーパスが必要です。Qualcomm GenieX、NPUランタイムを備えたAMD Lemonade、Intel OpenVINO、またはOSフレームワークを介したAppleのNeural Engineなどです。得られるものは、速度ではなく、バッテリー寿命と低消費電力の常時稼働であることを知っておく価値があります。また、NPUは現在70億モデル程度が上限であり、ディスクリートGPUは常にスループットでNPUを上回ります。
ローカルAIはWindowsとLinuxのどちらで実行すべきでしょうか？
このページに掲載されているデスクトップアプリに関しては、WindowsとmacOSの方がスムーズに動作します。LM Studio、Jan、AnythingLLM、Ollamaはすべてネイティブにインストールでき、GPUドライバは通常の場所から入手でき、ターミナルは不要です。Linuxは1つ下のレベルでその価値を発揮します。本番環境のサービスエンジンであるvLLMとSGLangはLinuxファーストであり、マルチGPUサービスでは事実上Linuxが前提となっています。また、AMDのRyzen AI NPUサポートなど、最新のアクセラレーションパスの一部は他のどの環境よりも先にLinuxに登場し、Linuxには最新のカーネルが必要です。その差は以前よりも縮まっています。AMDは2026年にROCmリリースをWindowsとLinuxで統合し、WSL2が残りのほとんどをカバーしています。そのため、Open WebUIのようなDockerベースのツールはWindowsマシンで問題なく動作します。実用的なルールとしては、デスクトップアプリのテーブルからインストールする場合は、現在使用しているOSのままにし、専用のサービスボックスを構築したり、すべてのアクセラレーションパスを追求したりする場合は、Linux上に構築してください。
ローカルモデルは、コーディングにおいてクラウドモデルを置き換えるのに十分な性能を備えているだろうか？
それは完全にタスク次第であり、その差は多くの報道で認められているよりも明確です。限定された作業、単一ファイルの生成、単体テスト、定型コード、コードの説明といった作業においては、高性能ワークステーション上の現在のオープンウェイトモデルは、最先端のクラウドモデルとほぼ同等の性能を発揮します。しかし、長期的なエージェント型作業、大規模リポジトリ全体にわたる複数ファイルのリファクタリングといった作業においては、明らかに劣勢となり、その失敗は、何も実行されないまま処理が停止したり、実際には行われていない作業が自信満々に報告されたりするなど、好ましくない形で現れます。ローカル環境への移行理由がプライバシー、エアギャップ要件、またはコストであれば、現時点では実現可能です。しかし、その理由が機能性であれば、まだ実現可能とは言えません。
モデルをローカルで実行する方が、クラウドサービスを利用するよりも安全でしょうか？
データ所在地の確保という点では、確かにそうです。それが通常、重要なポイントです。しかし、ソフトウェアのセキュリティに関しては、必ずしもそうとは限りません。2026年3月にCVSS 9.6と評価されたローカルAIアプリは、デスクトップアプリが安全でないデフォルト設定でパッケージ化されていたため、モデル自身のストリーム出力によってホスト上でコードを実行するように仕向けられる可能性があります。ローカルとは、データがその場所に留まることを意味します。ソフトウェアが強化されているという意味ではなく、このカテゴリには高速に変化するコードが多く含まれています。
AIエージェントサンドボックスとは何ですか？また、ローカルAIには必要ですか？
サンドボックスとは、通常はコンテナまたは軽量仮想マシンといった隔離された環境で、AIエージェントが生成したコマンドやコードを実行するため、ミスや悪意のある命令がホストシステムに影響を与えることはありません。エージェントは単に質問に答えるだけでなく、シェルコマンドを実行したり、ファイルを編集したり、ブラウジングしたりします。そして、これらのアクションはすべて、操作可能なモデルの出力によって駆動されます。モデルをローカルで実行しても、この仕組みは全く変わりません。サンドボックスの目的は、エージェントが行う操作を隔離することであり、モデルがどこにあるかを隔離することではありません。前述のコード実行の脆弱性は、まさにローカルファーストのアプリケーションでその点を浮き彫りにしました。このページに掲載されているツールの中には、サンドボックス機能が組み込まれているものもあります。また、ホストへのアクセス権を制限せずにエージェントを実行するツールは、重要なマシンで使用する前に、より慎重に検討する必要があります。エージェントの導入がビジネス環境に広がるにつれて、サンドボックスは脚注ではなく主要な機能となり、私たちもこれらのツールを評価する際にサンドボックス機能を考慮するようになるでしょう。
ローカルハードウェアは、数十個のサブエージェントを持つエージェントワークロードを実行できますか？
これは最先端技術であり、正直なところ、単一のワークステーションではすぐに容量が不足します。マルチエージェントワークロードは、それぞれ独自のコンテキストを持つサブエージェントを生成し、推論側では、アクティブなコンテキストごとにメモリ内に独自のKVキャッシュが存在するため、フットプリントはモデルサイズだけでなく、同時実行数に応じて増加します。メモリ容量を超えたキャッシュをどこに配置するかは、それ自体がエンジニアリング上の問題です。DellおよびSolidigmハードウェア上で構築された、 KVキャッシュのフラッシュへのオフロードに関する詳細な解説は、このテーマに関する当社がこれまでに公開した中で最高の解説です。30Bクラスのエージェントセッションを快適に処理できるマシンは、通常、レイテンシが悪化する前にバッチサーバーを介していくつかの並列セッションを処理できます。数十の同時サブエージェントはサーバーの領域であり、多くのライブコンテキストを保持できる十分なメモリと、継続的なバッチ処理用に構築されたvLLMのようなサービスエンジンが必要です。品質にも限界があります。ローカルモデルはツール数の増加に伴って信頼性が低下し、オーケストレーションはツールとハンドオフを増幅させます。我々の見解では、単一エージェントまたは少数エージェントによる処理は、今日では正当なワークステーション業務であり、大規模なサブエージェント群による処理はインフラストラクチャ業務である。この境界線、そしてその境界線を越えるために必要なハードウェアについては、今後さらに深く探求していく予定だ。
Amazon