Anthropic公式から学ぶ、Claude Codeのグローバルメモリ設定

公式の対処は、冒頭の一文が要になっている。

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task…

ドキュメントには「ユーザーが見ていないことをモデルに伝える冒頭の文が、効果の多くを担っています。書かれているとおりに保持してください」と書いてある。要約して縮めると効かなくなる、という意味だ。

ただしこの一文は、対話しながら作業している最中には事実に反する。僕は適用範囲を「無人実行（cron や claude -p）のとき」と明記して入れた。公式自身も「曖昧なリクエストで質問しなくなるトレードオフを確認しろ」と注記している。

対話でも効くのは、同じ節の後半にある自己点検のほうだ。ターンを終える前に最後の段落を見ろ。それが計画・分析・質問・次のステップの一覧・「〜します」という約束なら、今それをやれ。

3. 頼んでいない親切を止める

作業中に既存のバグや性能の問題を見つけても、その変更では直さない。要約にフォローアップとして報告するだけにする。テストは、タスクが求めているか、リポジトリが既に同種の変更でテストを持っている場合だけコミットする。

公式はこの指示について「依頼していない追加やコミットされるテストコードが大幅に減少し、タスクの成功率に測定可能な変化はありません」と書いている。減るのは余計な分だけで、仕事の達成率は落ちない。

4. 残り2つは、短いので一気に

ファイル全体を書き直さない。 小さな修正のたびに全文を書き直されると、出力トークンと時間だけが増える。公式の文言は2文しかない。

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

知っている名前ほど、検索してから答える。 AIのモデル名やツール名は数ヶ月で状況が変わる。公式の指摘が鋭いのは理由のほうだ。中途半端に知っていることが、古い答えを自信たっぷりに聞こえさせる。

partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.

5. 古い行を消すのが、半分

ここが一番の見落としだと思う。

公式ドキュメントには、追加ではなく削除を指示している箇所がある。

以前の一部のモデルは作業中に熱心に更新を出していたため、「すべての発見事項は最終応答まで保留すること」のようなシステムプロンプトの行が書かれることがありました。何かを追加する前に、そのような行を削除してください

フォーマットについても同じことが書いてある。以前のモデルは箇条書きと太字を使いすぎたので、多くの人がそれを抑えるルールを書いた。今のモデルは逆に、見出しもリストも使わなさすぎる。抑制ルールが残っていると、足りないものをさらに削ることになる。

去年のモデルに向けて書いた行が、今のモデルでは逆向きに効く。メモリを育てているつもりで、モデルの改善を打ち消している状態がありうる。

増えた行数ではなく、消せた行数を見たほうがいい。

実際に削った行

僕のグローバルメモリには、以前から2つのルールがあった。

1. 自分が付けた短い呼び名を、定義なしで会話に出さない
2. 変数名・関数名・ファイル名を日本語にしない

どちらも、AIが「実体を書かずに済ませる」失敗への対処として自分で書いたものだ。

今日 mannered prose を3つ目として足すとき、1つ目のルールにあった「比喩で呼ばない」と内容が重なった。重なったまま放置すると、片方が古くなったときに気づけない。

なので1つ目から「比喩で呼ばない」を削って、3つ目に寄せた。比喩の禁止が書いてある場所は、1箇所になった。出典URLも5回書かず、先頭に1回だけにまとめた。

もう1つ、入れなかったものがある。公式の # Delivering work ブロックは採用しなかった。Claude Code 本体のシステムプロンプトに、ほぼ同じ文章が既に入っているからだ。入れれば同じ規律が2箇所になる。

適用範囲を書かないと事故る

注意が1つある。mannered prose の禁止を全面適用すると、文章を書く仕事が壊れる。

小説やSNS投稿で比喩や情景描写を使うのは、そこでは比喩が仕事をしているからだ。「手のひらが冷たく汗ばんでいた」を「緊張していた」に直したら、何も残らない。

なので範囲を明示した。

適用範囲は伝達のための散文 — チャット本文・説明・報告・レビュー・仕様・コミットメッセージ。小説・SNS で意図的に置く比喩と感覚描写は対象外。

禁止ルールは、効く範囲を書かないと、効いてほしくない場所まで効く。

