OpenJarvisでローカルAIアシスタントを作る完全手順

OpenJarvisとは、ローカル環境で動く個人用AIエージェントを構築するためのフレームワークである。

クラウドの対話AIは便利ですが、メールやカレンダー、手元の文書を読ませようとすると「データを預けていいのか」という壁にぶつかります。この記事で扱うのは github.com/open-jarvis/OpenJarvis（末尾の参考資料にリンクがあります） で公開されているオープンソース版で、名前の似た別サービスとは無関係です。OpenJarvisはこの壁を逆向きに解く設計で、推論そのものを自分のPC上のモデルで回し、必要なときだけ外部に出る形を狙っています。ただし macOS・Linux・WSL2 向けの現行Bashインストーラは、クラウドAPIキーが環境にあればクラウド側を優先候補にする指定で設定を書きます。Native Windows版を含むほかの導入経路も含め、実際に何が既定になるかは生成された設定を見て確認してください。Ollamaを推論エンジンに据え、メール・カレンダー・ローカル文書をつないでいけば、推論や文書の中身を手元で処理できる「AI秘書」を一から組めます。

実際に手を動かして詰まりやすいところを、本記事では3つに分けて扱います。インストールは通ったのにモデルが選べない、メール連携の認証画面で止まる、どのエージェントを使えばいいか分からない、の3点です。この記事では、OpenJarvisをインストールしてOllamaにつなぎ、データソースを接続してMCPでツールを足すところまでを、実際に打つコマンドの順番どおりに追いかけます。

OpenJarvisの導入でつまずく具体ポイント

本記事では、1行で済むインストールそのものより、その後のモデル設定とデータ接続を重点的に扱います。山場と見ているのは、OllamaとのつなぎこみとデータソースのOAuth認可です。ここを飛ばして「とりあえず動かす」と、後から設定をやり直す羽目になります。

本記事では、導入時の問題を次の3系統に分けて解説します。まずOllamaは入っているのに、OpenJarvis側からモデルが見えない・選べないケース。次にメールやカレンダーを連携しようとして、認可フローの途中で止まるケース。そして、内蔵エージェントが複数あるためにどれを呼べばいいか分からず、結局単純な対話しか使えていないケースです。

この記事は、この3つを順に解消する順番で組んでいます。先にOllama連携を確実に通し、次にデータソースをつなぎ、最後に用途に合うエージェントを選ぶ。逆順でやると、応答が返らないときに推論エンジン側の問題か接続側の問題かを切り分けられなくなります。

「動くまで」より「データ接続」を実運用の山場として扱う

OpenJarvisを単なるローカルチャットとして使うだけなら、インストールしてモデルを引いて質問を投げれば終わりです。とはいえ、それだけならOllama単体やCline、Open WebUIでも事足ります。OpenJarvisを選ぶ意味は、メール・カレンダー・ローカル文書といった「自分のデータ」をエージェントに読ませて、朝の要約や調査を任せられる点にあります。

データ接続では、OAuth認可や対象フォルダの指定など、確認する項目が増えます。OAuth連携は外部サービスの認可画面を経由するため、ブラウザ側の挙動やトークンの保存先が絡みます。ローカル文書のインデックス化も、対象フォルダの指定を間違えると検索に何も引っかかりません。本記事が山場を2つ（Ollama連携とデータソース接続）に置いているのは、この2つが実運用の分かれ目になるからです。

ローカル完結のつもりが外部送信が混じる落とし穴

「ローカルで動く」と聞くと、データが一切外に出ないと考えがちです。ここは正確に整理しておく必要があります。OpenJarvisの推論エンジンをOllamaなどローカルのものにしている限り、モデルへの入力は手元で処理されます。ただし、外部へ出る経路はいくつもあります。クラウドのモデルを推論先に選ぶ、Web検索や外部APIのコネクタを使う、メールやカレンダーを連携する、読み上げや音声入力にクラウドのTTS/STTを使う、外部のMCPサーバーやエージェントランタイムを足す。有効にした機能の分だけ送信先が増えるので、ここに挙げたものが全部だと思わず、使う機能ごとに確認してください。

つまり「外部の推論APIへ送らない」状態は、ローカルエンジンを使い、外部接続系のツールをオフにしている前提で初めて成り立ちます。プライバシーを理由にOpenJarvisを選ぶなら、どの接続が外に出るのかを把握したうえで構成するのが前提条件。この線引きは後半のデータソース接続のところでもう一度具体的に確認します。

もう1つ、機能とは別に押さえておきたい分析・記録の仕組みが4つあります。名前が似ていて紛らわしいので、分けて整理します。外部へ送るのはインストール時分析と [analytics] の2つで、[telemetry] と [traces] は端末内に保存されます。

