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.
ひと目でわかる
- これは何？
- nanocoder は Ollama や OpenAI 互換 API を自分で選んで使うターミナル常駐のコーディングエージェントで、商用ティアやテレメトリを前提としない点を設計の軸に置いている。本稿では README とドキュメント構成から読み取れる範囲で、その仕組み、導入コマンド、画面モードの設計上のトレードオフ、向く用途と向かない用途を整理する。
- 誰に向いている？
- nanocoder が向くのは、モデルを自分で選びたい、プロンプトを外部に送りたくない、あるいは Ollama で手元のマシンに閉じてエージェントを動かしたい開発者だ。逆に、ホスト型サービスにワークフローを預けたい人、モデル選定や API キー管理を丸ごと任せたい人には向かない。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
nanocoder が埋めようとしているのは「モデル選択の主導権」という穴
ターミナルで動くコーディングエージェントは、ここ数年で一気に増えた。ただ、その多くは特定ベンダーのモデルを前提に組み立てられており、使うモデルを変えるにはツール自体を乗り換える必要がある。nanocoder が解こうとしているのはこの点だ。README は「Bring your own model」を掲げ、Ollama 経由のローカルモデルと、OpenRouter、Anthropic、Google といった OpenAI 互換 API の両方を対象に挙げている。つまり、どのプロバイダにコードとプロンプトを渡すかを利用者側が決める、という構図になっている。
対象読者は明確だ。API キーを自分で管理でき、モデルの違いを理解し、そのうえで手元のマシンか自分の契約したプロバイダに処理を寄せたい開発者である。逆に、モデル選定も含めてツール側に丸投げしたい層には、この設計は荷が重い。README の言葉を借りれば「privacy-respecting」「local-first」「open for all」が売りであり、これは利便性よりも制御を優先する立場だと言い換えられる。
プロバイダ抽象化とモード、2 つの軸で動く仕組み
公開されている資料から読み取れる構造は、大きく 2 つの軸に分かれる。1 つはプロバイダの抽象化、もう 1 つは動作モードだ。
プロバイダ側は、CLI フラグで --provider と --model を指定する形になっている。README の例では nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts" のように、非対話で 1 回だけタスクを流す使い方と、nanocoder --provider ollama --model llama3.1 のように対話セッションを特定プロバイダで始める使い方が並記されている。フラグは run コマンドの前後どちらにも置けると明記されており、nanocoder run --provider openrouter "refactor database module" という書き方も示されている。
モード側は normal、auto-accept、yolo、plan の 4 つが挙げられている。--mode yolo は自動承認を最大まで広げる方向、--mode plan は実行前に計画を立てさせる方向だと読める。README の例では nanocoder --mode plan run "audit the auth module" という組み合わせが示されており、監査のような読み取り中心の作業を計画モードで流す想定が見える。
この 2 軸は独立している。プロバイダをローカルに固定したまま yolo で走らせることも、OpenRouter を使いながら plan で慎重に進めることもできる。設定の自由度が高い代わりに、何をどう組み合わせるかは利用者が決めなければならない。
導入は npm 1 行、ただしプロバイダ指定まで含めて初めて動く
導入手順そのものは短い。README の Quick Start は次の 2 行だけを示している。
npm install -g @nanocollective/nanocoder nanocoder
ただし、これだけで意図したモデルが使われるわけではない。プロバイダとモデルを明示するなら、起動時にフラグを渡す。
nanocoder --provider ollama --model llama3.1 nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts"
Homebrew と Nix Flakes でも配布されていると README は述べており、詳細は docs/getting-started/installation.md の該当セクションに置かれている。設定項目は docs/configuration/index.md にまとまっており、AI プロバイダ、MCP サーバー、preferences、logging、timeouts が並ぶ。画面モードの既定を変えたい場合は preferences の "alternateScreen": true を設定するか、起動時に --alt-screen を付ける。逆に設定を無視して inline に固定したいときは --no-alt-screen を使う。
機能側は docs/features/index.md に Skills（commands、subagents、tools、event triggers）、lifecycle hooks、プロジェクト単位の daemon、checkpointing、development modes、task management が列挙されている。ここは名前の列挙以上のことまでは資料から読み取れないので、個々の挙動は各ドキュメントを直接参照する必要がある。
inline と alt-screen の選択は、コピー操作とスクロールのどちらを優先するかの問題
nanocoder の画面設計は地味だが、日々の使い勝手を左右する。README は Claude Code と Codex が採用しているのと同じ 2 モードを用意したと説明している。
inline は既定で、メイン画面に描画する。確定したメッセージはターミナル本来のスクロールバックに 1 度だけ出力されるため、スクロールバー、マウスホイール、検索がそのまま機能する。終了後もトランスクリプトがターミナルに残る。
alt-screen は --alt-screen フラグか preferences の "alternateScreen": true で有効になり、代替画面バッファ上に固定高のレイアウトを敷く。アプリ内スクロールになり、マウスホイールと PgUp/PgDn、スクロールインジケータが付き、新規出力で自動的に最下部へ戻る。
ここに実害のあるトレードオフがある。代替画面ではマウスレポートが有効になるため、ターミナル側のクリックドラッグ選択が奪われる。README は Ctrl+P で選択モードを切り替えてターミナルに返せる、と説明している。つまり alt-screen を常用するなら、コピーのたびに修飾キーを 1 つ挟む運用になる。ログを頻繁にコピーする人にとっては、これが inline を選ぶ十分な理由になりうる。
両モードに共通する挙動として、/clear はターミナルを完全にリセットして新しいウェルカムバナーを出し、Ctrl+C か /exit での終了時は入力 UI を消してトランスクリプトと別れのメッセージを残す、と説明されている。
コレクティブ開発という前提が、ロードマップの読み方を変える
nanocoder は企業ではなく Nano Collective というコミュニティが作っている。README はこの点を機能差として説明する。有料ティアがないこと、プロンプトを外部に送るテレメトリが仕込まれていないこと、収益化に有利な方向へロードマップが曲がらないこと。加えて、マルチプロバイダを原則として維持するため、特定ベンダーのモデルに固定されないと述べている。
これは採用判断に直接効く。商用製品なら、機能の優先順位は売上に引き寄せられる。コレクティブ運営では、その代わりに貢献者の関心と、スポンサー収入の継続性が優先順位を決める。README には Atlas Cloud がスポンサーとして掲載され、支援ページと Economics Charter へのリンクが置かれている。無料で使えることと、開発が継続することは別問題であり、この構造では後者がスポンサーと貢献者に依存する。
もう一点、README は「他のプロジェクト」へのリンクを置き、複数プロジェクトで規約、テスト、リリース基準を共有していると説明している。ツール単体ではなく collective 全体の一員として保守されるという立場であり、リリース頻度や互換性の方針もその枠組みの中で決まる。
ライセンス識別子が NOASSERTION である点は、採用前に必ず潰す
このリポジトリについて報告されているライセンス識別子は NOASSERTION であり、これは「標準的な SPDX 識別子として機械的に判定できなかった」ことを意味するだけで、ライセンスが存在しないとか、自由に使えるという意味ではない。README のバッジには NPM License の表示も含まれているが、それだけで条項が分かるわけではない。
ここは推測で埋めてはいけない部分だ。リポジトリ直下の LICENSE ファイルと、npm パッケージに同梱されるライセンス表記を自分の目で確認する必要がある。特に、社内ポリシーで許可されたライセンスのホワイトリスト運用をしている組織では、NOASSERTION のまま導入判断を通すのは難しいはずだ。ライセンス条項の解釈は法務の領域であり、ここで断定的なことは書けない。
保守コストの面では、リリースが v1.28.1（2026-06-28）、v1.29.0（2026-07-26）、v1.30.0（2026-08-26）とほぼ月次で並んでいる。活発に見えるが、これは変化が速いということでもある。設定キーや CLI フラグの互換性がどう扱われるかは資料からは分からないため、バージョンを固定して運用するか、都度リリースノートを追うかを先に決めておきたい。npm のグローバルインストールは更新が手元に直接届く形態なので、この判断は導入と同時に必要になる。
Claude Code や Codex と何が違うのか、比較の軸はホストか自前か
同じターミナル型エージェントとして名前が挙がるのが Claude Code と Codex だ。README 自身が画面モードの説明でこの 2 つを引き合いに出し、inline と fullscreen の 2 モードを揃えたと述べている。つまり UI の作りは近い。
差が出るのはモデルの扱いだ。Claude Code は Anthropic のモデルを前提とし、Codex は OpenAI 側のモデルを前提とする。nanocoder はプロバイダを --provider で切り替える構造で、Ollama を使えばローカル推論に閉じられる。ここが実質的な分岐点になる。手元のマシンからプロンプトを出したくない案件、あるいは API 従量課金を避けて手持ちの GPU で回したい案件では、選択肢の性質が変わる。
逆に、モデルとホスト環境を一体で最適化した体験を求めるなら、専用ツールの方が摩擦は少ない。nanocoder は抽象化の層を 1 枚挟む分、プロバイダごとの差異を利用者が吸収する場面が出る。抽象化は自由度と引き換えのコストであり、そのコストを払う価値があるかどうかが採用の分かれ目になる。
編集部の結論
nanocoder が向くのは、モデルを自分で選びたい、プロンプトを外部に送りたくない、あるいは Ollama で手元のマシンに閉じてエージェントを動かしたい開発者だ。逆に、ホスト型サービスにワークフローを預けたい人、モデル選定や API キー管理を丸ごと任せたい人には向かない。導入前に確認すべきは 3 点ある。第一に、npm install -g @nanocollective/nanocoder で入れた後、nanocoder --provider ollama --model llama3.1 のように自分のプロバイダとモデルを明示して起動できるかどうか。第二に、--mode plan と --mode yolo のどちらを日常の作業に置くか、つまり自動承認の範囲をどこまで広げるかを決めること。第三に、ライセンス識別子が NOASSERTION と報告されているため、リポジトリ直下の LICENSE ファイルで実際の条項を自分の目で確認すること。この 3 点が自分の用途に合わなければ、採用を見送る判断も普通にありうる。
コミュニティノート