はじめに：AIはセッションを跨いで記憶を失う
Claude Code、Cursor、Codex——これらのAI支援ツールは、それぞれ優れた能力を持っていますが、共通の課題を抱えています。それはセッションを跨いで記憶を維持できないということです。
あなたがClaude Codeで「このAPIの設計はこう決めよう」と議論し、アーキテクチャの決定を固めたとしましょう。次の日、「あの決定、なんだったっけ」と呼び出そうとしても、セッションはすでにリセットされています。MEMORY.mdやCLAUDE.mdといったプロジェクト内の設定ファイルがあっても、それはそのプロジェクト固有の「浅い記憶」に留まり、プロジェクト横断の「深い記憶」——昨日なぜその技術を選んだか、という文脈——を持つことは難しいのです。
複数AIツールを使っている開発者なら、この問題はさらに深刻になります。Claude Codeで決めた方針をCursorでは把握できない。Codexで調査した情報をClaude Codeでは参照できない。各AIがそれぞれ独立したセッションを持ち、コンテキストが断片化していきます。
本記事では、この問題を**Obsidianを使ったSSOT（Single Source of Truth）**によって解決する設計手法を提案します。
🔄 前提知識として：本記事の前提となる「複数LLMの使い分け」と「コスト最適化」について、Claude Code CLIをGLM/MiniMaxで代替した話で詳しく解説しています。先に読むと本記事の理解が深まります。
SSOT（Single Source of Truth）とは
SSOTという概念は、もともとデータ工学の分野で「データの整合性を保つため、1つの信頼できる情報源だけを正とする」という原則として知られています。
本記事では、この概念をAI支援ツールの文脈に適用し、**「全AIが参照する1つの知識ベース」**として定義します。
重要なのは、コードと知識を分離する考え方です。コードは各リポジトリにありますが、「なぜこの技術を選んだのか」「どのAPIを優先して使っているのか」という知識はリポジトリに属しません。
コードはリポジトリに、知識はObsidianに。
この二つを分離する。
コードと同じ場所に知識を書くと、バージョン管理が煩雑になり、pull requestの文脈と混在してしまいます。Obsidianのようなナレッジベースに分離することで、AIツールから簡単に参照でき、人間にとっても自然に閲覧・更新できるようになります。
3層構造の設計思想
SSOTのvaultは、3つの層で構成されます。この構造は偶然ではなく、実際の運用を通じて確立されたものです。
レイヤー1：00_SYSTEM —— 全AI共通ルール
SSOT/
├── 00_SYSTEM/ # システムルール（全AI共通）
│ ├── CHARTER.md # 基本ルール・禁止操作
│ └── shared-rules/
│ ├── rules.md # Tier1判定キーワード等
│ ├── llm-routing.md # LLM振り分けルール
│ └── ai-setup/ # Claude Code, Cursor, Codex別設定
この層は**「どう振る舞うべきか」を定義**します。各AIツールの共通ルール、業務上の禁止事項、LLMの振り分け方針などを配置します。
重要なのは、「このプロジェクトでは危険な操作は何か」「このAPIは非推奨なので避けるべき」というルールが一元化されている点です。Claude Codeが参照したルールは、CursorでもCodexでも同じものを参照します。
レイヤー2：01_DECISIONS —— 技術決定の記録
SSOT/
├── 01_DECISIONS/ # プロジェクト別の技術決定
│ └── <project>/YYYY-MM-DD_<topic>.md
この層は**「何を決めて、なぜ」を記録**します。アーキテクチャの決定、API選定、性能問題への対応——これらを時系列で記録し、後から参照できるようにします。
各決定ファイルには、問題の根本原因、選択した解決策、代替案を捨てた理由、CLIコマンド履歴などを記録します。これにより、「なぜこの技術を選んだんだっけ」をAIに尋ねられるようになります。
レイヤー3：10_DAILY —— 日次ハブ
SSOT/
├── 10_DAILY/ # 日次セッションログ（ハブ）
│ └── YYYY-MM-DD.md # サマリー + 01_DECISIONSへのリンク
この層は**「今日何をやったかのサマリー」**を配置します。詳細な議論は01_DECISIONSにありますが、10_DAILYでは「今日はどこを修正したか」「新しい決定事項は何か」「未解決の課題は何か」を簡潔にまとめます。
なぜこの分離が必要なのか。日記ファイルは毎日追記されるため肥大化します。しかし詳細な議論や決定事項は別のファイルに分離されているため、日記は常に軽量に保たれつつ、必要な時に掘り下げて参照できます。
日記 = サマリー + リンク集
詳細 = 01_DECISIONSの個別ファイル
この3層構造により、AIは最新の日記から直近の作業を把握し、必要に応じて具体的な決定事項に掘り下げて参照できます。
CLAUDE.mdとの連携
vaultを構築しても、AIが自動的に参照してくれなければ意味がありません。Claude CodeのCLAUDE.mdから、SSOTのルールを読み込む設定方法を説明します。
CLAUDE.mdへの参照設定
プロジェクトのCLAUDE.mdに、以下のようにshared-rulesへの参照を設定します。
# プロジェクトルール
## 共通ルールの読み込み
- 詳細はSSOT共通ルールを参照: /path/to/SSOT/00_SYSTEM/shared-rules/rules.md
## セッション開始時に参照するファイル
- SSOT Charter: /path/to/SSOT/00_SYSTEM/CHARTER.md
## タスク完了時の自動記録
完了時は必ず /path/to/SSOT/10_DAILY/YYYY-MM-DD.md を更新し、
関連する決定事項があれば /path/to/SSOT/01_DECISIONS/<project>/ に記録すること。
こうすることで、Claude Codeがセッションを開始するたびに、CHARTER.mdとrules.mdが自動的に読み込まれます。
タスク完了時の自動記録ルール
CLAUDE.mdには、タスク完了時の自動記録ルールも記載しておきます。
## 自動記録ルール
重要な技術的決定や問題の解決をした場合は、以下の形式で記録すること：
1. 01_DECISIONS/<project>/YYYY-MM-DD_<topic>.md を作成
2. 10_DAILY/YYYY-MM-DD.md の「## セッションログ」セクションに記録を追加
3. 記録内容包括:
- 何をしたか（簡潔な説明）
- なぜその方法を選んだか
- 使用したコマンド（あれば）
- 未解決の課題（あれば）
これにより、タスク完了時にAIが自動的に記録してくれるようになります。
実際の記録フォーマット
01_DECISIONSのフォーマット
技術決定を記録する際のフォーマット例です。
# <プロジェクト名> <内容>
## 日時
YYYY-MM-DD HH:MM
## 根本原因
なぜこの決定が必要だったのか。
## 修正内容
どのような選択をしたのか。
代替案があれば、なぜそちらを選択しなかったのか。
## コマンド履歴
\`\`\`bash
# 実行したコマンド
some --command --args
\`\`\`
## 関連ファイル
- /path/to/file1.md
- /path/to/file2.ts
## 備考
追加のコンテキストや参考資料。
10_DAILYのフォーマット
日次日記のフォーマット例です。
# YYYY-MM-DD
## セッションログ (HH:MM)
### <作業内容のサマリー>
- 作業内容（3〜5行の簡潔な説明）
- 詳細: 01_DECISIONS/<project>/YYYY-MM-DD_<topic>.md
- 未解決: ○○（原因: △△、次にやる: □□）
日記ファイルは簡潔に保ち、詳細な議論は01_DECISIONSに委ねる原則を徹底します。
複数AIツールでの運用
このSSOT vaultの真価が発揮されるのは、複数AIツールを同時に使用している場合です。
⚙️ 実践例：このSSOTの設計思想は、実際のプロジェクトでも活きています。例えばplaywright-stealthが開発停止なのでPython版を自作してPyPIに公開した話では、AI駆動開発で「欲しいツールを自作→PyPI公開」まで実施。その過程の意思決定記録にSSOTを使っています。
運用例
| AIツール | 用途 | SSOT参照 |
|---|---|---|
| Claude Code (WSL2) | サーバーサイド、CI/CD | あり |
| Cursor (Desktop) | フロントエンド、UI修正 | あり |
| Codex | バッチ処理、調査 | あり |
すべてのAIツールが同じSSOT vaultを参照しています。Claude Codeで決めたAPI設計方針を、Cursorでコードを書く際に参照できます。
設定の共有化
各AIツールのプロジェクト別設定ファイル（CLAUDE.md、.cursorrulesなど）から、相対パスでSSOT vaultを参照します。
# Cursorプロジェクトの .cursor/rules/memory.md
- 詳細はSSOT共通ルールを参照: ../../shared/SSOT/00_SYSTEM/shared-rules/rules.md
パスは環境によって調整しますが、基本的な考え方は同じです。共通ルールは1箇所で管理し、各プロジェクトからはそれを参照するだけです。
運用1.5ヶ月で分かったこと
実際に1.5ヶ月間、このSSOT運用をして分かったことをまとめます。
メリット
「昨日の自分がなぜその判断をしたか」が即座に参照できる
一番大きかったのはこれです。以前は「あの決定どうだったっけ」と遡るのに苦労しましたが、今はAIに「昨日のAPI設計決定を振り返って」と尋ねるだけで参照できます。
AIが過去の決定を参照して矛盾する提案をしなくなる
これが実際のコーディング中で最もうれしい変化でした。Claude Codeが「ここはReactよりVueの方が良い」と提案しても、SSOTを参照すれば「01_DECISIONSによるとReactに決定済みだ」と確認できます。
課題
記録の負荷
AIに自動記録させていますが、完璧ではありません。コマンドの出力結果など、AIが会話中に把握していない情報は手動で記録する必要があります。
vaultの肥大化
1.5ヶ月間で日記ファイルが70ファイル、DECISIONSフォルダに30ファイル以上がたまりました。アーカイブ運用が必要です。現在は四半期ごとに古いファイルをアーカイブフォルダに移動するルールで運用しています。
SSOT/
├── 10_DAILY/
│ ├── 2026-01.md
│ ├── 2026-02.md
│ └── ...
├── 99_ARCHIVE/
│ └── 10_DAILY_ARCHIVE/
│ ├── 2026-03-05.md
│ └── ...
この記事を読んで興味を持った方へ
- 📖 Claude Code CLIをGLM/MiniMaxで代替した話 — 複数LLMの使い分けをコスト観点で比較検討した記録。本記事の前提となる環境構成の話
- 📖 playwright-stealthが開発停止なのでPython版を自作してPyPIに公開した話 — AI駆動開発の実践例。SSOTで意思決定を記録しながらライブラリを自作・公開した流れ
おわりに
本記事では、Obsidianを使ったAI記憶のSSOT化設計について述べました。
AIのセッション跨ぎ記憶喪失という課題は、今後のAI活用においてますます重要になります。MEMORY.mdのようなプロジェクト内設定ファイルは有用ですが、プロジェクト横断の知識管理には限界があります。
3層構造（00_SYSTEM / 01_DECISIONS / 10_DAILY）を基本とし、各AIツールから共通して参照できる知識ベースを構築することで、複数AI間での記憶共有が可能になります。
AIの記憶をどう設計するか。これは、これからのソフトウェア開発における重要なテーマになっていくでしょう。本記事がそのヒントになれば幸いです。
本記事は個人Zennでも公開しています。