Googleのマルチモーダル埋め込みモデル「EmbeddingGemma 2」を搭載したMacメニューバー検索ツール：指定フォルダ内の動画や音声区間まで探せる

DigUp は、Google のマルチモーダル埋め込みモデル EmbeddingGemma 2 をベースに構築された Mac 向けのメニューバー検索ツールです。指定したフォルダ内の写真、文書、コード、さらには動画や音声の区間まで、さまざまなコンテンツを検索できます。開発者の Abdur Rahim 氏によってオープンソースとして公開されており、覚えている内容を言葉で説明するだけで、手元の Mac 内から関連ファイルを特定し、動画の該当シーン、文書の該当ページ、コードの該当ブロックへ直接ジャンプできます。

Mac 標準の Spotlight でも、ファイル名、文書の本文、メタデータの検索は可能です。DigUp はそこからさらに一歩進め、写真に写っている情景、録音で話されているトピック、動画に現れるシーンなどを処理します。例えば次のような場面です：

• かつて撮影した動画で、画面にシマウマが映っていた記憶はあるものの、ファイル名が思い出せない。
• 以前聴いたポッドキャストで、睡眠の話題について話していたのは覚えているが、シークバーを手探りで動かすしかない。
• 契約した長い PDF の賃貸借契約書で、ペットに関する特約が具体的に何ページ目にあるかわからない。
• ローカルのコードリポジトリ内にある指数バックオフ付きのリトライ関数を探したいが、ファイル名や関数名に retry という単語が含まれていない。

本ツールは Google DeepMind が公開したマルチモーダル埋め込みモデル EmbeddingGemma 2 を採用しています。（埋め込みモデルとは、コンテンツをベクトルと呼ばれる比較可能な数値の列に変換するモデルです）Mac のローカル環境で画像、スクリーンショット、PDF、テキスト文書、音声、動画に対して統一されたベクトル表現を構築し、ファイルが「どんな名前か」ではなく「何を含んでいるか」という内容の意味に基づいたセマンティック検索を実現しています。

さらに DigUp の特徴は、ファイルそのものを提示するだけでなく、ファイル内の該当箇所へ直接ジャンプできる点にあります。動画プレイヤーを該当シーンが映る再生位置へスキップさせ、ポッドキャストを対応するトピックの音声区間へジャンプさせ、PDF を該当条項が記載されたページへめくり、エディタ上で該当するコードブロックへ移動します。すべてのセグメント分割とインデックス検索は Apple Silicon のローカル上で完結し、個人のファイルを外部サービスへアップロードする必要はありません。

なぜ一言のテキストで写真や録音が見つかるのか

DigUp の検索ロジックを理解する鍵は、搭載されているマルチモーダル埋め込みモデル EmbeddingGemma 2（Google DeepMind がオープンソース化、Apache 2.0 ライセンス）にあります。

マルチモーダル検索でよく用いられる手法の一つは、音声認識で台詞を書き起こしたり、OCR で画面上の文字を抽出したりして、純粋なテキスト同士の類似度を計算するという中間テキストへの変換処理を挟むものです。しかし、このアプローチは文字を媒体とするため、声のトーンや環境音、画面の構図や被写体の動きといった、文字情報に変換されない情報が抜け落ちやすくなります。

EmbeddingGemma 2 が採用しているのは、ネイティブなマルチモーダルアライメント（Native Multimodality）のアプローチです：

1. 統合されたベクトル空間：モデル全体のパラメータ数は 740M（270M のテキストバックボーン、170M のビジョンエンコーダ、300M のオーディオエンコーダで構成）です。テキスト、静止画像、動画からサンプリングしたフレーム、音声区間は、すべて同一の 768 次元のベクトル空間に写像されます。
2. モダリティ間での直接比較が可能な表現：ベクトル空間が統合されているため、テキストクエリと画像・音声・動画の各セグメントの間で、コサイン類似度を直接計算できます。アプリはこの類似度に基づいて候補ファイルを並べ替え、元のファイルを確認できるようにします。
3. タスク指示プレフィックス（Task Instruction Prefixes）：モデルの学習時には、タスクの種類に応じたテキストプレフィックスによる誘導が用いられています。通常の検索クエリには task: search result | query: {query}、コードの意図検索には task: code retrieval | query: {query} を付与し、文書コンテンツは title: {title} | text: {content} としてラップします。このプレフィックスによって、テキストベクトルが対象の検索シナリオにより適切に整合します。
4. エンコーダのモジュール分離設計：ビジョンエンコーダとオーディオエンコーダは互いに独立しています。入力テキストをもとにマッチングを行う検索フェーズではテキストバックボーンのみを読み込めばよく、画像や音声のエンコードコンポーネントを同時にメモリに保持し続ける必要はありません。

