AI agent に context を渡そうとすると、多くの人が同じところで詰まる。必要な資料は一つの Git repo だけにない。design note は Markdown、meeting note は document、古い説明は PDF、runbook は別 folder、実際に直す code はまた別の source tree にある。これらを毎回 prompt に貼るのは無理があるし、全部 cloud RAG に投げるのも private な作業資料には合わないことがある。

今日紹介する gmickel/gno は、この問題に向けた local knowledge engine だ。code search だけでも note app だけでもない。notes、code、PDF、Office docs、meeting transcripts、reference material を local collection に入れ、BM25、vector search、hybrid retrieval、citation 付き回答、Web UI、REST API、MCP server、Bun/TypeScript SDK を提供する。使いどころははっきりしている。agent に「実際に自分が使っている local files」を検索させたいが、資料を先に cloud service へ移したくない場合だ。

2026-07-21 時点で GitHub repository page、README、Releases page/API、LICENSE、package.json、npm registry、public git history、そして scout が返した field から確認できる情報では、gmickel/gno は 96 stars、9 forks。GitHub の primary language は TypeScript、license は MIT。GitHub page embedded data の repository creation time は 2025-12-16 15:58:15 UTC。public git history の最初の commit は 1345efe、commit time は 2025-12-16 15:58:26 UTC、message は Initial Commit。現在の default branch commit は f02cecd、commit time は 2026-07-21 09:37:51 UTC、message は chore: bump to v1.12.2。scout が記録した latest pushed time は 2026-07-21 09:44:08 UTC。GitHub Releases で Latest と表示されているのは v1.12.2、published time は 2026-07-21 09:57:53 UTC。npm の @gmickel/gno latest も 1.12.2 で、published time は 2026-07-21 09:46:50 UTC。

プロジェクト概要

項目内容
リポジトリgmickel/gno
位置づけlocal knowledge engine、docs/code search、agent retrieval layer
Stars96
Forks9
主言語TypeScript
ライセンスMIT
GitHub 作成時刻2025-12-16 15:58:15 UTC
最初の public commit1345efe、2025-12-16 15:58:26 UTC
current main commitf02cecd、2026-07-21 09:37:51 UTC
latest pushed2026-07-21 09:44:08 UTC
最新 GitHub releasev1.12.2、2026-07-21 09:57:53 UTC
npm version@gmickel/gno 1.12.2、2026-07-21 09:46:50 UTC published
キーワードlocal-first、BM25、vector search、MCP、REST API、SDK、notes、docs

collection を先にきちんと作る

gno の README でいちばん実用的なのは、「AI answer」そのものより、複数の source を collection としてどう扱うかだ。例では ~/notes、仕事用 docs directory、project source directory をそれぞれ追加し、collection ごとに context を持たせている。検索結果は単なる file hit ではなく、「これはどの資料領域か」という framing を持つ。

これは agent にとってかなり重要だ。失敗する agent workflow の多くは、model が code を書けないからではなく、見つけた文書が RFC なのか、runbook なのか、personal note なのか、古い実装メモなのかを判断できないところで起きる。gno context add は小さな機能に見えるが、retrieval の解釈を毎回 prompt に押し込むのではなく、index layer に近いところへ寄せている。

検索入口も分かれている。gno search は exact keyword、gno vsearch は semantic lookup、gno query は hybrid retrieval で、score traces も出せる。人間が CLI で retrieval quality を確認してから、同じ能力を agent に渡せる。この順序は、最初から black-box RAG server を立てるより調整しやすい。

local-first だが CLI だけではない

gno の基本姿勢は local-first だ。README は local files に fast keyword search、semantic retrieval、grounded answers with citations、wiki-style linking、workspace UI を提供すると説明している。導入も軽い。Bun が必要で、bun install -g @gmickel/gno の後に collection initialization、indexing、embedding model pull、検索、daemon 起動ができる。

