ObsidianとClaudeを組み合わせた「第二の脳」という発想は、AIコミュニティでよく見かけます。MarkdownのノートをWikilinkでつなぎ、Graph viewで可視化し、Claude CodeやMCPから読み書きする。個人のナレッジ管理としては非常に魅力的です。
では、会社のMicrosoft 365環境で同じことをやろうとするとどうなるか。業務データはSharePointやOneDrive、Teams、Outlookに分散していて、既存の権限・版管理・保持ポリシー・監査・承認手続きを崩さすわけにはいかない。この記事では、Obsidianの「小さなノートをリンクでつなぐ」という発想を、企業向けの原本保護・権限・監査へ適応させた設計パターン――System Links――に自分用に整理しました。
System LinksはMicrosoft製品の公式機能名ではなく、検討過程で定義したアーキテクチャパターンです。またClaude+Obsidianの事例も単一の公式標準ではなく、公開されている実装例の一つです。
この記事でわかること
- Obsidian型の「第二の脳」とCopilot+SharePoint型の発想の違い
- System Linksが生まれた5段階の検討過程
- 両方式のメリット・デメリットと、併用する際の注意点
- System Linksを自分で設計する際の実務チェックリスト
Obsidianの発想をSharePointへ移す
Obsidianは内部リンクでノート同士のネットワークを作り、Graph viewでNodeとLinkを可視化します。「Markdownが知識本体であり、リンクが文脈を形成する」という考え方は、企業向けに移す際の重要な着想になりました。この発想を、SharePoint上の管理レコードと明示的リンクへ置き換えたものが本稿のSystem Linksです。
System Linksが生まれるまでの5段階
| 段階 | 内容 |
|---|---|
| 1. 常駐型アシスタントの構想 | 変更検知→差分抽出→状態集約→定期ブリーフの3ループ（対応・事前処理・運用学習）を検討 |
| 2. フォルダ中心から差分・状態中心へ | 1文書が複数案件に関係する、移動で参照が切れる、同名別内容・別名同内容——フォルダ階層だけでは解決しない問題が判明 |
| 3. Resume中心からGraph+Event+Projectionへ | 引継ぎ文書が巨大化し、最新が判別しにくくなったため、Registryを入口に関係Recordをたどる方式へ移行 |
| 4. ファイル操作へSystem Links更新を組み込む | 「忘れず更新して」と指示するだけでは保証できないため、Move等のツール処理自体へ強制する |
| 5. 全件列挙不能を前提にした運用 | 起動時はRegistryとCurrent Statusだけを読み、そこからSystem Linksをたどる方式へ |
特に重要なのは段階4です。ファイル移動では、新しいFile ID取得→移動後の内容確認→System Links更新→Registry更新→完了記録、という一連を「1つの完了条件」として扱います。Moveだけを成功とみなさないのがポイントです。
System Linksの構成
System Linksは1本のURL列ではなく、用途の異なるリンク群として扱います。
| Link種別 | 接続対象 | 目的 |
|---|---|---|
| Canonical link | 正本Registry、正規Entity | 入口の一意化 |
| Source link | 原本ファイル、版、頁、セル | 根拠への到達 |
| Parent/Child link | 上位・下位Record | 構造の再構成 |
| Relation link | 設備、文書、案件、設定値 | 意味的関係の表現 |
| Conflict link | 競合するClaim | 矛盾の追跡 |
| Decision link | 判断、承認、却下、訂正 | 採否理由の追跡 |
| Runtime link | Session、Claim、Lock、Handover | 実行再開 |
| Projection link | HTML、Dashboard、Report | 人間向け表示への到達 |
| Supersession link | 旧版、新版、訂正文書 | 版と訂正の追跡 |
ワンポイントメモ
論理的なCanonical Targetと、現在のPhysical Targetは別にするのがポイント。ファイル名だけでLink対象を決めず、Link自体にも検証状態を持たせ、旧Linkは削除せず有効期間やSupersessionで履歴を残します。
リンク切れと自己修復
Obsidianはファイル名変更時に内部リンクを自動更新できますが、SharePoint型はURL変更やFile ID変更、権限変更などより多くの変化を想定します。修復は次の順序で行います。
- File IDまたは永続識別子で再解決
- Canonical PathとRegistryで再解決
- 内容ハッシュで同一内容候補を確認
- 原本Metadataと版を照合
- 一意に決まらない場合はConflictまたはRetry Pendingで停止
- 修復Eventと旧Linkを監査記録へ残す
ハッシュ一致だけで別ファイルを同一Entityに統合しないことが重要です。同じテンプレートや同一添付の複製の可能性があるため、原本境界・業務文脈・版・Entityを合わせて判断します。
2つの方式を比較する
| 観点 | Claude + Obsidian型 | Copilot + SharePoint + System Links型 |
|---|---|---|
| 保存単位 | ローカルまたは同期されたMarkdown Vault | SharePoint原本、Atomic Record、Registry、Event |
| リンク | Wikilink、Markdown link、Backlink | Entity ID、Source link、Relation、Canonical link |
| 可視化 | Obsidian Graph view | HTML Projection、Dashboard |
| AI接続 | ファイル直読、MCP、REST plugin | Microsoft Graph、Connector、Workflow、Agent tool |
| 版管理 | Gitまたは同期履歴 | SharePoint版履歴、Event、Hash、Correction |
| オフライン性 | ローカルのとき高い | 基本的にCloud接続依存 |
| 非技術者展開 | Vault配布・Git・MCP運用が必要 | 既存Microsoft 365基盤へ統合しやすい |
| Vendor lock-in | Markdownは可携性が高い | Microsoft 365依存が大きい |
Claude + Obsidian型のメリット・デメリット
メリット
- Markdownが中心で人間が直接読める
- GitによるDiff・Rollback・Branch運用と相性がよい
- WikilinkとBacklinkで知識接続が簡潔
- Claude Code、Skills、Hooks、MCPを組み合わせやすい
- 個人・少人数の試行を小さく始めやすい
デメリット
- 企業の原本をVaultへ複製すると版と原本境界が複雑化
- 同時編集やMerge conflictへの運用設計が必要
- MCP serverやCommunity pluginのSecurity reviewが必要
- Office文書・メール・権限付きSharePoint原本は別接続が必要
Copilot + System Links型のメリット・デメリット
メリット
- 既存SharePoint/OneDrive原本を動かさず利用できる
- Microsoft 365の認証・権限・版管理・保持・監査と統合しやすい
- 原本とAI生成Recordを分離できる
- TeamsやCopilotを非技術者の入口にできる
デメリット
- 初期のContract・Registry・状態・権限設計が重い
- SharePoint APIやConnector、検索Indexの制約を受ける
- System Linksを可視化する専用Projectionが別途必要
- Microsoft 365外へ移行する場合はExport設計が必要
併用するという選択肢
二者択一である必要はありません。公開情報や個人メモはObsidian、社内原本と承認済み知識はSharePointという分離も可能です。ただし双方向同期は慎重に設計します。
- 企業機密を個人 Vaultへ自動複製しない
- Vaultのノートを自動的に企業正本へ昇格させない
- 共有時はContribution PackageとReviewを通す
- 同一Entityでも個人メモと正式Claimは別IDにする
どちらを選ぶべきか
| 条件 | 適する方式 |
|---|---|
| 個人・少人数で始める、Local-firstを重視 | Claude + Obsidian型 |
| SharePoint/Teams/Outlookが業務基盤、原本を動かせない | Copilot + System Links型 |
| 個人の思考整理と企業正本を分離したい | ハイブリッド |
System Linksを設計する際のチェックリスト
- Canonical EntityとPhysical Fileを分離したか
- Source・Relation・Conflict・Decision・RuntimeのLink種別を分けたか
- File ID・Path・URL・Hashの役割を混同していないか
- Move/Rename後のLink更新を完了条件へ含めたか
- リンク切れを自動修復できない場合、安全に停止するか
- 権限不足を「存在しない」と誤判定しないか
- 旧版Linkを削除せず履歴を追跡できるか
- Sessionが消えてもRegistryから再開できるか
- 全件列挙なしで目的Recordへ到達できるか
- Projectionを原子Recordから再生成できるか
参考資料
こんな人におすすめ
- Obsidianでの知識管理に興味があるが会社のSharePointとどう併用するか悩んでいる
- ナレッジ基盤でファイル移動・リネーム後にリンクが切れて困った経験がある
よくある質問
Q. System LinksはWordPressのような小規模サイトでも参考になりますか？
A. 考え方自体は応用可能です。「ファイルを動かさず、意味を持つリンクで結びつける」という発想は、規模に依存しません。
Q. まずObsidianで始めて、後かSharePoint型へ移行できますか？
A. 可能ですが、MarkdownのLink構造をそのまま移すことはできません。EntityとClaimの単位を意識して記録しておくと、移行時の変換が楽になります。
コメント