コンテンツにスキップ

Claude CodeとObsidianで第二の脳を作る動画要約

チェック

  • [ ] 本文を確認した
  • [ ] 概要を確認した
  • [ ] タグを確認した
  • [ ] inbox/ 直下へ移行した

概要

中国語のX投稿は、Claude CodeとObsidianを組み合わせる約59分のチュートリアル動画を紹介している。 動画の中心テーマは、ObsidianのMarkdown vaultを「AIに渡せる第二の脳」として育て、Claude Codeに自分の文脈を読ませること。 単にAIに作業させる話ではなく、日々のメモ、プロジェクト背景、好み、思考の変化をMarkdownに残し、それをエージェントの判断材料にする設計が語られている。 特に重要なのは、LLMの出力品質は「その時点でどれだけ正しい文脈を渡せるか」で決まる、という考え方。

本文

投稿の内容

投稿者は、この動画を「Claude Code + Obsidianの良い教材」として紹介している。 1時間ほど見ると、Obsidianを第二の脳として使い、AIに自分の考えを覚えさせ、パターン発見、アイデア生成、実行支援までつなげる方法が学べる、という趣旨。

動画の構成と内容

00:00-05:00 ObsidianとClaude Codeを組み合わせる意味

冒頭では、Obsidianを「第二の脳」として使う人が増えており、それをClaude Codeと組み合わせるとAIの使い方が大きく変わる、と説明される。

Claude Codeは、CLI上で動くエージェントとして紹介される。自然言語で「デスクトップにファイルを作って」「この内容を書いて」と頼むと、PC上で実際に操作できる。単発のファイル作成だけでなく、プロジェクト説明、長い対話、作業方針などの文脈が増えるほど、より複雑な作業を委任できる。

ただし問題は、毎回AIに同じ文脈を説明し直す必要があること。Web版のLLMにもメモリ機能はあるが、何を覚えているかをユーザーが完全には制御できない。そこで、文脈をMarkdownファイルとして持ち、必要なときにClaude Codeへ渡す設計が有効になる。

05:00-12:00 Obsidian vaultはMarkdownファイルの集合だが、ただのフォルダではない

ObsidianはMarkdownファイル群の上に載るインターフェースとして説明される。日記、プロジェクトメモ、人物メモ、学習メモなどをMarkdownとして保存し、[[Greg Eisenberg]] のようなリンクでファイル同士を結びつけられる。

普通のフォルダと違うのは、ファイル間の関係性を可視化し、思考のつながりを扱える点。動画では、Obsidianのグラフが「脳がパターンをつなぐ動き」に近いものとして語られる。

ここでの主張は、AI活用のゲームは「正しいタイミングで良い文脈を渡すこと」だというもの。Obsidian vaultには、自分のプロジェクト、関心、日々の思考、過去の変化が蓄積される。Claude Codeがそれを読めると、単なる一般論ではなく、その人の文脈に沿った出力ができる。

12:00-17:00 Claude Code用コマンド群

話者は、ObsidianとClaude Codeをつなぐために自作したコマンド群を紹介する。Obsidian内でターミナルを使っているが、通常のターミナルでも同じ考え方で実行できる。

紹介された主なコマンドは次の通り。

  • context/context: 人生、仕事、現在の状態に関する文脈を読み込む。README、プロジェクト文脈、日次ノート、バックリンクをたどり、現在地をClaude Codeに渡す。
  • /today: 朝のレビュー用。カレンダー、タスク、メッセージ、直近1週間のデイリーノートを読み、優先順位付きの1日の計画を作る。
  • /close-day: 1日の終わりに、アクションアイテム、vault内の関連、確信度の変化などを抽出する。
  • /ghost: vaultから自分の声・文体・視点を推定し、自分ならどう答えるかを生成し、その忠実度も評価する。
  • /challenge-topic: vault内の履歴を使い、現在の信念に矛盾、反証、考えの変化がないかを圧力テストする。
  • /emerge: vault内に散らばっている前提、名前のないパターン、まだ明文化されていない方向性を表面化する。
  • /drift: 30から60日程度の範囲で、宣言した意図と実際の行動のズレを検出する。
  • /ideas: vault全体を横断して、仕事、ツール、映画、買うものなど、複数領域のアイデアを生成する。
  • /trace: ある考えがvault内でどのように変化してきたかを時系列で追跡する。

