💻 computer science

OpenJarvis: Personal AI, On Personal Devices

OpenJarvis は、LLM によって導かれる仕様検索を活用して 5 つの独立したプリミティブを最適化する分解型で型付けされたパーソナル AI アーキテクチャを導入し、API コストとレイテンシを劇的に削減しながらオンデバイスシステムがクラウドレベルの精度を達成することを可能にします。

原著者： Jon Saad-Falcon, Avanika Narayan, Robby Manihani, Tanvir Bhathal, Herumb Shandilya, Hakki Orhun Akengin, Gabriel Bo, Andrew Park, Matthew Hart, Caia Costello, Chuan Li, Christopher Ré, Azalia Mirhosei

公開日 2026-05-19

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Jon Saad-Falcon, Avanika Narayan, Robby Manihani, Tanvir Bhathal, Herumb Shandilya, Hakki Orhun Akengin, Gabriel Bo, Andrew Park, Matthew Hart, Caia Costello, Chuan Li, Christopher Ré, Azalia Mirhoseini

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたがクラウドに住む、卓越した世界クラスのパーソナルアシスタントを持っていると想像してください。彼らは非常に賢く、複雑な問題を解決でき、メール、カレンダー、健康記録などの機密データを巨大なサーバーファームに送信することで処理します。これはうまく機能しますが、毎月多額の費用がかかり、インターネット接続が必要であり、さらにプライベートな日記を他人に読ませることになります。

次に、同じアシスタントをあなたのラップトップやスマートフォンの中に住まわせたいと想像してください。それはプライベートで、月額費用が不要で、Wi-Fi がない飛行機の中でも動作することを望みます。

問題は、クラウドアシスタントの「脳」（強力な AI モデル）をそのまま取り出してスマートフォンで実行しようとすると、クラッシュしてしまうことです。これは、コンパクトセダンの車体にフォーミュラ 1 レースカーのエンジンを搭載しようとするようなもので、その車はそんなエンジン向けに設計されていません。車のサスペンション、燃料システム、ステアリング（ソフトウェアスタック）はすべて、より小さなエンジンに合わせて調整されています。車体の変更なしにエンジンだけを交換すれば、車は崩壊してしまいます。

これが論文「OPENJARVIS」が解決する核心的な問題です。

問題：「エンジン交換」の失敗

研究者たちは簡単な実験を行いました。既存のパーソナル AI システム（OpenClaw や Hermes Agent など）からクラウドの脳をローカルの脳（デバイス上で動作する小型の AI モデル）に単純に交換したのです。

結果は？ システムはひどいものになりました。精度は 25〜39% 低下しました。
なぜでしょうか？「指示」「ツール」「メモリ設定」はすべて巨大なクラウドの脳向けに書かれていたからです。ローカルの脳を配置すると、従来設計されていない指示に混乱してしまうのです。

解決策：「LEGO の設計図」（Spec）

著者たちは、脳を交換するだけでは不十分で、新しいエンジンに合うように車全体を再構築する必要があることに気づきました。そのために彼らはOPENJARVISを作成しました。

OPENJARVIS を汎用的な LEGO の設計図（「Spec」と呼ばれる）だと考えてください。ごちゃごちゃに絡まったコードの塊ではなく、パーソナル AI システムを 5 つの独立した交換可能な LEGO ブロックに分解しました：

知能（Intelligence）： 脳（AI モデル）。
エンジン（Engine）： 車のエンジンとトランスミッション（モデルの動作方法）。
エージェント（Agents）： 運転手の論理（思考と決定の方法）。
ツールとメモリ（Tools & Memory）： 地図と工具箱（ファイルやインターネットへのアクセス方法）。
学習（Learning）： メカニック（システムの自己改善方法）。

これらは独立したブロックであるため、「知能」ブロックをローカルモデルに交換し、残りの 4 つのブロックをそれに完璧に合うように調整することができます。これは、レースカーのエンジンをセダンの車体に無理やり押し込むのではなく、そのエンジンに合わせてサスペンション、タイヤ、燃料混合比を調整するのと同じです。

