AIの記憶のしくみと、
第二の脳のつくり方

第1章

記憶の正体 — ただのテキストファイル

Claude Codeの「メモリ（記憶）」は、特別な仕組みでも、AIの脳内でもありません。PCのフォルダに入った、ただの文章ファイルです。だから自分の目で開けるし、直せるし、消せます。

まず「.md」とは何か

ファイル名の末尾につく「種類ラベル」（拡張子）です。見慣れたものと同じ仕組み：

フォルダとファイルの関係（最重要の基礎）

フォルダ＝入れ物（箱）、ファイル＝中身そのもの。ファイルの中にファイルは入れられません。記憶フォルダの中身はこうなっています：

図1｜フォルダの中身 — メモの紙が並んでいるだけ

図2｜そのうち1枚（MEMORY.md）の中身 — ただの箇条書き

図2の各行はただの文字です。ファイル名を「文字として」書いてあるだけで、ファイル本体は図1のとおり隣に並んでいます。

「MEMORY.md」だけは特別な1枚

62枚のメモは全部が対等ではありません。「MEMORY.md」という名前のファイルだけは特別で、Claude Codeにはチャットを始めるたびに、この1枚を必ず最初に読むという決まりがあります。中身は図2のとおり「どのメモに何が書いてあるか」の一覧＝受付案内（索引）。

AIはまずこの案内を読み、今の話題に関係するメモ（.md）だけを本棚（memoryフォルダ）から選んで開きます。残りの何十枚は、案内を見て必要になったときだけ開かれる——つまりMEMORY.mdは「どのファイルを読むべきかを教えるメモ」です。

読み込みは「二段構え」— だから燃費がいい

AIは新しいチャットを始めるたびに目次（索引）だけを自動で読み、話題に関係するメモの本文だけをその都度開きます。

この設計のおかげで、メモが増えても毎回のコスト（トークン＝AIの読み書き量）はほぼ一定に保てます。ただし放っておくと劣化するので、運用ルールは3つ：

第2章

2種類の記録 — AIの手帳と、現場の作業ファイル

「メモリ」と「各プロジェクトフォルダの中の記録」は役割がまったく違います。

実例：テンプレ販売の場合、メモリ側には「商品化が進行中。詳細はリポジトリのPRODUCT_PLAN.mdを必ず確認」と書いてあります。つまりメモリは場所を指す付箋で、本体は現場（プロジェクトフォルダ）にある。新しいチャットで「あの件の続きやろう」と言われたAIは、まず手帳（付箋）で思い出し、現場のファイル（本体）を開いて作業する——という流れです。

※もう1つ「CLAUDE.md」という記録もあります。これはあなたが書くルール（職場に貼る就業規則のようなもの）。メモリはAIが書く記録。どちらもただの.mdです。CLAUDE.mdの置き場所は2段——全案件で効かせたい普遍ルールは`~/.claude/CLAUDE.md`（＝コーポレートの社則・どこでも効く）、その案件だけのルールは各プロジェクトの`CLAUDE.md`（＝現場ルール）。一部だけ共有したい時は各プロジェクトから@importで共通ファイルを読み込む。なおCLAUDE.mdが長くなったら（目安200行超）、詳細は別ファイルに出して本体には「◯◯の時は△△.mdを読む」と一言リンクだけ書くと薄く保てる（＝MEMORY.mdの索引と同じ考え方・必要な時だけ読まれる）。@importは共有・重複排除用で、中身は毎回読み込まれる点だけ別物。なお@importはClaude Code専用の記法（他のAIでは効かずただの文字列）。Codex等でも同じリポを使うなら、①の"普通の文章ポインタ"の方がツール非依存で安全。

第3章

置き場所の設計 — 作業場と道具箱を分ける

記憶フォルダは C:\dev\（作業場）の中ではなく、C:\Users\<ユーザー名>\.claude\ にあります。これは意図的な分離です。

なぜ全部 dev の下にせず、.claude に分けるのか（シンプルに）

一言でいうと 「コーポレート（会社全体の共通資産・社則）と、各事業部（現場ごとの実務）を分ける」のと同じです。

分ける理由は3つ：

1. そもそもClaude Codeがそういう作り：~/.claude はClaude自身の「家」で、どのフォルダから起動しても必ず最初に読む。だから"どこでも効いてほしい共通のもの"の指定席がここ。
2. 巻き添え事故を防ぐ：プロジェクトは増減・引っ越しする。記憶をその中に置くと消した瞬間に頭脳ごと消える。分ければ作業場をいくら片付けても頭脳は無傷。
3. 効く範囲（スコープ）で仕分けできる：~/.claude＝全案件に効く（日本語で返答・.env禁止）／各プロジェクト＝その案件だけ。置き場所を変えるだけで"全体ルール"と"案件ルール"が自然に分かれる。

混ぜると事故ります：「プロジェクトごと消したらAIの記憶も消えた」「制作物のリポジトリにAIの設定が紛れ込んだ」。成果物と道具は別の場所——これが原則です。

第4章

ノートを1冊にする — 記憶の一本化

仕様：記憶は「起動フォルダごと」に別ノート

Claude Codeは「どのフォルダで起動したか」を仕事の単位とみなし、フォルダごとに別々の記憶ノートを作ります。起動フォルダのパスがそのままノートの名前になります：

エンジニアには合理的です（A社案件の記憶をB社案件に持ち込まない）。しかし個人が自分の事業で使うと、起動フォルダは日によって変わるので——「昨日教えたのに、今日は忘れてる」が起きます。忘れたのではなく、別のノートに書いてあるだけ。

解決策：設定1行で「ノートは1冊」

C:\Users\<ユーザー名>\.claude\settings.json に1行足すだけです：

意味は「どこで起動しても、記憶はこの1か所に書け」。実際、私たちの環境でも記憶が3か所に散らばりかけたため、この設定で一本化しました。すでに散らばっている場合は、各フォルダの.mdを集約先に移せばOK（AIに頼めばやってくれます）。

第5章

消えない仕組み — GitHubバックアップ

原則：「PCの外にコピーが1つ」あれば防災は成立

「PCが壊れたら終わる」問題の解決策は、場所を変えることではなくPCの外に複製を持つこと。その置き場としてGitHub（Privateリポジトリ・無料）を使います。記憶フォルダ自体がGitの管理下にあり、「プッシュ」すればGitHubに写しが送られます。

GitHubが同期サービスより強い理由：履歴

同期（Obsidian SyncやiCloud）は「今の状態」を写すだけなので、誤削除も同期されます。GitHubは履歴が全部残るので、3年前の状態にも戻れる。だから掃除（メモの削除）を気軽にやれる——消しても戻せるからです。

「ロックイン」を避ける＝乗り換え自由でいる

ロックインとは、データがそのサービス専用の形になって離れられなくなること。数百ページ貯めた後では引っ越しが大仕事になり、値上げや仕様変更に従うしかない立場になります。ChatGPTやClaudeアプリ内蔵の「メモリ機能」も同じで、中身を持ち出せないので正本にしてはいけません。

逆にMarkdownの記憶は他のAIにもそのまま引き継げます。たとえばCodexなら設定ファイル（AGENTS.md）に「最初にこの索引を読め」と1行書くだけ。中身（資産）は持ち運べて、仕組み（自動読み込み）だけツールごとに1行設定する——これが「正本はMarkdown」の実利です。

第6章

保存先の使い分け地図

判定は1問：「AIに管理・編集までさせたいか」

直感的な言い換え：「これは資料か、自分の脳の一部か」。資料はDrive、脳の一部はGitHubへ。今Driveで回っているもの（議事録など）は引っ越し不要です——AIはDriveも読めるので。

「GitHubを Drive 代わりにできる？」— 大物はNG

GitHubはテキストなら実質無制限。だから「動画やデザインもここに置けば？」と思いがちですが、大きいファイルには向きません。理由は仕組みにあります。

つまりテキストの"脳"はGitHub、大物の"倉庫"はDrive。1つにまとめようとせず、役割で分けるのが正解です。

100MB上限の目安：Markdownメモ＝数千〜数万本／スクショPNG＝30〜200枚／スライドPDF＝5〜50個／音声1分＝約1MB／動画は1分ほどで上限超え（文字は無限・画像OK・音声ギリギリ・動画は一発アウト）。※「1GB推奨」等は1リポジトリごとで、アカウント全体に上限はなく、リポジトリは無制限に作れる。なお公開/非公開は選べ、メモは必ずPrivate（Public＝オープンソースは"世界に公開する"意図的な選択で、企業やSaaSの製品コードは大多数がPrivate）。

NotebookLMとの仕組みの違い（RAGとまるごと読み）

メモ数千ファイル程度まではClaude Code方式で十分。個人の第二の脳の規模でRAGの出番はまずありません。

表・数字データはどうする？

Obsidianの正しい位置づけ

Obsidianは「保存場所」ではなく閲覧・執筆アプリです。GitHub＝倉庫（保管と履歴）、Obsidian＝机（同じフォルダを快適に読み書きするメガネ）——競合せず、併用できます。AIに読み書きさせるだけなら不要。「自分の目で眺めたい・つながりを地図で見たい」と思った日に、今のフォルダを指定して入れるだけです。

大物を"脳"につなぐ — 栞（しおり）テク

PDF・パワポ・エクセル・動画は、AIが中身を読みにくく、検索にも引っかからず、リンクも付けられない——せっかくの資料が"脳の外"に取り残されます。そこで、その資料1つにつきMarkdownを1枚だけ添える。中身は「要約＋タグ＋元ファイルへのリンク」。これだけ。

位置づけは「大物はDriveに置き、GitHubには栞（テキストの目印）だけ残す」——上の"テキストの脳＝GitHub／大物＝Drive"の橋渡しです。環境をいじる必要はゼロ、遡って全部やる必要もない。「AIに見つけてほしい大事な資料が出てきた時だけ」1枚添えるで十分。

さらに上級（必要になったら足す2つ）

土台（GitHub＋Markdown＋索引）だけで第二の脳は十分に成立します。以下はFOMOで積み上げないのがプロの運用——複雑さと事故リスクを足すからです。

今の数十〜数百メモの規模では、手入れした索引（MEMORY.md）方式の方がむしろ制御が効いて優秀。足すなら栞テクだけが"今すぐ"価値が高い（環境変更ゼロ）。

第7章

毎日の運用 — 第二の脳を育てる

入力・保存・転記の役割分担

頻度は流量次第。週1の定期作業は流量が増えてからで、最初は「溜まったなと思ったとき」のトリガー式で十分です。仕組みを作りすぎないこと。

「ほぼ放置」でも回る理由 — 覚えておくことをゼロにする

掃除・転記・バックアップを「あなたが覚えておく作業」にしないのがコツ。中でもバックアップは"手でプッシュし忘れる"のが唯一にして最大の穴です。ここを自動化すれば、第二の脳は本当に放置で守られます。土台は「AIに読ませられる開いた形式で貯め続ける習慣」——道具選びより、この習慣が本体です。

バックアップの自動化 — OSのスケジューラに任せる

やることは「メモに変更があれば自動でGitHubへ送る」だけ。これをOSの定期実行機能（Windowsはタスクスケジューラ／Macはlaunchd／Linuxはcron）に、小さなスクリプトを登録して任せます。肝はアプリを1つも開いていなくてもOSが実行すること。ノートアプリ（Obsidian等）のプラグインは"そのアプリを開いている間だけ"なので、放置には向きません。

OS cron と AI cron — 「判断が要るか」で使い分ける

定期実行には2種類あり、混同しがちです。線引きはシンプル：

だからバックアップはOSのスケジューラ、AIニュース日次ダイジェストのような頭を使う自動化はAIのcron。同じ理由でコードは手動コミット（意味ある単位で・壊れた状態を上げない）／メモはタイマー自動——この分け方は「自動対象のフォルダにメモだけを入れ、コードは入れない」だけで実現します。

※この仕組みづくり自体が、講座の最初の課題としても機能します。「作りたいものがまだ無い」人でも、全員に確実に資産が残り、以降どのメモアプリを使っていても「いつでもClaude Codeで呼び出せる状態」になるからです。

第8章

実例 — 私のPCとGitHubの全体図

ここまでの話を、実際の環境（2026年7月時点）でそのまま見せます。左がPCの中、右がGitHub上のバックアップ先という対応です。

全体マップ

図3｜全体対応図 — 「何がどこにあり、どこに写しがあるか」

※ memory / skills の「2hごと自動」は、C:\dev の auto-backup-secondbrain.ps1 をOSのタスクスケジューラが定期実行して実現（第7章）。失敗した時だけデスクトップに警告が出る。

「保存済み / 未保存」を一目で（道具箱＝.claude直下）

.claude直下そのものは.gitではありません。バックアップされているのは中の skills\ と memory\ が"それぞれ別リポジトリ"だから。＝入れ子構造です。

図3.5｜.claude直下の保存状況 — 未保存なのは実質 settings.json だけ。その"核（deny規則）"は控えで確保済み。

なぜこの形なのか（理由の対応表）

記憶フォルダの実物

図4｜索引の実物 — User／Reference／Feedback／Projectの4分類

メモ1枚の実物（ラベル部＋本文の2階建て）

図5｜メモの実物 — 「何があったか＋Why＋How to apply」の型

第9章

APIキーの守り方 — 3つの別々の問い

「サーバーに鍵が行くのが気になる度」と「Bitwardenを使うか」は、実は別々の軸です。混ぜると混乱するので、APIキーの守りは3つの独立した問いに分けて考えます。

問い0：全員・無条件の最低ライン（土台）

下のどれを選んでも必ずやる共通の土台。ここだけで実際の事故の大半（GitHub流出・画面への映り込み）を防げます。①gitに上げない（.gitignore）／②チャットに鍵を貼らない／③従量課金の鍵は使用上限・予算アラート／④画面録画・共有に映さない。

問い1：AI（チャット→サーバー）に鍵を"見せる"か？

AIに見せた物はサーバーを通ります（第5章）。それをどう扱うか：

問い2：鍵を"どこに保管"するか？（問い1とは別の軸）

3つは直交している（自由に組み合わせられる）

問い1（見せる/見せない）と問い2（ローカル/金庫）は独立。掛け合わせの4象限：

第10章

deny封印のしくみ — AIに秘密を読ませない

第9章「問い1」の"厳しめ版"を、もう一段だけ詳しく。deny（ディナイ）は、AIに .env などの秘密ファイルを読ませないための、一番強い設定です。

権限は3階層。denyは最強の壁

denyの決定的な点：会話中に「OK」と言っても覆せない。手動承認より上位の、絶対的な壁です。

どこに書くか

書き方の読み方

何を止めて、何を止めないか（核心）

だから動画生成などの自動化はそのまま動く。止まるのは「AIが覗く」動作だけ。秘密でない設定は config に逃がしてあるので、AIも困りません。

足す行（既存は消さず追記）

いつ・どう設定するか（手順）

denyは"全員が初日にやること"ではありません。「守るべき鍵を実際に扱い始めた段階」で導入します。最初から全員に課すと難しくて詰まるので、下の合図が出るまではラク版（AIが.envを読める）のまま学ぶのがコツ。

事前準備（封印前に3点チェック）

設定はAIに頼むのが一番かんたん（コピペ可）

確認：AIに「うちの.envを読んでみて」と頼み、「ブロックされる／読めない」と返ればOK。反映されなければ Claude Code を再起動。

第11章

キーの通り道 — マスターから実行まで

APIキーを金庫（Bitwarden等）に移すと「キーは金庫だけにある」と思いがちですが、正確には2か所にあります。ここを誤解すると、片方を消して自動化を壊します。

2つの層（マスターと実働コピー）

流れ

だから「渡し方」は今までと同じ.envに直書き。変わるのは調べる場所が .txt から Bitwarden になるだけ。新しい習慣は「新規／更新のとき、値をBitwardenからコピーして .env に貼る」1つだけです。

付録

用語ミニ辞典

拡張子（.md .docx など）

ファイル名の末尾につく「種類ラベル」。.mdはただの文章ファイル。

Markdown

「#を付けたら見出し」等のかんたんな記号ルールで書く文章形式。どのアプリ・どのAIでも読める。

リポジトリ

GitHub上の「プロジェクト1個分の保管箱」。履歴ごと保管される。Private＝自分だけが見られる。

プッシュ

PC側の変更をGitHub（倉庫）へ送ること。これがバックアップの実行にあたる。

索引（MEMORY.md）

メモの目次ファイル。1メモ=1行。毎チャット開始時にAIが自動で読む。

トークン

AIの読み書き量の単位。読む文章が長いほど消費する＝燃費の正体。

RAG

文書を細切れにして「意味が近い断片」だけAIに渡す検索方式。NotebookLMがこの系統。

ロックイン

データがサービス専用の形になり、離れられなくなること。正本を置く場所では避ける。

正本（マスター）

いちばん信頼できる大元のデータ。ここではMarkdown＋GitHubに置く方針。

付録

このノートに対応するカリキュラム教材

各章の"教える版"は、脱・属人プログラムのカリキュラム（datsuzokujin-program-curriculum リポジトリ・Private）の次のファイルにあります。このノートは自分の理解・思い出し用、下記は受講者に教える用という役割分担です。

※これらはローカルの c:\dev\claude\datsuzokujin-program-curriculum\ にあり、GitHub（Private）にも同期済み。上記はファイルの置き場を示すもので、Web上のクリック可能なリンクではありません（教材本体は各自のPC／リポジトリで開く）。