Memory on KnightLiブログ

ChatGPT、Claude Code、Gemini の記憶機構は何が違うのか

Thu, 07 May 2026 14:47:17 +0800

AI 製品における「記憶」はますます重要になっている。これは AI が「単発の会話ツール」から「長期的な協力相手」へ移行していることを示している。毎回背景を説明し直す必要がなくなり、好みを繰り返し伝える必要もなく、同じプロジェクトを何度も理解させる必要も減る。

しかし、製品ごとの記憶は同じものではない。ChatGPT、Claude Code、Gemini はいずれも「AI がより長く覚える」問題を扱っているが、設計目標、保存場所、透明性、適用シーンは大きく異なる。

2026 年 5 月 7 日時点では、おおまかに3つに分けられる。

ChatGPT は「個人アシスタントの記憶」に近い。
Claude Code は「エンジニアリングプロジェクトの記憶」に近い。
Gemini は「Google エコシステムの文脈」に近い。

ChatGPT：人を中心にした長期的な好み

ChatGPT の記憶機構は主に個人協作向けだ。関心の中心は「あなたは誰か」「何を好むか」「長期的に何をしているか」にある。

OpenAI は現在、ChatGPT の記憶を saved memories と chat history に分けている。

saved memories は、ChatGPT が保存する重要情報だ。名前、好み、目標、よく使う技術スタック、文章の癖などが含まれる。ユーザーが明示的に覚えるよう頼むこともできるし、ChatGPT が会話の中から将来役立つと判断した情報を保存する場合もある。

chat history は、回答時に過去の会話を参照する仕組みだ。すべての会話がそのまま記憶になるわけではなく、必要に応じて過去の会話から関連文脈を探す。

つまり ChatGPT の中核ロジックは、同じユーザーを会話をまたいで理解することだ。

典型例は次のようなものだ。

「今後コード例はできるだけ簡潔にして。」
「私は主に Python と TypeScript を使っている。」
「AI ツールについての Hugo ブログを書いている。」
「先に結論を見て、その後に詳細を読むのが好き。」

これらの記憶は特定プロジェクトに紐づくものではなく、アカウントと個人の利用習慣についてくる。

Memory Sources：個人化の出所を見えるようにする

OpenAI は 2026 年 5 月の更新で Memory sources を強調した。

これは新しい記憶タイプではなく、ChatGPT が回答を個人化するときに参照した情報源をユーザーに見せる仕組みだ。OpenAI のヘルプ文書によると、Memory Sources には次のようなものが表示される場合がある。

過去のチャット。
保存された記憶。
カスタム指示。
ファイルライブラリ内のファイル。
接続済み Gmail のメール。

ファイルや Gmail の表示範囲は、プラン、地域、接続状態によって制限される。OpenAI はまた、Memory sources が回答に影響したすべての要因を表示するとは限らず、個人化の理解と管理を助けるものだと説明している。

これは重要だ。AI が「あなたを覚える」ほど、ユーザーは何に基づいて回答したのかを知る必要がある。そうでなければ個人化はブラックボックスになりやすい。AI が自分を知っているように見えるが、なぜ知っているのか分からない状態になる。

ChatGPT の強みは、会話やテーマをまたいで個人の好みを継続的に理解することだ。一方で、記憶が古くなったり、古い記憶がまだ回答に影響していることをユーザーが忘れたりするリスクもある。そのため saved memories と古いチャットは定期的に整理したほうがよい。

Claude Code：コードベースとエンジニアリングルールを中心に

Claude Code の記憶機構はエンジニアリング協作寄りだ。関心の中心は「ユーザーが普段何を好むか」ではなく、「このコードベースをどう変更すべきか」だ。

Claude Code には混同されやすい2種類の記憶がある。

明示的なプロジェクト記憶：CLAUDE.md。
自動プロジェクト記憶：Auto Memory。

CLAUDE.md は最も基本的で安定したプロジェクト記憶ファイルだ。プロジェクトルートにも、サブディレクトリにも置ける。Claude Code はこれらのファイルを読み、プロジェクト説明と作業ルールとして扱う。

CLAUDE.md に書くのに適した内容は次の通りだ。

よく使う build、test、lint コマンド。
コードスタイルと命名規則。
プロジェクトアーキテクチャ。
モジュール境界と危険な領域。
チームの約束事とコミットフロー。