魔法のトリック：「チューターと生徒」による探索

LEGO ブロックがあっても、ローカルの脳はクラウドの脳ほど賢くはありません。では、ローカル版をクラウド版と同じレベルで動作させるにはどうすればよいのでしょうか？

彼らはLLM 主導の Spec 探索と呼ばれる手法を開発しました。チューターと生徒の関係を考えてみてください：

生徒： デバイス上で動作するローカル AI。
チューター： 超賢いクラウド AI（有料のものなど）。

彼らがどのように協力するか：

テスト： 生徒がタスクを実行しようとして失敗する。
診断： チューターが失敗を見て、「ああ、カレンダーツールを正しく使わなかったからだ」とか、「推論手順を変更する必要がある」と指摘する。
編集： チューターは単に答えを与えるのではなく、LEGO の設計図を書き換える。「ツールの説明を変更する」「メモリ設定を調整する」「脳のパラメータを微調整する」などと言う。
ゲートキーパー： 厳格なルールがチェックする。「この変更は生徒を良くしたか、かつ他の部分で悪化させていないか？」もしそうなら変更は承認され、そうでなければ却下される。
結果： 生徒は学び、設計図を改善する。

重要なのは： チューターの支援は「探索」フェーズ（セットアップ時）のみであることだ。設計図が完成すれば、生徒はクラウドへの呼び出しゼロで完全にあなたのデバイス上で動作する。クラウドのチューターは消え去り、残るのは高度に最適化されたプライベートなローカルアシスタントだ。

結果：プライベートで高速、かつ安価

この論文は、コーディング、調査、スケジューリングなどの 8 つの異なる現実世界のタスクでこれをテストしました。その結果は以下の通りです：

性能： 最適化されたローカルアシスタントは、高価なクラウド版とほぼ同等の性能を発揮しました。8 つのテストのうち 4 つでは、ローカル版が実際には優れているか同等でした。平均して、最良のクラウドモデルよりも精度はわずか3.2% 低いのみでした。
コスト： ローカルモデルは自前のハードウェアで動作するため、クエリあたりのコストは約800 倍低下しました。月額サブスクリプションの支払いを止めることができます。
速度： ローカル版はクラウドへのデータ往復を待たないため、4 倍高速でした。
プライバシー： 通常の使用中、データはデバイスから離れることはありません。

まとめ

OPENJARVISは、パーソナル AI を構築する新しい方法です。ローカル AI をクラウド AI のように無理やり動作させるのではなく、システムを部品に分解し、「チューター」を使ってそれらの部品をローカルハードウェア向けに再設計します。その結果、ポケットの中にあり、秘密を守り、動作コストがほぼゼロで、高価なクラウド巨人とほぼ同等の賢さを持つパーソナル AI が実現します。

技術概要：OPENJARVIS – 分解され、エンドツーエンドで最適化可能なパーソナル AI スタック

1. 問題定義

パーソナル AI スタック（例：OpenClaw、Hermes Agent）は日常のワークフローの中核をなすものとなっているが、現在、ほぼ例外なくクラウドホスト型の最先端モデルに依存している。このアーキテクチャは、以下の 4 つの重大な課題を呈している：

プライバシー： クエリには、第三者のサーバーへルーティングされる機密性の高いローカルデータが含まれることが頻繁にある。
コスト： 重度のユーザーにとって、API 利用料とサブスクリプション費用の合計は年間数千ドルに上る。
依存性： ユーザーはモデルの所有権を持たず、絶え間ないネットワーク接続を必要とする。
エネルギー： クラウド推論は、ローカル実行に比べてトークンあたりのエネルギー消費量が桁違いに多い。

消費者向けハードウェアは、パーソナル AI タスクにおいて最先端モデルからわずか 6〜12 ヶ月遅れでしかないオープンウェイトモデル（10 億〜1,280 億パラメータ）をサポートするようになったが、既存のクラウド設計スタックに単にローカルモデルを置換するだけでは失敗する。実験によると、OpenClaw や Hermes Agent などのフレームワーク内で、クラウドモデル（例：Claude Opus 4.6）をローカルモデル（例：Qwen3.5-9B）に置き換えると、精度が25〜39 パーセントポイント（pp）低下する。

