僕の手元では動くのに、同僚のところでは動かない
ども！Claude Code と毎日仕事している龍ちゃんです。
ちょっと前に、同僚と2人で Claude Code を使い始めたときの話なんですけど。せっかくだからと、僕がガッツリ育ててきたリポジトリを、.claude/ の中身ごとまるっと共有したんですよ。これで同僚も僕と同じように使えるはず、と思ってました。
ところが、です。僕の手元ではちゃんと動くのに、同僚のところでは同じようにいかない。一番わかりやすいのは、同じ指示を出してるのに結果が違うってやつ。僕がふわっとお願いするとデザインまで整った成果物が一発で出てくるのに、同僚のところだと崩れたものが出てきたり、コマンドがうまく動かなかったり。「いや、こっちだとちゃんと出るんだけど…？」って、あの不毛なやつです。
原因をたどっていって、行き着いたのは身も蓋もない事実でした。うまくいってたのは、共有リポジトリのおかげじゃなくて、僕のPCの中だけに溜まってた”何か”のおかげだった。リポジトリには乗ってない、僕の手元だけが知ってる前提が、こっそり下支えしてたんですね。しかもその正体を知ったとき、便利を通り越して、正直ちょっとゾッとしました。
今日はその”何か”の正体と、チームで Claude Code を使うときどう構えるか、って話です。
犯人は「勝手に賢くなる」Auto Memory だった
その”何か”の正体が、Auto Memory です。Claude Code が会話の中から「これ覚えとくと良さそう」って学びを勝手に拾って記録してくれる機能ですね（v2.1.32 で登場、v2.1.59 で /memory から管理できるようになりました）。
これ、オンにしてた頃にちょっとゾッとしたことがあって。作業の途中で Claude がしれっと「前回これで失敗したので、回避策としてこっちを確認しますね」って言い出したんですよ。いやいや、その失敗、このセッションでは一度も話してないんですけど、と。Auto Memory がせっせと記録してたわけです。
便利なんですよ、ほんとに。こっちの好みも、よくやる失敗も、勝手に覚えてくれる。雑なプロンプトでもいい感じに解釈してくれるようになる。…でもこれ、よく考えると「僕の入力だから通じてる」だけなんですよね。同僚が同じ雑な指示を出しても、向こうの Claude はそんな学習してないから、通じない。さっきの「同僚で動かない」の正体がこれです。僕の Claude だけ、見えないゲタを履いてたわけ。
しかも保存先がクセモノで、公式にもこう書いてあります。
Auto memory is machine-local. … Files are not shared across machines or cloud environments.
（Auto memory はマシンローカルです。ファイルはマシン間・クラウド環境間で共有されません）
— Claude Code 公式ドキュメント
この マシンローカル（machine-local） ってのがミソで、保存先は ~/.claude/projects/<project>/memory/、つまり僕のホームディレクトリの中。リポジトリの外で、git にも乗らない。僕のPC1台の中に、Claude の賢さがこっそり溜まっていくんです。
もし公式が対応してるぞ！って情報があったら教えてください。すぐブログを公開停止にするんでｗ
でも、チーム単位でメモリーをGit管理できるようにするって結構有用だと思うんですよね～
ただ差分が地獄になりそうですけど…
Docker で環境を揃えたのに、AIの賢さだけPCに残るのは違う
で、ここが僕的に一番引っかかるところで。
僕、開発環境は基本ぜんぶ Docker 化してるんですよ。「Docker さえ入ってれば、どのPCでも同じ環境が立ち上がる」状態にしてある（Docker じゃなくてもいいんですけど、要は”誰のPCでも同じになるように揃える”あれです）。PC を乗り換えても、認証を通せばすぐ元通り。「俺の環境だと動くんだけど」っていう、あの不毛なやつを消したくて、けっこうな手間をかけてきました。
その努力をしておいて、AIの賢さだけが僕のPCのローカルに溜まってたら、本末転倒じゃないですか。環境は再現できるのに、Claude の振る舞いだけは僕のPCでしか再現しない。せっかく追い出したPC依存を、Auto Memory が裏口からこっそり呼び戻してるのと同じなんですよね。
そもそも僕、git で管理できない設定やメモリって、あんまり信用してないんですよ。だから Auto Memory は、チーム運用の前提だと意図的に切ってます。リポジトリの設定に CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 と書いて、ガッツリ無効化。「Docker さえあれば同じ」を、Claude の賢さのところまで広げたいんです。
「勝手に学ぶ」と、失敗を育てる気がなくなる
PC依存の話だけじゃないんですよ。Auto Memory って、失敗も勝手に吸収してくれるんですよね。一見ありがたい。でも勝手に吸収されると、「この失敗、どう仕組みに落とそうか」って考えなくなるんですよ。本来なら、失敗を拾って CLAUDE.md やスキルに反映して、環境ごと育てていく——その一番おいしい作業を、Auto Memory がサボらせちゃう。同じ目的に「自動で覚える」と「自分で書く」の2つの道があると、つい自動のほうに任せて、手で書くほうが形骸化するんですよね。ぶっちゃけ僕も、Auto Memory を切って初めて、CLAUDE.md をちゃんと書くようになりました。
それに、メモを書いてるのが Claude 自身なので、何をどう記録するかは人によってバラバラ。Aさんのメモリはよく育ってて、Bさんはこれから、なんてことになる。「教訓」と言いつつ品質が揃わない。チームの共有資産としては、ちょっと危なっかしいんですよね。
実は公式も、Auto Memory は「Claude が自分で書くもの」、CLAUDE.md は「人間が書いてチームで共有するもの」と、はっきり役割を分けてます。
| Auto Memory | CLAUDE.md | |
|---|---|---|
| 書くのは誰 | Claude | あなた（人間） |
| 中身 | 学びとパターン | 指示とルール |
| 有効範囲 | そのPCの中だけ | プロジェクト / チーム / 組織 |
（Claude Code 公式ドキュメントの対比表より）
裏を返すと、チームの教訓は CLAUDE.md に書け、ってことなんですよ。Auto Memory に任せきると、この「CLAUDE.md を育てる」という観点がスポッと抜け落ちる。新しく入った人の Claude もゼロからスタートになっちゃうしね（ちなみに Anthropic 社内でも、新メンバーが CLAUDE.md を読んでコードベースを理解するって使い方をしてるらしいです）。
教訓は「共有できる場所」に昇格させる
じゃあどうするか。やることはシンプルで、Auto Memory の逆をやればいい。「Claude が・自分のPCに・勝手に書く」んじゃなくて、人間が・共有リポジトリに・意図して書く。この「個人のPCに溜まる学びを、チームで共有できる場所に移しかえる」ことを、僕は“昇格”って呼んでます。で、Claude Code には、その昇格先になる”共有できる器”がちゃんと用意されてるんですよ。
- CLAUDE.md … プロジェクトのルールや方針を書く場所。公式も、git に入れてチームで共有しよう、って言ってます（訳が正しければ、ですけどｗ）
.claude/のスキル・コマンド … 繰り返す手順を入れておく。.claude/ごと git に乗せれば、チーム全員が同じものを使えます- サブエージェント … 特定の役割を持たせた専門の Claude ですね。これも
.claude/agents/で共有できます
で、おもしろいのが、この”昇格”の手順、公式には載ってないんですよ。Auto Memory と CLAUDE.md を別物として並べてはくれるけど、つなぎ方は書いてない。だから自分たちで設計するしかない。ここが「自前で管理する」ことの存在理由です。
僕が意識してるのはシンプルで、人間が「これは残す価値があるか」を判断して（ここを Claude任せにしない）、種類で分けて置く。ルールなら CLAUDE.md、手順ならスキル、役割ならサブエージェント。この振り分けが雑だと、また「僕の手元では動くのに」のループに逆戻りです。
実際、このブログを書いてるリポジトリ自体が、昇格の積み重ねでできてます。
- スライドで何度も再発明してた CSS のレイアウト手法
→ 教訓化してスキルのリファレンスに昇格。以来どのプロジェクトでも一発 - アウトライン改訂で Claude が履歴を本文に書き込む失敗
→ 「最新版だけ残す」ルールを CLAUDE.md に昇格。誰の環境でも書き方が揃う
「勝手に学ぶ」んじゃなく「人間が分けて積んだ」結果だから、別のPCでも、新しい人が入っても同じように動く。冒頭で困ってたやつの、ちょうど逆ですね。
じゃあ、どうやって昇格させるの？
「言いたいことは分かったけど、実際どうやって失敗を拾って昇格させるの？」ってところですよね。ここは前に1本まるごと記事にしてるので、そっちも読んでみてください。
やってることはシンプルで、失敗が起きた瞬間に「教訓ファイル」として書き出して、CLAUDE.md やスキルに反映したら消す。「ファイルがある＝まだ直してない」っていう、バグチケットみたいな扱いにしてます。永続的に積み上げるんじゃなくて、消化したら消す。
ミソは分担なんですよね。「こうしてほしかったのに、こうなった」っていう”意図”だけ人間が書いて、原因の分析は Claude に任せる。さっき書いた「判断は人間がやる」が、ここで具体的なプロンプトに落ちてる感じです。実際に僕が投げてるプロンプトもそのまま載せてるので、コピペで試せます。単純に失敗の記録だけでなく、チーム内でのClaude Codeとの付き合い方みたいなところのディスカッションもできるんで結構よいと思いますね。
この記事が「なぜ昇格させるのか（チームと再現性のため）」だとしたら、あっちは「どう昇格させるか」。あっちと合わせて読むと、全部つながるはずです。
おわりに
最後に。ぶっちゃけ、Auto Memory 自体はダメな機能じゃないです。1人で使う分には勝手に賢くなって普通に便利。否定したいわけじゃ全然ない。ぶっちゃけ、チーム全員が Claude Code 熟練者で、各自そのへんを分かった上で使うなら、切らなくてもいいと思います。
でも、これから広めていく段階——みんながまだ手探りのときに、Auto Memory で「なんか動く」状態を作っちゃうと、なんで動いてるのか誰も分からなくなる。だから僕は、今の段階では切る。そして教訓は、勝手に溜めるんじゃなく、ちゃんと分けて、共有できる場所に育てる。
最初の一歩はかんたんです。まず CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 で切る。そのうえで、次に「お、これ覚えとくと良さそう」と思った学びを、1個でいいから自分の手で CLAUDE.md に書いてみる。それだけで「勝手に溜める」から「分けて育てる」に、頭が切り替わると思います。（割と強火な思想なんで失敗からの共有だと優しい目でお願いしますｗ）
Auto Memory は”個人の相棒“、CLAUDE.md やスキルは”チームの資産“。役割が違うんですよね。「Docker さえあれば誰でも同じ」を、AIの賢さのところまで広げる。たぶんそれだけで、隣の人の Claude も、ちゃんと同じように動いてくれるはずです。
ほなまた〜
