ホーム › AI駆動開発ジャーニー › memory システムで Claude に長期記憶を持たせた話 — 152 ファイル / 992 KB の設計と運用
AI駆動開発ジャーニー

memory システムで Claude に長期記憶を持たせた話 — 152 ファイル / 992 KB の設計と運用

公開: 2026-05-24 · 著者: Sasaki Ryuji

AI に「セッション間で連続する長期記憶」を持たせる仕組みの 6 ヶ月運用ログ

memory システムで Claude に長期記憶を持たせた話 — 152 ファイル / 992 KB の設計と運用

「AI に長期記憶を持たせると何が変わるか」を 6 ヶ月実体験で検証しました。個人開発者である私 (Sasaki Ryuji) が Claude Code (Opus 4.7 / 1M context) のために 6 ヶ月かけて構築した memory システム 152 ファイル / 992 KB の設計と運用ノウハウを公開します。memory システムこそが AI 駆動開発の競争力の核です。

本記事の結論を先出しすると、以下の3点です。

  1. memory システムは AI に 「セッション間で連続する長期記憶」 を持たせる仕組み、Claude Code の 1M context window で全 152 ファイルを毎回読み込ませる運用パターン
  2. 4 タイプ (user / project / feedback / reference) + MEMORY.md インデックス + 個別 frontmatter + 相互参照 [[name]] リンク = 6 ヶ月で確立した設計テンプレート
  3. memory の最大の価値は 「同じ失敗を 2 度起こさない仕組み化」。楽観バイアス対策 / moat 保護 / SAIKI 完全分離 / ステマ法対応など、AI の「楽観的な結論」を本人が制御するための情報基盤

以下、memory システムの設計思想、4 タイプの分類、frontmatter 構造、相互参照リンクの設計、蓄積パターン、6 ヶ月の運用で見えた価値と限界を時系列で残します。

memory システムとは何か — Claude Code の 1M context との関係

Claude Code (Opus 4.7) は1M context windowを提供する大規模言語モデルです。1M tokens は日本語約 50-70 万字に相当し、書籍 5-7 冊分の情報を 1 回のセッションで読み込める容量があります。

この大規模 context をフルに活用するため、私は個人開発の全知見を memory ファイル群に蓄積し、Claude Code 起動時に自動的に読み込ませる運用を確立しました。これにより以下が実現します。

  1. セッション間の連続性: 別タブ / 別日のセッションでも、過去の判断 / 失敗 / 教訓を AI が「覚えている」状態を維持
  2. 同じ判断を繰り返さない: 過去に「○○すべき / すべきでない」と決めた判断が memory に残っているため、AI が毎回再考しない
  3. 過去の失敗の教訓を自動適用: Reddit AutoMod 削除 / 楽観バイアス再発 / 楽天 API 仕様変更などの教訓が、新しい判断時に自動的に考慮される
  4. 本人の意思決定の透明化: 「なぜこの判断をしたか」「何を優先しているか」が memory に明文化されており、AI が本人の意図に沿った提案を生成できる

2026 年 5 月時点で私の memory システムは 152 ファイル / 合計 992 KB に達しました。これらすべてが Claude Code の 1M context で毎回読み込まれ、AI が「個人開発全体の文脈を理解した上で対話する」状態を作り出しています。

memory の 4 タイプ — user / project / feedback / reference

memory ファイルは 4 つのタイプに分類して管理しています。各タイプの用途と例を整理します。

タイプ用途例
user本人のプロフィール / 役割 / 知識「Sasaki Ryuji = GramShift 開発者」「業務委託でりゅうさんのクライアント案件あり」
project進行中のプロジェクト情報「saas-diary AdSense 申請 8/16」「GramShift v1.5.15 リリース済」「楽天アフィ 5 記事カバー」
feedback本人の好み / NG 事項 / 運用ルール「日本語で出力」「saas-diary はアフィカード禁止」「SAIKI と AI 系は完全分離」
reference外部システムへのポインタ「楽天 API 新エンドポイント URL」「ConoHa WING SFTP 接続情報」「Discord Webhook URL の保管場所」

