ほとんどの人は、ノート、モデル、エージェントを<br> 別々の3つの世界として扱っている
このスタックは、それらを1つのフィードバックループに統合する:
Obsidian を記憶、Hermes をエージェント、MiniMax M3 を推論コアとして
「ノートアプリ」よりも「ナレッジスタック」が優れている理由
従来の PKM は、次の3つの予測可能な形で破綻する:
- ノートは一度書かれて、二度と更新されない
- AI チャットは賢いが記憶がない - 毎回ゼロからのスタート
- 本格的な作業に必要なコンテキストは、あなたとモデルの両方の RAM から常に溢れてしまう
私たちが実際に欲しいもの:
- 知っているすべてのことに関するローカルでリンク可能なグラフ
- そのグラフの内部に存在し、その上に存在しないエージェント
- たった2〜3パラグラフではなく、膨大な実際のコンテキストで推論できるフロンティアモデル
Hermes + MiniMax M3 + Obsidian がこれを実現する:
- Obsidian - バックリンク、グラフビュー、パーソナルナレッジベース向けに設計されたプラグインエコシステムを備えたローカル Markdown グラフ
- Hermes Agent - 組み込みの学習ループ、ツール、長時間実行ジョンを備えた自己改善型のオープンソースエージェントで、自身のインフラ上で動作する
- MiniMax M3 - 私が実際に Hermes 内で毎日実行しているモデル。ロングコンテキスト、マルチモーダル、エージェンティック。これを選んだのは、RAG パイプラインを自分で接着することなく、1つのコンテキストウィンドウで Vault 全体、ログ、新しい未加工の記事の山を読める1つのモデルが欲しかったからだ。数ヶ月実際に使った後も、デフォルトのまま使い続けている。その理由は後述する
この結果は、「LLM を使っている」というよりは、「ゆっくりとセカンドブレインを訓練している」ように感じられる
私が M3 を選んだ理由（そして気づいたこと）
私はベンチマーク結果で M3 を選んだわけではない
私が選んだのは、2025年に試した他のモデルはすべて、私のワークフローで同じ失敗の仕方をしたからだ:
1つのノートを要約するのは問題ないが、10個のノートを読んで、MOC とクロスリファレンスし、新しいノートを書き戻すように依頼すると、すぐに内容を見失ってしまう
症状はいつも同じだった:
- 要約は局所的には首尾一貫しているが、全体的には間違っている
- 実際にはファイルに存在しないプロジェクトを引用する
- 異なる分類法のタグを使用する
- 存在しないページへの Wiki リンクをでっち上げる
モデルは賢かった。ワークフローがモデルの能力を超えていたのだ
M3 は、私が試した中でグラフ全体がコンテキストに収まり、タスク全体を通してそこに留まり続けた最初のモデルだった
実際の使用で際立った3つの点:
- 私の分類法を実際に使う 私は固定スキーマ（#coin/\, [#project](https://x.com/search?q=%23project&src=hashtag_click)/\, #concept/*, #solana 内部, #meta）で約41個のタグを持っている。M3 に新しいノートをまとめるように依頼すると、初回で正しいプライマリタグを選ぶ確率は約90%。
200K コンテキストのモデルでは約60%だった。違いは、M3 がタグの状況全体を一度に見渡し、いくつかの例から推測するのではなく、その上で推論できることだ。
- 長いエージェントループでも内容を見失わない Vault 全体の lint は30回以上のツールコールになる: MOC を読む、Wiki リンクをたどる、タグを数える、重複をスキャンする、レポートを書く。
ほとんどのモデルは8〜9コールあたりでずれ始める。
M3 は最後まで首尾一貫している。これが、20分ごとに新しいセッションにコンテキストをローテーションするのをやめた最大の理由だ。
- 前方参照を機能として扱う ノートをまとめるように依頼したときに、そのコンセプトがまだ存在しない場合、M3 はとにかく Forward Reference を書く。
Obsidian はそれをグレーのリンクとして表示する。私は週に一度 lint のときにそれらをトリアージしている。
これは、偽のノートをでっち上げたり、リンクを完全にスキップするモデルよりもはるかに優れている。
数ヶ月使用した後の正直な3つの注意点:
- 初回呼び出しのレイテンシが高い。 Hermes はコンテキストをプリロードする。最初の3秒で M3 を判断しないでほしい - 10秒待ってほしい。
- 存在しないページへの [[wikilink]] を自信満々に書くことがある。 これは上記の「前方参照」の動作だ。週次の lint をスキップしなければ問題にはならない。
- マルチモーダルは本物だが、図の多い PDF では、今でもまず専用のビジョンツールを使う。 M3 は画像や短いスクリーンショットからのテキスト読み取りは問題ない。図を含む全面ページには、適切なツールではない。
これがすべての要点だ。
このモデルは、Vault のワークフローが必要とするまさにそのこと、つまりグラフ全体を一度に読み、構造を失うことなく書き戻すことが得意なのだ。
レイヤー1 – Obsidian をグラウンドトゥルースとして
Obsidian は、このスタックにおける地味だが重要なベースレイヤーである
- あなたの知識は、誰かのクラウドにロックされることなく、ディスク上のプレーンな Markdown ファイルとして存在する
- バックリンク、グラフビュー、デイリーノートは、アイデアがチャット履歴に消えるのではなく、クラスターに収束するのを助ける
- プラグインは Obsidian を、エージェントが体系的に横断できる文書、タスク、データセットのプログラマブルなグラフに変える
原理はシンプルだ:
価値があるなら、まず Obsidian に置く エージェントが何か有用なことをしたなら、それはノートとして保存されるべきだ
実用的な構造:
1/obsidian-vault2 /inbox3 /people4 /projects5 /research6 ai-agents.md7 minimax-m3-benchmarks.md8 /ai9 hermes-playbook.md10 agents-ideas.md
Hermes はこれらのノートを読み、リファクタリングし、作成する - しかし Vault は依然として信頼できる情報源である
レイヤー2 – Hermes を自己改善型オペレーターとして
ここが、スタックが単なる「LLM 付きノートシステム」からインフラストラクチャとして機能し始めるポイントだ
Hermes Agent は、@NousResearch によって構築された自己改善型 AI エージェントである
それは、あなたとあなたの仕事に関する永続的なモデルを維持し、経験からスキルを作成し、使用中にそれらを改善し、毎回リセットする代わりに関連するコンテキストを呼び出すために自身の過去の会話を検索する
Hermes は主に2つの方法で実行できる:
- Linux、macOS、WSL2 上の CLI ツールとして
- Hermes Desktop 経由 - macOS、Windows、Linux 用のネイティブアプリで、同じエージェントコアを GUI でラップしたもの
インストール方法
macOS / Linux / WSL2 (CLI)
この1行で Hermes Agent をインストールし、環境をセットアップし、グローバルな hermes コマンドを公開する
1curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
インストール後:
1source ~/.bashrc 2>/dev/null || true2source ~/.zshrc 2>/dev/null || true3hermes
Windows PowerShell (CLI)
1irm https://hermes-agent.nousresearch.com/install.ps1 | iex
Windows インストーラーは Python 3.11、Node.js 22、ripgrep、ffmpeg、ポータブル Git Bash を処理し、hermes を PATH に追加する
Hermes Desktop (GUI)
ターミナルを使いたくない場合は、公式デスクトップページから Hermes Desktop をダウンロード し、macOS、Windows、Linux 用のネイティブインストーラーを実行する。
- Desktop は、CLI ファーストのセットアップの代わりにネイティブ GUI、よりシンプルなオンボーディング、手動でのシェルブートストラップなしで同じ Hermes コアを使用したい場合に使用する
- CLI は、再現性、スクリプト化、リモートサーバー/VPS へのデプロイ、ツール、環境変数、長時間実行ワークフローの厳密な制御を必要とする場合に使用する
ほとんどの人は両方を使うだろう: 日常的な操作には Desktop、セットアップ、自動化、リモートワークには CLI
アーキテクチャ – スタックが実際にどのように連携するか
明確なメンタルモデル:
1Obsidian Vault2 ↓3Hermes Agent4 ↓5MiniMax M36 ↓7更新されたノート、要約、スキル、スケジュールされたジョブ
各レイヤーには明確な役割がある:
- Obsidian はノートを Markdown ファイルとして保存し、インデックス作成、検索、差分、バージョン管理を容易にする
- Hermes はオーケストレーションレイヤーである – ファイルを読み、ツールを実行し、以前の作業を記憶し、ジョブをスケジュールし、有用なものをいつ永続化するかを決定する。メッセージングプラットフォームやゲートウェイに接続することもできる
- MiniMax M3 はこのスタックの推論エンジンである。大量のノートコレクションを読み、乱雑なノートを書き換え、Vault 全体のドキュメントを比較し、20ツールコール前のコンテキストの先頭を忘れることなく、長時間のエージェントタスクを処理する
- 私のワークフローでは、この最後の点が鍵となる: Vault 全体の lint、MOC 間のリファクタリング、または「この記事を5セクションのノートにまとめて3つの MOC を更新する」という30コールのタスクがすべてエンドツーエンドで首尾一貫する
- 「MSA アーキテクチャ」という主張はマーケティングだ。実際の経験はこうだ: 1つのタスクを20分間実行しても、モデルは1分目に何を依頼したかを覚えている
Hermes は Obsidian を置き換えるものではない。Vault とモデルの間に位置し、Vault を実用的なものに変える
現実的なループ:
- Obsidian で生のアイデアをキャプチャする
- Hermes が Vault または特定のフォルダを読む
- Hermes が関連するノートセットを MiniMax M3 に送信する
- M3 が素材を再構成、タグ付け、リンク、要約、または拡張する
- Hermes が結果をクリーンな Markdown として Vault に書き戻す
そのループ - 1回限りのチャットではない - こそが実際のプロダクトである
実際のセットアップ – Hermes を Vault に接続する
Obsidian Vault を通常のファイルシステムの場所に置き、そのパスを Hermes に公開する。
macOS / Linux
1export OBSIDIAN_VAULT="$HOME/Documents/Obsidian/MainVault"2ls "$OBSIDIAN_VAULT"
Windows PowerShell
1$env:OBSIDIAN_VAULT="$HOME\Documents\Obsidian\MainVault"2Get-ChildItem $env:OBSIDIAN_VAULT
次に Hermes セットアップウィザードを実行する:
1hermes setup
または、Nous Portal 経由の最短パス（自動プロバイダー、Tool Gateway 等）の場合:
1hermes setup --portal
公式ドキュメントでは、主要なオンボーディングコマンドとして \hermes setup\ を、アカウントおよびプロバイダーリンク構成のショートカットとして \--portal\ を推奨している
次にインストールを確認する:
1hermes doctor
hermes doctor は依存関係、PATH、プロバイダー構成をチェックし、モデルやツールの配線を始める前によくある問題を報告する
モデルレイヤー – Hermes を MiniMax M3 に配線する
Hermes は「どのモデルを使うか」をハードコードされた前提ではなく、ファーストクラスの構成として扱う。
設定ファイルを手動で編集するのではなく、Hermes 自身を使ってモデルを選択・更新する。
主要なコマンド:
1hermes model
これによりモデル選択フローが開き、Hermes がサポートするプロバイダーとモデルをリストアップし、MiniMax M3 を公開するバックエンドを選択できるようにする。
実用的なセットアップパス:
- Hermes をインストールする（CLI または Desktop）
- hermes setup または hermes setup --portal を実行する
- hermes model を実行する
- MiniMax M3 へのアクセスを提供するプロバイダーパスを選択する
- それをデフォルトのロングコンテキストモデルとして保存する
環境変数とプロバイダー形式が既にわかっている場合は、特定の値を次のように設定することもできる:
1hermes config set
ドキュメントでは、hermes config set がファイルを手動で編集せずに個々の設定値を書き込むサポート対象のメソッドであるとしている。
私の日々のセットアップでは、M3 は通常複数のモデル呼び出しに分割しなければならないものすべてのデフォルトである。具体的には:
- 答えが単一ファイルではなくグラフ全体に依存する、大量のノートフォルダを読むこと
- 重複または重複するノートのマージ - これはテキスト問題ではなくグラフ問題である
- 自分の口調で構造化された要約と概要を書くこと（5セクションテンプレート、41タグ分類法）
- コンテキストが増え続ける長いリサーチチェーン - 「まとめて、3つの MOC を更新して、3つのスレッドアイデアを書く」というような未確定のタスク
- コードが多く複数ステップのエージェントタスクで、モデルが20回以上のコールにわたって自身のツール履歴を覚えておく必要があるもの
私は Hermes 内に小さくて高速なモデルを、小さなユーティリティアクション（ファイル名変更、文字列検索、YAML フォーマット）用に保持している。
上記のすべてには、M3 を使用する。大まかな分割は: 機械的なタスクには安価なモデル、推論タスクには M3。数週間後には、ルーティングは意識しなくなる。
経験則:
小さなユーティリティアクションには高速で安価なモデルを使う。大きなコンテキスト、構造、または長い推論に依存するものには MiniMax M3 を使う。そこが、このスタックが標準的なチャットよりも有意に優れている点である
作業パターン – 実際にスケールするフォルダ構成
これを実際の人々のために機能させたいなら、Vault の構造が重要である。
実用的なレイアウト:
1MainVault/2 Inbox/3 Projects/4 People/5 Reading/6 Daily/7 Reviews/8 AI/9 Hermes/10 MiniMax/
これが機能する理由:
- Inbox/ は生のキャプチャとラフなダンプを受け止める
- Daily/ は低摩擦な日々のログのため
- Reading/ はソースノート、ハイライト、引用を保持する
- Projects/ は耐久性のあるアウトプットと進行中の作業を保存する
- Reviews/ は週次および月次の統合を保存する
Hermes は、各フォルダに明確な役割があるときに最もよく機能する。Vault が混沌としている場合でも、Hermes は役立つだろうが、改善することではなく、混乱を解釈することにより多くの時間を費やすことになる
シンプルな運用ルール:
- 人間は Inbox/、Daily/、Reading/ に自由に書き込む
- Hermes は Projects/、Reviews/、そして AI/ のようなトピックフォルダに要約することが許可されている
- 長期的なノートは、安定した予測可能なフォルダに存在する
これにより、たとえ YAML で形式化しなくても、エージェントに許可の境界が与えられる。
実際に自動化する価値のあるジョブ
最も強力な Hermes のユースケースは「1つの質問に答える」ことではない - それらは繰り返し発生する変換である
具体的な例:
- 昨日のデイリーノートを構造化された要約に変換する
- 10個のラフなリーディングノートを1つのエバーグリーンノートにマージする
- プロジェクトフォルダから未解決の質問を抽出する
- 散らばったノートから週次レビューを構築する
- 現在のノートを古いノートと比較し、変化した意見を強調表示する
ここで MiniMax M3 がその価値を発揮する。
標準的なショートコンテキストモデルは、単一のノートをうまく要約できる。
M3 は、Vault 内の50個のノートフォルダを要約し、10個の MOC とクロスリファレンスし、私自身の口調とタグを実際に使った1,000語の概要を提案できる – グラフ全体を見たからだ。
私が最も頻繁に実行するジョブ: 新しい記事を raw/ にドロップし、M3 にそれを5セクションのノート（# Profile → # Context in my research → # Links into vault → # Tags → # Related）にまとめるように依頼し、そして見守る:
- 私の41タグ分類法から正しくタグを選ぶこと、
- 既存のノートに8〜12個の Wiki リンクを書くこと、
- どの MOC を更新する必要があるかを教えてくれること。
200K モデルでは、これら4つのうちおそらく3つしか正しくできなかった M3 では、約500ファイルの Vault で、1回のパスで4つすべてを正しく実行できる
複合的な効果: このスタイルでコンパイルしたすべてのノートは、次に私が質問するときの M3 のコンテキストの一部になる。
毎週のコンパイルを6ヶ月続けると、モデルは私の口調、タグシステム、どのような作業にどの MOC を更新するかを「理解」する – 何も再トレーニングすることなく。
ターミナルからの典型的なフロー:
1hermes
次に、Hermes 内で次のようなタスクを依頼する:
- 「Reading/AI Agents/ のすべてを読んで、agent-architecture-overview.md という1つの統合ノートを作成して」
- 「Daily/ の過去7日間をスキャンして、Reviews/2026-W24.md に週次レビューを書いて」
- 「Inbox/ と Projects/ 全体で重複するアイデアを見つけて、マージを提案して」
正確な言い回しは自由だが、核となるアイデアは: すべてのタスクは実際のフォルダにマッピングされ、実際の Markdown アウトプットを生成する、ということである
スケジューリングと無人作業
Hermes はチャットだけでなく、ゲートウェイ、スケジューラー、バックグラウンド実行のために構築されている
これは重要である。なぜなら、最高の PKM ワークフローは通常、アドホックではなく非同期であるからだ。
便利なスケジュールジョブ:
- 毎朝08:00 - 昨日のノートを要約して Reviews/ にデイリーサマリーを作成する
- 毎週金曜日 - Daily/ と Projects/ から週次レビューを生成する
- 1日1回 - 孤立したノートや構造的な問題をスキャンする
- 毎晩 - 新しいリーディングハイライトをアトミックノートに変換し、リンクする
アーキテクチャのシフトは大きい:
- チャットの回答は消える
- スケジュールされたメンテナンスノートは複合的に成長する
時間が経つにつれて、その複合効果こそが「単なるノート」を真のセカンドブレインに変えるのだ
完全な実践パス、エンドツーエンド
1. Hermes をインストールする
macOS / Linux / WSL2:
1curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
Windows:
1irm https://hermes-agent.nousresearch.com/install.ps1 | iex
Desktop:
- 公式デスクトップページから Hermes Desktop をダウンロードし、macOS、Windows、Linux でネイティブインストーラーを実行する。
2. エージェントを設定する
1hermes setup2# または3hermes setup --portal
3. ヘルスを確認する
1hermes doctor
4. モデルを選択する
1hermes model
MiniMax M3 を公開するプロバイダーパスを選択し、ロングコンテキストワーク用のデフォルトモデルとして保存する。
5. Hermes を起動して現実のものにする
1hermes
この時点で、最初の有用なアクションは「コードを書く」ことではない。以下のことだ:
- Hermes を Vault に向ける
- 正確に1つのフォルダを与える
- 1つのクリーンな Markdown アーティファクトを生成するように依頼する
- Obsidian でそれを開き、結果を検査する
- このワークフローが退屈で信頼できるものになるまで反復する
1つのループがしっかりと感じられるようになったら、別のループを追加する -> そしてまた別のループを。
これが、Hermes + MiniMax M3 + Obsidian をクールなアイデアから実際のインフラへと変える方法である
これが役に立ったなら:
- この記事をブックマークしてください。リンクは変わり、新しいリポジトリが毎週登場します - リファレンスとして必要になるでしょう
- 上記のスレッドにいいねとリポストをして、他のビルダーがチャットボットの罠から抜け出すのを助けてください
- AI アーキテクチャ、クオンツトレーディング、エージェント経済に関する週刊の深掘り記事については、私をフォローしてください: @polydao
- TG チャンネルに参加: Buzzoni Notes - ここでは、生のプロンプト、カスタムスキル、X には早すぎるアルファ情報を共有しています
読むだけじゃない。構築しよう。今日からワークフローを変えよう
