ObsidianのMarkdownをClaude Codeに接続して自動業務エンジンを作る方法

ウェブクリッパーが持ってきたゴミデータの掃除から始める

ウェブからスクレイピングしたMarkdownファイルは、広告やメニューバーなどのノイズの塊です。このようなテキストが混ざっていると、RAG（検索拡張生成）の性能が目に見えて低下します。実際に、精製されていないデータはモデルの注意力を分散させますが、きれいに整理されたMarkdownは検索精度を高めます。不要なテキストを削ぎ落とせば、ローカルLLMが消費するトークンも30%以上減るため、コストの節約にもなります。

PythonのBeautifulSoupライブラリを使って、このノイズを取り除く必要があります。

1. ターミナルで pip install beautifulsoup4 lxml を入力して環境を整えます。
2. スクリプトで decompose() メソッドを使い、.ad-container や .nav-menu といった不要なCSSクラスを丸ごと削除します。
3. lxml パーサーで本文だけを抽出し、Markdownとして保存してObsidianの保管庫（Vault）に入れます。
   これにより、モデルが核心的な内容だけに集中できるようになり、ハルシネーション（もっともらしい嘘）が減り、トークン消費量も25%程度まで劇的に抑えられます。

Claude Codeが迷子にならないフォルダー設計

ファイルが数百個に増えると、どんなに賢いモデルでもコンテキストを見失います。ただファイルを積み上げておくのではなく、情報の状態に応じて区域を分けてください。私はPARAフレームワークをアレンジした3段階（01_Raw_Inbox、02_Processed_Wiki、03_Project_Action）の構造を使っています。Claude Codeがどの情報を信頼して参照すべきか、物理的なガイドラインを与えるのです。

エージェントが迷わないように、ファイル名とターミナルオプションを活用します。

1. すべてのファイル名の先頭に YYYY-MM-DD を付けて、情報の鮮度を伝えます。
2. Claude Codeを実行する際、--newer-than オプションを使って最近24時間以内に更新されたファイルだけを読み込ませます。
3. 03_Project_Action フォルダーには作業状態が記されたファイルだけを置きます。
   この構造を整えれば、Claudeが保管庫全体をかき回すような無駄な動きをしなくなります。おかげで10分かかっていた検索が30秒で終わります。

YAMLメタデータで検索の穴を埋める

単純なテキスト検索では、その文書が「重要なのか」あるいは「完了したことなのか」を区別できません。そのため、文書の上部にYAML Frontmatterを入れる必要があります。メタデータがあれば、Claude Codeに対してより精巧な命令を下すことができます。

ナレッジ起業家の業務エンジンに必要なフィールドは3つで十分です。

1. トピックを分ける topic、重要度を判断する source_importance、作業状態である status をノートの冒頭に記します。
2. Obsidianの「YAML Toolkit」プラグインを使って、既存の数百個のファイルにこのルールを一括適用します。
3. Claude Codeの設定ファイル（CLAUDE.md）に「statusがDoingの文書だけを見て業務リストを作成せよ」と記述しておきます。
   毎朝2時間かけていた資料整理の苦労から解放され、10分で業務ブリーフィングを受けられる状態になります。

コマンド一行で終わらせるデイリーブリーフィングルーチン

ターミナルベースのClaude Codeは、シェルスクリプトと組み合わせた時に真の力を発揮します。出勤してコマンドを一つ打つだけで、昨日学習した内容を分析し、今日送るメールの下書きまで作成してくれるエンジンが完成します。毎朝「まず何をすべきか」と悩み、エネルギーを浪費する必要はありません。

自動化ルーチンは次のように構築します。

1. claude --bare コマンドを入れたシェルスクリプト（.sh または .bat）を作成し、初期起動速度を上げます。
2. find -mtime -1 コマンドをスクリプトに組み込み、直近1日間に作成されたノートだけをClaudeに渡します。
3. Claude CodeのPostToolUse機能を使って、生成されたメール下書きの誤字を修正し、特定のフォルダーに自動保存させます。
   メール一通書くのに30分かかっていた時間が5分に短縮されます。

データ爆発に対処する階層的参照戦略

ファイルが1,000個を超えると、20万トークンのコンテキストウィンドウもすぐに埋まってしまいます。ここからは、すべてのファイルを読み込ませるのではなく、全体の地図の役割を果たす master_index.md を先に参照させる2段階方式を採用すべきです。この方式はAPI呼び出し回数を60%近く削減します。

性能を維持するには、コンテキスト管理を賢く行う必要があります。

1. 全体のトークン消費を以下のような構成で理解し、管理します。$$T_{total} = T_{system} + T_{index} + T_{active\_files} + T_{history}$$
2. Claude Codeがマスターインデックスを先に読み、質問に答えるために不可欠なファイルパスだけを探し出すようにします。
3. 見つけ出したパスのファイルだけを追加で読み込んで回答を作成し、会話が長くなったら /compact コマンドで履歴を要約します。
   この階層構造を導入すれば、データがいくら積み重なっても、もたつくことなく即座に意思決定のサポートを受けることができます。