slacrawl: Slack workspace を local SQLite に mirror する CLI
team の議論が Slack に寄るほど、本当に困るのは「検索窓があるか」ではなく、data が自分たちで扱える場所に残っているかです。
Slack UI は、その場で一言を探すには便利です。ただ、もう少し細かく query したい、audit 可能な local copy を持ちたい、offline で過去の incident を追いたい、script や agent に team knowledge を読ませたい、となると Web search だけでは足りません。必要なのは別の chat UI ではなく、query できて、backup できて、retention も管理できる local archive です。
今日メモしておきたい openclaw/slacrawl は、まさにそこを扱う project です。Slack workspace の data を local SQLite に mirror し、CLI、FTS5、read-only SQL、MCP connector、desktop cache ingest、git-backed archive workflow から扱えるようにします。
GitHub repository API、README、CHANGELOG、release page、LICENSE、default branch commit history を 2026-07-04 時点で確認すると、slacrawl は 201 stars、23 forks。repository の primary language は Go、license は MIT です。repository 作成日は 2026-03-07、直近の repository push は 2026-07-04。default branch main の最新公開 commit は 2026-07-04 の 1d54439 で、message は perf: make event-head upgrades lazy (#77) です。最新 release は v0.7.4、公開日は 2026-07-04 です。
Project overview
| 項目 | 内容 |
|---|---|
| Repository | openclaw/slacrawl |
| 位置づけ | Slack workspace local SQLite archive CLI |
| Stars | 201 |
| Forks | 23 |
| Primary language | Go |
| License | MIT |
| Repository 作成日 | 2026-03-07 |
| 直近の repository push | 2026-07-04 |
| Default branch 最新 commit | 2026-07-04, 1d54439 |
| Latest version | v0.7.4 |
| Release date | 2026-07-04 |
| 中心の考え方 | Slack の visible data を local SQLite に同期し、search、SQL、MCP、desktop ingest、retention、git snapshot で再利用する |
解いているのは chat ではなく archive boundary です
Slack の履歴には、いろいろな情報が混ざっています。
- incident retrospective;
- customer issue;
- temporary decision;
- release window;
- 「誰が何を変えたか」の context;
- thread にしか出てこなかった重要な制約。
これらは Slack の中では検索できます。ただ、engineering system の一部にするのは難しいです。ある channel の activity trend を SQL で集計しづらいし、履歴の一部を audit 可能な Git snapshot として配布しづらいし、local agent に安定して読ませることも簡単ではありません。
slacrawl の方針はシンプルです。まず data を SQLite に入れる。README にある capability には、workspace、channel、user、message sync、SQLite FTS5 full-text search、read-only SQL、mention extraction、thread reply backfill、DM/MPIM sync、Slack file media caching、time-based retention purge が含まれています。
この方向は、「Slack client をもう 1 つ作る」より engineering workflow に合っています。SQLite は local で、安定していて、script、BI、小さな tool、agent から読みやすい中間層です。
複数 source を扱う設計が重要です
slacrawl は Slack data source を token 付き API だけに単純化していません。複数の path を明示的に扱います。
README の source model には、次の選択肢があります。
sync --source bot/api: configured bot token または user token で標準 API sync;sync --source mcp: Codex の HTTP Slack connector または reference Slack MCP server から workspace data を取得;sync --source wiretap/desktop: local Slack Desktop cache を読む;sync --source all: API を先に走らせ、そのあと desktop enrichment;tail: Socket Mode で live event を追う;watch: desktop-local state を定期 refresh する。
この分け方は現実的です。company Slack の permission、token、retention、desktop state は、きれいな 1 つの model では収まりません。bot token で見える範囲があり、user token で補える thread / DM / MPIM があり、desktop cache に local visible state が残っていることもあり、MCP connector は Slack を agent environment に接続済みの人に向いています。
slacrawl が強調している大事な点は、1 つの config/database は 1 つの Slack visibility boundary を表すべき、ということです。つまり、personal、company、別 permission source を混ぜて「完全そうに見える archive」を作るべきではありません。この境界感は重要です。archive tool が source を混同すると、後の query や sharing が危険になります。
SQLite に入ると Slack history は操作できる asset になります
slacrawl で良いと思うのは、「message を download できます」で終わっていないところです。
README の command は local data workbench に近いです。
searchは FTS と substring fallback を行う;messagesは condition 付きで message を列挙する;mentionsは structured mention を見る;sqlは read-only SQL を実行する;reportは archive activity と git-share freshness を見る;digestとanalyticsは channel activity を集約する;purgeは absolute / relative cutoff で古い message を preview して削除する;publishは SQLite archive を compressed JSONL shards と manifest に export する;subscribe/updateは git-backed reader workflow を扱う。
これは、data を取った後の maintenance まで考えている設計です。
たとえば retention purge は見落とされがちです。team は最近 90 日だけ searchable に残したいかもしれないし、retained event history を compact したいかもしれません。いきなり delete ではなく、preview してから transactional に消したい場合もあります。slacrawl はこの流れを command として持っていて、user に直接 database を触らせません。
read-only SQL も大事です。Slack data が SQLite に入ったあと、少し調べたいだけで write permission を開くのは危険です。slacrawl は SQL path を read-only にしていて、日常の query surface として扱いやすいです。
v0.7.4 は実用中の細部を直しているように見えます
最新 release の v0.7.4 は、headline のための release というより、multi-workspace と desktop/API sync の現実的な edge case を直す release に見えます。
CHANGELOG では、multi-workspace desktop/API sync scoping、fail-closed workspace authentication、workspace-qualified purges、明示的な watch workspace selection の修正が挙げられています。unchanged desktop refresh が message events を重複させる問題への対応、retained-history compaction の preview-first path、relative runtime path の absolute path normalization、nullable optional message metadata の扱いも含まれます。
派手ではありませんが、local archive tool が本当に踏みやすい問題です。
長く個人開発機や team machine で動かす tool にとって、いちばん怖いのは UI がないことではありません。workspace boundary を間違える、purge scope を間違える、duplicate event が history を汚す、relative path のせいで違う database を開く、といった問題です。v0.7.4 はそこを直しています。
default branch では、v0.7.4 の後に event-history upgrade を lazy seeding にする performance commit も入っています。archive size と migration cost をまだ詰めていることが分かります。
向いている人、向いていない人
slacrawl は、次のような人には試す価値があります。
- Slack history を offline search したい developer;
- incident、release、support discussion を queryable knowledge として残したい team;
- SQL や script で Slack activity を分析したい人;
- MCP / Codex Slack connector をすでに使っていて、Slack data を local agent workflow に入れたい人;
- Slack data の git-backed snapshot を持ち、SaaS UI だけに依存したくない人。
一方で、次の用途には向きません。
- たまに Slack UI で一言検索するだけの場合;
- 適切な Slack token がなく、desktop cache も読めない場合;
- team policy が local message copy を許していない場合;
- write-back actions や完全な Marketplace-level distribution が必要な場合;
- 一般 user 向けの graphical Slack replacement を期待している場合。
最大の caveat は permission と compliance です。slacrawl が archive できるのは、現在の token、connector、desktop profile から見える data だけです。Slack permission を迂回する tool ではありませんし、複数 workspace を無造作に混ぜる backup tool として扱うべきでもありません。本格的に使う前に、local message copy、file media cache、git snapshot について team policy を確認したほうがいいです。
まとめ
openclaw/slacrawl の面白さは、Slack history を「Slack UI の中でだけ検索できるもの」から、local で query でき、retention を管理でき、snapshot として配布できる SQLite archive に変えるところです。
この種の tool は毎日開くものではないかもしれません。ただ、incident retrospective、長期 project migration、customer context の整理、agent に team memory を読ませる場面では、Web search より infrastructure に近い存在になります。
Slack は chat tool ですが、その中には大量の engineering facts が残っています。slacrawl の価値は、それらを UI の中から取り出し、engineer が実際に操作できる場所へ置くことです。