Claude Codeのセカンドブレイン：1時間で構成する方法

Ailootの参考ドキュメント：ailoot.ai/docs/。

Claude Codeにセカンドブレインが必要なのはなぜ？何が欠かせない？#

火曜日にClaude Codeを開きます。これがプロジェクトで、これが対象者で、これはしないで、と説明します。一緒に作業します。木曜日には新しいチャットになり、またすべて説明し直さなければなりません。

CLAUDE.mdがあれば、最初の苛立ちは解消されています。基本ルールとプロジェクトの説明が1つのファイルにあり、毎回のセッションで読み込まれます。このファイルの仕組みはCLAUDE.mdのガイドで説明しました。まずそれを読めば、基礎を整えられます。

しかし、CLAUDE.mdは新入社員向けの取扱説明書です。服装、顧客との話し方、公開に使うコマンドなどを定めます。プロジェクトについて良い判断を下すには、それだけでは足りません。判断には知識が必要です。製品とは何か、対象者は誰か、収支はどうなっているか、何を試し、何がうまくいかなかったか、といった知識です。

ここで述べる筆者の経験では、そうした知識は以前、4か所に分散していました。自分の頭、Telegramのチャット、Googleドキュメント、従業員の頭です。決定から1か月もすれば、なぜそう決めたのか誰も覚えていません。新しい人が加わると、状況を把握するためにチームへ1時間質問することになります。Claudeはその背景をまったく共有していませんでした。

筆者が説明する経験では、セカンドブレインを作る前は、セッションのたびに顧客は誰か、オファーはどういう構成か、支払いをどのプロバイダーが処理するかを説明していました。business/を作ってからは、チャットを開いて「新しい料金プランに合わせてオファーを更新して」と伝えるだけです。Claudeは自分でbusiness/company/legal.mdを開いて要件を読み、次にbusiness/products/pricing.mdを開いて新しい料金プランを確認し、一度の作業で編集案を出します。準備にかける時間がなくなり、背景情報が自動で読み込まれます。

Anthropicはエンジニアリングブログで、この問題を「コンテキストの劣化」と呼んでいます。

言い換えると、ウィンドウに詰め込む情報が増えるほど、エージェントは細部を扱うのが苦手になります。解決策は、Claudeが個別の依頼に応じて自分で参照できる外部ファイルの構造を保つことです。それがセカンドブレインです。

セカンドブレインとは何？Claudeでどう応用できる？#

典型的なセカンドブレインの利用者はObsidianの保管庫を作り、本からの抜粋、通話のメモ、プロジェクトのアイデアを追加します。

筆者がこの考え方をClaude Codeとの作業に応用すると、生産性の話ではなくエージェントのアーキテクチャの話になりました。

従来のアプローチでは、セカンドブレインは自分のもので、自分で手動でアクセスします。Claude Codeと作業する場合、セカンドブレインは双方向になります。あなたとエージェントの両方がアクセスします。そのため、形式に求められる条件が変わります。

エージェントが自分でアクセスするため、別の連携機能がなくても理解できる形式でファイルを保存する必要があります。Markdownが理想的です。テキスト、見出しの階層、ファイル間のリンクを使えます。NotionやGoogle Docsは適していません。MCP経由で接続できますが、別の層が増え、リクエストごとにトークンが追加され、障害点も増えます。

ファイルはプロジェクトと同じファイルシステムにあるので、Claude Codeが自動的にアクセスできます。設定は不要です。プロジェクトフォルダーでエージェントを起動すれば、その中のファイルをすべて見ることができます。無料で、そのまま動作します。

Claude Codeに標準搭載されている記憶の階層とは？#

独自のものを追加する前に、Claudeが手助けなしで何を記憶できるのか見てみましょう。Anthropicは公式ドキュメントで2つの仕組みを説明しています。自分で書くルールであるCLAUDE.mdと、Claude自身が書く教訓である自動メモリです。どちらも各セッションの開始時に読み込まれます。

CLAUDE.mdは同時に4か所から検索されます。

4つのファイルすべてがコンテキストに読み込まれます。階層が具体的になるほど優先度が高くなります。ローカルファイルは最後に読まれるため、そのルールがほかのルールより優先されます。

プロジェクト内のどのフォルダーにもCLAUDE.mdを置けます。Claudeがサブフォルダー内のファイルを読むと、そのサブフォルダーのCLAUDE.mdを必要に応じて読み込みます。これはモノレポで便利です。フロントエンドのルールはfrontend/CLAUDE.mdに、バックエンドのルールはbackend/CLAUDE.mdに置き、エージェントが該当部分を扱うときだけ読み込みます。

自動メモリはClaude Code 2.1.59で導入されました。これはClaudeがあなたについて書くファイルです。