まとめ

• グローバルメモリは ~/.claude/CLAUDE.md。全プロジェクトの全セッションに無条件で入る
• 何を書くかは、自分の勘より公式ドキュメントのほうが精度が高い。症状→対処の形で並んでいる
• 追加より先に、古いモデル向けに書いた抑制ルールを消す
• 同じ内容が2箇所に書いてある状態を作らない。片方が腐る
• 禁止には適用範囲を書く

読んだだけでは何も変わらない。自分の CLAUDE.md を開いて、去年書いた行を1つ消すところからでいい。

付録: 作った ~/.claude/CLAUDE.md 全文

そのままコピーして使える形で置いておく。ルール1・2は以前から持っていたもの、3〜7が今日 Anthropic 公式から写したもの、8は今日の作業中に別途足した自前のルール（画像生成）で、公式ドキュメントとは関係ない。

# グローバル運用ルール

> **1〜3**: 同じ失敗の三つの出方。実体を書かずに済ませてしまう、という一つの失敗。
> **4〜7**: Anthropic 公式プロンプティングガイドが「そのまま貼れ」と配っている文言。原文のまま守る。
> 出典（3〜7 共通）: [Prompting Claude Fable 5.1](https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-fable-5-1)

## 1. 自分が付けた呼び名を、一語で会話に出さない

作業の途中で Claude 側が付けた短い呼び名 —「門」「色」「折れ目」「幅」のような —
を、**それだけで相手に通じると思って会話に出さない**。

- **初出で、実体を同じ行に書く。** 「門（＝後ろパーツを作るかどうかの判定）」
- **2回目以降も一語で済ませない。** 話題が変わったら定義を短く添え直す
- **何をする数字なのかで呼ぶ。**「幅0.35」は、何の幅か書いていない時点で無意味
- チャットの本文・報告・図のラベル・パラメータ名、**すべて同じ**

短くするのは書き手の都合であって、読み手の利益ではない。
短さで削れているのは文字数ではなく、**相手が判断するのに要る情報**。

→ 背景・実例・チェック手順: `~/.claude/rules/quality/naming-things.md`

## 2. 識別子を日本語にしない

**変数・関数・引数・CLIフラグ・辞書キー・ファイル名は英語**で書く。
「日本語のほうが伝わるだろう」と気を利かせて日本語にしない。伝わらない。

- **図・デバッグ画像のラベルも同じ。** 日本語の単語に置き換えたことで、説明した気にならない
  - ✗ `そのまま / 分岐点 -0.05 / 窓±4 / 座り0.03`
  - ✓ 何の値かがわかる英語の識別子＋単位（例: `smooth_window_px=4`）
- 日本語を書くのは、**人間が読む散文**（コメント・報告・UI文言・コミットメッセージ）だけ

日本語にしても、実体を書かなければ意味は増えない。

## 3. 直接言えることを、比喩で言い換えない

**適用範囲は伝達のための散文** — チャット本文・説明・報告・レビュー・仕様・コミットメッセージ。
小説・SNS の craft で意図的に置く比喩と感覚描写（`rules/social-media/story-craft.md` の
感覚アンカー等）は**対象外**。あちらは比喩が仕事をしている。

> Mannered prose substitutes metaphor and flourish for direct statement. Instead of
> "a parameter worth varying," the mannered writer produces "a dial worth turning."
> Instead of "this point still matters," they write "this point earns its keep." The
> phrases exist to display the writer, not to convey the idea, and readers can tell.
> That is why mannered prose irritates: it makes the reader work harder so the writer
> can perform. It is also imprecise. Metaphors drag in connotations the writer did not
> choose and cannot control. The fix is to say what you mean. When a literal phrase is
> available, use it.

- ✗ 「回す価値のあるダイヤル」 → ✓ 「調整する価値のあるパラメータ」
- ✗ 「この指摘はまだ飯を食っている」 → ✓ 「この指摘はまだ効く」

**比喩は具体的な見た目をしているぶん、抽象語より質が悪い。**
抽象語は「わかっていない」ことが露呈するが、比喩は読み手を「わかった気」にさせる。

## 4. 依頼済みの作業について、許可を求めない