ファイル特定後、どのように該当ページや再生位置へ飛ぶのか

動画全体や数百ページの PDF 全体をまとめて単一のベクトルにしてしまうと、検索結果はファイルそのものを指し示すことしかできません。DigUp では各種メディアをタイムスタンプや位置メタデータを保持した区間（Segments）に分割することで、ファイル内部の位置への直接ジャンプを実現しています。

macOS 環境下において、DigUp は AVFoundation、PDFKit、Vision、ImageIO の各フレームワークを呼び出してファイルの解析と特徴抽出を行います：

1. 動画の区間分割：キーフレームサンプリングと画像ハッシュによる重複排除

動画は最もデータ量が大きくなるメディアです。バックグラウンドでの処理にあたり、DigUp はフレーム数予算の配分と画像ハッシュによる重複排除戦略を採っています（Media+Apple.swift のソースコード参照）：

• サンプリング間隔とフレーム数予算：サンプリングの間隔は max(3, duration / 1200) 秒で計算されます。通常は約 3 秒ごとに 1 フレームを抽出しますが、動画が長尺になった場合は、最初の 1,200 フレームだけで打ち切るのではなく、最大 1,200 フレームを上限予算として間隔を動的に広げます。各フレームは 70 個のビジョン soft token の予算でエンコードされます。
• 平均ハッシュ（aHash）による重複排除：抽出された各フレームは 8×8 のグレースケール画像にリサイズされ、平均ハッシュが計算されます。前後のフレームのハミング距離が 4 ビット以内（(hash ^ lastHash).nonzeroBitCount <= 4）であれば、画面がほぼ同じであるとみなされ、そのフレームのエンコードはスキップされて直前の代表フレームの区間が後ろへ引き延ばされます。スライド資料や定点カメラのような静止に近い画面を重複排除し、どの画面に後続区間を代表させるかを決定します。
• 映像と音声の独立した並行処理：動画ファイルは映像トラックと音声トラックの 2 つの独立したパスに分解されます。映像はフレーム抽出を経てエンコードされ、音声トラックは抽出後に音声処理パイプラインへ送られます。これにより、画面の動き・情景の検索と、発話内容の検索の双方が可能になります。

2. 音声の区間分割：スライディングウィンドウと無音区間の除去

音声処理において、EmbeddingGemma 2 の一般的なモデルカードは 8,192 トークンのコンテキストウィンドウを備えており、理論上はより長尺な音声も受け入れ可能です。一方、DigUp の現在の実装では、1 回の入力上限を 30 秒に設定しています（ソースコードのコメントでも、単一入力において 30 秒以降の内容は無視される旨が明記されています）：

• ウィンドウ仕様：音声は一律 16 kHz のモノラルにリサンプリングされ、30 秒の固定時間区間に切り分けられます。ウィンドウは 25 秒ステップでスライド（すなわち 5 秒間の重複を保持）します。5 秒の重複を設けることで、区間の境界をまたぐ発話もいずれかのウィンドウに収まりやすくなります。
• 無音の除去：区間ごとに二乗平均平方根（RMS）エネルギーを計算します。RMS ≤ 0.003（約 -50 dBFS 未満）の場合は無音または極めてノイズの少ない環境と判定し、ベクトル生成をスキップしてストレージ容量を節約します。

3. PDF と長文ドキュメント：2 段階スケジューリングと画像・テキストのハイブリッド処理

長文ドキュメントや契約書に対して、DigUp はバッチ読み込み機構を設計しています：