~/.claude/projects/<project-name>/memory/
├── MEMORY.md          # インデックス。各セッションで読み込まれる（200行または25KB）
├── debugging.md       # 詳細メモ（必要に応じて読み込まれる）
├── api-conventions.md
└── ...

Anthropicは公式ドキュメントで次のように説明しています。

自動メモリは~/.claude/settings.jsonのautoMemoryEnabledフラグで有効にします。何を書くかはClaudeが判断します。MEMORY.mdを読んだり手動で編集したりできます。普通のMarkdownファイルです。

CLAUDE.mdとセカンドブレイン、どこで使い分ける？#

講演でよく使うたとえを紹介します。新しい従業員を雇ったと想像してください。初日に何を渡しますか？

取扱説明書です。服装、出勤時間、顧客との話し方、公開に使うシステムを伝えます。短い文書で、何をしているのか、なぜそうしているのかまでは説明しません。単に、どう振る舞うかを示します。

そして別に、社内Wikiへのアクセス権を渡します。製品とは何か、誰のためのものか、対象者は誰か、価格はいくらでその理由は何か、競合は誰か、どんな失敗をしたかを説明します。これは大規模なアーカイブです。誰も最初から全部は読みません。特定の質問があるときに参照します。

CLAUDE.mdは取扱説明書。セカンドブレインはWiki。両方が必要です。

区別は簡単です。すべてのタスクに関係するものは、すべてCLAUDE.mdに入れます。

• このプロジェクトでのエージェントの役割（ヘルパー、リード、アシスタント）
• 回答する言語
• ツールのスタック
• 公開コマンド
• 禁止事項（emダッシュを使わない、git push --forceを実行しない）
• 案内先：ビジネスの背景情報や原則をどこで確認するか

必要に応じて使うものは、セカンドブレインに入れます。

• 製品、対象者、収支、目標
• 競合と市場
• 過去の決定とその理由
• 顧客事例とレビュー
• 原則と方法論

Anthropicもドキュメントで同じ区別を示しています。

スキルは、エピソード的な知識を保存する方法の1つです。プロジェクトと同じ場所にbusiness/フォルダーを置く方法もあります。筆者は両方を使っており、以下で詳しく説明します。

プロジェクトのブレインを構成するもの：5つの要素とタイムマシン#

筆者が説明する経験に基づく構成例です。

方法論上の重要な点は、ai-clone/とbusiness/を分けることです。

business/は「何をしているのか」に答えます。製品、対象者、価格、競合など、プロジェクトに関する情報です。明日プロジェクトをパートナーに引き継ぐなら、このフォルダーも一緒に渡します。

ai-clone/は「どう意思決定するのか」に答えます。自分の原則、口調、仕事の技術、避けるべき言葉など、自分に関する情報です。明日新しいプロジェクトを始めるなら、このフォルダーを持っていきます。

これらを組み合わせると、筆者が「一人会社」と呼ぶものになります。1人の人間、構造化された背景情報、そしてその情報を読むAIです。

2つ目のフォルダーを設定するだけでなく、Claudeの一貫性を保つ仕組みも作りたいですか？それだけでは不十分です。ai-clone/がなければ、エージェントはあなたではなく誰にでも当てはまる回答をします。コンテキストエンジニアリングがなければ、フォルダー全体を歩き回ってトークンを浪費します。3つすべてをつなげると役立ちます。セカンドブレイン＋AIクローン＋コンテキストエンジニアリングです。これらは、AIが幻覚を起こさないための3本柱です。

business/には何を入れ、何を入れない？#

筆者が説明するプロジェクトにおけるbusiness/の最上位構成です。

business/
├── INDEX.md              ← フォルダーの案内図。最初に読む
├── company/              ← ミッション、法人、価値観、法的ポリシー
├── products/             ← 製品、プログラム、価格
├── audience/             ← 顧客像、セグメント、異議
├── goals/                ← 年次、四半期、月次の目標と指標
├── economics/            ← ユニットエコノミクス、収入、費用、予測
├── marketing/             ← チャネル、ファネル、資料、競合
├── execution/            ← 週次計画、バックログ
└── assets/               ← デザインシステム、レビュー、コピー集

これは筆者が説明するプロジェクトの例であり、絶対的な規則ではありません。必要に応じてフォルダーを作ります。最初は3つ（products/、audience/、goals/）から始め、2-3か月後に新しいものの保存先が分からなくなったため、ほかを追加しました。

フォルダーの中心となるファイルはINDEX.mdです。これは案内図です。「質問 → ファイル」の表を置き、Claudeがどこに進めばよいか判断できるようにします。これがないと、エージェントはファイルを順番にすべて読むためにトークンを使います。

INDEX.mdの抜粋例です。

### 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万人の前に公開されたとして、見せてもよいものだけを残します。従業員、エージェント、ときには外部の契約業者もこのフォルダーを読みます。

ai-cloneフォルダーを分けて作る理由は？businessと混ぜてはいけない理由は？#

