2024年から2025年にかけて、コーディング支援AIは単なるコード補完ツールから、リポジトリ全体を理解して自律的にデバッグ・リファクタリングを行う「コーディング・エージェント」へと進化しました。一方で、機密性の高いソースコードを外部サーバーに送信するセキュリティリスクや、API利用コストの増大という課題も顕在化しています。

この記事では、OSSライセンス（Apache 2.0 / MIT）で商用利用が可能なコーディング特化LLMに絞り、ローカル環境で実用的に動かすための情報を包括的にまとめます。

なぜ「OSSライセンス」にこだわるのか

AIモデルの世界では「オープンソース」の定義が曖昧になりつつあります。多くのモデルが「オープンウェイト（重み公開）」として提供されていますが、必ずしも真のOSSライセンスではありません。

例えば以下のモデルは、独自ライセンスにより商用利用に制限があります。

また、「コードはOSSでも重みが非OSS」というケースも存在します。DeepSeek-Coder はリポジトリ自体は MIT 表記ですが、モデル重みの配布は別の Model License（利用制限付き）と明記されています。

本記事では、OSI（Open Source Initiative）の定義に沿った Apache 2.0 と MIT ライセンスのモデルを中心に評価します。この2つのライセンスの実務上の違いは以下の通りです。

2026年3月時点のモデル、Tier リスト

OSSライセンスかつローカル実行可能なコーディングLLMを、実力に基づいて3段階に分類しました。

Tier 1：フロンティアクラス（商用モデルに匹敵）

*Kimi K2.5 は MIT ライセンスですが、商用利用に月間1億ユーザー上限の制限があります

Tier 2：日常の開発に最適

Tier 3：特定用途に強い

主要モデルの詳細評価

Qwen2.5-Coder-32B：ローカル開発の大本命

2024年後半にリリースされた Qwen2.5 Coder シリーズは、ローカルLLMの勢力図を塗り替えました。Apache 2.0 ライセンスでありながら、GPT-4o に匹敵するコーディング能力を実現しています。

性能の秘密は学習データの質と量にあります。 5.5兆トークンの学習データを、コード70%、テキスト20%、数学10%の比率で混合することで、「コーディング特化でありながら一般的な対話能力を失わない」という実用上重要な特性を獲得しています。

アーキテクチャは Grouped Query Attention（GQA）と SwiGLU 活性化関数を採用し、推論時のメモリ効率を最適化。128Kトークンのコンテキストウィンドウをサポートし、大規模なプロジェクトファイルを一度に読み込んで解析できます。

サイズ展開は 0.5B / 1.5B / 3B / 7B / 14B / 32B の6段階で、あらゆるローカル環境に対応可能です。

Qwen3-Coder-Next：2026年の効率革命

2026年2月にリリースされた Qwen3-Coder-Next は、80B総パラメータでありながら推論時にアクティブなのはわずか3Bという革新的な MoE（Mixture of Experts）アーキテクチャを採用しています。

512個のエキスパートのうち10+1個のみがトークンごとに活性化するこの設計により、10〜20倍のアクティブパラメータを持つモデルに匹敵する性能を実現。約80万の検証可能なタスクで強化学習を行い、エージェント的なコーディング（長期計画、ツール使用、自律的な失敗回復）に特化しています。

ネイティブ262Kトークンのコンテキストウィンドウを持ち、Claude Code、Qwen Code CLI、Cline などのエージェントツールとの統合も進んでいます。

Qwen3.5：マルチモーダル×MoEの次世代フラッグシップ

2026年3月にリリースされた Qwen3.5 は、Qwen シリーズの最新フラッグシップモデルです。Gated DeltaNet と Gated Attention を組み合わせた新アーキテクチャに MoE を統合し、397B総パラメータのうち推論時にアクティブなのはわずか17Bという高効率設計を実現しています。

最大の特徴は、テキストとビジョンの Early Fusion 学習により、全サイズでマルチモーダル対応を実現している点です。201の言語・方言をサポートし、コーディングだけでなく視覚的な理解タスクでも高い性能を発揮します。

