OpenHuman レビュー: ローカルファーストの記憶とエージェント群を統括する Rust 製パーソナル AI

OpenHuman が解決する問題: 記憶を持たない AI の限界

OpenHuman は、一般的な AI アシスタントが会話ごとに文脈を忘れる問題を直接扱います。README によると、これは「あなたの世界の永続的なローカル記憶を構築する脳」を謳っており、単なるチャットボットではなく、過去のデータを圧縮してスコア付きの Markdown ツリーにし、SQLite に保存します。対象は、Gmail や Notion、GitHub など複数のサービスを横断して情報を蓄積し、それを AI に参照させたい個人ユーザーです。特に、クラウドにデータを預けたくない層に向けて、ローカルファーストを前面に押し出しています。ただし、この「記憶」が実際にどの程度正確に圧縮されるかは、ドキュメントの記述だけでは判断できません。

メモリツリーの仕組み: ベクトルではなく Markdown と SQLite

OpenHuman の記憶の中核は Memory Tree と Obsidian Wiki です。README によると、データは「スコア付き Markdown ツリーに圧縮され、SQLite に保存」され、さらに Obsidian ボールトとしてミラーリングされます。つまり、ベクトルデータベースのブラックボックスではなく、人間が読める Markdown として記憶を直接編集できる設計です。これは大きな利点で、AI が要約した内容をユーザーが後から修正したり、Obsidian の既存ノートと統合したりできます。また、Auto-fetch 機能が 20 分ごとにデータを取得し、「明日の文脈を今朝持つ」と README は説明します。ただし、この圧縮プロセスがどのようにスコアリングされるのか、詳細なアルゴリズムは公開資料からは不明で、実際の品質は試用して確認する必要があります。

オーケストレーター: 反射エージェントと深層推論の分割

オーケストレーションは「分割された脳」と README で表現され、高速な反射エージェントが受信トラフィックをトリアージし、深層推論コアがワーカーフリートにタスクを委任します。これは、単一の LLM にすべてを処理させるのではなく、役割を分離することで応答速度と複雑な推論を両立させるアーキテクチャです。さらに、ワークフローはエージェントが自動化を提案し、ユーザーがキャンバス上でレビューして保存する形式です。実行はオープンソースの tinyflows と tinyagents に基づき、チェックポイント付きのグラフで管理されます。つまり、エージェントが途中で停止しても、再開や原因の特定が可能です。ただし、この分割構成が実際にどれだけのオーバーヘッドを生むか、また反射エージェントのトリアージ精度がどの程度かは、公開情報からは検証できません。

インストールと実行: インストーラとターミナル手順

インストール方法は README に明記されています。公式サイト tinyhumans.ai/openhuman または GitHub Releases ページからインストーラをダウンロードできます。ターミナルでのインストールには、Homebrew、Debian/Ubuntu の .deb パッケージ、AUR、インストールスクリプトが用意されており、詳細は INSTALL.md に記載されています。リポジトリの主要言語は Rust ですが、ユーザーが Rust を直接ビルドする必要はなく、バイナリ配布が中心です。実行後の設定として、モデルルーティング機能があり、サブスクリプションのデフォルトモデルに加えて、自分のプロバイダキー (BYOK) や完全ローカルの Ollama モデルを混在させることができます。これは、クラウド API に依存したくないユーザーにとって実用的な選択肢です。ただし、ベータ版であるため、インストール後に設定ファイルが頻繁に変更される可能性があり、アップグレードのたびに再設定が必要になるかもしれません。

TokenJuice: トークン圧縮の実際と限界

OpenHuman の特徴的な機能に TokenJuice があります。これは、ツールの出力をモデルに渡す前に圧縮し、「同じ情報で最大 80% 少ないトークン」を実現すると README は主張します。これは、大量のツール呼び出しを行うエージェントにとって、コスト削減に直結する重要な仕組みです。ただし、この圧縮率は情報の種類に依存するはずで、コードの差分や数値データなど、圧縮しにくい形式では効果が薄い可能性があります。また、圧縮による情報損失がエージェントの判断精度に与える影響は、ドキュメントでは触れられていません。実際に 80% 削減が達成できるかは、自分のワークロードで計測する必要があります。TokenJuice のアルゴリズム詳細も公開資料からは不明で、過度な期待は禁物です。

ライセンスとメンテナンス: GPL-3.0 とベータ版のリスク

ライセンスは GPL-3.0 です。これは、OpenHuman を組み込んだソフトウェアを配布する場合、そのソースコードも GPL-3.0 で公開する必要があることを意味します。個人利用や内部ツールとして使う分には問題ありませんが、商用サービスとして提供する場合は法的な検討が必要です。また、README には「Early Beta: 活発に開発中。粗い部分があることを想定してください」と明記されています。リリース頻度を見ると、v0.63.7 から v0.63.12 まで同日に複数のリリースがあり、バージョン番号の細かい更新が頻繁に行われています。これは、バグ修正や機能追加が速い一方で、API や設定形式が安定していない可能性を示唆します。メンテナンスコストとしては、アップデートの追従と、ベータ版特有の挙動変化への対応が求められます。

代替手段との比較: ローカル記憶のアプローチの違い

OpenHuman の代替として、ローカルファーストの AI アシスタントや、メモリ機能を持つチャットボットが考えられます。例えば、Ollama を利用したローカル LLM と、LangChain などのフレームワークで独自の記憶機構を構築する方法があります。この場合、記憶はベクトルストアに保存するのが一般的で、OpenHuman の Markdown ツリー方式とは対照的です。ベクトルストアは類似検索に強い一方、人間が内容を直接編集するのは難しく、ブラックボックス化しがちです。OpenHuman は Markdown を採用することで、透明性と編集可能性を優先しています。また、商用の AI アシスタント (例えば Notion AI や ChatGPT のメモリ機能) はクラウドにデータを保存しますが、OpenHuman はローカルに保持します。この違いは、データのプライバシーと管理のしやすさに直結します。ただし、OpenHuman のオーケストレーション機能は独自のもので、単純なメモリ追加とは比較にならない複雑さを持っています。

編集部の結論

OpenHuman を採用すべきなのは、個人データをクラウドに預けたくないが、AI に記憶とタスク実行の両方を任せたい技術者です。特に、SQLite 上のメモリツリーを直接編集したい人や、Obsidian を日常的に使う人には設計が合っています。逆に、商用製品に組み込みたい企業や、安定した API を求める開発者は避けるべきです。理由は GPL-3.0 が派生物のソース公開を要求する点と、ベータ版で breaking change が頻発する可能性がある点です。導入前に確認すべきは、まず自分の利用が GPL-3.0 の解釈で問題ないか、そしてドキュメントの INSTALL.md に記載されたインストール手順が自分の OS で完走するかです。また、モデルルーティングで BYOK とローカル Ollama を混在させる設定が、実際に意図通りに動くか小規模で試すことを推奨します。最後に、メモリツリーの圧縮率が TokenJuice の主張する 80% 削減を本当に達成するかは、自分のデータで計測してから判断してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes