この記事ではOpenHumanという個人AIエージェントに特化して解説します。AIエージェントの全体像・主要フレームワークの比較は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。

この記事のポイント
  • OpenHumanは自分のデジタル活動を全部ローカルで記憶する個人AI。Gmail/Notion/GitHub/Slackなど118+のデータをOAuthで取り込み、SQLiteに自分専用の記憶を構築する（GPL-3.0）
  • 連携データは≤3kトークンのMarkdownチャンクに正規化され、スコア付けして階層サマリ（Memory Tree）に畳み込まれる。同じチャンクはObsidian互換ヴォルトの.mdとしても開ける
  • ただし既定構成はマネージドバックエンド依存。サインイン・モデルルーティング・Web検索・OAuthはホスト側を通る。完全ローカルにするには自前設定が必要で、ここを正しく理解しないと『ローカルファースト』を誤読する

30秒で理解するOpenHuman

OpenHumanは、TinyHumans（開発者: Steven E.）が2026年5月に公開したオープンソースのデスクトップ個人AIエージェントだ。要点だけ先に押さえる。

・OpenHumanは自分のデジタル活動（Gmail/Notion/GitHub/Slack等118+）をローカルで記憶する個人AI。ライセンスはGPL-3.0
・連携データを≤3kトークンのMarkdownチャンクに正規化し、スコア付けして階層サマリ（Memory Tree）としてSQLiteに保存。同じ内容をObsidian互換ヴォルトのWiki UIで検索・編集できる
・Product Hunt週間1位（2026年5月15日週）、公開から数週間で約30,000★という急成長
・画面録画型のscreenpipe / Rewind.ai、開発者向けSDKのsupermemory / mem0とは設計思想が異なる
・「クラウド非依存」を掲げるが、既定ではホスト型バックエンドを経由する。完全ローカルは自前設定が前提

クラウドAIの「セッションごとに記憶が消える」「データが他社クラウドに置かれる」という不満に正面から答えるプロダクトだが、マーケティングの『ローカルファースト』と実際の通信経路には差がある。本記事は誇張を避け、設計・連携・プライバシーの実態を一次ソースで整理する。

ローンチの勢いも押さえておきたい。OpenHumanはProduct Huntでローンチ初日に1位、さらに週間1位（2026年5月15日週）を獲得した。創業者の報告によれば公開7日で8,000★・5,000ユーザー・週次150%成長というペースで伸び、本記事執筆時点では約30,000★に達している。Rewind.aiの終息という追い風もあり、「個人の記憶をローカルに持つ」という長年語られてきたコンセプトが、ようやく実用プロダクトとして広く触れられる段階に入ったことを示す数字だ。

なぜ「個人AIをローカルで」持つのか

クラウド型のAIアシスタントには、使い込むほど見えてくる4つの限界がある。

クラウドAIの4つの限界
・メモリ喪失：セッションが終わると文脈が消える。毎回ゼロから説明し直す
・データ主権：自分のメール・コード・メモが他社のサーバーに蓄積される
・ベンダーロック：特定ベンダーのモデル・料金体系に縛られ、乗り換えコストが高い
・従量課金：使うほどコストが膨らみ、常時稼働の個人エージェントには向かない

OpenHumanの開発元が掲げる問題意識は明快だ。「AIエージェントを試した人の90%が脱落する。理由は3つ——セッションごとにリセットされる記憶、他人のクラウドに置かれる自分のデータ、起動にターミナルが要る難しさ」。OpenHumanはこれを、ローカルファースト・プライバシーファースト・GUI完結で解こうとする。記憶は手元のSQLiteに残り、使うほど自分専用に賢くなっていく、という設計だ。

この発想自体は新しくない。Rewind.aiが先行し、screenpipeがオープンソースで追随した領域である。だが後述するように、Rewind.aiは2025年12月にMetaに買収され、デスクトップの画面録画アプリは終息した。「自分の記憶を自分の手元に置く」というニーズだけが残り、その受け皿の一つとしてOpenHumanが急浮上した格好だ。

なお、エージェントに永続メモリを与えるという課題は、開発者向けにも別解がある。Claude CodeやCursorにメモリを足すMCPサーバーの考え方は agentmemory徹底解説｜Claude Code・CursorのAIエージェントに永続メモリを与えるMCPサーバー で扱っている。OpenHumanは「個人の生活全体」を、agentmemoryは「開発エージェントの作業文脈」を記憶対象にする、という対象範囲の違いで読み分けると整理しやすい。