4 タイプの分類により、新しい知見が出てきたとき「これは user か project か feedback か reference か」を即時判断でき、memory の散らかりを防げます。タイプを跨ぐ知見 (例: GramShift 開発の進捗 = project、開発時の方針 = feedback) は両方に書くか、相互参照リンクで繋ぎます。

frontmatter 構造 — メタデータで AI に文脈を伝える

各 memory ファイルは YAML frontmatter を持ち、メタデータを構造化しています。標準フォーマットは以下です。

---
name: saiki-koyomi-strategy
description: りゅうさんからの新方針を受けた SAIKI集客の戦略大転換。koyomi (りゅうじ本人ペルソナ) によるパーソナル型集客、完全紹介制
metadata:
  node_type: memory
  type: project
  originSessionId: 7a2f6a04-6dbe-46e5-a934-865ec81fdeba
---

# 本文 (Markdown 形式)

...

frontmatter の各フィールドは以下の役割を持ちます。

  • name: ファイル名と一致する一意の ID、相互参照 [[name]] で使用
  • description: 1 行の要約 (200 字以内)、AI が「このファイルは何か」を即座に把握
  • metadata.type: 4 タイプの分類 (user / project / feedback / reference)
  • metadata.originSessionId: 作成元セッション ID、トレーサビリティ

frontmatter があると、AI は文脈を理解した上で memory を処理できます。「これは project memory だから期日とステータスに注目」「これは feedback memory だから今後の判断ルールとして扱う」といった処理が、自動的に適切になります。

MEMORY.md インデックス — 1 行参照で全体俯瞰

個別 memory ファイルの一覧は MEMORY.md というインデックスファイルに集約しています。各エントリは 1 行で簡潔に書きます。

# Memory

## 🗺️ プロジェクト俯瞰
- 🔴 [project-overview-table.md](project-overview-table.md) — サイト×ドメイン×GA4×メアド×SNS の対応表
- 🎯 [事業成功確率 ≧ 90%](200man-monthly-target-strategy-2026-05-24.md) — 月200万到達戦略

## User
- [ユーザーの役割](user_role.md) — りゅうじ本人 ≠ りゅうさん、業務委託の区別

## フィードバック
- [日本語で出力](feedback_japanese_output.md) - 全て日本語
- 🔴 [絞らず拡張](expansion-strategy-no-narrowing.md) - 並走最大化哲学

... (152 行続く)

MEMORY.md は AI が最初に読むファイルで、ここから個別ファイルの存在と概要を把握します。重要な原則は以下です。

  1. 1 エントリ 1 行: 200 文字以内、長くしない
  2. 200 行以内: それ以上は AI が読み込み時にトリミングする可能性、必須情報は上に
  3. カテゴリ別整理: User / Project / Feedback / Reference / GramShift / SAIKI 等のセクション分け
  4. 絵文字で重要度: 🔴 (最重要) / 🆕 (新規) / ⚠️ (注意) を使って視認性を高める
  5. 1 行ハイフン要約: - [タイトル](file.md) — 要約 形式で統一

MEMORY.md があると、AI は「個別 memory ファイルを全部読まなくても、MEMORY.md だけで全体像が分かる」状態になります。1 つの大きなセッションで複数 memory を参照するケースで威力を発揮します。

相互参照リンク [[name]] — memory 間のグラフ構造

個別 memory 内では、他の memory を [[name]] 形式で参照します。これにより memory 間にグラフ構造が形成され、AI が関連情報を辿れるようになります。

具体例 (saas-diary-rewrite-plan.md の冒頭):

## 🚨 リライト前に必読: SAIKI 言及完全禁止 ([[feedback_saiki_ai_kei_isolation]] 確立)

saas-diary を含む AI 系メディアで記事リライト・新規作成する際、以下の固有名詞は
一つも書いてはならない ([[feedback_saiki_ai_kei_isolation]])。本人念押し済。

[[opus-rewrite-counterproductive]] により Opus 4.7 の「人間っぽく」リライトは
GPTZero で逆効果。