CLAUDE.md をリポジトリに置けば、Git にコミットしてチーム共有の agent 説明書にできる。これは ChatGPT のクラウド上の個人記憶とはまったく異なる。

Claude Code Auto Memory：プロジェクト経験を自動で蓄積する

Claude Code には現在 Auto Memory もある。目的は、ユーザーが毎回手で説明を書かなくても、Claude が複数セッションにまたがってプロジェクト経験を自動的に蓄積できるようにすることだ。

Claude Code の文書によると、Auto Memory は作業中に Claude が自分用のメモを保存する仕組みだ。build コマンド、デバッグで分かったこと、アーキテクチャ説明、コードスタイルの好み、ワークフロー習慣などが対象になる。すべてのセッションで保存するわけではなく、将来役立ちそうな情報を判断する。

誤解されやすい点がある。Auto Memory はデフォルトでプロジェクトルートの .claude/memory.md に書くわけではない。公式文書では、各プロジェクトはユーザーディレクトリ配下に独自の memory ディレクトリを持つと説明されている。パスは次のような形だ。

`1`	`~/.claude/projects/<project>/memory/`

MEMORY.md は各会話開始時に最初の 200 行または 25KB が読み込まれ、詳細は別のトピックファイルへ分割される場合がある。Auto Memory ファイルはローカルの Markdown ファイルで、ユーザーは /memory から表示、編集、削除できる。

これにより Claude Code の記憶は「ローカル上のプロジェクト経験庫」に近くなる。ChatGPT の個人記憶よりコードベースに近く、単なる CLAUDE.md より動的だ。

ただし Auto Memory はローカルマシン上のものだ。リポジトリと一緒に他のマシンやクラウド環境へ自然に同期されるわけではない。チームで共有すべき安定したルールは、やはりプロジェクト内の CLAUDE.md に書くべきだ。

Gemini：Google エコシステムの文脈を中心に

Gemini の記憶ロジックはまた別だ。

Gemini にも保存情報と過去チャット参照の能力がある。Google のヘルプ文書では、ユーザーは生活、仕事、好みに関する情報を保存でき、Gemini は回答前に過去のチャットを参照できると説明されている。これらの情報を使うと、回答下部のソース領域に Your saved info や Previous chats が表示される場合がある。

しかし Gemini の差別化は「好みを数個保存する」ことだけではなく、Google エコシステム連携にある。

ユーザーが許可し、機能が利用可能な場合、Gemini は Gmail、Google Drive、Docs、Sheets など接続された Google アプリから文脈を取得できる。強みは、ユーザーが一つずつ教え込むことではなく、すでに Google アカウント内にある資料を検索可能な作業文脈にできることだ。

典型的な違いは次のようになる。

ChatGPT は「最近 LTO テープドライブを修理している」と覚える。
Gemini は Gmail から購入確認メールを見つけたり、Drive から修理メモを読んだりできる場合がある。

もちろん、Gemini が無条件で Google データすべてを読めるわけではない。アカウント種別、地域、権限、接続アプリ、Keep Activity 設定、具体的な製品提供状況に依存する。企業や学校アカウントでは、Google Workspace 管理者の制御も受ける。

より正確に言えば、Gemini の記憶は単純な「メモ帳」ではなく、「保存情報 + 過去チャット + Google エコシステム接続」の組み合わせだ。

3者の主な違い

次元	ChatGPT	Claude Code	Gemini
中心対象	人と好み	プロジェクトとコードベース	Google アカウントとエコシステム資料
典型的な記憶	好み、背景、長期目標	アーキテクチャ、コマンド、規約、デバッグ経験	saved info、過去チャット、Gmail/Drive/Docs 文脈
保存形態	OpenAI アカウント内の記憶とチャット文脈	`CLAUDE.md`、`MEMORY.md`、ローカル Markdown ファイル	Google アカウント活動、保存情報、接続アプリデータ
透明性	Memory sources で一部の出所が見える	Markdown ファイルを直接表示・編集できる	ソース表示、Gemini Apps Activity、Google 設定で管理
プロジェクト横断	強い。ユーザーアカウントに追従	弱い。主にプロジェクトまたはローカル project memory に追従	強い。Google 資料と権限に依存
チーム共有	直接共有には不向き	`CLAUDE.md` を Git で共有可能	主に Workspace と権限体系に依存
得意領域	個人の好みと長期アシスタント	長期コードプロジェクトと agent 協作	Google Workspace 資料検索とクロスツール作業

