Claude Code、使い込んでいますか？
CLAUDE.md を書き、スキルを自作し、MCP をつなぎ気づけば立派な「自分専用環境」が育っているはずです。
でも、ある日 /context を叩いてみて、私はふと思いました。
「もしかして、無駄なことを裏側でやってないかな…」と。
具体的には、下記のようなことを思いました。
- 一度も使っていない MCP がコンテキストを大量に食っている
- 作ったまま放置したスキルの description が、毎セッション読み込まれている
- CLAUDE.md は増築を重ねて、どれが重要なルールか分からない
- メモリファイルが積もりに積もっている
Claude Code を利用すると簡単にスキルやルールが追加できる一方で、不要な記述が Claude の効率を下げます。
そこで本記事では、「Claude Code の 3S」= 整理・整頓・清掃 を紹介します。
一度きれいにして終わりではなく、最大効率を発揮し"続ける" ための習慣の話です。
本記事は 2026 年 7 月時点の情報です。機能は更新されるので、最新は Claude Code 公式ドキュメント で確認してください。
なぜ「散らかり」が効率を下げるのか
本題の前に、散らかりの正体を押さえます。
Claude Code の作業効率を支えているのは コンテキスト（作業机の広さ） です。
そして、自分で育てた環境は、セッション開始時にこの机を静かに占有していきます。
-
MCP ツール定義
- つないだ MCP のツール名は起動時に読み込まれる。設定や環境によっては定義全体が机を占有する
-
スキルの description
- スキルが増えるほど、起動時に読み込まれる説明文も増える
-
CLAUDE.md
- 書いた分だけ毎セッション読み込まれる
-
メモリファイル
- 自動で貯まる学びも、放っておくと積もる
机が狭くなると、何が起きるか。
- auto compact（会話の自動要約）が早く訪れ、それまでの文脈が失われやすくなる
- 実行コストが増える（読むものが多い＝トークンを消費する）
- ノイズが増えて精度が下がる（似たスキルで発火が迷う、古いルールに引っ張られる）
つまり、便利を追求して増やしたものが、手入れしないと効率を削る側に回るわけです。
まず /context を叩いてみてください。何がどれだけコンテキストを消費しているかが一目で分かります。
私がチームでこれを見せ合ったとき、「MCP tools の消費割合がデカすぎる」「Memory files がすごく多い」と、各自の散らかりポイントが見事にバラバラで面白かったです。掃除の第一歩は、汚れの見える化です。
ここからが本題。整理・整頓・清掃の 3S を、ひとつずつ見ていきます。
S1 整理 要らないものを捨てる
最初は 整理 です。
要るものと要らないものを分け、要らないものを手放します。
使っていない MCP を無効にする
チームで /context を見せ合ったとき、コンテキスト消費の大物になっていたのが MCP ツール定義でした。
つないだこと自体に満足して使っていない MCP、ありませんか。
- 使っていない MCP は
/mcpコマンドから disabled にする - GitHub MCP のように CLI で代替できるものは CLI に切り替える（
ghコマンドで十分なことは多い）
完全にゼロを目指す必要はありません。「よく使うものだけ残す」で、消費は大きく減ります。
最近の Claude Code には tool search（ツール検索） の仕組みがあり、デフォルトでは MCP ツールの詳細定義は「必要になったときに」読み込まれるようになりました。以前ほど「つないだだけで大量消費」ではなくなっています。
とはいえ、ツール名は起動時に読み込まれますし、設定や環境によっては全定義が載ることもあります。思い込みで判断せず、/context の実測で判断するのが確実です。
使っていない・重複したスキルを捨てる
スキルの棚卸しです。
判断基準はシンプルです。
-
一度も発火していない
- → 本当に要るか見直す。要るなら次の「整頓」へ、不要なら消す
-
似た機能が複数ある
- → ひとつに統合する
-
その場のノリで作った一度きりの作業
- → 思い切って削除する
「もったいないから残す」が、一番もったいない状態を作ります。
スキルは多いほど Claude の判断対象が増え、発火がブレる原因になります。
使っていないものを消すのは、残ったスキルを効かせるための投資です。
特に効いたのが統合でした。
似たようなレビュー系スキルが分散していたのを役割で 1 つにまとめると、「どれを呼べばいいか」を Claude も自分も迷わなくなりました。
また、Claude Code にスキルの使用回数を調べてもらうことも可能です。
直近1〜2ヶ月で利用していないものを消してしまうのも良いと思います。
CLAUDE.md をダイエットさせる
CLAUDE.md は増築されがちです。「あれも守らせたい」「これも書いておこう」で膨らんだ結果、どれが重要か Claude も判断できなくなります。
- もう守らせる必要のなくなったルールを消す
- 「絶対守ること」と「できれば」を分け、優先度をつける
- 迷ったら公式の Best Practices と見比べて削る
私のチームでも「Best Practices を参考に CLAUDE.md をダイエットさせた」という報告があり、定番の掃除メニューになりつつあります。
S2 整頓 使いやすい場所に、使いやすい形で置く
次は 整頓。残したものを「効きやすい状態」に並べ直します。
スキルのトリガーを、自分の言い回しに合わせる
スキルは description に書いたトリガーを見て起動します。
「作ったのに発火しない」ものの多くは、トリガーが自分の言い回しと合っていないだけです。
# Before: 漠然としていて発火しにくい
description: コードをレビューする
# After: 自分が普段使う言い回しを具体的に並べる
description: >
コードをレビューするスキル。
トリガー: "レビューして", "review", "コードチェック", "見て", "確認して"
自分が実際にどう話しかけるかを思い出して、その言葉を入れておく。
これだけで、眠っていたスキルが息を吹き返します。
手動で呼ぶスキルは、コンテキストから追い出す
逆に「自動で発火してほしくない、手動で呼べば十分」なスキルもあります。
その場合は YAML フロントマターに 1 行足します。
disable-model-invocation: true
これで description が起動時のコンテキストに含まれなくなり、/skill-name で呼んだときだけフルスキルが読み込まれます。
「自動発火してほしいもの」と「手動で十分なもの」を仕分けて置き場所を変える、これが整頓です。
CLAUDE.md は優先度とリンクで構造化する
残したルールも、平置きせず並べ方を工夫します。
- 優先度を明記する（P0: 必須 / P1: 推奨、のように）
- 特定ディレクトリだけで効かせたいルールは、
.claude/rules/配下のルールファイルに分割し、frontmatter のpathsで対象パスを指定する。対象ファイルを触るときだけ読まれるようになる
@path/to/file.md 形式の import でルールを別ファイルに切り出す方法もありますが、import は起動時に展開して読み込まれるため、見た目が整理されるだけでコンテキスト削減にはなりません。机を広くしたいなら、paths 指定のルールファイルやスキルへの切り出しが有効です。
「全部を毎回読ませる」から「必要なものが必要なときに読まれる」に近づけるほど、机は広く保てます。
S3 清掃 古くなったものを点検し、磨く
最後は 清掃。中身が古くなっていないか、定期的に点検して手入れします。
スキル・設定の「賞味期限切れ」を直す
スキルや CLAUDE.md は「書いたら終わり」ではありません。
外の世界（ツール・バージョン・チームのルール）は動き続けているので、書いた当時の前提がいつのまにか壊れています。
私が実際に出くわした例です。
- 連携していた MCP の仕様が変わり、スキルの手順が通らなくなっていた
- 参照していたファイルパスやコマンドが、プロジェクトの変更で古くなっていた
- チームのルールが変わったのに、スキルが昔のルールのまま
特に 月 1 回しか使わないスキルは危険です。
動かしていない間に世界が動いていて、いざ使おうとすると「先月は動いたのに」となる。点検しないと、肝心なときに壊れています。
さらに言えば、CLAUDE.md や AGENTS.md のベストプラクティス自体が半年で様変わりします。
カスタムスラッシュコマンドがスキルに統合されたように、Claude Code 本体の進化で「昔の正解」が「今の遠回り」になることも珍しくありません。中身だけでなく、書き方の前提ごと定期的に見直す価値があります。
メモリファイルを棚卸しする
auto memory（自動メモリ）は便利ですが、貯まる一方だと /context で「Memory files が多すぎる」状態になります。
役目を終えたメモリ（終わったプロジェクトの事情、直った問題のメモ）は消す。
内容が古くなったものは書き換える。自動で貯まるものこそ、手動の棚卸しが要ります。
セッションの机も、こまめに拭く
環境だけでなく、セッション中のコンテキストにも清掃があります。
清掃のコツは、「使うたびに、ついでに点検する」ことです。
スキルの出力に違和感があればその場で手順を見直す。
大掃除を待たず、こまめに拭くことで負担が小さくて続きます。
とはいえ使う度にというのは難しいということであれば週の終わりに Claude と壁打ちしてみるだけでも良いと思います！
おまけ: 3S を「仕組み」で回す
3S を「気が向いたらやる」だと、結局たまります。
私が取り入れているのは、点検そのものを仕組みにすることです。
-
/statuslineで残りコンテキストを常時表示する。汚れが常に目に入る状態にしておくと、掃除のタイミングを逃しません - 設定ファイルのレビューを定期実行に組み込む。チームには「Claude の設定ファイル群のレビューを毎朝 cron で自動的に回している」猛者もいます
- 月初にスキル・MCP・メモリを棚卸しするをルーティンに入れる
- 成果物を別の AI にダブルチェックさせる工程を習慣化し、劣化に気づく目を増やす
意識でやろうとすると続きません。
3S を回す「仕組み」までセットで作るのが、長続きのコツでした。
まとめ
Claude Code の 3S
| S | やること | 効果 |
|---|---|---|
| 整理 | 使わない MCP・スキル・ルールを捨てる／統合する | コンテキストが空き、発火が安定する |
| 整頓 | トリガー・呼び出し方法・優先度を見直して並べ直す | 必要なものが必要なときだけ効く |
| 清掃 | 古い手順・メモリを点検し、セッションもこまめに拭く | 「いざ使うとき壊れている」を防ぐ |
本記事の要点は下記のとおりです。
- 育てた環境は、手入れしないとコンテキストを圧迫するノイズになる
- まず
/contextで汚れを見える化する - 整理: 使わない MCP は disabled、重複スキルは統合、CLAUDE.md はダイエット
-
整頓: トリガーは自分の言い回しに、手動スキルは
disable-model-invocation: trueで机の外へ -
清掃: 外の世界は動く。スキル・設定・メモリを定期点検し、セッションも
/clearでこまめに拭く - 仕組み化: statusline・定期レビュー・棚卸しルーティンで、意識に頼らず回す
Claude Code は、作った数より「手入れされて効いている数」も大事です。
しばらく掃除していない人は、ぜひ一度 /context を叩いてみてください。
「作ったまま忘れていた便利なやつ」と「もう要らないやつ」が、きっと両方見つかると思います。