notcrawl - Notion workspace をローカル SQLite と Markdown に写す

重要な仕事の記録を Notion に集めている team は多いですが、browser の外に出た瞬間に扱いづらくなることも少なくありません。全文検索したい、SQL で覗きたい、page を folder として export したい、agent に読ませる knowledge snapshot を作りたい。そんな場面で、Notion の UI だけでは足りなくなります。

今日取り上げたい openclaw/notcrawl は、そのギャップをかなり正面から扱う project です。Notion workspace をローカルの SQLite と normalized Markdown に mirror し、内容を UI 依存ではなく、検索・照会・共有しやすい local asset に変えます。README では SQLite を canonical archive、Markdown を durable human/agent surface と位置づけていて、この整理がとても良いです。

公開時点の GitHub page では、約 106 stars、10 forks。主な言語は Go、license は MIT。Repository には現在 149 commits あり、release page の latest は v0.4.0、公開日は 2026-05-18 です。

プロジェクト概要

項目	内容
Repository	openclaw/notcrawl
位置づけ	local-first Notion archive / search tool
Stars	約 106
Forks	約 10
主な言語	Go
License	MIT
Latest version	v0.4.0
主な出力	SQLite、Markdown、git-share snapshot

やっているのは backup ではなく、Notion を扱える data layer に戻すこと

Notion export tool の多くは、最終的に扱いづらい HTML や、構造が安定しない Markdown を置いて終わります。File は出ても、その後に query したり、incremental sync したり、automation へ渡したりしづらいことが多いです。

notcrawl はもう少し engineering 寄りです。README には三つの ingestion path が明示されています。

desktop: ローカル Notion desktop cache の read-only snapshot
api: official Notion API を使った rate-limit aware な sync
notion-mcp: あらかじめ設定された Codex Notion connector を使う targeted repair

この設計が実務向きです。ひとつの path に全部を賭けず、desktop cache で輪郭を取り、official API で structure を補い、MCP で欠けた page や block を埋める、という使い方ができます。実際の Notion workspace はきれいに一発同期できないことが多いので、複数の入口を持つ意味があります。

SQLite と Markdown の二層構成が一番おもしろい

README の中でも一番重要なのはこの一文です。SQLite is the canonical archive. Markdown is the durable human/agent surface.

この分け方はかなり筋が良いです。

まず machine 側には、安定して query できる source of truth が必要です。notcrawl は SQLite をその役に据え、README の current scope でも FTS5、status、activity report、maintenance command、read-only SQL access を挙げています。つまり database を一時 cache ではなく、主要な archive として扱っています。

一方で、人間や agent にとっては normalized Markdown の方が扱いやすいことが多いです。README では workspace、teamspace、page path に沿って整理された Markdown export が説明され、Unicode-safe path も明記されています。こういう path 安定性は地味ですが重要で、Git diff、history、share、automation の質にそのまま効きます。

Knowledge base、agent context、long-term notes のような用途では、database だけでも text file だけでも足りません。二層を最初から分けているのが、この project の強みです。

この project は「自分の PC に export できた」で終わっていません。README には compressed JSONL git-share snapshots があり、git share mode を使うと、他の machine が Notion credential を持たなくても normalized snapshot を subscribe できると書かれています。

これはかなり大事です。Team の課題はしばしば「Notion から一回出す」ことではなく、「出した knowledge をどう安全に再配布するか」です。すべての environment が直接 Notion API に触り、token を持ち、独自に crawl し始めると、permission と audit の境界はすぐ複雑になります。

notcrawl は取得と共有を分けます。信頼できる environment で crawl し、共有先にはすでに正規化された snapshot を渡す。Agent retrieval、offline search、multi-machine sync、internal archive のような場面では、この設計の方がずっと扱いやすいです。

単なる crawler ではなく、日常運用の surface がそろっている

こういう project で信頼しやすいのは、core idea だけでなく、運用面の surface まで作っているものです。

README の quick start と commands を見ると、notcrawl はかなり実用品寄りです。たとえば:

doctor は config、SQLite、desktop cache、token presence を確認する
status は archive counts、last sync time、database/WAL size を出す
report は recent page、database、space、comment activity をまとめる
maintain は FTS rebuild、index optimize、VACUUM を実行できる
tui で terminal から page/database をさっと見られる
--json control surface があり、automation や CI から呼びやすい

特に metadata --json、status --json、doctor --json、check-update --json のような control surface があるのは良いです。Launcher、定期 sync、health check、CI smoke test などにそのまま組み込みやすくなります。

Notion MCP integration は面白いが、役割は補修レイヤー

notion-mcp はこの project を個性的にしている部分です。README では、preconfigured Codex Notion connector を使う targeted repair と説明されていて、workspace 全体の完全列挙を約束していません。--page や --query を指定しない場合も、主に desktop cache で本文がない page、参照 block が欠けている page、API block sync が完了しなかった page を補う用途です。

この割り切り方は正しいと思います。MCP をメインの同期パスではなく、repair path として使うことで、外部 session への依存を抑えつつ、欠損を埋められます。

config.example.toml にも境界が見えます。

auth_path は ~/.codex/auth.json
base_url は ChatGPT apps gateway
connector_id は明示設定
max_pages で上限を置ける

README は Notion MCP mode を read-only and targeted と明記し、credential は request 時に読むだけで保存せず、signed URL credential も persist 前に除去すると説明しています。Private knowledge を扱う tool では、この種の boundary 表明がかなり重要です。

release と distribution の作りも参考になる

Tool project を見るとき、distribution 周りはその project の成熟度が出やすいです。

docs/distribution.md では、notcrawl が GitHub Releases、Homebrew tap、そして optional な Cloudsmith APT/RPM repository で配布されると書かれています。Release 前の local check は go test ./... と go build ./cmd/notcrawl だけでなく、metadata --json、status --json、doctor --json、check-update --json、tui --json --limit 10 まで含みます。CI でも dependency verification、gofmt、go vet、tests、GoReleaser snapshot build、CodeQL を実行します。

この release discipline は好印象です。単に build が通るだけでなく、control surface 自体が壊れていないかを確かめています。Local archive tool は UI より先に control interface の安定性が効くので、この方向性はかなり実務的です。

Latest release v0.4.0 の note は短めですが、Markdown export path の UTF-8 truncation 修正が入っています。Archive tool にとって、こういう path と encoding の修正は flashy feature より価値があります。History が壊れないこと、Git diff がきれいなこと、cross-platform で path が安定することの方が本質だからです。

向いている人

notcrawl は特に三つのタイプの人に合いそうです。

ひとつ目は、Notion を日常の workspace として使っているが、knowledge を browser に閉じ込めたくない個人開発者や small team です。

ふたつ目は、AI agent に読ませる context を安定して作りたい人です。必要なのは「Notion に書いてあること」ではなく、「agent が読めて、あとから audit しやすい local surface」なので、この project はかなり相性が良いです。

三つ目は、local-first software が好きな人です。Remote knowledge platform を増やすのではなく、まず data を手元へ戻し、その上で search、export、share、automation を組み立てたい人向けです。

境界もある

もちろん万能ではありません。

1 page をたまに export したいだけなら、notcrawl は少し重いはずです。この project の価値は、一回限りの export ではなく、継続 sync、local archive、structured search、multi-surface reuse にあります。

また、README が説明している通り、notion-mcp は experimental な gateway / connector contract に依存します。そこを workspace 全体の唯一の foundation とみなすより、repair layer として使う方が安全です。

まとめ

openclaw/notcrawl の価値は、「Notion を crawl できる」ことそのものではありません。Notion の内容を SQLite という canonical archive と、Markdown という human/agent surface に分けて保持し、git-share、TUI、JSON control surface、distribution discipline まで含めて、Web UI の中に閉じていた knowledge を local で扱える資産へ変えているところです。

最近「Notion をただの browser app ではなく、開発 workflow で再利用できる data layer にしたい」と感じているなら、かなり見る価値のある小さめの project です。