どう選び、どう使うか

AI に「自分は誰か、どんなスタイルが好きか、普段どう働くか」を覚えさせたいなら、ChatGPT の記憶が向いている。

文章スタイル、よく使う技術スタック、回答形式、職業背景、長期プロジェクトの方向といった個人の好みを保存するのに適している。重点は自己紹介コストを下げ、新しい会話を素早く始めることだ。

AI に「このコードベースをどう変えるか、どのコマンドが動くか、どの罠を避けるか」を覚えさせたいなら、Claude Code が向いている。

安定したルールは CLAUDE.md に書いてチーム共有する。動的な経験は Auto Memory に補助させる。重要な意思決定はローカル自動記憶にだけ残さず、文書や CLAUDE.md に整理するのがよい。

資料の多くが Gmail、Drive、Docs、Sheets にあるなら、Gemini のエコシステム文脈が有利だ。

過去メールの検索、Google Drive 文書の整理、カレンダーやオフィス資料との連携に向いている。Gemini を使うポイントは、チャット内で何度も思い出させることではなく、関連アプリの接続、権限、アクティビティ設定を正しくしておくことだ。

実用的な分担

3者は次のように分担できる。

ChatGPT は「自分の一般的な好み」を覚える。
Claude Code は「このリポジトリのエンジニアリング知識」を覚える。
Gemini は「Google エコシステム内の資料」を検索する。

つまり、ChatGPT は個人秘書、Claude Code はプロジェクト内のシニアエンジニア、Gemini は Google アカウント内の資料インデクサーに近い。

この3種類の記憶に絶対的な優劣はない。目的が違うだけだ。

最も注意すべきなのは混同することだ。個人の好みは必ずしもプロジェクト記憶に書くべきではない。プロジェクトアーキテクチャは必ずしもクラウド上の個人記憶に保存すべきではない。Google エコシステム検索は、モデルがあなたを長期的に本当に理解したことと同じではない。

短い判断

AI 記憶の次の段階は、単に「多く覚える」ことではない。記憶は階層化され、見えるようになり、制御可能である必要がある。

ChatGPT の重点は会話をまたいだ個人化、Claude Code の重点はコードプロジェクトの継続性、Gemini の重点は Google エコシステム文脈だ。本当に使いやすい長期 AI 協作は、すべての情報を一つのブラックボックスに詰め込むのではなく、異なる種類の記憶を適切な場所に置く。

個人の好みは個人記憶に、エンジニアリングルールはコードベースに、過去資料は元の文書やメールシステムに置く。AI がすべきことは、必要なときに正確にそれらの文脈を呼び出すことであり、すべてを一つに混ぜることではない。

ChatGPT Release Notes 更新：記憶ソース、GPT-5.5 Instant、表計算アドイン

Thu, 07 May 2026 14:30:15 +0800

OpenAI の ChatGPT Release Notes ページは 2026 年 5 月初めに更新された。最新の主な内容は3つある。ChatGPT の記憶ソースとパーソナライズ能力の強化、GPT-5.5 Instant の新デフォルトモデル化、そして ChatGPT for Excel と Google Sheets のグローバル提供だ。

これらを合わせて見ると、方向は明確だ。ChatGPT は単なるチャット入口から、より継続的で、より個人化され、オフィス作業に近いワークアシスタントへ進んでいる。

Memory sources：パーソナライズをより透明に

最新更新で最も注目すべきなのは memory sources だ。

OpenAI は、ChatGPT Plus と Pro ユーザーに対して記憶機能の改善を展開し始めるとしている。ChatGPT は過去のチャット、保存された記憶、利用可能なファイル、接続済み Gmail アプリから関連文脈をよりうまく取り出し、ユーザーに合ったアイデア、提案、次の行動を出せるようになる。

これにより、ユーザーは新しい会話のたびにプロジェクト背景、好み、作業習慣、既存資料を繰り返し説明する必要が減る。長期的な執筆、プロジェクト計画、資料整理、学習、チーム作業では、継続性が強くなる。

ただし、パーソナライズが強くなるほど透明性は重要になる。そのため OpenAI は memory sources を導入し、どの情報が回答のパーソナライズに使われたかをユーザーが確認できるようにする。回答下の Sources アイコンを押すと、関連する保存記憶、過去のチャット、カスタム指示を確認できる。Plus と Pro ユーザーは、ライブラリ内のファイルや、接続済み Gmail から参照されたメールも見る場合がある。

