コーディングエージェント前提での開発教育はどのようになるか

コーディングエージェントがコードを書いてくれるので、プログラミング言語とかコーディングの勉強の必要性は下がっているわけですが、それでもちゃんと開発を行うための能力というのは必要です。
で、それを勉強しようとしたとき、どう変わるか。

まず、コーディングエージェントを使って入門をしようとすることを考えます。 ここで、「ブロック崩しつくって」のような単純なものだと一発で作ってくれて人間の能力が不要なので、入門題材に使えません。
Hello world的な、開発環境の動作確認であれば問題ないけど、開発能力を鍛えようとすると使えません。

なんなりか躓きポイントがあるほうがいいのだけど、最近のAIさんを躓かせようとすると、結構複雑な処理を実装させる必要があります。
そうすると、その題材の複雑さに入門者がついてこれなくなります。

あと、作るものを問題文として整理してしまうと、ソフトウェア開発の一番難しいところが解決された状態で提示されています。作るものを明確に定義するというのが一番難しいところなのです。これは設計手法が流行ったとき、それぞれの設計手法の評価をどうするかというときに問題になっていました。

単純で小さいものを作らせるのであれば、エージェントという予測困難な層をはさむよりも、ふつうにコードを書かせて実習させるほうがいい気がします。そのあと、エージェントに入るという。

ということで、あまり文法の細かいところまでは突っ込まず、アルゴリズムやテストなどソフトウェア開発とは何かということを伝えるようなコードベースの題材がいいんじゃないかと思います。

と書いて、そういえばそういういい本がありますね。
「プロになるJava」っていうんですけど。

Gemma 4-12B、日常使いによさそう

なんか出てた。メモリがそんなにないしコード書かないし、というところにちょうどよさそうなので、UnslothさんのところのQ4_K_XLで試してみたんだけど、要約や翻訳、ロールプレイなど、コーディング以外で使うには結構よさそう。

Qwen3.5はよかったけど9Bは少したりず、Qwen3.6やGemma 4が4月に出たときは性能十分ってなったけど26B以上は手軽に動かせず、というところに12Bというのはとてもいいサイズ。

最初は壊れていたけど「寝て起きたらなんか直ってめちゃ使えるってなるのに期待」と書いて寝て起きたら直ってた。なので、内容はあわせて16時に更新しています。

google/gemma-4-12B · Hugging Face
Introducing Gemma 4 12B

メモリ使用量はLM Studioの予測基準でこんな感じ

コンテキスト長 4000 14000 60000 131K
メモリ 7.81GB 9.25 15.89GB 26.15GB

8000トークンの設定でOS利用含め10GBくらい使ってます。

まあ、8GBだとQ4は厳しくて、12GBくらいでQ4の1.5万トークンくらいまででチャットや要約などに使うのがいいですね。

カットオフ

Javaの最新バージョンを聞くと2025年1月カットオフ、最新バージョンはJava23と返ってきました。Java 24は2025年3月でまだ出てないので正しい。Gemma 4 31Bなどと同じっぽい。

山口県知識

「山口県の特徴は?」と聞いてみます。
長門峡は「ちょうもんきょう」だけど、それ以外は大きな間違いもなく、よさそう。

llama.cppで直接動かしても大丈夫。「白鷺城」は間違いだし石見銀山は島根だけど、12Bだとこのくらいの間違いは仕方ない。

リリース直後は「「山口県」という名称の県は 日本には存在しません。」と答えてたけど、修正されてます。

ギャルぽく

ギャルっぽくも、Gemmaシリーズらしく表現力高くやってくれました。
内容の誤りも見当たらない。

翻訳

リリースブログの冒頭を翻訳してもらいます。いい感じ。

ちなみに、サムネイルの英訳もGemma 4 12Bに相談して決めたのだけど、普通に使えた。

要約

「注文の多い料理店」の要約。 客を料理にして食べること、死んだ犬が救いにきたことなど、的確にまとめてます。

音声認識

音声対応をしていて、話声は認識してくれる。

ちなみにここで使った音声。 Qwen3-TTSに自分の声でしゃべらせる - きしだのHatena

