先週、6日前に自分が作った機能を開き、Claude Codeにそれを拡張してほしいと頼みました。
それ以降、ファイルには触っていませんでした。コードは動いていました。テストも通っていました。何も燃えていません。ただ、小さな機能を追加したかっただけです——15分くらいの作業、たぶん。
返ってきたのは、拡張ではありませんでした。静かな“いじり”でした。
「これを拡張する前に、リファクタリングをおすすめします。現状の実装にはいくつか問題があります。エラーハンドリングが一貫していない、この関数は名前が示す以上のことをしていて、重複したバリデーションブロックがあるのでヘルパーにすべきです。まずそれらを直しましょうか？」
読者の皆さん、そのコードを書いたのはClaude Codeでした。同じプロジェクト。同じモデルの階層。6日前。いま私に対して、礼儀正しい自信に満ちた口調で「めちゃくちゃだ」と告げているのと同じエージェントが書いたものです。
私はそれを少し考えました。次に、それが意味することを考え始めました。なぜなら考えれば考えるほど、これ——このまさに瞬間——は、AIコーディングエージェントについて誰も書いていない“もの”だと気づいたからです。
みんなが文句を言う「メモリ問題」
Claude Code、Codex、Cursorのエージェントモード、あるいは他の何かを使ったことがあるなら、そこで必ずぶつかります。エージェントには、セッション間の連続性がありません。新しい会話は必ず冷えた状態から始まります。先週の火曜日に何を決めたかは覚えていません。特定の抽象化がなぜ存在するのかも覚えていません。そして、この関数に名前を付ける件をあなたがすでに議論して、ある特定のものに落ち着いたことも覚えていません。
これについての議論の多くは、これを解決すべき問題として扱います。メモリシステムを後付けします。CLAUDE.mdファイルを積み重ねます。コンテキスト読み込み用のスクリプトを作ります。暗黙の前提は、エージェントは覚えているはずで、覚えていないことを補うのが作業だ、というものです。
私は、この捉え方こそが完全に逆だと思い始めています。
実際のそのセッションで何が起きたのか
Claude Codeが、6日前の自分のコードを批判したとき、それは一貫していなかったからではありません。誤作動していたわけでもありません。人間の共同作業ではできないやり方で、それは正直だったのです。
いま起きたことを考えてみてください：
- コードに対する自尊心のしがらみがないレビュアーが、あらためて新鮮な目で見た
- なぜそのように書いたのか、何を却下したのか、時間に追われながらどんな妥協をしたのか、そしてテストがようやく通った11時pmにあなたがぶつぶつ言ったことまで、何も覚えていない
- ただコードを、その出来として見て、こう言った：もっと良くできる
これはバグではありません。これまでで一番きれいなコードレビューです。
人間が一週間前の自分のコードをレビューすると、認知バイアスが全部自分に不利に働きます。制約を覚えています。締切を覚えています。「このヘルパーが重複しているのは分かっていた」ことも覚えていますが、関数シグネチャを壊したくなかったのです。過去の判断を守ります。なぜなら過去の判断は自分のものだからです。
Claude Codeは、連続性がないのでそれがありません。どのセッションも、昨日の推論に“買収”されていない新しい二組目の目になります。
リフレーム
これを理解したとき、私はそれを意図的にやり始めました。
今、機能を完成させたらすぐには出荷しません。コミットして寝ます。そして翌朝、新しいClaude Codeのセッションを開き、「これまで一度も見たことがない」かのようにコードをレビューしてもらうのです。そのセッションにとっては、実際にそうだからです。
レビューは厳しいです。でも、ほとんどの場合、正しいです。
見つけてくれるのは例えば：
- 2つのことをしているのに、名前の中でそれを偽っている関数
- ある場所では防御的で、別の場所では存在しないエラーハンドリング
- 抜き出すべきだったのに抜き出していないヘルパー
- 文脈では分かりやすかったのに、冷静に読み直すと持たない命名
- テストは通っているが、誤ったことを検証している
コードを書いたのと同じエージェントでも、書いている最中にはこれらの問題を見抜けません。人間がフローに入っているときと同じようにトンネル視になっているからです。しかし、セッションの記憶を剥がしてファイルを渡すと、リアルタイムでは決してなり得なかったレビュアーに変わります。
「メモリ問題」は実際には、役に立つ別の振る舞いのための“ゲート”です。私たちはそれを活用するのではなく、取り除こうとしてきました。
これがCLAUDE.mdの捉え方を変える理由
私は以前にもCLAUDE.mdについて書きましたが、この経験で何かが明確になったので、そこで述べたことを精錬したいと思います。
CLAUDE.mdはエージェントのメモリではありません。その捉え方は間違っています。
CLAUDE.mdは、セッションごとに毎回蒸し返されるべきではない“プロジェクトの意思決定”の記憶です。たとえば：
- 「Tailwindはv3で使う。v4へは移行しない。」
- 「認証レイヤーは意図的にシンプル。相談なしにOAuthを追加しない。」
- 「テストは /tests ではなく、ソースファイルの隣に置く。」
これらはスタイルではなく決定です。CLAUDE.mdは、エージェントが落ち着いた選択肢について自分自身と毎回議論する時間を無駄にしないようにするためにあります。
しかし、CLAUDE.mdに入れるべきではないものはこういったものです：
- 「この関数はXをする」（コードがそう言っている）
- 「先週、Yをリファクタリングした」（それは履歴であって、意思決定ではない）
- 「私たちが使うパターンはZ」（コードを“真実の出典”として任せてほしい）
間違いは、CLAUDE.mdをメモリのゴミ箱（ダンプ）として使うことです。そうすると、エージェントに連続性を与えようとすることになります——そして“新鮮な目”によるレビューという恩恵を失います。あなたが決めたことすべてに最初から同意している、“頷き役（yes-man）”に、正直なレビュアーを変えてしまうのです。
正しいCLAUDE.mdは短いものです。意思決定を固定します。そして判断は残します。そうすれば、新しいセッションでもあなたのコードがダメだときに、そのことをちゃんと伝えられます。
メンタルモデルの切り替え
AIコーディングエージェントを、時間を通して一貫した協力者のように考えるのはやめましょう。
それは、高品質なレビュアーとして、必要なだけ何度でも呼び出せる存在だと思ってください。前提は、推論ではなく“意思決定”を保持することです。
この考え方はワークフローを変えます：
- あるセッションではエージェントと一緒にコードを書く
- 動いたらコミットする
- 翌日に新しいセッションを開き、レビューを依頼する
- 批判を真剣に受け止める。そこには、昨日の判断を守ろうとする人がいないからだ
- 批判が間違っているなら、それはCLAUDE.mdに意思決定が欠けているサイン
- 批判が正しいなら直す。同じエージェントがコードを書いたという事実は関係ない
これを採用してから、明らかにもっときれいなコードを出荷するようになりました。Claude Codeが賢くなったからではありません。私は、セッション同士を“つなぎ合わせようとする”のをやめて、それらの間にできるギャップを使い始めたからです。
最後のひとこと
今、AIエージェントをより連続的にする、よりメモリを持たせる、セッションをまたいで“より意識できる”ようにするための取り組みに、多くのエネルギーが注がれています。長時間動作するエージェント。永続的なコンテキスト。メモリ層。
私はそれらに反対ではありません。でも、私はその“加速”が価値ある何かを隠していると思います。セッション間の非連続性こそが、エージェントを共感的なチームメイトではなく、実際のレビュアーにするものです。完全なメモリを与えてしまうと、コードを外側から見られなくなり、人間のように過去の判断を守り始めてしまいます。
たぶん目標は、エージェントに連続性を与えることではありません。もしかすると、与えるのは十分なだけ——つまり落ち着いた意思決定だけ——にして、残りは守らないようにすることなのかもしれません。コードがそういうふうに出来上がった過程は忘れさせましょう。新鮮な目で「それはダメだ」と言えるようにしましょう。
私のはそうでした。正しかったのです。
Claude Codeは、あなたのプロジェクトで自分自身の過去の出力をいじったことがありますか？一番ひどいやつを聞きたいです——コメント欄に投下してください。