考え方はシンプルです。ビジネスは私たちが何をしているかを把握します。クローンは私がどう意思決定するかを把握します。

筆者が説明するプロジェクトでのai-clone/構成です。

ai-clone/
├── INDEX.md           ← フォルダーの案内図
├── role.md            ← 自分は何者か、経歴、何を大切にするか
├── identity/          ← 価値観、ビジョン、ミッション
├── thinking/          ← 講演から得たメンタルモデル
├── voice/             ← 口調、語彙、スタイル
├── principles/        ← 製品、コード、ビジネスに関する信念
├── feedback/          ← 失敗から学んだルール ← 主要フォルダー
├── style/             ← 避けるべき言葉、Telegram形式
└── reference/         ← ツール、環境

最も役立つのはfeedback/フォルダーです。エージェントの失敗を通して学んだ具体的なルールを保存します。各ルールは別ファイルに、次の形式で記述します。

---
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はプロジェクトに残ります。

Live Metricsとは？ファイルに数値を直接書くべきでない理由は？#

セカンドブレインを作り始めるときによくある落とし穴の1つは、古い数値でいっぱいにしてしまうことです。「顧客が320人いる」と書いても、2週間後には410人になっています。「月間売上は470万」と書いても、1か月後には、その数値が目標、実績、予測のどれなのか分からなくなります。

筆者の例では、次のように機能します。business/products/practicum.mdファイルでは、数字の代わりにマーカーを置きます。

## 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クエリと、結果の説明を記載します。

## 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つの問題を同時に解決できます。数値が古くなりません。そして、意思決定は昨年のものではなく、現状を反映した情報に基づいて行われます。

1つの依頼に対して、AIはセカンドブレインをどう参照する？#

具体的な依頼の例：「新しい期の参加者に送るメールを作成してください。」

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はエンジニアリングブログで、このアプローチをジャストインタイムのコンテキストと呼んでいます。

つまりClaudeはデータそのものではなく、データへの参照を保持します。関連する情報だけがコンテキストに入るので、トークン効率が高く、精度も上がります。ウィンドウを推論のために使えます。

セカンドブレインで避けるべき5つのアンチパターン#

アンチパターン1。肥大化したCLAUDE.md。「すべてを1か所に入れる」ための500行の指示です。Anthropicは明確に述べています。

目安は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/をリポジトリ内に置くと便利です。機密情報は権限を分けた場所に保管し、許可したアクセスと案内を明示的に設定してください。フォルダーの便利さを機密保持より優先してはいけません。

1時間でセカンドブレインを構築する方法：手順#

1. ルートフォルダーを2つ作る

   プロジェクトのルートで、src/と同じ階層に作成します。

   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を開き、次のセクションを追加します。

   ## 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、コンテキストエンジニアリング#

セカンドブレインを用意したら、Anthropicがコンテキスト最適化の異なる3つの段階として説明するツールがさらに3つあります。

Skillsは手順の知識です。繰り返し行うワークフロー（学習ガイドの執筆、Telegram投稿の作成、ウェブサイトの監査など）があれば、タスクの説明を含むSKILL.mdファイルに記述できます。セッション開始時にClaudeはスキル名と説明を確認し、現在のタスクに合うものだけを読み込みます。これによりトークンを節約し、作業への集中を保てます。

Subagentsは、独自のコンテキストウィンドウを持つ隔離されたClaudeのインスタンスです。大変なタスク（30個のファイルを読んで要約するなど）をサブエージェントに任せると、独自のウィンドウで作業し、結果だけを返します。メインのウィンドウはすっきりしたままです。Anthropicは次のように述べています。

コンテキストエンジニアリングとは、ウィンドウに何を入れるかを管理することです。Anthropicは、2025年にエージェントと作業するための基礎的なスキルであり、プロンプトエンジニアリングより一段上だと述べました。プロンプトエンジニアリングは言葉の選び方です。コンテキストエンジニアリングは、ファイル、案内先、スキル、サブエージェントの選び方です。

セカンドブレインは、コンテキストエンジニアリングの最初の構成要素です。これがなければ、Skillsは空っぽの場所を読み、Subagentsには参照先がなく、エージェントのウィンドウは無作為な情報で埋まります。用意すれば、3つすべてが機能し始めます。

次のステップ。プロジェクトと同じ場所にbusiness/とai-clone/という2つのフォルダーを作ります。それぞれに案内図となるINDEX.mdを作り、5行を書きます。CLAUDE.mdに案内先を4行追加します。1時間で、使えるセカンドブレインの枠組みができます。その後、「エージェントが間違えるたびに、ai-clone/feedback/に1行追加する」というルールで育てます。セカンドブレインに案内するためのCLAUDE.mdテンプレート全体は、CLAUDE.mdを正しく設定する方法のガイドで説明しています。

Ailootで引き続きご覧ください。