根本的な原因は、既存のスタックがモノリス的であることにある。エージェントのプロンプト、ツールの説明、メモリ設定、ランタイム設定は、特定のクラウドモデル向けに共同設計され、融合されている。現在の最適化手法（GEPA や DSPy などのプロンプト最適化ツールなど）は、プロンプトというプリミティブのみを調整でき、そのギャップをわずか5 ppしか埋められない。単一のプリミティブを孤立して最適化しても、スタック全体にわたるミスマッチに対処することはできない。

2. 手法：OPENJARVIS アーキテクチャ

ローカルモデルがクラウドシステムと競争できるようにするため、著者はパーソナル AI システムを 5 つの型付けされた独立して編集可能なプリミティブに分解するアーキテクチャ、OPENJARVISを提案する。

2.1 仕様抽象化（Spec Abstraction）

OPENJARVIS は、パーソナル AI システムを 5 つのプリミティブから構成される**型付けされた仕様（spec）**として表現する：

Intelligence（知能）： 言語モデルのアーキテクチャ、重み、生成パラメータ。
Engine（エンジン）： 推論ランタイム、ハードウェア実行パス、バッチ処理、量子化設定。
Agents（エージェント）： 推論ループ、プロンプト、ツール使用ポリシー。
Tools & Memory（ツールとメモリ）： 外部インターフェース、検索メカニズム、永続的なユーザー状態。
Learning（学習）： トレースからシステムを更新するオプティマイザ（例：LoRA、プロンプト最適化ツール、または提案された探索アルゴリズム）。

この分解により、スタック全体を単一の最適化可能なオブジェクトとして扱い、すべてのコンポーネントを自由度として露出させることができる。

2.2 LLM 支援仕様探索（LLM-Guided Spec Search）

中核となる最適化アルゴリズムは、LLM 支援仕様探索であり、これは 4 つの編集可能なプリミティブ（Intelligence、Engine、Agents、Tools & Memory）を共同で最適化し、Learningプリミティブを用いてプロセスを駆動する、ローカルとクラウドの協調である。

探索時（クラウド）： 最先端のクラウドモデル（「教師」）は、反射的な提案者として機能する。現在のローカル仕様からの実行トレースを分析し、失敗のクラスター（例：「学生は多段のカレンダー検索で失敗する」）を診断し、複数のプリミティブにまたがって協調的な編集を同時に提案する（例：ツールの説明を書き換えつつ、ランタイム設定を調整するなど）。
推論時（ローカル）： 生成された最適化された仕様は、完全にオンデバイスで実行される。推論段階ではクラウドモデルは関与しない。
ゲート： 劣化を防ぐため、「ゲート」メカニズムは、特定の失敗クラスターでのパフォーマンスを向上させつつ、他のクラスターで許容できない回帰（許容誤差 $\epsilon$ で定義）を引き起こさない場合にのみ編集を受け入れる。
共同最適化： 単一プリミティブ最適化器とは異なり、この手法は単一の編集が複数のプリミティブにまたがることを可能にし、結合効果を捉える（例：新しいプロンプト構造に合わせるためにモデルの重みを更新するなど）。

3. 主要な貢献

OPENJARVIS アーキテクチャ： パーソナル AI を 5 つの型付けされたプリミティブに分解する新規フレームワーク。これにより、スタックはエンドツーエンドで最適化可能となり、精度、コスト、レイテンシに対して測定可能になる。
LLM 支援仕様探索： 探索時に最先端のクラウドモデルを活用してローカル仕様への編集を提案する探索アルゴリズム。単一プリミティブのベースラインに比べ、最適化コストを7〜11 倍削減しつつ、ローカルとクラウドの精度ギャップを13〜32 pp埋める。
パレート最適なローカル構成： 最適化されたオンデバイス仕様は、8 つのベンチマークのうち 4 つでクラウドの精度に匹敵または上回り、かつマージナルな API コストを約 800 倍削減し、エンドツーエンドのレイテンシを4 倍削減できるという実証的証拠。
包括的な分析： 成果が提案者（進化探索/ランダム探索対 LLM 診断）と移動空間（単一のプリミティブ対 4 つのプリミティブ全体を最適化）の両方から生じていることを示すアブレーション研究。