情報が古い、不関連、または誤っている場合、ユーザーは修正、削除、または不関連としてマークできる。

記憶の制御は依然として重要

OpenAI は、memory sources が回答に影響したすべての要因を表示するとは限らず、今後もこのビューを改善すると説明している。

これは重要な注意点だ。memory sources は完全な「モデル思考ログ」ではない。個人化の文脈を理解するためのプロダクトインターフェースだ。可視性は高めるが、すべての影響要因を完全に展開するものではない。

プライバシーと制御について、OpenAI は memory sources がユーザー自身のアカウント体験内にのみ表示されると述べている。チャットを共有しても、関連 sources は共有チャットに表示されない。ユーザーはチャットを削除したり、記憶を使わず更新もせず履歴にも残らない Temporary Chat を使ったり、記憶をオフにしたり、アプリ接続をいつでも解除したり、自分のコンテンツがモデル改善に使われるかを管理できる。

これは、ChatGPT のパーソナライズがより明確な道筋を取っていることを示している。ユーザーをより理解する一方で、なぜそう答えたのかを知らせ、管理入口も残すという方向だ。

GPT-5.5 Instant がデフォルトモデルに

Release Notes は、GPT-5.5 Instant が ChatGPT の新しいデフォルトモデルとして展開され、すべてのユーザー向けの GPT-5.3 Instant を置き換えることも確認している。

今回のデフォルトモデル更新では、主に次の点が改善される。

正確性。
明確さと簡潔さ。
画像理解。
STEM 質問への回答。
いつ web search が必要かの判断。

OpenAI は、GPT-5.5 Instant が特に正確性が重要なプロンプトでより事実に強いと強調している。また、より引き締まった直接的な回答を出し、不要な追問を減らし、過度なフォーマットや装飾的な内容による散らかりを減らす。

ユーザーにとって、これは新しいボタンほど目立たないかもしれない。しかし毎日 ChatGPT を開くときの体感には効く。回答が遠回りせず、冗長さが減り、簡単な質問に過剰な形式を積み上げにくくなる。

パーソナライズとデフォルトモデルがつながる

Web 版の Plus と Pro ユーザーに対して、GPT-5.5 Instant は過去のチャット、ファイル、接続済み Gmail の文脈をより効果的に使える。

これは memory sources と同じプロダクトラインにある。モデルは単に「賢い」だけではなく、適切な場面で、ユーザーが以前に何をしていたか、何を気にしているか、どんな資料をすでに提供したかを理解する必要がある。プロジェクトの継続、計画作成、メール情報の整理、過去の好みに基づく提案では、ChatGPT は重複した質問を減らせる。

有料ユーザーは GPT-5.3 Instant をモデル設定から3か月間使い続けられ、その後このモデルは退役する。

ChatGPT for Excel と Google Sheets

もう一つの重要な更新は、ChatGPT for Excel と Google Sheets のグローバル提供だ。

これは Microsoft Excel と Google Sheets のサイドバーに ChatGPT を入れ、ユーザーが表計算内で直接データを作成、更新、理解できるようにする。OpenAI が挙げるシーンは次の通りだ。

トラッカー。
予算。
数式。
複数シートのファイル。
シナリオ作業。
スプレッドシートの整理。

利用可能な条件では、Skills と apps もサポートする。

この機能の意味は分かりやすい。多くのオフィスデータは専用 BI システムではなく、Excel と Google Sheets にある。ChatGPT を表計算のサイドバーに置くことは、チャット画面へコピー＆ペーストさせるより自然で、実際のワークフローに入りやすい。

利用制限とインストール方法

Release Notes によると、Free と Go には限定的な利用量が含まれる。Plus と Pro は Codex と同じ agentic usage limits を使う。プラン上限を超える場合、追加 credits を購入できる。

インストール方法も直接的だ。Excel 版は Microsoft Marketplace から、Google Sheets 版は Google Workspace Marketplace からインストールし、対象となる ChatGPT アカウントでログインする。

OpenAI は、数式や分析に依存する前に出力を確認するよう促している。これは重要だ。AI は表計算作業を速くできるが、数式、予算、財務、業務分析は依然として人間の確認が必要だ。

短い判断

今回の ChatGPT Release Notes の焦点は、単一の機能ではなく、プロダクト形態がさらに整えられていることだ。