1つめはインストール時の分析。公式のBashインストールスクリプトは、導入の各段階で匿名のイベントを外部の集計サービス（PostHog）へ送ります。送られるのはOS・アーキテクチャ・インストーラのバージョン・段階名・所要時間・終了コードと、端末側に保存される匿名IDです。少なくとも現行のBash版スクリプトには、この送信を止めるフラグがありません（PowerShell版は別途確認が要ります）。

2つめは実行時の分析。設定に [analytics] があり、既定で有効です。アプリの起動、最初のチャット、セッション終了時の集計値、機能やツールの使用、モデルの変更、コネクタの認証といったイベントが、同じくPostHogへ送られます。止めるなら設定で明示的に無効化します。

# 実行時の外部分析を止める
[analytics]
enabled = false

# こちらはローカル保存の記録（外部送信ではない）
[telemetry]
enabled = true

# エージェントの詳細な処理トレースを端末内にも残さない場合
[traces]
enabled = false

3つめはローカル記録の [telemetry]。既定で有効ですが、推論の所要時間・トークン数・使用モデルなどを手元のSQLiteに記録するもので、公式は外部には送らないと明記しています。[analytics] とは別の仕組みなので混同しないでください。

4つめも端末内の記録で、[traces] です。エージェントが処理を進める過程を traces.db に残す仕組みで、公式アーキテクチャでは学習にトレースを使う土台として位置づけられています。[telemetry] が所要時間やトークン数といった指標を持つのに対し、こちらは処理の中身がより詳しく残る可能性があります。外部送信ではありませんが、機密性の高いデータを扱うなら見落とせません。既定値は公式ドキュメントと現行コードで記載が食い違っている（ドキュメントは無効、コードは有効）ので、記録を残したくないなら [traces] enabled = false を明示しておくのが安全です。

前の2つの外部分析について、公式はプロンプト本文・モデルの出力・メールの中身・ファイルパスなどを送信しないと説明しています。[telemetry] と [traces] は端末内に保存され、外部には送られません。それでも「本文が手元に残る」ことと「外向きの通信がゼロ」は別の話ですし、通信がゼロでも端末内には詳しい記録が残りうる、という点も別に押さえておく必要があります。

なお、公式Bashインストーラ固有の匿名イベント送信を避けたいなら、リポジトリから手動で導入する経路があります。ただしこれは「通信ゼロ」ではありません。クローンも依存パッケージの取得もモデルのダウンロードも通信を伴いますし、手動で入れても [analytics] を無効にしなければ実行後のイベントは外へ出ます。さらにCLIには更新確認もあります。ask や memory などの実行時にPyPIの https://pypi.org/pypi/openjarvis/json を参照し、結果は24時間キャッシュされます。止めるには設定で [updates] auto_update = false にするか、環境変数 OPENJARVIS_NO_UPDATE_CHECK を立てます。つまり本当にオフラインで運用するなら、ソース・依存関係・モデルを別環境で事前に取得したうえで、実行前に [analytics] enabled = false と更新確認の無効化をどちらも設定することになります。デスクトップ版を使う場合は、そちらの自動更新確認についても別途無効化するか、ネットワーク側で遮断する必要があります。

OpenJarvisの全体像と前提環境

OpenJarvisは、Stanford系の研究室（Hazy Research / Scaling Intelligence Lab）が公開したパーソナルAIのフレームワークです。公式の説明によれば、ライセンスはApache 2.0のオープンソースで、利用に費用はかかりません。設計の中心は「local-first」、つまり推論を手元で動かすことを既定に置く方針です。

現行のArchitecture Overview本文では、Intelligence / Engine / Agentic Logic / Memory / Learning という5つの抽象で整理されています（公式のリリース資料では Agents / Tools & Memory という表記も使われており、資料間で揺れがあります）。ここでは導入作業を追いやすくするため、操作上の役割を4つの層に簡略化して説明します。1つめが推論エンジン層で、ここをOllamaに差し替えてローカルのLLMを動かします。2つめが複数の内蔵エージェント。単純な対話から多段の調査まで、用途に応じた振る舞いが用意されています。3つめがツールやスキルの層で、ここにMCPサーバーを足して機能を拡張します。最後がデータソース接続の層。メール・カレンダー・ローカル文書などをエージェントの入力源にする部分です。

この4層が分かれているおかげで、「モデルだけ差し替える」「データ接続だけ増やす」といった部分的な変更がしやすくなっています。クラウド型のアシスタントが提供元の用意した範囲でしか動かないのに対し、OpenJarvisは各層を自分で選び直せる点が違いです。

推論エンジンを差し替えられる設計

OpenJarvisは推論バックエンドを1つに固定していません。一般的なNVIDIAコンシューマーGPU環境ではOllamaが推奨されますが、実際にどれが既定になるかは検出したハードウェアや、環境に用意されているクラウドAPIキーによって変わります。公式ドキュメントでは、Ollamaのほかに vLLM・SGLang・llama.cpp・MLX といったバックエンドにも対応すると説明されています。これは「最初はOllamaで気軽に始め、後から高速なバックエンドへ移る」という運用ができることを意味します。

