重要なポイント
Claude Codeのセカンドブレインは1つのファイルではなく、5つのフォルダーとgitで構成されます。CLAUDE.mdがルールと案内先を定め、`business/`にはプロジェクトの知識を、`ai-clone/`には意思決定者であるあなたについての情報を、`plans/`には技術計画を、`retrospectives/`には過去のセッションから得た教訓を保存します。エージェントはCLAUDE.mdから始め、依頼内容に応じて適切なフォルダーへのリンクをたどります。この記事では、Claude Code公式ドキュメントに記載された記憶の階層、5つの部分からなる構成、そして1時間で段階的に構築する方法を解説します。
Ailootの参考ドキュメント：[ailoot.ai/docs/](https://ailoot.ai/docs/)。
## Claude Codeにセカンドブレインが必要なのはなぜ？何が欠かせない？
重要なポイント
CLAUDE.mdファイル1つで基本ルールはカバーできますが、ビジネスの記憶までは扱えません。1か月後には、なぜ価格を上げたのか忘れてしまいます。3か月後には、なぜ分割払いを断ったのかも忘れてしまいます。知識は、あなたの頭、Telegramのチャット、Googleドキュメント、従業員の頭という4か所に分散しています。セカンドブレインは、それらをプロジェクトと同じ場所にある1つのMarkdownファイル群に集め、Claudeが自分で参照できるようにします。
火曜日にClaude Codeを開きます。これがプロジェクトで、これが対象者で、これはしないで、と説明します。一緒に作業します。木曜日には新しいチャットになり、またすべて説明し直さなければなりません。
CLAUDE.mdがあれば、最初の苛立ちは解消されています。基本ルールとプロジェクトの説明が1つのファイルにあり、毎回のセッションで読み込まれます。このファイルの仕組みは[CLAUDE.mdのガイド](https://ailoot.ai/blog/ja/claude-md-template/)で説明しました。まずそれを読めば、基礎を整えられます。
しかし、CLAUDE.mdは新入社員向けの取扱説明書です。服装、顧客との話し方、公開に使うコマンドなどを定めます。プロジェクトについて良い判断を下すには、それだけでは足りません。判断には知識が必要です。製品とは何か、対象者は誰か、収支はどうなっているか、何を試し、何がうまくいかなかったか、といった知識です。
ここで述べる筆者の経験では、そうした知識は以前、4か所に分散していました。自分の頭、Telegramのチャット、Googleドキュメント、従業員の頭です。決定から1か月もすれば、なぜそう決めたのか誰も覚えていません。新しい人が加わると、状況を把握するためにチームへ1時間質問することになります。Claudeはその背景をまったく共有していませんでした。
筆者が説明する経験では、セカンドブレインを作る前は、セッションのたびに顧客は誰か、オファーはどういう構成か、支払いをどのプロバイダーが処理するかを説明していました。`business/`を作ってからは、チャットを開いて「新しい料金プランに合わせてオファーを更新して」と伝えるだけです。Claudeは自分で`business/company/legal.md`を開いて要件を読み、次に`business/products/pricing.md`を開いて新しい料金プランを確認し、一度の作業で編集案を出します。準備にかける時間がなくなり、背景情報が自動で読み込まれます。
注記
これはClaudeの記憶の問題ではありません。アーキテクチャの問題です。エージェントにとって、コンテキストウィンドウは作業記憶です。明示的に指し示したものだけが読み込まれます。それ以外はウィンドウの外にあり、必要に応じて読み込まれます。セカンドブレインは、その「それ以外」をClaudeが見つけられるように整理して保存します。
Anthropicはエンジニアリングブログで、この問題を「コンテキストの劣化」と呼んでいます。
重要なポイント
考えることに頭を使い、考えを保存することには使わない、というシンプルな発想です。Claude Codeでは、セカンドブレインは生産性向上の手法からエージェントのアーキテクチャへと変わります。つまり、エージェントがファイルシステムから直接アクセスできる外部ノートフォルダーです。
典型的なセカンドブレインの利用者はObsidianの保管庫を作り、本からの抜粋、通話のメモ、プロジェクトのアイデアを追加します。
筆者がこの考え方をClaude Codeとの作業に応用すると、生産性の話ではなくエージェントのアーキテクチャの話になりました。
従来のアプローチでは、セカンドブレインは自分のもので、自分で手動でアクセスします。Claude Codeと作業する場合、セカンドブレインは**双方向**になります。あなたとエージェントの両方がアクセスします。そのため、形式に求められる条件が変わります。
エージェントが自分でアクセスするため、別の連携機能がなくても理解できる形式でファイルを保存する必要があります。Markdownが理想的です。テキスト、見出しの階層、ファイル間のリンクを使えます。NotionやGoogle Docsは適していません。MCP経由で接続できますが、別の層が増え、リクエストごとにトークンが追加され、障害点も増えます。
ファイルはプロジェクトと同じファイルシステムにあるので、Claude Codeが自動的にアクセスできます。設定は不要です。プロジェクトフォルダーでエージェントを起動すれば、その中のファイルをすべて見ることができます。無料で、そのまま動作します。
ヒント
セカンドブレインはObsidianに置いてもかまいません。筆者も、つながりのグラフを見やすくするためにObsidianで開いています。ただし、ファイル自体はコードと同じ場所にある普通のフォルダーに保存されています。ObsidianはMarkdownファイルを扱いやすくするためのラッパーにすぎません。ObsidianがなくてもClaudeはファイルを見られます。どのエディターを使ってもかまいません。重要なのは、独自形式のクラウドサービスではなく、ディスク上にファイルがあることです。
## Claude Codeに標準搭載されている記憶の階層とは？
/memory/
├── MEMORY.md # インデックス。各セッションで読み込まれる（200行または25KB）
├── debugging.md # 詳細メモ（必要に応じて読み込まれる）
├── api-conventions.md
└── ...
```
Anthropicは公式ドキュメントで次のように説明しています。
Claudeはすべてのセッションで何かを保存するわけではありません。その情報が今後の会話で役立つかどうかに基づいて、記憶する価値があるものを判断します。
— Anthropic、code.claude.com/docs/en/memory
自動メモリは`~/.claude/settings.json`の`autoMemoryEnabled`フラグで有効にします。何を書くかはClaudeが判断します。MEMORY.mdを読んだり手動で編集したりできます。普通のMarkdownファイルです。
警告
自動メモリは便利ですが、セカンドブレインの代わりにはなりません。Claudeは、ツールやコードのパターンについての実務的な要点を書き込みます。「フラグXがないとこのスクリプトは動かない」「このデータベーステーブルの名前はこれ」などです。ビジネス戦略は書きません。対象者が誰か、特定の価格を選んだ理由をエージェントに覚えてほしければ、自分で別のコンテキストフォルダーに保存する必要があります。
## CLAUDE.mdとセカンドブレイン、どこで使い分ける？
重要なポイント
CLAUDE.mdは新入社員向けの取扱説明書です。どう振る舞うか、どのコマンドを使うか、何をしてはいけないかを説明します。セカンドブレインは社内Wikiです。何をしているのか、誰のためなのか、収支はどうなっているのか、何を試してきたのかを説明します。行動ルールを記したファイル1つと、外部知識の構造を組み合わせます。CLAUDE.mdはインデックス、セカンドブレインはアーカイブです。インデックスがなければ、エージェントはアーカイブの存在を知りません。アーカイブがなければ、ルールは知っていてもビジネスの背景は知りません。
講演でよく使うたとえを紹介します。新しい従業員を雇ったと想像してください。初日に何を渡しますか？
取扱説明書です。服装、出勤時間、顧客との話し方、公開に使うシステムを伝えます。短い文書で、何をしているのか、なぜそうしているのかまでは説明しません。単に、どう振る舞うかを示します。
そして別に、社内Wikiへのアクセス権を渡します。製品とは何か、誰のためのものか、対象者は誰か、価格はいくらでその理由は何か、競合は誰か、どんな失敗をしたかを説明します。これは大規模なアーカイブです。誰も最初から全部は読みません。特定の質問があるときに参照します。
CLAUDE.mdは取扱説明書。セカンドブレインはWiki。両方が必要です。
区別は簡単です。**すべてのタスクに関係する**ものは、すべてCLAUDE.mdに入れます。
- このプロジェクトでのエージェントの役割（ヘルパー、リード、アシスタント）
- 回答する言語
- ツールのスタック
- 公開コマンド
- 禁止事項（emダッシュを使わない、`git push --force`を実行しない）
- 案内先：ビジネスの背景情報や原則をどこで確認するか
**必要に応じて使う**ものは、セカンドブレインに入れます。
- 製品、対象者、収支、目標
- 競合と市場
- 過去の決定とその理由
- 顧客事例とレビュー
- 原則と方法論
Anthropicもドキュメントで同じ区別を示しています。
CLAUDE.mdはすべてのセッションで読み込まれるため、広く当てはまる内容だけを含めてください。特定の場面でのみ必要なドメイン知識やワークフローにはスキルを使います。Claudeはすべての会話を肥大化させずに、必要に応じて読み込みます。
— Anthropic、code.claude.com/docs/en/best-practices
スキルは、エピソード的な知識を保存する方法の1つです。プロジェクトと同じ場所に`business/`フォルダーを置く方法もあります。筆者は両方を使っており、以下で詳しく説明します。
## プロジェクトのブレインを構成するもの：5つの要素とタイムマシン
重要なポイント
プロジェクトのブレインは、5つのフォルダーにgitを加えたものです。CLAUDE.mdがルールと案内先を定めます。`ai-clone/`にはあなたのデジタルな投影、つまり原則、口調、失敗後のフィードバックを保存します。`business/`にはプロジェクトの知識を保存します。`plans/`には段階ごとの技術計画を置きます。`retrospectives/`にはセッション後の振り返りを置きます。gitはすべてをタイムマシンに変えます。1年後でも、任意のファイルを開けば、決定時に何が書かれていたか確認できます。
筆者が説明する経験に基づく構成例です。
| フォルダー | 中身 | 目的 |
|----|----|----|
| **`CLAUDE.md`** | プロジェクトのルール、スタック、ファイル構成、フォルダーの案内先、コミュニケーション言語 | エージェント向けの取扱説明書です。すべてのセッションで読み込まれます。200行未満、できれば80-120行にします。 |
| **`ai-clone/`** | 自分は何者か、原則、口調、意思決定のスタイル、失敗後のフィードバック | 意思決定者である自分のデジタルな投影です。何をすぐに却下するか、どんなスタイルで提案するか、失敗から学んだルールを把握します。 |
| **`business/`** | 製品、対象者、目標、収支、マーケティング、過去の決定、事例 | WikiリンクでつながるMarkdownファイル群です。各ファイルは`[[...]]`リンクでほかのファイルとつながります。エージェントは特定の質問に答えるために参照します。 |
| **`plans/`** | 機能ごとの計画。フェーズとチェックボックスを含む`YYYY-MM-DD-feature.md`ファイル | Plan Modeの内容は1つの会話内にあり、`/clear`で消えます。`plans/`フォルダーはリポジトリ内にあるため、どのエージェントでもいつでも計画を引き継げます。 |
| **`retrospectives/`** | 各セッション後の振り返り：実施内容、覚えておくこと、改善点 | システムの自己学習です。失敗は`ai-clone/feedback/`のルールになります。 |
| **`+ git`** | すべてのファイルのバージョン履歴 | タイムマシンです。任意のファイルを開いて`git log`を実行すれば、いつ、なぜ変更されたか確認できます。 |
方法論上の重要な点は、**`ai-clone/`と`business/`を分けること**です。
`business/`は「何をしているのか」に答えます。製品、対象者、価格、競合など、プロジェクトに関する情報です。明日プロジェクトをパートナーに引き継ぐなら、このフォルダーも一緒に渡します。
`ai-clone/`は「どう意思決定するのか」に答えます。自分の原則、口調、仕事の技術、避けるべき言葉など、自分に関する情報です。明日新しいプロジェクトを始めるなら、このフォルダーを持っていきます。
これらを組み合わせると、筆者が「一人会社」と呼ぶものになります。1人の人間、構造化された背景情報、そしてその情報を読むAIです。
2つ目のフォルダーを設定するだけでなく、Claudeの一貫性を保つ仕組みも作りたいですか？それだけでは不十分です。`ai-clone/`がなければ、エージェントはあなたではなく誰にでも当てはまる回答をします。コンテキストエンジニアリングがなければ、フォルダー全体を歩き回ってトークンを浪費します。3つすべてをつなげると役立ちます。**セカンドブレイン＋AIクローン＋コンテキストエンジニアリング**です。これらは、AIが幻覚を起こさないための**3本柱**です。
## business/には何を入れ、何を入れない？
重要なポイント
週に1回以下しか変わらないプロジェクトの事実を`business/`に入れます。ポジショニング、対象者、製品と価格、四半期目標、重要な決定などです。チャットのやりとり、未処理の生資料、コード内に重複している情報、スクリーンショット、動的な数値は入れません。数値はLIVEマーカーとSQLクエリへのリンクに置き換えます。詳しくは後述の専用セクションで説明します。
筆者が説明するプロジェクトにおける`business/`の最上位構成です。
```
business/
├── INDEX.md ← フォルダーの案内図。最初に読む
├── company/ ← ミッション、法人、価値観、法的ポリシー
├── products/ ← 製品、プログラム、価格
├── audience/ ← 顧客像、セグメント、異議
├── goals/ ← 年次、四半期、月次の目標と指標
├── economics/ ← ユニットエコノミクス、収入、費用、予測
├── marketing/ ← チャネル、ファネル、資料、競合
├── execution/ ← 週次計画、バックログ
└── assets/ ← デザインシステム、レビュー、コピー集
```
これは筆者が説明するプロジェクトの例であり、絶対的な規則ではありません。必要に応じてフォルダーを作ります。最初は3つ（`products/`、`audience/`、`goals/`）から始め、2-3か月後に新しいものの保存先が分からなくなったため、ほかを追加しました。
フォルダーの中心となるファイルは`INDEX.md`です。これは案内図です。「質問 → ファイル」の表を置き、Claudeがどこに進めばよいか判断できるようにします。これがないと、エージェントはファイルを順番にすべて読むためにトークンを使います。
`INDEX.md`の抜粋例です。
```markdown
### Where to find things
| What you need | Where to look |
|---|---|
| Who our client is and their pain points | `business/audience/avatar.md` |
| Products, plans, and prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics (income, expenses, unit economics) | `business/economics/` |
| Promotion channels and materials | `business/marketing/` |
```
CLAUDE.mdには「ビジネスについての質問では、`business/INDEX.md`を読んで案内図に従う」と1行書くだけで十分です。エージェントはフォルダー全体をコンテキストに読み込みません。案内図を読み、適切なファイルを選び、その1つだけを読みます。
**`business/`に入れないもののチェックリスト：**
- 処理していないチャットのやりとり。洞察があれば要点を整理して書き留めます。なければ入れません。
- コードと重複する情報。「支払いはCloudPaymentsを通す」は不要です。エージェントはコードを見られます。
- スクリーンショットや画像。フォルダーのサイズが増え、追加の手順なしではテキストモデルが解析できません。
- 動的な数値。「今日は製品への支払いが423件ある」は1週間後には古くなります。LIVEマーカーとデータベースクエリへのリンクを使います。
- 機密情報や問題になりそうな情報。明日リポジトリがYouTubeで10万人の前に公開されたとして、見せてもよいものだけを残します。従業員、エージェント、ときには外部の契約業者もこのフォルダーを読みます。
警告
リポジトリが公開されていれば、`business/`フォルダーも公開されています。今は非公開でも、明日公開される可能性があるものとしてセカンドブレインを扱います。同意のない顧客名、月間売上の数字、パスワードは入れません。この習慣で多くのストレスを避けられます。
## ai-cloneフォルダーを分けて作る理由は？businessと混ぜてはいけない理由は？
重要なポイント
`ai-clone/`には、原則、口調、避けるべき言葉、失敗後のフィードバックといった、あなたのデジタルな投影を保存します。エージェントの失敗はすべて「ルール → 理由 → 適用方法」という形式で`ai-clone/feedback/`のルールになります。このフォルダーはプロジェクトからプロジェクトへ持ち運べます。`business/`はプロジェクトと一緒に残ります。両者を分けておけば、新しいプロジェクトで`business/`が変わっても、あなたの原則やスタイルはそのまま保たれます。
考え方はシンプルです。ビジネスは私たちが何をしているかを把握します。クローンは私がどう意思決定するかを把握します。
筆者が説明するプロジェクトでの`ai-clone/`構成です。
```
ai-clone/
├── INDEX.md ← フォルダーの案内図
├── role.md ← 自分は何者か、経歴、何を大切にするか
├── identity/ ← 価値観、ビジョン、ミッション
├── thinking/ ← 講演から得たメンタルモデル
├── voice/ ← 口調、語彙、スタイル
├── principles/ ← 製品、コード、ビジネスに関する信念
├── feedback/ ← 失敗から学んだルール ← 主要フォルダー
├── style/ ← 避けるべき言葉、Telegram形式
└── reference/ ← ツール、環境
```
最も役立つのは`feedback/`フォルダーです。エージェントの失敗を通して学んだ具体的なルールを保存します。各ルールは別ファイルに、次の形式で記述します。
```markdown
---
name: short-name
description: one line - what’s in the file and when to apply it
type: feedback
---
短いルールを1文で記します。
**理由:** このルールが存在する理由。背景、出来事、観察内容。
**適用方法:** どのようなときにルールを適用するか、具体的なきっかけ。
```
「理由」がなければ、そのルールは役に立ちません。エージェントは似た状況に応用できません。「適用方法」がなければ、いつルールを使うのか明確ではありません。
筆者のフォルダーにある例は「emダッシュではなくハイフン」です。emダッシュ`—`は生成テキストを強く連想させる視覚的な記号であることから生まれたルールです。公開向けのテキストすべてに適用されます。ファイルの場所は`ai-clone/feedback/no-em-dashes.md`です。
筆者は少し違う方法をとります。ルールはCLAUDE.mdではなく`ai-clone/feedback/`に書きます。CLAUDE.mdはプロジェクト用ファイルですが、口調やスタイルに関するルールは個人のものです。次のプロジェクトにも持っていきます。`CLAUDE.md`はプロジェクトに残ります。
注記
この方法がどれだけ成熟しているかを測る目安は、同じことについてエージェントに「違う、そうじゃない」と週に何回伝えるかです。成熟したシステムでは、その答えはゼロです。各失敗が`feedback/`のルールになり、エージェントは次に同じ失敗をしません。
## Live Metricsとは？ファイルに数値を直接書くべきでない理由は？
重要なポイント
セカンドブレインのファイルに書いた数値は、数日で古くなります。今日の「顧客1,000人」は明日には1,050人になり、1か月後には2,000人になります。数値を直接書いてしまうと、1か月後には、エージェントが前日のデータに基づいて提案します。解決策は、ファイル内にLIVEマーカーを置き、すぐに実行できるSQLクエリを記載した別の`live-metrics.md`文書を用意することです。エージェントはLIVEを見つけたら、データベースから最新の数字を取得し、最新データをもとに判断します。
セカンドブレインを作り始めるときによくある落とし穴の1つは、古い数値でいっぱいにしてしまうことです。「顧客が320人いる」と書いても、2週間後には410人になっています。「月間売上は470万」と書いても、1か月後には、その数値が目標、実績、予測のどれなのか分からなくなります。
筆者の例では、次のように機能します。`business/products/practicum.md`ファイルでは、数字の代わりにマーカーを置きます。
```markdown
## Cohorts
> **LIVE** - run the queries in `live-metrics.md`, section “Sales”
> to see current payments by cohort.
| Cohort | Dates | Paying |
|-------|------|------------|
| 1 | March 10-12, 2026 | LIVE |
| 2 | March 24-26, 2026 | LIVE |
```
別の`live-metrics.md`ファイルには、すぐに実行できるSQLクエリと、結果の説明を記載します。
````markdown
## Sales (payments by cohort)
```sql
SELECT c.name, COUNT(p.id) AS paid, SUM(p.amount) AS revenue
FROM purchases p
JOIN cohorts c ON c.id = p.cohort_id
WHERE p.status = 'paid'
GROUP BY c.name
ORDER BY c.starts_at DESC;
```
````
エージェントに「第2期には支払いが何件ある？」と尋ねると、次のように動きます。
1. `business/products/practicum.md`を読む
2. 数字の横にあるLIVEマーカーを見る
3. `live-metrics.md`を開く
4. 「Sales」セクションを見つける
5. 本番データベースにクエリを実行する
6. 最新データに基づいて回答する
これで2つの問題を同時に解決できます。数値が古くなりません。そして、意思決定は昨年のものではなく、現状を反映した情報に基づいて行われます。
警告
筆者が説明する方法では、本番データベースにアクセスできるのは信頼されたエージェントだけです。そのアクセスはクエリを記録し、パスワードを露出しないラッパー経由でのみ許可します。`live-metrics.md`にパスワードを平文で含む直接の`psql`コマンドを書くのはよくありません。環境変数からパスワードを取得し、出力に表示しないラッパーを作ります。これは別の技術レイヤーですが、用意しなければLIVEがセキュリティ上の穴になります。
## 1つの依頼に対して、AIはセカンドブレインをどう参照する？
重要なポイント
依頼を処理する流れはいつも同じです。ClaudeがCLAUDE.mdを読み、案内図（`business/INDEX.md`、`ai-clone/INDEX.md`）を確認し、関連するINDEXに進み、そこから特定のファイルを開きます。必要なら、LIVEを通じて数値を取得します。フォルダー全体をコンテキストに詰め込むのではなく、読み込み操作は5-6回で済みます。ウィンドウは推論のために使え、関係のないファイルにトークンを浪費しません。
具体的な依頼の例：「新しい期の参加者に送るメールを作成してください。」
1. Claudeは空のウィンドウから開始します。CLAUDE.md（ルール、スタック、案内先）を読み込みます。
2. CLAUDE.mdの案内で「`ai-clone/INDEX.md` - セッション開始時に必ず読む」と確認します。ファイルを開き、自分が何者か、どんな口調か、どんな言葉を避けるかを把握します。
3. 案内に「メールテンプレート - `src/lib/email/layout.ts`」とあるのを確認します。ファイルを開き、形式を把握します。
4. 「製品の背景情報 - `business/products/practicum.md`」とあるのを確認します。ファイルを開き、製品について読みます。
5. ファイル内にLIVEマーカーと`live-metrics.md`への参照があるのを確認します。ファイルを開き、すぐに実行できるSQLを探します。最新の数値が必要ならクエリを実行します。不要なら「送信時にこの数値を取得する」と記録します。
6. `ai-clone/style/telegram-format.md`の口調ルール、`ai-clone/feedback/no-em-dashes.md`のemダッシュ禁止、`business/marketing/funnel.md`のファネル転換率を確認します。
自分の口調で、最新の数字を使い、emダッシュやAIらしい印を使わずにメールを書きます。
Anthropicはエンジニアリングブログで、このアプローチをジャストインタイムのコンテキストと呼んでいます。
「ジャストインタイム」方式で構築されたエージェントは、軽量な識別子（ファイルパス、保存済みクエリ、リンクなど）を保持し、それらのリンクを使って実行時にデータを動的にコンテキストへ取り込みます。
— Anthropic、anthropic.com/engineering/effective-context-engineering-for-ai-agents
つまりClaudeはデータそのものではなく、データへの参照を保持します。関連する情報だけがコンテキストに入るので、トークン効率が高く、精度も上がります。ウィンドウを推論のために使えます。
## セカンドブレインで避けるべき5つのアンチパターン
重要なポイント
セカンドブレインの初心者がよく犯す主な間違いは次の5つです。1）短い案内役にする代わりに、500行以上の巨大なCLAUDE.mdを作る。2）何でも入れる保存用フォルダーを作り、ゴミ捨て場にしてしまう。3）Claudeが言語やコードからすでに把握できることを重複して記載する。4）LIVEを使わずに、古くなる数値を固定して書く。5）同じリポジトリか別の非公開保管先かにかかわらず、必要な文脈への権限や案内をエージェントに与えない。
アンチパターン1。**肥大化したCLAUDE.md。**「すべてを1か所に入れる」ための500行の指示です。Anthropicは明確に述べています。
短く保ちましょう。各行について、「これを削除するとClaudeは間違いを始めるか？」と考えてください。そうでなければ削除します。肥大化したCLAUDE.mdファイルは、Claudeが実際の指示を無視する原因になります。
— Anthropic、code.claude.com/docs/en/best-practices
目安は80-120行です。それ以外は別ファイルに置き、そこへ案内します。
アンチパターン2。何でも入れるフォルダー。 生のチャットのやりとり、役に立たないスクリーンショット、誰も読まないレポートなど、あらゆるものをセカンドブレインに放り込みます。1か月後にはフォルダーが膨らみ、エージェントは不要な情報を読むためにトークンを使い、どこに何があるか分からなくなります。ルールは、セカンドブレイン内の各ファイルが特定の質問に答えることです。6か月間誰も開かなかったら削除するか、アーカイブに移します。
アンチパターン3。**重複。**「支払いはCloudPayments経由で、`src/lib/payment/cloudpayments.ts`にあります。プロバイダーは`.env`で設定されています。」エージェントはコードからこれらすべてを確認できます。`business/`に重複して書かないでください。重複した情報は古くなります。コードが変わっても`business/`が更新されず、エージェントが古い情報に基づいて作業します。
アンチパターン4。**数値の固定。**「顧客が1,247人で、転換率は6.3%」と書きます。抽象的なフィンテックのスタートアップの数字だと想像してください。こうした数値はすべて1週間後には古くなります。LIVEマーカーと`live-metrics.md`を使います。詳しくは上のセクションを参照してください。
アンチパターン5。アクセスできる案内のない文脈。 セカンドブレインが別の場所にあり、権限も案内もなければ、コードフォルダーで起動するだけでは足りません。共有可能な情報なら`business/`と`ai-clone/`をリポジトリ内に置くと便利です。機密情報は権限を分けた場所に保管し、許可したアクセスと案内を明示的に設定してください。フォルダーの便利さを機密保持より優先してはいけません。
ヒント
別ブランチ（`context`や`business-context`）は整理には使えますが、アクセスの境界ではありません。同じリポジトリのGitオブジェクトなので、ブランチや履歴と公開される可能性があります。非公開の業務情報には、権限とエージェントの許可経路を明示した別の非公開リポジトリや外部保管先を使います。サブモジュールでも非公開性は接続先の権限によるものです。バックアップ付きで意図的に無視するローカルフォルダーも選択肢ですが、無視設定は追跡済みファイルや公開済み履歴を除去しません。コードと一緒に置くのは共有可能な情報だけです。
## 1時間でセカンドブレインを構築する方法：手順
重要なポイント
1時間あれば、最小限のセカンドブレインを設定できます。ルートに`business/`と`ai-clone/`を作り、それぞれに案内図となる`INDEX.md`を用意します。`business/products/`に製品の短い説明を、`audience/`に顧客の説明を追加し、`ai-clone/role.md`に自分が何者かを記します。CLAUDE.mdにこれらのフォルダーへの案内を追加します。その後は作業を進めながら拡張します。エージェントが間違えるたびに`ai-clone/feedback/`にルールを追加し、決定を下すたびに`business/`にメモを追加します。
1. ### ルートフォルダーを2つ作る
プロジェクトのルートで、`src/`と同じ階層に作成します。
```bash
mkdir -p business/{products,audience,goals,economics,marketing}
mkdir -p ai-clone/{identity,voice,principles,feedback,style}
```
2. ### フォルダー案内図としてINDEX.mdを作る
`business/INDEX.md`には「質問 → ファイル」の表を置きます。まずは少なくとも5行を作り、必要に応じて追加します。`ai-clone/INDEX.md`にも同じものを作ります。
3. ### 製品と顧客の短い説明を追加する
`business/products/main.md`には、製品とは何か、誰向けか、価格はいくらか、何が違うのかを書きます。30-50行にします。`business/audience/avatar.md`には、顧客は誰か、どんな悩みを抱え、何を購入するかを書きます。30-50行にします。理想の顧客像ではなく、実在する顧客を説明してください。分からないことがあれば「要確認」と記し、先に進みます。
4. ### ai-clone/role.mdに自分自身を記す
自分は何者か、何をしているか、何を大切にするかを書きます。20-30行で十分です。まずはそれだけで始められます。エージェントが自分らしくないスタイルで文章を書くと気づいたら、口調、原則、避ける言葉を追加します。
5. ### CLAUDE.mdに案内先を追加する
`CLAUDE.md`を開き、次のセクションを追加します。
```markdown
## Project map
- Business context → `business/INDEX.md`
- Context about me → `ai-clone/INDEX.md`
- Technical plans → `plans/YYYY-MM-DD-*.md`
- Reflections on past sessions → `retrospectives/`
Always read `ai-clone/INDEX.md` and `business/INDEX.md` at the start of a session.
```
6. ### Claude Codeを起動して確認する
エージェントを開き、「製品と対象者について教えて」と尋ねます。フォルダーの背景情報から答えれば、機能しています。作り話をする場合は、フォルダーがプロジェクトと同じ場所にあるか、ファイル名が正しいか、CLAUDE.mdの案内が明確に書かれているか確認します。
その後、セカンドブレインは2つの原則に沿って成長します。
1つ目は、エージェントが間違えるたびにルールを追加することです。3-4週間後には、`ai-clone/feedback/`に15-20個のルールファイルがあり、よくある間違いのほとんどをエージェントがしなくなります。
2つ目は、ビジネス上の決定を下すたびに`business/`に記録することです。価格を上げたら、日付と理由を添えて`business/products/pricing.md`にメモを追加します。ポジショニングを変更したら、`business/company/about.md`に記録します。6か月後には、「なぜ」を覚えているアーカイブができています。
プロンプト：夕方にセカンドブレインを更新するための、そのまま使えるプロンプト
```
今週、私たちは一緒にかなりの量の作業をしました。
今週のコード変更と、作成したすべてのコミットを分析してください。
そこから得られる価値ある情報のうち、business/に保存すべきものを書き出してください。コンテキストが失われないよう、近接するファイルへのwikiリンクを付けて、適切なファイルに記載してください。
コードに説明されていない決定があれば、その理由を私に尋ねてください。
そして理由を日付とともに適切なファイルに記録してください。
コードからすでに明らかなことを重複して書かないでください。business/がなければ、次のセッションでエージェントが知り得ないことだけを含めてください。
```
## 次に進むには：Skills、Subagents、コンテキストエンジニアリング
重要なポイント
セカンドブレインとCLAUDE.mdが土台です。その上に、Skills（タスクの説明に応じて必要なときに読み込む手順の知識）、Subagents（重い作業向けに独自のコンテキストウィンドウを持つ隔離されたClaudeのインスタンス）、コンテキストエンジニアリング（ウィンドウに何を入れるかの管理）を追加します。これらが上に重なる3つの階層です。土台がなければ、エージェントには読むものがありません。
セカンドブレインを用意したら、Anthropicがコンテキスト最適化の異なる3つの段階として説明するツールがさらに3つあります。
**Skills**は手順の知識です。繰り返し行うワークフロー（学習ガイドの執筆、Telegram投稿の作成、ウェブサイトの監査など）があれば、タスクの説明を含む`SKILL.md`ファイルに記述できます。セッション開始時にClaudeはスキル名と説明を確認し、現在のタスクに合うものだけを読み込みます。これによりトークンを節約し、作業への集中を保てます。
**Subagents**は、独自のコンテキストウィンドウを持つ隔離されたClaudeのインスタンスです。大変なタスク（30個のファイルを読んで要約するなど）をサブエージェントに任せると、独自のウィンドウで作業し、結果だけを返します。メインのウィンドウはすっきりしたままです。Anthropicは次のように述べています。
専門化されたサブエージェントは、整理されたコンテキストウィンドウで、焦点を絞ったタスクを解決できます。[…] 各サブエージェントは数万以上のトークンを使って幅広く調査しながら、圧縮され要点を抽出した作業の要約（多くの場合1,000-2,000トークン）だけを返します。
— Anthropic、anthropic.com/engineering/effective-context-engineering-for-ai-agents
**コンテキストエンジニアリング**とは、ウィンドウに何を入れるかを管理することです。Anthropicは、2025年にエージェントと作業するための基礎的なスキルであり、プロンプトエンジニアリングより一段上だと述べました。プロンプトエンジニアリングは言葉の選び方です。コンテキストエンジニアリングは、ファイル、案内先、スキル、サブエージェントの選び方です。
セカンドブレインは、コンテキストエンジニアリングの最初の構成要素です。これがなければ、Skillsは空っぽの場所を読み、Subagentsには参照先がなく、エージェントのウィンドウは無作為な情報で埋まります。用意すれば、3つすべてが機能し始めます。
次のステップ。 プロジェクトと同じ場所に`business/`と`ai-clone/`という2つのフォルダーを作ります。それぞれに案内図となる`INDEX.md`を作り、5行を書きます。CLAUDE.mdに案内先を4行追加します。1時間で、使えるセカンドブレインの枠組みができます。その後、「エージェントが間違えるたびに、`ai-clone/feedback/`に1行追加する」というルールで育てます。セカンドブレインに案内するためのCLAUDE.mdテンプレート全体は、[CLAUDE.mdを正しく設定する方法](https://ailoot.ai/blog/ja/claude-md-template/)のガイドで説明しています。
### 出典
- [Claude CodeのMemoryドキュメント](https://code.claude.com/docs/en/memory) - Anthropic公式のClaude Code記憶階層
- [Claude Codeのベストプラクティス](https://code.claude.com/docs/en/best-practices) - CLAUDE.mdを使った作業に関する公式ガイダンス
- [AIエージェントのための効果的なコンテキストエンジニアリング](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - Anthropic Engineeringによる、コンテキストの劣化、注意力の予算、ジャストインタイムのコンテキストに関する解説
- [Skillsの解説](https://claude.com/blog/skills-explained) - Skills、Memory、Subagents、MCPの違いに関するAnthropicのブログ
[Ailoot](https://ailoot.ai/)で引き続きご覧ください。
## Claude Codeのセカンドブレイン：1時間で構成する方法：よくある質問
### 別のGitブランチに業務情報を置けば非公開になりますか？
いいえ。同じリポジトリの一部で、オブジェクトや履歴と一緒に共有されえます。権限を分けた非公開保管先か、意図的に無視するバックアップ付きローカルフォルダーを使ってください。無視設定は追跡済み履歴を消しません。
### リポジトリ外の非公開情報を、エージェントにどう見つけさせますか？
明示的な案内と必要最小限の権限を与えます。短い索引から該当文書へ案内し、許可したファイルを実際に読めるか確認してください。非公開の場所に置くだけでは自動で文脈には入りません。
## Ailoot · 企業とそのプロジェクト群
Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。
企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。
Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。