GPT-5.5 Instant はデフォルト回答品質を高める。memory sources はパーソナライズを見えるようにする。Excel と Google Sheets のアドインは ChatGPT をオフィスの表計算に入れる。Advanced Account Security とモデル選択の変更は、アカウント保護と操作体験を補強する。

ChatGPT はより長期的な作業レイヤーになりつつある。より多くの文脈を覚え、より多くのツールに入り、より多くの日常タスクを担う。次に見るべきなのは、パーソナライズの透明性が十分に分かりやすいか、オフィスアドインが実際の複雑な表計算で安定するか、そしてユーザーが便利さと制御のバランスを保てるかだ。

Claude Code の環境設定4点セット：CLAUDE.md、Rules、Memory、Hooks をまとめて理解する

Thu, 23 Apr 2026 10:43:40 +0800

Claude Code をしばらく使っていると、すぐに気づくことがあります。モデルそのものが重要なのは当然ですが、どんな環境を与えるか、どんな境界を置くか、どんなルールを持たせるかも同じくらい重要だということです。

最初のうちは「今回の prompt をどう書くか」に意識が向きがちです。ですが、本当に Claude Code を使いこなすようになると、気になるのは別のことです。

それは自分が誰かを分かっているか
自分がどう働くかを分かっているか
破ってはいけないルールを分かっているか
先に確認すべきことを分かっているか
そうした境界を長期的に覚えていられるか

Claude Code が成熟したツールになる理由は、単にモデルが強いからではありません。こうした働き方を仕組みとして定着させる一式があるからです。大きく分けると、その中核は次の4層です。

CLAUDE.md
Rules
Memory
Hooks

この記事では、この4つをまとめて整理します。

なぜ単発のプロンプトより環境設定のほうが重要なのか

Claude Code を、雇ったアシスタントだと考えてみてください。

初日に「何か手伝って」と一言だけ伝えることはないはずです。普通は説明書を渡して、次のようなことを伝えます。

自分はどんな立場なのか
どんなコミュニケーションのトーンを好むのか
どんな操作は必ず事前確認が必要か
以前起きたどんなミスを今後は避けたいか
重要な文書がどこにあるか

だからこそ、長い目で見ると、環境設定は単発の prompt より重要になりやすいのです。

prompt が解決するのは「今回は何をするか」です。環境設定が解決するのは「これから毎回どう働くか」です。

第1層：`CLAUDE.md`

まず一番基本から始めます。CLAUDE.md は本質的にはただのテキストファイルです。

そこには Claude への説明を書けます。たとえば：

自分が誰か
何に取り組んでいるか
どんなコミュニケーションを好むか
守るべきルール
現在のプロジェクトの特殊事情
重要な文書やディレクトリの場所

Claude Code が起動するたびに、この文書は自動的にコンテキストに入るので、モデルは必ず目を通します。

私はこれを「共有された暗黙知のファイル」だと考えることが多いです。実際、それがあなたとモデルの長期協業における前提になるからです。

`CLAUDE.md` に書くのに向いていること

CLAUDE.md に最も向いているのは、おおむね次のような内容です。

身元や仕事上の背景
話し方や出力の好み
グローバルな行動ルール
よく参照する重要なプロジェクト背景
よくあるミスとその防ぎ方

たとえば：

自分のタイムゾーン
モデルによるメールやメッセージの直接送信を許可するか
どの操作が不可逆か
文書やファイルの扱い方の癖
セキュリティ方針や機密情報の境界

とても大事な原則：できるだけ簡潔にする

CLAUDE.md には非常に大事な原則があります。それは、できるだけ簡潔に保つことです。

理由は単純で、毎回コンテキストに強制的に入るからです。

長くなりすぎると、大量のコンテキストを消費してしまい、本当に重要な情報が薄まります。モデルが読まないのではなく、注意が分散し、最も重要なルールを取りこぼしやすくなるのです。

公式の目安としては、400 行を超えないほうがよいと言われることが多いです。

私自身はもう少し保守的で、できるだけ 200 行以内に収めるようにしています。

`CLAUDE.md` のよくあるスコープ

CLAUDE.md には実際には複数の配置レベルがあり、そのレベルによって効く範囲が変わります。最もよく使うのは次の2つです。

1. User Level

これはグローバルレベルです。

ローカル環境に置かれ、そのマシン上で扱うすべてのプロジェクトに効きます。

