Obsidianは、ノートを保存するだけのメモアプリです。AIエージェントが自力で正本へ辿り着く基盤に変えるには、階層・原本・機密分離という3つの設計判断が別途必要です。本記事は、Obsidian公式仕様とClaude Code公式仕様、統合済みの自社Vaultの実例から、この設計図を1枚にまとめます。
01結論：Obsidianの知識基盤は、階層・原本・機密分離の3点で決まる
階層は、AIが最初にどこを読むかを決めます。原本は、同じ事実を複数箇所に書かせないための1点管理です。機密分離は、書いてよい内容と隠す内容を、フォルダとfrontmatterで機械的に分けます。
3つの設計判断は、順番に決めると手戻りが減ります。
- 階層を先に決める：番号帯ごとに「ここが正本」と言えるフォルダを宣言する
- 原本を1つに絞る：同じ事実を書ける場所を1箇所に制限する
- 機密度で読ませる範囲を分ける：public・internal・restrictedの3層に振り分ける
以下、この3つを実際の階層設計と自社の実測記録に沿って見ていきます。
02AIエージェントに読ませるVaultとは｜ナレッジ基盤に「階層」が要る理由
Obsidian公式ドキュメントは、Vaultをローカルのファイルシステム上にある1つのフォルダと定義しています（出典: Obsidian公式）。ノートはこのフォルダの中に、ただのMarkdownファイルとして保存されます。
公式ドキュメントには、フォルダ構成を特定の形に強制する記述がありません。どんなツリー構造にするかは、使う人が決める設計問題として残されています。
人間はこの自由度を、検索とグラフビューで埋めます。目的のノートが見つからなくても、キーワード検索やリンクの網でたどり着けるからです。
AIエージェントは検索の代わりに、決まった手順でファイルを読みます。目的のフォルダが分からないと、無関係なファイルを大量に読み込んでから判断するか、古い情報を正本と誤認するかのどちらかが起きます。
だからこそ、AIに読ませるナレッジ基盤には、人間向けの検索性とは別に、AI向けの「最初に読む場所」を固定する階層が要ります。
03Vault設計の階層｜AIが遠回りせず正本へ辿り着く番号フォルダの型
階層設計の核心は、フォルダ名の先頭に番号帯を振ることです。番号は読む順序そのものであり、AIにも人にも同じ順で伝わります。
Claude Code公式ドキュメントは、作業ディレクトリから上の階層へCLAUDE.mdをたどると説明しています。見つけたファイルは、起動時にまとめて読み込まれます（出典: Claude Code公式）。番号帯を先頭に置くと、この読み込み順とフォルダの意味順を一致させられます。
| 番号帯（例） | 役割 | 何を置くか | 誰が更新するか |
|---|---|---|---|
| 00番台 | 横断ルール | 命名規則・秘匿区分・運用ループの定義 | 人がレビューしてから更新 |
| 01〜02番台 | 個人設定・会社の事実 | 口調ガイド・公式プロフィール・数字の正本 | 人が確定した内容のみ |
| 03番台 | 実行部隊のナレッジ | 役割ごとの手順書・素材ライブラリ | 各担当が追記 |
| 04〜06番台 | 成果物・タスク管理 | 案件ごとの作業領域・進行台帳 | AIが作業中に更新 |
| 90・99番台 | 稼働インフラ・機密 | 常駐ジョブの定義・restricted領域 | 人の承認が要る領域 |
番号帯は、一度割り当てたら意味を変えないことが条件です。番号の意味が入れ替わると、AIは古い記事や設計書を新しい正本と取り違えます。
階層だけでは、設計はまだ終わりません。同じ事実がどの番号帯にも書けてしまうと、階層を作った意味が薄れます。次に、事実そのものの置き場所を1つに絞る方法を見ます。
04原本（単一情報源）とルール置き場の決め方｜同じ事実をナレッジ基盤の中で二重管理させない
原本とは、ある事実について「ここを読めば正しい」と言い切れる、唯一の置き場所です。原本が複数あると、AIはどちらを信じるかを毎回判断することになります。
判定の軸は2つです。1つ目は事実の種類（横断ルールか、会社の事実か、担当ごとの実行知識か）。2つ目は、その事実を混ぜてはいけない相手です。
| 事実の種類 | 原本の置き場所（例） | 混ぜてはいけないもの |
|---|---|---|
| 横断ルール（全体で共通） | ルール専用フォルダ | 個別担当のノウハウ |
| 会社の事実（数字・沿革・人物） | 会社ナレッジ専用フォルダ | 案件ごとの下書き・推測 |
| 担当別の実行知識（手順・素材） | 各担当のナレッジ配下 | 会社全体の横断ルール |
| 一度きりの作業記録 | 完了記録・案件フォルダ | 恒久ルールとしての参照 |
原本を決めても、書いた本人以外がその存在を知らなければ意味がありません。Claude Code公式仕様でも、指示ファイルの内容は文脈として渡されるだけだと説明されています。従うかどうかの判断はClaude側に委ねられます（出典: Claude Code公式）。原本の場所を書いた文書自体にも、強制力はありません。
原本は、要約や伝聞ではなく一次情報に当たって初めて機能します。姉妹メディアの公開本数は、検索結果の要約ではなくsitemap.xmlを直接数えた値を正本にしています（2026-07-28実測・251本）。
ルール置き場も同じ発想です。横断ルールと、個別の担当が使う実行ナレッジを同じフォルダに混ぜると、担当を変えるたびに横断ルールまで一緒に書き換わるリスクが生まれます。
05機密分離の設計｜知識基盤を公開・社内・制限の3層に分ける
機密分離は、階層設計の続きにある判断です。どの番号帯に置くかを決めた後、その中身を公開してよいかを、もう1段細かく分けます。
分ける基準は3段階です。誰にでも見せてよい内容、社内向けだが記録には残す内容、外に出してはいけない内容の3つです。
| レベル | 配置 | Gitでの扱い | AIの出力ルール |
|---|---|---|---|
| public | 会社ナレッジの直下 | 追跡・公開可 | そのまま引用してよい |
| internal | 会社ナレッジ配下＋frontmatterで明示 | 追跡するが社外非公開 | 社内向け出力のみ |
| restricted | 専用フォルダに隔離 | .gitignoreで追跡から除外 | 出力時は個人名・数値をマスキング |
Obsidianのプロパティ機能を使うと、この判定をファイルの先頭にYAML形式で書き込めます。公式ドキュメントは、プロパティがファイル冒頭に---で囲んで保存される仕組みだと説明しています（出典: Obsidian公式）。人間はこの値をフィルタ表示に使い、AIエージェントは同じ値を出力可否の判定に使います。
ただし、frontmatterに値を書くだけでは、機密は守られません。書いた値をAIが本当に守るかどうかは、読んで判断するか、技術的に強制するかで結果が変わります。
判定に迷ったときの逃げ道を先に決めておくことが、機密分離の要です。迷ったら出力を止めて人に確認する、という合流点を1つ用意しておきます。
06自社のナレッジ基盤で実際に何が起きたか｜階層設計と実測の記録
WEBMARKSは2026年6月、外部から受け入れた新しい骨格構造を土台に、既存のナレッジ資産を畳み込みました。番号帯の意味を先に固定し、旧フォルダを新しい番号帯へ移管する形で統合しています。
AI社員体制は、この統合と同じ2026年6月24日に7部署・30体で定義されました。運用が始まったばかりの段階のため、ここでは日数ではなく番号帯の数と担当数という規模で語ります。
設定ファイルを書いた事実と、いま動いている事実は別に数えます。WEBMARKSは常駐ジョブの稼働をlaunchctlで毎回実測しています。8本定義したジョブのうち、2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちだと把握しています。自動再開の仕組みも同じ実測で確認しており、最終実行は2026-07-13で止まっていると記録しています。
つまり、階層と機密区分を正しく設計しても、書いた設定どおりに動いているとは限りません。ナレッジ基盤自体を定期的に実測し直し、動いている数を都度数え直すことが、原本を原本のままに保つ条件です。
07つまずきやすい点｜ナレッジ基盤の階層設計でよくある3つの失敗
階層設計でつまずくパターンは、だいたい3つに集約されます。
| 失敗 | 起きること | 直し方 |
|---|---|---|
| 番号帯を使い回す | AIが古いフォルダと新しいフォルダを両方正本と誤認する | 番号帯は固定し、統合時は移管先を1行で案内する |
| 機密frontmatterを書き忘れる | restricted相当の情報がpublic領域から出力される | 新規作成時のテンプレートに既定値を組み込む |
| 設計書と実態がずれる | 「動いているはず」の仕組みを動いていると誤報告する | 稼働を主張する前に、コマンドで実測してから書く |
3つとも、設計そのものより運用の途中で起きます。最初の設計を疑うより、定期的な実測を仕組みに組み込むほうが効きます。
08チェックリスト
- 番号帯ごとに「ここが正本」と言えるフォルダを1つ決めたか
- 同じ事実を書ける場所を1箇所に制限したか
- 横断ルールと担当別の実行ナレッジを別フォルダに分けたか
- 機密度（公開・社内・制限）をフォルダとfrontmatterの両方で示したか
- restricted相当のフォルダをGitの追跡から外したか
- AIへの出力時、機密度が不明な場合の逃げ道（人に確認する）を決めたか
- 番号帯の意味を、統合や移管のたびに書き換えていないか
- 設計書に書いた稼働状態を、実測で確認したか
09FAQ
Obsidianでなくても同じ設計は作れますか
作れます。本記事の階層・原本・機密分離という3つの判断は、フォルダとMarkdownファイルさえあれば成立する設計です。Obsidianはこの構造を人間が見やすく表示するビューアという位置づけです。
番号帯はどのくらいの粒度で切ればいいですか
10個前後の大分類が目安です。細かく切りすぎると、AIも人も「どの番号か」を毎回調べる手間が増えます。粒度に迷ったら、担当者や更新頻度が同じかどうかで区切ります。
frontmatterのconfidentiality値は誰が書きますか
原則として、ファイルを作った本人が作成時に書きます。値を書き忘れた場合の既定値をpublicではなくinternal寄りに倒しておくと、機密の漏れを防ぎやすくなります （既定値の運用は組織によって異なります）。
階層を後から変えると、AIは古い場所を探しにいきませんか
探しにいきます。番号帯の意味を変えるときは、旧フォルダを空にせず、新しい場所への案内だけを残す移行期間を置くと、参照切れを防げます。
機密分離を人間のレビューだけで運用しても大丈夫ですか
小規模なら運用できますが、restricted相当の情報は技術的な仕組み（Gitの除外設定など）と併用するほうが安全です。人のレビューだけに頼ると、確認漏れがそのまま公開範囲の事故になります。
