Vuncloud ブログ
← 開発日記へ戻る

OpenHuman が示す「Memory OS」革命

現場メモ · 2026.05.26 ·約 14 分

ニューラルネットワークと知識グラフの抽象ビジュアル、OpenHuman Memory OS と Memory Tree 個人 AI 記憶アーキテクチャを象徴

2026 年、個人 AI の競争軸は「モデルが賢いか」から「Agent があなたを覚えているか」へ移っています。ChatGPT の Memory、Claude のプロジェクトコンテキスト、各種 Coding Agent の AGENTS.md——いずれも同じ痛点を狙っています:大規模言語モデルは本質的にステートレスであり、system prompt の数行は付箋であって、知能ではない。 オープンソースの OpenHuman(TinyHumans AI、GPL-3.0)はさらに一歩進み、「記憶」を CPU やスケジューラと同格の Memory OS(記憶オペレーティングシステム)として位置づけます。外部ベクトル DB のラッパーではなく、ローカル優先で監査可能、編集可能な Memory Tree パイプラインです。本稿ではアーキテクチャ視点でこの動きを分解し、Apple Silicon 開発者が Mac mini M4 Cloud Mac 上で 7×24 個人 Agent を動かす理由を整理します。

3
層サマリーツリー:Source / Topic / Global
≤3k
token 決定論的 Markdown チャンク上限
20min
Auto-fetch デフォルト同期間隔(公式)

なぜ Memory OS か——長いコンテキスト窓だけでは足りない

コンテキスト窓が 8K から 1M token へ広がっても、会話が終わればモデル重みに何も残らないという事実は変わりません。プロダクト上の「記憶」はだいたい次のどれかです:

  • ユーザー嗜好を system prompt に数行書く;
  • セッション内 RAG でベクトル DB から似た断片を引く;
  • プラグインで Notion / Google Drive を一時マウントする。

これらは症状緩和には有効ですが、OS レベルの抽象——統一 ingest 規格、永続フォーマット、検索スコープ、ライフサイクル管理、人間が読めるストレージ——がありません。OpenHuman の Memory OS 比喩はここを埋めます。Memory Tree は「またベクトル DB ラッパー」ではなく、メール、Slack、GitHub、会議文字起こしなどの異種データを deterministic pipeline で Agent が検索可能、ユーザーが開ける Markdown 知識ベースに変換します。公式ドキュメントは 「You can't trust a memory you can't read.」 と明言しています。

OpenHuman とは

OpenHuman は TinyHumans が出したローカル優先の個人 AI Agent デスクトップアプリです。Rust + Tauri 製で、「デジタル生活の記憶と実行役(memory and doer)」を目指します——単なるチャット UI ではありません。Terminal-first の Agent フレームワークと比べ、次を前面に出しています:

  • Memory Tree + Obsidian Wiki:構造化された長期記憶;
  • Auto-fetch:手動 prompt なしで接続済み SaaS から定期取得;
  • フルツールチェーン:Web 検索、コードツール、ブラウザ制御、Cron、マルチ Agent 調整、音声と Google Meet Agent;
  • 118+ OAuth 連携(公式比較表。最新はGitBookを参照)。

2026 年 5 月前後、GitHub と Product Hunt で大きな注目を集めました——差別化の核は Chat UI ではなく Memory OS です。

Memory OS の中核:Memory Tree 決定論パイプライン

OpenHuman Memory Tree ドキュメントによると、新規データは常に同じ hot path を通ります:

Memory Tree ingest パイプライン(簡略)
source adapters (chat / email / document)
        ↓
canonicalize    → 正規化 Markdown + 出典メタデータ
        ↓
chunker         → 決定論 ID、≤3k token チャンク
        ↓
content_store   → ディスク上の atomic .md ファイル
        ↓
store           → chunks.db(SQLite)
        ↓
score           → シグナル + embedding + エンティティ抽出
        ↓
source / topic / global trees  → 各スコープのサマリーツリー
        ↓
retrieval       → search / drill_down / topic / global / fetch

Ingest の 3 原則

  • Deterministic(決定論):チャンク ID はコンテンツアドレス。再 ingest でも重複行は増えない。
  • Fast(高速):hot path では LLM を呼ばず、低コストなヒューリスティックでスコアリング。
  • Bounded write(有界書き込み):単一トランザクションで永続化し、中途半端な ingest が DB を汚さない。

重い処理——embedding、エンティティ抽出、seal サマリー、毎日 digest——はバックグラウンド job queueへ。デフォルト 3 worker が消費し、semaphore で LLM 同時実行を制限。Auto-fetch のピークが API クォータを食い潰すのを防ぎます。

3 層ツリー:Source、Topic、Global