ここに向いているのは：

自分の基本情報
汎用的なコミュニケーションの好み
プロジェクトをまたいで通用する作業習慣
グローバルな安全ルール

たとえば、あなたのタイムゾーンが一般的に想定されがちなものではなく、バンコク時間であるなら、それは user level に置くのが自然です。そうすれば、後で日時を扱うときのミスが減ります。

2. Project Level

こちらはプロジェクトレベルです。

特定のプロジェクトディレクトリの下に置かれ、そのプロジェクトにだけ効きます。

ここに向いているのは：

プロジェクト固有の背景
そのプロジェクトでしか成立しないルール
ディレクトリ構成の説明
重要文書の入口

たとえば、あるプロジェクトが財務を扱い、別のプロジェクトが人事を扱うなら、背景も制約も違うので、同じグローバル説明に混ぜるべきではありません。

どのレベルに置くかをどう判断するか

判断基準はシンプルです。

別のプロジェクトに移っても成立するなら user level に置く。

プロジェクトを変えた瞬間に成立しなくなるなら project level に置く。

最初の版をどう書き始めるか

よくある始め方は2つあります。

1. `/init` を使う

ターミナルで /init を実行して、Claude に現在のプロジェクトをスキャンさせ、基礎的な CLAUDE.md を自動生成してもらう方法です。

2. Claude に整理してもらう

他の人がどう CLAUDE.md を書いているかを Claude に調べてもらい、自分の状況に合わせて質問してもらった上で、最終的に自分向けの版に整理してもらうこともできます。

多くの場合、ゼロから自分で書くよりずっと楽です。

とても実用的な習慣

長く協業していると、「これは今後も必ず覚えておくべきだ」「これは二度と繰り返してほしくない」と思うことが出てきます。そういう内容は、そのまま CLAUDE.md に書き足していくと便利です。

ただし、その前に考えるべきことがあります。

それはグローバルルールか
それとも今のプロジェクト専用のルールか

何でも1つのファイルに詰め込まないことが大切です。

第2層：`Rules`

次が Rules です。

CLAUDE.md との最大の違いは、ファイル形式ではなくロードの仕方です。

CLAUDE.md は何をしていても常に読まれます。

一方、Rules の強みは 条件付きで読み込める ことです。

つまり、特定のパス、ファイル、ツール、場面でだけ、そのルールを読ませることができます。

なぜ条件付きロードが重要なのか

コンテキスト空間は常に限られています。

すべてのルールを無差別に毎回押し込むと、次の2つが起きます。

モデルの負担が増える
本当に重要なルールが埋もれる

必要なときに必要な情報だけ読ませる。これが条件付きロードの価値です。

`CLAUDE.md` から `Rules` に移すべきタイミング

典型的には2つあります。

1. `CLAUDE.md` が長くなりすぎたとき

CLAUDE.md が 200 行を超え始め、ルールが増えすぎて重要な内容が薄まってきたら、一部を切り出すタイミングです。

2. 特定のルールが特定のパスにしか関係しないとき

たとえば、あるルールが：

Python スクリプトにだけ有効
hooks ディレクトリにだけ有効
特定のサブプロジェクトにだけ有効

のように、適用対象が明確なら、それは Rules に移したほうが自然です。

`Rules` が最も向いている場面

典型的なのは「特定状況・特定パス・特定ファイル種別」です。

たとえば：

hook ファイルにだけ適用したい規約
特定種類のスクリプトだけで守らせたいコーディング規則
特定ディレクトリだけで有効な作業方針

そうした内容を CLAUDE.md に入れ続けるのは、あまり効率的ではありません。

第3層：`Memory`

3つ目の層が Memory です。

これも CLAUDE.md や Rules と同じくコンテキストに入りますが、本質的な違いがあります。

CLAUDE.md はあなたが意図的に定義するものです。

Memory は、協業の中で Claude が自分用に残すメモに近いものです。

`Memory` に入るもの

Claude が「これは覚えておく価値がある」「しばらく保持したほうがよい」と判断した内容は Memory に入ります。

たとえば：

あなたが修正したやり方
最近追加された好み
現在のプロジェクトの一時的な状態
今日終わらず、明日続きが必要なこと
最近誰と協業しているか
最近出てきた個人的な情報や文脈

つまり、Memory は長期制度というより、動的な知識に近いのです。

最初の2層との違い

