AIエージェントが、数年分の知識管理基盤を丸ごと手入れする時代が来ています。
2026年7月4日、AIコンサルタントのAshutosh Shrivastava氏（@ai_for_success）は、AnthropicのClaude Fable 5にNotionワークスペース全体の解析とデータベーススキーマの修正・移行を任せ、そのうえでObsidian vaultへ日次差分同期するスクリプトまで生成したと報告しました。次の段階として、同期したvaultをHermes agentに接続し、埋め込みベクトルとナレッジグラフで音声操作できるIRISプロジェクトへ統合する計画も示しています（参考）。
この記事では、同氏の事例を軸に、なぜNotionとObsidianを分け、Fable 5のような長時間エージェント向けモデルが必要になるのかを整理します。
この記事でわかること
- Fable 5でNotionワークスペース全体を解析・移行した具体的な流れ
- データベーススキーマ不整合が知識管理を壊す理由
- Obsidianへの日次差分同期スクリプトが担う役割
- Hermes agentでNotion MCPと埋め込み検索を使い分ける考え方
課題は「肥大化したNotion」と「エージェントが検索できない壁」
Notionはチーム向けのデータベース、タスク管理、テンプレート配布に強い一方、個人の知識が数年にわたって蓄積すると構造が複雑になります。データベース間のリレーション設定ミス、プロパティ名の揺れ、リンクビューと原本データベースの取り違えなど、スキーマ上の不整合はAPI連携や自動化の足かせになります。Notion公式APIでも、データソースのプロパティ定義がスキーマの正本であり、個別ページの値とは別に管理されると明記されています（参考）。
Shrivastava氏は、3〜4年分の大量データを抱えていました。Hermes agentのNotion MCPは、ページの作成・更新・整理といった変更操作には向いています。一方、長期にわたるノート横断の検索や文脈理解、要約には不向きだと指摘しています。MCPで検索を重ねると数十ステップが必要になる場面でも、埋め込みベクトルとナレッジグラフなら数ステップで関連文脈を引ける、という使い分けです（参考）。
つまり課題は二層あります。まずNotion内部のスキーマを整え、データを信頼できる形に移行する。次に、エージェントが高速に検索できるローカル知識ベースへ同期する。この両方を人手で進めるには、調査・修正・スクリプト作成・検証の工数が積み上がります。
Fable 5が担った作業の中身
Claude Fable 5は、Anthropicが2026年6月9日に公開した第5世代モデルで、数日単位の非同期タスクをエージェントハーネス上で継続できるよう設計されています。大規模なコード移行、複雑な実装、自律的なテスト作成まで任せられると公式に位置づけられており、2026年7月1日にはグローバル提供が再開されました（参考）。
Shrivastava氏がFable 5に依頼した作業は次のとおりです。
- Notionワークスペース全体の解析
- データベーススキーマ上の問題の特定と修正
- 修正を反映した状態への移行
- Obsidian vaultへ毎日実行する差分同期スクリプトの生成
「解析→修正→移行→同期スクリプト作成」を一連の依頼として渡した点が、この事例の核心です。単発のプロンプトではなく、ワークスペース全体を対象にした長時間作業を想定したモデル選択になっています。Stripeが5,000万行規模のRubyコードベース移行を1日で完了した事例が公式に紹介されているように、Fable 5は大規模な構造変更をエージェントに任せる用途で評価されています（参考）。
Notion側では、リレーション先データベースの共有漏れやリンクビューと原本の取り違えがAPIエラーにつながる典型例として知られています。既存のObsidian連携プラグインでも、スキーマ取得とプロパティマッピングが初期設定の要になるとドキュメントに書かれています（参考）。Fable 5が行ったのは、この手作業になりがちな棚卸しと修正を、ワークスペース単位で前に進めた点です。
Obsidian日次同期スクリプトが解くこと
ObsidianはローカルにMarkdownファイルを置くノートアプリで、vaultと呼ばれるフォルダがデータの本体です。Gitで履歴管理しやすく、バックリンクでノート同士を結べるため、エージェントの読み書き先としてよく選ばれます。
Shrivastava氏がFable 5に作らせたスクリプトは、毎日実行し、変更差分（デルタ）を追跡して、ノートの新規作成と更新を自動化します。既存の同期ツールでも、再同期時に前回以降の変更だけを取り込む増分更新や、削除フラグの付与といった設計が採用されています（参考）。日次バッチで走らせることで、Notion側の更新がローカルvaultへ継続的に反映され、エージェントは常に最新のMarkdownを参照できます。
同期の方向性は一方向です。Notionを運用の正本とし、Obsidianをエージェント向けの検索・推論レイヤーとして使う構成です。Hermes agentの公式ガイドでも、チーム向けデータベースはNotion、ローカルMarkdownとレビューはObsidian、という役割分担が推奨されています（参考）。
Hermes agentとIRISへの接続計画
https://hermes-agent.ai/blog/hermes-agent-obsidian-integration
同期したvaultは、Shrivastava氏のHermes agentに読み込ませる予定です。Hermes agentはMarkdown vaultをファイルシステム経由で読み書きするエージェント基盤で、永続メモリ・スキル・セッションと、人間が読めるノートを分離して運用する設計が推奨されています（参考）。
次のステップは、vault全体の埋め込みベクトル生成と、IRISプロジェクトへの統合です。IRISは同氏が開発中のAIアシスタントで、Gemini LiveとHermes agentを組み合わせ、ウェイクワードや透明HUD、ハンドジェスチャー操作などを備えたと別投稿で紹介されています（参考）。音声でナレッジグラフのノードをたどれるようにする、という発想は、検索UIを画面操作から声に移す試みです。
ここで重要なのは、Notion MCPを変更系ツールとして残しつつ、検索は埋め込みとグラフに任せる二段構えです。変更と検索を同じ経路に押し込むと、トークン消費とレイテンシが膨らみます。vault同期でローカルに知識を寄せ、検索専用の経路を別に用意する方が、長期データでは合理的です。
再現するうえでの前提と注意点
この事例は個人の実運用報告であり、生成されたスクリプトのソースコードは公開されていません。再現には、NotionインテグレーションのAPIキー発行、対象データベースの共有設定、Obsidian vaultのパス設計、日次実行のcronやlaunchd設定が必要になります。
Fable 5は入力トークン100万あたり10ドル、出力50ドルと高単価です（参考）。ワークスペース全体の解析は一度きりの投資として割り切れる一方、日次同期の検証とエラーハンドリングは人間のレビューが欠かせません。サイバーセキュリティや生物学関連のクエリはOpus 4.8へフォールバックする安全装置もあり、意図しないルーティングが起きないか確認する価値があります（参考）。
最初からvault全体をエージェントに開放するのではなく、専用フォルダから始め、読み書き範囲を段階的に広げるのがHermes側の推奨パターンです。機密情報や個人メモが混在するvaultでは、スコープを絞ったうえで同期対象を選ぶべきです。
知識管理の次の一手
Fable 5でNotionの棚卸しと移行を済ませ、Obsidianへ日次差分同期するスクリプトまで一気に組み上げたShrivastava氏の事例は、AIエージェントが知識管理基盤そのものを整備し始めた具体例です。Notionを構造化データのハブに、Obsidianをエージェント向けの高速検索レイヤーに分ける設計は、長期ノートを抱える個人や小規模チームにそのまま応用できます。埋め込みとナレッジグラフをIRISへ載せる次の段階が、音声インターフェースとどう噛み合うかも注目に値します。