ggml-org/llama.vscode とは何ですか？

ggml-org/llama.vscode は llama.cpp をバックエンドに、VS Code 上でローカル LLM による補完、チャット、エージェント操作を行う拡張機能である。MIT ライセンスの TypeScript 実装で、v0.0.65 が 2026-09-05 に公開されている。本稿では README とリポジトリ情報から確認できる範囲で、仕組み、導入手順、制約、代替手段を整理する。

ggml-org/llama.vscode は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

ggml-org/llama.vscode は今もメンテナンスされていますか？

されています。最後のコミットは 10 日前です。

ggml-org/llama.vscode はどのプログラミング言語で書かれていますか？

主に TypeScript です（GitHub の言語統計による）。

llama.vscode レビュー: ローカル FIM 補完と Llama Agent の導入手順と制約

ひと目でわかる

これは何？: ggml-org/llama.vscode は llama.cpp をバックエンドに、VS Code 上でローカル LLM による補完、チャット、エージェント操作を行う拡張機能である。MIT ライセンスの TypeScript 実装で、v0.0.65 が 2026-09-05 に公開されている。本稿では README とリポジトリ情報から確認できる範囲で、仕組み、導入手順、制約、代替手段を整理する。
誰に向いている？: ローカル推論でコード補完を完結させたい、あるいは MCP 経由で手元のツールをエージェントに使わせたい開発者に向く。逆に、クラウドモデルの品質をそのまま期待する用途や、llama.cpp を別途運用したくない環境には向かない。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 10 日前です。
何の言語で書かれている？: 主に TypeScript です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · ggml-org/llama.vscode

llama.vscode が埋める穴: 補完リクエストを外部に送らない選択肢

VS Code の補完拡張は、多くの場合クラウドの推論 API を呼ぶ。llama.vscode はその経路を手元の llama.cpp サーバーに置き換える。README の冒頭は「Local LLM-assisted text completion, chat with AI and agentic coding extension for VS Code」と述べており、補完、チャット、エージェントの 3 用途を 1 つの拡張にまとめている。対象読者は、ソースコードを外部サービスに送りたくない開発者、あるいはネットワーク遅延や従量課金を避けたい開発者である。実装の出発点は llama.vim で、README の Implementation details には「The initial implementation was done by Ivaylo Gardev @igardev using the llama.vim plugin as a reference」と記されている。Vim 版の設計を VS Code の拡張 API に移植した系統であり、ゼロから設計された補完エンジンではない。

補完の操作体系とコンテキストの組み立て方

補完は入力中に自動で提示される。README が挙げる操作は、Tab で候補全体を確定、Shift + Tab で候補の 1 行目だけを確定、Ctrl/Cmd + Right Arrow で次の 1 語だけを確定、Ctrl + L で手動トグル、という 4 種類である。部分確定を段階的に用意している点は、長い候補を丸ごと受け入れる心理的な抵抗を減らす設計だと言える。コンテキストについては、カーソル周辺の範囲を設定で制御できるほか、開いているファイルや編集済みファイル、ヤンクしたテキストからチャンクを集める ring context という仕組みがある。README は「Supports very large contexts even on low-end hardware via smart context reuse」と説明し、参照先として llama.cpp の PR 9787 を挙げている。つまりコンテキスト長そのものを巨大にするのではなく、再利用によって実効的な文脈量を確保する方向の最適化である。生成にかける最大時間も設定項目として公開されており、遅いハードウェアで候補が延々と出続ける事態を避けられる。

導入は 2 段階: 拡張機能と llama.cpp サーバー

拡張機能自体は VS Code Marketplace の ggml-org.llama-vscode から入れる。Open VSX にも同じ拡張が公開されていると README は記している。問題はバックエンドで、llama.vscode は単体では推論できない。llama.cpp のサーバーが必要になる。README によれば現在は自動化されており、ステータスバーの llama-vscode をクリックするか Ctrl+Shift+M でメニューを開き、「Install/Upgrade llama.cpp」を選ぶと macOS と Windows では自動導入される。macOS は Homebrew が、Windows は winget が前提条件として必要である。Linux は自動化の対象外で、GitHub のリリースから最新バイナリを取得し、bin フォルダを PATH に追加する必要がある。手動で入れる場合のコマンドは README に明記されている。macOS は brew install llama.cpp、Windows は winget install llama.cpp。その後、メニューの「Select/start env...」で用途別の env を選ぶ流れになる。

VRAM 別の llama serve プリセットと CPU のみの構成

README は VRAM 量に応じた 4 段階の推奨設定を提示している。64GB 超なら llama serve --fim-qwen-30b-default、16GB 超なら --fim-qwen-7b-default、16GB 未満なら --fim-qwen-3b-default、8GB 未満なら --fim-qwen-1.5b-default である。これらはモデル名を直接指定するのではなく、llama.cpp 側のプリセットを呼ぶ形式になっている。CPU のみの環境向けには別の設定が折りたたみで用意されており、Qwen2.5-Coder-1.5B-Q8_0-GGUF または 0.5B を使い、--port 8012、-ub 512 または 1024、-b 512 または 1024、--ctx-size 0、--cache-reuse 256 という引数を指定する。README 自身が「Note that the quality will be significantly lower」と品質低下を明言している点は重要で、CPU 構成はあくまで動作させるための下限だと読むべきである。モデルの保存先もプラットフォーム別に記載されており、macOS は ~/Library/Caches/llama.cpp/、Linux は ~/.cache/llama.cpp、Windows は LOCALAPPDATA となる。

