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