ローカルとクラウドの境界も、この層で決まります。エンジンをローカルのOllamaにしている限り、入力は手元のモデルで処理される。一方で、設定でクラウドのモデルを推論先に指定すれば、その経路は外部のAPIを使います。どちらを既定にするかは設定ファイルで切り替えるので、プライバシー要件に合わせて選べる作りです。

ローカルでのOllama活用そのものの土台については、姉妹サイトの実測記事MTPでローカルLLMは本当に速くなるか（RTX 5080実測）が、構成によって速度がどう変わるかを扱っています。推論エンジンの選び方を詰める際の参考になります。

必要なもの（Python・Ollama・環境の目安）

動かす前にそろえるものは、それほど多くありません。公式のサポート範囲はPython 3.10から3.13までで、pyproject.toml も同じ範囲を宣言しています。3.14以降は公式には未対応です。ソースからビルドする際にRust拡張のビルドを通す回避策（maturin の実行前に PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 を設定する）は案内されていますが、これは依存関係全体が3.14で動くことを保証するものではありません。対応OSはmacOS・Linux・Windowsで、WindowsにはPowerShellのワンライナーが用意されているため、WSL2を経由しなくても導入できます。

推論をローカルで回す以上、モデルを動かすだけのメモリとディスクの余裕は要ります。GPUがあると応答が速くなりますが、必須かどうかや最低限のメモリ量といった具体的な数値は、モデルの大きさや量子化で大きく変わるため、ここでは断定しません。エンジンとモデルを選ぶ段階で、引こうとしているモデルの実行時サイズ（重みにコンテキスト分を足した実際の占有量）が手元のVRAMに収まるかを確認する、という進め方が現実的です。収まらない場合でも、一部をシステムRAMへ退避して動くことがあります。ただしシステムRAMまで足りない場合や、モデルとバックエンドの組み合わせによっては読み込みに失敗する可能性もあります。

macOS・Linux・WSL2向けの公式Bashインストーラは、Ollamaの導入・起動と軽量モデルの取得まで行うため、この経路ではOllamaの事前導入は必須ではありません。Native Windows版は公式資料のあいだで処理内容の説明に差があるので、Python・Git・Ollamaといった前提は最新のWindows向けガイドで確認してください（公式は現時点で、WSL2をよりスムーズな経路として案内しています）。いずれの場合も、手元にすでに使いたいモデルがある場合や手動で入れる場合は、先にOllamaを動く状態にしておくと後の連携設定が短くなります。Ollama自体のインストールは公式サイトの手順に従えば比較的短い手順で済みます。導入後に次のコマンドでモデルを1つ引いておくと、OpenJarvis側の動作確認がすぐにできます。

# Ollama が動くか確認し、軽量モデルを1つ取得しておく
ollama --version
ollama pull llama3.1:8b

ここで引くモデルは何でも構いませんが、最初は小さめのモデルにしておくと、OpenJarvisの設定が正しいかどうかを切り分けやすくなります。大きいモデルでいきなり試すと、設定ミスで止まっているのか、CPUへの退避で単に遅くなっているだけなのかが分かりにくいからです。

インストールとOllama連携の手順

ここが1つめの山場です。OpenJarvisを入れて、Ollamaにつなぎ、最初の応答を出すまでを順に進めます。コマンドは実際に打つ順番どおりに並べているので、上から順に実行してください。

インストールとOllamaの自動検出

OpenJarvisの導入は、公式が用意するインストールスクリプトを使うのが手早い方法です。macOS・Linux・WSL2では、ターミナルで次のワンライナーを実行します。

# macOS / Linux / WSL2
curl -fsSL https://open-jarvis.github.io/OpenJarvis/install.sh | bash

WindowsではPowerShellからのインストールが案内されています。WSL2を経由しなくても導入できます。

# Windows (PowerShell)
irm https://open-jarvis.github.io/OpenJarvis/install.ps1 | iex

リポジトリを直接クローンして入れる方法も用意されています。ブラウザ版をまとめて立ち上げるなら ./scripts/quickstart.sh、CLI だけを開発環境として使うなら uv sync からの手順が公式Installationページに載っています。スクリプトのURLや手順は更新されることがあるため、最終的には公式のInstallationページの記載に合わせてください。

インストールが終わると、jarvis というCLIコマンドが使えるようになります。まずバージョンや状態を確認しておきましょう。OpenJarvisは環境を見て、Ollamaが入っていればそれを推論エンジンの候補として扱います。検出は起動時にも行われるので後から入れても認識されますが、先にOllamaとモデルを用意しておくと jarvis init の直後にそのまま最小の応答確認まで進めるため、手戻りが少なくなります。

jarvis --help
jarvis --version

# 背景で続くRust拡張のビルドやモデル取得の状態を見る
jarvis doctor