3 つの [[link]] が連鎖することで、AI は「リライトプラン → SAIKI 分離ルール → Opus リライト逆効果」という関連情報を 1 つの判断に統合できます。リンクが不在の状態だと、AI は毎回これらを再思考する必要があり、ペアモデル運用の効果が薄れます。

[[link]] の重要なルールは以下です。

  • 未存在の [[link]] でも書いて OK (将来の memory への予約として機能)
  • 同じ memory への [[link]] は複数回出てきても問題なし (重要度を強調できる)
  • 双方向リンクは推奨だが必須ではない (A → B だけでも AI は B → A を推測可能)
  • カテゴリ系の link は「ハブ memory」を作って集約 (例: SAIKI 関連は全部 [[saiki-project]] を経由)

蓄積パターン — どこから memory が増えるか

6 ヶ月の運用で見えてきた、memory が増える典型パターン 5 つを整理しました。

  1. 失敗からの蓄積 (最も価値が高い): Reddit AutoMod 削除 / 楽観バイアス再発 / 楽天 API 仕様変更 / 楽天初回中古本ヒット 等の失敗事例を「次に同じパターンに遭遇したら避ける」memory に
  2. 成功確認からの蓄積: 「○○の運用パターンが上手くいった」「○○の設計判断が正解だった」を確認後に memory 化、AI が同じパターンを再利用
  3. 一次情報の収集: 楽天 API 公式ドキュメント / Princeton GEO 論文 / Meta Community Standards / 業界統計などの権威ソースを「いつでも参照できる」memory に
  4. 本人の方針 / 好みの明文化: 「saas-diary はアフィカード禁止」「SAIKI と AI 系は完全分離」など、本人の意思決定ルールを明文化
  5. セッション末の引き継ぎノート: 1 セッションの終わりに「次セッションで言う合言葉」「期日付きタスク」「決定事項」を memory に永続化

5 パターンのうち、私が経験的に最も価値があると感じるのは「失敗からの蓄積」です。成功は再現が難しいですが、失敗は再発を防ぐだけで明確な価値があります。「同じ失敗を 2 度起こさない仕組み化」が memory システムの最大の価値です。

運用の現実 — 152 ファイル / 992 KB が context に収まる理由

「152 ファイル / 992 KB を毎回読み込むって、コスト的に大丈夫?」という疑問が出てくると思います。Claude Code の Max plan ($200/月) サブスクリプション内で動くため、追加コストは発生しません。Anthropic API を別契約していたら、1 セッションあたり数 $-$10 のコストが発生するレベルですが、Claude Code 内ではサブスクリプション込みです。

tokens の換算は以下のとおりです。

  • memory 992 KB ≈ 25-30 万 tokens (日本語 1 文字 ≈ 2-3 tokens)
  • Claude Code の 1M context = 100 万 tokens
  • つまり memory は context の 25-30% を占める
  • 残り 70-75% は 当該セッションの会話 / コードファイル / その他リソース

運用上の余裕は十分にあります。memory が 1.5-2 MB (50-60 万 tokens) を超えると context 余裕が少なくなるため、その時点で「古い memory のアーカイブ」「重複情報の統合」が必要になります。現状は問題なし、2027 年初頭まで余裕があります。

失敗事例 — memory システムの限界

6 ヶ月の運用で memory システムの限界も見えました。率直に共有します。

  1. memory 自体の古さ問題: ファイル冒頭に「This memory is 4 days old」のような警告が出るが、AI が古い情報を採用してしまうケースが時々ある (これも memory 化して防止)
  2. 重複情報の散らかり: 同じ情報が複数 memory に書かれている、修正時に片方だけ更新するミス
  3. 巨大ファイル化: 1 ファイルが 200 行を超えると、AI が情報を見失う傾向 (200 行で分割推奨)
  4. 「楽観バイアス」が memory に残るリスク: 過去に楽観評価した数値が memory に残り、後の判断で再利用されてしまう (定期的に「確率スナップショット」memory を更新して対策)
  5. 本人記憶との不整合: 本人が「○○と決めた」と言うが、memory には別の決定が書かれているケース (memory 優先で確認するルール化)