• ページ数による振り分けと 2 段階スケジューリング：ソースコードでは bigPDFPages = 50 と定義されています。50 ページ以内の PDF は初回インデックス時に全文が読み込まれます。50 ページを超える長大な PDF の場合、第 1 段階では先頭の 30 ページのみを読み込み、多くのファイルが速やかに検索可能な状態になるようにします。30 ページ以降の内容はバックグラウンドの後続処理に回されます（単一ファイルの上限は 5,000 ページ）。一般的なテキスト文書も、先頭 40 チャンク（約 6.4 万文字）を優先してインデックス化し、残りは後から追加する方針で処理されます。
• スキャン文書の画像・テキスト統合：1 ページから抽出されたテキストが 200 文字未満の場合（スキャン文書やプレゼンスライドでよく見られます）、DigUp はページを画像としてレンダリングし、ビジョンエンコーダを呼び出します。同時に Apple Vision による OCR を組み合わせることで、スキャンされた請求書や領収書の中の番号類もキーワード検索の対象に含まれるようにしています。

4. コードプロジェクト：独立インデックスと構造化された行ブロック

コード検索を有効にすると、専用の独立したデータベース（code.sqlite）が使用されます：

• 行ブロック分割：コードの完全な行単位で分割され、各ブロックの上限は約 1,800 文字に収まるよう制御されます。ソースコードのコメントによると、分割が短すぎると関数のロジックが分断されやすく、長すぎると検索意図が曖昧になりやすいとされています。
• ルールに基づく除外：.gitignore のルールに従い、依存ライブラリ、テスト生成物、秘密鍵、証明書などは自動的にスキップされます。

このようにウィンドウやサンプリングフレームで切り分ける仕組みには、粒度に関するトレードオフも存在します。システムが提示する位置は、ヒットした時間ウィンドウやサンプリングフレームであり、1 文字単位・1 フレーム単位の厳密なアンカーではありません。また、特定の重要シーンが動画内で一瞬だけ映り、それがたまたまサンプリング間隔の隙間に落ちてしまった場合には、検出を見落とす可能性があります。

意味での検索と元の単語での検索はどのように連携するのか

すべての区間のベクトルがローカルデータベースに保存された後、テキストクエリとテキスト・画像・音声動画との間の素のコサイン類似度をそのまま比較しようとすると、モダリティ間での分布の違いという壁に突き当たります。

1. モダリティごとの平均補正と標準化スコア

実際の検索において、同一の入力クエリに対する素のコサイン類似度の分布は、モダリティ（テキスト、画像、音声）ごとに平均値の水準が異なる傾向があります。素の類似度でそのまま順位付けしてしまうと、平均値が高めに出やすいモダリティが上位を独占し、他のモダリティにある真に関連性の高い候補が埋もれてしまう恐れがあります。

DigUp は Searcher.swift 内で、モダリティごとの平均による中心化（Modality Centering）という処理スキームを採用しています：

1. 各モダリティの平均値の算出：現在のクエリにおけるテキスト、画像、音声の各モダリティごとのコサイン類似度の平均値を集計します。あるモダリティのベクトル数が 20 個未満の場合は、全体ベクトルの平均スコアをそのモダリティの平均値として借用します。
2. モダリティの中心化：各区間のスコアから、該当モダリティの平均値を差し引いた差分を計算します：中心化差分 = コサイン類似度 − 当該モダリティの平均値。
3. 合同標準偏差の算出とスコアの標準化：キャリブレーション対象となった全区間の中心化差分の平均値と、モダリティを横断した合同標準偏差（下限値を 0.02 に設定）を計算し、最終的な標準化 Z スコアを導出します：Z = (中心化差分 − キャリブレーション区間の中心化平均) ÷ 合同標準偏差。
4. 突出度しきい値によるフィルタリング：しきい値 zGate = 2.0 を設定します。このスコアは、ある区間がそのモダリティの平均水準から標準偏差いくつ分乖離しているかを測定するものであり、該当モダリティの中で相対的に際立っているかを判定するための指標です。関連確率や検索精度そのものを示す数値ではありません。各モダリティ共通の合同標準偏差を用いることで、サンプルの分布幅が狭いモダリティが過剰に拡大評価されるのを防いでいます。

