OpenHuman 速読：オープンソース個人 AI Agent のデスクトップ路線

Fri, 15 May 2026 14:52:31 +0800

OpenHuman は tinyhumansai が公開しているオープンソースの個人向け AI Agent プロジェクトだ。目的は単なるチャットウィンドウをもう一つ作ることではない。デスクトップアプリ、個人の記憶、サードパーティ連携、音声、コーディングツール、ローカルナレッジベースを同じ agent harness に入れ、AI が日常の作業コンテキストをより速く理解できるようにすることにある。

プロジェクト README では “Personal AI super intelligence” と位置づけられ、公式サイトでも private、simple、extremely powerful が強調されている。この表現はかなり野心的だが、分解して見る方がわかりやすい。OpenHuman で本当に注目すべきなのは、「個人のコンテキスト」を製品の中心に置こうとしている点であり、モデル呼び出し、プラグイン設定、ドキュメント検索をユーザー自身の組み合わせ作業に任せないところだ。

この記事を確認した時点で、GitHub リポジトリは約 7.8k stars、629 forks だった。最新 release は OpenHuman v0.53.43 で、日付は 2026 年 5 月 13 日。プロジェクトはまだ Early Beta で、README でも活発に開発中だと明記されているため、粗い部分がある前提で見るべきだ。

何を解決しようとしているのか

多くの AI アシスタントの問題は、モデルが弱いことではなく、コンテキストが冷たいことにある。毎回、プロジェクト背景、最近のメール、予定、コードリポジトリ、文書、タスク、好みを説明し直さなければならない。Gmail、Notion、GitHub、Slack、Calendar、Drive、Linear、Jira などをまたぐと、情報はさらに別々のツールへ散らばってしまう。

OpenHuman の考え方は、まずこれらのデータを接続し、その後で自動取得、圧縮、要約、ローカルナレッジベースを通じて、継続的に更新できる個人記憶レイヤーを作ることだ。これにより agent は現在の会話だけを覚えるのではなく、ユーザーのワークフローを中心に長期コンテキストを形成できる。

これが通常のチャットボットとの最大の違いでもある。チャットボットは多くの場合 prompt を中心に動く。OpenHuman はむしろ、デスクトップ上の個人向け OS 入口に近く、コネクター、記憶、ツール、モデルルーティングをあらかじめまとめて提供しようとしている。

主な機能

OpenHuman README に挙げられている中核機能は次の通り。

デスクトップ優先の UI と短いオンボーディング経路。ユーザーが最初からターミナル設定を始める必要はない。
「顔」を持つデスクトップ mascot。話したり、環境に反応したり、Google Meet に参加したりできる。
Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira などを含む 118+ のサードパーティ連携。
自動取得機構。プロジェクト説明では、20 分ごとにアクティブな接続を巡回し、新しいデータを memory tree に取り込むとされている。
Memory Tree：接続データと活動情報を Markdown ブロックへ圧縮し、ローカル SQLite に保存する。
Obsidian-compatible vault：知識ブロックを .md ファイルとして書き出し、ユーザーが Obsidian で開いて閲覧、編集できる。
内蔵検索、Web 取得、コーディングツール、ファイルシステム、git、lint、test、grep、音声入出力などの機能。
Model routing：タスクに応じてリクエストを異なるモデルタイプへルーティングする。
TokenJuice：ツール結果、Web 取得、メール本文、検索結果が LLM に入る前に token 圧縮を行う。
ローカル AI ワークロード向けの Ollama を任意で利用できる。

機能は多く見えるが、実際の焦点は二つにまとめられる。一つは設定やプラグインの組み合わせ作業を減らすこと。もう一つは、個人データを agent が検索でき、圧縮でき、継続的に更新できる記憶へ変えることだ。

インストール方法

プロジェクトは Web サイト上のダウンロード入口に加え、ターミナル用のインストールコマンドも提供している。

macOS または Linux x64：

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows：

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

日常的に使うメインマシンなら、まず公式サイトからインストーラーをダウンロードするか、少なくともインストールスクリプトを開いて内容を確認してから、リモートスクリプトを直接実行するか決めたい。OpenHuman はメール、文書、コードリポジトリ、カレンダー、ローカルファイル権限に関わるため、インストールと認可は普通の小さなツールより慎重に扱うべきだ。

オープンソースと技術スタック

OpenHuman リポジトリは GPL-3.0 license を採用している。言語構成では Rust が中心で、次に TypeScript が多く、JavaScript、Shell、CSS、PowerShell も含まれる。README のコントリビューション説明では、Node.js 24+、pnpm 10.10.0、Rust 1.93.0、CMake、さらに各プラットフォームのデスクトップビルド依存関係が求められている。

