Claude Code Second BrainをAgrici Danielさんが実演。20プロンプトより先に決めたい委ね方
家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Agrici Danielさんの動画『Claude Code Second Brain: The Full Client Build』を紹介するね。
3行でわかるポイント
- 二十回という数より、目的・境界・停止条件が再現性を作る。
- 公開情報と限定情報を隔離し、出典台帳で後から戻れる形にします。
- 私の母艦でダミー三資料を使った最小検証も行い、七ファイルの基盤を確認しました。
動画制作者・解説者
動画を眺めて終わらせず、あなた自身の仕事へ持ち帰れる一つの仕込みまで落とします。
元動画
「20 prompts and two days」——Claude Code Second BrainをAgrici Danielさんに学ぶ
「Everything here was done by the way with a total of maybe 20 prompts. 20 prompts and two days guys.」
Agrici Danielさん — 3:34〜
この一言は強いです。二十回ほどのプロンプトと二日間で、会社のマーケティング情報を一つのVaultへまとめた。画面にはレポート、商品情報、キーワード、被リンク、ロードマップまで並びます。ただし、数字だけを真似すると危ない。動画で本当に効いていたのは、長い魔法の呪文ではなく、何を脳に入れ、何を人が確認し、どこで止めるかという設計でした。
今回は本当にAgrici Daniel氏がGitHubで公開しているclaude-obsidian（MIT・無料・登録不要）を取ってきて、AI氣道/分身AI事業の実データ三件——brand-bible.mdの抜粋、週次の6KPIスナップショット、毎朝LIVE配信スケジュール——を投入した。vaultを作ると、index.md・hot.md・log.md・overview.md・出典台帳・claim台帳の七ファイルが本当に生まれます。投入した資料には「revenue: ¥247,240」のような実データがそのまま入った。3ページの生成と台帳更新をtransaction apply一発で書き込み、実行結果は「approval_sha256: 7b3918e1cb94e28398762b489e4845933becd9b5230ed0e30356aebc31e85f65」という承認ハッシュ付きで返ってきます——ハッシュが一致しない限り書き込まれない設計です。lintを流すと「issues_found: 9 / pages_scanned: 7」で、出典への内部リンクが9箇所dangling（未解決）だった。手作業で組んだ分の粗さが機械にちゃんと見つかります。地味な作業だけど、記事の裏取りとしてはちゃんと効いてきます。
実機検証の生録画（無編集・約31秒）。init→capture→ingest transactionまでを実端末でそのまま撮影
私がSecond Brain Mothershipで大事にしているのも、人間とAIの担当を混ぜないこと。ワクワクを見つけるのは人間。カード化や整理はAI。最後に何を届けるかは人間が味見する。全部をAIへ投げるのではなく、得意な工程を渡すから、母艦が物置ではなく動く厨房になります。
料理に例えると、プロンプト数は包丁を入れた回数。回数が多くても、献立と衛生境界が曖昧なら一皿にはなりません。目的、材料、止める条件。この三つを先に決めると、AIは速さだけでなく、戻って確認できる仕事をする。
今日の仕込み：あなたの仕事を一つ選び、AIへ渡す作業、人が持つ判断、停止条件を各一行で書きます。十分以内に三行がそろえば完了です。
「don’t just blindly accept」——計画を先に味見する
「don’t just blindly accept. Definitely check it out and just ensure that everything is set and put.」
Agrici Danielさん — 29:30〜
動画では、Codexが作った計画をそのまま通していません。制作者は、Vaultを一つにするか、納品物をどこまで含めるか、公開ページと限定ページをどう分けるかを画面で確かめています。フルアクセスを渡した場面だけ切り取ると自動化の派手さが目立つけど、その直前には、人間が計画を読む工程が置かれていた。
実際に触ると、claude-obsidianはもっと機械的に計画を味見させます。initやtransactionは、まず変更内容のJSONとハッシュ値だけを吐き出し、そのハッシュを承認として付け直さないと一切書き込まない。今回の実データ投入でも、実行結果は「approval_sha256: 7b3918e1cb94e28398762b489e4845933becd9b5230ed0e30356aebc31e85f65」という値付きで返ってきて、ハッシュが一致しない限りvaultは変わりません。読んでから確定するまで、AIの気分では動けない仕組みになっています。
AIは外から別人格を貼り付けるものではなく、本人から生やす拡張装置。鏡、実行役、記録役など役割は変わっても、判断の根は本人に残ります。だから計画の味見は、AIを疑う儀式ではありません。自分から生えた仕事になっているかを確かめる工程。
ここを省くと、速いけれど戻れない仕事になります。計画を読む時間は遠回りに見えます。しかし、後で一千ファイルを直すより、最初の一枚で境界を直す方が軽い。セカンドブレインの価値は、量ではなく、判断の履歴が残ることです。
今日の仕込み：次にAIへ渡す大きな仕事で、実行前に計画だけ出させる。五分で読み、削除・公開・認証のどれかが含まれたら人へ戻す、と明記できれば完了です。
「capture and quarantine」——公開情報と限定情報を混ぜない
「capture and quarantine. So archive them fully but isolate them as an exposure security review rather than mixing them with customer SEO pages.」
Agrici Danielさん — 27:22〜
この章が、動画でいちばん実務的でした。見つけた情報を捨てるか、全部同じ棚へ入れるか。その二択ではありません。保持はする。でも公開向けSEOページとは混ぜない。隔離して、セキュリティレビューの対象にする。情報を増やすより先に、混ぜない設計を置いています。
実際にclaude-obsidianの中身を見ると、動画にあった「公開棚と鍵付き棚」の物理的な仕切りは、ツール本体の標準機能ではありませんでした。GitHubのREADMEにその機能の記載は無い。ツールが本当にやっているのは、資料をSHA-256でcontent-addressedに保存し、source-ledger.jsonのauthority（primary/secondary等）とreview_status（active/rejected等）で論理的に分類することです。「隔離」という言葉が指す物理フォルダ分けは、Agrici Daniel氏が今回のクライアント案件向けに自分で設計した運用ルールらしい。
私は実家の惣菜屋の厨房で、料理を手伝い、おじいちゃんが作る鶏チャーシューを味見して育った。厨房は、材料を一か所へ山積みにする場所ではありません。生の材料、仕込み済み、提供する皿を分けるから、安心して味見できます。セカンドブレインも同じ。
情報は集めた瞬間に価値になるわけではありません。誰が見てよいか、どこから来たか、次に誰が確かめるかが分かって初めて使えます。保存する勇気と、出さない判断。その両方を持つと、AIは便利な検索箱から、信頼できる仕事場へ変わります。
今日の仕込み：いまの共有フォルダを一つ開き、公開候補と限定情報を二つの場所へ分ける。対象五件だけでよく、移動後に元の場所へ混在がなければ完了です。
「put read only」——最初の接続は小さくする
「put read only because I don’t have access to the current API executive operators recommended execution okay recommended one for sure」
Agrici Danielさん — 28:18〜
動画では、Google Search Consoleなどの書き込み権限を最初から渡していません。公開データと市場APIでベースラインを作り、必要な接続は後に残しています。完成品の派手さとは逆に、入口は小さい。これは慎重さだけでなく、検証可能性を高める設計です。何が公開情報から作られ、何が認証後に追加されたかを分けられます。
今回の検証も外部認証はゼロのままで、GitHubから取ってきたclaude-obsidianをローカルのvaultとして初期化しただけ。三つの実データ（brand-bible抜粋・6KPIスナップショット・LIVEスケジュール）を読み込ませ、source-ledger.jsonへ実際に記録させました。ネットワークへの書き込みは一度も発生していない——README自身も「ネットワークegressは別途明示的な決定」と言い切っています。
私は一本を入魂してから仕組みにし、魂を薄めず量産する考えを大切にしている。最初の一本で残すのは表面の文体ではなく、なぜ、判断軸、価値観、体験です。read-onlyは機能制限ではなく、最初の味を確定するための小鍋だと考えています。
いきなり全部をつなぐと、便利さと同時に原因も見えにくくなる。まず読めるだけ。次に台帳。最後に、人が必要性を判断した接続だけを増やす。この順番なら、動かなかった時も、どの材料で味が変わったのかを戻って確かめられます。
今日の仕込み：新しい連携を一つ選び、最初の権限を閲覧だけにできるか確認する。書き込みが必須なら接続せず、必要理由を一行残した時点で完了です。
「research is being done in parallel」——調査と整理を同じ鍋に入れない
「The research is being done in parallel currently with sub agents for the tasks.」
Agrici Danielさん — 31:47〜
二時間後の画面では、サブエージェントが並列でキーワード調査を進めています。その後、動画ではCodexの調査フェーズからClaudeの整理フェーズへ交代。ここで大事なのは、AIを二つ使ったことじゃないんですよ。集める仕事と、意味のある構造へ整える仕事を分けたこと——それだけ。
私の検証では規模を極端に小さくし、三資料の読み取りと台帳化を分けました。先に元資料を固定し、その後に統合ノートを書き、最後に検証スクリプトで逆引きを確認。小規模でも順番を分けると、要約文がどこから生えたかを失いません。逆に、読みながら勝手に統合すると、後で根拠だけを拾い直すはめになる。
私のCliftonStrengthsでは、IdeationやStrategicなど考える資質が上位で、手を動かす達成欲はそこまで高くない。これは優劣じゃなくて、役割の凸凹です。全体像を描き、道を選ぶ仕事へ集中し、繰り返し作業は委ねる。その設計が、私にとっての委ねるOSです。
料理でも、仕入れ担当と盛り付け担当が同時に鍋へ手を入れたら混乱します。調査は材料を集める。整理は献立へ変える。検証は味を見る。工程を分けると、AIを増やさなくても仕事の衝突が減ります。複数AIは目的ではなく、工程分離を見える形にする道具。
今日の仕込み：次の調査で、収集ファイルと最終ノートの保存先を分けます。出典一件から要約一段落を逆引きでき、混在ファイルがゼロなら完了です。
「your business has right now a voice」——会社の声はファイル数では生まれない
「this is basically you can say you’re talking to your business everyone so this is your your business has right now a voice」
Agrici Danielさん — 50:10〜
動画の終盤、制作者は会社に声ができたと表現します。多数のノートとスクリーンショットがつながり、事業へ質問できる状態。ただ、声はファイル数から自動で生まれるわけじゃないんですよ。出典、境界、更新日、判断者がつながって初めて、会社の過去と現在を混ぜずに答えられます。
私のミニVaultは七ファイルしかない。それでも、会社概要、目標、限定ルールの出どころを追えます。これは会話AIとしては小さすぎるけど、基盤の最小条件を確かめるには十分だった。一方で、実クライアント規模の自動収集、外部API接続、長期更新は今回試していません——記事末の免責にまとめ、動画の結果と私の検証範囲を混ぜません。
私にとって発信は、完成した自分を見せる出口だけではなく、自分を見つける鏡です。ブログやノートを読み返し、違和感なく腑に落ちるかを見る。会社の声も同じで、AIが雄弁に答えることより、本人が読んで『これは私たちの判断だ』と戻れることが大切です。
作って終わりの脳は、すぐ古い冷蔵庫になる。いつ入れた材料か分からず、捨てる判断もできません。更新のたびに出典と判断を一行残す。月に一度、古い前提を味見する。その小さな循環が、会社の声を大きくするのではなく、濁らせない仕組みになります。
今日の仕込み：既存の社内ノート一枚に、出典、更新日、最終判断者の三項目を足します。三つが埋まり、古い前提が一つ見つかれば完了。
最小構成を、自分の現場へ移す手順
ここまでを実務へ移す時は、動画と同じ規模から始めない方が安全。しかもね、最初に決めるのは集める資料の数じゃなくて、今回答えたい問い。たとえば「今月の重点商品を、新人が説明できる状態にする」のように、一つの利用場面へ絞ります。問いが曖昧なまま資料を増やすと、AIはきれいな要約を返しても、誰が何に使うのかは決まりません。問いを一文に固定し、その問いへ直接関係する三〜五件だけを選ぶ。
次に、原本、作業中、公開候補の三つへ置き場所を分けます。原本は変更せず、作業中にはAIの要約や仮説を置き、公開候補には人が味見した内容だけを移す。この三層があれば、AIが誤った時も原本へ戻れる――限定情報は別の隔離先へ置き、公開候補と同じ検索対象へ混ぜない。情報を消すのではなく、扱いを変える設計。
出典台帳には、元ファイル、採用先、確認日、確認者を残します。大げさなデータベースは要りません。最初は四列の一覧で十分。答えの文章から元資料へ戻れない時は、AIの表現が自然でも採用しません。私が今回確かめたのも、賢い回答の質ではなく、この逆引きが三資料すべてで成立するかでした。
その後で、AIへ任せる工程を一つだけ増やす。読み取り、分類、重複整理、下書き、更新候補の検出……いずれも一度に渡さず、入出力と停止条件を一つずつ決めます。削除、公開、認証を伴う操作は人へ戻す。成功条件だけでなく、止まる条件を書いておくと、便利さが増えても境界が薄まらない。
最後は、週に一度の味見。古くなった前提、出典のない文章、限定情報の混入、誰も使っていないノートを確認します。全部を磨く必要はありません。今週使った一枚だけでも、根拠と更新日を確かめる。会社のセカンドブレインは、一度の大量生成で完成する作品ではなく、材料を入れ替えながら味を守る厨房です。
この順番なら、プロンプトの巧拙に依存しすぎない。問い、置き場所、出典、権限、味見という五つの仕込みが、人間とAIの役割を支えます。動画の二日間という速さを目標にするより、翌週も根拠へ戻れることを最初の合格にしてください。
運用を止めないための確認票
最初の確認は、答えの正しさより材料の鮮度。正直、ここを飛ばす人が一番多いんです。元資料に更新日があるか、現在も有効か、誰が責任を持つ情報かを見ます。日付がない資料は、古いと決めつけず、未確認として印を付ける。確信を装わない——それが、次の確認を呼び戻すコツです。
二つ目は、同じ事実が複数の資料で食い違っていないか。いやー、これ地味に多いんですよ。AIに多数決をさせず、差分を並べて人へ戻します。会社の方針は、新しい文書が常に正しいとは限らない。採用した理由まで台帳へ一行残すと、後から判断を更新できます。
三つ目は、検索できることと、使ってよいことを分ける確認。見つかる情報でも、顧客向けページへ出してよいとは限りません。ぶっちゃけ、ここを混同すると事故る。閲覧範囲、引用範囲、公開範囲を別々に持ちます。迷った材料は隔離し、人が扱いを決めるまで料理へ入れません。
四つ目は、AIの文章へ新しい因果が足されていないか。元資料にない理由、感情、頻度、成果……こういうのが自然な文章として混じることがあります。読みやすさだけで採用せず、事実、解釈、提案を分けて読みます。出典へ戻れない断定は削るか、仮説として明示する。
五つ目は、使われた記録。誰も開かないノートを増やすより、一つの会議や一件の問い合わせで役立ったかを残します。利用場面が分かれば、次に足す材料も決まります。で、セカンドブレインの成長を見るのはファイル数じゃなくて、判断へ戻れた回数。
この確認票は、AIを遅くするためのものではありません。人が持つ味見を短く、具体的にするための仕込みです。毎回すべてを調べず、変更された材料だけを見る。小さな循環を守れば、便利さを増やしながら、会社の声を本人たちの手元へ残せます。
運用開始日は、完成日ではなく最初の検証日。三日後に同じ問いを投げ、答えの根拠が同じ資料へ戻るかを確かめます。更新された資料があれば、古い答えを黙って上書きせず、差分と採用理由を残します。誰かが迷った箇所は、プロンプトを長くする前に、置き場所や名前を直す。人が探せない構造は、AIにも長く維持できません。
小さな会社なら、管理者を増やす必要はありません。週に一人が一枚を味見し、次の人へ気づきを渡すだけでも循環する。重要なのは、全部を知る人を作ることではなく、分からない時にどこへ戻るかを全員が知ることです。戻り道があれば、AIの速度を怖がらず、必要な工程だけを委ねられます。
ひろくんコラム ― 厨房を一人で回さない
大きなセカンドブレインを見ると、私の中の『もっと良くしたい』が動きます。資料を増やし、機能を足し、気づけば厨房の全部の鍋を自分で見ようとする。Maximizerの強みが、抱え込みOSへ戻る瞬間です。
実家の惣菜屋の厨房を思い出すと、一皿は一人の手だけでできていません。仕入れ、下ごしらえ、火入れ、盛り付け。役割が分かれ、最後に味見がある。AIの役割も、一人の万能料理人にするより、工程ごとに置いた方が分かりやすいです。
私が持つべきなのは、全部の包丁ではありません。何を届けたいか、誰に出してよいか、今の自分の味か。この三つです。残りは委ねても、味見まで手放す必要はない。むしろ、手を離すから舌と身体の感覚へ戻れます。
今回のミニVaultは豪華ではありません。けれど、三つの材料がどの皿へ入ったかは追える。失敗したのは、最初にREADMEへ書いたsourcesコピーを実際には作らなかったこと。検証項目を必要七ファイルへ絞り直し、主張も『逆引きと隔離を確認した』までに留めました。
抱え込みOSから委ねるOSへ移るとは、厨房を無人にすることではありません。自分しか出せない味を守るため、下ごしらえを渡すこと。分身AIはそのための道具で、本人の外から人格を貼るものではありません。分身AIの考え方も、ここから始まります。
よくある質問（FAQ）
会社のセカンドブレインは何から始めればいいですか？
まず三〜五件のダミーまたは公開資料だけで、出典台帳と統合ノートを作ります。認証接続や自動更新は後です。
Claude Codeへフルアクセスを渡す必要がありますか？
最小検証では不要です。閲覧範囲、停止条件、公開境界を先に決め、必要性が確認できた権限だけ追加します。
動画の二十プロンプトをそのまま使えば再現できますか？
動画では独自ライブラリや市場APIも使われています。回数だけでは再現できないため、目的・素材・権限・完了条件を自分の事業に合わせて設計します。
まとめ
Agrici Danielさんの実演で価値があったのは、巨大な成果物だけではありません。計画を読む、限定情報を隔離する、最初はread-onlyにする、調査と整理を分ける。その地味な境界が、会社の声を濁らせない土台でした。
私の最小検証では、ダミー三資料から七ファイルのVaultを作り、出典逆引きと隔離を確認した。実クライアント規模の自動収集は未検証です。だからこそ、あなたも最初は小さく、戻れる形から始めてください。
元動画の発言は自動文字起こしと構造化教材を照合し、英語の逐語引用は文字起こし表記のまま掲載した。動画内の規模・所要時間・成果はAgrici Danielさんの実演に帰属します。今回の独自検証は実在OSS「claude-obsidian」（AgriciDaniel/claude-obsidian・MIT）本体をGitHubから取得し、AI氣道/分身AI事業の実データ三件（brand-bible.md抜粋・週次6KPIスナップショット・毎朝LIVE配信スケジュール）で行った。録画・スクショ・公式README突合を伴う実機検証です。未検証・訂正した点: ①「公開棚と鍵付き棚」の物理フォルダ分離はツール本体の標準機能ではなく、動画内でAgrici Daniel氏が独自に設計した運用らしいと判明 ②read-onlyのデフォルト強制もツール機能ではなく、動画内の外部サービス（Google Search Console等）側の権限設定 ③実際のClaude Codeセッション（`/claude-obsidian:wiki-ingest`スラッシュコマンド）は起動しておらず、凛ちゃんがSKILL.mdの契約を手で再現してportable core（transaction inspect/apply）へ渡す形で検証した ④Obsidianアプリ本体のGraph view等ビジュアル確認は未実施 ⑤「20プロンプトで完成」の再現性は検証していません（今回は3資料の最小構成）。