インストーラが戻ってきても、Rust拡張のビルドや既定モデルのダウンロードがバックグラウンドで続いていることがあります。jarvis doctor がその状態を表示するので、メモリ機能などを使う前にここで完了を確かめておくと、原因のはっきりしない失敗を避けられます。なお jarvis doctor 自体も前述の更新確認の対象なので、通信を切りたい場合は先にそちらを無効化してください。

ここでコマンドが見つからないと言われる場合は、インストールスクリプトが追加したパスがまだシェルに反映されていないことが多いです。ターミナルを開き直すか、シェルの設定ファイルを読み込み直してから再度実行してください。

config.tomlでモデルと推論エンジンを指定する

OpenJarvisの設定は、ホームディレクトリ配下の設定ファイルに集約されます。場所は ~/.openjarvis/config.toml です。このファイルは現行のBashインストーラの実行時にも生成されます。Native Windows版など他の経路で入れた場合や、ハードウェアを検出し直して設定を作り直したい場合は jarvis init を実行します。GPUベンダー・VRAM・CPU・RAMを自動検出して、その環境に合った既定値を書き込んでくれます。

# ハードウェアを検出して ~/.openjarvis/config.toml を生成する
jarvis init

# すでにある設定を上書きして作り直す場合
jarvis init --force

生成されたファイルをエディタで開いて、使う推論エンジンとモデルを確認・調整します。

推論エンジンをOllamaにし、引いておいたモデルを既定にする最小の設定はこの形です。キー名やセクション構成はバージョンで変わることがあるため、生成された設定ファイルの中身と公式のConfigurationページを照らし合わせて調整してください。

# ~/.openjarvis/config.toml （最小構成）
[engine]
default = "ollama"          # 既定の推論バックエンド

[engine.ollama]
host = "http://localhost:11434"

[intelligence]
default_model = "llama3.1:8b"   # ollama list に出ている名前をそのまま書く
# preferred_engine = "ollama"   # [engine] default より優先したいときだけ指定

エンジンの選択には優先順位があります。CLIで明示したフラグが最優先、次に intelligence.preferred_engine、その次に engine.default、どれも無ければ起動時に見つかった正常なエンジンが使われます。ポイントは、default_model の名前が、Ollama側で ollama pull 済みのタグと一致していること。タグが少しでも違うと「モデルが見つからない」系のエラーになります。ollama list で手元にあるモデル名を確認し、その文字列をそのまま貼るのが確実です。

クラウドのモデルを推論先にすることもできますが、その場合は入力が外部のAPIへ送られます。手元で完結させたいなら、[engine] default をローカルのエンジンにしたうえで、intelligence.preferred_engine にクラウド側を書かない・CLIで外部エンジンを明示しない、の2点も合わせて守る必要があります。前述のとおり優先順位はCLIフラグ、preferred_engine、engine.default の順なので、既定を書くだけでは経路は塞げません。

最初の応答を出す（最小の動作確認）

設定ができたら、いちばん簡単な問い合わせで応答が返るかを確かめます。OpenJarvisのCLIから質問を投げる基本形はこれです。

# 既定エンジン・既定モデルで質問する
jarvis ask "今日のタスク管理に役立つ考え方を3つ挙げて"

特定のモデルを明示して投げたい場合は、モデルを指定するオプションを付けます。複数のモデルを引いてあるときに、設定を書き換えずに切り替えられるので便利です。

# モデルを明示して質問する
jarvis ask -m llama3.1:8b "OpenJarvis の設定ファイルはどこにある？"

ここで応答が返ってくれば、OpenJarvisとOllamaの連携は成立しています。逆に、ここで止まる・エラーになる場合の原因は、後半の「動かないときの分岐」でOllama未検出やモデル名不一致として扱います。まずはこの最小の応答が出る状態を作るのが、データソース接続に進む前の合格ラインです。

応答が遅いと感じたときは、引いているモデルが手元のVRAMに対して大きすぎる可能性があります。ただし「重みのサイズが大きいほど遅い」という単純な関係ではありません。当サイトの検証環境で、OpenJarvisが推論を任せるOllama側を直接計測しました。条件は次のとおりです。Ollama 0.30.7、RTX 5060 Ti 16GB（Ollamaが自動選択。同一マシンのRTX 5080は未使用）、/api/generate に同じ日本語プロンプトを stream=true で投げ、temperature 0・num_predict 128・コンテキスト32768 に固定。各モデルとも直前に keep_alive=0 でアンロードし、読み込まれていない状態（コールドスタート）から計測しました。「最初の出力チャンクまで」はリクエスト送信から、中身のある最初のチャンク（推論過程の出力を含む）を受け取るまでの実測時間です。生成速度は Ollama が返す eval_count と eval_duration から算出し、配置は ollama ps の表示を使いました。