ネイティブ262Kトークンのコンテキストウィンドウに加え、RoPE スケーリングにより最大約100万トークンまで拡張可能です。サイズ展開は 397B-A17B / 122B-A10B / 35B-A3B / 27B / 9B / 4B / 2B / 0.8B の8段階で、小規模環境から大規模環境まで幅広く対応します。

gpt-oss：OpenAI初のOSSモデル

OpenAIが2025年8月にリリースした gpt-oss は、Apache 2.0（+ usage policy 併記）で提供される初のオープンウェイトモデルです。20Bと120Bの2サイズで展開されています。

注目すべきはツール利用を前提としたエージェント運用での強さです。

チェックポイントサイズは 20b が 12.8GiB、120b が 60.8GiB。MoE + MXFP4 量子化により、20b は 16GB メモリでも稼働可能、120b は単一 80GB GPU（H100等）で動作と明記されています。

ただし、Harmony チャット形式が前提となっており、正しい形式で運用しないと性能が出ない点には注意が必要です。

IBM Granite Code：エンタープライズ品質の選択

IBM が開発した Granite Code シリーズは、データの出所が明確で、法的なクリーンさが担保されている点が最大の特徴です。

学習データの準備フレームワーク「data-prep-kit」自体がオープンソース化されており、116のプログラミング言語をカバー。著作権侵害のリスクを最小限に抑えたい企業にとって、最も信頼できる選択肢の一つです。

また、レガシーシステム（例：COBOL）からモダンな言語への移行を支援する「アプリケーション・モダナイゼーション」用途にも最適化されています。

Microsoft Phi-4：小さな巨人

Microsoft の Phi-4（14B）は MIT ライセンスで提供される小規模言語モデル（SLM）で、「データの質は量に勝る」という哲学を体現しています。

GPT-4 等の強力なモデルを使って生成した「教科書のような」合成データで学習することで、従来のモデルが数百億パラメータを費やして獲得していた論理的直感を、14B のパラメータで実現しています。

14B モデルが 70B の Llama-3.3 を上回っている点は注目に値します。128Kトークンのコンテキストをサポートし、最新の Phi-4 Multimodal では画像・音声・テキストの統合処理も可能です。

ハードウェア要件と量子化ガイド

量子化の基礎

量子化とは、モデルの重みをより低いビット数に変換してサイズを縮小する技術です。**Q4_K_M（4ビット量子化）**がコミュニティの標準で、精度低下を最小限に抑えつつサイズを約1/4に削減できます。

原則として、小さなモデルを高精度で動かすより、大きなモデルを Q4 で動かす方が良い結果が得られます。

VRAM 容量の目安

モデル本体のサイズに加えて、KVキャッシュ（コンテキスト保持用メモリ）の確保が必要です。

VRAM の概算式：VRAM (GB) ≈ (パラメータ数B × ビット数) / 8 + KVキャッシュ + ~1GB

Apple Silicon の Unified Memory は大規模モデルの実行にコミュニティで人気があり、M3 Pro 36GB で 70B モデルが約15 tok/s で動作します。

実践的なセットアップガイド

推論エンジンの選択

Ollama でのクイックスタート

最も手軽にローカルLLMを始められるのが Ollama です。

# Qwen 2.5 Coder 32B を起動（24GB GPU推奨）
ollama pull qwen2.5-coder:32b
ollama run qwen2.5-coder:32b
 
# 軽量環境なら 7B
ollama pull qwen2.5-coder:7b
 
# Phi-4 を起動
ollama run phi4
 
# DeepSeek-R1 蒸留版（推論・デバッグ用）
ollama pull deepseek-r1:32b

GPU が搭載されていれば自動的にオフロードし、VRAM が不足する場合はシステム RAM を併用します。

IDE連携のおすすめ構成

Continue.dev（GitHub Stars 31K+、Apache 2.0）が最も推奨されるオープンソース Copilot 代替です。VS Code と JetBrains に対応し、Ollama / LM Studio に接続してチャットとタブ補完（FIM）の両方を利用できます。

推奨スタック（24GB VRAM / RTX 3090・4090）：

