Date
2026/05/24
Category
Hermes Agent
Title
Obsidian vault×Hermes Agentで24時間動くAI秘書|794 upvotes事例
Obsidian の vault を、AIエージェントの長期記憶バックボーンとして使う —— このアイデアを Reddit に投稿して794 upvotesを集めた事例があります。投稿者は Reddit ユーザーの @Jonathan_Rivera、日付は2026年4月23日。「24時間動く AI 秘書が欲しい」というニーズに対して、Obsidian と Hermes Agent を組み合わせるアプローチが多くの開発者の共感を呼びました。株式会社Fyveは中小企業向けのAI業務効率化を主業務にしており、この事例は「個人ナレッジをそのまま AI 秘書に渡せるか」という観点で実務的に重要だと考えています。本記事ではこの事例の構造と、私たちが現場でどう応用できるかを分解します。
まず事実関係を3点で押さえます。
反響を示す数字は次のとおりです。
指標 | 数値 | 備考 |
|---|---|---|
upvotes | 794 | r/LocalLLaMA 上の投稿時点 |
投稿日 | 2026-04-23 | Hermes Agent v0.11.0 公開と同日帯 |
核となる発想 | vault = 長期記憶 | 個人ナレッジを外部知識層として扱う |
出典は Reddit r/LocalLLaMA の議論スレッドです。この事例が「24時間動く AI 秘書が欲しい」というニーズに刺さって 800 近い upvotes を集めたことは、欲求の存在と解決アプローチの妥当性を裏付ける一次データだと私たちは見ています。

この事例の核心は、Obsidian vault を「人間が読み書きするメモ」と「AIエージェントが参照する長期記憶DB」の兼用ストレージとして扱う点にあります。
Obsidian は、マークダウンファイルをローカルフォルダ(vault)に格納し、ファイル間を内部リンク・バックリンク・タグで結びつけるナレッジツールです。技術者・研究者・ライター層に深く浸透しており、数年単位で日次メモ・議事録・読書ログ・コードスニペットを蓄積している利用者が多数います。
一方の Hermes Agent は、2026年2月に Nous Research が公開したオープンソースの自律エージェントランタイムです。短期・中期・永続の3層メモリを内蔵し、セッションを跨いで記憶を保持する設計を持ちます。@Jonathan_Rivera のアプローチは、ここにもう一段外側のメモリ層として vault を接続する、というものです。
連携の構造を整理すると、こうなります。
つまり、エージェントが内部に閉じこもったベクタDBだけで記憶を持つのではなく、人間が編集できる外部資産を一次情報源として共有するという発想です。

Reddit で 794 upvotes を集めたという事実は、技術コミュニティが何に飢えているかを示すシグナルです。この事例から私たちが読み取った論点は3つあります。
第一に、「24時間動く AI 秘書」を欲しい層は、すでに自分のナレッジを Obsidian に貯めている。 ゼロから AI に教え込むのではなく、いま手元にある知識資産をそのまま渡したい、という具体的なニーズが背景にあります。新しい仕組みのために自分の書き方を変えるのではなく、すでに毎日書いているメモがそのまま AI の燃料になる、というのが刺さった理由です。
第二に、エージェント本体に記憶を依存させたくない、という設計上の警戒感がある。 Hermes Agent 自体はオープンソースですが、永続記憶DBの実体はベクタDBや独自フォーマットになりがちで、エージェントを乗り換えると記憶資産を失うリスクがあります。vault に書き戻しておけば、エージェント側がどう変わっても、知識はマークダウンの素朴な形で人間の手元に残ります。これは「ベンダーロックイン回避」の発想を、エージェント層に持ち込んだものと言えます。
第三に、AIに対する「所有権の主張」として機能している。 エージェントの長期記憶を vault に置くというのは、技術的な選択であると同時に、「これは自分のメモであり自分の知識資産である」という宣言でもあります。AIに何でも委ねるのではなく、人間が編集権を持ち続ける構成にする、という運用思想がコミュニティ層に響いたと私たちは見ています。
この設計は、中小企業の現場でも転用可能です。社内に散らばっている議事録・対応履歴・ノウハウメモを vault に寄せておけば、エージェントを差し替えても会社の知識資産は残ります。私たちが企業に AI 担当者として伴走する際にも、まず「会社の vault に相当する場所」を1か所決めることを最初の設計にしています。
では、@Jonathan_Rivera の発想を実際に手を動かして再現するとき、どう設計すればよいでしょうか。中小企業の現場や個人の業務に持ち込むことを想定して、私たちが推奨する手順を示します。
YYYY-MM-DD.md、トピックノートは kebab-case、議事録は meeting-{date}-{topic}.md など、エージェントが推論しやすい命名に統一する_agent_inbox/ など専用フォルダに置く。人間が確認してから vault 本体に取り込む運用にすると安全#task, #decision, #question など、エージェントが拾いやすい意味タグを最初に決めておくprivate/ 配下に隔離し、Hermes 側で除外設定する運用を始めると、人間の「メモを書く動作」とエージェントの「メモを参照する動作」が同じ vault の上で同居します。代表的な使われ方は以下です。
中小企業に応用する場合、vault は個人の Obsidian である必要はなく、社内 Wiki・Notion・Google Drive 上の Markdown フォルダなどでも同じ思想で運用できます。重要なのは、知識がエージェント所有のブラックボックスDBに入りきらない場所に置かれていることです。
「個人ナレッジを永続記憶バックボーンに使う」というアプローチは、@Jonathan_Rivera のものが代表例ではあるものの、近い設計で動いている事例が他にもあります。
これらに共通するのは、エージェントの記憶を「人間が見えない場所」ではなく「人間がいつも開く場所」に置いている点です。Obsidian vault・日次ジャーナル・過去のLinkedIn記事・iMessage 履歴 —— いずれも人間側に編集権がある外部資産であり、そこを長期記憶バックボーンとして再利用しています。

Company
株式会社Fyve
Address
〒810-0001
福岡県福岡市中央区天神4丁目6-28
天神ファーストビル7階
Tel
080-1460-2728
info@fyve.co.jp