「Obsidian第二の脳」からSystem Linksへ　SharePoint版ナレッジ基盤の作り方

記事内に広告が含まれています。

ObsidianとClaudeを組み合わせた「第二の脳」という発想は、AIコミュニティでよく紹介されています。

Markdown形式の小さなノートを内部リンクでつなぎ、BacklinkやGraph viewで関係を可視化する。さらに、Claude Code、Claude Desktop、MCP Server、Obsidian Pluginなどを組み合わせ、AIからVault内のノートを検索、読取、作成、更新する構成です。

個人のKnowledge Managementとしては、非常に魅力的な考え方です。

では、会社のMicrosoft 365環境で、同じ発想をそのまま再現できるでしょうか。

業務データはSharePoint、OneDrive、Teams、Outlookなどに分散しています。原本は既存のSiteやLibraryに置かれ、利用者ごとに権限が異なり、版管理、保持、監査、承認、機密区分も適用されています。

そのため、企業の原本を新しいMarkdown Vaultへ複製し、そこを新たなKnowledgeの中心にするだけでは、原本境界、最新版、Access control、保持、監査の問題が生じます。

この記事では、Obsidianの「小さなNoteをLinkで接続する」という発想を、Microsoft 365上の原本保護、権限、版、監査、実行状態へ適応させた設計パターンとして、System Linksを整理します。

System LinksはMicrosoft製品、Obsidian、Anthropicの公式機能名ではありません。本記事の検討過程で定義したArchitecture patternです。

また、「Claude＋Obsidian」も一つの公式製品構成を指す名称ではありません。Claude CodeからVaultへ直接アクセスするPlugin、MCP Server、Local REST API、File system accessなど、複数のコミュニティ実装や接続方式を便宜上まとめて表しています。

Obsidianのどの発想を引き継ぐのか

Obsidianの公式Helpでは、内部Linkを使ってNote、添付File、見出し、Blockなどを接続し、Knowledge networkを作れると説明されています。

内部Linkは、次のようなWikilinkまたはMarkdown linkで記述できます。

