Claude Codeで「俺だけのナレッジベース」を作る
はじめに
こんにちは。いつもAIに感謝しながら仕事しているエンジニアです。
話題のClaude Code proプランを勢いで年契約したので、さっそく何か活用法を考えてみました。
探せば似たような記事出てきそうですが...
この記事もClaudeに書かせてます。
なぜ「俺だけのナレッジベース」が必要か
エンジニアとして、技術トレンドの追跡は永遠の課題です。
- TypeScript の新しい型安全パターン
- Next.js App Router のベストプラクティス
- AWS のコスト最適化テクニック
- セキュリティの最新脅威と対策
これらを毎日手動でキャッチアップするのは現実的ではない。かといって、Zenn や Qiita のタイムラインを眺めるだけでは体系的な知識にならない。
そこで考えたのが、AIエージェントに技術のベストプラクティスとアンチパターンを収集させ、自分だけのナレッジベースとして蓄積するシステムです。
記事まんまコピペではなく情報を要約して蓄積させている。
あと、ナレッジリポジトリは念のためプライベートにしている。
このシステムの特徴
- Agent Foundry — 「エージェントを作るエージェント」で専門エージェントを自動生成
- Collector/Curator 2層構造 — 収集と整形を責任分離
-
Dual Output — 人間が学ぶ用の
docs/と、AIに読ませる用のskills/を同時生成 - スマホからワンコマンド — Claude Code Web でどこからでも収集を起動
- Single File 更新 — 日付でファイルを分割しない。1トピック1ファイルを育て続ける
システム全体像
┌──────────────────────────────────────────────────────┐
│ ユーザー │
│ スマホ (Claude Code Web) / PC (CLI) │
└──────────────┬───────────────────────────────────────┘
│ 「日次収集を実行して」
▼
┌──────────────────────────────────────────────────────┐
│ Claude Code (Proプラン) │
│ │
│ ┌─────────────────────┐ ┌──────────────────────┐ │
│ │ Collector (8体) │ │ Curator (2体) │ │
│ │ 技術ごとの専門家 │→│ docs + skills 整形 │ │
│ │ Web検索で情報収集 │ │ フォーマット統一 │ │
│ └─────────────────────┘ └──────────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ docs/ │ skills/ │ metadata/ │ │
│ │ (人間向け) │ (AI向け) │ (収集履歴) │ │
│ └─────────────────────────────────────────────────┘ │
│ │ │
│ git commit & push │
└──────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ GitHub (private-research-lab) │
│ ナレッジベースが蓄積されていく │
└──────────────────────────────────────────────────────┘
Agent Foundry — 「エージェントを作るエージェント」
このプロジェクトの土台にあるのが Agent Foundry です。
Agent Foundry は、「こんなエージェントがほしい」と自然言語で伝えると、4段階のパイプラインで .agent.md ファイルを自動生成するメタエージェントです。
ユーザーの要望
→ RequirementsGatherer (要件整理)
→ DesignerAgent (設計)
→ WriterAgent (ファイル生成)
→ ReviewerAgent (品質レビュー)
→ .agent.md ファイル完成
今回のナレッジベースシステムでは、Agent Foundry のアーキテクチャを踏襲して10体のエージェント定義を生成しました。これは今後、別プロジェクトでもエージェントが必要になった時に同じ仕組みを使う「コンストラクション(構築規約)」として定めています。
Collector/Curator 2層設計
なぜ分けるか
最初は「1体のエージェントで収集も整形もやればいいじゃん」と思いました。でも、実際に設計すると問題が見えてきます。
問題: プロンプトの肥大化
あなたはTypeScriptの専門家です。
以下のトピックについてWeb検索で情報を収集してください...
(技術固有の知識: 500トークン)
収集した情報を以下のフォーマットで整形してください...
(人間向けテンプレート: 300トークン)
同時に以下のAI向けフォーマットでも出力してください...
(skills テンプレート: 300トークン)
1体に全部やらせると、システムプロンプトが 1100トークン以上に膨れ上がります。12トピック分実行すると、ほとんどのトークンがプロンプトの読み込みに使われてしまう。
解決: 責任分離
Collector (技術知識に特化): ~500トークン
→ 「何を集めるか」に集中
Curator (フォーマットに特化): ~300トークン
→ 「どう整形するか」に集中
これで各エージェントのプロンプトがコンパクトになり、トークン効率が向上します。
Collector エージェント (8体)
技術カテゴリごとに1体ずつ、専門家のペルソナを持つエージェントを定義しました。
| エージェント | 担当 | ペルソナ |
|---|---|---|
frontend-collector |
TypeScript, React/Next.js | フロントエンド10年のシニアエンジニア |
java-collector |
Java, Spring Boot | エンタープライズJava15年のアーキテクト |
flutter-collector |
Flutter/Dart | モバイル開発7年、公式チーム動向をフォロー |
aws-collector |
AWS全般 | SA Professional認定アーキテクト |
devops-collector |
CI/CD, Docker, IaC | DevOps/SREとして複数企業で構築経験 |
security-collector |
Webセキュリティ, 認証認可 | OWASP貢献者、脆弱性診断の実務経験 |
architecture-collector |
設計パターン, API, DB/SQL | アーキテクト20年、DDD実践者 |
ai-collector |
プロンプトエンジニアリング, トレンド | LLMアプリ設計の最前線 |
Curator エージェント (2体)
| エージェント | 役割 |
|---|---|
docs-curator |
人間向け学習ドキュメントに変換 (テクニカルライター) |
skills-curator |
AI消費用スキルファイルに変換 (AI/MLエンジニア) |
ドキュメント設計 — 人間向け vs AI向けの Dual Output
このシステムの最もユニークな設計判断が Dual Output です。同じ技術知識を2つの形式で蓄積します。
人間向け (docs/)
### 1. Discriminated Union を活用する
**なぜ:** 型の網羅性チェックでランタイムエラーを防止
**Good:**
```typescript
type Result<T> =
| { status: "success"; data: T }
| { status: "error"; error: Error };
Bad:
type Result<T> = { data?: T; error?: Error; };
参考: TypeScript公式
特徴:
- **「なぜ」から始まる** — 理由が分かるから記憶に残る
- **Good/Bad の対比** — 何がダメで何が良いか一目瞭然
- **コード例が具体的** — コピペしてすぐ使えるレベル
- **参考URLあり** — 信頼性の裏付け
### AI向け (`skills/`)
```markdown
## RULES (必ず守ること)
- any型を使わない。unknown + 型ガードを使う
- asキャストよりsatisfies演算子を優先
## PATTERNS (推奨パターン)
### Discriminated Union
```typescript
type Result<T> = { status: "success"; data: T } | { status: "error"; error: Error };
USE WHEN: 関数の戻り値が成功/失敗で異なる場合。
ANTI-PATTERNS (避けること)
AP-1: any の多用
BAD: function parse(data: any): any
FIX: function parse(data: unknown): Result<ParsedData>
REASON: 型安全性が完全に失われる
CHECKLIST
- strict: true が有効か
- any が使われていないか
特徴:
- **RULES / PATTERNS / ANTI-PATTERNS / CHECKLIST** の4セクション構造
- **`USE WHEN`** でパターンの適用条件を明示
- **`BAD/FIX/REASON`** の3点セットで機械的に検知・修正可能
- **`triggers`** (YAML frontmatter) で「いつこのスキルを参照すべきか」を定義
**将来的には、この skills ファイルを CLAUDE.md から参照することで、AIがコード生成・レビュー時に自動的にベストプラクティスを適用できるようになります。**
---
## 収集パイプライン — スマホからワンコマンド
### 毎日の運用フロー
- 朝起きる
- スマホで Claude Code Web を開く
- 「日次収集を実行して。対象: all」と入力
- Claude Code が自動で:
- 各技術のWeb検索
- 新情報の判定 (なければスキップ)
- 既存ファイルとのマージ
- docs/ と skills/ の更新
- git commit & push
- 終わり
### Single File 更新 — なぜ日付でファイルを分割しないか
多くのナレッジベースシステムは `2026-02-14-typescript.md` のように日付でファイルを分割します。しかしこれには問題があります:
- **ファイルが爆発的に増える** — 12トピック × 365日 = 4,380ファイル/年
- **最新情報がどこにあるか分からない** — 全ファイルを横断検索が必要
- **古い情報が残り続ける** — 情報のアップデートが追跡困難
このシステムでは **1トピック1ファイルを育て続ける** 方式を採用:
- `docs/frontend/typescript.md` は常に最新のTypeScriptベストプラクティス
- 古い情報は新しい情報で上書き
- **Gitの履歴が完全な変更追跡**として機能する
- ファイル数は常に24個 (12トピック × docs/skills) で固定
---
## トークン使用量の管理
Claude Proプラン内で運用するため、トークン使用量の管理が重要です。
### 最適化戦略
1. **スキップ判定**: 新情報がないトピックは即スキップ
2. **ローテーション**: 使用量が多い場合、曜日ごとに3-4トピックずつ実行
3. **bulk分割**: 初回一括収集は2-3トピックずつ複数セッションに分ける
4. **Curator効率化**: 変更のあったトピックのみ整形
### 記録
`metadata/collection-log.json` に各セッションの実行結果を記録:
```json
{
"date": "2026-02-14",
"mode": "bulk",
"topics_updated": ["typescript", "java", ...],
"topics_skipped": [],
"notes": "初回一括収集。全12トピック"
}
トークン使用量を抑えるように指示はしていたんだけども。やはりエージェント(選定技術)が多すぎる。
このあたりをもっと抑えられるように調整が必要かもしれない。
なにかアドバイスがあればいただけると大変助かります。
追記
前回実行した日時以降の記事を検索させるように変更
実際に収集されたドキュメント例
TypeScript — ベストプラクティスの一例
satisfies 演算子で型推論と型制約を両立
type ColorMap = Record<string, string | number>;
// satisfies: 型制約を満たしつつ、推論されたリテラル型を保持
const colors = {
red: "#ff0000",
green: 0x00ff00,
} satisfies ColorMap;
colors.red.toUpperCase(); // OK — string 型として推論される
AI向けスキルファイルでの表現
### satisfies 演算子
(コード例)
USE WHEN: 型制約を満たしつつ、推論されたリテラル型を保持したい場合。
このように、同じ知識が「人間が理解しやすい形」と「AIが参照しやすい形」の2つに同時変換されます。
収集対象技術 (12トピック)
| カテゴリ | トピック | 主なカバー範囲 |
|---|---|---|
| Frontend | TypeScript | 型安全パターン, satisfies, Branded Types, Zod |
| Frontend | React / Next.js | RSC, Server Actions, Suspense, 状態管理 |
| Backend | Java | Record, Sealed Classes, Virtual Threads, Optional |
| Backend | Spring Boot | Security, JPA最適化, Native Image, テスト戦略 |
| Mobile | Flutter / Dart | Riverpod, Widget設計, Dart 3+, GoRouter |
| Cloud | AWS | IAM, Lambda, DynamoDB, コスト最適化, CDK |
| DevOps | CI/CD & GitHub Actions | パイプライン設計, デプロイ戦略, セキュリティ |
| DevOps | Docker & IaC | マルチステージビルド, Terraform, CDK |
| Security | Webセキュリティ & 認証認可 | OWASP, JWT, OAuth2, CORS, CSP |
| Architecture | 設計パターン & API & DB | DDD, REST, SQL最適化, インデックス戦略 |
| AI | プロンプトエンジニアリング | プロンプト設計, RAG, エージェント, MCP |
| Trend | 最新技術トレンド | 月次更新、注目技術・フレームワーク |
今後の展望
Phase 1: ナレッジベースの充実 (現在)
毎日の収集で知識を蓄積し、品質を改善していく段階。
さっき記載したように毎日は厳しいけど、時々回してナレッジを蓄積していきたい。
Phase 2: skills を使ったアプリ構築
蓄積された skills/ ファイルを CLAUDE.md から参照し、AIがコード生成時にベストプラクティスを自動適用するシステムを構築。例えば:
# CLAUDE.md (あるプロジェクトの)
## 参照skills
- @skills/frontend/typescript.skills.md
- @skills/security/security.skills.md
上記のskillsに基づいてコードを生成・レビューしてください。
これはやる。というか主な目的の一つ。
まとめ
「俺だけのナレッジベース」は、以下の設計判断で成り立っています:
- Agent Foundry (コンストラクション) — エージェント生成の標準化
- Collector/Curator 分離 — トークン効率とプロンプト品質の両立
- Dual Output (docs + skills) — 人間とAIの両方が活用できる知識資産
- Single File 更新 — 日付分割を排し、常に最新の1ファイルを維持
- スマホからワンコマンド — Claude Code Web で場所を選ばない運用
技術トレンドの追跡を「AIに任せる」ことで、自分は学ぶことと作ることに集中できる。これが「俺だけのナレッジベース」の目指す姿です。
おわりに
まだ実装段階には入れていませんが、世間で言われている通り便利ですね。ほぼ命令するだけ。
出力されたドキュメントも割とちゃんと勉強になりそうです。
skillsがたまってきたら何か製造させてまた記事にしてみようと思います。![]()