ollama pull qwen2.5-coder:32b    # FIMオートコンプリート（最高性能）
ollama pull deepseek-r1:32b      # チャットベースの推論・デバッグ

Continue.dev で VS Code に統合し、Aider でターミナルからの操作を補完する構成が鉄板です。

8GB VRAM 環境の場合：

ollama pull qwen2.5-coder:7b     # FIMオートコンプリート
ollama pull qwen3:8b             # チャット・デバッグ

Fill-in-the-Middle（FIM）の重要性

IDE でのコード補完で威力を発揮するのが FIM（Fill-in-the-Middle）です。カーソルの前後の文脈を同時に読み取り、その間に最も適切なコードを挿入する技術で、Qwen2.5-Coder は学習段階から FIM 形式のデータを大量に含んでいます。

内部的には、入力を <PRE> {prefix} <SUF> {suffix} <MID> という特殊トークン形式に変換し、<MID> 以降を生成させることで、従来の「続きを書く」だけのモデルよりも遥かに正確な補完を実現しています。

実運用での注意点

ベンチマークと実務のギャップ

ローカルモデルは HumanEval や MBPP では GPT-4o に匹敵しますが、実際の GitHub Issue 解決能力を測る SWE-bench Verified では、Claude Opus 4.5（80.9%）や GPT-5.2（80.0%）との差がまだ残っています。

コミュニティの実践的なコンセンサスは：

日常作業の80%はローカルモデルで処理し、フロンティア推論が必要な20%はクラウドに切り替える — r/LocalLLaMA コミュニティでの実践的コンセンサス

よくある課題として、存在しない API のハルシネーション、コンテキストウィンドウの限界での品質劣化、マイナーな言語やフレームワークでのパフォーマンス低下が挙げられます。

セキュリティとデータプライバシー

「ローカル実行 = 安全」ではありません。以下のリスクは引き続き管理が必要です。

• プロンプト/ログへの機密混入：入出力ログにソースコードが残る
• 依存関係のサプライチェーン：モデル重みの改ざん対策（ハッシュ検証、社内保管）
• 生成コードの品質保証：テスト・静的解析・レビューの自動化が必須
• モデルサーバーのアクセス権管理：社内ネットワークでのアクセス制御

IBM Granite のモデルカードでも、生成コードへの過度な依存や安全性未整合の注意が明記されています。LLM の出力をそのままマージするのではなく、lint / 型検査 / テストを機械実行し、差分を最小化してマージするワークフローが事故率を下げます。

ライセンスの実務運用

gpt-oss のように Apache 2.0 に追加で usage policy が併記されるケースもあるため、導入前に社内法務との確認を推奨します。

今後の展望

1. 推論時計算量（Reasoning-at-Inference）の一般化

DeepSeek-R1 や OpenAI の o シリーズに見られる「回答前に思考プロセスを生成する」手法がコーディングにも広がり、アルゴリズムの論理的ミスが大幅に減少すると予想されます。

2. 小規模モデルのアンサンブル（マルチエージェント）

全ての作業を一つの巨大 LLM に任せるのではなく、以下のような役割分担が主流になります。

• Phi-4 Mini（超高速）→ コード補完
• Qwen2.5-Coder-32B → リファクタリング
• IBM Granite → ドキュメント生成・法的チェック

3. MoE アーキテクチャの支配

Tier 1 のモデルは全て MoE を採用しており、アクティブパラメータあたりの性能最大化が今後の方向性です。Qwen3-Coder-Next の「3B アクティブで SWE-bench 70%超」や、Qwen3.5 の「17B アクティブで SWE-bench 76%超」は、そのパラダイムシフトを象徴しています。

まとめ：用途別おすすめモデル

OSSライセンスのコーディングLLMは、もはや商用モデルの「安価な代用品」ではありません。適切なモデルとハードウェアの組み合わせにより、プライバシーと生産性を両立した開発環境を自分の手で構築できる時代が到来しています。

以上、OSSライセンスで使えるコーディング特化ローカルLLM完全ガイド（2026年版）、現場からお送りしました。