Memory OS の「ファイルシステム」はフラット key-value ではなく、独立に育つ 3 本のサマリーツリーです:

ツリー種別 スコープ 典型クエリ
Source tree 接続ソースごと(Gmail label、Slack チャンネル、単一ドキュメントなど) 「Stripe webhook は先週火曜 15 時に何と言った?」
Topic tree エンティティ(人、プロジェクト、リポ、ticker)の熱量で lazy load 「この顧客との最近のやり取りサマリーは?」
Global tree UTC 日次のグローバル digest 「今日全体で何が起きた?」

ベクトル類似度は底層で効きますが、ツリー構造が圧縮とナビゲーションを提供する——ここが Memory OS と「純 RAG ベクトル袋」の分水嶺です。Leaf のライフサイクルは pending_extraction → admitted → buffered → sealed(または dropped)。検索時に provenance を辿れ、パイプライン全体を再実行しなくて済みます。

Obsidian Wiki:記憶は読めて、直せて、消せるべき

Memory Tree の二重書き込み設計はエンジニアリング的に誠実です。チャンクは memory_tree/chunks.dbwiki/ 下の .md の両方へ——Obsidian vault 互換で、Karpathy 由来の obsidian-wiki ワークフローに着想。デスクトップアプリの Intelligence ページから「Obsidian で開く」深リンクがあり、検索ヒットからソース Markdown に戻れます。

開発者にとっての意味:

  • wiki/ を Git 管理できる(秘匿情報は除外);
  • Agent が誤記したら人間が md を直接修正;
  • 監査時、記憶はブラックボックス embedding ではなく、平文 + スコア + 出典。

Auto-fetch:Memory OS が能動的に「仕訳」する

多くの Agent の記憶は受動的——ファイルを @ したり、リンクを貼ったり、手動 export したり。OpenHuman の Auto-fetch は約20 分ごとにアクティブな接続を走査し、新着メール、メッセージ、PR を Memory Tree に書き込みます。Scheduler は UTC 0:00 に global daily digest と stale buffer flush も実行。

プロダクトの体感が変わります:朝 Agent を開けば「昨日の文脈」が既にある——毎回クラウドから cold mount するのではなく、OS の page cache に近い。

開発者ノート PC のコードエディタ、Mac mini M4 Cloud Mac 上で OpenHuman などローカル優先 AI Agent ワークフローを動かす様子

agentmemory バックエンド:Cursor、Codex と記憶を共有

Cursor や Claude Code 側で agentmemorynpx -y @agentmemory/agentmemory)を自前ホストしているなら、OpenHuman はオプション backend を提供します。config.tomlmemory.backend = "agentmemory" とすると、OpenHuman は REST 薄クライアントになり、保存 / embedding / ハイブリッド検索(BM25 + vector + graph)は agentmemory が担います。

典型マッピング(公式より):

  • storePOST /agentmemory/remember
  • recallPOST /agentmemory/smart-search
  • ライフサイクル:consolidation、retention scoring、auto-forget、graph extraction

Memory Tree の chunking / sealing pipeline と trait backend は直交——agentmemory に切り替えても Obsidian wiki のドキュメント ingest はそのまま。Agent 側 recall だけ共有庫経由になります。移行は SQLite export → agentmemory へ POST → 設定変更再起動(現状ホット移行なし)。

Memory OS vs ベクトル DB vs チャットコンテキスト

方式 強み 典型弱点
チャット履歴を延ばす インフラゼロ 構造化なし、セッション横断圧縮なし、token コストが線形増
純ベクトル RAG 意味類似 recall が速い タイムライン / エンティティ追跡 / 「今日何があった」に弱い
OpenHuman Memory OS ツリー型サマリー + 平文 wiki + Auto-fetch + マルチスコープ検索 ローカルディスクと macOS デスクトップが必要;beta で API も進化中

OpenClaw など他 Agent との記憶の違い

OpenClaw(当ブログでも何度か実践している Gateway オーケストレーション層)はマルチチャネルルーティング、Daemon ヘルスチェック、SSH トンネル vs WSSが得意——OpenClaw とクラウド Mac 自動化を参照。記憶はプラグインや外部 DB 依存が多く、Memory Tree は内蔵しません。OpenHuman は記憶をプロダクト化し、Intelligence ページでストレージ指標、エンティティ関係図、ingest ヒートマップ、Obsidian 入口を提供します。

エンジニアリング上、二者は同一 Cloud Mac に共存可能:OpenHuman が長期個人知識 OS、OpenClaw が Telegram / Webhook トリガーのタスク編成——ただし OPENHUMAN_WORKSPACE と OpenClaw 設定ディレクトリを分け、launchd や tmux で CPU / メモリピークを隔離(大規模 embedding と Gateway 高峰の重なりを避ける)。