簡単に分けるなら：

CLAUDE.md / Rules：長期的、制度的、明示的なルール
Memory：一時的、動的、作業の中で新しく得た理解

ここ数日しか有効でないことや、状態が継続的に変わることなら、長期ルールではなく Memory に向いています。

`Memory` は手動でも書ける

Memory は自動整理されることがありますが、こちらから明示的に指示して書かせることもできます。

たとえば：

明日やることを覚えておいて
誰の状況を追う必要があるか覚えておいて
今月のプロジェクトの重要な節目を覚えておいて

といった内容です。

また、/memory コマンドで現在の記憶を確認し、手動で編集・削除することもできます。

ただ、私自身はあまり頻繁に手で管理しません。Claude 側でも古くなった記憶を定期的に整理できるからです。

第4層：`Hooks`

最後であり、最も重要かつ上級なのが Hooks です。

ここまでの CLAUDE.md、Rules、Memory は、いずれも最終的には自然言語の指示です。

ルールを書けば、モデルはたいてい従います。ですが、それでも「解釈してから実行する」ものです。

自然言語にとどまる限り、いくつかの問題が残ります。

ときどき見落とす
ルールが増えると注意が分散する
状況によっては、そのルールを重要でないと自己判断する

これは書き方が悪いのではなく、自然言語ルールが 100% 強制にはなりにくいという性質によるものです。

`Hooks` の本質

Hooks は自然言語の説明ではありません。スクリプトです。

イベントで発火する、プログラムレベルの強制ロジックです。

あるイベントが起きれば、そのロジックは必ず実行されます。モデルの判断で飛ばされることはありません。

これが Hooks の最大の価値です。

「守るべき」から「必ず実行される」へ変えることです。

どんなときに `Hooks` に上げるべきか

もし、あるルールをすでに CLAUDE.md や Rules に書いてあるのに、Claude がときどき守り損ねる。そして、その見落としのコストが高い。そういう場合は Hooks に上げるべきです。

要するに：

低リスクならルール
高リスクなら Hooks

典型的な `Hooks` の場面

最も典型的なのは、絶対にミスしてほしくない操作です。たとえば：

メール送信前の確認
Slack、Outlook、Gmail 送信前の確認
危険なファイル削除の遮断
パスワードや API Key の外部送信のブロック

こうした内容が自然言語ルールだけだと、いつか忙しいタイミングでミスが起きる可能性があります。

でも Hooks にしておけば、イベント発生時に必ず止められます。

これは本当の意味でのプログラム的な安全柵です。

`Hooks` のよくあるトリガー地点

Hooks はさまざまな段階に設定できます。たとえば：

会話開始時にリマインドを入れる
ツール実行前に条件を確認する
ツール実行後に結果を検証する

専門用語を全部知っている必要はありません。

多くの場合、「こういう要件がある」「これを hook にすべきか」と明確に説明できれば、Claude が一緒に設計してくれます。

また、/hook コマンドで現在設定されている hooks を確認することもできます。

より実用的な導入順

この4層をつなげて運用するなら、私なら次の順番を勧めます。

ステップ1：まず `/init` で基本版 `CLAUDE.md` を作る

最初から完璧なルール文書を手書きしようとしないことです。

まずは Claude にプロジェクトを見てもらい、たたき台を作ってもらって、そこから育てていくのが自然です。

ステップ2：使いながら足していく

協業の中で、

今後も必ず覚えてほしい
このミスは二度と起こしてほしくない
この好みは毎回効いてほしい

というものが見つかったら、CLAUDE.md に追加していきます。

ステップ3：`CLAUDE.md` が長くなったら `Rules` に分ける

CLAUDE.md がどんどん長くなり、すべてのルールが安定して効かなくなってきたら分割します。

何がグローバルルールか
何が特定パス専用か

後者を Rules に移し、条件付きロードにします。

ステップ4：高リスクなものを `Hooks` に上げる

書いてあるのにまだ漏れる。そして漏れると危険。そういうものは自然言語のままにせず、Hooks に上げます。

つまり「リマインド」を「強制実行」に変えるわけです。

ステップ5：一時状態は `Memory` に任せる

期限があるもの、変化するもの、長期制度ではないものは、何でも CLAUDE.md に入れないことです。

たとえば：

現在のプロジェクト進捗
最近の協業相手
最近増えた好み
直近の計画や ToDo

