ローカルLLMはAI Codingへ利用可能か？ ～データで見る2026年7月のAI Codingの動向まとめ～
著者: @kotauchisunsun
公開日: 2026/08/12
AI Coding Agentの2026年8月の動向
AI Coding.Infoというサイトを2025年7月から運営しています。
これは、Claude CodeやCodex CLI、あるいはGithub Copilot、Geminiなど、AI Coding Agentに関する利用動向をGithubのリポジトリの情報から定点観測するサイトです。 AI Coding Agentの利用の判定として、以下のような条件で毎日調査を行っています。
- Githubの公開リポジトリを9,000リポジトリを毎日調査
- プログラミング言語毎のGithub スター数のTOP 300
- プログラミング言語は30種類から調査
- AI Coding Agent 16種類を対象
- 各種AI Coding Agentの利用するルールファイルがGithubリポジトリにある場合のみ、AI Coding Agentを利用していると判断
先月の動向
https://ai-coding.info/reports/articles/20260703
AI Coding Agentの利用率は13.0%
AI Coding Agentのリポジトリ利用率は13.0% で、前回12.1%から0.9%増加です。
2026/8/1のAI Coding Agent利用率
https://ai-coding.info/?date=2026-08-01#adoption-rate
2026/7/1のAI Coding Agent利用率
https://ai-coding.info/?date=2026-07-01#adoption-rate
2026/7/1～2026/8/1までのAI Coding Agent利用率の推移
https://ai-coding.info/?date=2026-04-01&since=2026-07-01&until=2026-08-01#share-trend
AI Coding Agentのプロダクト別のシェア
プロダクト別のシェアは以下のようになっています。
| 順位 | 製品名 | シェア率 |
|---|---|---|
| 1位 | Codex CLI | 40.8% |
| 2位 | Claude Code | 32.0% |
| 3位 | Copilot Agent | 15.1% |
| 4位 | Gemini CLI(Antigravity) | 5.3% |
| 5位 | Cursor | 4.4% |
Codex CLIのシェア率が上昇していく中、Claude Codeはそのまま。Copilot AgentやGemini CLI(Antigravity)に関しても微減という推移をしています。少し注目していたのがCursorです。CursorがSpaceXに買収される。というニュースがありました。
https://www.nikkei.com/article/DGXZQOGN16BC70W6A610C2000000/
そのため、このCursorのシェア率にも変化があるのか。と考えていましたが、先月は4.7%、今月は4.4%なので、そこまで大きな変動はありません。後述のリポジトリ数を見てみると7/1にCursorの採用リポジトリは85件、8/1時点でも85件と変わっていません。そのため、この現象について言えば、全体としてAI Coding Agentを利用しているリポジトリの母数が上昇したが、Cursorの利用数は増えていない。そのため、全体としてシェア率が下がっている。という現象になっています。ただし、AI Coding.Infoの調査の特性上、Cursor固有の設定ファイル(.cursor)を持つリポジトリ数が変わらない。という話であり、Cursor自身はAGENTS.mdに対応しています。AI Coding.Info ではAGENTS.mdを持つリポジトリ数=Codex CLIの採用数としているため、Cursorを利用しているが、Codex CLIとしてカウントされている可能性はあり、見えない部分で利用数が増加している可能性はあります。
2026/8/1のAI Coding Agentシェア率
https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#agent-share
2026/7/1のAI Coding Agentシェア率
https://ai-coding.info/?date=2026-07-01&since=2026-07-01&until=2026-08-01#agent-share
プログラミング言語別のAI Coding Agent利用状況
一番AI Coding Agentが利用されているプログラミング言語は「TypeScript」、2番目は「Python」、3番目は「Rust」、4番目は「Go」、5番目は「C#」です。「TypeScript」のAI Codingの採用率が高いのは変わらず、一方で、2軍としての「Python」・「Rust」・「Go」、3軍として「C#」あたりの構図は、ここ最近の変わらないトレンドとなっています。
2026/8/1のAI Coding Agentのプログラミング言語別ランキング
https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#language-agent-rank
2026/7/1のAI Coding Agentのプログラミング言語別ランキング
https://ai-coding.info/?date=2026-07-01&since=2026-07-01&until=2026-08-01#language-agent-rank
AI Coding Agent利用リポジトリ数の1ヵ月の推移
2026/07/01時点では1,794件だったリポジトリ数が、2026/08/01時点では1,940件となり、AI Coding Agentを利用しているリポジトリは146件増加しています。
2026/7/1～2026/8/1までのAI Coding Agentを利用しているリポジトリ数の推移
https://ai-coding.info/?date=2026-08-01&since=2026-07-01&until=2026-08-01#time-based-bar-chart
ローカルLLMはAI Codingへ利用可能か？
6月にMythosおよびFable 5という次世代のLLMがClaudeから公開され、その性能に業界が衝撃を受けました。しかし、その後、中国のKimi社からKimi-K3というオープンウェイトのモデルが公開され、それがほぼFable級だ。ということが話題になりました。実際のベンチマークを見ても近い数値になっています。
https://artificialanalysis.ai/#intelligence-category-tabs
そう考えたとき、
ローカルLLMもAI Codingの選択肢に入ってくるのではないか？
と考えることもあると思います。そのあたりを調査しました。先ほどのグラフから主要なオープンウェイトのLLMモデルを列挙したのが以下の表となります。
| モデル名 | 社名 | 発表日 | パラメーター数 | アクティブパラメーター数 | コンテキスト長 | Intelligence Index |
|---|---|---|---|---|---|---|
| Kimi K3(max) | Kimi(中国) | 2026/07 | 2,800B | 104B | 1M | 60 |
| GLM-5.2(max) | Z AI(中国) | 2026/06 | 756B | 40B | 1M | 53 |
| DeepSeek V4 Flash 0731 | DeepSeek(中国) | 2026/07 | 284B | 13B | 1M | 52 |
| MiMo-V2.5-Pro | Xiaomi(中国) | 2026/04 | 1,023B | 42B | 1M | 43 |
| Muse Glimmer (high) | Meta(アメリカ) | 2026/08 | 30B | 256K | 35 | |
| Gemma 4 31B (Reasoning) | Google(アメリカ) | 2026/04 | 30.7B | 256K | 30 |
しかし、これらが実際に自分の持っているPCで動くのか。ということはよくわかりません。そこで、考えた判別方法が、
必要なVRAMメモリは、
パラメーター1[B]あたり2[GB]
です。自分の持っているPCのVRAMメモリ容量と、動かしたいモデルのパラメーター数から動くかどうかが概算できます。 したがって、
Kimi-K3を動かそうとおもうと、数式上は、5.6TB(5,600GB)のメモリが必要です。
この理由を解説します。 標準的に配布されているLLMのモデルはbf16やfp16という精度の小数を用いて重みが表現されています。これらは1つのパラメーターにつき2Byte必要です。 よく見る、30[B]などの表記はパラメーターの数で、BはBillionの略で10^9を表します。したがって、30[B]などのモデルは30×10^9個の重みデータがあることが分かります。 そして、1[GB]=1*10^9[Byte]となっています。そう考えると、先ほど標準的な重みは2Byteで格納されているということでしたので、1つの重みあたり、2Byte、それが1[B]個のパラメーターをメモリに乗せるのに2[GB]必要。という計算になります。これが先述した"パラメーター1[B]あたり2[GB]"の意味です。 しかし、これはあくまで概算で、これは重みをVRAMにロードするための最低必要要件であり、それ以外にメモリを使うこともあるので、あくまでそれ以上はないと厳しい。というVRAM容量になります。
ここで、量子化という概念が出てきます。Q4_0とかQ4_K_Mなどが見たことがあるのではないでしょうか。これは、重みをそのbit数に圧縮する技術です。そのためQ4_0の場合は、ざっくりと言うと、重みの容量が4bit(Q4_0の4の部分)になります。したがって、この場合は、1[B]あたり、0.5[GB]の容量となります。これらを早見表にすると以下のようになります
| 量子化方式 | 1[B]あたりの必要メモリ量[GB] |
|---|---|
| bf16,fp16(標準) | 2.0 |
| Q8_0 | 1.0 |
| Q4_0 | 0.5 |
Q4_K_Mといった表記を見ると思いますが、雑にはあれはQ4_0より精度を高める代わりに、少し使用するメモリ容量が多くなるモデルである。と認識しておくと良いです。 もう1つ別の見分け方があり、単純に重みファイル(safetensorやgguf)のファイル容量を見ます。これが、VRAMのメモリ容量を超えている場合、おおむね動かない。と思ってよいと思います。
ここからVRAMのメモリ量と量子化方式とパラメーター数を早見表にしました。
| VRAMメモリ容量[GB] | パラメータ数(bf16,fp16)[B] | パラメータ数(Q8_0)[B] | パラメータ数(Q4_0)[B] |
|---|---|---|---|
| 8 | 4 | 8 | 16 |
| 16 | 8 | 16 | 32 |
| 24 | 12 | 24 | 48 |
| 32 | 16 | 32 | 64 |
| 64 | 32 | 64 | 128 |
| 128 | 64 | 128 | 256 |
| 256 | 128 | 256 | 512 |
| 512 | 256 | 512 | 1024 |
| 1024 | 512 | 1024 | 2048 |
| 2048 | 1024 | 2048 | 4096 |
大体どれくらいで出来るか。ということを考えると仮にVRAM 8GBのモデルだと、RTX 5050となり、Amazon価格で5.5万円です。これはQ8_0で量子化された8[B]ぐらいのモデルなら動くかもしれない。というレベルです。
VRAMが16GBになってくるとRTX 5060 Tiあたりのモデルになり、10.8万円ぐらいです。このあたりで、Q4_0の量子化であればギリギリ30[B]級のLLMが動くか動かないか。というレベルです。
VRAMが32GBになってくるとRTX 5090のフラグシップモデルになり、79.5万円となります。こうなってくると、相当な覚悟がないと手が出ないレベルかな。と思います。これはQ8_0の量子化で30[B]級のモデルが動くか動かないか。ぐらいのレベルになります。
この辺が民生品レベルの最上位ラインです。では、業務用レベルになってくると、RTX PRO 6000 Blackwellが96GBのメモリ搭載となっています。お値段が235万円です。 ここでQ4_0の量子化レベルでも、192[B]のモデルしか動かないので、フラグシップモデルは動きません。
そして、サーバーに導入するGPUクラスタ用のデータがあったので、参考程度に載せます。NVIDIA B300の場合、メモリが288GB、お値段が863万円となっています。1つであれば、Q8_0量子化のDeepSeek V4 Flash 0731が動くかもしれない。Q4_0なら動くでしょう。2つあれば(1,700万円相当)、Q4_0量子化のMiMo-V2.5-Proが動くかもしれません。
https://www.nttpc.co.jp/cgi-bin/gpu/simulation/custom/index.cgi
したがって、メモリ量とパラメーター数を比較するとこれくらいの肌感です。もちろん、これ以上に議論の余地があり、これはメモリに乗るか乗らないか。だけであり、では、通常利用できるほどtok/s出るか。というのはまた別の課題があります。 この記事では極めて基礎的な話をしています。LLMにはDenseやMoEというアーキテクチャがあり、MoEでは実際に計算されるのはアクティブパラメーターだけであり、実行方法によっては全Expertを常時メモリに載せず、必要なExpertをストレージなどから読み出すことで物理メモリ量を削減する方法もあります。しかし、モデルの実行の仕方に特殊な部分があり、ストレージからメモリへのロードがボトルネックになり得る。みたいな話もありますが、ここでは、そういう細かい部分は抜きにして、モデルの重みをすべてメモリに載せる場合の単純な容量で考えています。
というわけで、現行のQ4_0やQ8_0で量子化されたフラグシップモデルを動かすのであれば、最低でも1,000万円級ぐらいのマシンが必要かな。というのが肌感です。 一方で、特殊なハードでより量子化を極めた場合なら動く場合があります。例えば、M4 Macの128GBメモリ搭載版(販売終了)とかDGX Spark(メモリ128GB)で、2bit量子化、3bit量子化を動かしている人はいます。
https://zenn.dev/tkhr_sait/articles/20260508_try-local-deepseek-v4
https://dev.classmethod.jp/articles/dgx-spark-deepseek-v4-flash-0731-llama-cpp/
逆に言えば個人ではこれくらいが限界かな。という肌感です。 個人的に注目しているのは1bit量子化で、有名なところではモデルではBonsai、技術としてはBitNetなどがあるのですが、1bit量子化をする際のノウハウがあまり公開されていないので、手を出してないです(おそらく膨大な時間がかかるだろうし、推論精度も下がる)。
なので個人的には、DeepSeekを1bit量子化したもの(約35.5GB)がでてくれれば、工夫次第では民生用GPUでローカルで動かせる世界が見えてきますが、現在は、それがないので、かなりきついな。というのが正直なところです。
従って、
フラグシップモデルをローカルLLMで動かすのは現実的ではない。
というのが大まかな感想です。本当に動かしたいなら、それなりに検証する必要があると思います。
感想
今回は、ローカルLLMへ焦点を当てて、話をしてみました。Kimi-K3が出てきたとき、かなり衝撃で、ローカルLLMでFable級が動く！というのは、かなり印象的でしたが、自分の持っている機材では動かすことすらままならないな。というのが正直な感想でした。過去にもローカルLLMの記事をあげて、書きましたが、その時もあまりうまくは動かなかったので、もうちょっと自分でも深堀したいなぁ。と思いました。