Mac mini M4 Cloud Mac で OpenHuman を動かす

デスクトップ Agent なのに Cloud Mac? 次の 3 層ユーザーには理由がはっきりしています:

  • Windows / Linux メインの開発者:Tauri 版 OpenHuman + Ollama Metal embedding に macOS が必要だが、Mac を買いたくない——Windows からリモート Xcodeと同じ発想。
  • 7×24 Auto-fetch:ノート PC のスリープで定期 sync が止まる;専用 M4 なら SSH + VNC 常駐で Memory Tree が伸び続ける。
  • 大容量 wiki:chunks.db + Obsidian + Hugging Face / Ollama キャッシュの成長が速い——1TB/2TB 拡張はM4 ストレージ FAQ参照。

ハードウェア:16GB vs 24GB と Ollama

Memory Tree の fast-score path は GPU を食いませんが、バックグラウンド embedding とサマリーは LLM を呼びます。Local AI(Ollama)をオンにするなら、M4 ユニファイドメモリはMLX / Ollama 実験と同系:16GB は軽量 sync + 小 embed モデル向け;24GB は worker 並列、大きめ embed、IDE 同時起動向け。ディスクは AI + Memory OS なら1TB からが無難です。

デプロイ手順(要約)

  1. Vuncloud Mac mini M4 をレンタル、SSH ログイン、workspace を永続ボリュームに配置。
  2. OpenHuman release をインストール、OAuth 連携を設定。
  3. 初回手動 Run ingest、wiki/ と Intelligence 指標の増加を確認。
  4. (任意)Ollama を入れ Local AI で on-device embedding。
  5. (任意)agentmemory を接続し Cursor ワークフローと recall を共有。
Memory OS ≠ AGI
OpenHuman 公式は AGI ではないと明言しています。ただし記憶、オーケストレーション、ツールチェーンでは「個人 AI OS」に近い一歩です。評価は GitBook と GitHub release note を正とし、beta 機能は迭代が速い点に留意してください。

Mac を買うか Cloud Mac を借りるか

Memory Tree が本番級の第二の脳で、Auto-fetch が仕事用メールとコードリポに接続されているなら、ローカル Mac mini のプライバシーと月額ゼロは魅力的——第二拠点バックアップやチーム共有 read-only wiki ミラーが必要になるまで。OpenHuman + agentmemory の短期検証なら週単位の専用ノードが柔軟;長期高稼働はローカル vs リモートレンタル TCOを参照。同じマシンでGitHub Actions macOS runnerも回す CI チームなら、租期を並列分割するパターンがよくあります。

FAQ

Memory OS とは? ローカル Memory Tree + Obsidian wiki + Auto-fetch 全体の比喩——記憶に ingest、ストレージ、インデックス、スケジュール、検索 API がある OS 像。

データの場所は? デフォルト ~/.openhuman/memory_tree/chunks.dbwiki/。ローカル SQLite + Markdown。

Cursor と agentmemory を共有できる? はい。memory.backend = "agentmemory" でローカル REST を指す。

RAG ベクトル DB との差は? Source/Topic/Global ツリー、digest、編集可能 wiki があり、similarity search だけではない。

Mac 必須? デスクトップ版は macOS 向け。24/7 なら Cloud Mac が定番。

OpenClaw と競合? 必ずしも競合しない。ディレクトリとリソースを分離。

beta は安定? 活発だが迭代が速い。本番なら chunks.db と wiki/ を自前バックアップ。

まとめ

OpenHuman が示す Memory OS 路線は、個人 AI を「チャット + 一時 RAG」から「ローカル優先で監査可能、同期可能な知識 OS」へ押し上げます。 Memory Tree の決定論 ingest、3 層サマリーツリー、Obsidian 二重書き込みが「Agent はなぜあなたを覚えられるのか」に答えます——より大きな context ではなく、構造化された記憶層によって。Apple Silicon 開発者なら Mac mini M4 で Ollama と agentmemory を組み合わせ、必要に応じ Cloud Mac 常駐 sync へ拡張する——2026 年に現実的な個人 AI エンジニアリングパスです。

Mac mini M4 をレンタルし、7×24 OpenHuman Memory OS を動かす

Vuncloud の専用 Mac mini M4 Cloud Macで OpenHuman、Ollama ローカル embedding、永続 Memory Tree ワークスペースをデプロイ——Auto-fetch がノート PC のスリープで止まりません。レイテンシに合わせ米東、米西、APAC ノードを選択。

Mac Mini M4 プランヘルプセンターブログへ戻る

AI 開発者

個人 AI 記憶層は Cloud Mac から

OpenHuman · Memory Tree · Ollama · 永続 wiki ディスク

M4 プランを見る
期間限定 M4 プランを見る