設計の中身：Memory Tree + Obsidian Wiki

OpenHumanの核は、連携してきた雑多なデータを「検索・要約しやすい階層」に畳み込む仕組みにある。READMEの説明を分解すると、データは次の経路をたどる。

flowchart TD A["118+連携
Gmail / Notion / GitHub / Slack"] -->|"OAuth取り込み
20分ごと自動同期"| B["TokenJuice圧縮
HTML→Markdown / URL短縮 / 重複排除"] B -->|"最大80%トークン削減"| C["≤3kトークンの
Markdownチャンク化"] C -->|"関連度スコア付け"| D["SQLiteに階層保存
（ローカル）"] D --> E["Memory Tree
階層サマリツリー"] D --> F["Obsidian互換ヴォルト
.mdファイル群"] E --> G["エージェントが
関連チャンクのみ検索"] F --> H["Wiki UIで
人間が閲覧・編集"]

ポイントは3つある。第一にTokenJuiceと呼ばれる圧縮層が、HTMLをMarkdownに変換し、URLを短縮し、重複を排除して、最大80%までトークンを削った状態でチャンク化する。生のWebページやメールをそのまま保存するのではなく、LLMが食べやすい密度に整えてから格納する発想だ。

第二に、チャンクは≤3kトークンという上限で揃えられ、関連度でスコア付けされたうえで、階層的なサマリツリー（Memory Tree）に畳み込まれる。エージェントが何かを問われたとき、作業履歴を丸ごとプロンプトに流し込むのではなく、「最も関連するチャンクとサマリ」だけを引く。これがコンテキスト長とコストの両方を抑える肝になる。Product Huntのコメントでもチームメンバーが「低品質な処理には低価格帯のモデルを充てる」とコスト設計に触れている。

第三に、同じチャンクがObsidian互換ヴォルトの.mdファイルとしても書き出される。人間がObsidianを開いて記憶を直接読み・編集でき、ブラックボックス化しない。KarpathyのワークフローにインスパイアされたというこのWiki UIが、「AIの記憶を人間が監査できる」という安心感につながっている。

階層サマリによる二層記憶という考え方自体は、エージェント設計のトレンドでもある。Claudeのマネージドエージェントが採る記憶アーキテクチャは Claude Managed Agents「Memory」と「Dreaming」完全解説 — セルフラーニング・エージェントを実現する2層記憶アーキテクチャ で詳述している。OpenHumanのMemory Treeも、生データ層と要約層を分けるという点で同じ系譜にある。

118+連携の中身

OpenHumanの「118+連携」は、独自実装ではなくComposioコネクタ層を基盤にしている。これが設計上の重要な事実だ。

連携の通信経路に注意
既定の「マネージド」構成では、OAuthフローはOpenHumanがホストするComposioバックエンドを経由する。つまり連携の認可ステップでは、データの取り回しにホスト側が関与する。プライバシーを最優先するなら、自分のComposio APIキーを使う「ダイレクトComposioモード」に切り替える設定が用意されている。

代表的な連携先は次の通りで、いずれもワンクリックのOAuthで接続できる。

・コミュニケーション：Gmail / Slack / Telegram / Discord / WhatsApp / Calendar
・ドキュメント・ナレッジ：Notion / Google Drive / Obsidian
・開発：GitHub / Linear / Jira
・業務・決済：Stripe ほか

接続された各サービスは、エージェントに対して「型付きツール」として公開される。そして20分ごとの自動フェッチで、アクティブな連携を巡回して新しいデータをMemory Treeに取り込む。常時起動の個人エージェントとして、放っておいても記憶が更新され続ける設計だ。

連携データそのもの（取り込まれたメールやドキュメントの中身）はローカルのSQLiteとObsidianヴォルトに残る。一方で、後述するモデル推論やWeb検索の段では、既定構成だとホスト側を経由する。「保存はローカル、処理は一部マネージド」という線引きを押さえておきたい。

マスコット・ネイティブツール・モデルルーティング

OpenHumanが単なる「検索可能な記憶DB」で終わらないのは、記憶を使って動くエージェント側の作り込みがあるからだ。READMEが挙げる要素を押さえておく。

第一にデスクトップマスコット。画面上に「顔」が常駐し、発話し、周囲に反応する。さらにGoogle Meetへ実際の参加者として加わり、会議をまたいでユーザーを覚えている、という常駐エージェント体験を打ち出している。賛否が分かれる演出だが、「常に隣にいて文脈を共有する個人AI」という製品コンセプトを体現する部分だ。

第二にネイティブツール群。エージェントには、Web検索・Webスクレイパー・ファイルシステム/git操作・コードのlint/test・grep、そしてElevenLabsのTTSとリップシンクを使った音声I/Oが標準で組み込まれている。連携サービスから取り込んだ記憶を読むだけでなく、その記憶を踏まえて手元のファイルやコードに対して実際に作業できる。

モデルルーティングという考え方
OpenHumanは内蔵のモデル選択機構で、タスクの性質（推論重視・速度重視・ビジョン）に応じて適切なLLMを振り分ける。重い推論には高性能モデル、軽い整形には低価格帯モデル、という使い分けで、常時稼働エージェントのコストを抑える設計だ。Ollamaを指定すればこの推論段をローカルに寄せられる。

この「記憶（Memory Tree）＋実行ツール＋モデルルーティング」という三層構成が、OpenHumanを「個人の生活データで動くエージェント」として成立させている。記憶だけのメモリツール、あるいはツールだけのエージェントフレームワークとは、ここで一線を画す。

ローカル実行手順

対応OSとインストール経路は次の通り。ネイティブパッケージ（署名チェーンで検証可能）が推奨で、スクリプトインストールは整合性検証がない点に注意する。

対応プラットフォームとインストール
・macOS：brew tap tinyhumansai/core && brew install openhuman
・Linux：署名済みaptリポジトリ（Debian/Ubuntu）／Arch AUR
・Windows：MSIインストーラ

OpenHumanはRust（約62%）とTypeScript（約35%）で書かれたデスクトップアプリだ。READMEではRAM/SSDの数値要件は明示されていないが、ローカルのSQLiteとObsidianヴォルトに記憶を蓄積し続ける性質上、連携を増やすほどディスクと処理負荷が伸びる。常用するなら余裕のあるSSD容量を見ておきたい。

ソースからビルド・開発する場合の前提は明確に記載されている。

# 開発環境の前提
# Git, Node.js 24+, pnpm 10.10.0
# Rust 1.93.0（rustfmt, clippy 同梱）
# CMake, Ninja, ripgrep

git clone https://github.com/tinyhumansai/openhuman
cd openhuman
pnpm install

# UIの開発サーバ
pnpm dev

# デスクトップアプリの開発起動
pnpm --filter openhuman-app dev:app

最初のセットアップでは、アカウントにサインインしたあと、使いたいサービスをOAuthで順に接続していく。接続が済むと20分ごとの自動同期が走り、Memory Treeが構築され始める。OpenHumanが掲げる「数週間ではなく数分で文脈を持つ（context in minutes, not weeks）」という体験は、この初期接続の速さに由来する。

ローカルモデルで完結させたい場合は、Ollama経由のオンデバイス推論に対応している。既定のマネージド・モデルルーティングを使わず、自分のモデルエンドポイントを指定すれば、推論段もローカルに寄せられる。

類似ツールとの比較表

「自分の活動を記憶するAI」というカテゴリには複数のアプローチが混在している。入口（何を記録するか）とレイヤ（製品かSDKか）で整理すると違いが見える。

ツール アプローチ 主なデータ源 ライセンス プライバシー設計 形態
OpenHuman アカウント連携を記憶 118+サービス（Gmail/Notion/GitHub等） GPL-3.0 ローカル保存＋既定はマネージド経由 デスクトップアプリ
screenpipe 画面・音声を24h録画 画面OCR・音声文字起こし オープンソース 100%ローカル デスクトップアプリ
Rewind.ai 画面録画（先行製品） 画面・音声 クローズド（Meta買収・終息） ローカル＋任意クラウド （Limitlessへ移行）
supermemory アプリ用メモリSDK 開発者が渡すデータ オープンソース（自己ホスト可） 自己ホスト次第 開発者向けSDK
mem0 エージェント用メモリSDK 開発者が渡すデータ オープンソース 構成依存 開発者向けSDK

要点を絞ると次のようになる。

・OpenHuman vs screenpipe：記録の入口が「アカウント連携」か「画面録画」か。OpenHumanは構造化されたサービスデータを、screenpipeは画面に映った体験そのものを記憶する
・OpenHuman vs Rewind.ai：Rewind.aiは2025年12月にMetaへ買収され、デスクトップ画面録画は終息しLimitlessへ移行。「終わった先行製品」の受け皿という文脈でOpenHumanが注目された
・OpenHuman vs supermemory / mem0：後者は完成品ではなく、AIアプリに記憶を組み込むための開発者向けSDK。エンドユーザーがそのまま使うものではない

つまりOpenHumanは「エンドユーザーが今日から使える、アカウント連携起点の個人AI」という枠で、現状ほぼ単独のポジションにある。

プライバシーとセキュリティ

OpenHumanのプライバシーは、マーケティングの「クラウド非依存」を額面通りに受け取ると誤読する。実態を分解する。

「ローカルファースト」の正確な意味
ローカルに残るのは Memory Tree・Obsidianヴォルト・ワークスペース設定・ローカルランタイム状態。一方で既定のマネージド構成は、サインイン・モデルルーティング・Web検索のプロキシ・OAuth連携（Composio経由） にOpenHumanのホスト型バックエンドを使う。「保存はローカル、一部の処理はクラウド」が正しい理解。

Product Huntのローンチでも、創業者が「すべてオープンソースなのでソースを確認できる」「ローカルで全部動かせる」と説明する一方、コメント欄では「手を振るだけでない、具体的なプライバシーの説明が欲しい」という指摘が出ていた。誠実に評価するなら、次の点を自分の要件と突き合わせるべきだ。

・データ保管場所：記憶本体（メール・ドキュメントの中身）はローカルのSQLite／Obsidianヴォルト。完全オフラインにするには独自モデル・検索・Composio資格情報の自前設定が必要
・OAuthトークン：既定ではComposioコネクタ層が認可を仲介。トークンの取り回しを完全に手元に置くにはダイレクトComposioモードを使う
・暗号化：READMEはデバイス上のデータを「ローカルで暗号化」と表現。at-rest／in-transitの詳細仕様は公開情報が限られるため、本番採用前に実装を確認したい
・リアルタイムトリガー：ホスト機能を要する機能（リアルタイムトリガー等）はマネージドバックエンド前提

セキュリティ観点では、118+のサービスにOAuthで接続するという性質上、接続スコープの最小化が最重要になる。広いスコープで全サービスを繋ぐと、攻撃面とローカルDBの肥大が同時に膨らむ。エージェントが外部サービスへアクセスする構成のリスク管理は、トークン窃取やプロンプトインジェクションを含めて多層で考える必要がある。

ユースケース別の活用パターン

個人開発者の業務記憶補助

GitHub / Linear / Slackを連携し、過去のPR・Issue・議論を横断検索する。「あの修正、なぜその設計にしたか」を毎回掘り返す手間が消える。コードレビューの文脈やレビュー指摘の傾向もMemory Treeに蓄積され、エージェントが過去の判断を踏まえた提案を返せるようになる。

ナレッジワーカーの調査メモ

Notion / Google Drive / Gmailを連携し、調査資料・メール・メモを一つの記憶として扱う。Obsidianヴォルトに.mdとして落ちるため、AIの要約と人間の手書きメモが同じヴォルトで共存する。AI任せにせず人間が編集できる点が、調査の信頼性を支える。

経営者の会議サマリ

Calendar / Gmail / Slackに加え、Google Meetへ「参加者」として加わるマスコット機能を使えば、会議の流れと決定事項がMemory Treeに残る。後日「先週の意思決定の経緯」を自然言語で引ける。ただし会議録の取り扱いは機密性が高く、マネージド経由の処理範囲を事前に確認すべきだ。

クリエイターの素材管理

Drive / Notion / Discordを連携し、素材・アイデア・コミュニティの反応を横断管理する。散在する制作メモを、エージェントが関連チャンク単位で引き出してくれる。

拡張：自分の連携を作る

OpenHumanの連携はComposioコネクタ層に乗っているため、拡張の経路は大きく2つある。

第一に、Composio側でカスタムツールを登録する経路。Composioが対応していないサービスでも、APIをカスタムツールとして定義すれば、OpenHumanのエージェントから型付きツールとして呼べる。自分のComposio APIキーを使うダイレクトモードと組み合わせれば、認可の取り回しも自分の管理下に置ける。

第二に、GPL-3.0のリポジトリ本体へコントリビュートする経路。OpenHumanはRust + TypeScriptで実装され、コントリビューションガイド（CONTRIBUTING.md / 初心者向けのCONTRIBUTING-BEGINNERS.md）とDiscordコミュニティが整備されている。コア機能やネイティブツール（Web検索・スクレイパー・ファイルシステム/git操作・lint/test・grep・ElevenLabsのTTS音声I/O等）の拡張は、こちらの経路になる。

# 連携・コア拡張の開発フロー（概略）
git clone https://github.com/tinyhumansai/openhuman
cd openhuman
pnpm install

# UIを動かしながら変更を確認
pnpm dev

# 変更を整形・静的解析（Rust側）
cargo fmt && cargo clippy

なお外部のAIエージェント（Claude Code / Cursor / Codex / OpenCode）とメモリを共有するagentmemoryバックエンド連携もオプションで用意されている。OpenHumanのMemory Treeを単体で閉じず、他のエージェントの記憶基盤として使う構想だ。エージェントにナレッジグラフ的な構造を持たせる発想は Understand Anything入門：コードベースをナレッジグラフ化するClaude Codeプラグイン とも近く、「記憶を構造で持つ」流れの一部として読める。

よくある落とし穴

実運用で踏みやすい問題を先に挙げておく。

導入前に想定しておきたい4点
・ローカルDBの肥大：全データを取り込むとSQLiteとObsidianヴォルトが膨張する。連携範囲を絞り、必要なサービスから始める
・OAuthスコープの広げすぎ：攻撃面が増える。読み取り専用で足りる連携は最小スコープに
・Memory Tree要約の品質依存：階層サマリの質に検索精度が引っ張られる。要約モデルの選定・確認が効く
・複数デバイス間の同期問題：記憶はローカル前提のため、複数端末で使うと記憶が分散する。同期戦略は自分で設計する必要がある

加えて、OpenHumanはアーリーベータである点を忘れてはいけない。急成長中で機能追加が速い反面、バグや仕様変更も多い。本番の重要ワークフローに据える前に、まずは限定的な連携で挙動と通信経路を自分の目で確認するのが安全だ。

まとめ：誰に向くか

OpenHumanは、「クラウドAIのメモリ喪失とデータ主権に不満があり、自分の活動を手元に記憶させたい」開発者・ナレッジワーカーに刺さる。Memory Tree + Obsidian Wikiという、AIの記憶を人間が監査できる設計は、ブラックボックス化を避けたい層に特に響く。

一方で、「クラウド非依存」を完全オフラインと誤読すると期待を外す。既定はマネージドバックエンド依存であり、真にローカルで閉じるには自前設定が要る。GPL-3.0のコピーレフトも、組み込み配布を考えるなら無視できない。これらを正しく理解したうえでなら、終息したRewind.aiの受け皿として、また screenpipe とは別軸の「アカウント連携起点の個人AI」として、現状ほぼ単独のポジションを占める有力な選択肢だ。

アーリーベータゆえの不確実性は残るが、「自分のデータを自分の手元で記憶させ、AIに監査可能な形で使わせる」という方向性は、クラウドAI全盛の今だからこそ価値を増している。まずは少数の連携から試し、通信経路とローカルDBの挙動を自分の目で確かめたうえで、用途を広げていくのが堅実な進め方になる。

参照ソース（一次ソース）

・OpenHuman 公式リポジトリ（README・CONTRIBUTING）: https://github.com/tinyhumansai/openhuman
・OpenHuman 公式README: https://github.com/tinyhumansai/openhuman/blob/main/README.md
・Product Hunt: OpenHuman — An open source AI harness built with the human in mind: https://www.producthunt.com/products/openhuman
・screenpipe vs Rewind.ai（screenpipe公式比較）: https://docs.screenpi.pe/vs-rewind