話者は、LLMを「作るための道具」としてだけでなく「思考の相棒」として使うのが好きだと述べる。Claude Codeにvaultを読ませることで、自分では見落としていた反復パターンや、まだ名前のない考えを発見できる。

17:00-22:00 /trace デモ: Obsidianとの関係性の変化を追う

/trace の例として、「自分がObsidianをどう使うようになったか」を追跡するデモが行われる。

Claude Codeはvault内の多数のファイルとリンク関係を読み、ある概念がいつ初めて現れ、どう変化したかを構成する。例では、2024年時点ではObsidianがまだ使われておらず、音声メモ、MacWhisper、LLMとの対話、物理ノート、空間マッピングなどが使われていたと整理される。

その後、2025年の発見期では、Obsidianに音声文字起こしを入れる可能性や、双方向リンクの有用性への懐疑が出てくる。さらに、単に「podcast」「fitness」「filmmaking」のような一般語へリンクするのではなく、自分のパターン、理論、プロジェクト、視点ごとにノートを作り、それをリンクするほうが有効だという認識に変わっていく。

2026年には、Obsidian自体の摩擦よりも、vaultとエージェント実行の境界が次の課題になっている。つまり、ノートを書く段階から、ノートをエージェントにどう実行させるかへ関心が移っている。

22:00-25:00 書くことは、反省であり、AI委任のための文脈作りでもある

ホストは、Obsidianをうまく使うには日常に内省を入れる必要があるのではないか、と質問する。話者は、メモを書く理由を2つ挙げる。

1つ目は、時間の経過による自分の変化、スキルの変化、プロジェクトの変化を後から見返せること。 2つ目は、書くこと自体がアイデア生成の手段だということ。考えを書き出すことで内面化され、独自の見方が形成される。

さらに、AI時代には「書くこと」がエージェントへ委任するための文脈作りにもなる。日々の考え、プロジェクト背景、好み、仮説がMarkdownとして残っていれば、AIに渡せる情報が増え、委任できる仕事の量と質も上がる。

25:00-29:00 自律エージェントと第二の脳をつなぐ怖さ

OpenClawのような自律エージェントとの関係も語られる。例として、会議予定を入れるべきかを判断するコマンドが紹介される。

単にカレンダーを見るだけでなく、直近のデイリーノートや関連人物のノートを読んだ上で、「今日は既にその人物との収録や関連予定があるため、別ミーティングは不要かもしれない」と判断する。これは、AIが予定表だけではなく「自分が何を考えているか」まで踏まえて判断している例。

一方で、Obsidian vaultが本当に第二の脳なら、それを自律エージェントに読ませるのは怖い。話者も、Claude Codeやエージェントに多くの個人情報を意図的に読ませているが、それはこの技術が人間とコンピュータの関係をどう変えるかを理解したいからだと説明する。

プライバシーは重要な論点であり、実演用にも個人情報を出しすぎないようデモ用コマンドを別途作っている。それでも画面に何が出るかわからないため、完全には安全と言い切れない。

29:00-35:00 /connect と、AIに書かせすぎないルール

/connect は、vaultのリンクグラフを使って2つの領域を接続するコマンド。例では、filmmakingとworldbuildingをつなぎ、それぞれの周辺ノートを読み、共通する橋渡し概念を出す。

たとえば「インタビューは相手の内的世界への入口である」「企業や人の継続的なドキュメンタリー化は世界構築に近い」といった形で、過去に書いた断片同士の接続を見つける。

会議メモの扱いについても触れられる。GranolaやGeminiなどで取った会議文字起こしをObsidianに入れれば、それもvaultの文脈になる。タグやリンクを付ければ、エージェントはその会議がどのプロジェクト、人、テーマに関係するかを理解しやすくなる。

ただし話者は、自分のメインvaultにAIが勝手にファイルを書くことは避けている。理由は、後でエージェントがパターンを探すとき、それが自分の考えから出たパターンなのか、AIが書いた内容から出たパターンなのかが混ざるから。自分のvaultは、自分の思考を記録する場所として保ち、AIの出力は横に置いて、人間が採用するものだけを取り込むという分離をしている。

35:00-42:00 アイデア生成デモ: vault全体を読ませて行動可能な提案にする

次に、より実行寄りの例としてアイデア生成が紹介される。Claude Codeはvault構造、孤立したノート、デッドエンド、タグ数、デイリーノート、プロジェクト文脈、個人ワークフロー文脈を読み込む。

