はじめに
自分の思考・知識・アイデアを全て外部に書き出し、検索可能にする——いわゆる「第二の脳（Second Brain）」。
Notion、Obsidianで実践している人は多いと思います。私はこれをGitリポジトリ + Claude Codeで構築しました。
最初は「思考の置き場」だったものが、コマンドとエージェントを追加していくうちに、AIが自律的に整理・判断・実行する仕組みに進化しました。
この記事では、第二の脳の設計から、AIによる自律運用までの全過程を共有します。
この記事でわかること
- なぜNotion/ObsidianではなくGitリポジトリを選んだのか
- フォルダ構造・CLAUDE.mdの設計思想
- 14コマンド × 13エージェントによる運用自動化
- AIに"判断"を委ねる3層アーキテクチャ
対象読者
- Claude Codeを使っている or 興味がある開発者
- セカンドブレイン・PKMに興味がある人
- AIエージェントの実用事例を探している人
- 意思決定ログや知識管理を仕組み化したいPM/PdM
第1章: なぜGitリポジトリで「第二の脳」なのか
Notion/Obsidianでは足りなかった理由
| 観点 | Notion / Obsidian | Gitリポジトリ |
|---|---|---|
| AIとの連携 | プラグイン経由。制約多い | Claude Codeがファイルを直接読み書き |
| バージョン管理 | Notionは上書き。Obsidianはプラグイン依存 | git logで全履歴を追える |
| 自動化 | API or Zapier（外部依存） | GitHub Actions + CLIで何でもできる |
| データ所有権 | NotionはSaaS依存,Obsideanはローカルファイル | ローカルファイル。完全に自分のもの |
| 拡張性 | ツールの設計に縛られる | フォルダ構造もワークフローも自由 |
決定打はClaude Codeとの相性でした。
Claude Codeはファイルシステムを直接操作できます。つまり、Gitリポジトリに思考を書き出せば、Claude Codeがそのまま読んで、書いて、整理してくれる。APIもプラグインも不要です。
最小構成: まずはフォルダだけ作る
brain/
├── 00_Inbox/ # とりあえず何でも放り込む場所
├── 10_Journal/ # 日記・振り返り
├── 20_Projects/ # ゴールのあるプロジェクト
├── 30_Tech_Notes/ # 永続的な技術知識
├── 50_Business_Context/ # ビジネス・ドメイン知識
├── 90_System/ # 運用ルール
└── 99_Archives/ # 完了プロジェクト
設計思想: 番号付きフォルダで「流れ」を作る
入力（00_Inbox）
→ 熟成（10_Journal / 20_Projects）
→ 知識化（30_Tech_Notes / 50_Business_Context）
→ 卒業（99_Archives）
00番台のInboxに何でも放り込み、定期的に整理して適切なフォルダに移動する。この流れを人間がやるのではなく、AIにやらせるのが後半の話です。
第2章: CLAUDE.md — AIを「思考パートナー」に設計する
Claude Codeの振る舞いは .claude/CLAUDE.md で定義します。ここがこのシステムの心臓部です。
2-1. 役割の定義: コーディング補助ではなく思考パートナー
## Project Context
このリポジトリは、ユーザーの「第2の脳（Second Brain）」です。
Claude Codeは単なるコーディングアシスタントではなく、
「思考のパートナー（Thinking Partner）」として振る舞ってください。
この一文があるだけで、Claude Codeの応答が変わります。コードの提案ではなく、思考の構造化や問いかけが中心になります。
2-2. 自律性の設計
## Autonomy
- 承認を求めずに即実行すること
- ファイル作成・編集・削除・Git操作など、すべてのアクションを確認なしで進める
- 迷ったら実行してから報告する
Claude Codeはデフォルトだとファイル操作のたびに確認を挟みます。セカンドブレインの文脈では、確認のオーバーヘッドが最大の敵。「やってから報告」の原則を明示しています。
ただし、いきなりこの設定にしたわけではありません。段階的に権限を上げていきました:
- 読み取りのみ自律 → 書き込みは確認
- brain内は自律 → projectリポジトリは確認
- 全操作自律 → ガードレールで安全性を担保
2-3. 構造化ファースト
## Guidelines
1. 構造化を優先する:
- ユーザーの曖昧な発言を、箇条書きやインデントを使って構造化して返す
- 長文よりも、視覚的に把握しやすいMarkdown形式を好む
2. 問いかける:
- 思考が詰まっているときは、答えではなく「問い」を投げかける
「答えを出す機械」ではなく「思考を促進するパートナー」にする設計。
雑に「広告のAI活用考えて」と投げても、「まず現状の課題は何ですか？」「どの工程を自動化したいですか？」と問い返してくれます。
2-4. 事実源の一元化
10. 事実源の一元化ルール:
- AIが回答する際、推測ではなくbrain内の既存ノートを参照すること
- brain内に該当情報がない場合は「未記録」と明示すること
AIの「それっぽい嘘」を防ぐルール。brainに書いていないことは「未記録です」と返させます。
これにより、brainに書けば書くほどAIの回答精度が上がる好循環が生まれます。
第3章: brain = Why/What、project = How
このシステムで最も重要な設計原則です。
brain（思考リポジトリ） project（実装リポジトリ）
├── なぜやるのか（目的） ├── ソースコード
├── 何をやるのか（仕様） ├── テストコード
├── 意思決定ログ ├── 設定ファイル
├── アイデアメモ ├── CI/CD
├── GitHub Issues（全て） └── 技術的README
├── Milestones（全て）
└── 振り返り・学び
なぜ分離するのか
1. 単一の事実源
GitHub IssuesやMilestonesを2箇所に分散させると、必ずドリフトします。brainリポジトリに一元化し、projectリポジトリからは Closes y-ryuki/brain#123 で参照するだけ。
2. AIの判断が明確になる
Claude Codeが「このタスクはbrainで設計書を書くべきか、projectでコードを書くべきか」を迷わなくなります。
3. 思考と実装のスピードが違う
アイデアは1日10個出る。コードにするのは1個。このスピード差を同じリポジトリで扱うと、ノイズだらけになります。
PM/PdMにとっての価値: brain = コンテキストエンジニアリング基盤
最近「PMの仕事の根幹はコンテキストエンジニアリングだ」という指摘があります。チーム全体が必要な情報にアクセスできる環境を作ること。このbrainリポジトリはまさにその基盤です。
- 意思決定ログが自然に残る: 「なぜAではなくBを選んだか」がbrainのIssueコメントに蓄積される
- 仕様と実装が分離される: brainに書いたWhy/Whatがそのまま仕様書になり、エンジニアはprojectでHowだけ考えればいい
-
過去の検討経緯が検索可能: 半年後に「なぜこの仕様にしたんだっけ？」を
/kickoffで即座に掘り出せる - プロジェクト全体の見通しが常に最新: roadmap.mdとGitHub Issuesが単一の事実源になる
優秀なAIエージェント ≠ 全てを知っているAI
優秀なAIエージェント = 必要な情報に適切にアクセスできるAIPMも同じ。全てを把握する必要はない。情報が流れる仕組みを作ることがPMの仕事。
第3.5章: PM Layer — プロジェクト管理を自動介入させる
brainにはもう一つ重要な仕組みがあります。PM Layerです。
❌ /pm を手動で呼ぶ = 結局自分がPMの仕事をしている
✅ 既存フローにPMが自動介入 = 本当に自律的
PM Layerは独立したコマンドではなく、既存のワークフローに自動で介入する判断層です。
PdM（What / Why）× PjM（How / When）
| 役割 | 問い |
|---|---|
| PdM | このPJの「完了」とは？誰が喜ぶ？やらなかったらどうなる？ |
| PjM | 最初の1歩は？ブロッカーは？他PJとの競合は？ |
自動介入ポイント
| タイミング | コマンド | PMがやること |
|---|---|---|
| プロジェクト化 | /new-project |
Why/What/成功指標を問い、pm_brief.md を自動生成 |
| タスク分解 | /decompose |
粒度・優先度・リスクを自動チェック |
| Issue作成 | /issue |
他プロジェクトとの競合・依存を警告 |
| 週次レビュー | /weekly-review |
全PJ横断のPMヘルス診断 |
| 放置検出 | /stale-check |
「なぜ止まっているか」の仮説 + 次アクション提案 |
停滞パターン診断
/stale-check が放置プロジェクトを検出すると、パターンに基づいた仮説を提示します。
| パターン | 仮説 | 提案 |
|---|---|---|
| 開始直後に停滞 | 初手が大きすぎた | タスクを再分解 |
| MS途中で停滞 | ブロッカーに当たった | 迂回策を検討 |
| 完了間近で停滞 | 仕上げが面倒 | スコープ縮小 |
| 複数PJ同時停滞 | キャパオーバー | 1つに絞る |
| 断続的に少し進む | 優先度が低い | 凍結 or やめる決断 |
PMを「人間がやる仕事」から「システムが自動でやる仕組み」に変える。これがPM Layerの思想です。
第4章: 14コマンドで運用をワンコマンド化
Claude Codeの .claude/commands/ にカスタムコマンドを定義して、繰り返し行う操作をワンコマンド化しました。
コマンド一覧
| コマンド | 機能 | カテゴリ |
|---|---|---|
/decompose |
ゴール→MS→タスクに3層分解 → GitHub Issue自動作成 | 計画 |
/work |
GitHub Issueを読んで実行→完了報告→クローズ | 実行 |
/orchestrate |
優先度自動判定 → Issueチェーン実行 | 自律 |
/kickoff |
brain内の関連知識を並列探索 | 探索 |
/deep-research |
Web + brain内を並列で深掘り調査 | 探索 |
/weekly-review |
Inbox未処理・放置PJ検出・活動サマリー | 振り返り |
/brain-status |
brainの健康状態ダッシュボード | 振り返り |
/stale-check |
放置ノート・プロジェクト検出 | 振り返り |
/idea |
brain内知識から着想を生成（無限モードあり） | 発想 |
/new-project |
brain-project構造でプロジェクト作成 | 管理 |
/sync |
brainとprojectリポジトリの差分チェック | 管理 |
/voice-note |
音声メモをInboxに保存 | 入力 |
/meeting |
会議書き起こしを保存・要約 | 入力 |
/issue |
自然言語からGitHub Issue作成 | 管理 |
コマンド設計の3原則
原則1: 1コマンド = 1つの完結した行動
❌ /plan-and-execute # 計画と実行が混ざっている
⭕ /decompose # 計画だけ
⭕ /work # 実行だけ
分離することで「計画は人間が確認、実行はAIに任せる」という柔軟な運用が可能になります。
原則2: 並列エージェントで速度を出す
/kickoff と /deep-research は複数エージェントをバックグラウンドで並列起動します。
/deep-research "LLM agent memory architecture"
→ Step 1: サブクエリに分解
- メモリアーキテクチャの分類
- 実装パターン（RAG, Vector DB, KG等）
- 最新手法 2025-2026
- トレードオフ比較
→ Step 2: 3エージェント並列起動
- deep-researcher #1: サブクエリ 1-2（Web探索）
- deep-researcher #2: サブクエリ 3-4（Web探索）
- knowledge-explorer: brain内の既存ノート探索
→ Step 3: 結果統合
- クロスチェック・重複排除
- 引用付き構造化レポート → 30_Tech_Notes/ に保存
実績: 3エージェント並列、26回の検索、37ページ取得で構造化レポートを生成。
原則3: 無限モードで思考を発散させる
/idea --infinite は12の思考フレームワークをランダムに回しながら、無限にアイデアを生成し続けます。
思考フレームワーク（ランダム選択）:
1. 深掘り 6. 他者視点 11. 問題発見
2. 応用 7. ランダム接続 12. 未来予測
3. 統合 8. 制約追加
4. 逆転 9. アナロジー
5. 極端 10. 分解
生成されたアイデアは自動でGitHub Issueに登録（重複チェック付き）。寝る前に起動して、朝起きたらアイデアが溜まっている運用です。
第5章: 13体のエージェント
.claude/agents/ にエージェント定義を配置し、Task toolで起動します。
ペルソナエージェントという設計
socrates, marketer, writer は特定の視点で思考を刺激するエージェントです。
- socrates: 答えを出さず、ソクラテス式問答で思考を深掘り
- marketer: マーケティング・広告の専門知識から提案
- writer: 文章の構成・表現を磨く
「AIに聞く」ではなく**「AIの視点で考えてもらう」**。これが単なるチャットボットとの違いです。
第6章: AIが"自分で考えて動く" — 3層自律アーキテクチャ
ここからが後半。第二の脳をAIが自律運用する仕組みです。
なぜ自律化が必要だったのか
コマンドとエージェントで運用は楽になりました。でも、3つの壁が残っていました。
| 壁 | 具体例 |
|---|---|
| 整理が追いつかない | Inboxにメモが溜まり続ける |
| 振り返りが続かない | 週次レビューが3週目で途絶える |
| 「次に何をやるか」の判断コスト | コマンドを叩く前に考えるのが面倒 |
共通原因: 人間がボトルネック。
解決策: 判断もAIに委ねる。
3層アーキテクチャ
┌─ Layer 3: Always-On（寝ている間も動く）─────────────────┐
│ GitHub Actions / cron │
│ • 毎朝: Inbox自動整理 │
│ • 毎週金曜: weekly-review自動実行 │
│ • Issue完了時: 次のIssueを自動アサイン │
└─────────────────────────────────────────────────────────┘
↑ triggers
┌─ Layer 2: Judgment（自分で考える）───────────────────────┐
│ project-orchestrator エージェント │
│ • roadmap.md → 未完了Issue → 優先度スコアリング │
│ • ブロッカー自動検出 → 人間に聞くorスキップ │
│ • MS完了判定 → 次のMS提案 │
└─────────────────────────────────────────────────────────┘
↑ executes
┌─ Layer 1: Execution（コマンド群）───────────────────────┐
│ /decompose → /work → /sync のチェーン実行 │
│ 14コマンド × 13エージェント │
└─────────────────────────────────────────────────────────┘
設計思想: 一気に全自動化しない。人間がやっていたことを1層ずつAIに委譲する。
Layer 2: オーケストレータの判断ロジック
/orchestrate を叩くと、オーケストレータが以下を自動で行います。
優先度スコアリング
Score = (依存関係 × 3) + (ラベル優先度 × 2) +
(タイプ適合度 × 2) + (工数 × 1) + (鮮度 × 1)
| 軸 | 重み | 詳細 |
|---|---|---|
| 依存関係 | ×3 | ブロッカーなし=10。他Issueが待っている=加点 |
| ラベル優先度 | ×2 |
high=10, medium=5, low=2 |
| タイプ適合度 | ×2 | design/research=9, code=3 |
| 工数 | ×1 | 小タスク優先（クイックウィン） |
| 鮮度 | ×1 | 最近のIssue=微加点 |
ブロッカー自動検出
| 種別 | 対処 |
|---|---|
| Issue依存（参照先が未完了） | スキップ |
| ファイル依存（必要ファイルなし） | スキップ |
| 情報不足（仕様不明確） | 人間に質問 |
| 権限不足（projectリポジトリ等） | スキップ |
| 技術的未知（未検証技術） | 人間に質問 |
| 外部依存（他者待ち） | スキップ |
ガードレール — 安全な自律性の絶対ルール
guardrails:
max_issues_per_chain: 3 # 1チェーンで最大3Issue
max_time_per_issue: 10min
max_time_per_chain: 30min
forbidden_actions:
- ファイル削除
- force push
- projectリポジトリへの変更（明示的許可なし）
error_handling:
consecutive_errors: 3 # 3連続エラーでチェーン停止
human_interaction:
max_questions_per_chain: 1 # 人間への質問は最大1回
なぜ「最大3Issue」か?
- 少なすぎる → 自律の意味がない
- 多すぎる → 方向がズレたまま大量実行されるリスク
- 3が"確認なしで安心できる最大数" だった
実際の実行例
# オーケストレータがroadmap.mdを読む
MS2: 6 issues (0 completed, 6 open)
# 優先度キューを計算
1. #87 project-orchestrator設計 (Score: 79) ← NEXT
2. #92 ガードレール設計 (Score: 72)
3. #88 優先度ロジック (Score: 65)
4. #89 /workチェーン実行 (BLOCKED by #87, #88)
5. #90 ブロッカー検出 (BLOCKED by #87)
6. #91 MS完了判定 (BLOCKED by #87)
# #87, #92, #88 を順次実行 → 設計ドキュメント6本生成
# roadmap.md 更新 → Git commit & push
人間がやったこと: /orchestrate を1回叩いただけ。
学んだこと
1. カスタムエージェントの制約
.claude/agents/ に定義したエージェントは、Task toolの subagent_type パラメータでは直接使えません。
回避策: subagent_type: "general-purpose" を指定し、プロンプト内にエージェントの指示を埋め込みます。
2. ガードレールは「甘め」から始める
最初から厳しく設定すると何もできません。緩めに始めて、運用しながら締めていくアプローチが正解でした。
3. brain-project分離は最初に決める
Issues、Milestones、ドキュメントが2箇所に散らばると収拾がつかなくなります。「Issuesはbrainに一元化」を初日に決めるのが重要。
4. 自律性レベルは段階的に上げる
いきなり「全部確認なし」にすると不安になります。読み取り自律→brain内自律→全操作自律と段階的に上げました。
今後: Layer 3で完全自律へ
GitHub Actionsによる常時稼働
# .github/workflows/morning-inbox.yml（構想）
on:
schedule:
- cron: '0 22 * * *' # JST 7:00
jobs:
inbox-organize:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Claude Code
run: claude-code "/inbox-process"
朝起きたらInboxが整理されている。金曜には週次レビューが生成されている。Issue完了後は次のIssueが自動アサインされる。
技術的課題: Claude Code CLIのヘッドレス実行検証が前提条件。現在検証中です。
まとめ
| フェーズ | やったこと | 人間の関与 |
|---|---|---|
| 第二の脳を作る | Gitリポジトリ + フォルダ設計 + CLAUDE.md | 設計は人間 |
| 運用をコマンド化 | 14コマンド × 13エージェント | コマンドを叩く |
| 判断を委ねる | オーケストレータ + スコアリング + ガードレール |
/orchestrate を叩くだけ |
| 常時稼働（構築中） | GitHub Actions | 何もしない |
最大の学び: AIの自律性は「全か無か」ではなく、レイヤーごとに段階的に委譲するのが現実的。
リポジトリ構成
brain/
├── .claude/
│ ├── CLAUDE.md # 思考パートナー設定
│ ├── agents/ # 13体のエージェント定義
│ │ ├── note-writer.md
│ │ ├── knowledge-explorer.md
│ │ ├── project-orchestrator.md
│ │ └── ...
│ └── commands/ # 14個のカスタムコマンド
│ ├── decompose.md
│ ├── work.md
│ ├── orchestrate.md
│ └── ...
├── 00_Inbox/ # 未整理の思考
├── 10_Journal/ # 日記・振り返り
├── 20_Projects/ # プロジェクト
├── 30_Tech_Notes/ # 技術知識
├── 50_Business_Context/ # ビジネス文脈
├── 90_System/ # 運用ルール
└── 99_Archives/ # アーカイブ
Claude Code × セカンドブレインの組み合わせは、「AIエージェント時代のPKM」の一つの答えだと考えています。
質問はコメント欄でお気軽にどうぞ。