2. 完全一致による補完：なぜ FTS5 全文検索が必要なのか

埋め込みモデルは自然言語の意図を把握することに長けていますが、ベクトル表現だけでは 1 文字ごとのコード、型番、請求書の伝票番号などを確実に保持することは困難です。

そこで DigUp は、2 つの経路を組み合わせたハイブリッド検索構造を採用しています：

• セマンティック軌道（Meaning）：EmbeddingGemma 2 のベクトル類似度とモダリティ補正スコアに依拠します。
• キーワード軌道（Words）：SQLite ネイティブの FTS5 全文検索モジュールに依拠し、ファイル名、ディレクトリパス、文書内の文字列、OCR で抽出された文字に対して語幹処理と正規化検索を行います。

システムはクエリ文字列の特徴に応じて、両軌道の重み付けを動的に調整します：

• 通常の検索：セマンティックベクトルのスコアが主導し、キーワードが一致した場合は追加の加点が付与されます。
• 特定番号の検索（Lookup）：ソースコード内の isLookup の判定条件では、クエリ内のすべての有効な単語に数字が含まれており、かつアルファベットが含まれているか、または数字の長さが 4 桁以上であることが求められます。例えば純粋な注文番号 4815162342 やコード記号 K7Q2LM を入力した場合にこのモードが発動し、キーワードの重みが 2 倍に引き上げられ、セマンティックベクトルの重みは半減します。しかし、通常の単語が混在したクエリ（例えば invoice 4815162342 の場合、invoice はストップワードではなく数字も含まないため）では、この特殊な重み付けはトリガーされません。
• コード検索向けの重み調整：コード検索においては、app、get、running などの高頻度な単語がソースファイル内に極めて普遍的に現れます。そのため、コード検索時のキーワードの重みは 1.0 に設定され（通常検索では 2.0）、表面的な単語の一致が本来の検索意図を阻害しないよう配慮されています。

以下のクエリの例を切り替えることで、どのインデックスへ振り分けられ、意味と元の単語がどのように検索に関与するかを確認できます：

作者のデモで示された 4 つの検索結果

開発者の Abdur Rahim 氏が公開し、Google Gemma 公式アカウントも推薦・引用した実機デモでは、典型的なワークフローの操作が紹介されています：

ケース 1：動画のシーン特定（zebra in a video）

検索窓に zebra in a video と入力すると、候補リストに Masai Mara - day 2.mp4 という動画がヒットし、該当するタイムスタンプが提示されます。

• 直接のアクション：Enter キーを押して開くと、QuickTime Player が起動し、シマウマの映る該当の再生位置へ自動的にジャンプします。
• 権限の仕組み：macOS のオートメーション制御権限の仕様により、アプリが初めて QuickTime Player を操作する際にはシステムの確認ダイアログが表示されます。許可を与えることで、プレイヤーの直接制御が可能になります。

ケース 2：ポッドキャストの会話位置特定（where they talk about sleep）

where they talk about sleep と入力すると、検索リストに音声ファイル The Long Run - Ep 14.mp3 がヒットします。

ケース 3：長文 PDF の条項特定（the clause about pets in the lease）

賃貸借契約書の中のペットに関する規定を検索すると、システムは契約書 Lease - 14 Elm Street.pdf の 4 ページ目を特定します。

ケース 4：コードの意図検索（code: retry with backoff）

入力が code: プレフィックスで始まる場合、DigUp は設定されたコードディレクトリを対象に検索を行います。

コード検索のロジックでは、意図検索によって関連するコード行ブロック（stretches of lines）が返されます。ユーザーが正確なシンボル名や識別子を入力した場合に限り、システムは具体的な定義行の特定を試みます。Zed のほか、DigUp は VS Code、Cursor、Xcode、Sublime Text、JetBrains シリーズなどのエディタにも対応しています。

多言語および日本語・中国語の対応状況

