AIに「自分の文脈」を渡すために。Obsidianを第二の脳として育て始めた
生成AIやAIエージェントを使っていると、ときどき妙な感覚になります。
目の前のAIは優秀です。コードも文章も、以前よりずっと速く形になります。けれど新しいセッションを始めるたびに、AIは基本的に「初対面」です。以前に何を設計し、どこで迷い、なぜその案を捨てたのかは、こちらが渡さなければ知りようがありません。
私は長くITの仕事に関わり、最近はAWS、生成AI、Claude Code、Codexを日常的に使っています。そのなかで強く感じるようになったのが、AIに必要なのは最新のプロンプトだけではなく、自分の過去の文脈なのではないか、ということです。
そこで、これまでトラブルシューティングのメモ置き場として使っていたObsidianを、少し違う目的で育て始めました。プロジェクトごとの判断記録をMarkdownで残し、次のAIセッションには必要な一枚だけ渡す。目標は壮大な自動化ではありません。まずは、過去の知識・経験・判断理由を、次の自分とAIが読める場所に残すことです。
もともとは、トラブルシューティング用のメモだった
Obsidianを使い始めた頃の目的は実用的でした。調べた設定、障害対応の手順、あとで再利用したいコマンドや設計メモを保存する。それだけでも、検索できる自分用のノートは十分に役に立ちます。
ObsidianのVaultはローカルファイルシステム上のフォルダであり、ノートはMarkdownのプレーンテキストとして保存されます。公式ヘルプでこの仕組みを確認したとき、アプリ固有のデータベースに閉じず、普段のエディタやGitとも付き合える点が私には魅力でした。
ただ、メモが増えるほど別の問題が見えてきます。「書いてある」のに「使えない」のです。
似たものを、また作ってしまった
過去に設計したAWSの構成や、ほかのプロジェクトで作った再利用可能な手順がある。そう思って探しても、どのプロジェクトに置いたのかをすぐ思い出せない。結局、似たSkillsや資料をもう一度作る。この経験は一度ではありませんでした。
もう一つの失敗は、AIとの長い作業セッションです。私の場合、前提をたくさん渡したまま進めるほど、途中で重要な条件が薄れ、計画や作業分解の精度が落ちると感じることがありました。対策として、作業の区切りごとに引継ぎ文書を作り、新しいセッションへ渡すようにしました。
これは一定の効果がありました。しかし引継ぎ文書そのものが、Notion、複数のプロジェクト、AIツールごとの作業場所に散らばりました。問題は「記録していないこと」ではなく、「必要なときに、必要な文脈として取り出せないこと」だったのです。
知識だけでなく、判断理由も残したい
手順書だけなら、コードやWikiにも残ります。けれど実務で次に効くのは、手順の周辺にある情報です。
- なぜこの案を選んだのか
- どの選択肢と比較したのか
- 何がうまくいかず、どこまで試したのか
- 次回は何を先に確認すべきか
こうした情報は、コミットログだけでは追い切れません。少なくとも私は、結論だけよりも判断の経路が少し残っている方が、次の作業で選択しやすいと感じています。
私は今、Knowledge（知識）だけでなく、Experience（経験）、Decisions（判断）、Principles（原則）、Ideas（アイデア）、Projects（プロジェクト）、AI Memory（AIへ渡したい文脈）を蓄積する場所としてVaultを捉え直しています。これは一般に確立された名称ではなく、私が便宜上「Personal Context Engine」と呼んでいる作業仮説です。
現在のVault構成
今のVaultは、次のように大きく分けています。完璧な分類ではありません。まず入口を決め、あとから見直せるようにすることを優先しています。
My-Private-Vault/
├── 00_Inbox/ # まず受け止める。未整理のメモ
├── 01_Daily/ # 日々の気づき、作業の断片
├── 10_AI/ # AI活用、プロンプト、エージェント運用の知見
├── 20_AWS/ # AWSの学習・設計・トラブルシュート
├── 30_Projects/ # プロジェクトごとの判断・経緯・引継ぎ
├── 40_Creative/ # 音楽など創作活動の記録
├── 50_Personal/ # 公開範囲を慎重に扱う個人文脈
├── 90_Archive/ # 現役ではないが捨てない記録
├── Attachments/ # 添付ファイル
└── Templates/ # ノートの雛形プロジェクトのコードやSkillsそのものを、すべてVaultへ移すつもりはありません。実体は各リポジトリに置き、Vaultには「何をしたか」よりも「なぜそうしたか」を残す。今のところ、この役割分担が一番しっくりきています。
まずはこのテンプレートから始める
同じことを試したい方は、最初から細かく分類しなくても大丈夫です。私なら、次の最小構成から始めます。
My-Vault/
├── 00_Inbox/
├── 01_Daily/
├── 10_Knowledge/
├── 20_Projects/
├── 90_Archive/
└── Templates/
└── project-context.mdTemplates/project-context.md は、次のような形です。
---
created: YYYY-MM-DD
project: <project-name>
status: active
---
# <プロジェクト名> の文脈
## 今回の目的
## 決めたこと
- 結論:
- 理由:
- 比較した案:
## うまくいかなかったこと
- 試したこと:
- 分かったこと:
## 次の作業で最初に読むこと
-
## 関連ノート
-重要なのは、きれいな分類を作ることではありません。「結論」と「理由」をセットで一枚残すことです。最初の数週間は、Inboxに放り込んでから週に一度整理するくらいで十分だと思います。
OneDriveとPrivate Gitを併用している理由
私のVaultはOneDriveで日常的に同期し、Private Gitは履歴・バックアップ用途として使う形にしています。前者には複数デバイスで同じノートを扱いやすいこと、後者には変更の履歴を追いやすいことを期待しています。同期の正本と競合時の復旧手順は、使い始める前に決めておく必要があります。
Obsidian公式ヘルプでも、OneDriveなどのサードパーティ同期やGitを使った同期が選択肢として案内されています。同期に関する公式ヘルプも、実際に選ぶ前に確認するとよいと思います。
ただし、これは私の用途に合わせた選択です。私はVaultを端末でオフライン利用できる状態か確認し、同じノートを複数端末で同時に編集しないことを最低限のルールにしています。同期の競合、端末の紛失、Gitの履歴に残る内容には注意が必要です。Privateリポジトリであっても、顧客情報、認証情報、契約上の機密を入れてよい理由にはなりません。所属組織の情報分類・契約・利用規程を優先し、認証情報はVaultにもGitにも置かない。私は「AIに読ませたいから残す」と「残してよい」は、別の判断として扱うことにしています。
RAGはまだ始まっていない
ここは誤解のないように書いておきます。今の私は、Vault全体を埋め込み検索し、AIエージェントが自動で最適なノートを取り出す仕組みを運用しているわけではありません。
現時点で行っているのは、私のローカル環境で、作業対象として明示したMarkdownをClaude CodeやCodexに読ませ、プロジェクトの節目で文脈を記録することです。Vault全体を自動で渡すのではなく、必要最小限のノートだけを選びます。これはRAGの前段階、あるいは「RAGに渡せる素材を整える段階」だと考えています。
たとえば、次の作業を始めるときは、project-context.md を一枚指定して、私は次のように依頼します。利用するAIや実行環境によってファイルへのアクセス範囲は異なるため、パスを指定して読ませる、作業ディレクトリに必要なノートだけを置くなど、その環境の手順に従って渡せる範囲を毎回確認します。
この作業では project-context.md を前提情報として読んでください。
記載された「決めたこと」「理由」「うまくいかなかったこと」を踏まえ、
次の作業計画を提案してください。
ノートにない事実は推測せず、判断が必要な点は質問として分けてください。将来は、意味検索や埋め込みを使って関連ノートを候補として出すことも検討しています。ただ、Vaultが大きくなれば、今度はVaultの中で探せなくなるかもしれません。検索精度、タグ、リンク、更新ルール、アクセス権をどう設計するかは、これから検証する課題です。
AIに渡す前に、人間が読める状態にする
AIエージェントに過去の文脈を渡せるようにしたい、という考えは、AIにすべて任せたいという意味ではありません。むしろ反対です。
自分が過去に何を考え、何を失敗し、なぜ判断したのかを人間の自分自身が読み返せる状態にする。その副産物として、必要な部分をAIにも渡せるようにする。私はその順序の方が健全だと思っています。
長く積み重ねてきた経験を、そのままAIへ移せるとは考えていません。経験は、暗黙知のままでは検索も引用もできないからです。それでも、判断理由を短いMarkdownとして残す習慣なら、今日から始められます。
まずは一つのプロジェクトで、「決めたこと」「理由」「うまくいかなかったこと」を書くところから始めます。次は、ノートの粒度と検索性、そしてClaude CodeやCodexへ必要な文脈だけを渡す方法を検証する予定です。
Obsidianを第二の脳にできるかは、まだ分かりません。ただ少なくとも私は、次のセッションで判断理由を一から説明し直す負担を減らすために、AIへ渡す材料を少しずつ育てていこうと思います。