OmniSearch: Windows に散らばった作業の痕跡を 1 つのローカル launcher に集める
desktop search で本当に面倒なのは、「検索欄がない」ことではありません。作業の痕跡が細かく分断されていることです。
app は Start Menu、file は Explorer、browser page は history、clipboard は短い履歴、screenshot の文字は OCR、Git commit や TODO は別の場所。そこに AI agent、chat history、local command まで入ると、何かを探すたびに小さな database を何個も行き来することになります。
今日メモしておきたい PranshulSoni/omnisearch は、このかなり具体的な Windows の摩擦を扱う project です。PC 上にすでにあるものを、local-first な keyboard launcher に集め直します。
GitHub repository page、README、release page を 2026-07-03 時点で確認すると、この project は 42 stars、3 forks。repository の primary language は Rust、license は MIT です。repository 作成日は 2026-06-22、直近の公開 code push は 2026-07-02。最新 release は v1.0.4 で、公開日は 2026-07-01 です。
Project overview
| 項目 | 内容 |
|---|---|
| Repository | PranshulSoni/omnisearch |
| 位置づけ | local-first Windows launcher / desktop search |
| Stars | 42 |
| Forks | 3 |
| Primary language | Rust |
| License | MIT |
| Repository 作成日 | 2026-06-22 |
| 直近の公開 code push | 2026-07-02 |
| Latest version | v1.0.4 |
| Release date | 2026-07-01 |
| 中心の考え方 | app、file、content、clipboard、OCR、browser history、Git activity、agent record を 1 つの shortcut で探す |
価値は app launcher そのものではなく、「少しだけ覚えている手がかり」を入口にすることです
多くの launcher は「app を開く」ところで境界が止まります。それ自体は便利ですが、実際の作業には少し足りません。
よく覚えているのは app name ではなく、もっと曖昧な手がかりです。
- さっき copy した error message;
- 先週開いた document;
- screenshot に写っていた注文番号;
- browser history にある title の一部だけ覚えている page;
- どの repo で直したか曖昧な commit;
- agent と話した task context。
OmniSearch は、こうした手がかりを同じ search entry に入れる方向です。README に並んでいる search source には、app、file と file content、image/screenshot OCR、browser bookmark/history、clipboard、Git、Windows Settings、local command、agent と agent chat が含まれます。
これは単なる launcher より少し先にあります。Windows desktop 向けの個人作業 index に近いです。
local-first はここでは飾りではありません
この project で見るべき点の 1 つは、最初から search box を cloud AI entry にしていないことです。
README では、index data は PC 上に残ると説明されています。runtime data は %APPDATA%\omnisearch に置かれ、local database には indexed metadata、searchable text、browser items、clipboard history、chats、agents、settings が入ります。実装面では native Rust/Win32、SQLite FTS5、background indexing、OCR、debounced input を使って responsiveness を狙っています。
これは desktop tool ではかなり重要です。
扱う data が非常に私的だからです。clipboard、browser history、file content、screenshot OCR、Git activity。この範囲を探す tool が最初から remote service に強く依存すると、日常 workflow に入れるのはためらいます。local-first であることは、少なくとも trust boundary を自然な場所に置きます。まず local で探し、AI や agent はその上の追加 layer として扱えるからです。
clipboard を重く扱っているのが良いです
OmniSearch で個人的に良いと思うのは、clipboard をおまけではなく重要な入口として扱っている点です。
developer が毎日何度も探すものは、正式な file だけではありません。むしろ手元を一瞬通り過ぎた temporary fragment のほうが多いです。
- command;
- URL;
- log;
- issue number;
- token name;
- screenshot;
- reply に混ぜたい短い text。
README では、clipboard history search、pin、multi-select、image copy、text clip editing、recent item の sequential paste、latest screenshot paste、clipboard cleanup、clipboard text について AI に聞く、といった機能が挙げられています。
この種の機能は派手ではありませんが、うまく動くと大きな assistant より頻繁に使われます。作業の距離が近いからです。世界全体を agent に理解させるのではなく、今すれ違った小さな context を取り戻すための tool です。
Git、OCR、browser recall が入ると programmer tool らしくなります
OmniSearch は完全な一般 office tool ではありません。Git activity、code content、TODO/FIXME、OCR、agent chat が入ることで、かなり power user / programmer 寄りになります。
この組み合わせは自然です。
programmer の「探す」は複数の媒体をまたぎます。error clue は screenshot にあるかもしれないし、fix の手がかりは browser history にあるかもしれない。TODO は code にあり、context は agent chat にあるかもしれません。それぞれの tool でも検索できますが、切り替えのたびに集中が削られます。
local launcher がこれらを Alt + Space の後ろにある 1 つの search box にまとめられるなら、解いているのは search algorithm そのものではなく、検索する前の switching cost です。
Hermes agent support は慎重に見るべきですが、方向は面白いです
README には Hermes agent support もあります。launcher から local task を実行し、承認済み command を走らせ、agent chat を管理し、PC control を補助するという説明です。
この部分は少し慎重に見たいです。
desktop launcher に agent を入れると、すぐに「何でもできる」大きすぎる tool になりがちです。permission、誤操作、説明可能性の問題も出ます。ただし OmniSearch の入口は比較的筋が良いです。search box を最初から chatbot にするのではなく、local context と command palette を先に作り、その後ろに agent capability を置いています。
つまり agent が indexed files、clipboard、Git activity、settings entry の近くで働くなら、孤立した chat window ではなく desktop に近い操作 layer になり得ます。
今のリスク: 若い、Windows-only、docs はまだ粗い
この project はまだかなり小さく、新しいです。repository 作成日は 2026-06-22 で、このメモを書いている時点では公開から十数日しか経っていません。
現実的な caveat はあります。
- Windows tool なので、macOS/Linux user は基本的に対象外;
- README には重複している section があり、docs はまだ整理中に見える;
- release は v1.0.4 まで進んでいるものの、最新説明は older version から upgrade するときの self-update / lock 問題修正が中心で、install/update path はまだ磨いている段階;
- local data の範囲が広いので、使う前に index directory、data location、agent/command permission を確認したほうがいい。
これらは project を否定する理由ではありません。ただ、今すぐ main desktop tool に入れるかどうかには影響します。
私は OmniSearch を、方向性のはっきりした early tool として見ています。Windows が主な作業環境で、Start Menu、Explorer、browser history、clipboard、screenshot、Git 情報の分断にかなり疲れているなら試す価値があります。成熟した cross-platform launcher を探しているだけなら、今はまだその答えではありません。
まとめ
PranshulSoni/omnisearch が面白いのは、狭い意味の「app を開く launcher」だけに留まっていないことです。同時に、desktop search をいきなり cloud AI chatbot に包んでもいません。
選んでいる方向はもっと地味ですが、日常には近いです。
Windows 上にすでにある作業の痕跡を local に index し、1 つの shortcut から取り戻せるようにする。
app、file、content、OCR、clipboard、browser history、Git、settings、agent chat は、単体ではよくある source です。ただし、それらが同じ低遅延の入口に入ると価値はかなり具体的になります。
Windows power user にとって、この種の tool が継続的に磨かれるなら、また 1 つの「万能 AI desktop assistant」より長く効くかもしれません。