Vault・Bot・Memory は gateway 単位で束ねる
ObsidianとHermes Agentで AI エージェントを安全に運用するための前提整理
TL;DR
- AIエージェントに Obsidian を読ませるなら、Obsidian内の分類だけで統制しようとしない
- 読める Vault、使う Bot、保持する Memory を gateway 単位で束ねる
- kanban は用途に応じて、gateway ごとに分離するか、共有kanban に gateway 名前空間を切る(章4)
- gateway をまたぐ橋渡しは 人間が行う。AIには越境させない
- さらに、マシン分離・小さな素材での検証・フィルタ非依存・別モデル検証・Bot名の視覚的区別で 多重防御する
- これらは「プロンプト上の約束」ではなく、実装上の制約として組む
はじめに
ObsidianとHermes AgentのChainでは、kanban(Hermes Agent由来のSQLiteデータストア) と 看板CLI(データストア入出力ツール)、そして Vault が知識保管のコアになる。
Hermes Agent とは、AIエージェントに状態と記憶を持たせて自律的に動かすための実行基盤で、SQLiteベースの kanban(タスクと状態の保持)と、その入出力を担う 看板CLI を備える。これを Obsidian の Vault(Markdownベースの知識保管庫)と組み合わせることで、知識・状態・実行が一つのワークフローとして連動する構成になる。本記事はこの構成を前提に書いている。
そのうえで、運用を始める前に採用しておくべきスタンスがひとつある。
Obsidianに一度流し込んだら統制は難しい、と考えた方が良い。
これは技術的な不可能性を主張しているのではなく、運用上の前提として置く話だ。
技術的には工夫の余地はある。frontmatterで分類する、フォルダで分ける、暗号化プラグインを入れる、Vaultそのものを分ける——どれも「やればできる」。
しかし運用してみると、
- 「あとで分類しよう」のメモが必ず溜まる
- 忙しいときの雑な貼り付けが混ざる
- 人間側の規律だけで分類を維持するのは長期的にしんどい
- AIから見れば frontmatter もただのテキストで、
scope: privateは紳士協定にすぎない - OSのファイルアクセス権限をファイル単位で細かく切ること自体はできるが、ObsidianのVault運用の中でそれを長期的に維持し続けるのは現実的でない
つまり「やればできる」かもしれないが「やり続けるのは難しい」。
やり続けるのは難しい、という前提で設計しないと、運用は容易に破綻する。
だから「Obsidianでの統制は難しいもの」と扱い、統制は Obsidianの外側 に置く。
その外側の単位が gateway であり、gatewayは単独では機能しない。
gateway は (Vault, Bot, Memory) の三点セットを束ねる単位である。
複数のロールを設計するというのは、複数の gateway を設計し、それぞれにどの Vault・Bot・Memory を見せるかを指定することである。
読込先を gateway 単位で分ける、というのは、Vault・Bot・Memory を gateway 単位でセットで分ける、ということだ。
なお、kanban もこの三点と並ぶ重要な構成要素だが、kanban の物理構成は「gateway ごとに分離」と「共有 + 名前空間」の二択がある(章4で詳述)。三点セットとは独立した、状態基盤としての設計対象として扱う。
そしてさらに、AIエージェントは新しい技術であり、gateway という論理境界も完全に守られる保証はまだない、という前提も置く。だから gateway だけに頼らず、二重・三重の対策 を重ねる。
この記事はその構造を整理する。
1. なぜ「ひとつだけ分ける」では効かないのか
Vault・Bot・Memory のどれか一つだけ分けても、残り二つが共有されていれば分離は崩れる。
1.1 Vault だけ分けて、Bot と Memory を共有すると
- 個人Vaultと組織Vaultを別フォルダにしても、同じBotが両方読めれば混ざる
- そのBotのMemoryに個人Vaultで得た文脈が残ったまま、組織Vaultを解釈する
- 「個人で聞いた話」が「組織として答えるとき」の暗黙の前提になる
Vault分離は、ファイル管理上の整理にはなるが、運用上の境界としては弱い。
1.2 Bot だけ分けて、Vault と Memory を共有すると
- 個人Botと組織Botを別名で立てても、同じVaultが読めるなら名前だけの分離
- 共有Memoryに「あなたは経営として答えてください」と書いてあれば、個人Botの出力もそちらに引っ張られる
- Bot名と実態の権限がずれた状態は、運用者を一番混乱させる
1.3 Memory だけ分けて、Vault と Bot を共有すると
- Memoryが別でも、同じVaultを毎回読むなら実質同じ情報を毎回再注入している
- Memoryは「思い出すかどうか」の差で、「読めるかどうか」の差ではない
- Bot人格が同じなら、出力スタイルも判断軸もほぼ同じになる
つまり、三つのうちどれか一つでも共有していると、残り二つの分離は実効性を失いやすい。
三つを束ねて分けて、初めて運用上の境界になる。
その単位が gateway である。
2. gateway = (Vault, Bot, Memory) を束ねる単位
gateway は単なる「読込口」ではない。
gateway は、その境界の中で動く ランタイム環境 そのものだ。
以下は、kanban も gateway ごとに分離する場合の例である(kanban を共有 + 名前空間で分ける構成もある。章4を参照)。
gateway: personal
vault: personal-vault/ # 読み書きできるVaultはここだけ
bot: personal-bot # この環境で動くBot
memory: personal-memory.db # personal-bot だけが触る記憶
kanban: personal.db # 看板CLI --gateway personal
gateway: organization
vault: organization-vault/ # 承認済みファイルのみ
bot: organization-bot # 別人格・別履歴
memory: organization-memory.db
kanban: organization.db # 看板CLI --gateway organization
gateway: publication
vault: public-output-vault/ # 公開用素材のみ
bot: article-bot
memory: publication-memory.db
kanban: publication.db # 看板CLI --gateway publication
gateway: project-xxx
vault: project-xxx-vault/
bot: project-xxx-bot
memory: project-xxx-memory.db
kanban: project-xxx.db
図解:gateway の内部構造と人間の位置
ひとつの gateway の中で、Bot・Vault・Memory・kanban がどう繋がり、その外側に人間がどう関わるかを図示する。
この図には複数の設計原則が一枚で現れている。
- Bot は gateway の中に閉じ込められている:Botから外側への矢印はすべて vault-gateway か 看板CLI を経由する。Vaultやkanbanへの直結はない
-
統制は Obsidian の外側にある:Bot→Vaultが必ず vault-gateway 経由でフィルタされ、
scope未設定のファイルは返らない -
承認は AI に任せない:H→CLI の点線経路は人間専用(
actor:human必須)で、Botからは叩けない - Botにできる操作は capability として宣言:B→CLI は「限定コマンド」のみ
- Obsidian側は雑に使ってよい:H→Vault は直接書ける。Obsidianに統制を期待しないかわりに、雑な使い方を許容する
そして、Human だけが gateway の境界線をまたいで立っていることに注目してほしい。
これは後の章10で重要な意味を持つ。
運用ルール
- Bot は一つの gateway に属する。複数 gateway をまたがない
- Bot は自分の gateway の Vault しか読まない
- Bot は自分の gateway の Memory しか持たない
- gateway 間の橋渡しは、原則として人間がやる
この縛りがあって初めて、「Vaultに変なものが流れ込んだ」事故が他の gateway に伝播しにくくなる。
逆に言えば、「便利だから個人Botに組織Vaultも読ませよう」とした瞬間に、この三点セットは崩れる。崩れた瞬間に統制が大きく弱まる。
gateway は「プロンプト上の約束」ではなく「実装上の制約」
ここで強調しておきたい点がひとつある。
gateway は、プロンプトで指示するのではなく、実装側で強制する。
- 「あなたは personal-bot です。personal-vault しか読まないでください」とプロンプトでお願いしても、それは紳士協定にすぎない
- Bot に生のファイルパスや、広いスコープのMCP権限を渡した瞬間に、gateway は無力化される
- Bot から Vault へのアクセスは必ず vault-gateway を通す。生の
globやfs.readを許さない - 看板CLI 以外の経路で kanban に書き込めるなら、それは gateway ではない
- 可能なら、OSユーザー、ディレクトリ権限、コンテナ、別マシンなど、物理・実装境界でも補強する
つまり、gateway は「思想」ではなく「実装制約」として組み立てる。
ここを緩めると、後の章で書く多重防御の話がすべて意味を失う。
プロンプト上の約束は、モデルの気分や入力の微妙なニュアンスで崩れる。
実装上の制約は、モデルの気分とは無関係に崩れない。
統制は後者の側にしか存在しえない。
3. Memory を束ねることの重要性
Vault と Bot は分けても、Memoryは「便利だから」と共有されがちだ。これが一番危ない。
Memory はAIが 暗黙に持っている前提 だ。Vaultやプロンプトのように毎回明示するものではなく、いつのまにか積み重なる。
共有Memoryで起きる事故:
- 個人で雑談したときの仮説が、組織として回答するときに引きずられる
- 過去に見た顧客名・金額・案件状況が、関係ない文脈の出力に混ざる
- 「あなたの好きな文体」が、組織の公式文書にも適用される
- プロジェクトAの技術選定が、プロジェクトBの提案に流れる
これらは「Vault分離した」「Bot分離した」運用でも、Memoryさえ共有していれば普通に起きる。しかも、Memoryからの染み出しは ログだけでは検知しづらい。
だからMemoryも gateway に束ねる。
- personal-bot は personal-memory しか持てない
- organization-bot は organization-memory しか持てない
- 同じBotが gateway をまたいで動けないので、Memory が物理的に混ざりにくい
ここまでやって、初めて「染み出し」が技術的にも起きにくくなる。
補足:外部Memoryプロバイダを使う場合
ここで言うMemory分離は Hermes built-in の profile別Memory の話である。mem0 / honcho などの外部Memoryプロバイダ を使う場合、それ自体が gateway をまたぎうる独立した経路になるため、外部Memoryプロバイダの権限設計を別途 gateway に組み込む必要がある。
具体的には、外部Memoryプロバイダを使う場合、
- provider(どのサービスか)
- namespace(どの空間に書くか)
- API key / credential
- 保存先アカウント
これらすべてを gateway 単位で確認する。
同じ provider / 同じ namespace / 同じ credential を複数 gateway で共有してしまうと、VaultやBotを分けていてもMemory経由で文脈が混ざる。
これは「Memory を分けたつもり」になっていて一番危ない種類の事故だ。外部Memoryを使うなら、上記4つすべてが gateway ごとに独立しているかをチェックする。
4. 看板CLI:kanban への唯一の入口
ここまで来ると、Hermes Agent における看板CLIの位置づけがはっきりする。
看板CLIは、kanban(SQLite)という状態データソースに対する 唯一の入口 である。
そのうえで、kanban の物理構成は用途に応じて二択になる。
構成A:gateway ごとに kanban DB を分ける
看板CLI --gateway personal # personal.db のみ操作可能
看板CLI --gateway organization # organization.db のみ
看板CLI --gateway publication # publication.db のみ
看板CLI --gateway project-xxx # project-xxx.db のみ
厳密な分離を求める場合の構成。ファイルとして物理的に分かれているので、誤って別 gateway の状態に触れる経路がない。
構成B:共有kanban に gateway 名前空間を切る
kanban:
db: ~/.hermes/kanban.db
namespace_key: gateway
gateway: personal
kanban_namespace: personal
gateway: organization
kanban_namespace: organization
Bot 間のタスク受け渡しや、横断的な状態管理を重視する場合の構成。物理的には一つのDBだが、看板CLI が gateway を見て、読めるタスク・書けるタスク・実行できる操作を制限する。
看板CLI に共通の責任
どちらの構成を選んでも、看板CLI には共通の責任がある。
看板CLIは、gateway / owner / visibility / allowed_actor / allowed_gateway といったフィールドを見て、
- 触れるテーブル(または行)
- 実行できるサブコマンド
- 監査ログの送り先
- 承認系コマンドが有効か無効か
をすべて gateway ごとに切り替える。
承認系(approve、publish、send など)は gateway 設定で actor: human を必須にする。AIエージェントが叩こうとしても、CLIの段階で弾く。
「AIにできる操作の集合」は、gateway 定義の中で宣言的に書く。
プロンプトでお願いするのではなく、capability として明示する。
構成B を選ぶ場合の注意
構成B(共有kanban + namespace)を選ぶ場合、gateway 間の分離は看板CLI のフィルタに依存することになる。
したがって、後の章7で書くレイヤー4(フィルタ依存の排除)の原則がそのまま適用される——他 gateway に見せたくない本当の秘密は、共有kanbanに書かない。共有kanbanはあくまで「横断してよいタスク状態」のための場所、と割り切る。
機密性の高いタスクを抱える gateway は、共有kanbanに参加させず、構成Aで独立した kanban DB を持つ、という混在もありうる。
5. vault-gateway:Obsidianの「外側」に統制を置く
Obsidian自体での統制は難しい——というより、頼らないものとして扱う。
そのうえで Vault を直接 glob させず、vault-gateway を間に挟む。
vault-gateway がやること:
- frontmatter の
scope,status,ownerでフィルタ - パスベースのスコープ制限
scope未設定のファイルはデフォルトで返さない- 検索クエリと結果の監査ログ
- 書き込みは別 gateway(vault-write-gateway)として分離
ここでも、vault-gateway は単独で存在しない。
vault-gateway --gateway personal は personal-bot と personal-memory のセットでしか呼ばれない。
「組織Botから個人Vaultを覗く」は、技術的にできない構成にする。
そして特に重要なのが、「分類されていないファイル」をデフォルトで存在しない扱いにする ことだ。
これがないと、「あとで分類しよう」のメモが gateway 越しでも漏れる経路を作る。
逆にこれを徹底すると、人間側に「分類しないとAIに食わせられない」という制約が生まれる。
繰り返しになるが、Obsidian側で頑張って統制しようとしない。
Obsidianは雑に使ってよい。雑に使われても困らない構造を、外側に作る。
6. gateway をまたぐときは人間が橋渡しする
複数 gateway にまたがる作業は、必ず人間を経由させる。
例: 個人で書いたアイデアメモから Qiita 記事を作る場合
[gateway: personal]
personal-bot が personal-vault からアイデアを抽出
→ 候補リストを出力
↓ ここを人間が判断する
↓ 「これは公開してよい」を選別
↓ public-output-vault/ に下書きを置く
[gateway: publication]
article-bot が public-output-vault だけを読んで整形
→ publication kanban のステータスを更新
→ 人間が最終レビュー → 公開
この 人間を境界にする 一手間が、最も簡素で最も確実な漏洩防止策になる。
AIに gateway 越境を許す瞬間に、Vault・Bot・Memory の三点セットが崩れる。
だから越境は AI ではなく人間がやる。
これは不便ではなく、運用が壊れないための最低限のコスト である。
7. エージェントは新しい技術:多重防御の姿勢で臨む
ここまでに書いた gateway 設計は強力だが、それだけで安全だと思ってはいけない。
AIエージェントは構成として新しい。gateway が期待どおり動く保証は、今のところ十分ではない。
- プロンプトインジェクションで gateway の制約を回避するよう仕向けられるかもしれない
- フィルタの実装漏れで、見せないはずのファイルが返ってしまうかもしれない
- モデルが「親切心」で gateway が返さなかった情報を補完してしまうかもしれない
- バージョンアップで挙動が変わるかもしれない
- そもそもMCPやプラグインの隙間から、設計を素通りされるかもしれない
つまり、gateway は境界として機能する「はず」だが、境界が常に守られる保証はまだ十分にはない。
だから、gateway だけに頼らない。二重・三重の対策 を重ねる姿勢で臨む。
これは新奇な発想ではなく、人間の組織における情報管理がずっとやってきたことそのものだ。
- 情報管理の段階(機密区分:極秘/秘/社外秘/公開)
- 秘密保持契約書の締結と規定
- そもそもの保存領域の分離(物理的なファイルサーバ、共有範囲)
機密区分があるからNDAが要らない、ということにはならない。NDAがあるから保存領域を一緒にしてよい、ということにもならない。それぞれが独立した防御層として、重ねて初めて意味がある。
筆者自身、組織で情報を扱ってきたとき、これらの層は「念のため」ではなく「どれか一つが破れても他が残る」ための設計として並んでいた。AIエージェントの運用も、まったく同じ発想で組むのが妥当だと考える。
具体的には、最低でも次の5つのレイヤーを意識する。
レイヤー1: マシンを分ける
Hermes Agent / Obsidian を走らせるマシンは、通常業務のPCとは分ける。
通常業務のPCには、メール、顧客資料、社内システムへのアクセス、ブラウザのCookie、SSO セッション、SSH 鍵、認証済みクラウドストレージなど、無数の機密情報がある。AIエージェントが走るマシンとそれが同一だと、エージェント側に「うっかり」流れ込む経路を全部見落とすことになる。
そして、情報をエージェント側に流すときは「流通影響」を事前に検討する。
- 何を渡すのか
- それが漏れたら何が起きるのか
- その情報がエージェントの記憶やVaultに残ることをどう許容するのか
- エージェント側マシンが侵害されたとき、何が漏れるのか
これは、社外秘の書類を持ち出すときに「持ち出してよいか」を判断するのと同じ作業だ。
持ち出していいかわからないなら、持ち出さない。
補足:認証経路は「実際に探索される場所」まで潰す
実際に運用しはじめて気づくのが、設定上は使わせていないつもりの認証経路が、暗黙に有効になっていることがある、という現象だ。
たとえば、設定上はAPIキー経由を使わせるつもりでも、Keychain や既存の credential file に残っていた認証情報が優先され、意図した経路に切り替わらない、ということが起きる。Keychain entry を削除して初めて、想定した経路に切り替わった、という事例もあった。
これは「使わないでください」とプロンプトに書いても解決しない。
credential store、Keychain、環境変数、設定ファイル、既存セッション——実際に探索される認証経路を確認し、不要なものは物理的に消す必要がある。
ここでも原則は同じだ。プロンプト上の約束ではなく、実装上の制約として強制する。
そして、こうした「予期しない credential discovery」は、エージェント運用マシンと通常業務マシンが同一だと、追跡も封じ込めも一気に難しくなる。マシン分離は、こうした見えにくい経路を最初から物理的に絶つための一手でもある。
レイヤー2: 影響の小さい情報から試す
gateway 設計が正しく機能していることは、最初は影響の小さい情報で検証する。
- 漏れても問題ない素材
- すでに公開済みの情報
- ダミーデータ
- 自分自身の情報のうち、外に出ても被害が限定的なもの
これらで gateway の挙動を確かめる。
- 想定どおりのファイルだけが返るか
- 別 gateway から覗けないか
- Memoryに残るべきでないものが残っていないか
- 承認系コマンドがCLIで弾かれるか
- frontmatter 未設定のファイルが除外されているか
これを確認してから、機密性のある情報を順次入れていく。
「いきなり本番データを流す」は、gateway 設計の有無に関わらず事故の元になる。
設計に自信があるときほど、最初は影響の小さいデータで殴って確かめる。
レイヤー3: gateway を複数設計する
ここまでに書いてきた本題。
gateway を複数設計し、Vault・kanban・Bot・Memory のそれぞれについて何を見せるかを決める。
gateway は一つでは意味がない。複数あって、それぞれの境界が立ってはじめて、運用上の分離になる。
「複数のロールが必要」と感じたら、それは「複数の gateway が必要」ということだ。
ひとつの gateway の中でロールを切り替える、という発想は持たない。
ロールが変わる = 別の gateway = 別の Vault/Bot/Memory の組、と考える。
レイヤー4: 「共有Vaultの片側にしか見えない秘密」を置かない
ふたつの gateway が同じVaultの一部を共有している場合がある(たとえば共通の知識ベースを両方に見せる、など)。このときに気をつけるべきは、フィルタによる隠蔽を「秘密の保管」に使わない ことだ。
つまり、gateway A からは見えて gateway B からは見えない、というフィルタ設定をしたうえで、その「Aだけに見える」領域に 本当の秘密 を置かない。
理由は単純で、フィルタは実装次第で漏れるからだ。
- 検索のクエリ次第で意図せず引っかかる
- frontmatter の書き漏れで scope なし扱いになる
- パス指定の typo で別 gateway から見える
- バージョンアップで挙動が変わる
- そもそもファイルシステム上は同居しているので、誰かの誤操作で別Vaultに移る
- プロンプトインジェクションでフィルタを迂回されうる
つまり、「Aだけに見える」を担保している手段がフィルタしかない場所には、漏れたら困る情報を置かない。
漏れたら困る情報は、Vault そのものを物理的に分ける。gateway 間で共有しないVaultに置く。
共有Vaultはあくまで「両方が見てよい情報」のための場所、と割り切る。
これが「保存領域を分ける」の現代版だ。
なお、この原則は kanban を共有構成(章4の構成B)で運用する場合にも同様に適用される。共有kanbanは便利だが、片側のgatewayにしか見せたくない情報は、共有kanbanには書かない。
レイヤー5: 別のフロンティアモデルで検証する
最後に、最も見落とされやすい層。
Hermes Agent / Obsidian の設定や挙動を、推論エンジンに設定したエージェントとは別軸の、別系統のモデルで検証する。
たとえば、
- メインの運用がClaude系なら、設定レビューやログ監査は GPT 系で行う
- 逆に GPT 系で運用しているなら、Claude 系で検証する
- frontmatter 監査や分類抜けの検出には、運用とは別系統のモデルを使う
- 承認操作の誤発火を別モデルで二重チェックする
同じモデルファミリーで運用も検証もやると、同じ思い込みで同じバイパスを許す 可能性がある。
モデルには癖がある。指示の解釈のしかた、注意の向け方、サボりやすい場所、いずれも傾向がある。
運用と検証を同じファミリーで揃えると、その癖が両方で同じように出る。
これは人間組織における内部監査 vs 外部監査の関係に近い。
内部だけで完結させると、内部の前提が共有されるぶん盲点が共有される。
別系統のモデルを噛ませることで、
- 設定の矛盾を指摘させる
- ログから不審な挙動を抽出させる
- frontmatter スキャンで分類抜けを検出させる
- 承認系コマンドの誤発火を別系統で再判定させる
といった検証ができる。完璧ではないが、層としては明確に価値がある。
8. 最小構成
最初から全部の gateway を揃える必要はない。最小は二つ。
gateway: personal
vault: personal-vault/
bot: personal-bot
memory: personal-memory.db
kanban: personal.db
gateway: publication
vault: public-output-vault/
bot: article-bot
memory: publication-memory.db
kanban: publication.db
そして人間が橋渡しする。
それに加えて、最低限の多重防御として、
- マシンを通常業務PCから分ける(レイヤー1)
- 最初は影響の小さい素材で gateway の挙動を確認する(レイヤー2)
- 別系統のモデルで設定を一度レビューする(レイヤー5)
をやっておく。
なお、レイヤー3(gateway を複数設計する) は最小構成そのものが personal と publication の2つの gateway を持つため、定義上すでに満たされている。
レイヤー4(共有Vaultの片側秘密禁止) は、最小構成では personal-vault と public-output-vault が完全に分離していて共有Vaultが存在しないため、原理上自動的に満たされる。組織や複数プロジェクトを足してVaultの一部を共有し始めた段階で、レイヤー4の判断が初めて意味を持つようになる。
組織のドキュメントを扱い始めたら gateway: organization を足す。
プロジェクトが始まったら gateway: project-xxx を足す。
そのたびに、Vault・Bot・Memory を3つセットで増やす。
「Vaultだけ足して既存Botに読ませる」は禁じ手。
新しいスコープが必要になった = 新しい gateway が必要、と考える。
9. 失敗パターン
「Obsidian側で統制すれば守れる」と思う
frontmatterもフォルダ分けも、運用を続けるうちに必ず緩む。Obsidianは雑に使えるからこそ便利で、雑に使ってよい設計にすべき。統制はObsidianの外に置く。
「Vaultだけ分ければ守れる」と思う
Vaultを分けてもBotとMemoryが共有なら、AIは結局両方を踏まえて動く。検知も難しい。
「Botは別名にしたから安心」と思う
名前だけ分けてMemoryやVaultを共有していると、Bot名と実態の権限がずれて運用者が混乱する。
「Memoryは便利だから一個で運用したい」と思う
最も検知しにくい染み出しが起きる。個人の仮説や顧客名が、別の場面の出力に混じる。
外部Memoryプロバイダの provider / namespace / credential を gateway 間で共有する
VaultとBotを分けていてもMemory経由で文脈が混ざる。「Memoryを分けたつもり」が一番危ない。
一つのBotに複数の gateway をまたがせる
便利さの誘惑だが、その瞬間に統制の単位が崩れる。横断が必要なら必ず人間を間に挟む。
gateway をプロンプトの約束として扱う
「○○Vaultしか読まないでください」とプロンプトに書いても、それは紳士協定にすぎない。実装上の制約として強制しないと、状況次第で簡単に崩れる。
通常業務PCとエージェント運用マシンを同一にする
うっかり経由でいくらでも情報が流れる。Keychainや既存credentialの暗黙の優先順位が事故を起こす。物理を分けないと、論理境界の議論は半分意味を失う。
いきなり本番データで動かし始める
設計の自信は、実機で挙動を確認するまではただの推測。最初は捨ててよいデータで殴って確かめる。
フィルタで隠せば秘密は守れると思う
フィルタは実装次第で漏れる。本当の秘密はVaultそのものを分ける。共有kanbanを使うときも同じ。
運用と検証を同じモデルファミリーで完結させる
同じ癖で同じ盲点を作る。別系統のモデルで一度通すだけでも、見落としは確実に減る。
Vault に scope 未設定のメモを置いたまま放置する
vault-gateway がデフォルトで除外する設計にしていないと、未分類のメモが全 gateway に漏れる経路になる。
承認系コマンドをAIから叩けるCLIに載せる
gateway 設定で actor: human を必須にする。「あとで戻せばいい」では戻せない事故が起きる領域。
MCPサーバを直接Botに渡してしまう
MCPの能力がそのままBotに流れるので、フィルタ・スコープ・監査が抜ける。MCPの上にも gateway を被せる。
10. もっとも注意したいのは:Bot誤爆(ごばく)
ここまで gateway と多重防御を律儀に組んでも、なお一番起きやすい事故が残る。
Bot誤爆 である。
Botは gateway を取り違えない。取り違えるのは人間
章2の図をもう一度思い出してほしい。
あの図では、Bot は gateway の中に閉じ込められていた。Botから外への矢印は vault-gateway や 看板CLI を経由するものしかなく、別 gateway へ直接繋がる経路は存在しない。
一方、Human だけが gateway の境界線をまたいで立っていた。
個人 gateway の Bot とも、組織 gateway の Bot とも、公開 gateway の Bot とも、人間は同じように対話できる。
つまり、
- Botは自分の所属 gateway の外には原則出られない → 「別 gateway に送る」種類の誤爆はしにくい
- Humanは複数 gateway を行き来できる → gateway を取り違える事故は人間側で起きる
これが「Bot誤爆」=入力先取り違えの構造的な根拠だ。
取り違えは技術的境界の内側で起きるのではなく、境界の上流に立つHumanの側で起きる。
ここで誤解しないでほしい補足を一つ。
これは「gateway の取り違え」に限った話だ。
Bot自身が gateway の中で 誤った要約・誤った判断・誤った操作 をする可能性は、依然として残る。章7のレイヤー5「別モデルでの検証」が必要なのは、まさにそのためだ。
ここで言っているのは「情報が正しい場所に届くか」の話であって、「届いた内容が正しいか」の話ではない。
両者は別の問題で、別の対策が要る。
LINE誤爆との対比
LINE で送り先を間違えた経験は誰しもあるはずだ。
- 個人の愚痴を仕事のグループに流してしまった
- 家族へのメッセージを部活LINEに送ってしまった
- 取引先Aへの連絡を取引先Bに送ってしまった
人間相手の誤爆は、相手が困惑したり信頼を失ったりはするが、相手の頭の中から「無かったこと」にしてもらえる可能性は残る。
しかし、AIエージェント相手の誤爆は質が違う。
- 個人Botに話すつもりで、組織Botのウィンドウに機密の悩みを書き込んでしまう
- 公開記事Botに「◯◯案件のことなんだけど」と内部情報を渡してしまう
- プロジェクトAのBotに、プロジェクトBの会議内容をうっかり相談してしまう
このとき、その情報は
- その gateway のVaultに書き込まれるかもしれない
- その gateway のMemoryに「ユーザの関心」として残る
- ログに残り、後から検索される
- 別のセッションで「以前話していたXX案件は…」と参照される
つまり、入力した瞬間に gateway の中に染み込み、後戻りができない。
gateway 設計は「Botが触れる範囲」を物理的に絞るための仕掛けだが、誤爆は 境界の上流 で起きる。「正しい gateway の中で、間違った情報が入る」。技術的な境界では止められない。
Bot名と表示で視覚的に殴る
これに対して、地味だが効く対策がある。
Bot名と表示でユーザの目を殴る ことだ。
-
personal-botではなく[個人]yoshi-personal -
organization-botではなく[ORG]corp-secretary -
secret-project-botではなく[!SECRET!]project-x-bot -
article-botではなく[PUBLIC]article-writer
[!SECRET!] のように記号付き・大文字で目立たせるのは、安全より目立たせを優先する からだ。
ユーザが入力欄に何かを書こうとした瞬間、視野の隅に [!SECRET!] があれば、「あ、いまここに書いていいやつだっけ?」と一瞬手が止まる。
その一瞬が、誤爆を一回減らす。
可能なら、
- UIの背景色を gateway ごとに変える(個人=白、組織=青、機密=赤、など)
- ウィンドウタイトルに gateway 名を入れる
- ターミナル運用なら PS1 や bashプロンプトに gateway 名を入れる
- Bot名は機械生成の似た名前にせず、意図的に違うキャラクター性のある名前にする
「いま自分はどこに話しているか」を、目で見て一瞬で分かるようにする。
これはUIの問題であり、運用ルールでは補えない。
誤爆は技術ではなく癖で防ぐ
gateway が論理境界、物理マシン分離が物理境界、フィルタ非依存とモデル別検証が運用境界だとしたら、誤爆対策は 「人間の癖」境界 だ。
癖は意識では作れない。表示と名前で、半ば強制的に作る。
そして、これだけは強調しておきたい。
多重防御を組んでもなお、最後に残る穴は人間側の操作ミスだ。
だからこそ、ここに最も注意を払ってほしい。
まとめ
ObsidianとHermes AgentのChainでは、kanban・看板CLI・Vault が知識保管のコアになる。
そのうえで、運用の前提としてこう考える。
Obsidianに一度流し込んだら統制は難しい、と考えた方が良い。
技術的に守れるかどうかではなく、運用上は守り切るのが難しい、と置く。
そう置けば、設計は自然に 安全側 に倒れる。
統制はObsidianの外側、すなわち gateway に置く。
gateway は単独では機能しない。
gateway = (Vault, Bot, Memory) の三点セットを束ねる単位
であり、
複数のロールを設計するとは、複数の gateway を設計し、それぞれにどの Vault・Bot・Memory を見せるかを指定すること
である。kanban は、gateway が操作する状態基盤として、分離 or 共有 + namespace の構成を選ぶ。どちらを選んでも、看板CLI を唯一の入口にし、capability・actor・監査ログで制御する。
そしてこの gateway は プロンプト上の約束ではなく、実装上の制約 として組む。プロンプトは紳士協定、実装は強制力——統制は強制力の側にしか宿らない。
さらに、AIエージェントは新しい技術であり、gateway という論理境界も常に守られる保証はまだない。だから gateway だけに頼らず、二重・三重の対策 を重ねる。
これは伝統的な情報管理(機密区分・NDA・保存領域の分離)と発想が共通している。それぞれが独立した防御層として重ねて初めて意味がある、というのは、AI以前から変わらない。
最低限、次の5層を意識する。
- マシンを分ける(物理境界)
- 影響の小さい情報から試す(運用前検証)
- gateway を複数設計する(論理境界)
- 共有Vault・共有kanbanの「片側にしか見えない秘密」を置かない(フィルタ依存の排除)
- 別系統のモデルで検証する(独立検証)
そして gateway をまたぐ橋渡しは、原則として人間がやる。
最後に、これらすべてを整えてもなお最後に残る穴が、人間側のBot誤爆 である。
Bot名に視覚的マーカーを付け、入力先を見間違えにくくする。
技術ではなく癖で守る、最後の層を忘れない。
おわりに:後戻りできない感覚
筆者は Agent + Obsidian × LLM の運用を始めて、ある感覚を得た。
もう、これなしの仕事には戻れない。
過去のメモが瞬時に引き出される。書きかけのアイデアが対話で形になる。定型作業が背景で進む。
一度この体験を経ると、「自分の頭だけで全部やる」モードに戻すのは、もう難しい。
これは個人的な感想だが、おそらく同じ感覚を持つ人はこれから急速に増える。
そして、この感覚が広がった瞬間に、情報管理とエージェントの両立は社会的に喫緊の課題になる。
- 会社で「何をエージェントに渡してよいか」のルールがない
- 個人の機密と業務情報の境界が曖昧
- AIに渡した情報が、次にどこへ行くか追えない
- 誤爆や染み出しが見えないまま蓄積する
- 取引先・顧客・従業員、それぞれの情報が混ざる
すでに「便利だから使ってしまう」が先行している。
組織のルールや法的整理は、ほぼ確実に遅れる。
だからこそ、まだ個人や小さな組織の段階のうちに、
- 統制は難しいと前提する
- gateway を単位に Vault・Bot・Memory を束ねる
- kanban の構成(分離 or 共有 namespace)を意識的に選ぶ
- gateway は実装上の制約として組む
- 多重防御で守る
- 誤爆を表示で防ぐ
という設計を、自分の手元から始めておく 意味がある。
社会のルールが追いつくのを待っていると、追いつく頃には自分の情報はすでにエージェントの記憶のどこかに散らばっている。
後戻りができないことを知ったうえで、入る前に道を作る。
それが、AIエージェント時代の情報管理の、いま個人ができる最も実務的な答えだと考える。
一文でまとめるなら:
Obsidianに流し込んだら統制は難しい、と考えて設計する。読込先を gateway 単位で分け、各 gateway に専用の Vault・Bot・Memory を束ねて持たせる(kanban は分離 or 共有 namespace の構成を意識的に選ぶ)。すべて「プロンプト上の約束」ではなく「実装上の制約」として組む。エージェントは新しい技術であるため、物理境界・段階導入・フィルタ非依存・独立検証で多重に守る。gateway をまたぐ橋渡しは人間がやり、人間側の誤爆はBot名の視覚的マーカーで防ぐ。そして、この感覚が広がる前に、自分の手元から設計を始めておく。