OmniBox を自前で動かす前に読む、収集と RAG の境界
Collect, organize, use, and share, all in OmniBox.
ひと目でわかる
- これは何？
- OmniBox は Web ページ・ファイル・音声を一箇所に集めて質問できるようにする Apache-2.0 の Python プロジェクトである。本稿はリポジトリ構成と README から読み取れる範囲で、何を解決し、どこでつまずき、どんな用途に向かないかを整理する。
- 誰に向いている？
- 採用を検討すべきなのは、社内やチーム内に散らばった PDF・Word・Web 記事を一箇所に集め、その上で質問と執筆をしたい層である。逆に、単一の静的サイトを検索したいだけの場合や、外部サービスへのデータ送信を一切許容できない環境には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
OmniBox が埋めようとしている穴は何か
情報を集める行為と、集めた情報を後から使う行為は、たいてい別の道具に分かれている。ブックマークは溜まるが検索できない。ノートアプリは書けるが、PDF の中身を横断してはくれない。OmniBox はこの二つを一つの場所に寄せようとしている。README の Introduction は「collect, then ask」という短い言い方でこれを表現しており、保存した時点で取り込みと索引付けが走り、後から質問できる状態になる、という流れを想定している。
対象は個人だけではない。Core Features の最後に「User and team system, permissions, sharing management, multi-tenancy」とあり、チーム単位の権限管理と共有を最初から視野に入れている。つまり個人のメモ帳ではなく、部署やプロジェクト単位で資料を溜めて再利用する場面を想定した作りである。ブラウザ拡張、iOS アプリ、WeChat Bot という複数の入口が用意されているのも、同じ発想の延長にある。入力の摩擦を下げないと資料は溜まらない、という判断だろう。
単一リポジトリに見えて、実体は submodule の集合
リポジトリ名は import-ai/omnibox だが、README のバッジが示すのは omnibox-web、omnibox-backend、omnibox-wizard、omnibox-browser-extension という別々のリポジトリである。本体はこれらを束ねる親リポジトリで、実際のコードは submodule 側にある。クローン手順が git clone --recurse-submodules を要求しているのはそのためで、この指定を忘れると空のディレクトリが並ぶだけになる。
プライマリ言語が Python とされているのは backend と wizard に対応する部分で、Web フロントエンドとブラウザ拡張はそれぞれ別の言語で書かれていると考えるのが自然である。リポジトリを読むとき、あるいは不具合を追うときに、どの submodule の話をしているのかを意識しないと迷子になる。Issue や Pull Request の宛先も、機能によっては親ではなく各 submodule 側になる。導入検討の段階では「Python プロジェクト」という一行だけで判断せず、動かすためには複数のコンポーネントが揃う必要があると理解しておきたい。
取り込みから質問までの流れ
README から読み取れる範囲で、データは次のように流れる。入口は三つあり、ブラウザ拡張は Web ページの本文を抽出して送る。ファイルアップロードは PDF、Word、PPT、MP3 といった形式を受け取り、README はこれを「end-to-end parsing & indexing」と表現している。WeChat Bot はファイル、Web ページ、動画、音声メッセージ、テキスト、チャット記録を対象にする。
取り込まれた内容は解析され、索引が付く。その上で質問と執筆が成立する。特徴的なのは、質問の対象がローカルのデータベースだけではない点で、README は「based on both Internet and local databases」と書いている。手元の資料と外部の情報を同じ問い合わせの中で扱う設計である。トピックに rag と ai-search が並んでいるのはこの部分を指す。
編集機能は Markdown ベースで、数式、マインドマップ、フローチャート、シーケンス図、ガントチャート、楽譜といった記法のレンダリングに対応するとされている。取り込んだ資料を読むだけでなく、そこから書くことを想定している点が、単なる全文検索ツールとの違いである。ただし解析や索引付けの具体的な実装、どのベクトルストアを使うのか、チャンク分割をどう決めているのかは README には書かれていない。ここは example.env と backend のコードを読んで確認するしかない。
動かすためのコマンドと設定
ローカル開発の手順は README に明記されている。git clone --recurse-submodules で取得し、example.env を .env にコピーし、scripts/dev.sh up -d --build を実行する。Docker Compose ベースの起動スクリプトであることはこの形から推測できるが、README は各サービスの中身までは説明していない。
ホスト型のサービスを使う選択肢も用意されており、omnibox.pro ではメール、Google、WeChat でのログインが可能とされている。ブラウザ拡張の導入とローカル配備の手順は別ページのドキュメントに分かれている。
注意したいのは、example.env の中身が README には一切示されていないことである。外部 LLM の API キー、埋め込みモデルの指定、ストレージの接続先といった必須項目がここに集中しているはずで、導入可否の判断は結局このファイルを開かないと下せない。公開されている情報だけで「どの程度の構成で動くのか」を確定させることはできない。
向かない場面と、確認できない部分
第一に、静的サイトや社内 Wiki の検索を置き換える道具ではない。OmniBox の中心は取り込んだ資料に対する質問であり、クロールして回る検索エンジンではない。既存の全文検索で足りているなら、解析と索引付けの分だけ構成が重くなる。
第二に、データの扱いが気になる組織では慎重になるべきである。README は質問がインターネット側のデータベースも参照すると書いており、取り込んだ内容がどこまで外部に送られるのかは、この記述だけでは判断できない。オンプレミスで閉じたい場合に外部依存を切れるのかどうか、example.env と backend の設定を確認する必要がある。
第三に、これはまだ v0.1 系である。リリースは v0.1.47、v0.1.48 と短期間に刻まれており、beta 版も並行して出ている。破壊的な変更が入る前提で運用を組むべき段階で、長期的な安定を前提にした基盤には向かない。
第四に、README には動作要件、対応する Python のバージョン、最低限必要なマシン資源、バックアップや移行の手順が書かれていない。これらは導入前に自分で確かめるしかない項目である。
代替としての Obsidian と AnythingLLM
同じ問題に対して、アプローチの異なる道具がある。Obsidian はローカルの Markdown ファイル群を Vault として扱い、検索とリンクで知識を繋ぐ。ファイルは手元のディスクにそのまま置かれ、アプリを捨ててもデータは残る。OmniBox は逆で、取り込んだ内容は解析と索引を経てサービス側のデータベースに入る。持ち出しやすさでは Obsidian が明確に有利で、Web ページや PDF の自動取り込みと質問応答では OmniBox が有利という関係になる。
AnythingLLM は、ドキュメントを取り込んでワークスペース単位で LLM に渡すという点で OmniBox と重なる。違いは入口の広さにある。OmniBox はブラウザ拡張、iOS アプリ、WeChat Bot を揃えており、日常の動線から資料を放り込む体験を重視している。AnythingLLM はどちらかといえば既存の文書群をまとめて投入し、チャットの土台にする使い方に寄る。Markdown エディタと図表レンダリングを備えた執筆環境まで一体化しているかどうかも、両者を分ける点である。どちらを選ぶかは、資料を「集める頻度」と「書く頻度」のどちらが高いかで決まる。
ライセンスと更新コストの見取り図
ライセンスは Apache-2.0 で、商用利用や改変、再配布が許容される条項を含む。ただし親リポジトリが Apache-2.0 だからといって、submodule 側の omnibox-web、omnibox-backend、omnibox-wizard、omnibox-browser-extension が同じ条件であるとは限らない。各リポジトリの LICENSE を個別に確認する必要がある。ここは法的判断ではなく、確認すべき対象の指摘である。
更新の頻度は高い。直近では v0.1.47 から v0.1.48 までが数日で進み、その間に beta 版も出ている。追従する側は、submodule の更新をどのタイミングで取り込むかを決めておかないと、差分が積み上がる。git submodule update の運用を決めることが、実質的なメンテナンス計画になる。
ロードマップには RSS Subscription が未完了として残っており、Agent、folder、document の公開共有、WeChat Bot、Open API、モバイルアプリは完了済みと記されている。Open API が既に存在するため、UI を経由せずに取り込みを自動化する道は用意されている。
編集部の結論
採用を検討すべきなのは、社内やチーム内に散らばった PDF・Word・Web 記事を一箇所に集め、その上で質問と執筆をしたい層である。逆に、単一の静的サイトを検索したいだけの場合や、外部サービスへのデータ送信を一切許容できない環境には向かない。最初に確認すべきは example.env に並ぶキーのうち、外部 LLM とベクトル検索に関わるものが何を要求しているか、そして scripts/dev.sh が submodule をどう扱うかである。ここを読まずに本番構成を組むと、後から保存先ごと移行することになる。
コミュニティノート