ギターを弾いてる音声を渡したけど、これは認識してなさそう。

ただ、LM Studioは音声入力に対応していないので、llama.cppを直接つかっています。

ブロック崩し

ブロック崩し作ってもらいます。なんかよさそうなソースを出してる。

でもコンパイルエラー。一発では動かなかった。

main.java:127: エラー: シンボルを見つけられません
            g2d.fill3D(b.x, b.y, b.width, b.height, true); // 簡易的な長方形描画
               ^
  シンボル:   メソッド fill3D(int,int,int,int,boolean)
  場所: タイプGraphics2Dの変数 g2d
エラー1個

エラーを渡したら修正して動きました。

エージェントでTODO管理アプリ

OpenCodeを試してみます。

Spring Bootでtodo管理アプリを作って。 Spring MVCでテンプレートにthymeleafを使って。
DBはH2でアクセスにはSpring JDBCを。
Spring Bootは3.5.9、Javaのバージョンは25

動かなかった・・・

LM Studio経由でもllama.cppでもダメだった・・・
チャットテンプレートの問題な気もするから、あとで修正されるかも。

結論

コーディング以外の、日常使いにはよさそう。

AIが発達しても人間にわからないコードを書くようにはならない

「AIが人間にわからないコードを書くようになる」という話、割とよくみかけるので書いておきますね。
これ、「AI専用の言語があらわれる」「AIが直接バイナリを吐く」の亜流です。

AI専用の言語があらわれない話はここ。
AI専用のプログラミング言語は現れない - きしだのHatena

AIがバイナリを吐くようにならない話はここ。
AIがバイナリを直接吐くようにはならない - きしだのHatena

というか、AIが読み書きするコードも読みやすいほうがいいという話をすでに書いていた。
AIが読み書きするコードも読みやすいほうがいい(トランスフォーマの特性の考慮やリーダブルコードについて追記) - きしだのHatena

まあ、プログラムというのは、処理の流れが最小限でデータがスムーズに流れるほうがいいわけです。
その上で、共通である部分は共通で、まとめて扱ったほうがいい部分はまとめて書かれるほうが扱いやすいわけですね。
また、機械的検証可能であることも重要です。

ただし、最小限の処理フローやデータフローを見出して記述することには高い能力が必要になります。 そしてそれを無駄な重複を省き、まとめるべき部分をまとめるにも高い能力が必要です。
検証可能なように適切に型を使うということにも高い能力が必要ですね。

高度なコーディングAIはそういった書き方を容易に見つけるようになるはず。というか、そういった書き方を容易に見つけるAIを、高度なコーディングAIと呼ぶことになります。

基礎的な部分でフレームワークやライブラリを使わず実装したりもするので、フレームワークのためのコードやライブラリのためのコードも減って見通しもよくなりそうです。

で、そうすると無駄がなく、あるべきものが当たり前の場所にあり、自然でそれ以外考えられないようなコードになり、非常に読みやすくなるわけです。

プログラミングに不慣れだと、全体を見通せず目の前の処理をアドホックに書くので、ぐちゃぐちゃと処理が流れてデータがいろいろ変換されて無駄のあるコードになりがち。そして読みにくい。

あと、いくらAIが賢くコードを書くと言っても、バグは作りこんでしまうので、既存コードを確認して修正しながら完成に近づけていく、それを自動で休まず何時間もやるから大きく複雑なコードがかけるわけで、AIにとっても把握しやすく検索しやすいコード構成になっていることは重要ですね。

将棋は、完全情報ゲームの中でいかに相手にばれないよう勝ち手を打つかが大事なので、人間にわかりにくい必要があります。でも、プログラムはそうではない。

まあ、そういうわけで、高度に発達したAIは、あるべき場所にあるべきコードが書かれて、それ以外には書きようがない完成度の高いコードを書くようになって、非常に読みやすいコードを書くようになると思います。

ローカルでコーディングエージェントするために使えるLLM

ローカルでコーディングエージェントするために使えるLLMもまとめておきます。

モデルと傾向

いまコーディングエージェントで使えるかなというモデルはこのくらい。