コンテキスト分の上乗せはKVキャッシュの構成によってモデルごとに差が大きく、3行目のように、ollama ps の表示上は増分がほとんど見えない例もあります。

「最初の出力チャンクまで」は、その大半がモデルの読み込みです（この計測ではそれぞれ11.2秒・23.0秒・22.3秒がロード）。モデルがメモリに保持されている間の次回問い合わせでは、このロード分の待ちはなくなるか大幅に短くなります。ただしプロンプトの評価と最初の出力の生成には引き続き時間がかかりますし、keep-alive の期間を過ぎたり明示的にアンロードしたりすれば、またロードから始まります。また各モデル1回ずつの計測なので、生成速度には実行ごとのぶれがあります。別ラウンドでは qwen3:8b が74.9 tok/s、qwen3.5:35b-a3b が40.1〜44.3 tok/s の範囲で動きました。桁の比較には使えますが、小数点以下を厳密な差として読まないでください。

読み取れることは3つあります。1つめは、実行時サイズは重みより大きくなること。重み5.2GBのモデルもコンテキストを確保すると実行時は10.0GBになり、重み12.6GBのモデルは20GBまで膨らんで16GBに収まらず、CPUへの退避が起きました。2つめは、少なくとも今回計測した3モデルでは、VRAMに収まらなくても読み込み自体は成功し、CPUへの退避と速度低下として現れたこと。システムRAMまで足りない場合や、バックエンドとモデルの組み合わせによっては読み込み失敗も起こり得ます。3つめは、退避しているかどうかだけでは速度が決まらないことです。退避の割合がより大きいMoEモデル（39%がCPU）が、退避の小さいdenseモデル（27%がCPU）の3倍の速度で生成しています。MoE構造によるアクティブパラメータ数の違いが一因になった可能性があります。今回の結果では、アクティブパラメータ数とCPUへの退避割合が、速度差に影響した要因の一部と考えられます。実際にはメモリ帯域や量子化方式、実装、コンテキスト長なども効くため、この2つだけで説明がつくわけではありません。

なお3つのモデルは重み・実行時サイズ・配置・MoE/denseが同時に違うため、この計測は退避だけの寄与を分離したものではありません。同一モデルでコンテキストや配置だけを変えた対照は取っていない点は差し引いて読んでください。

まずは小さいモデルで通し、必要に応じて大きくしていくのが安全という方針は変わりません。ただし切り分けるときは、重みのGB数だけでなく、コンテキスト長を含めた実行時サイズと、モデルがMoEかdenseかを見てください。

データソース接続の設定（メール・カレンダー・ローカル文書・MCP）

OpenJarvisが「ただのローカルチャット」と一線を画すのは、ここから。手元のメール、カレンダー、ローカルの文書フォルダ、さらにMCP経由で足した外部ツールを、エージェントが必要に応じて参照できるようになります。朝の予定をまとめさせたり、自分のメモ群から関連情報を引かせたりといった「秘書らしい」動きは、データソースをつないで初めて成立する仕組みです。

接続先は大きく分けて、ローカルにある文書（自分のPC内のフォルダ）、認証を伴う外部サービス（メール・カレンダー等）、そしてMCPサーバー経由で追加するツールの3系統です。前の2つは外部送信の有無がはっきりしていて、ローカル構成では文書内容を手元で処理でき、メール・カレンダーはサービスとの通信を伴います。MCPは接続の方式なので、外に出るかどうかはそのサーバーが何にアクセスするか次第。設定の前に接続ごとに確認しておくと事故が減ります。

ローカル文書のインデックスと検索

まず、文書の中身を外部サービスへ送らずに扱える接続先がローカル文書です。自分のメモやドキュメントを置いたフォルダをOpenJarvisに教えると、内容を検索可能な形にインデックス化し、質問に応じて関連箇所を引いてきます。いわゆる検索拡張（retrieval）の仕組みで、推論と埋め込みをローカルに固定しておけば、文書本文は端末内で処理できます。ただし前述の実行時分析や更新確認による別経路の通信は、これとは別に残ります。

ローカル文書は設定ファイルにフォルダを書くのではなく、CLIからインデックスを作る形です。対象のディレクトリやファイルを jarvis memory index に渡すと、中身を検索できる形に取り込みます。

# フォルダごと取り込む
jarvis memory index ./docs/

# ファイル単体でも指定できる
jarvis memory index ./notes.md

# 分割の粒度を調整する場合
jarvis memory index ./data/ --chunk-size 256 --chunk-overlap 32

取り込んだ内容の検索バックエンド（SQLite / FAISS 等）は config.toml のストレージ設定で選べます。標準のSQLiteは永続保存ですが、FAISSはインメモリで再起動時に失われる点に注意してください。インデックス作成の処理は、対象を指定したときに走ります。文書量が多いと初回のインデックス作成に時間がかかりますが、埋め込みまでローカルのモデルで行う設定なら、インデックス化のために文書の中身を外部サービスへ送る必要はありません（埋め込みモデルを初めて取得する場合は、その分の通信が入ります）。ただし実行時分析や更新確認が有効なら、それらの通信は別に発生します。更新した文書を反映させたいときは、再度インデックスを走らせる運用になります。

