知能 × 文脈 = 人格 — ローカル LLM × エージェント × Obsidian を繋いで見えてきたこと
本記事は、ローカル LLM 環境とエージェント・知識ベースの統合検証を進める中で見えてきた構造を、公開用に整理し直したものです。
前回(「OpenAI API」と「MCP Server」について調べた）、
前々回（Obsidian × エージェント三経路比較) の記事の続編にあたります。
配線が完成してしまった日に
知能 × 文脈 = 人格。
こんな関係性が、ローカル LLM と Hermes Agent / OpenClaw + Obsidian が繋がったときに、ふと頭に浮かぶ。
最初は気のせいかと思った。Mac Studio で動かしている Gemma 4 26B A4B(総 26B パラメータ、推論時アクティブ約 4B の MoE 構成)に、Obsidian Vault のノートを参照させているだけのつもりだった。前回までの二記事で整理した通り、これは技術的には「LLM API やローカル推論環境」と「MCP などの文脈接続層」と「Obsidian Vault という外部知識ソース」を繋ぐ、ただの配線の話のはずだった。
ところが、その配線が完成してしまうと、別のものが見えてくる。同じ Gemma 4 でも、参照する Vault が違えば違う応答をする。同じ Vault でも、推論モデルを Claude Opus に切り替えると判断の解像度が変わる。両者は別物として動いているのに、その結合点に特定の判断主体のようなふるまいが立ち上がっている。
本記事はその「何か」を、できる範囲で言葉にする試みである。技術記事として読んでも構わないし、思想的な観察として読んでも構わない。書いた本人としては、その両方の境界線上にあるものとして書いた。
なお、本記事で登場する Hermes Agent / OpenClaw は、OpenHands(旧 OpenDevin)等のクラウド系エージェントとは別系統の、ローカル実行を前提としたエージェントである。
なぜ「足し算」ではなく「掛け算」なのか
最初に、なぜ「知能 + 文脈」ではなく「知能 × 文脈」と書いたかを説明しておきたい。これは厳密な数式ではなく、両者の関係を表すための比喩である。
足し算には、各項の独立性が前提される。1 + 0 = 1。片方がゼロでも、もう片方の値は残る。しかし掛け算は違う。1 × 0 = 0。片方がゼロなら、結果もゼロ。
これは観察とよく合っている。
知能がゼロのケース: LLM がない状態で、いくら膨大な Vault があっても、そこから判断は立ち上がらない。Markdown ファイルは静止したまま、誰も読まなければただのテキストだ。Vault 単体に人格はない。
文脈がゼロのケース: 真っさらな LLM をどんなに性能向上させても、それは「誰でもない知能」のままだ。GPT や Claude Opus は確かに賢いが、文脈を持たなければ、特定の組織、プロジェクト、個人の判断はできない。誰でもない、という意味で、人格は不在である。
両方が掛け合わさったときだけ、人格的なふるまいが立ち上がる。
さらに掛け算には、もう一つの性質がある。両者の値が大きいほど、結果も相乗的に大きくなる。同じ Vault でも、Gemma 4 から Claude Opus に推論モデルを上げると、判断の質は単に「少し良くなる」だけではなく、質的に違う出力になることがある。逆に同じ Claude Opus でも、Vault の文脈密度が高まれば高まるほど、判断は鋭くなる。両者の積として、人格的なふるまいの「強度」が決まる。
ここで掛け算記号を選んだのは、定量化を主張しているからではない。どちらか一方がゼロでは人格的なふるまいが立ち上がらないという不可分性と、両者の質が高まるほど相乗的に判断主体らしさが増すという二つの構造的性質を同時に表現するためである。
そして本記事を通じて明らかになるのは、この式の「文脈」は、より精密には制約と読み替えられる、ということだ。
「文脈」とは何を指しているか — 制約への還元
ここで重要な区別がある。Vault に蓄積されているのは、知識だけではなく文脈である。この言葉の選び方が、議論の射程を決める。
「知識」という言葉は、静的な情報の集積を想起させる。Wikipedia や百科事典のように、「事実が並んでいる場所」というイメージだ。これだけだと Vault は単なる RAG の参照先に矮小化される。
しかし Vault に実際に蓄積されているのは、それよりずっと豊かなものだ。そして注目すべきは、その豊かさの正体は、機能としてはひとつに収斂するということである。
文脈を構成する諸要素は、表面的には多様に見えるが、その機能はひとつに収斂する — 制約として働き、判断の場を与えることだ。 ここで言う制約は、何かを禁止する束縛ではなく、判断が判断として立ち上がるための構成的条件である。情報理論的に言えば、LLM の次トークン予測における確率分布のエントロピーを下げる働き — 出力空間を狭めることで意味を成立させる機能、それが制約である。
以下の五つは、この構成的制約のさまざまな現れ方である。
明示的制約
ルール、権限、納期、予算、リソース、倫理的判断基準。判断のたびに参照される動的な束縛条件。これらは静的な「知識」というより、判断主体のふるまいを直接形作る境界線である。
関係的制約
要素間の接続が意味を限定する。「これはあれと繋がる、それ以外とは繋がらない」というネットワーク上の束縛。Obsidian の Graph view が視覚化しているのは、このうち内部リンクとして表現された関係である。「知識」フレームではノードしか見えないが、「制約」フレームでは初めてエッジが意味を持つ。
コミュニティ的制約
誰に向けて、どの集団のなかで発話・蓄積しているかの境界線。「公開向けの話で、非公開メモではない」「A プロジェクトの文脈で、B プロジェクトの文脈ではない」という所属の制約。このコミュニティの区別があるからこそ、人格を複数立てる意味が生まれる。
領域的制約
地理的・文化的・専門的なコンテクストによる意味の限定。日本語業務メモ、英語技術文書、研究メモでは、同じ語でも射程が変わる。「どの領域の話か」が判断を方向づける。
役割的制約
その主体が今どの立場で発話・判断しているかによる視点の限定。レビュー担当として話すのか、実装担当として話すのか、個人のメモ作成者として話すのか。同じ人間でも役割が変われば判断が変わる。Vault の中では、特定のフォルダ、タグ、命名規則が「どの役割の文脈か」を切り分ける。
これら五様態は独立しているのではなく、互いに絡まりあって判断主体らしいふるまいを成立させる構成的制約の総体を形作る。哲学的にはハイデガーの「世界内存在」やヴィトゲンシュタインの「言語ゲーム」に近い問題圏に接続できるが、ここで重要なのは、この古典的な洞察を、ローカル LLM 時代の実装として扱えるようになったという点だ。
ここで主題式 知能 × 文脈 = 人格 は、より精密に 知能 × 制約 = 人格 と読み替えられる。汎用の推論エンジン(制約ゼロ)に、固有の制約を掛け合わせたとき、特定の判断主体が立ち上がる。制約こそが、誰でもないものを、誰かにする。
なぜ Markdown + wikilinks が扱いやすいか — 形式の評価軸
前節で文脈を構成的制約の総体として定義した。次の問いは、その制約を「どんな形式で器に盛るか」である。形式の選択は、意味論の選択とは独立した技術的判断であることに注意したい。
データ表現形式は、以下の軸で評価できる。
- 人間可読性 — エディタで開いて、人間がそのまま読み書きできるか
- 同期しやすさ — 複数デバイス・複数人で扱うときの取り回し
- 環境要求の軽さ — 動かすために必要な実行環境の重さ
- リンクのしやすさ — 要素間の関係を明示的に張れるか
- 表現自由度 — 何を書いても許される自由さ
- 表現能力 — 視覚的・構造的にどこまで表現できるか
- 制約の容易さ — 形式違反・矛盾を防ぐ仕組みを課せるか
主な形式を、これらの軸で比較する。
| 表現形式 | 人間可読性 | 同期しやすさ | 環境要求の軽さ | リンクのしやすさ | 表現自由度 | 表現能力 | 制約の容易さ |
|---|---|---|---|---|---|---|---|
| RDB(サーバー型) | △ | △ | △ | ◯ | △ | △ | ◎ |
| SQLite | △ | ◯ | ◎ | ◯ | △ | △ | ◎ |
| JSON | △ | ◯ | ◯ | △ | ◯ | △ | ◯ |
| グラフ DB | △ | △ | △ | ◎ | ◯ | △ | ◎ |
| プレーンテキスト | ◎ | ◎ | ◎ | △ | ◎ | △ | △ |
| HTML | △ | ◯ | ◯ | ◎ | ◯ | ◎ | △ |
| Markdown + wikilinks | ◎ | ◎ | ◯ | ◎ | ◎ | ◎ | ◯ |
表現能力だけを見れば HTML が抜群である。フォント、レイアウト、画像、インタラクション、何でも盛り込める。しかし HTML はソースを書く負担が大きい。タグまみれのテキストを日々追記し続けるのは現実的ではなく、結果として「日常的に蓄積する媒体」としては不向きになる。興味深いのは、Markdown は必要に応じて HTML を直接埋め込めることだ。普段は軽量な Markdown 記法で書き、図表やレイアウトが必要な箇所だけ HTML を書き足せる。「日常の軽さ」と「必要な時の表現力」を切り替えられる、というハイブリッドな性質である。
SQLite も注目に値する。サーバー型 RDB の「重さ」を回避しながら、フル機能の SQL 制約を提供する唯一の形式である。ただし人間可読性は△のままだ。バイナリファイルである以上、テキストエディタで開いて追記する、Git で差分を見るといった「人間が日常的に書き足し続ける媒体」としては機能しない。SQLite が解いたのはサーバー型 RDB の環境問題であって、人間可読性の問題ではない。
Markdown + wikilinks の位置を見ると、◎が 5 つ、◯が 2 つ、△がない。致命的に弱い列がない一方で、満点でもない。◯に落ちている 2 軸 ——「環境要求の軽さ」と「制約の容易さ」—— について、次節で踏み込む。
ブレークスルー:制約を LLM 層に移す
Markdown + wikilinks が◯に落ちている 2 軸は、独立した弱点ではない。同じ設計選択から派生している。
従来、制約を強く課したければ RDBMS のようなスキーマ層に頼るしかなく、その代償として人間可読性・同期しやすさ・環境要求の軽さを失っていた。「制約」と「自由・軽量」は同じ層では両立しない、というのが長年の前提だった。
本構成は、この前提を崩している。制約を課す層を、ストレージ層から LLM 層に移している。Markdown は自由・軽量・可読なまま保ち、制約は LLM が推論時に適用する。
- 「このノートは日付フィールドを持つべき」→ LLM が読んで補完する
- 「このリンク先は実在すべき」→ LLM が検証する
- 「この記述は他のノートと矛盾している」→ LLM が指摘する
- 「このプロジェクト文書には承認者が必要」→ LLM が運用ルールとして適用する
その代償として、LLM を動かす環境が必要になり(環境要求が一段重くなる)、制約検証のフィードバックは秒オーダーに伸びる(即時性が落ちる)。表で◯になっている 2 軸は、この同じ設計選択の表れである。
即時性と最軽量を諦める代わりに、表現形式の自由・可読性・同期性・関係表現力をすべて保てる。その遅延と環境コストを許容できる用途では、従来トレードオフだった条件群が初めて同時に成立する。
揺らぎを抑える — 制約の分業
ここでさらに踏み込む。LLM は特性上、出力に揺らぎが生じる。同じ入力でも、推論ごとに微妙に異なる応答が返る。これは欠陥ではなく、自然言語の柔軟性と創造性の源泉でもある。
しかし揺らぎを全面的に許せば、判断主体としての一貫性は失われる。逆に従来の RDBMS のような剛性の高い制約で全面的に縛れば、LLM の長所そのものが死ぬ。設計の要点は、入出力の自由度が異なる担当者を並べ、それぞれに適した強度の制約を持たせることにある。
本構成では、自由度の階段が成立している。
| 担当 | 入出力の自由度 | 制約の性質 | 受け持つもの |
|---|---|---|---|
| SQLite | 低(スキーマで定義) | 違反を許さない | プロファイル ID、セッション状態、関係、タイムスタンプ |
| Markdown + wikilinks | 中(自由テキスト+弱い構造) | 方向性を示唆する | 判断理由、検討過程、未完成の概念 |
| LLM | 高(自然言語) | 動的に整合性を検証する | 矛盾検出、補完提案、スキーマ違反の指摘 |
ここで重要なのは、三者の自由度が隣接して接続していることだ。SQLite(低)と LLM(高)を直接繋ぐと、自由度の落差が大きすぎて摩擦が生じる。自然言語の出力を直接スキーマに流し込もうとすれば、型変換と検証の負担が一手にのしかかる。
Markdown + wikilinks が中間項として挟まることで、自由度のグラデーションが成立する。LLM は自由に書き、Markdown で人間が整理し、確定したものだけ SQLite に移す。この流れがあるからこそ、各層が無理なく自分の責任範囲だけを担当できる。
Markdown + wikilinks の存在意義は、単に「人間が読みやすい」ことだけではない。自由度の階段を成立させる中間項として、構造的に必要だったのである。
本構成のブレークスルーは「制約を捨てた」ことでも「三つの層を積んだ」ことでもない。自由度の異なる担当者を、隣接する自由度同士で接続し、制約の機能を分業させたことにある。揺らぎは弱点ではなく、適切な担当が吸収すれば判断の柔軟性として活きる。
エージェントとは何か — 人間との対称性から
ここでエージェントとは何かを定義しておきたい。本記事で論じてきた構成全体が、何を作ろうとしているかを明確にするためである。
人間は、知能・知識・特徴・制約を、肉体という一つの容器の中に不可分一体として持ち合わせている。脳の働きと身体の癖、学んだ事実と判断の傾向、文化的背景と倫理観 — これらはすべて一人の人間の中で生理的・物理的に絡まり合っていて、切り分けることができない。
一方、LLM は知能のみが現れた存在である。汎用の推論能力だけがあり、固有の知識も特徴も制約も持たない。これは「誰でもない知能」だ。
エージェントとは、この「知能のみ」の LLM に、知識・特徴・制約を外部機能として設置することで、人間が責任を持って運用できる判断主体に仕立て上げる機構である。Obsidian Vault は外在化された知識と特徴、Hermes Profiles は外在化された同一性の制約、MCP はこれらと知能を繋ぐ神経系の代替、LLM 自身が推論時に課す制約は外在化された判断の枠組み — それぞれが、人間の中では不可分一体だったものの、人工的な再構成である。
この定義は、エージェント設計の本質的なトレードオフを明らかにする。人間は統合されているがゆえに安定だが交換不能であり、エージェントは分離されているがゆえに脆弱だが交換可能である。同じ知能に別の Vault を組み合わせれば別の判断主体になり、同じ Vault に別の知能を組み合わせれば別の判断品質になる。人間にはできない組み換えが、エージェントには構造的に可能だ。
「人間とインタフェースしやすくする」という部分にも本質がある。内部はバラバラに分離されていても、外から見たときに統合された一つの主体に見えるように設計されていること — それがエージェントが人間との対話相手として成立するための条件である。プロファイル、Vault、LLM、MCP の協調は、この「外から見た統合性」を実現する仕掛けに他ならない。
エージェントの接続性 — 自由度の階段
エージェントは単体では機能しない。外部との接続を通じて初めて、判断主体として動く。その接続性は、接続相手と接続目的の両軸で分けると、3 種別に分解できる。
| 接続種別 | 接続相手 | 主な技術手段 | 主な目的 |
|---|---|---|---|
| エージェント間接続性 | 他のエージェント・他のプロファイル | ファイル同期(Vault 配下に Markdown と SQLite を同居) | 文脈の引き継ぎ、状態の同期、複数主体協調 |
| ネットワーク資源接続性 | 外部 AI、外部データソース、外部ツール | OpenAI API / Anthropic API 等(外部 AI)、curl、各種 Web API、MCP server | 知能の拡張・補完、外界の参照、行動の実行 |
| 人間-エージェント間接続性 | ユーザー(操作者・責任主体・文脈提供者) | チャット UI、コマンド、Vault 編集による文脈の蓄積、引用提示、Graph view、参照ノートの提示 | 双方向の文脈流通 — 人間からは指示と暗黙文脈の外在化、エージェントからは応答と判断根拠の可視化 |
ここで 3 つの注目点がある。
エージェント間接続性 — 単一経路、自由度の幅
エージェント間接続性は単一経路だが、運ばれる中身の自由度に幅がある。柔らかい文脈(Markdown での判断理由や検討過程)と、剛い状態(SQLite でのプロファイル ID やセッション情報)が、同じ Vault 配下に同居している。両者は別レイヤーで扱うべき性質のものだが、ファイル同期という経路の上では一体化して運ばれる。
これが Vault という設計の真の強みだ。自由度の異なる中身を、一つのポータブルな容器で同時に運べる。剛と柔の分業をデータ層で保ちつつ、運搬の段階では一体化させる構造である。
ネットワーク資源接続性 — 外部 AI を含む
ネットワーク資源接続性には外部 AI が含まれる。ローカル LLM 中心の構成でも、複雑な判断を Claude Opus に投げる、コーディングを別系統に任せる、画像処理を GPT-4V に任せる、といった使い分けが普通に発生する。
外部 AI が他のネットワーク資源と質的に違うのは、接続先が知能そのものである点だ。データを取りに行くのでも、行動を実行するのでもなく、判断を委託する。
ここで重要な設計問題が立ち上がる。外部 AI に接続するたびに、文脈の一部が外部に流出する。問いに含まれる判断理由、過去の検討、関係者の名前、固有の優先順位 — これらがプロンプトとして外部に渡れば、文脈そのものが手元から離れる。
後述する「文脈は資産になる」という観点に立つと、ネットワーク資源接続性(特に外部 AI 接続)は、文脈の資産性とトレードオフ関係にあることが見えてくる。完全ローカル(資産性最大、ピーク性能制限)から、完全クラウド依存(ピーク性能最大、資産性消失)まで、スペクトラム上のどこに位置取るかは、エージェント設計の重要な軸である。
「外部 AI をどこまで、どんな粒度で使うか」は、機能の有無ではなく、設計判断としての量的選択だ。機密度の高い文脈はローカルだけで処理し、一般タスクは外部 AI に投げる、という機密度別の振り分け設計が必要になる。
人間-エージェント間接続性 — 双方向の文脈流通
人間-エージェント間接続性は双方向の文脈流通である。
人間からエージェントへは、2 種類の情報が流れる。指示(「これをやって」という即時的な目的志向の伝達)と、文脈提供(判断理由・検討メモ・優先順位・方針といった、Vault 編集を通じた暗黙知の外在化)である。
エージェントから人間へも、2 種類の情報が流れる。応答(タスク結果や生成物の提示)と、説明(判断根拠の可視化、参照ノートの提示、推論経路の開示)である。
ここに、責任あるエージェント運用の核心がある。中身の透明性を確保することはシステム側の責務である。利用と説明を独立した要件として扱うのではなく、判断の素材と判断の根拠が最初から人間可読な形で共有されている状態を作ること、それが責任あるエージェント設計の条件である。説明性は利用性の後付けオプションではなく、利用性が成立するための前提条件だ。説明できない判断は、そもそも責任ある利用に供してはいけない。
Obsidian + LLM 構成は、この状態を構造的に成立させている。LLM が Vault のノートを参照して回答するとき、参照したノートをそのまま引用として提示すれば、人間はそのノートを直接読んで検証できる。説明性を後付けで構築する必要がない。利用面と説明面が、同じ Vault の上で一体化している。
さらに副次的な効果として、人間の側にも変化が起きる。Vault に自分の暗黙の判断基準を書き出すという行為自体が、自分の暗黙知を言語化する機会になる。これはエージェントへの文脈提供であると同時に、人間自身の自己理解の深化でもある。
Vault は単なるデータストアではない。人間とエージェントが互いに文脈を蓄積し合う共生の場である。人間は自分の文脈を Vault に蓄積し、エージェントはそれを参照して判断し、エージェントは判断根拠を Vault の引用として提示し、人間はその引用を確認し、必要なら文脈を補強する。このサイクルが回ることで、両者の判断の質が共進化する。
人格を「分ける」という設計
ここで前回までの議論と接続する。Hermes Agent には Profiles という機能がある。プロファイルごとに、設定、環境変数、SOUL.md、memory、sessions、skills、cron jobs、state database などを分けられる。つまり、同じマシン上で複数のエージェント状態を混ぜずに運用できる。
このとき何が起きているかと言うと、
- 知能、つまり推論モデルは交換可能
- 制約、つまりプロファイルや Vault は固有
- 両者の積として人格的なふるまいが立ち上がる
Hermes は、この構造と相性がよい。推論モデルを変えても、プロファイルに蓄積された制約は別の軸として残るからである。
ただし重要な注意点がある。プロファイル分離は、そのままファイルシステム上の安全境界になるわけではない。プロファイルは状態を分ける仕組みであって、サンドボックスではない。実際のアクセス制御は、作業ディレクトリ、実行環境、MCP サーバー側の設定、OS の権限、コンテナ、ネットワーク設定などで別途設計する必要がある。
Obsidian 側では、次のような分け方が考えられる。
- Vault そのものを分ける
- 同一 Vault 内をフォルダやタグで分ける
- MCP サーバー側の read/write スコープでアクセス範囲を絞る
- プロファイルごとに参照する Vault や作業ディレクトリを変える
これらを組み合わせると、どの人格的なふるまいに、どの制約領域への、どの権限でのアクセスを許すかを設計できる。
重要なのは、何でも知っている万能アシスタントを作るのではなく、役割に応じて制約領域を区切ることだ。これは人間組織で職務分掌を与える発想に近いが、LLM 運用ではまだ十分に語られていない論点だと思う。
「文脈」は資産になる — 知識との決定的な違い
ここでもう一つ重要な観点が開ける。一般知識は共有されやすいが、固有の文脈は資産になりうるという違いだ。
物理法則、歴史的事実、プログラミング言語の文法のような一般知識は、多くの人が参照できる。一方で、過去の判断理由、未公開の検討メモ、権限関係、評価基準、失敗の履歴、暗黙の優先順位は、特定の主体に固有のものだ。
この区別は、運用設計上かなり大きい。
| 一般知識 | 固有の文脈 | |
|---|---|---|
| 独占性 | 低い | 高くなりうる |
| 模倣可能性 | 比較的容易 | 難しい |
| 外部 RAG への投入 | 条件次第 | 要審査 |
| 経済的価値 | 汎用的 | 資産性が高い |
| 流出時の影響 | 限定的な場合が多い | 判断能力・競争優位に影響しうる |
ここでいう文脈資産は、単なる秘密情報ではない。判断の癖、優先順位、失敗から得た制約、関係性の地図、何を重視し何を避けるかの履歴である。これを外部サービスに投入する場合は、利用規約、データ保持、学習利用、アクセス制御、監査ログ、匿名化の可否を確認すべきだ。
だからこそ、ローカル LLM + ローカル Vault という構成に意味が生まれる。これは「ローカル LLM がクラウドより常に性能で勝つ」という話ではない。性能比較ではなく、どこに制約を置くか、誰がアクセスできるか、どの境界の内側で判断させるかという設計の話である。
前節で触れた「ネットワーク資源接続性は文脈の資産性とトレードオフ関係にある」という点は、ここに直結する。外部 AI への接続は便利だが、接続のたびに資産が削れる。意識的な振り分け設計が必要になる所以である。
「人格」という言葉について
ここで一つ、慎重に扱うべき言葉について書いておきたい。
本記事でいう「人格」とは、哲学的・倫理的な意味での主体性や意識を主張するものではない。ある主体が、一貫した制約の総体の中で判断を下し続けるとき、外から観察されるふるまいの一貫性 — それを便宜上「人格」と呼んでいる。
LLM が意識を持つかは問わない。問うているのは、特定の制約と結合した LLM が、外から見て一貫した判断主体のように機能するかである。
本記事では AI 倫理上の主体性議論には踏み込まず、外から観察可能なふるまいの一貫性に絞って議論する。
結局、Obsidian は何なのか
ここまで来て、最初の定式に戻る。
知能 × 文脈 = 人格 — より精密に言えば、知能 × 制約 = 人格。
この関係を支えるために、Obsidian は何を提供しているか。整理するとこうなる。
- 知能と制約を分離して保持する — Vault は LLM とは独立に存在する
- 制約の様態を人間可読な形で蓄積する — Markdown ベースのノートが、明示的・関係的・コミュニティ的・領域的・役割的な制約を担う
- 形式特性の組み合わせで剛・柔の分業を実現する — Markdown が柔らかい制約を、同居する SQLite が剛い制約を、LLM が動的な整合性検証を担う
- 3 種別の接続性をすべて支える — Vault 同期(エージェント間)、プラグインと MCP(ネットワーク資源)、Markdown 編集と引用提示(人間-エージェント間)
- 複数の人格的なふるまいを分けて運用しやすい — Vault、フォルダ、タグ、プロファイル、権限設計の組み合わせ
つまり Obsidian は単なるノートアプリにとどまらず、人格形成のインフラとして機能する。慎重に言葉を選べば、ローカル LLM とエージェントが成熟してきた現在、Obsidian は結果として「人格形成のためのインフラ」に近い役割を果たしはじめている — 設計者がそこまで意図していたかは分からないが、Vault、Markdown、wikilinks、Sync、プラグインエコシステムの組み合わせは、知能 × 制約 = 人格 という関係を実装する基盤として、驚くほど整っている。
そして、責任あるエージェント運用を支える構造的基盤としても機能している。判断の素材と判断の根拠が、同じ Vault の上で人間可読な形で共有される — これが透明性を後付けではなく構造として担保する仕組みである。
この構造を意図的に活用できる時期に、私たちは入りつつある。
連載の終わりに
今回までの三本で、こんな道のりを通ってきた。
| 回 | テーマ | 視点 |
|---|---|---|
| 第 1 回 | OpenAI API と MCP Server の二層構造 | プロトコル |
| 第 2 回 | Obsidian への三つの到達経路 | 実装 |
| 第 3 回(本記事) | 知能 × 制約 = 人格 | 思想 |
技術的な配線図から始めて、実装の選択肢を比較し、最終的に「その配線の上に何が立ち上がるのか」を考えた。書き始めた時点ではここまで来るつもりはなかったが、配線が完成してしまうと、配線図では説明できないものが見えてきた。
ローカル LLM × エージェント × Obsidian という構成は、技術スタックとしては既に成立している。残された問いは、この上に何を立ち上げ、どう運用するかだ。それは技術の問題というより、自分や組織の制約をどう設計するかという、もっと根本的な問いになる。
そしてその問いは、エージェントの側だけでなく、人間の側にも返ってくる。Vault を育てるという行為は、自分の暗黙の判断基準を言語化することでもあるからだ。エージェント設計の予期せぬ副産物として、人間の側も自分の判断を客観視できるようになる。
次回以降は、この基盤の上で検証している構成を、より具体的な実装記事として書いていく予定である。
関連記事