ただし単一 CLI では終わらない。project は Web UI、REST API、MCP server、SDK を持つ。日常利用では Web UI で collection、graph、document view、answer を見る。automation には REST や SDK が向く。Claude Code、Cursor、Zed などの MCP client には MCP server が自然な入口になる。

Gumi でこの project を拾う理由もここにある。多くの “local knowledge” tools は personal second brain に寄り、多くの code search tools は source code だけを見る。gno はその間をつなごうとしている。同じ collection に notes、docs、PDF、Office files、code を置き、同じ retrieval result を human UI、CLI、agent に渡せる。

agent には回答より引用が大事

README では gno ask と grounded answers が目立つが、より重要なのは retrieval surface のほうだと思う。Agent の回答が流暢であることは珍しくない。本当に必要なのは、その判断がどの local document、どの file fragment に基づくかを示せることだ。

gno は raw retrieval と synthesis を分けている。gno query --all --files で file context を agent に渡すだけでもよいし、citation 付き回答まで作らせてもよい。engineering workflow ではこの選択肢が効く。code を変更する前なら関連 docs と source snippets だけで十分なことが多く、design summary なら citation 付き synthesis が合う。

daemon mode もある。local 資料が変わったときに index を background で追従できる。長期 project では、毎回 context bundle を手で作り直すより現実的だ。runbook、meeting notes、design drafts はよく変わる。agent が古い static context だけを見ていると、すぐ実態からずれる。

GNO の niche なところ

この project は star 数こそまだ小さいが、範囲はかなり広い。desktop beta assets、Web UI screenshots、MCP と skills の説明、REST API、SDK、embedding benchmark まわりまである。README には Qwen3-Embedding-0.6B-GGUF を default embedding model として使う話や、code retrieval / multilingual docs retrieval の benchmark 説明も載っている。

面白いのは、これは「もう一つの chat UI」ではないことだ。gno は local work material の retrieval runtime に近い。collection management、indexing、embedding、query、daemon、UI、API、MCP が同じ local knowledge layer を中心にまとまっている。Codex、Claude Code、Cursor をすでに使っている人にとっては、IDE を置き換えるものではなく、agent の外部記憶に近い部品になる。

publish 機能も実用的だ。README では note や collection を gno.sh reader に export でき、public、secret、invite-only、locally encrypted before upload を選べると説明している。local-first と publish は一見ぶつかるが、default sync ではなく明示的な export なら、team に選んだ knowledge pack を共有する用途に使える。

注意したいところ

第一に、project の動きが速い。GitHub Releases の latest は v1.12.2、npm latest も 1.12.2 だが、README の “What’s New” section はまだ latest release v1.8.0 と書いている。documentation の一部は遅れる可能性があるため、automation script では release/tag/package metadata を優先したい。

第二に、Bun に依存し、advanced features では local embedding model、SQLite/vector retrieval、background daemon が関係する。README では macOS の vector search に Homebrew SQLite が必要とも書いている。company machine や CI runner に入れる場合、bun install -g だけを見ずに runtime environment を先に確認したほうがよい。

第三に、local-first は risk-free という意味ではない。扱うのは notes、docs、PDF、Office files など、sensitive な情報を含みやすい資料だ。MCP、REST API、publish export は便利だが、どの collection を agent に見せるか、どの内容を export してよいかは明確に決める必要がある。

第四に、project name の gno は短く、別 ecosystem の Gno/Gnolang などと混同しやすい。script や document では package name @gmickel/gno または GitHub repo gmickel/gno を明記したほうが安全だ。

まとめ

gmickel/gno を記録する価値は、agent context の問題を chat UI ではなく local files と retrieval quality に落としているところにある。notes、code、docs、PDF を、searchable、citable、MCP/REST/SDK accessible な local knowledge layer にする project だ。

もし agent が project 外の資料、たとえば design notes、customer docs、old meeting records、runbooks、cross-repo references をよく必要とするなら、gno は試す価値がある。まだ若く、documentation にも部分的な遅れはあるが、方向は明確だ。まず local knowledge を信頼できる retrieval surface にして、それを agent に使わせる。