MCPサーバーを足してツールを増やす

既製の連携に無いツールを使いたいときの拡張口がMCP（Model Context Protocol）。外部のツールやデータソースを、AIから呼べる標準化された形でつなぐ仕組みで、OpenJarvisはこれをネイティブにサポートしています。

OpenJarvis can extend agent capabilities by connecting to external Model Context Protocol (MCP) servers. （OpenJarvis 公式ドキュメント user-guide/mcp-external-servers より）

有効化は config.toml のMCP用セクションで行います。enabled をオンにし、接続したいMCPサーバーの定義を servers に書きます。ここはTOMLのテーブルではなく、サーバー設定のリストをJSONで文字列として渡すフィールドである点に注意してください。

[tools.mcp]
enabled = true
servers = '''[{"name": "filesystem", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]}]'''

ここで注意したいのが、コネクタとMCPの使い分け。メールやカレンダーのような広く使われるサービスは、後述の認証付きコネクタで繋ぐのが手早い。一方、自分で用意した独自のツールや、特定のAPIを叩く処理を足したいときはMCPが向きます。既製コネクタがあるサービスならそちらが手早く、無い場合や独自ツール・特定APIを足したい場合はMCPが向きます。両者は排他ではなく、同じ対象に両方の口があることもあります（ローカルファイルは jarvis memory index でも、filesystem 系のMCPサーバー経由でも扱えます）。認証や運用の手数が少ないほうを選ぶ、という判断で十分です。

MCPサーバーが外部のAPIを呼ぶ種類のものなら、当然そのMCP経由でデータは外に出ます。ローカルファイルを扱うだけのMCPサーバーなら手元で完結。MCPを足すときは「そのサーバーが何にアクセスするか」を1つずつ確認するのが安全側の運用です。

メール・カレンダー連携と認証で気をつける点

メールやカレンダーをつなぐと、朝の要約や予定の整理にエージェントが本領を発揮します。接続は jarvis connect にコネクタ名を渡す形です。Google 系は1回の認可で Gmail・カレンダー・タスク・連絡先・Drive などがまとめて繋がります。

# Gmail・カレンダー・タスクを1回のOAuthで接続する
jarvis connect gdrive

実行するとブラウザが開き、アクセスを許可する流れになります。許可するスコープ（どこまで読ませるか）はサービス側の同意画面で決まるので、ここで内容を確認してから承認してください。接続できるコネクタはGmail・Google カレンダー・Google Drive・Obsidian・Slack・Notion など多数あり、名称は公式のコネクタ一覧で確認できます。

朝のブリーフィングを使いたい場合は、プリセットを指定して初期化しておくと必要な構成がまとめて入ります。ここで一点つまずきやすいのが音声です。読み上げ音声の生成にはクラウドのTTS（Cartesia または OpenAI）を使う構成があり、その場合はAPIキーが要ります。キーを用意しないなら --text-only を付けてテキストだけ出力します。

# プリセットを指定して初期化する（環境に応じて -mac / -linux / -minimal）
jarvis init --preset morning-digest-minimal
jarvis connect gdrive

# 音声つきで生成する（クラウドTTSのAPIキーが必要）
CARTESIA_API_KEY="sk_car_..." jarvis digest --fresh

# 音声を使わずテキストだけ出す
jarvis digest --fresh --text-only

音声を使う構成では、読み上げ用のテキストがTTSの提供元へ送られます。これをやめたいなら --text-only を選んでください。ただし止まるのはTTSへの送信だけで、メールやカレンダーを情報源に使う以上、それらのサービスとの通信は別に発生します。

つまずきやすいのはこのあたりです。認証ウィンドウが開かない、リダイレクトが返ってこない、トークンの期限切れで急に連携が切れる、といった症状は後半のトラブル分岐で扱いますが、まず押さえるべきは「これらの連携は外部サービスと通信する」という前提。ローカル文書とは性質が違います。

ローカルでの推論性能そのものを底上げしたい場合は、モデルの選び方や量子化、推論手法の影響も無視できません。姉妹サイトでは推論の高速化手法を実機で検証しており、たとえば先に挙げたRTX 5080でのMTP実測記事では、構成によって速度がどう変わるかを数値で扱っています。OpenJarvisで使うモデルの土台を詰めるときの参考になります。

エージェントタイプとプリセットの使い分け

OpenJarvisには複数の内蔵エージェントがあります。単発対話の simple、ツールを組み合わせて多段で進める orchestrator、Thought-Action-Observation 形式で理由づけを明示する native_react、コード実行を絡める native_openhands、再帰的に問題を分解する rlm、外部のコーディングランタイムを使う openhands や claude_code、継続実行向けの operative とその長期版 monitor_operative などです。

