この記事でわかること

Obsidian×Claude Codeの連携は、繋ぐところまでは記事を見ればできる。問題はその次で、自分の場合も一度は開かなくなった。7週間続いている今の形は、発想を逆にしたら回り始めた。Obsidianは自分では最小回数しか開かない。読解はClaudeにやらせて、自分はClaudeと議論する。 つまりClaudeを通訳として挟む。この記事では、その運用の中身と、7週続けて分かった線引きを書く。

記事概要図

連携したあと、続くかどうかの分かれ目 よくある形(開かなくなる) 自分が読みに行く ノートだけ増える 量に負けて開かない 読み返す労力が積み上がる この記事の形(通訳を挟む) 自分は議論だけする 論点 Claudeが読解する Obsidianに積む 自分はここを最小回数しか開かない

繋ぐところまでは、たぶん誰でもできる

ObsidianとClaudeを繋ぐ話は、これまでにも何度か書いてきた。MCPで繋いだ時の実録もあるし、obsidian-skillsでAIに作法を教える導入手順もまとめた。手順自体は、詰まるところがあってもネットを探せば大抵解決する。

問題はその後だった。繋いだ直後は面白いので毎日開く。ところが数週間すると、ノートは増えているのに自分が読みに行かなくなる。これは自分の意志が弱いという話ではなくて、単純に量が増えた読み返しは労力的にきついし、読んでも頭に入らないからだ。

世の中の連携記事を8本ほど見比べてみたが、7本はセットアップの手順で終わっていた。「繋いだ後どう回すか」まで書いているものは、ほとんど無い。自分もそこで一度止まった。

発想を逆にした:Obsidianは自分で開かない

今の形に落ち着いたきっかけは、続ける工夫を足すのをやめたことだった。読み返しが続かないなら、自分が読み返さなくていい形にすればいい

そこで役割をこう決めた。

  • Obsidian=置き場。自分は最小回数しか開かない
  • Claude Code=通訳。ノートを読解して、議論できる形にして出してくる
  • 自分=Claudeが出した論点に対して、判断する人

ポイントは、AIに「要約させる」で止めないところだ。要約が返ってきても、結局それを読む労力は残る。自分が欲しいのは要約ではなくて、議論の相手だった。だから毎回の依頼も「まとめて」ではなく、「先週と比べて何が変わったか、判断が必要な点はどこか」と聞く形にしている。

この時、ノートは自分のためではなくClaudeのために書いていることになる。これが分かってから、書き方も変わった。

残すのは5ブロックだけ

週次の振り返りは、Obsidianの中に週ごとのファイルとして積んでいる。ここで大事なのは、その週の作業ログを全文残さないことだ。

残しているのは次の5つだけにした。

ブロック中身
KPIダッシュボード数値と前週比だけ。所感は書かない
売上ファネルどこで止まっているか
今週の判断何をどう決めたか、理由つきで
来週の最優先3つ3つ以上書かない
続ける / やめる / 変える迷っている候補を置いておく

全文を残さないのは、後で読み返す時のためではなく、Claudeに読ませた時に判断がブレないためだ。作業ログを全部残すと、Claudeは大量の「やったこと」に引きずられて、肝心の「決めたこと」を拾いにくくなる。逆に判断だけが並んでいると、前の週との差分が一発で出る。

書かない項目を決めるほうが、書く項目を決めるより効いた。ここはタスク管理をObsidianとClaudeで回した時にも同じ感触があって、情報を減らすと精度が上がるのは一貫している。

7週続けて、積み上がるものと積み上がらないもの

このやり方で週次ファイルが7週分たまった。実際に積み上がったのは、思っていたものと少し違った。

積み上がったものは、判断の履歴だった。「先月これをやめる判断をした」「その前の週に同じ理由で保留した」という流れが残っているので、同じ論点が再燃した時に一からやり直さずに済む。

積み上がらなかったものは、作業の詳細だった。何時間かかったとか、どのコマンドを打ったとか、そういうものは書いていても一度も参照していない。もし全部残していたら、Claudeに読ませるコストだけが増えていたと思う。

もう一つ効いたのが、前週比を必ず入れるルールだった。単体の数字は良し悪しが判断できないが、前週比が並ぶと自分の施策が効いたかどうかを議論の俎上に載せられる。Claudeに聞く時も「増えた要因の候補を出して」と頼めるようになる。

積んだノートが、自分の判断ミスを見つけた

一番効果を実感したのは、つい先週のことだった。

その週の振り返りに、自分は「予定していた記事の枠は全部消化した」と書いていた。書いた時点では本当にそう思っていた。ところが翌週、Claudeに過去の週次ファイルと記事の計画表をまとめて読ませて、「この記録は今のデータと整合しているか」と聞いてみたところ、未消化の枠が1本残っていると返ってきた。

確認したら、確かに残っていた。しかも、その枠を優先していた根拠のデータを実測し直したら、根拠のほうが既に成り立っていなかった。つまり自分は、根拠が消えている作業を「やり残し」として抱えたまま、しかもやり残していること自体を見落としていた

これは記憶では絶対に気づけない。1週間前の自分の書き方を正確に覚えていないし、覚えていたとしても「間違っているかもしれない」と疑うきっかけがない。過去の判断が同じ形式で並んでいて、それを読む係が自分以外にいたから出てきた指摘だった。

このとき、ノートを積む意味がやっと腑に落ちた。未来の自分のためではなく、自分にツッコミを入れる相手のために積んでいる。

Vaultを触らせる時の線引き

ただ、AIにVaultを読ませる運用には注意がいる。Obsidianは何でも放り込める置き場なので、副業だけのVaultになっている人のほうが少ないはずだ。そこを一緒くたに読ませるのは、まずい。

ここで自分が取っているのは、読ませたくないものを数え上げるのではなく、渡す範囲を先に決めてそこだけ指定するやり方だ。依頼の形はこうなる。

副業レポート/週次/2026/ と 記事ネタ/ を読んで、
先週からの変化と、判断が必要な点を出して

「Vault全体を見て」とは頼まない。除外する側を並べる作戦は、フォルダが増えた時に必ず抜けが出るので続かない。渡す側だけを挙げるほうが、手間も少ないし事故りにくい。

もう一つ、書き込みは基本的にやらせていない。読解と提案までがClaudeの役割で、ファイルを更新するかどうかは自分が決める。全部任せたほうが楽ではあるが、判断の履歴が誰の判断か分からなくなると、上で書いたツッコミ役が機能しなくなる。ここは楽さより一貫性を取った。

3つの結論

7週間やってみて、言えるのは次の3つになった。

1. 続かない原因は意志ではなく設計にある。 読み返す前提で作ると、量が増えた時点で必ず止まる。自分が読み返さない前提で組んだほうが結果的に続く。

2. AIには要約ではなく議論をさせる。 要約は読む労力が残る。「判断が必要な点はどこか」と聞く形にすると、通訳として機能し始める。

3. 残す項目より、残さない項目を決める。 作業ログを削って判断だけを残したら、前週との差分が出るようになった。

連携そのものは、正直そんなに難しくない。難しいのはその後の設計のほうで、しかもそこを書いた記事が少ない。もし今まさに繋いだところで止まっているなら、まず「自分がObsidianを開く回数を減らすには?」から考えてみてほしい。

Claude Code自体の使い方をもう少し体系的に押さえたい場合は、Udemyで講座を探す(セール時が狙い目)のも手っ取り早い。自分は手を動かしながら足りない部分だけ拾う使い方をしている。

Obsidian側の土台を整えるなら、外部脳にするプラグイン8選のほうもあわせてどうぞ。