Sidekick: macOS に常駐する llama.cpp ベースのローカル RAG エージェントをどう評価するか

Sidekick が埋めようとしている穴は「ローカル推論」と「自分のファイル」の断絶

ローカル LLM を動かす手段自体は増えた。問題は、モデルを起動できても、そのモデルが自分の Mac の中にある論文やメモを読めないことにある。Sidekick はこの断絶を、アプリ一つで埋めようとする。README は「Chat with a local LLM that can respond with information from your files, folders and websites on your Mac without installing any other software」と述べており、別途 Python 環境やベクトル DB を立てる構成を前提にしていない。対象は、研究ノート、講義資料、業務文書を外部サービスに送らずに検索と要約をしたい macOS 利用者だ。README の例では、歴史論文を書く学生がアステカとスペイン兵の相互作用について質問し、回答に引用元のページ番号が付き、参照をクリックすると該当論文がビューアで開く流れが示されている。

内蔵 llama.cpp と expert 単位の RAG という構成

推論はアプリに同梱された llama.cpp バックエンドが担当し、Qwen3.5 のような GGUF 形式のモデルを扱うと README は説明している。情報源の管理単位は expert と呼ばれる。expert ごとにファイル、フォルダ、ウェブサイトを登録でき、有効化した expert の範囲から Sidekick が必要に応じて資料を取得する。README はこの仕組みを RAG と明記し、「you can theoretically put unlimited resources into each expert」としているが、これは理論上の話であり、実際の検索品質と処理時間はモデルとハードウェアに依存する。入力欄にファイルをドラッグする一時的な渡し方も用意されている。関数呼び出しは逐次ループで結果が得られるまで繰り返す方式で、README の例では Nvidia の 2025 年第 3 四半期の財務指標を計算させる際に 27 回のツール呼び出しが発生し、CSV を保存して結果を提示したと記載されている。

導入はビルド済みアプリか、Xcode でのビルドか

README とリポジトリの構造から確認できる導入手順は二通りある。配布ページからアプリを取得する方法と、リポジトリを clone して Xcode でビルドする方法だ。後者の場合、Swift と SwiftUI で書かれた macOS プロジェクトを開き、ビルドして起動する。モデルは GGUF 形式のファイルを別途用意し、アプリ内で読み込ませる。API 経由で使う場合は、設定画面でプロバイダを選び API キーを入力する。README が挙げるプリセットは OpenAI、Anthropic、Google AI Studio、DeepSeek、Groq、MiniMax、Mistral、xAI などで、OpenAI 互換のエンドポイントであれば同じ経路で扱えるとされている。関数呼び出しや Deep Research を使う場合、どのモデルがツール呼び出しに対応しているかを事前に把握しておく必要がある。ここは README だけでは判断できない部分で、モデル側の対応状況を自分で確認するしかない。

エージェント機能は便利だが、検証コストを伴う

関数呼び出し、Deep Research、メモリ、Canvas、画像生成が README で紹介されている。Deep Research は「reading 50-80 webpages」と記載され、長距離の調査タスクを想定した実装だと分かる。ただし、これらの機能はモデルの能力に強く依存する。27 回のツール呼び出しが成功した例が README にある一方で、ローカルの小型モデルで同じ精度が出る保証はどこにもない。メモリ機能は会話をまたいで情報を保持するが、保持された内容が誤っていた場合の訂正手段や、保存範囲の詳細は README からは読み取れない。Canvas はテキストの選択的な編集を促せるが、生成物の最終確認は人間が行う前提だ。エージェント機能を業務に組み込むなら、出力の検証工程を別途設計する必要がある。

向かないケース: クロスプラットフォーム、安定版志向、大規模共有

Sidekick は macOS ネイティブアプリであり、Linux や Windows では動かない。チーム全員が同じ環境を使える前提がないなら、導入は現実的でない。リリースは 1.0.0-rc.18 のようなリリース候補版が並んでおり、1.0.0 の正式版はまだ出ていない。バージョン番号から判断する限り、API やデータ形式が今後変わる可能性を織り込んでおくべきだ。また、expert に登録したフォルダの内容がローカルに留まるとしても、複数人で同じ expert 定義を共有する仕組みは README には見当たらない。共有ナレッジベースとして運用したいなら、別のアーキテクチャを検討した方がよい。

比較対象としての Ollama + Open WebUI との違い

同じ「ローカル LLM を自分の文書に接続する」目的では、Ollama でモデルを動かし Open WebUI をフロントエンドにする構成が一般的だ。この構成は Docker 上で動かすことが多く、ブラウザからアクセスする。Sidekick との差はアプリの性質にある。Sidekick は macOS のネイティブアプリとして完結し、ファイルのドラッグ、連絡先からのメール下書き作成、画像生成の自動判別といった OS 連携を持つ。一方で、サーバとして常駐させて複数人で使う、Linux の GPU サーバで推論する、といった使い方は Sidekick の設計から外れる。どちらが優れているかではなく、単一 Mac 上で閉じた作業をしたいのか、共有サービスとして立てたいのかで選ぶべきだ。

MIT ライセンスとモデル重みのライセンスは別物

リポジトリのライセンスは MIT と明記されている。アプリのコードを改変し、再配布することはライセンス上可能だ。ただし、Sidekick 自体はモデルを同梱していない。利用者が読み込む GGUF モデルのライセンスはモデルごとに異なり、Qwen 系や Llama 系では商用利用の条件が個別に定められている。業務利用を検討するなら、アプリのライセンスではなく、使うモデルのライセンスを確認する作業が先に来る。また、OpenAI 互換 API を併用する場合、送信されるデータは各プロバイダの規約に従う。ローカル完結を売りにしたアプリでも、API キーを設定した瞬間にその前提は崩れる。

導入前に確認すべきこと

最初に確認するのは、自分の Mac のメモリ量と、動かしたい GGUF モデルのサイズの関係だ。README はモデルの推奨スペックに触れていないため、ここは自分で試すしかない。次に、expert に登録するフォルダの範囲を決める。広げすぎると検索対象が増え、回答の根拠が薄まる可能性がある。関数呼び出しを使うなら、連絡先やメールクライアントへのアクセス権限をどこまで与えるかを決めておく。最後に、リリース候補版であることを踏まえ、設定や会話履歴のバックアップ手段を確認する。これらは README やリポジトリから直接読み取れない部分を含むため、実際に小さいフォルダで試してから範囲を広げるのが現実的だ。

編集部の結論

Sidekick が向くのは、macOS 上で完結する文書検索と要約を必要とし、モデルファイルの管理やビルドを自分で引き受けられる利用者だ。逆に、Linux や Windows が混在するチーム、クラウド側でモデルを差し替えたいだけの用途、リリースチャネルの安定性を重視する本番導入には向かない。導入前に確認すべきは、自分の Mac で動かせる GGUF モデルのサイズ、expert に登録するフォルダの権限、そして 1.0.0-rc.18 というリリース候補版の位置づけである。MIT ライセンスなので改変と再配布は可能だが、モデル重みのライセンスは別に確認する必要がある。

公式情報源

1. johnbean393/Sidekick on GitHub
2. License: MIT
3. Project website
4. README
5. Releases