1. あらまし
クラウドAIは便利ですが、便利すぎて普通に使っているとすぐ利用制限に引っかかります。
あんまり追加課金もしたくない。
しかも、今後値上げされてもおかしくない気配が多々あります。
「何か...何か策はないのか。」
そこで気になったのが、小型のローカルAIです。
最近は各種有名どころのアプリにローカルAIが搭載されるようになってきました。
この流れからみるに、場面を限定すれば結構使えるレベルになっていると判断されていると推測できます。
”複雑な設計や判断はクラウドAIに任せる。
一方で、単純なコード作成や小さな修正はローカルAIに任せる。”
そんなふうに役割分担できれば、クラウドAIの利用回数を減らせるのではないかと思い立ったわけです。
ということで、小型ローカルAIでコーディング支援がどこまでできるのか試してみることにしました。
2. 既存ツールで試す
まずは、OpenCode、Continue など既存の有名なAIコーディングツールを試しました。
小型ローカルLLMのローカルサーバーたてて、簡単なコード作成や小さな修正を試してみました。
ただ、
- 無限ループ
- 回答失敗
などが相次ぎます。
ツールが悪いのか、プロンプトが悪いのか、モデルが弱いのかよく分からない。
正直、どこに原因があるのか切り分けが難しい...。
クラウドAIだとすんなりいくものが小型ローカルAIだと回答がスロットマシーンのようになる。
粘り強く試行錯誤と祈願祈祷を繰り返し、操作していましたが、
１ファイルの１行修正の指示で１５分以上のループが開始された時に、張り詰めていた最後の細い糸が、音も立てずにぷつりと断ち切れた。
理性の防壁を跡形もなく粉砕する無慈悲なる激昂をもって、
AIコーディングツールを自作する
という身の毛もよだつ凄惨な愚行への着手を決意してしまいます。
3. 開発
小型ローカルAI専用コーディング環境を作り、クラウドAIへの依存をさげ、それにより環境負荷を下げることで地球環境に貢献するという、清廉かつ崇高な理念のもとに開発が開始されます。
アプリ名は ParrotCode。
ITカルテルから飛び膝蹴りを食らいそうな名前ですが、
gpt、opus、gemini の大御所お三方より条件付きで素晴らしいとのお墨付きをいただいたのでおそらく問題ありません。
Aider、OpenCode、Continue など、参考になるOSSを割り出し、
クラウドAIエージェントコーディング環境も準備万端。もはや開発に死角などありません。
簡易AIコーディングアプリのMVP完成を2日の電撃戦で見積もります。
しかし、この見通しはすぐに打ち砕かれます。
雑に機能を真似ると想像以上に問題が噴出します。
- ローカルAIの出力が不安定
- JSONや決めた形式を崩す
- 指示していないファイルを触ろうとする
- 作業範囲を勝手に広げる
- プロンプトの制約を普通に無視する
- ビルドエラー修正で無限ループする
- 削除や移動の権限を与えるとDBとか消そうとする
- クラウドAIと同じ感覚で任せると普通に各ファイルぶっ壊す
どう粒度を小さくし、小型ローカルAI判断を要所に何度挟んでも許容できるレベルの動作となりません。肥大化する内部プロンプト...カオスなエージェントフロー...度重なるファイル破壊...事態は急速に悪化していきます。
4. 方針転換
この時点でエージェントループは小型ローカルAIでは無理筋と考えるようになります。
そもそも小型ローカルAIだと回答に至るトークンを出力できない可能性があり、そのようなモデルに何度判断を仰いでも仕方がありません。
よって
- LLMの判断を極力減らす。信頼できる決定論的に動ける周辺ツール側をメインで考える。
- ビルド・検証・修正ループを捨てる
- ファイル削除や移動などの経路を根本的に削除
- 自然文では指示が無視される可能性が高いので、プロンプト構造化
- タスクレベル判定、指定レベル以上は無理筋なのでやらせない
という方針にシフトしました。
一昔前のAIコーディングに近くなりますが、まともな速度でそこそこの回答が出力できないのではアプリとしてもはや成り立たないので、もう妥協するしかありません。小型ローカルAIが想像以上に出力が不安定で暴れるのでまずはそれを制御できるようにしないと開発が前に進まないのです。
とにかくAIをがっつり使ってというより、AIをいかに使わないようにするかが焦点となっていきます。
5. 再度試す
怒濤の如く機能を削り、それらしく動くものができあがってきました。
ひとまず一旦もういいや感があったので、小型ローカルAIモデルをいくつか使い、Lv1〜Lv5に分けたプロンプトで試してみました。
各レベル感は、だいたい以下のようなものです。
| Level | 主な用途 | 例 | 規模感の目安 |
|---|---|---|---|
| Lv1 | ほぼロジックを持たない定義 | DTO、Options、Result、Enum、定数 | 新規または既存1ファイル内 |
| Lv2 | 副作用のない小さなロジック | Validator、Mapper、Formatter、計算、判定 | 1〜2ファイル程度 |
| Lv3 | 外部I/Oを含む限定的な処理 | ファイル、DB、HTTP、設定読み込み、Repository、API Client | 少数ファイル。参照範囲が明確なもの |
| Lv4 | 複数の処理をつなぐ調整役 | Service、Policy、Manager、Coordinator、Orchestrator | 複数ファイル。責務分割や整合性確認が必要 |
| Lv5 | 影響範囲が大きい、または慎重に扱う変更 | 権限、安全制御、非同期処理、危険操作、ビルド設定、大きなリファクタリング | 広い既存コードベース。影響範囲の確認が必要 |
同じレベルでも、10ファイル規模の新規寄りプロジェクトと、100ファイル規模の既存プロジェクトでは難易度がまったく変わります。
あくまで参考程度として見てください。
試したモデル
最後の OpenAI API 以外は、すべて LM Studio でローカルサーバーを起動して試しています。
| モデル | 量子化 | Params | 実行環境 | サイズ |
|---|---|---|---|---|
| gemma-4-E4B | Q4_K_M | 7.5B | LM Studio | 6.33GB |
| qwen2.5-coder-14B | Q4_K_M | 14B | LM Studio | 8.99GB |
| qwen3-coder-30B | IQ1_S | 30B-A3B | LM Studio | 8.91GB |
| DeepSeek-Coder-V2-Lite-Instruct | IQ4_XS | 16B | LM Studio | 8.57GB |
| Codestral 22B v0.1 | Q2_K | 22B | LM Studio | 8.27GB |
| OpenAI API gpt-5.5 | - | - | クラウド | - |
判定の見方
| 判定 | 意味 |
|---|---|
| 成功 | ほぼ期待どおり。多少のミスはあるが、概ね使える |
| 微妙 | 方向性は合っているが、手動修正や再指示が必要 |
| 失敗 | 意図から外れる。修正量が多い |
クラウドAIと比べるのはさすがに酷なので判定は甘めです。
厳密なベンチマークではありません。
同じ条件で大量に測定したものではなく、個人開発の中で試した体感です。（感想文レベル）
なお、各レベルのテストでは、自然文で雑に依頼するのではなく、目的・制約・完了条件を明示した構造化プロンプトを使っています。
プロンプト全文を載せると長くなるので、ここでは割愛します。
結果
| モデル | Lv1〜2 | Lv3 | Lv4 | Lv5 | 所感 |
|---|---|---|---|---|---|
| gemma-4-E4B | 成功 | 微妙 | 失敗 | 失敗 | 小さな定義や判定なら使えるが、少し複雑になると厳しい |
| qwen2.5-coder-14B | 成功 | 成功 | 微妙 | 失敗 | 小規模の閉じた作業なら安定。Lv4,5は厳しい |
| qwen3-coder-30B | 成功 | 成功 | 微妙 | 失敗 | 小規模の閉じた作業なら安定。Lv4,5は厳しい。MoEで回答速度は速め |
| DeepSeek-Coder-V2-Lite-Instruct | 成功 | 成功 | 微妙 | 失敗 | 小規模の閉じた作業なら安定。Lv4,5は厳しい。MoEで回答速度は速め |
| Codestral 22B v0.1 | 成功 | 成功 | 微妙 | 失敗 | 小規模の閉じた作業なら安定。Lv4,5は厳しい |
| OpenAI API gpt-5.5 | - | - | 成功 | 成功 | 爆速・安定・高品質。クラウドAIの強さを再認識する |
Lv1〜Lv2は、各モデルとも概ね問題なく動きました。
DTO、Options、Result、Enum、小さなValidator、Formatterのような処理であれば、小型ローカルAIでもそれなりに使える印象です。
Lv3になると、少し差が出始めます。
ファイル操作、設定読み込み、Repository風クラスのような外部I/Oを含む処理では、参照ファイルや作業範囲をきちんと絞る必要があります。
ただし、やることが明確であれば、多くのモデルはまだ対応できている印象です。
Lv4になると、かなり怪しくなります。
複数の処理をつなぐServiceやCoordinatorのような作業では、既存クラスとの整合性、責務分割、命名、依存関係の扱いが甘くなりがちです。 幻覚もかなり多くなります。
Lv5はかなり厳しいです。
Lv5は、単にモデルのコーディング能力だけでなく、影響範囲を把握するための文脈量が大きくなります。コンテキストに収まっていても、依存関係、副作用、既存仕様、プロジェクト固有の制約を安定して扱えるとは限りません。
このレベルでクラウドAIを使うと、普段あまり意識していないクラウドモデルの強さを実感します。 小型ローカルAIを使った後だと、その出力の速度・高品質さに圧倒されます。
6. 感想
小型ローカルAIでもAIコーディングは可能ですが、
有名どころのツールを使っても、人間が目的と範囲を切り、小さな作業を任せるならという条件付きという印象です。
「AI-scaffold-first coding」あたりで使い道を考えるとしっくりくるかと思います。
従来型の開発が強いられる場合に条件付きでギリギリ使えるかなといった感想です。
ただ、正直にいうと、クラウドAIのAIエージェントコーディングが使えるなら絶対に使わないです。
設計判断をクラウドAIにして、実装を小型ローカルAIに任せるやり方も考えましたが、ちょっと厳しいと感じます。小型ローカルAIにコードを書かせても、結局レビューと修正をクラウドAIに任せることになってしまいます。この場合、ほとんどクラウドAIの利用回数を減らすことができないでしょう。（レビューと修正をゆっくり人間が実施するならこの限りではないですが...それが今後も許されるのだろうかという不安はあります。）
なお、70B級以上のモデルを大容量VRAM（A6000など）や高速なユニファイドメモリ（Mac）などに丸ごと載せて快適に動かせるなら、話は変わると思います。動画などで見る限り、かなり強力な出力ができているようです。自律型エージェントループも現実的だと思います。ハードウェア価格や電気代の問題が噴出するので、一般人が手軽に手を出せるものではありませんが...。
ローカルAI自体にはまだ期待しています。
問題は、巨大なモデルをVRAMやメモリに大きく展開して動かす今の前提です。
量子化やMoEの工夫はありますが、根本的にはまだ力技に見えます。
新ハードがでるのか、あるいはソフト側の工夫で乗り切るのだろうか？
そろそろ、この状況をひっくり返すような仕組みを出してほしいと願うばかりです。