• 言語横断的なセマンティック能力：EmbeddingGemma 2 の事前学習は 100 以上の言語をカバーしていますが、各言語間でのパフォーマンスの均一性は完全ではありません。プロジェクト自体の評価データセットでは、現時点で主に英語、ベンガル語、アラビア語がテストされています。本文に記載している日本語の検索例は、読者向けの翻訳・参考例であり、プロジェクト本来の公式テストケースではありません。
• キーワード検索と文字認識：FTS5 キーワード層において、SQLite のデフォルトのトークナイザーは日本語、中国語、タイ語などスペースで単語を区切らない言語を単語単位で分かち書きしません。また、スクリーンショットや画像内の文字認識能力は Apple Vision フレームワークに依存しています（約 25 言語に対応）。
• 入力方式（IME）の体験改善：バージョン 0.6.1 において、日本語、中国語、韓国語などの複合入力方式（IME）で検索窓に文字を入力する際に入力文字が確定前にバラバラになってしまう不具合が修正され、スムーズな入力が可能になりました。

データを手元に残したまま、計算と保存をどう管理するか

ローカルリソースの消費やシステムアーキテクチャの設計において、DigUp は外部の常駐デーモンや独立した専用ベクトルデータベースに依存していません：

1. 単一ファイルによるローカル保存とベクトルの容量： DigUp はファイルの記録、区間のメタデータ、そして 768 次元の float16 ベクトルを、単一のローカル SQLite ファイルにまとめて保存します。例えば 2 万個のベクトルセグメントの場合、純粋なベクトルデータ自体の容量は約 30MB です（純粋なベクトルデータの保存サイズのみであり、他のメタデータやメインプログラムの実行時メモリは含みません）。検索時はこのベクトルデータをメモリ上に読み込んで直接内積演算を行うため、重厚なベクトルデータベースサービスを維持管理する必要がありません。
2. 処理完了後に自動終了するヘルパープロセス： 負荷の高いファイルスキャンと GPU によるベクトルエンコード処理は、独立した Helper プロセスが実行し、llama.cpp の Metal バックエンドを通じて Mac の GPU を呼び出します。処理待ちのキューが完了すると、このヘルパープロセスは自動的に終了して計算リソースを解放します。ユーザーが検索を実行した際には、メインプログラムが必要に応じてテキストクエリのエンコード部分のみをメモリにロードし（README の見積もりでは約 250MB）、普段は軽量なメニューバー常駐アプリとして待機します。
3. 選択したフォルダのみを読み込む設計： DigUp はユーザーが明示的に選択したフォルダの範囲内でのみファイルを読み込み、元のファイルを変更・移動したり、インデックス化した内容をアップロードしたりすることはありません。スキャン処理中、秘密鍵、証明書、パスワードファイル、隠しディレクトリ（~/.ssh など）、アプリケーションバンドルやキャッシュ、データセット風のディレクトリは自動的にスキップされます。また、iCloud に保存されていてローカルにダウンロードされていないクラウドアセットについては、自動ダウンロードを誘発しないよう配慮されています。ネットワーク通信が発生するのは、初回起動時のモデル重み取得（約 865MB）と、1 日 1 回のアップデート確認（設定でオフにすることが可能）のみであり、ユーザーアカウントの仕組みやテレメトリ収集は一切含まれていません。アプリは MIT ライセンス、基盤モデルは Apache 2.0 ライセンスで公開されており、Windows および Linux 向けのバージョンは現在計画中とされています。

手元の Mac で実際に試してみる

Apple Silicon 搭載の Mac（M シリーズチップ、macOS 14 以降）をお持ちのユーザーは、以下の手順でセットアップして試すことができます：

ステップ 1：入手とインストール

• Homebrew Cask でのインストール（Homebrew が導入済みの環境で、ターミナルから実行）：

  brew install --cask arahim3/tap/digup
  

• DMG ファイルの手動ダウンロード：プロジェクトの Releases ページ から署名済みの DigUp-0.6.1.dmg をダウンロードし、DMG を開いて DigUp を Applications（アプリケーション）フォルダにドラッグ＆ドロップします。

ステップ 2：モデルのダウンロードとローカルインポート