モデル パラメータ アクティブ アテンション 埋め込み
Qwen3.6 27B Dense 線形 64 5120
Qwen3.6 35B A3B 線形 40 2048
Gemma 4 26B A4B スライド 30 2816
Gemma 4 31B Dense スライド 60 5376
Qwen3.5 122B A10B 線形 48 3072
Step 3.7 Flash 198B A11B
MiniMax M2.7 230B A10B フル 62 3072
MiniMax M3 428 A23B スパース 60 6144
DeepSeek V4 Flash 284B A13B スパース 43 4096
MiMo-V2.5 310B A15B スライド 61 4096
GLM-5.2 744B 40B スパース 79 6144
Kimi K2.7 1T 32B スパース 61 7168

※ 2026/6/19 Kimi K2.7、GLM-5.2、MiniMax M3を追加

とはいえ、Qwen3.6-35Bはちょっとコードが書くのが下手、Gemma 4はコーディングエージェントとしての動きが弱い、GLM-5.1は重すぎ、というのはあります。候補にできるかな、くらい。

リリースされていてもGGUFやMLXが対応していなくてローカルで使いにくいものもありますが、ここに上げたものは実際に試せたモデルです。

現実的には、300Bより大きいモデルは生成は速くても、コーディングエージェントで数万トークンになったプロンプト読み込みに5分かかったりするので、そのくらいが限界だと思います。

また、30Bくらいだと知識量が足りないので、細かいAPI呼び出しを間違えたりしやすくなるので、完全にこれだけというのは難しいです。

新しいコードを書くときは30Bくらいのモデルで試行錯誤をやりやすく、バグ修正は200Bのモデルで、さらに難しい検証などはGPTやClaudeを使う、のような階層的な使い分けが大切かと思います。
ローカルLLMコーディングエージェントは重くて賢いモデルと軽くて新しいモデルを組み合わせるようになるんでは - きしだのHatena

LLMの構造

LLMは基本的にアテンション+FFN(ニューラルネット)でできてます。 アテンションはパラメータ数は少ないけど計算が重い、FFNはパラメータ数が多いけど計算は単純です。 アテンションは文章の読み方、FFNには考え方と知識を扱います。

アテンションの種類

アテンションはトークン数nに対してO(n2)なので、いろいろ削減の工夫がされてます。 フルはそのままO(n2)でやる スパースとスライドはnの部分を減らす。スパースは間引く。スライドは一部領域をみる なので、スパースは全体をみれるけどちょっとあいまいになる。スライドははっきり認識するけど局所的になる、みたいなイメージ。 線型は計算を工夫してO(n)にする。ただ、理論的には等価だけど実際には離れたところほど誤差が出てしまう。なので、たとえば長いコードを少し修正して出し直させると、1行ぬけてたり、ちょっと変わってたりする。

FFNの種類

FFNではDenseとMoEがあります。 Denseはふつうに全部のパラメータを使うモデル。
MoEは小さいFFNがたくさんExpertとして用意されていて、実行時にはいくつか選んで使うというものです。MoEで実際に使われるパラメータ数がアクティブパラメータです。

アクティブパラメータ数は推論の速さや考えの深さにつながります。
Qwen3.6-35B-A3BとGemma 4 26B-A4Bがわかりやすいですが、Qwen3.6のほうが総パラメータ数は多いけどアクティブパラメータが少ないのでGemma 4より速く、Gemma 4は総パラメータ数は少ないけどアクティブパラメータ数が多いので間違いが少なくコード書けます。

Denseであれば、総パラメータ数=アクティブパラメータ数なので、思考が深く、Qwen3.6-27BがQwen3.5-122B-A10Bと勝負できるくらいのコーディング力になったりします。さすがにQwen3.5-122B-A10Bのほうが総合力で勝つのだけど。

量子化

LLMは、学習時には精度が必要だけど、推論時にはそれほど精度が必要ありません。
なので、16bit浮動小数のパラメータを、8bitや4bitに精度を落としてもサイズが減った割には性能が落ちません。

また、アテンション部分では精度が必要ですが、FFNではあまり精度が必要ないので、アテンション部分だけ精度を高めて、FFNは精度を落とすというようにうまく量子化すれば、性能を落とさずにサイズを減らすことができます。