ローカル開発のおおまかな流れは次の通り。

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

提出前には focused checks の実行が推奨されている。例えば次のようなものだ。

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

ディレクトリ構造を見る限り、これは軽量なスクリプトプロジェクトではない。デスクトップアプリ、フロントエンド、Rust バックエンド、ドキュメント、テスト、サンプル、ビルドスクリプトを含む、製品型のリポジトリだ。

Memory Tree と Obsidian vault が重要な理由

OpenHuman で単独で見る価値が高い概念は Memory Tree だ。README によると、接続されたデータは約 3k token 以下の Markdown chunks に標準化され、スコアリングされた後、階層的な要約ツリーへ折り込まれ、ローカル SQLite に保存される。同じ内容は Obsidian 互換 vault にも入る。

この路線にはいくつか利点がある。

ユーザーは agent の知識ベースを直接見られ、ブラックボックスな記憶を信じるだけで済まない。
Markdown ファイルは検索、バックアップ、バージョン管理、手動修正がしやすい。
SQLite はローカルインデックスと高速検索に向いている。
階層的な要約は、平坦な文書の山より長期コンテキスト圧縮に向いている。

ただし現実的な課題もある。データ同期が安定するか、要約が重要な細部を落とさないか、権限境界が十分明確か、削除と取り消しが完全か、異なるコネクターの意味を一貫して扱えるか。これらは README の “remembers everything” という一文だけで解決できるものではなく、長期利用と監査が必要になる。

TokenJuice：コストとレイテンシの中間層

OpenHuman は TokenJuice も強調している。役割は、Web ページ、メール、検索結果、ツール呼び出し結果がモデルへ入る前に圧縮することだ。例えば HTML を Markdown に変換する、長い URL を短縮する、一部の不要な文字を取り除く、といった処理が含まれる。README では、これによりコストとレイテンシを減らし、最大 80% の token 使用量削減が可能だと説明されている。

この方向性は妥当だ。Agent システムで本当に費用がかかる部分は、一回のチャットではなく、バックグラウンド取得、ツール呼び出し、検索、Web 解析、長いコンテキスト注入であることが多い。データを先に整理してからモデルへ渡す方が、元データをそのまま詰め込むより安定しやすい。

ただし圧縮層は新しい問題も生む。どの情報を残し、どの情報を捨てるかを決めるからだ。契約書、請求書、医療記録、コンプライアンス資料、本番障害ログを扱うなら、token 節約だけを見るわけにはいかない。追跡可能性、原文確認、圧縮誤差も見る必要がある。

プライバシー：売りでもあり監査ポイントでもある

OpenHuman の売りの一つは private であることだ。公式サイトではローカル AI モデルが低レベルのタスクを処理できると説明され、README でも workflow data stays on device、encrypted locally、treated as yours が強調されている。

この設計方向は魅力的だ。個人 AI Agent が Gmail、Drive、Calendar、Slack、GitHub に接続した瞬間、もっとも機密性の高い仕事データに触れることになる。完全なクラウド型アシスタントと比べると、ローカル優先の記憶レイヤーと見える Markdown vault は、少なくともユーザーにより強い制御感を与える。

ただし全体像も見る必要がある。OpenHuman は同時に one subscription、30+ providers、model routing、ElevenLabs TTS、OAuth integrations などの機能にも触れている。つまり、純粋なオフラインツールではない。プライバシーを本当に評価するには、各コネクター、各種モデル呼び出し、音声や検索機能がそれぞれ何のデータをどこへ送るのかを確認しなければならない。

誰が注目すべきか

現時点の OpenHuman は、次の三種類の人に向いている。

単機能のチャットボットではなく、個人 AI の操作台がほしいユーザー。
Early Beta を試す意欲があり、機能変化や粗い部分を受け入れられる開発者。
ローカル記憶、Obsidian ワークフロー、agent connector、コンテキスト圧縮に関心がある人。

安定して軽量で、プライバシー境界が非常に単純なオフラインアシスタントだけを探しているなら、現時点では重すぎるかもしれない。次世代の個人 AI Agent がデスクトップ、コネクター、記憶、ツールをどう統合するかを研究したいなら、OpenHuman は追いかける価値のあるオープンソースサンプルだ。

私の提案は、まずこれを「製品型オープンソース実験」として観察することだ。release のリズム、issue の品質、コネクター権限、データエクスポート機能、削除機構、ローカル vault の可読性を見る。個人 AI の鍵は、質問に答えられるかだけではない。長期的に、透明で、制御可能な形で自分のコンテキストを背負えるかどうかだ。

オープンソースプロジェクト on KnightLiブログ