これらの限界を踏まえつつ、memory システム全体としては「個人開発の競争力の核」として機能しています。失敗を memory 化して再発防止、新しい判断を memory 化して継続性確保、という循環が回り始めると、AI 駆動開発の生産性が指数関数的に上がります。

他の個人開発者が memory システムを始めるには

「自分も memory システムを始めたい」という個人開発者向けに、最初の 30 日の運用ガイドを 5 ステップで整理しました。

  1. Day 1: ディレクトリ作成 + MEMORY.md の雛形 — ~/.claude/projects/<name>/memory/MEMORY.md + 「User」「Project」「Feedback」「Reference」の 4 セクション
  2. Day 1-3: 最初の 5 memory を書く — user_role.md / current_project.md / feedback_japanese.md / feedback_no_assumptions.md / reference_github_repo.md (具体例)
  3. Day 4-14: 失敗するたびに memory 追加 — 「あの判断は間違いだった」「あの設計はやめた方が良かった」と気づいた瞬間に新規 memory ファイル作成
  4. Day 15-30: 相互参照 [[link]] を意識的に増やす — 既存 memory を読み直して、関連するもの同士をリンクで繋ぐ
  5. Day 30 以降: 月次振り返り — 月末に MEMORY.md を見直して整理、不要 memory を archive、新しいカテゴリを追加

30 日続けると memory ファイル数が 20-30 件に達し、ペアモデル運用の効果を実感できるようになります。6 ヶ月で 100-150 件に達すると、私と同じく「AI 駆動開発の競争力の核」として機能し始めます。

次回連載 6 本目は 「AI に「月 200 万戦略」を立てさせたら何を提案してきたか」 を予定しています。memory に蓄積された全データを使って、Claude が立てた事業戦略 / 確率分析 / リスク評価の全公開です。

筆者: Sasaki Ryuji — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech 等 複数メディア運営。本記事内の memory システム数値 (152 ファイル / 992 KB) は 2026 年 5 月 25 日時点の実測値です。

よくある質問

memory システムは Claude Code 以外でも使えますか?

原則として、長期 context を扱える AI ツール全般で応用可能ですが、Claude Code (Opus 4.7 / 1M context) ほど大規模に活用できる環境は現状少ないです。ChatGPT Plus の Memory 機能や Cursor の Project Rules は小規模なら同等の効果がありますが、152 ファイル / 992 KB 規模の memory を毎セッションで読み込ませる用途には Claude Code が最適です。AI ツール選定の主要な判断軸は「context window のサイズ」「長期セッションでの状態保持」「ファイル参照の柔軟性」の 3 点です。

memory ファイルは何個まで増やせますか?

現状 152 ファイル / 992 KB ですが、1M context window では 25-30 万 tokens を memory に割いている状態で、まだ 70-75% の余裕があります。1.5-2 MB (50-60 万 tokens) を超えると context が逼迫するため、その時点で「古い memory のアーカイブ」「重複情報の統合」が必要になります。2026 年現在の運用ペースなら 2027 年初頭まで余裕があります。Anthropic が将来 2M / 5M context を提供したら、さらに 5-10 倍の規模拡張が可能です。

memory が大きくなるとパフォーマンスは落ちますか?

正直に言うと、ファイルサイズが大きくなるほどセッション開始時のロード時間は若干増えます。1M context フル使用でも数秒の差程度で、実用上の問題はありません。ただし「AI が情報を見失う」リスクは存在します。これは memory のサイズではなく「情報の整理度」次第で、200 行を超える 1 ファイルや、重複情報が散らかった memory は AI のパフォーマンスを下げます。月次振り返りで memory を整理する運用が有効です。

memory システムを始めて効果が出るまでにどれくらいかかりますか?

私の経験では「30 日で 20-30 件の memory」段階で効果を実感し始め、「3 ヶ月で 100 件以上」段階で AI 駆動開発の競争力として機能し始めます。最初の 1-2 週間は memory を書く時間が増えるため、生産性が下がるように感じるかもしれませんが、3 週目以降は「同じ判断を再考しない」「失敗を再発しない」効果で生産性が大きく上がります。継続が鍵で、書き慣れると 1 つの新規 memory を 5-10 分で書けるようになります。