このガイドで分かること
AI Buildersは、情報の収集・整理・記事化を「raw/ → wiki/ → product」という3フォルダの流れで運営しています。これはAndrej Karpathyが提唱し、Xで1.2Mビューを記録した設計と同じ構造ですが、私たちが実際に1ヶ月以上運用して得た一次体験として、うまくいった点・詰まった点を正直に書きます。
読み終えると：AIに「毎回同じことを説明する」無駄がなくなり、情報収集から記事化まで流れる仕組みの全体像が分かります。所要時間：読了20分。情報は2026年6月時点です。
目次
- なぜ「second brain」が必要か——情報が腐る前に使う
- 3フォルダ設計（raw / wiki / product）
- raw/：一次情報を「そのまま」放り込む
- wiki/：裏取りして「使える知識」に蒸留する
- product：記事化して世に出す
- CLAUDE.mdで「毎回説明しない」設計
- Skillで型を固める（実際のAI Builders設計）
- 回すほど賢くなる改善ループ
- 使っているツール一覧
- 正直な限界と注意点
- セットアップチェックリスト
- FAQ
なぜ「second brain」が必要か——情報が腐る前に使う
AIで発信や副業を始めると、情報収集だけが増えて記事にならない問題が起きます。「あの情報どこに保存したっけ」「AIに先週も同じことを説明した」「調べたのに使わずに埋もれた」——これらは全て情報管理の設計が無いことが原因です。
解決策は「電子的なゴミ捨て場」を「使える脳」に変える設計です。Xで調査したところ、これを実践している人たちに共通するのが「入口→整理→出口」の3段構造でした。AI Buildersも同じ構造を採用し、実際に機能することを確認しています。
3フォルダ設計（raw / wiki / product）
| フォルダ | 役割 | 情報の状態 | 対応工程（CODE） |
|---|---|---|---|
| raw/ | 一次情報の収集・保管 | 整理前・未検証OK | Capture（集める） |
| wiki/ | 裏取り・要約・蒸留 | 検証済み・evergreen | Organize / Distill（磨く） |
| product | 公開記事・成果物 | 読者向けに再構成 | Express（表現する） |
CODE（Capture / Organize / Distill / Express）は情報管理の定番フレームワークです。私たちはこれをそのままフォルダ名にしています（詳しくはAIで情報収集→記事化を仕組み化するを参照）。
重要なのは「rawはそのまま放り込んでいい」こと。完璧に整理してから保存しようとすると何も保存できなくなります。
raw/：一次情報を「そのまま」放り込む
AI Buildersのraw/には、以下が入っています（実際のファイル一覧はリポジトリで公開予定）：
- YouTube収集：NotebookLMにYouTubeのURLを入れて要約・文字起こし（例: raw/hp-lp-craft.md）
- X収集：hermesエージェント（Grok/xAI）でXポストをURLベースで取得（例: raw/x-collect-2026-06-07-*.md）
- 体験ログ：作業中に詰まったこと・発見・一次体験を逐次追記（raw/LOG.md）
- ツール調査：公式ドキュメント・海外ブログの要点（例: raw/v0.md, raw/ai-video-tools.md）
各ファイルの先頭には必ず「収集日 / 出典URL / 検証ステータス（✅/🟡/⚠️）」を書きます。これがないと後で「この情報いつのもの？」が分からなくなります。
実際に詰まったこと：最初は「完璧なノートを作ろう」として何も書けなくなりました。今は「3行のメモ＋出典URL」だけでも入れる方針に変えて、rawの更新頻度が上がりました。
wiki/：裏取りして「使える知識」に蒸留する
rawの情報をそのまま記事に使うのは危険です（誤情報・時点ズレ・著作権）。wiki/の役割はrawを「裏取り済みの事実」に磨くことです。
wiki化で意識していること：
- evergreen（時点によらない）な知識を中心に：「2026年〇〇の価格」はrawに、「LPの構成原則」はwikiに。
- 1ファイル1トピック（atomic）：大きすぎるwikiはAIが参照しにくい。適切な粒度で分割。
- [[wikilink]]でつなぐ：関連ノートを相互リンクして知識グラフを作る。
- AIが読む前提で書く：見出し・箇条書き・表を使い、AIがコンテキストとして読み込みやすい構造に。
実際のwikiには: article-standard.md（記事の型）/ quality-rubric.md（評価基準）/ operating-system.md（運営の設計）/ second-brain-design.md（今回新設）などがあります。
Xで1.2Mビューを記録した@obsidianstudio9の設計がこの思想と完全に一致しています——「raw/wiki/outputs」の3フォルダ設計です。私たちが独立に同じ構造に辿り着いたことで、この設計の再現性を確認できました。
product：記事化して世に出す
AI Buildersでは「product」はdata/articles.tsの各記事です。wiki/の素材を使って、読者向けに再構成します。重要なのは：
- raw直コピーは禁止：必ずwiki経由で裏取りしてから記事にする。
- 一次体験を加える：wikiの情報だけでなく、「実際にやってみたらこうなった」という体験談を織り込む（これが質ルーブリックの「独自性・E-E-A-T」に直結します）。
- 内部リンクで堀をつなぐ：各記事からpillar・有料パッケージ・プランへ送客する。
CLAUDE.mdで「毎回説明しない」設計
Claude CodeはセッションをまたいでLLMのコンテキストがリセットされます。つまり「前回話したこと」は毎回ゼロになります。これを解決するのがCLAUDE.mdです。
AI BuildersのCLAUDE.mdに書いていること（実際の内容の一部）：
- このプロジェクトが何か（AI副業メディア・楔戦略・収益モデル）
- 読者の定義（未経験会社員・出口は「作って納品」）
- 禁止事項（誇大表現・raw直コピー・slug分岐をapp/に書く等）
- 作業のルール（audit実行・export:md実行・LOGへの記録）
これをプロジェクトルートに置くだけで、次のセッションでClaude Codeが「前提を全て知った状態」でスタートします。「AIに同じことを何度も説明している」なら、まずCLAUDE.mdを作ることから始めてください。
Skillで型を固める（実際のAI Builders設計）
CLAUDE.mdが「プロジェクトの前提」なら、Skillは「作業の型」です。AI BuildersはClaude Code Skill（.claude/skills/）として2つを設置しています：
- ai-builders-article：記事執筆のhouse style・「作れる基準」・内部リンク規約・よくある事故（バッククォート禁止等）・完了条件。
- ai-builders-ops：サイト運営・データ変更・ビルド・鮮度メンテの安全手順。
Skillは「必要な時だけロードされる」ため、毎回全文をプロンプトに貼り付けるよりトークン効率が高いです。記事執筆の品質も一定に保てます。
実際の効果：Skillを入れる前は「バッククォートが本文に混入してTypeScriptエラー」という事故が何度かありました。Skillに「本文に`を入れない」と明記してから、エラーが0になりました。
回すほど賢くなる改善ループ
この仕組みの最大の価値は「回すほど質が上がる」ことです。
- 計測：
npm run audit（リンク切れ検出）＋node scripts/article-metrics.mjs（体裁スコア0-100） - 質判定：別モデル（Sonnet）に質ルーブリックで採点させる（著者と分離してself-enhancement biasを防ぐ）
- 読者の声：記事下部のフィードバックフォーム（👍/🙏）→
npm run feedbackで集計 - 改善：批評→追加調査→改稿（Reflexion）→再計測
- 還元：学びをSkill・quality-rubric.md（バージョン管理）に反映 → 次回からその学びを読んで書く
実際にこのループを1周して分かったこと：体裁スコア（82点）と質スコア（約60点）は別物です。長くて見出しが多くても、「実プロンプト＋実出力がない」「出典が無い断定がある」と質は低いまま。ループがないと体裁だけ上がって中身が空になります。
使っているツール一覧
| ツール | 用途 | コスト |
|---|---|---|
| NotebookLM | YouTube/PDFの収集・要約（Capture工程） | 無料 |
| hermes（Grok/xAI） | XポストのURLベース収集（Capture工程） | X Premium連動 |
| Claude Code | wiki化・記事執筆・サイト実装・Skill活用 | Pro 約$20/月 |
| Obsidian | raw/wiki/をMarkdownで管理・知識グラフ化 | 無料（本体） |
| Sonnet（サブエージェント） | 下書き・wiki蒸留・質judge（Claude tokenを節約） | Claude Pro内 |
全て合わせても月数千円〜$20前後で動いています。Obsidianは無料でMarkdownファイルを管理するだけなので、このリポジトリをObsidianで開けばそのままwiki/raw/がVaultになります（npm run export:mdで記事もMarkdownに出力可能）。
正直な限界と注意点
- 「実プロンプト＋実出力」が少ない：質judgeに指摘されました。現在改善中です。AIが生成した「それらしい出力例」を「実際の出力」と見せることはしません（捏造になるため）。本物の出力は今後の作例制作で随時追加します。
- 運営者の受注実績がまだない：E-E-A-Tの「Experience」として、LP受注実績を作ることが今後の課題です。
- Vellum・n8n等はまだ導入していない：wiki化した知識はありますが、実運用していないツールは「実践済み」とは書きません。
- 副業収入の保証はしない：情報管理を仕組み化すると発信の質と量は上がりますが、それが収益に直結するかは取り組みと市場次第です。
セットアップチェックリスト
- ☐ raw/ wiki/ の2フォルダを作り、1件だけ情報を入れてみた
- ☐ raw/の先頭に「収集日・出典URL・検証ステータス」を書く習慣をつけた
- ☐ CLAUDE.mdをプロジェクトルートに作り、プロジェクトの前提を書いた
- ☐ wiki化の練習：rawの1ファイルをevergreen形式に書き直してみた
- ☐ 1本の記事・投稿に「体験談（自分がやってみたら〇〇だった）」を1行加えた
- ☐ 情報収集から記事化まで1回通しで回してみた
FAQ
Obsidianは必須ですか？
必須ではありません。raw/ wiki/ はただのMarkdownフォルダなので、VS CodeやNotion等でも管理できます。ただしObsidianは[[wikilink]]とグラフビューで知識のつながりが見えやすく、Claude Codeも直接読み書きできるためお勧めです。
CLAUDE.mdは何文字くらい書けばいい？
最初は200〜500文字で十分です。「プロジェクトの目的・禁止事項・作業ルール」の3点を書くだけで、AIへの毎回の説明が激減します。使いながら気づいたことを足していくスタイルが続けやすいです。
Skillとは何ですか？
Claude Code専用の「再利用できる指示書」です。.claude/skills/フォルダにMarkdownファイルを置くと、関連するタスクのときに自動で読み込まれます（毎回貼り付け不要）。Claude Codeのプラグインマーケットにも既製Skillがあります。
この設計はどんな人に向きますか？
「情報収集はしているが記事にならない」「AIに毎回同じことを説明している」「発信の仕組みを作りたいが方法が分からない」という人に向きます。LP/HP制作を副業にするなら、この情報管理の仕組みが記事・X・提案書の生産性を支えます（詳しくは1日で作るLP制作・LP/HP制作プランへ）。
情報はいつのもの？
2026年6月時点です。Claude Code・NotebookLM・Obsidianの機能・料金は変わるので、最新は各公式で確認してください。
まとめ：次の一歩
raw→wiki→productの3フォルダ、CLAUDE.md、Skill、改善ループ——これが私たちの実際の仕組みです。完璧に揃えてから始める必要はありません。まずraw/フォルダを1つ作り、今日調べたことを3行でいいので放り込んでください。それが第一歩です。
情報管理をもっと広く学ぶならAIで情報収集→記事化を仕組み化する（second brain × Claudeモデル使い分け）へ。実際に作って納品するなら1日で作るLP制作とv0の使い方をあわせてどうぞ。
参考: X @obsidianstudio9（ビュー1.2M・2026-06）、@obsidianotaku（ビュー103K・2026-06）、@_0xpainn（ビュー30K・2026-06）。数値は収集時点。情報は2026年6月時点のものです。