数と名前には注意が要ります。Agentsページの概要表には opencode が掲載されていますが、同ページ下部の AgentRegistry.keys() の例には含まれておらず、代わりに react（native_react のエイリアス）が入っています。公式ページの中でも記載が一致していません。既定にするエージェントは config.toml の [agent] default_agent で指定しますが、Configurationリファレンスが候補として明示しているのは simple / orchestrator / react / operative / monitor_operative です。使える名前は現行のAgentsページで確かめてください。

なお Morning Digest と Deep Research は、READMEでは built-in agent として紹介されている一方、Configurationリファレンスの default_agent 候補には含まれていません。本記事では、専用のコマンドやプリセットから使う機能として扱います。ポイントは「タスクの重さに合わせて選べる」こと。

軽い対話から多段オーケストレーションまで

ちょっとした質問や、1往復で終わる作業なら、軽量なエージェントで十分です。逆に「複数の情報源を横断して調べ、結果をまとめる」ような多段の作業では、調査特化のエージェントや、ツールを自動で選ぶ orchestrator が向きます。重いエージェントは内部で何度もモデルを呼ぶぶん、ローカルモデルの速度がそのまま体感に効いてきます。手元のマシンが非力なら、まず軽いエージェントで流れを掴むのが現実的。

設定では、どのエージェントタイプを既定にするかを指定できます。

[agent]
default_agent = "simple"

用途が固まっているなら既定を決め打ちし、状況に応じて切り替える運用が回しやすいでしょう。

用途別の選び方（朝のブリーフィング・調査・コード実行）

毎朝の予定とメールをまとめてほしいなら、morning digest系のプリセット。カレンダーとメールを接続した状態で動かすと、その日の段取りを一覧で返してくれます。一方、特定のテーマを腰を据えて調べたいときは調査特化のエージェントが適任。Web検索やローカル文書を組み合わせ、段階的に情報を集める動きをします。ただしWeb検索を含む構成では、前述のとおり検索クエリが外部に出ます。手元で完結させたいなら、情報源をローカル文書だけに絞った構成にします。

コードを扱う作業なら、コード実行を含むプリセットが候補。ただしコード実行は環境に手を入れる種類の動作なので、何を許可するかは慎重に。「朝の要約は自動・継続実行、調査は手動で都度起動」のように、エージェントごとに起動のタイミングを変えると、無駄な動作を抑えながら必要なときだけ働かせられます。

動かないときの分岐（症状→原因→対処）

ここまでの設定で動かない場合の原因を、本記事では4つに分類します。Ollamaが見つからない、モデル名が一致しない、モデルが大きすぎてCPUへ退避している、データソースやMCPの接続。この順に当たっていくのが早い。

Ollama・モデル周りのエラー

まず確認したいのが、Ollamaが見つからない・モデル名が一致しないケース。jarvis ask を投げてもエンジンに繋がらない、あるいは「モデルが見つからない」と返るパターンです。

まず確認するのは、Ollama自体が起動しているか。次のコマンドで応答があるかを見ます。

ollama list

ここに目的のモデルが出てこなければ、config.toml で指定したモデル名と、実際に ollama pull したモデル名がずれている可能性が高い。タグまで含めて正確に一致させる必要があります。llama3.1:8b と書いたのに引いたのが別タグ、という取り違えはよくある原因。

モデルが大きすぎる場合の症状は、多くの人が思うほど分かりやすくありません。当サイトの検証環境（RTX 5060 Ti 16GB）で計測した範囲では、実行時24GBのモデルを指定しても読み込み自体は失敗せず、Ollamaが入りきらない分をCPU側へ退避させて応答を返しました。今回の検証では「落ちる」のではなく「遅くなる」形で現れました。ただし落ち幅はモデル次第です。前掲の計測では、退避が起きた dense の codestral:22b が13.3 tok/s だった一方、退避の割合がさらに大きい MoE の qwen3.5:35b-a3b は43.9 tok/s を保っていました。退避の有無だけでなく、そのモデルが推論のたびに何パラメータ動かすかが体感を左右します。

体感が明らかに遅いときは、ollama ps で配置を確認するのが早い。100% GPU と出ていれば VRAM に収まっており、CPU/GPU の比率が出ていればその分だけ退避しています。退避が起きているなら、一回り小さい量子化モデルに替えるか、コンテキスト長を縮めて実行時サイズを下げると改善します。

データソース・MCP接続のエラー

メール・カレンダーの認証が通らない、MCPサーバーに繋がらない、という接続系のトラブル。OAuth認証では、ブラウザでの許可後にトークンが正しく保存されているかがカギになります。期限切れで急に連携が切れたら、再認証で回復するケースが多い。