Llama Agent と MCP: 補完拡張にエージェントを同居させた構成

この拡張は補完だけでなくエージェント機能を含む。Explorer ビューに Llama Agent の UI があり、Ctrl+Shift+A かメニューの「Show Llama Agent」で開く。README はローカルモデルでの利用を想定し、「gpt-oss 20B is the best choice for now」と述べている。OpenRouter のような外部モデルでも動くとされているが、これは補完のローカル完結という前提とは別の話になる。エージェントは MCP に対応し、VS Code 内でインストールおよび起動済みの MCP サーバーのツールを利用できる。内部ツールは 9 個で、うち custom_tool はファイルまたは Web ページの内容を返し、custom_eval_tool は JavaScript で独自のツールを書ける（入力と文字列の戻り値を持つ関数）。選択範囲をコンテキストに添付する機能と、最大ループ数を設定する項目もある。エージェントの利用手順は README では 3 ステップに留まり、詳細は Wiki に委ねられている。

モデル管理と env という抽象

設定面では、モデルの追加、削除、エクスポート、インポートが補完、チャット、埋め込み、ツールの各用途ごとに用意されている。モデル選択も同じ 4 用途で個別に行う。ここに env という概念が重なる。env はモデルのグループで、env を選択または解除すると、そのグループ内の全モデルがまとめて選択または解除される。env 自体にも追加、削除、エクスポート、インポートがある。README は用途別の定義済み env として、補完のみ、チャットと補完、チャットとエージェントなどの組み合わせを挙げている。モデルはローカルと外部の両方が定義済みで、Hugging Face から直接検索してダウンロードする機能もある。Kimi K3 については moonshot.ai 経由で使う場合の動的ツール読み込みに対応すると記されている。env という間接層は、モデル単位の切り替えでは煩雑になる構成、たとえば補完用の小型モデルとエージェント用の大型モデルを併用する場合に効いてくる。

向かないケースと代替: llama.vim という同じ設計の別実装

この拡張が適さない場面は明確である。第一に、llama.cpp サーバーを自分で動かす前提を受け入れられない場合。拡張は推論エンジンを内包しておらず、別プロセスの llama serve が動いていなければ補完は成立しない。第二に、FIM 非対応モデルしか使えない場合。README は「The plugin requires FIM-compatible models」と明記し、Hugging Face のコレクションを参照先として挙げている。FIM（fill-in-the-middle）に対応しないモデルでは補完品質が成立しない。第三に、CPU のみの環境でクラウド相当の品質を期待する場合で、前述のとおり README 自身が品質低下を認めている。代替としては llama.vim がある。同じ ggml-org が公開する Vim/Neovim 向けプラグインで、llama.vscode の実装はこれを参照して作られた。違いはホスト環境そのもので、エディタの拡張 API、UI の作り、操作キーの割り当てが異なる。VS Code を離れるつもりがないなら llama.vscode、Vim 系の操作体系にいるなら llama.vim という単純な住み分けになる。両者は排他的ではなく、同じ llama.cpp サーバーを共有する構成も理屈上は成り立つ。

ライセンス、保守コスト、導入前に確認すべきこと

ライセンスは MIT で、リポジトリ情報から確認できる。MIT は商用利用や改変、再配布を許容する寛容なライセンスだが、これは拡張本体に対する条件であり、利用するモデルの重みや llama.cpp 自体のライセンスは別に確認する必要がある。法的助言ではないので、配布物として組み込む場合は各自で確認してほしい。保守コストの面では、リリース間隔が短い。v0.0.63 が 2026-08-19、v0.0.64 が 2026-09-01、v0.0.65 が 2026-09-05 と、直近 1 か月で複数回の更新が入っている。機能追加のペースが速いということは、設定項目や env の扱いが変わりうるということでもある。バージョンを固定して運用するか、更新時に設定の互換性を確認する運用が必要になる。導入前に確認すべきは、使用予定モデルが FIM 対応のコレクションに含まれるか、手元の VRAM が 4 段階プリセットのどこに当たるか、agent を使うなら gpt-oss 20B を動かせる余裕があるか、そして Linux の場合は llama.cpp バイナリの導入と PATH 設定を自分で行う覚悟があるか、の 4 点である。

編集部の結論

ローカル推論でコード補完を完結させたい、あるいは MCP 経由で手元のツールをエージェントに使わせたい開発者に向く。逆に、クラウドモデルの品質をそのまま期待する用途や、llama.cpp を別途運用したくない環境には向かない。導入前に確認すべきは、使用予定モデルが FIM 対応かどうか、VRAM 量に見合った llama serve のプリセットが存在するか、そして agent を使う場合は gpt-oss 20B 程度を動かせる余力があるかの 3 点である。

公式情報源

コミュニティノート