Q4_K_Mなど、4bit量子化くらいまではほとんど性能が落ちないので、ローカルでLLMを使う場合にはそのくらいの量子化モデルが使われます。

うまくやれば、Q3くらいまで性能があまり落ちません。

LLMでのボトルネックはメモリ帯域です。なので、性能とのバランスを考えると、Q6やQ8を使う理由はあまりありません。

ただし、コーディングエージェントには性能が足りないのでここで上げてませんが、10Bより小さくなると量子化の影響が出やすくなってくるのと、そもそもパラメータ数が少ないのであまりメモリ削減する必要もなくなってくるので、Q6やQ8も候補になります。

実際にどのように量子化されているかは、GGUFの中身を見るとわかります。
ggufの歩き方 - LLMの構造をみてみる - - きしだのHatena

読み込み

SoCではなくdGPUを使う場合、CPUとGPUの振り分けも大事になります。
Denseモデルの場合は層をどれだけGPUに乗せるか単純に考えればいいです。
MoEの場合は、アテンションはなるべくGPUにのせて、FFNをCPUに乗せるほうがいいです。
そのあたりの設定はこちらに。
Qwen3.6-35B-A3Bの動作環境と設定、出力速度まとめ - きしだのHatena

埋め込み

エンベディングの幅を書いてますが、これはLLMのモデル内で情報を扱う単位です。
基本的にはアクティブパラメータに比例する設定になっています。
レイヤー間で伝送されるデータは、トークン数 x エンベディング幅なので、マルチGPUでの性能劣化を考えるときにはちょっと気にしたほうがいい数字です。

2023年からの3年でおうちで動くLLMはどう変わったか

ちょっと、おうちで動くLLMを振り返ってみます。
年間を通してではなく、毎年の3-4月くらい、16GB VRAMのGPUで動くくらいのモデルがどんな状況だったかをみてまとめるとこんな変遷
動いてえらい(2023)->返答がまとも(2024)->返答が使える(2025)->こだわらなければ使える(2026)

2023「動いてえらい」

最初に動かしたのはChatRWKVというモデルですね。TransformerではなくRNNを使うモデル。
おうちの8GB VRAM GPUでChatRWKVと会話する - きしだのHatena

こんな感じ。「寿司は好き?」って聞いたら英語でそれっぽい返事してくれてる。

いろいろ出てるのはデフォルトの文章で、このように会話形式の文に続けることで同様に会話してくれるんではないか、という作戦。チャット向けにファインチューンされてるわけではありません。

基本的に、海外のモデルは日本語を理解するけど出力しませんでした。

で、これはRinna社が開発したモデルで、ちゃんと日本語で会話ができています。

GPT-NEOXというアーキテクチャで、名前からもわかるように言語モデルの種類としてのGPT、つまりTransformerです。
そして、対話ができるようファインチューンもされています。

このころは「対話ができて偉い!」「日本語でやりとりできて偉い!」「聞いたことを答えてくれて偉い!」という感じでしたね。

あと、モデル開発もちょっと牧歌的でした。しかし牧歌的であるがゆえにマネタイズにはつながらかったのだろうな。

2024「返答がまとも」

GoogleからGemmaが出てなんかまともなことを話してくれるようになりました。

単文レベルの答えしか期待できなかったのが、まともな文章を、それも日本語を特別に学習してないモデルが返してくれるようになりました。

ただ、「動くぞ!」という感激は過ぎて、かといって「使えるぞ」というにはまだまだという状況で、振り返るとそこまで盛り上がってなかった。

2025「返答が使える」

Gemma 3やQwen3が出ました。

特にQwen3は、使える出力をするようになりました。
Qwen3はローカルLLMの世界を変えたかも - きしだのHatena

Qwen3 4Bに「CQRSと関数型プログラミングの関係」を聞いてみると、まず「CQRSとは、関数型プログラミングとは」という言葉の解説から始まり、ちゃんとした説明が出力されます。

また、14Bは「JavaのSwingでブロック崩しを作って」で一発目でちゃんと動くブロック崩しを作りました。