MCPが確立しない場合は、config.toml の servers に書いたコマンドや引数が正しいかをまず疑います。MCPサーバーは外部のコマンドを起動して通信する構造なので、そのコマンドが手元で単体で動くかを別途確かめると原因が見えます。enabled = true の書き忘れも定番の見落とし。

接続系で行き詰まったら、設定を最小に戻すのが有効です。データソースを一旦すべて無効にして最小の対話が動く状態に戻し、そこから1つずつ有効化して、どの接続で壊れるかを特定する。一気に全部つなぐと、どこが原因か分からなくなります。

なお、これらの設定値やコマンドは更新が速い領域です。本記事の記述は2026年7月31日時点で公式情報を確認した範囲のもの。実際に設定する際は、各公式ドキュメントで最新のキー名・要件・手順を確認してください。

まとめ

OpenJarvisで個人用AIアシスタントを組む流れは、3段で整理できます。まずローカルで動かす土台を作り、Ollamaに繋いでモデルを選ぶ。次に config.toml でエンジンとモデルを指定し、最小の応答が返る合格ラインを確認する。そこからローカル文書・メール・カレンダー・MCPといったデータソースを接続して、ようやく「秘書」として使える状態になります。

押さえておきたいのは、ローカル完結と外部送信の境界。推論をローカルモデルに固定し、ローカル文書だけを扱う構成なら、入力もデータの中身も手元で完結します。ただし初期状態では、内容を伴わない通信が別に残ります。実行時分析は [analytics] enabled = false、CLIの更新確認は [updates] auto_update = false か OPENJARVIS_NO_UPDATE_CHECK=1 で止められますが、現行Bashインストーラの導入時分析はこれらとは別で、スクリプト内に停止フラグがありません。一方でクラウドモデルやWeb検索コネクタ、メール・カレンダー連携、外部APIを呼ぶMCPサーバーを有効にすると、その分のデータは外に出る。この線引きを意識して必要なものだけ繋ぐのが、安全に運用するうえでの肝です。

最初の一歩としては、自分がいちばんよく使うデータ源を1つだけ繋いでみるのがおすすめ。ローカルのメモフォルダでも、カレンダーでも構いません。1つ動けば、残りの接続も同じ要領で増やせます。

よくある質問

Q. OpenJarvisは無料で使えますか？

はい。OpenJarvisはApache 2.0のオープンソースとして公開されており、ソフトウェア自体は無料で利用できます。ローカルで動かすぶんには利用料も発生しません。ただしクラウドのAIモデルを接続して使う場合は、そのモデル提供元の料金が別途かかります。

Q. 完全にオフラインで動きますか？

推論エンジンをOllamaなどローカルのモデルに固定し、ローカル文書だけを扱う構成なら、推論と文書の中身は手元で完結します。ただし通信がゼロになるかは別問題です。メール・カレンダー連携、Web検索コネクタ、クラウドモデル、クラウドTTSを有効にすれば当然その分の通信が発生します。内容を伴わない通信として、少なくともBashインストーラの導入時分析（現行Bash版に停止フラグなし）、設定の [analytics] による実行時分析（enabled = false で停止）、CLIの更新確認（[updates] auto_update = false または OPENJARVIS_NO_UPDATE_CHECK=1 で停止）があります。デスクトップ版では自動更新確認も別に発生します。いずれも本文・出力・ファイルパスは含まれません。厳密にオフラインで運用したいなら、これらをそれぞれ手当てしたうえで、実際の通信を確認してください。なお通信をすべて止めても、[telemetry] や [traces] による詳しい記録が端末内に残る場合があります。

Q. WindowsでもOpenJarvisは動きますか？

動きます。macOS・Linuxに加え、WSL2やWindowsに対応しています。環境によって導入手順が異なるため、Windowsで使う場合はWSL2を利用する方法も含め、公式のInstallationドキュメントで自分の環境に合った手順を確認するのが確実です。

Q. Ollama以外のモデルやエンジンは使えますか？

使えます。OpenJarvisは推論エンジンを差し替えられる設計で、OllamaのほかにvLLMやllama.cpp、MLXなど複数のバックエンドに対応しています。設定ファイルで使うエンジンとモデルを指定する形なので、環境や用途に応じて切り替えられます。

Q. どんなデータを接続できますか？

ローカルの文書フォルダ、メールやカレンダーといった外部サービス、さらにMCPサーバー経由の外部ツールを接続できます。ローカル構成なら文書の中身は手元で処理でき、メール・カレンダーや外部API系はサービスとの通信を伴います。接続ごとに外部送信の有無が異なる点と、これとは別に実行時分析や更新確認の通信がある点に注意してください。

参考資料

• OpenJarvis 公式ドキュメント（Getting Started / Configuration）
• GitHub: open-jarvis/OpenJarvis（ソースコード・README）
• Ollama 公式ブログ: OpenJarvis 紹介
• Stanford Scaling Intelligence Lab: OpenJarvis
• Model Context Protocol（MCP）公式サイト