4. 実験結果

著者は、OPENJARVIS を8 つのベンチマーク（PinchBench、GAIA、LiveCodeBench、DeepResearchBench などを含む）、4 つのファミリーに属する11 のローカルモデル、および7 つのハードウェアプラットフォームで評価した。

ポータビリティの回復： 単にローカルモデルをクラウドフレームワークに差し替えるだけで精度は 24〜39 pp 低下する。同じローカルモデルで OPENJARVIS 仕様を使用すると、この低下の56〜77%を回復し、残存ギャップを5.6〜16.5 ppにまで縮小する。
クラウドとの精度比較： 最良の単一オンデバイス仕様（Qwen3.5-122B）は、平均精度80.3%を達成し、最良のクラウドベースライン（Claude Opus 4.6 の 83.5%）から3.2 ppの差に留まる。8 つのベンチマークのうち 4 つでは、最良のローカルモデルがクラウドのパフォーマンスに匹敵または上回る。
効率性の向上： ローカル構成は、クラウドベースラインに比べ、マージナルな API コストを約 800 倍削減し、エンドツーエンドのレイテンシを4 倍削減する。
探索の有効性：
- LLM 支援仕様探索は、ベンチマーク全体でローカルモデルの精度を13〜32 pp向上させた。
- 編集対象をプロンプトのみから 4 つのプリミティブ全体に拡大することで、5.5〜16.5 pp追加された。
- 進化探索に対して LLM 教師を用いて失敗を診断することで、同じ移動空間において10.0 pp追加された。
- 受け入れられた編集は、Intelligence（16〜44%）、Agents、Tools、Engine のすべてのプリミティブに分散しており、単一のコンポーネントが最適化を支配していないことが確認された。

5. 意義と主張

本論文は、ローカルパーソナル AI には単なるモデルの置換以上のものが必要であると主張する。つまり、ポータブルで測定可能かつ最適化可能なスタックが必要である。OPENJARVIS は以下のことを実証する：

ローカルとクラウドの同等性は達成可能である： 適切なアーキテクチャを用いれば、オンデバイスシステムは、ローカル固有の性質（プライバシー、コスト、所有権）を犠牲にすることなく、最先端のクラウドパフォーマンスに近づけることができる。
分解が鍵である： パフォーマンスギャップは能力の問題ではなく、アーキテクチャ的な問題である。クラウド設計スタックの前提条件を編集可能なプリミティブとして露出させることで、ローカルモデルはその強みに合わせて再構成できる。
ハイブリッド探索は効率的である： クラウドモデルを探索フェーズ（診断と提案）でのみ使用し、最適化された仕様を推論時にローカルで実行することで、永続的なクラウド依存なしに最先端の機能をローカルデバイスへ転送できる。

著者は、生成されたローカル仕様は推論時にクラウドへの呼び出しを一切行わないことを強調している。探索フェーズでは一回限りのコストが発生するが（6 ヶ月の利用でクエリあたり 0.001 ドル未満に償却される）、運用モデルは定期的なクラウドサブスクリプションから、一回限りの最適化 followed by ローカル実行へと移行する。

著者が指摘する限界：

統計的な精度は、構成あたり 5 回の独立した実行に制限されている。
潜在的な LLM 判定者バイアス（GPT-5-mini の使用）は、GPT ファミリーの出力を有利に扱う可能性がある。
評価は現在、単一マシン展開に限定されている。
一部のクラウドベースラインは、評価ハーネス内のツール統合の問題により、予期せぬ低いスコアを示した。