こうしたものは Memory に持たせたほうが、コンテキストもすっきりし、モデルの挙動も安定しやすくなります。

4層それぞれに何を入れるか

手早く覚えるなら、次の整理で十分です。

CLAUDE.md：長期的な共通認識、グローバルな説明、プロジェクトの基礎背景
Rules：パスや場面ごとに読み込む専門ルール
Memory：動的な知識、一時状態、最近学んだこと
Hooks：高リスク操作をプログラム的に強制制御する層

まとめ

Claude Code を「コードを書けるチャット画面」として使う人は多いですが、深く使うほど、それは長期協業のための知的な作業台に近いと分かってきます。

重要なのは毎回の指示文だけではありません。安定していて、分かりやすく、積み重ねていける環境を与えられているかどうかです。

この4層、

CLAUDE.md
Rules
Memory
Hooks

をきちんと組めるようになると、あなたとモデルの協業品質はかなり大きく上がります。

毎回ゼロから「自分が誰で、どう働いて、何をしてはいけないか」を説明し直す必要がなくなり、それらが環境の一部として定着するからです。

それこそが、強いモデルを本当に成熟した道具として使うための重要な一歩です。

Memory on KnightLiブログ

ChatGPT、Claude Code、Gemini の記憶機構は何が違うのか

ChatGPT：人を中心にした長期的な好み

Memory Sources：個人化の出所を見えるようにする

Claude Code：コードベースとエンジニアリングルールを中心に

Claude Code Auto Memory：プロジェクト経験を自動で蓄積する

Gemini：Google エコシステムの文脈を中心に

3者の主な違い

どう選び、どう使うか

実用的な分担

短い判断

関連リンク

ChatGPT Release Notes 更新：記憶ソース、GPT-5.5 Instant、表計算アドイン

Memory sources：パーソナライズをより透明に

記憶の制御は依然として重要

GPT-5.5 Instant がデフォルトモデルに

パーソナライズとデフォルトモデルがつながる

ChatGPT for Excel と Google Sheets

利用制限とインストール方法

最近の更新の流れ

短い判断

関連リンク

Claude Code の環境設定4点セット：CLAUDE.md、Rules、Memory、Hooks をまとめて理解する

なぜ単発のプロンプトより環境設定のほうが重要なのか

第1層：CLAUDE.md

CLAUDE.md に書くのに向いていること

とても大事な原則：できるだけ簡潔にする

CLAUDE.md のよくあるスコープ

1. User Level

2. Project Level

どのレベルに置くかをどう判断するか

最初の版をどう書き始めるか

1. /init を使う

2. Claude に整理してもらう

とても実用的な習慣

第2層：Rules

なぜ条件付きロードが重要なのか

CLAUDE.md から Rules に移すべきタイミング

1. CLAUDE.md が長くなりすぎたとき

2. 特定のルールが特定のパスにしか関係しないとき

Rules が最も向いている場面

第3層：Memory

Memory に入るもの

最初の2層との違い

Memory は手動でも書ける

第4層：Hooks

Hooks の本質

どんなときに Hooks に上げるべきか

典型的な Hooks の場面

Hooks のよくあるトリガー地点

より実用的な導入順

ステップ1：まず /init で基本版 CLAUDE.md を作る

ステップ2：使いながら足していく

ステップ3：CLAUDE.md が長くなったら Rules に分ける

ステップ4：高リスクなものを Hooks に上げる

ステップ5：一時状態は Memory に任せる

4層それぞれに何を入れるか

まとめ

第1層：`CLAUDE.md`

`CLAUDE.md` に書くのに向いていること

`CLAUDE.md` のよくあるスコープ

1. `/init` を使う

第2層：`Rules`

`CLAUDE.md` から `Rules` に移すべきタイミング

1. `CLAUDE.md` が長くなりすぎたとき

`Rules` が最も向いている場面

第3層：`Memory`

`Memory` に入るもの

`Memory` は手動でも書ける

第4層：`Hooks`

`Hooks` の本質

どんなときに `Hooks` に上げるべきか

典型的な `Hooks` の場面

`Hooks` のよくあるトリガー地点

ステップ1：まず `/init` で基本版 `CLAUDE.md` を作る

ステップ3：`CLAUDE.md` が長くなったら `Rules` に分ける

ステップ4：高リスクなものを `Hooks` に上げる

ステップ5：一時状態は `Memory` に任せる