Omni: 社内知識と業務ツールをAIエージェントへつなぐ基盤
getomnico/omniは実運用向けに使える実用的なオープンソース実装で、再利用可能な導入ルートを持つプロジェクトです。
ひと目でわかる
- これは何?
- Google Drive、Gmail、Slack、Confluence、Jiraなどを取り込み、Postgres内の全文検索とベクトル検索で共有コンテキストを作るApache-2.0プロジェクト。
- 誰に向いている?
- Omniは社内文書と複数の業務システムを一つの検索・ツール層へまとめたいチーム向けです。READMEだけでは対応版、性能、運用実績が確定しないため、まず検証用Postgresに限定したデータを取り込み、権限境界、BM25結果、pgvector結果、同期失敗を確認してください。
- 商用利用できる?
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている?
- 主に Rust です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
業務システムを個別接続から外す
Omniは、エージェントをGoogle Drive、Gmail、Slack、Confluence、Jira、HubSpot、社内ファイルシステムなどへ直接つなぐ代わりに、共通のコンテキストとツール層を置く構想です。READMEは会社の知識を索引化し、質問への回答、情報分析、従業員支援に必要な文脈をエージェントへ渡すと説明しています。
対象は単なる文書ビューアではありません。コネクター、インデックス、検索、AIやLLMのオーケストレーション、Webフロントエンドを含む構成です。接続先の一覧があることと、各サービスの権限モデルや同期範囲が実運用で揃うことは別なので、連携ごとに確認します。
採用前の記録ではgetomnico-omni-deep-analysisのリリース、実行環境、入力、出力を固定します。画面やREADMEの印象ではなく、コマンドの終了コード、生成されたファイル、ネットワーク接続、エラー時の復帰を確認します。正常系だけでなく、設定値を欠かせた場合、権限を持たない場合、途中でプロセスを止めた場合も試します。観察結果は人が読めるメモと機械的なログの両方に残し、次の更新で同じ手順を再実行できる形にします。
導入を決める前に、getomnico-omni-deep-analysisが触れる範囲を一覧化します。読み取りだけか、ファイル変更や外部接続も行うかを分け、許可した範囲を越えた記録がないかを確認します。依存するランタイムと補助サービスの版を保存し、更新前後で差分を比較します。失敗したときに残るログの場所、利用者が元の状態へ戻す方法、削除や無効化の手順が説明できなければ、本番の対象には広げません。
この確認では、getomnico-omni-deep-analysisにない機能を推測で補いません。READMEに記載された入口から小さな入力を与え、期待する応答と実際の応答を比べます。未記載の挙動は未確認として残し、数値や互換性を一般化しません。
Postgres一つに検索とデータを置く
Architectureの説明では、ParadeDBをBM25全文検索、pgvectorを意味検索、アプリケーションデータを担うPostgresにまとめます。READMEはElasticsearchや専用ベクトルデータベースを使わず、一つのデータベースを調整、バックアップ、監視する構成を示しています。
この選択は構成要素を減らす一方、検索負荷と業務データを同じ運用面で扱う判断になります。インデックス更新、バックアップ容量、ベクトル検索の拡張、障害時の再同期について具体的な基準はREADMEにありません。採用時はPostgresのスキーマとマイグレーションを先に読みます。
Rust、Python、SvelteKitの分担
READMEは、検索、インデックス、コネクターの調整をRust、AIとLLMのオーケストレーションをPython、WebフロントエンドをSvelteKitで実装すると説明しています。三つの実行環境があるため、ビルドとデプロイの境界も一つではありません。
素材からは必要なPython版、Rustツールチェーン、Node版、最小のPostgres拡張構成を確定できません。導入ガイドに明記されていない既定値を補わず、リポジトリの設定ファイル、compose定義、リリース履歴を読み、各サービスを個別に起動してログを分けて確認します。
検索結果を業務権限と結び付ける
Omniの価値は、社内情報をエージェントが回答に使える形へまとめることにあります。だから検索品質だけでなく、誰の資格情報でどのコネクターを読むか、削除済みデータが索引から消えるか、回答に出典が残るかが中心的な確認点です。READMEは接続先を列挙していますが、各サービスのACL同期やテナント分離の詳細までは示していません。
検証用データには本物の顧客情報を入れず、アクセス可能な文書と不可視の文書を分けます。BM25で固有語を探し、pgvectorで言い換えを探し、両方の結果に許可されない文書が混ざらないかを確認します。認証情報やログの保存先が不明なまま本番接続へ進めないことが重要です。
導入資料の不足を前提にする
基線のREADMEには、現行版を固定して実行するコピー可能な導入コマンドが確認できません。公式サイトとリポジトリを入口に、README、Architecture、リリース、LICENSEを順番に確認する段階です。Apache-2.0は再配布と改変の条件を示しますが、連携先データの扱いやサービス保証を与えません。
また、互換表、性能基準、長期サポート、コネクター別の失敗復旧は素材から確定できません。書かれていないことを「対応済み」としないため、導入記録にはコミットまたはリリース、接続先、同期件数、検索遅延、エラーログを残します。
最初に試す範囲を限定する
社内検索とエージェントの業務支援を一つのデータ層で運用したいチームには検討余地があります。複数システムの認可を厳密に管理できない組織や、検索性能の基準が先に必要な組織には準備不足です。READMEは本番成功を証明する資料ではありません。
初回は公開または合成データだけを使うPostgresを用意し、最小のコネクター一つで取り込みます。ParadeDBの全文検索とpgvectorの意味検索を同じ質問で比較し、再同期後の削除、権限変更、バックアップからの復元を観察します。そこで設定とログの所在が説明できてから、対象システムを増やします。
接続テストでは、閲覧を許可した文書と拒否した文書を同じ検索語で用意します。同期前後の件数、ParadeDBの固有語検索、pgvectorの言い換え検索、削除後に残る結果を保存します。LLMへ渡るプロンプトと検索ログにアクセストークンが現れないことを確認し、失敗したコネクターを再試行した際の重複登録も確認します。
編集部の結論
Omniは社内文書と複数の業務システムを一つの検索・ツール層へまとめたいチーム向けです。READMEだけでは対応版、性能、運用実績が確定しないため、まず検証用Postgresに限定したデータを取り込み、権限境界、BM25結果、pgvector結果、同期失敗を確認してください。
コミュニティノート