「Claude CodeやCursorは便利だ。でも、そのたびに自分のコードとプロンプトが、どこかの企業のサーバーへ送られている」——この一点が気になる開発者に向けて作られたのが、Nanocoder(Nano-Collective/nanocoder)です。GitHubスター2,200超、企業ではなく非営利のコミュニティ・コレクティブが開発する、ターミナルで動くコーディングエージェント。最大の特徴は、Ollamaを使えばコードを一切マシンの外へ出さずに、完全オフラインで動くことです。しかも本体はMITライセンスで無料、テレメトリもベンダーロックインもありません。
- ・課題:主要なAIコーディングツール(Claude Code・Cursor等)はクラウド前提で、コードとプロンプトが外部へ送られる。料金もベンダーロックインもついて回る。
- ・解決:NanocoderはBYOM(Bring Your Own Model)。Ollamaでローカルモデルを指定すれば完全オフライン・ゼロコストで動き、コードはマシンから出ない。クラウドAPI(Anthropic・Google・OpenRouter)にも切り替え可能。
- ・実測:16GB Mac+4Bローカルモデルで実際に動かした。ツール対応モデルなら動くが、簡単なタスクで7分超——速度と品質は「指すモデル」で決まる。
- ・作り手:企業でなくNano Collectiveという非営利コミュニティ。テレメトリなし・有料ゲートなし・特定ベンダー非依存。
- ・ライセンスはMIT(LICENSE.md本文で確認済み。GitHubの「Other」表示は自動判定の都合)。ただし企業サポートはない。
なお、そもそも「AIにコードを書かせる」という開発スタイル全体の始め方・ツール選び・実践ワークフローについては、当サイトのVibe Codingとは?2026年完全ガイドにまとめてあります。本記事はその中でも「ローカルで・オフラインで・自分のモデルで動かす」という選択肢としてNanocoderを掘り下げます。
Nanocoderとは何か——「企業ではなくコミュニティが作る」ことの意味
Nanocoderの公式説明は明快です——「An open coding agent for your terminal, built by a community collective rather than a company. Bring your own model, keep your code on your machine, and owe nothing to anyone.(ターミナルのためのオープンなコーディングエージェント。企業ではなくコミュニティ・コレクティブが作る。自分のモデルを持ち込み、コードは自分のマシンに置き、誰にも借りを作らない)」。
作っているのはNano Collectiveという、営利ではなくコミュニティのためにAIツールを作る集団です。この「作り手が誰か」という一点が、ツールの性格を決めています。READMEはこう書いています——有料ティアはなく、プロンプトをどこかへ黙って送るテレメトリもなく、「何が最も収益化できるか」でロードマップが決まることもない。作っている人たちが、使っている人たち自身だからです。
具体的には、Nanocoderは次のモデル・プロバイダで動きます。
・ローカルモデル(Ollama経由)——完全オフライン・ゼロコスト。コードがマシンから出ない
・OpenAI互換API——OpenRouter、OpenAI、Mistral、Atlas Cloud、Z.aiなど
・ネイティブSDKプロバイダ——Anthropic Claude、Google Gemini、GitHub Copilot、ChatGPT/Codexなど
同じ端末エージェントの体験のまま、裏側のモデルだけを差し替えられる——これがBYOMの実像です。プライバシーが要る作業はローカルモデルで、難しい設計はクラウドの上位モデルで、と使い分けられます。
何ができて、何を解決するのか
読者が知りたいのは結局この3つのはずです。整理します。
・何ができるか:ターミナル内で、自然言語の指示からファイルの読み書き・コード編集・コマンド実行までをエージェントが自律的に進める。スキル(コマンド・サブエージェント・ツール・イベントトリガー)、プロジェクト単位のデーモン、チェックポイント、開発モード(normal/auto-accept/yolo/plan)といった機能を備える
・何を解決するか:「AIコーディングは便利だが、コードとプロンプトを外部へ送りたくない」「サブスク料金やAPI課金を積み上げたくない」「特定ベンダーの仕様変更に人質に取られたくない」という、クラウド前提ツールが構造的に抱える不安を、ローカル実行と多プロバイダ設計で解消する
・何を代替できるか:正直に言えば、生の生成品質でClaude CodeやCursorを丸ごと置き換えるものではありません(後述の実測を参照)。代替できるのは、「プライバシー・オフライン・コストゼロ・ロックインなし」が要件の作業。そしてBYOMなので、モデルを上位のものに差し替えれば品質のギャップは詰められます
ターミナル] --> N[Nanocoder
エージェントハーネス] N --> T[ツール実行
ファイル読み書き・コマンド・スキル] N --> P{プロバイダ選択
BYOM} P -->|プライバシー重視| L[Ollama ローカルモデル
完全オフライン・ゼロコスト] P -->|品質重視| C[クラウドAPI
Anthropic / Google / OpenRouter] L --> R[コードはマシンから出ない] C --> R2[高品質だがAPIへ送信・課金] T --> N
Nanocoderの主な機能——スキル・デーモン・チェックポイント
Nanocoderは単に「LLMにコマンドを投げる箱」ではなく、端末エージェントとして実用的な機能群を備えています。公式ドキュメントで挙げられている主要機能を整理します。
・スキル(Skills)——繰り返す作業を、コマンド・サブエージェント・ツール・イベントトリガーとして定義できる。プロジェクト固有の手順をエージェントに教え込み、再利用する仕組み。Claude Codeの「スキル」や「サブエージェント」に近い発想です
・プロジェクト単位のデーモン——プロジェクトごとに常駐プロセスを走らせ、スキルやイベントを継続的に扱う。nanocoder daemon start / stop / status / logs で管理する
・チェックポイント——エージェントが変更を重ねる途中の状態を記録し、必要なら巻き戻せる。自律的にファイルを書き換えるエージェントにおける安全弁になる
・開発モード——normal(都度承認)/auto-accept(承認自動化)/yolo(承認なし)/plan(計画のみ)を、対話にもCLIにも指定できる
・タスク管理——複数ステップの作業をタスクとして扱い、進行を追える
・MCP対応——Model Context Protocol のサーバーを設定でき、外部ツール・データソースをエージェントに接続できる
配布はnpmのほかHomebrew・Nix Flakesに対応し、エディタ連携としてVS CodeモードやACP(Agent Client Protocol)サーバーモードも用意されています。ACPで起動すればZedなどのエディタから、JSON-RPC経由でNanocoderをエージェントとして呼び出せます。設定は環境変数での上書き(NANOCODER_PROVIDERSなど)にも対応しており、APIキーをバージョン管理に混ぜずに済む配慮も入っています。
【実測】16GB MacでOllamaと動かしてみた——Nanocoderは動く、が「モデル次第」
ここが本記事の中心です。「オフラインで動く」と書くのは簡単ですが、実際にどのモデルで、どの程度使えるのか。手元の16GB RAMのMacで、Ollama経由で実際に動かして確かめました。結論から言えば——動きます。ただし、速度も品質も「どのモデルを指すか」で決まります。
・OS:macOS(Apple Silicon)/RAM 16GB
・ランタイム:Node.js v22.13.1(npm 11.1.0)/Ollama 0.20.5
・Nanocoder:v1.28.1(`npm install -g @nanocollective/nanocoder` で導入)
・モデル:gemma3:4b(3.3GB・ツール非対応)/qwen3:4b(2.5GB・ツール対応)
・タスク:隔離したサンドボックスで、小さなJSファイルを読ませて正誤を一文で答えさせる読み取り専用タスク(planモード)
まず引っかかったのは「ツール非対応モデル」
最初に、すでにマシンにあったgemma3:4b(3.3GB)で動かそうとしました。結果はエラーです。
Bad request: registry.ollama.ai/library/gemma3:4b does not support tools
コーディングエージェントは、ファイルを読む・書く・コマンドを実行するといった操作をツール(関数呼び出し)として行います。そのため、モデル側が関数呼び出しに対応していないと、そもそもエージェントとして成立しません。gemma3:4bはツール非対応だったため、Nanocoderは正しくエラーで止まりました。これはNanocoderの不具合ではなく、ローカルでエージェントを動かすときに最初にぶつかる、最も一般的な落とし穴です。
そこで、ツール対応のqwen3:4b(2.5GB)をollama pullで取得して再挑戦しました。事前にAPIへツール定義を渡して受理されることも確認済みです。
① ツール(関数呼び出し)対応モデルであること——qwen系・llama3.1系など。非対応モデルは即エラー。
② 十分なコンテキスト長——Nanocoderの公式ドキュメントは、Ollamaの既定コンテキスト長2048トークンは「エージェント用途には小さすぎる」と明記し、
OLLAMA_NUM_CTXを上げるよう推奨している。コンテキストが足りないと、モデルがツール定義と会話履歴を保持しきれず「ツール呼び出しが不安定になる/壊れる」とドキュメント自身が警告している。——この2つは別々の話。①はモデルの能力、②はコンテキスト長の設定。混同しないこと。
動いた。ただし1ファイル確認に7分19秒
qwen3:4bで、サンドボックスに置いた小さなFizzBuzzのコードを読ませ、「ロジックが正しいか一文で答えて」という読み取りだけの安全なタスク(planモード)を投げました。プロバイダ設定は環境変数NANOCODER_PROVIDERSでOllamaのローカルエンドポイント(http://localhost:11434/v1)を指すだけです。
結果、Nanocoderはツール(read_file)を使ってファイルを読み、最終的に正しい結論を返しました——「The FizzBuzz logic in fizzbuzz.js is correct…(FizzBuzzのロジックは正しい。15→3→5の順で条件分岐している)」。ツール呼び出しも含めて、完全にオフラインで機能したわけです。ネットワークへの送信は一切ありません。
ただし——所要時間は7分19秒(439秒)でした。たった1ファイルを読んで一文答えるだけの、最も単純なタスクでです。しかも途中の思考ログには、小型の思考モデル特有の「堂々巡り」がびっしり出ました。
Wait, maybe the user’s problem statement is that the code is supposed to have a bug… Wait, the code seems correct… Wait, but the problem says “there is a bug somewhere”… So the code is correct…
この「Wait…」の反芻は、qwen3:4bという4B級の思考モデルが吐く思考トークンが--plainモードでそのまま画面に出ているものであり、Nanocoderのふるまいではありません。同じNanocoderに上位モデル(大型ローカルモデルやClaude・GPTクラス)を指せば、この反芻も遅さも一気に解消します。速度と品質は、ハーネスではなくモデルとマシンの性質という、当たり前だが重要な事実がここに出ています。
実用ラインの引き方
この実測を踏まえると、Nanocoder+ローカルモデルの現実的な使いどころは次のように整理できます。
・4B級モデル・16GB RAM:動作確認・学習・「オフラインで完結すること自体に価値がある」軽作業向け。対話的なコーディング相棒としては遅すぎる
・7〜14B級モデル・32GB以上のRAM:ツール対応の中型モデル(qwen2.5-coderなど)を積めば、実用的な補完・小規模リファクタが視野に入る。RAMとモデルサイズがそのまま体感速度に効く
・クラウドAPIに切り替え:Anthropic・Google・OpenRouterを指せば、Claude CodeやCursorに近い品質で動く。この場合オフライン性は失うが、テレメトリなし・ロックインなしという設計上の利点は残る
つまりNanocoderは「非力なマシンで魔法のように賢くなる」ツールではなく、「モデルの選択権を完全にユーザーへ返す」ツールです。プライバシーと速度・品質のトレードオフを、自分の手で調整できるのが本質です。
なお、ローカルモデルを動かす土台となるOllama自体のセットアップやモデルの選び方は、Ollama公式ドキュメントを参照してください。ツール(関数呼び出し)対応モデルの選定と、コンテキスト長を十分に確保することが、Nanocoderをローカルで快適に使う鍵になります。
使えるかどうかの判定材料——ライセンス・活性度・バス係数・企業サポート
採用判断に必要な事実を、誇張せずに並べます。
| 判定軸 | 実測値(2026-07-18時点) | 評価 |
|---|---|---|
| ライセンス | MIT(LICENSE.md本文で確認・GitHub表示はOther) | 商用利用可。表示の「Other」は判定側の都合 |
| GitHubスター | 2,212 | 端末エージェントとしては堅調 |
| 最終更新 | 2026-07-18(当日push) | 活発に開発中 |
| リリース数 | 90本(最新 v1.28.1) | 頻繁にリリースを刻んでいる |
| コントリビュータ | 約60名(GitHub API上) | 数は多いがコミットは創設者に集中 |
| 実装言語 | TypeScript(npm配布) | Node.js環境があれば導入容易 |
| 配布経路 | npm / Homebrew / Nix Flakes | 主要3経路をカバー |
| 企業サポート | なし(Nano Collective=非営利) | SLA・保証はない |
ライセンス:実体はMIT、表示は「Other」
ここは正確に説明します。LICENSE.mdの本文は逐語のMITライセンスです(「MIT License / Copyright (c) 2026 Nano Collective」で始まり、標準のMIT条文が続くことを確認済み)。したがって商用利用も再配布も問題ありません。
一方で、GitHubのリポジトリ画面やAPIは、このリポジトリのライセンスを「Other/NOASSERTION」と表示します。これはライセンスがMarkdown見出し(# License)付きのLICENSE.mdという形で置かれており、GitHubの自動照合エンジンが標準テンプレートとの一致確信度を十分に上げられなかったためと見られます。表示上の「Other」は判定側の都合であって、中身はMIT——採用審査でライセンスを機械的にチェックしている組織では、ここで誤って弾かれる可能性があるので、ファイル本文を直接確認するのが確実です。
curl -sL https://raw.githubusercontent.com/Nano-Collective/nanocoder/main/LICENSE.md | head で冒頭を見れば「MIT License」の一行が確認できます。SPDX表示だけで判断しないこと。バス係数と企業サポート:数の多さと集中は別
もう1つ、誇張されがちな点を正直に書きます。NanocoderのコントリビュータはGitHub API上で約60名——「非営利コミュニティが作る集合体」という説明にふさわしい規模です。プロジェクトが1人の気まぐれで消える種類のものではありません。
ただし、コミット数の内訳を見ると、その大半は創設者(will-lamerton)に集中しています。次に多いのはCIボットやdependabotで、人間のコントリビュータの多くは小規模な貢献です。つまり「60名が均等に支えている」わけではなく、実質的な牽引役は少数というのが実態です。これは多くの若いOSSに共通する構造で、悪いことではありませんが、「バス係数が高い(=特定個人への依存が小さい)」と単純に評価するのは正確ではありません。
そして最も重要な弱点は、企業のサポートがないことです。Nano Collectiveは非営利のコミュニティで、SLAも商用サポート契約も存在しません。運営はスポンサー(Atlas Cloud等)と寄付で成り立っています。「企業が保証する安心」を求める本番用途には向かず、「ロックインされない自由」を重視する開発者に向く——この線引きを理解した上で採用するのが正解です。
既存のAIコーディングツールとの比較——何が本当に違うのか
「結局、Claude CodeやCursor、aider、clineと何が違うのか」に答えます。ここで大事なのは、オフライン動作やローカルモデル対応は、Nanocoderだけの専売特許ではないという事実を正直に置くことです。aiderやclineもBYOK(自前のキー)でOllamaに対して動きますし、当サイトで解説しているeasy-llm-cli:ChatGPT・ClaudeをターミナルからLLMローカル実行感覚で使えるシンプルなCLIツールのように、ターミナルからローカルLLMを扱うOSSは他にもあります。
では何が違うのか。Nanocoderの差別化は「オフラインで動くこと」そのものではなく、作り手の構造とそこから来る設計思想にあります。
| 観点 | Nanocoder | Claude Code | Cursor | aider | cline |
|---|---|---|---|---|---|
| 動作形態 | ターミナル | ターミナル | 専用IDE | ターミナル | VSCode拡張 |
| 作り手 | 非営利コミュニティ | Anthropic(企業) | Anysphere(企業) | OSS(個人主導) | OSS(企業+コミュニティ) |
| ローカルモデル | ○(Ollama等) | ×(クラウド前提) | ×(クラウド前提) | ○(Ollama等) | ○(BYOK) |
| 完全オフライン | ○ | × | × | ○ | ○ |
| BYOM/多プロバイダ | ○(ローカル+クラウド多数) | △(Claude中心) | △ | ○ | ○ |
| テレメトリ | なし(明言) | あり(設定で調整可) | あり | 最小 | 設定次第 |
| 有料ティアの機能ゲート | なし | あり(サブスク) | あり(サブスク) | なし | なし(BYOK課金) |
| ライセンス | MIT | 商用(クローズド) | 商用(クローズド) | Apache-2.0 | Apache-2.0 |
| 企業サポート | なし | あり | あり | なし | なし |
この表から読み取るべきは、次の3つの陣営分けです。
・Claude Code/Cursor=品質と企業サポートが強いプロプライエタリ・クラウド陣営。生成品質は最上位だが、コードは外部へ出て、料金とロックインがつく。この陣営の代表であるClaude Code側の全体像はClaude Code|2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめている
・aider/cline/Nanocoder=ローカルでも動くOSS陣営。オフライン・ゼロコストが可能で、モデルを自分で選べる
・その中でNanocoderの立ち位置は、「非営利コミュニティ製・テレメトリなし・有料ゲートなし・BYOM第一」を最も徹底していること。IDE統合の使い勝手ならcline、単一ファイル編集の枯れた実績ならaider、と適材適所で選ぶのが現実的です
同じ「OSSのAIコーディングツール」という括りでは、当サイトで解説したContinue vs Cursor徹底比較:無料OSSのAIコーディング拡張は$20の代替になるかや、ブラウザ操作でフロントを直すFrontman完全解説:ブラウザでクリックして直すAI Vibe Coding OSS、Next.js/Astro/Vite対応も比較対象になります。Nanocoderはその中で「ローカル・非営利・BYOM第一」の軸に特化した選択肢です。
導入手順——コピペで動かす
実際に動かす手順です。前提はNode.js環境(npm)と、ローカル実行するならOllamaです。
1. インストール
npmでグローバルインストールし、任意のプロジェクトディレクトリで起動します。HomebrewやNix Flakesでも導入できます。
npm install -g @nanocollective/nanocoder
nanocoder
初回起動時にプロバイダ設定のウィザード(/setup-providers)が立ち上がります。ここでOllama・OpenRouter・Anthropicなどを選んで設定できます。
2. Ollamaでローカル・オフライン動作させる
完全オフラインで動かす場合の手順です。まずOllamaでツール対応モデルを取得します(ツール非対応モデルはエージェントとして動きません)。
# ツール(関数呼び出し)対応モデルを取得(例)
ollama pull qwen3:4b
# より実用的にはツール対応の中型コーディングモデル(要RAM)
# ollama pull qwen2.5-coder:7b
次に、エージェント用途に十分なコンテキスト長でOllamaを動かします。既定の2048トークンはエージェントには小さすぎる、と公式ドキュメントが警告しています。
# コンテキスト長を上げてOllamaを起動(メモリが許す範囲で大きく)
OLLAMA_NUM_CTX=32768 ollama serve
プロバイダ設定は、プロジェクト直下のagents.config.jsonに書くか、環境変数NANOCODER_PROVIDERSで渡せます。ローカルOllamaを指す最小構成は次のとおりです。
export NANOCODER_PROVIDERS='[{"name":"ollama","baseUrl":"http://localhost:11434/v1","models":["qwen3:4b"],"contextWindow":32768}]'
nanocoder --provider ollama --model qwen3:4b
これでコードもプロンプトもマシンの外へ出ません。APIキーは不要です。
3. クラウドAPIで品質を上げる
品質が要る作業では、同じNanocoderのままプロバイダをクラウドに切り替えます。CLIフラグで直接指定できます。
# 非対話モードでプロバイダ・モデルを指定して実行
nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts"
# 開発モードを指定(normal / auto-accept / yolo / plan)
nanocoder --mode plan run "audit the auth module"
・
plan=計画のみ。ファイルを書き換えず読み取り中心で安全(本記事の実測もこのモード)・
normal=各操作で承認を求める既定モード・
auto-accept=runコマンドの既定。承認を自動化・
yolo=承認なしで突き進む。信頼できないリポジトリや重要な作業ディレクトリでは使わない初回は
planやnormalで挙動を確かめてから、自動化モードへ上げるのが安全です。CLIフラグはrunコマンドの前後どちらにも置けます。非対話実行では--plainで軽量ランタイムになり(非TTY環境では自動有効)、CI連携もしやすくなっています。
まとめ——「動く」と「賢い」を分けて考える
Nanocoderは、Ollamaを使えば16GBのラップトップでも本当に完全オフラインで動く、ローカルファーストのコーディングエージェントです。これは実測で確認した誇張なしの事実で、MITライセンス・テレメトリなし・有料ゲートなし・多プロバイダ対応という、非営利コミュニティ製ならではの設計が一貫しています。「コードを外に出さない」「誰にも借りを作らない」という価値観に、これほど素直に応えるツールは多くありません。
同時に、生の賢さや速度は、Nanocoderではなく指したモデルとマシンが決めます。4B級の小型モデル+16GB RAMでは、簡単な1ファイル確認に7分以上かかり、対話的な相棒としてはクラウド上位モデルに遠く及びません。ここを取り違えて「Claude Codeの完全な代わり」と期待すると、がっかりします。正しい見方は、Nanocoderはモデルの選択権を完全にユーザーへ返す器であり、プライバシー・コスト・品質のトレードオフを自分の手で調整するためのものだ、というものです。
Nanocoderの使い方が向く人・向かない人
最後に、Nanocoderの使い方を検討している人向けに、向き・不向きを整理しておきます。
・向く人:コードを外部へ出したくない、オフラインで完結させたい、API課金やサブスクを避けたい、特定ベンダーにロックインされたくない開発者。ローカルコーディングエージェントを「自分のマシンの中だけで」動かしたい人。あるいは、プライバシー重視の作業はローカルモデル、難所はクラウドモデル、と使い分けたい人
・慎重に検討すべき人:企業のサポート・SLAが必須の本番運用、非力なマシンしか無くクラウド級の応答速度を常に求める用途、GUI中心で端末操作に抵抗がある人。この場合はプロバイダをクラウドに切り替える、あるいは他ツールを併用するのが現実的です
いずれにせよ、Nanocoderは「賢さを買う」ツールではなく「選択の自由を取り戻す」ツールです。その前提さえ押さえれば、期待と現実のズレは起きません。
参照ソース
・Nano-Collective/nanocoder(公式リポジトリ・README) — 設計思想・BYOM・機能・インストールの一次情報
・Nanocoder Documentation(docs.nanocollective.org) — プロバイダ設定・開発モード・CLIフラグの詳細
・Ollama プロバイダ設定(公式ドキュメント) — コンテキスト長2048では小さすぎる旨とOLLAMA_NUM_CTXの推奨
・Nano Collective(公式サイト) — 非営利コミュニティ・コレクティブの理念とプロジェクト群
・LICENSE.md(MITライセンス本文) — 逐語のMIT条文(GitHub表示はOther/NOASSERTION)