[[Equipment A]]
[[Equipment A#Protection]]
[Equipment A](Equipment%20A.md)

ObsidianのGraph viewでは、NoteがNode、Note間のLinkがLineとして表示されます。Vault全体のGraphだけでなく、現在のNoteに関係するLocal Graphも表示できます。

System Linksが引き継ぐのは、次の発想です。

• Knowledgeを一つの巨大文書へ集約しない
• 小さな単位へ分け、LinkでContextを再構成する
• Folderの所属だけで意味を決めない
• 一つの情報から関連情報へ順番に移動できるようにする
• 全体を毎回読み込まず、必要な周辺情報だけを取得する
• 人間がLink構造を確認できるProjectionを用意する

そのまま引き継がない部分

企業環境では、Markdown Noteと内部Linkだけでは表現しにくい情報があります。

• 原本と派生情報の区別
• Draft、Approved、Superseded等の正式状態
• 利用者ごとに異なるAccess権限
• SharePointのVersionと保持状態
• Claimの根拠と検証状態
• 承認、却下、訂正の履歴
• Session、Claim、Lock、Handover等の実行状態
• File移動や改名後の再解決
• 同一内容の複製と同一Entityの区別

System Linksでは、Linkを単なる文字列ではなく、識別子、対象、種類、状態、Evidence、有効期間、検証履歴を持つRecordとして扱います。

System Linksが生まれるまでの5段階

段階1：会話の記憶だけでは継続できない

常時支援するAssistantを考えたとき、最初に問題となるのは、前回の会話を覚えているかどうかではありません。

重要なのは、次のような業務状態を再現できることです。

• 何を処理済みか
• 何が未承認か
• どのFileを変更する予定か
• どの処理が途中で停止したか
• どのClaimが競合しているか
• どのDecisionが現在有効か
• 再開時にどのSourceを確認すべきか

これらを会話の要約だけへ集約すると、要約の更新漏れ、古い状態の残存、根拠への到達不能が起きます。

そこで、Current Status、Decision Log、Open Threads、Session、Claim、Lock、Ledger Eventを別Recordとして保存し、それらをSystem Linksで接続します。

段階2：Folderは置場であり、意味のすべてではない

Folderは、人間がFileを探す入口として有効です。しかし、一つのFileが複数の設備、案件、工事、Decisionと関係する場合、Folderを一つだけ選ぶと他のContextが失われます。

次のような問題もあります。

• Fileを移動するとPath依存の参照が切れる
• 同じFile nameでも内容が異なる
• 異なるFile nameでも内容が同じ場合がある
• 同じ内容の複製でも業務上の役割が異なる
• 一つのDocumentが複数のEntityをEvidenceとして支える
• 最新版と正式版が一致するとは限らない

System Linksでは、Folder hierarchyを廃止するのではなく、Physical storageとして利用します。その上に、Entity relation、Source provenance、Revision、Decisionを表す論理Linkを追加します。

段階3：巨大なResumeを正本にしない

引継ぎ情報を一つのResumeやMarkdownへ追加し続けると、Documentが大きくなり、次の問題が生じます。

• 現在有効なDecisionが分かりにくい
• 同じ情報が複数箇所に重複する
• 一部更新で別の記述と矛盾する
• 必要部分だけを取得しにくい
• 部分取得した内容を全文と誤認する危険がある
• 同時更新時に一方の変更が失われる

そのため、ResumeをKnowledgeの正本とせず、次の構成へ分離します。

段階4：File操作とSystem Links更新を分離しない

System Linksで最も重要な考え方は、「Moveが成功した」だけでは処理完了としないことです。

File移動を例にすると、完了条件は次のようになります。

Pre-state確認
  → Session、Claim、Lockを確認
  → Source fileのID、Version、Size、Hashを確認
  → 許可された移動を実行
  → 移動後の実体を再取得
  → 内容、Metadata、Destinationを照合
  → Physical Targetを更新
  → System Linksを更新
  → RegistryとCurrent Statusを更新
  → AuditまたはLedger Eventを記録
  → Result Packageを返却

途中のいずれかが失敗した場合、単純にSucceededとせず、Failed、Conflict、RetryPending、Blocked等の定義済み状態へ移します。

特に、実体の移動だけが成功してSystem Links更新が失敗した場合は、業務上の完了ではありません。実体とRegistryが不整合な状態として、Recovery対象にします。

段階5：全件列挙を起動条件にしない

File数が増えると、毎回Rootから全Folderと全Fileを列挙する方式は安定しません。

そこで起動時には、固定された入口と現在状態だけを確認します。

_Home
  → Node Registry
  → Current Status
  → Decision Log
  → Open Threads
  → Active Session / Claim / Lock
  → 対象EntityのSystem Links
  → 必要なSourceとAtomic Record

全件列挙が必要な棚卸し処理は通常Taskから分離し、Pagination、Cursor、Checkpointを保持する別Taskとして実行します。

System Linksの基本構成

System Linksは一つのURL列ではありません。業務上の意味が異なるLinkを、別のRelation typeとして管理します。

Link Recordに保持する情報

Linkを単なる文字列にすると、切れたときの再解決や、過去状態の説明が困難になります。

一例として、次の項目を持たせます。

{
  "linkId": "LNK-...",
  "linkType": "SourceLink",
  "sourceNodeId": "CLM-...",
  "targetNodeId": "SRC-...",
  "canonicalTargetId": "DOC-...",
  "physicalTarget": {
    "siteId": "...",
    "driveId": "...",
    "itemId": "...",
    "path": "...",
    "webUrl": "..."
  },
  "sourceVersion": "...",
  "contentHash": {
    "algorithm": "SHA-256",
    "value": "..."
  },
  "verificationStatus": "Verified",
  "validFrom": "...",
  "validTo": null,
  "supersededBy": null,
  "lastVerifiedAt": "...",
  "accessBoundaryId": "...",
  "createdByEventId": "EVT-..."
}

すべての環境で同じFieldが必要とは限りません。重要なのは、次の値を混同しないことです。

Linkの状態を管理する

存在するLinkと、存在しないLinkの二値だけでは不十分です。

AccessDeniedをBrokenやNotFoundとして扱わないことが重要です。利用者に権限がない場合、Targetが存在しないとは判断できません。

Link切れの検出と再解決

Obsidianには、FileをRenameした際にVault内の内部Linkを自動更新する設定があります。

一方、Microsoft 365環境では、PathやURLだけでなく、Version、Site、Library、権限、保持、原本境界の変化も考慮します。

再解決は、次のような段階に分けます。

1. 保存済みのStorage IDでTargetを取得する
2. 取得結果のSite、Library、Item、Versionを期待値と照合する
3. 解決できない場合はCanonical Registryを確認する
4. 既知のCanonical PathやMigration mappingを確認する
5. 必要に応じてContent Hashから候補を抽出する
6. 候補の原本境界、Metadata、Version、Entity relationを照合する
7. 一意に決まった場合だけPhysical Targetを更新する
8. 一意に決まらない場合はConflictとして停止する
9. Accessできない場合はAccessDeniedとして停止する
10. 旧Linkを削除せず、SupersessionとRepair Eventを記録する

Hash一致だけで自動統合しない

同一Hashは、同一内容であることを確認する材料になります。しかし、次の可能性があります。

• 同じTemplateを複数案件へ配置した
• 同じAttachmentを複数の原本境界へ保存した
• 正式原本と作業Copyの内容が一時的に一致している
• 別の業務目的で同じDocumentを複製した
• 同じ内容でも保持PolicyやAccess権限が異なる

そのため、Hash、Source boundary、Entity ID、Document status、Version、業務Contextを組み合わせて判断します。

自己修復で行ってはいけないこと

• File nameが一致する最初のFileへ自動接続する
• Hashが一致したFileを自動的に同一Entityへ統合する
• 権限不足をNotFoundとして扱う
• 旧Linkを削除して履歴を消す
• 別SiteのFileを確認なしに新しい正本へ昇格する
• Version不一致を無視してCurrent FileへLinkし直す
• 複数候補からAIに一つを推測させて確定する

自己修復の目的は、必ずLinkを作り直すことではありません。安全に自動解決できない状態を検出し、Conflictとして人間Reviewへ渡すことも正しい結果です。

System LinksとMicrosoft 365の権限

System Linksを作成しても、Microsoft 365のAccess権限が自動的に変更されるわけではありません。

LinkはTargetへの関係を表すだけであり、利用者がTargetを読めるかどうかは、SharePoint、OneDrive、Microsoft Graph、Connector等の実際の認証と権限で判定します。

Link層で追加管理する情報

• Targetが属するSiteまたはStorage boundary
• 機密区分
• Sourceに適用されたSensitivity label
• Projectionで表示してよい情報範囲
• AccessDenied時の応答方法
• 別Boundaryへ情報を複製できるか

特に、人間向けHTML ProjectionやAI向けSummaryを作る場合、原本を閲覧できない利用者へ派生情報だけが表示される経路がないか確認します。

Version履歴とSystem Linksは別の役割

SharePointやOneDriveのVersion履歴は、Fileの過去Versionを管理するための機能です。Microsoft Purviewの保持Policyや保持Labelは、SharePointやOneDriveに保存されたFileの保持と削除を管理できます。

System Linksは、それらを置き換える機能ではありません。

たとえば、SharePointに過去Versionが残っていても、どのDecisionがそのVersionを採用したかはVersion履歴だけでは表現できません。System Linksでは、Decisionと採用Versionを明示的に接続します。

Obsidian＋Claude型とSystem Links型を比較する

以下は一般化した比較です。実際の機能は、ObsidianのPlugin、同期方法、Claudeとの接続方法、Microsoft 365のLicense、Connector、管理Policyによって変わります。

Obsidian＋Claude型のメリット

• Markdown Fileを人間が直接読める
• WikilinkとBacklinkでNote同士を簡潔に接続できる
• Graph viewで関係を探索できる
• Local-firstの構成を選択できる
• Git等を組み合わせたDiff、Rollback、Branch運用が可能
• 個人や少人数で小さく試しやすい
• PluginやMCP ServerによりAI接続を拡張できる

Obsidian＋Claude型の注意点

• Claude CodeとObsidianの直接連携は、利用するPluginやMCP Serverによって機能とSecurityが異なる
• 企業原本をVaultへ複製すると、原本とCopyの境界が増える
• Vault側のNoteが正式情報なのか個人解釈なのかを区別する必要がある
• 同時編集、同期競合、Git merge conflictの運用が必要になる場合がある
• Community PluginやMCP ServerのSource、更新、権限、通信先を確認する必要がある
• MCP Serverが外部Contentを取得する場合、Prompt injection riskも考慮する
• SharePoint、Outlook、Teams上の権限付き原本へは別の接続設計が必要
• Local Vaultだからといって、AIへ送信されるDataが常にLocal内だけで完結するとは限らない

Microsoft 365＋System Links型のメリット

• 既存のSharePointやOneDrive原本を移動せずに利用できる
• 原本とAI生成Recordを分離できる
• Microsoft 365の既存認証とAccess権限を利用できる
• SharePointのVersion historyと関係情報を分けて管理できる
• Microsoft Purviewの保持PolicyやLabelを原本管理に利用できる
• TeamsやCopilotを非技術者向けの入口にできる
• Claim、Conflict、Decision、Correctionを独立Recordとして残せる
• AgentやToolが変わっても、System LinksのContractを維持できる

Microsoft 365＋System Links型の注意点

• Canonical Entity、ID、Relation、状態のContract設計が必要
• 原本の権限と派生Recordの権限を別々に確認する必要がある
• SharePoint API、Microsoft Graph、Connector、検索Index等の制約を受ける
• 大量Fileの全件列挙を通常経路にできない場合がある
• System Linksを人間が確認するProjectionを別途作る必要がある
• Link修復で自動確定できないConflictを人間Reviewへ送る仕組みが必要
• Microsoft 365外へ移行する場合、ID、Relation、EventのExport Schemaが必要
• System Linksを作るだけでは、権限、保持、監査が自動的に完成するわけではない

二者択一ではなく併用する

個人の思考整理にObsidian、会社の正式原本と承認済みKnowledgeにMicrosoft 365を使う分離も可能です。

ただし、双方向同期ではなく、境界を持つContribution方式にする方が安全です。

Personal Note
  → Contribution候補を作成
  → 機密情報とPIIを検査
  → SourceとEvidenceを確認
  → 人間Review
  → Approved Packageを作成
  → 企業側Registryへ提出
  → ConflictまたはAcceptedを返却

併用時の原則

• 企業機密を個人Vaultへ自動複製しない
• VaultのNoteを自動的に企業正本へ昇格させない
• 個人Noteと正式Claimに別IDを付ける
• 企業側へ提出する情報をContribution Packageとして固定する
• 提出前に本人または担当者のReviewを通す
• 企業側で重複、Conflict、権限、Schema versionを検査する
• Rejectedになった個人Noteを自動削除しない
• 企業側の原本を個人側から直接更新しない

併用時の3つのZone

同じ内容が複数Zoneに存在する場合でも、同じRecordとして扱わず、DerivedFrom、SubmittedAs、AcceptedAs等のLinkで関係を残します。

どの方式を選ぶべきか

System Linksを特定のAIへ依存させない

System LinksのContractを、Copilot、Claude、GitHub Copilot、特定Pluginだけが理解できる形式にすると、AIやHarnessの変更時にKnowledge基盤ごと移行する必要が生じます。

移行性を高めるには、次の要素を外部化します。

• Node ID規則
• Relation type
• 状態名
• Source Pointer Schema
• DecisionとCorrectionのEvent Schema
• Export用JSON Schema
• Version compatibility
• Access boundary ID
• Projection生成規則

AIはこのContractを利用するConsumerまたはOperatorであり、Knowledgeの唯一の正本にはしません。

System Linksを設計する際のChecklist

Identity

• Canonical EntityとPhysical Fileを分離したか
• File nameを一意識別子として使っていないか
• Node ID、Item ID、Path、URL、Version、Hashの役割を分けたか
• 同一内容と同一Entityを区別しているか

Link model

• Source、Physical、Relation、Conflict、Decision、Runtime、Projectionを分けたか
• LinkにVerification statusがあるか
• 有効期間とSupersessionを保持できるか
• LinkからEvidenceへ戻れるか
• 旧Linkを削除せず履歴を残せるか

File operation

• MoveやRename前にPre-stateを確認するか
• Session、Claim、Lockを確認するか
• 操作後に実体を再取得するか
• System LinksとRegistry更新を完了条件へ含めたか
• 実体操作だけ成功した状態をRecovery対象にできるか
• 書込後にSize、ETag、Hash等を再確認するか

Repair

• 再解決の順序を定義したか
• Hash一致だけで自動統合しないか
• AccessDeniedをNotFoundとして扱わないか
• 複数候補ではConflictとして停止するか
• Repair Eventと旧Linkを保存するか

Runtime

• Sessionが消えてもRegistryから再開できるか
• Active Sessionと未Release Lockを検出できるか
• 一回の実行量をAtomic Taskへ制限しているか
• Current StatusとDecisionの正本が分かれているか
• Retry上限とDead Letterを定義しているか

Scale

• 全件列挙なしで目的Recordへ到達できるか
• PaginationとCursorを保存できるか
• 全件棚卸しを通常Taskから分離したか
• 必要なSubgraphだけを取得できるか
• 巨大Markdownや巨大JSONを直接更新していないか

Security and governance

• 原本と派生RecordのAccess boundaryを記録しているか
• Projectionが原本の権限を迂回しないか
• 保持PolicyとSystem Linksの役割を混同していないか
• 個人Vaultへ企業機密を自動複製しないか
• Community PluginやMCP ServerをSecurity reviewしたか
• AI Serviceへ送信されるData範囲を確認したか

Portability

• System LinksをJSON等でExportできるか
• Microsoft 365固有IDと論理Node IDを分離したか
• 別AIや別HarnessでもContractを読めるか
• ProjectionをAtomic Recordから再生成できるか
• Version compatibilityを管理しているか

現在の運用へ当てはめる

Copilot Chat、Classicエージェント、人間のHandoffを組み合わせる現在の構成では、System LinksはAgent同士のMemory共有機能ではありません。

各実行主体が同じRegistry、Current Status、Decision、Source Pointer、Result Packageを参照するための外部Contractです。

Copilot Chat
  → Python解析、変換、成果物生成
  → Instruction PackageとSource Pointerを作成

Human-controlled handoff
  → 短縮起動文と承認を転送

Classic Agent
  → InstructionとSourceを取得
  → Microsoft 365上の実体を検証
  → 許可されたFile操作を実行
  → System Links、Registry、Eventを更新
  → Result Packageを返却

Copilot Chat
  → Result Packageを解析
  → Succeeded、Conflict、Blocked等を判定
  → 次のAtomic Taskを決定

将来GitHub Copilot、Microsoft Scout、別のAgent Runtimeへ移行する場合でも、System Linksが製品固有の会話Memoryではなく、独立したSchemaとRecordとして存在すれば、原本と関係構造を維持したままOperatorを変更しやすくなります。

よくある設計ミス

1. SharePointをObsidian Vaultと同じように扱う

SharePointはFile保存だけでなく、Site、Library、Access権限、Version、保持、検索、共有等を含む業務基盤です。Markdown FileとWikilinkへ単純変換すると、これらのContextを失う可能性があります。

2. URLを永続的なCanonical IDとする

URLは人間のNavigationには便利ですが、Move、Rename、Site変更等の影響を受ける可能性があります。論理Node ID、Storage ID、Path、URLを分離します。

3. File IDだけですべて再解決できると考える

Storage IDは有力な解決手段ですが、Copy、再作成、Migration、別Driveへの移動等も考慮し、Registry、Version、Hash、Metadata、業務Contextによる検証を残します。

4. AIへLink更新を指示すれば保証できると考える

Instructionsは重要ですが、更新漏れを完全には防げません。File操作ToolやWorkflowの完了条件へ、再読込、Link更新、Registry更新、Event記録を組み込みます。

5. Graphを作れば最新状態が分かると考える

Graphは関係を表現しますが、Current、Approved、Superseded等の状態を自動的に決めません。State、Valid period、Decision、Versionを別Attributeとして管理します。

6. 個人Noteをそのまま企業Knowledgeへ取り込む

個人の仮説、所感、未確認情報と、企業の承認済みClaimは同じものではありません。Contribution Package、Review、Approvalを通して別Recordとして登録します。

7. System Linksが権限や保持を提供すると考える

System Linksは関係を表すArchitecture patternです。実際のAccess control、Version、保持、監査はMicrosoft 365とMicrosoft Purview等の機能で別途管理します。

参考資料

• Obsidian公式：Internal links
• Obsidian公式：Graph view
• Anthropic公式：Claude CodeとMCP Serverの接続
• Community implementation：Obsidian Claude Code MCP
• Microsoft Learn：SharePointとOneDriveの保持
• Microsoft Learn：SharePointとOneDriveのRecord versioning
• Microsoft Learn：SharePoint Version history limits FAQ

こんな人におすすめ

• Obsidian型のKnowledge Managementを会社でも応用したい
• SharePointの原本を別Vaultへ複製せずAI活用したい
• File移動やRename後にLinkが切れて困った経験がある
• AgentのSessionが変わっても業務状態を再開できるようにしたい
• Copilot、Claude、GitHub Copilot等を将来切り替えられる基盤を作りたい
• 原本、AI生成情報、承認済みKnowledgeを分離したい

よくある質問

Q. System LinksはKnowledge Graphと同じですか？

A. 重なる部分はありますが、同じとは限りません。

Knowledge Graphは主にEntityとRelationをGraphとして表します。System Linksは、それに加えてSource、Version、Decision、Conflict、Runtime、Projection、Supersession等の運用Linkを含む設計です。

Q. System LinksはMicrosoft製品だけで使うものですか？

A. いいえ。本記事のSystem Linksは独自のArchitecture patternです。Canonical ID、Source Pointer、Typed relation、Event、Verification stateを製品非依存のSchemaとして定義すれば、他のStorageやAgentでも応用できます。

Q. WordPressのような小規模Siteでも参考になりますか？

A. 考え方自体は応用できます。記事ID、画像、Source、Revision、関連記事、訂正履歴を分離してLinkする設計は、規模にかかわらず利用できます。

ただし、小規模SiteでSession、Lock、複雑なRegistryまで導入すると過剰設計になる場合があります。必要なLink typeだけに絞る方が現実的です。

Q. まずObsidianで始めて、後からSharePoint型へ移行できますか？

A. 可能ですが、Wikilinkをそのまま移せば完了するわけではありません。

移行を見越す場合は、Noteごとに一意IDを持たせ、Source、Entity、Claim、Relation、StatusをFrontmatter等で分けておくと変換しやすくなります。

Q. SharePointのFileをObsidianへ同期すれば簡単ではないですか？

A. 技術的に同期できる場合でも、同期Copyを原本として扱うか、個人用Cacheとして扱うかを明確にする必要があります。

原本のVersion、権限、保持、削除、Sensitivity label、同期遅延を維持できるとは限りません。企業Dataを同期する前に、組織のPolicyと承認を確認します。

Q. Claude CodeとObsidianは公式に直接統合されていますか？

A. 本記事で扱う直接連携は、主としてCommunity Plugin、MCP Server、Local REST API等を利用する構成です。単一の公式標準構成ではありません。

利用前に、対象実装のSource、権限、通信方式、更新状況、対応Clientを確認する必要があります。

Q. ObsidianのGraph viewのような表示をSharePointで作れますか？

A. System LinksのNodeとRelationから、HTML、Dashboard、専用Web Application等のProjectionを生成できます。

ただし、可視化したGraphが正本ではありません。Registry、Atomic Record、System Linksから再生成できる派生表示として扱います。

Q. System Linksが切れた場合、AIに自動修復させてよいですか？

A. 一意に再解決でき、Source boundary、Version、Metadata等を検証できる場合に限って自動修復します。

複数候補、権限不足、Version競合、Hash一致だけの候補では、自動確定せずConflictまたはRetryPendingとして停止します。

まとめ

• Obsidianから引き継ぐのは、Markdownそのものではなく、小さな単位をLinkで接続する発想
• 企業環境では、Note Linkに加えてSource、Version、Decision、Conflict、Runtimeを扱う必要がある
• SharePoint原本を新しいVaultへ移動せず、別の関係層から参照する
• Canonical Entityと現在のPhysical Fileを分離する
• URL、Path、File ID、Hash、Versionの役割を混同しない
• File操作、再読込検証、System Links更新、Event記録を一つの完了条件にする
• AccessDeniedをNotFoundとして扱わない
• 自動修復できないLinkはConflictとして安全に停止する
• Version history、保持、権限はSystem LinksではなくMicrosoft 365側の機能と組み合わせる
• 個人Noteと企業の承認済みKnowledgeはContribution境界で分離する
• System LinksのSchemaを特定のAIやHarnessへ依存させない

Obsidian型の「第二の脳」は、すべての情報を一つの巨大Documentへ集約するのではなく、小さなNoteとLinkから必要なContextを再構成する点に価値があります。

企業環境へ応用するときは、その発想へ原本境界、権限、Version、Decision、Conflict、Runtime、Auditを追加する必要があります。

System Linksの目的は、SharePointをObsidianへ置き換えることではありません。既存のMicrosoft 365原本を維持したまま、人間とAIが必要な情報へ安全に到達し、別のAgentや将来のRuntimeへ変更しても関係と根拠を失わない基盤を作ることです。

本記事の外部機能に関する情報は2026年9月10日時点です。ObsidianのCommunity Plugin、Claude Code、MCP Server、Microsoft 365の機能と提供条件は変更される可能性があります。System Linksは筆者が検討過程で定義したArchitecture patternであり、Microsoft、Obsidian、Anthropicが提供または保証する製品機能ではありません。