Q4_K_Mのような量子化も普及して小さいサイズで十分な精度を出せるようにもなり、おうちでLLMを動かすということもやりやすくなりました。 2023年は8GB VRAMのGPUつかってたのだけど、3BのモデルがFP16で動くのでギリギリとかが、2025年なら14BがちょっとCPU使いつつ動くという感じに。16GBあれば余裕です。

2026「実際に使える」

Qwen3.6とGemma 4が出て、実際に使えるようになりました。

例えばこれはDeepSeek V4のテクニカルレポートをQwen3.6-35B-A3Bに渡して内容を説明してもらっています。

そして追加の質問をしても答えてくれています。
英語PDFの内容を確認したいという用途であれば十分に使えます。

新しいアイデアを形にしたい、という場合にはちょっと足りないですが、既存情報を解説してもらう、要約してもらう、翻訳してもらう、といった、新しい考えや知識を付け足す必要がない用途であれば実用できます。

ブロック崩しもこんな感じに。
LLMの推論を速くする投機的デコードMTPは想定ユースケースに近いかどうかが重要? - きしだのHatena

RPGも簡単なプロンプトで複数のモンスターの描画まで行って作っていました。
Qwen3.6-27BにRPGを作ってもらったらすごすぎた - きしだのHatena

1800行のHTMLになったのですが、これをJavaに移植もちゃんとやってます。

2025年のGemma 3やQwen3では、使える出力をするものの、じゃあどこで使う?というと困る程度でしたが、Gemma 4やQwen3.6では1~2往復のチャットでおさまりそうなやりとりや、単機能のアプリケーションであれば十分に使えるというところまで来ています。

ローカルLLMを動かすハードウェア

LLMを動かすハードウェア、軽くまとめておきます。

SoC

LLMを動かそうとしたら、まず候補にしたいのはCPU+NPU+GPUのSoCが載ったマシン。
GPUカードのようなパフォーマンスは出ないけど、現実的な値段で大きいモデルが動かせます。
※ 追記(2026/5/14) 現状ではMacだけ普通で他は特別なマシンという感じですが、インテルも対応した今後は「パソコンを買ったらLLMが動かせる。せっかくLLM動かすならちょっとお金を足して30Bが動く程度にメモリ積もう」となるんじゃないかと思います。

Ryzen AI Max+ 395搭載の128GBのEVO-X2が48万円、と思ったら品切れ・・・
※追記 本家に「在庫たっぷり」と売ってあった。
※さらに追記
去年の11月くらいには30万弱で買えたんですよ・・・夏くらいには192GBとか256GBとか買えるようになるかなと思ってたんですよ・・・
GMKtec EVO-X2 AMD Ryzen™ AI Max+ 395 ミニPC – GMKtec JP

GB10が載ってDGX Spark互換のGX10が58万円。

Mac Studioの96GBが60万円。(128GB以上は注文できない状況)

インテルもようやくCore UltraでLLMが動くようになりました。32GBで22万円。

CPU+NPU+GPUなSoCとして他にはQualcommのSnapdragon Xシリーズがあるけど、「LLMを動かす」だとまだ物足りない様子。
Qualcommとしては、やっとPC用CPUが勝負になってきたと思ったらGPU勝負が始まってた、という感じになってますね。

GPU(32GB)

コーディングエージェントをターゲットと考えると16GBは足りない、コンテキスト長を考えると24GBも心もとない、ということで32GBで考えます。
RTX 5060 Ti 16GBを2枚挿すのが恐らく現状で一番安く20万弱で32GBを得ることができます。

インテルのIntel Arc Pro B70が32GBで22万5000円。
ファンレス版も。32GB VRAM搭載の「Intel Arc Pro B70」ビデオカード - PC Watch

しかしAmazonだと32万円ですね。

AMDのRadeon AI Pro R9700が25万円。

RTX 5090だと60万円から。

RTX Pro 4500も60万円

電源などあわせてそろえることを考えるとLLMの推論だけが目的ならSoC系のマシンを買うほうがよさそう。
大きいモデルを動かそうと思うと、メインメモリも増やして、いい感じの設定で動かす必要もあります。

動画生成や学習までさせるならRTX系は有力だけどDGX Sparkでもいい。