ここで重要なのは、Obsidian vaultを読ませる依頼は時間がかかるということ。単発プロンプトではなく、多数のファイルを読み、リンク関係を理解し、現在の関心やプロジェクト背景を反映するため、数分単位の処理になる。ただし話者は、それこそが欲しい出力だと言う。自分の現在地、プロジェクト、好み、関心を深く反映した応答が得られるから。

ホストはこの働きを、コーチやセラピストのように「点をつなぐ」ものとして表現する。人間は自分の生活や仕事の点をつなぐのが難しい。ObsidianとClaude Codeの組み合わせは、その点を見つけ、関連づけ、気づきを返す。

42:00-50:00 アイデアからコマンドやツールを作る

アイデア生成の結果として、いくつかの実行可能な提案が出る。

  • /graduate: デイリーノート内に眠っているアイデアを検出し、独立ノート化するか、既存ノートに追記するか、捨てるかを判断させるコマンド。
  • チーム用Obsidian vault: 個人vaultと同様に、チームの文脈、仮説、プロジェクト、アイデアを蓄積し、チーム全員で問いを投げられる場所を作る。
  • day-per-domain型の時間ブロックアプリ: 曜日や日ごとの集中領域を強制し、注意を分散させないアプリ。
  • ノート内からのインライン委任: デイリーノートに「今週この人とこの話題で通話を設定する」と書くと、Otis、Claude Bot、OpenClawのようなエージェントが拾って処理するUX。

話者は、最初は自分でコマンドを考えていたが、次第にClaude Codeへ「自分のvaultと現在のスキルレベルを踏まえると、次の段階へ進むためにどんなコマンドが必要か」と聞くようになったという。これは、より高い抽象度でAIに相談する使い方。

AIは単に命令されたコマンドを作るだけでなく、vaultから本人の癖や関心を読み、必要なコマンド自体を提案し、そのまま実装できる。話者にとってそれは、自分のノートを見ている並列エージェントが、ワークフローや人生を改善する提案をし、さらに道具まで作る状態に近い。

50:00-58:54 MarkdownファイルはAI時代の記憶になる

終盤では、ObsidianのようなMarkdownベースの集中ノート環境が、LLMを本気で使うための欠けていた部品だと語られる。

ただし、正しくセットアップするには時間がかかる。Obsidianは空白のキャンバスに近く、どこに好みを書くべきか、どう構造化すべきかを最初から案内してくれるわけではない。自分で文脈ファイル、プロジェクトファイル、日次メモ、リンクのルールを育てる必要がある。

それでも、一度説明をMarkdownファイルに落とせば、AIには何度も説明しなくてよい。プロジェクトの説明、好み、判断基準、過去の反省がファイルとして残り、必要なときに参照できる。人間の記憶は変形するが、ある時点で書いたMarkdownは、その時点のデータポイントとして残る。

最後に、AI時代においてMarkdownファイルは単なるメモではなく、LLMにとっての記憶や酸素のようなものだと表現される。中心にあるのは、高度なUIではなく、相互リンクされたMarkdownファイル群。それをどう育て、どうエージェントへ渡すかが、個人OSや第二の脳の実用性を左右する。

要点

  • Claude Codeの価値は、単にコードやファイルを作ることではなく、十分な文脈を読ませた上で作業・判断・発見を委任できる点にある。
  • Obsidian vaultは、Markdownファイルとリンクによって、自分の関心、プロジェクト、仮説、変化をAIに渡せる形で蓄積する場所になる。
  • context/context/today/close-day/trace/connect/ideas/graduate のようなコマンドで、ノートを行動や判断へ変換できる。
  • 重要なのは「AIに全部書かせる」ことではなく、人間が書いた思考のログを信頼できる文脈として保つこと。
  • エージェントに第二の脳を読ませると強力だが、個人情報とプライバシーのリスクが大きい。
  • LLM活用の質は、モデル単体よりも、最新で深い文脈をどれだけ整備して渡せるかに強く依存する。
  • 実務に落とすなら、まずプロジェクト文脈、日次メモ、意思決定ログ、好み、避けたいことをMarkdownで残すのが効く。

タグ

claude-code #obsidian #ai-agent #personal-knowledge-management #markdown #second-brain #context-engineering