1. DigUp を起動すると、メニューバーに常駐します。
2. 初回起動時に EmbeddingGemma 2 のモデル重みが自動的にダウンロードされます（約 865MB。うちテキストバックボーン約 310MB、ビジョン・オーディオエンコーダ約 555MB）。

   手動でのモデルインポート： ローカルのネットワーク環境で直接ダウンロードが進まない場合は、Settings → Storage 内で Use Files… をクリックし、モデルファイルを手動で指定できます。必要なファイルは ggml-org が管理している Q8_0 量子化の重み embeddinggemma-2-Q8_0.gguf と mmproj-embeddinggemma-2-Q8_0.gguf です。Hugging Face の公式リポジトリ ggml-org/embeddinggemma-2-GGUF（固定コミット bfcd298762cc34d0357ece5ebdd31791a3a374d8）から対応する 2 つのファイルをダウンロードし、指定して DigUp の検証が通ればそのまま使用できます。

ステップ 3：スキャン対象フォルダとインデックス戦略の設定

DigUp アプリの Settings ウィンドウで、インデックスを作成したいフォルダにチェックを入れます：

• 初回試用時の推奨事項：まずはファイル数が少なめな小型のローカルフォルダを 1 つ選択し、メニューバーの進捗表示を確認しながら、インデックス作成が完了した後に検索を試してみることをお勧めします。
• 所要時間の目安：数百個程度の一般的なファイルであれば初回のインデックス作成は通常数分で完了しますが、「ダウンロード」のような巨大なフォルダの場合、初回スキャンには 1 時間程度かかる場合があると README に明記されています。
• 低電力モードと電源オプション：Mac が「低電力モード」に入るとバックグラウンドのインデックス処理は自動的に一時停止し、低電力モードが解除されると再開します。電源アダプタ接続時のみインデックスを作成するかどうかは、独立した設定項目としてオン／オフが可能です。
• スケジュールインデックス：日中にマシンのリソースを消費したくない場合は、Settings → Folders でスケジュールインデックスを有効にできます（デフォルトでは午前 1:00 から 7:00 の間に実行されるよう設定されています）。

ステップ 4：よく使う全体ショートカットキー

ステップ 5：検索クエリを入力し、ヒットした元ファイルを確認する

検索時は、いずれか 1 つの言語で探したい意図を表現します。選択した検索対象ディレクトリ内に該当するコンテンツが存在することが前提となります。

以下の英語はプロジェクトのサンプルで、日本語は翻訳した参考例です。いずれかを入力して試すことができます：

動画のシーン

zebra in a video

シマウマが映っている動画

ポッドキャストの話題

where they talk about sleep

睡眠について話している音声

PDF の条項

the clause about pets in the lease

賃貸契約書の中のペットに関する条項

コードの意図

code: retry a failed call with backoff

code: 呼び出し失敗時にバックオフをかけてリトライする処理

コード検索はあらかじめ有効化が必要： コード検索機能はデフォルトでは無効になっています。コードを検索したい場合は、まず Settings → Code で対象のリポジトリを追加し、機能を有効化した上で、普段使用しているコードエディタ（Zed、VS Code、Cursor、Xcode など）を指定してください。その後、検索窓で code: プレフィックスを付けて検索を開始します。Enter キーを押してファイルを開く前に、右側のプレビューパネルでコードブロックの内容を確認することをお勧めします。期待した結果が得られない場合は、対象ディレクトリのインデックス作成が完了しているか、未ダウンロードのクラウドファイルではないかを確認し、検索クエリの表現を少し調整してみてください。

ファイル名を忘れても、内容そのものが探す手がかりになる

DigUp はローカルファイルの探索の入り口を大きく広げてくれます。写真に写るシーン、動画のカット、長尺の録音区間、複雑な文書の条項、そしてコードのロジックに至るまで、自然言語を使って直接検索し、具体的な該当位置へジャンプできます。すべてを手元のチップの計算能力だけで処理し、個人のプライバシーを外部へ一切送信しないという前提を守りながら、Mac 上のマルチメディア資産を探すための軽量で実用的な新しいアプローチを提供してくれます。