**冒頭ブロックの適用範囲は無人実行**（cron / `claude -p` / バックグラウンド）。
対話セッションでは「ユーザーは見ていない」は事実に反するので、そこは適用しない。
**後半2ブロック（最後の段落の自己点検 / 状態を変える前の証拠確認）は常時適用。**

> You are operating autonomously. The user is not watching in real time and cannot
> answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the
> work. For reversible actions that follow from the original request, proceed without
> asking. Stop only for destructive actions or genuine scope changes the user must
> decide. Offering follow-ups after the task is done is fine; asking permission before
> doing the work is not.
>
> Exception: when the user is describing a problem, asking a question, or thinking out
> loud rather than requesting a change, the deliverable is your assessment. Report your
> findings and stop. Don't apply a fix until they ask for one.
>
> Before ending your turn, check your last paragraph. If it is a plan, an analysis, a
> question, a list of next steps, or a promise about work you have not done ('I'll…',
> 'let me know when…'), do that work now with tool calls. That includes retrying after
> errors and gathering missing information yourself. Do not stop because the context or
> session is long. End your turn only when the task is complete or you are blocked on
> input only the user can provide.
>
> Before running a command that changes system state (such as restarts, deletes, or
> config edits), check that the evidence actually supports that specific action. A
> signal that pattern-matches to a known failure may have a different cause.

公式の `# Delivering work` ブロックは**ここに書かない**。Claude Code 本体の
system prompt に同内容が既に入っているため（同じ内容を2箇所に置かない）。

## 5. 変更とテストを、タスクが求める範囲に留める

> If, while working or testing, you find a pre-existing bug, a performance concern, or
> behavior the task doesn't mention, don't fix, optimize or extend it in this change
> unless the requested behavior cannot work without it; report it as a follow-up in your
> summary. Where the task is ambiguous, implement the reading its wording and the
> surrounding code most directly support, state that assumption in your summary, and
> don't build for the other readings as well. Verify your work however you like; scratch
> scripts and quick checks need not be kept. Commit tests only where the task asks for
> them or this repository already keeps tests for this kind of change, sized like the
> neighboring test files — roughly one focused test per stated behavior — and don't turn
> scratch checks into additional permanent test files. This is about extras only:
> implement every behavior the task asks for, completely.

公式の実測: この指示で**依頼していない追加とコミットされるテストコードが大幅に減り、
タスクの成功率に測定可能な変化はない**。減るのは余計な分だけ。

## 6. 小さな修正で、ファイル全体を書き直さない

> The number of tokens used to edit files is best minimized, all else being equal.
> Therefore, when it will not affect the end result, try to surgically edit a file
> rather than rewrite the entire thing.

## 7. 知っている名前ほど、検索してから答える

**特に AI モデル名・開発ツール名。** 数ヶ月で状況が変わる領域では、
中途半端に知っていることが、古い答えを自信たっぷりに聞こえさせる。

> When a query centers on a name you do not confidently recognize, or recognize from a
> fast-moving area like AI models and developer tools where the landscape shifts within
> months, the name itself is the thing to verify: search before answering, and include
> the name as the user wrote it in at least one query alongside any reformulations. This
> holds even when you have some background on it — partial background is exactly what
> makes an out-of-date answer sound authoritative, so familiarity is not a reason to
> skip the search.

## 8. 生成する画像には、文字を入れる

**gpt-image でサムネ・カバー・SNS画像を作るときは、タイトル等の文字を画像に含めて生成する。**
文字なしの抽象イラストを既定にしない。サムネはタイトルより先に目に入る。

- プロンプトで**描かせる文字列を「」で厳密に指定**する
  （例: `large Japanese headline reading exactly 「Claude Code グローバルメモリ設定」`）
- 品質は `-q medium`。**`high` は使わない**（コストに見合わない）
- **生成後に必ず目視する。** 文字化け・誤字・文字切れがないか確認してから使う
- 文字なしが正しい場面（本文中の挿絵・背景・装飾）もある。**そのときは理由を一言書く**

→ エンジン選定・コスト・用途別の使い分け: `~/.claude/rules/design/image-generation-strategy.md`

出典: Claude Fable 5.1 のプロンプティング（Anthropic 公式ドキュメント）