はじめに

Claude Codeを導入したのに、期待したほど速くならない。

原因はモデルでもプランでもなく、使い方にある。ここまでは、多くの実践者が同じ結論に達している。よく挙がる7つの型も、大枠では今も有効だ。

ただ、この分野は仕様変更が速い。数か月前に書かれた対策の中には、前提が変わっているものがある。

とくに大きいのがMCPまわりになる。「全部つなぐな、必要な分だけつなげ」という定番の助言は、ツール検索が既定で有効になったことで、状況が変わった。理由も、対策も、いま書き直す価値がある。

この記事では、よくある7つの型を2026年7月時点の仕様で検証し直し、8つ目を足す。扱う内容は次のとおり。

CLAUDE.md のコストが実際どう発生しているか（プロンプトキャッシュを踏まえた正確な話）
命令を置く3層と、その判定基準
/compact の事故を仕組みで防ぐ方法
MCPの前提が変わった件と、それでも残る注意点
設計と実装の境界線
レビューを人間の善意に任せない方法
権限設計という、8つ目の見落とし

1. CLAUDE.md を全部入りにする

命名規約、過去の経緯、ディレクトリ構成、心構え。全部 CLAUDE.md に書き込んで2000行になっていないだろうか。

コストの構造を正確に押さえる

この問題はよく「毎ターン2000行分のトークンを払っている」と説明される。方向は正しいが、実際の課金構造は少し違う。

プロンプトキャッシュが効くため、変化しない前置き部分は2回目以降キャッシュ側の安価な単価で処理される。だから直接の課金は、素朴な計算ほど跳ねない。

では問題ないのかというと、そうではない。より重い問題が2つある。

ひとつ、コンテキストを恒久的に占有する。 CLAUDE.md は最初のユーザーメッセージより前に読み込まれ、セッション中ずっと居座る。2000行を置けば、その分だけ実作業に使える領域が減り、圧縮の発動も早まる。キャッシュに乗っていても、場所は取る。

ふたつ、長いほど無視される。 指示が増えるほど、個々の指示が守られる確率は下がる。全部書けば全部守られる、とはならない。

つまり、削る理由は財布よりも精度にある。目安は200行程度になる。

削る基準

各行にこう問う。

これを削ったらClaudeは間違えるか → 間違えないなら削る
README やスキルで提供できるか → できるなら移す
常に必要か、特定の場面でだけ必要か → 場面限定ならスキルへ

3層で考える

「CLAUDE.md は憲法、Skills は六法全書」という整理は分かりやすい。ここに3層目を足すと、判断がさらに機械的になる。

置き場所	判定基準
CLAUDE.md	毎ターン真でなければならない前提
Skills（`.claude/skills/`）	ある場面でだけ必要な手順
Hooks（`.claude/settings.json`）	知識に関係なく必ず起きるべき処理

判定は一文で済む。毎ターン真でなければならないなら CLAUDE.md、たまに必要な手順ならスキル、自動で走るべきスクリプトならフック。

3層目が重要な理由は、公式ドキュメントに明記がある。

権限ルールを強制するのはClaude Codeであって、モデルではない。プロンプトやCLAUDE.mdの指示はClaudeが何をしようとするかを形作るが、Claude Codeが何を許可するかは変えない。

CLAUDE.md に「必ずlintを実行すること」と書いても、それは要望にとどまる。確実に実行させたいならフックに置く。文章で強制しようとするから、指示が増え、そして守られなくなる。

スキルにも上限がある

なお「CLAUDE.md からスキルへ逃がせば無料」ではない点も押さえておきたい。

スキルは本文こそ呼ばれた時に読まれるが、どのスキルがあるかを判断するための説明文は起動時に必要になる。数が増えれば、そこも積み上がる。

目安として8〜12個で日常の大半はカバーできる。月に一度棚卸しし、しばらく発動していないものは削る。スキルフォルダは、増える一方ではなく、価値のあるものへ縮んでいく状態を保つ。

2. 1つの指示に作業を全部詰める

「テスト直して、リファクタして、ドキュメントも更新して、ついでにPRも作って」

これをやると、途中で何をしていたか見失う。長いコンテキストの中盤は注意が薄くなる、いわゆる lost in the middle の問題が効いてくる。

対策は、責務をサブエージェントに切り出すことになる。

---
name: reviewer
description: 差分のバグだけを淡々と指摘する。実装はしない
tools: Read, Grep, Bash
---

あなたはレビュー専任になる。
修正提案ではなく「どこが・なぜ壊れるか」だけを返すこと。

レビュー、テスト実行、多言語ファイルの整合チェック。毎回同じ依頼はサブエージェント化した瞬間に効く。

利点は注意力だけではない。サブエージェントは独立したコンテキストを持つため、調査で大量のファイルを読んでも、メインの会話が汚れない。

メインの会話は指揮官に保つ。手を動かすのではなく、命令を出す場所にする。

3. 実装の途中で /compact を打つ

コンテキストが膨らむと反射的に /compact していないだろうか。これが事故の引き金になる。

圧縮の過程で「これから何をするつもりだったか」が要約に丸められて消える。再開したClaudeは、さっき自分で立てた設計を忘れ、半分だけ実装された土台の上に別の実装を重ねてくる。そして気づきにくい。動いて見えるからだ。

対策を3段階で持つ

計画をディスクに出す。 長い作業は最初に PLAN.md へ書き出させる。コンテキストが飛んでも、計画はファイルに残る。会話は揮発、ファイルは不揮発。この非対称を利用する。

区切りでだけ打つ。 コミット直後など、作業の切れ目で実行する。実装の途中は危ない。

PreCompactフックで保護する。 ここが、対策として一段強い。圧縮の直前に走るフックが用意されているため、要約で失われては困る状態を、その時点でファイルへ書き出せる。人間が忘れても仕組みが動く。

事故った時の救済

/rewind は以前のチェックポイントへ戻す機能だが、/clear 実行前の会話コンテキストの復元にも対応した。誤って消した時の保険として覚えておきたい。

そもそも測る

/context で現在の使用状況を可視化できる。「膨らんできた気がする」ではなく、数字を見てから判断する。長時間のセッションでは、定期的に確認する習慣が効く。

4. MCPを全部盛りでつなぐ ← 前提が変わった

Slack、GitHub、Notion、ブラウザ、ファイル系。便利そうだから全部つなぎっぱなし。

この問題の深刻さは、数字で見ると分かる。MCPツールの定義ひとつが200〜800トークンかかる。50ツールを持つサーバーを3つつなげば、ツール定義だけで6万トークンを消費する。毎ターン、モデルがメッセージを1行も読む前にだ。200Kのコンテキストウィンドウが、会話が始まる前に30%を失う。

だから「必要な分だけつなげ」が定番の助言だった。

2026年の現状

ここが更新点になる。公式ドキュメントの記述はこうだ。

ツール検索は既定で有効になっている。MCPツールは事前にコンテキストへ読み込まれるのではなく遅延され、タスクが必要とした時にClaudeが検索ツールで関連するものを見つける。実際に使うツールだけがコンテキストへ入る。利用者から見た挙動は、これまでと変わらない。

効果も公表されている。ツール検索ツールは19万1300トークンのコンテキストを保持する。従来方式では12万2800トークンだった。トークン使用量で85%の削減になる。

精度も上がっている。大規模なツールライブラリを扱う内部評価では、MCPの評価スコアが Opus 4 で49%から74%へ、Opus 4.5 で79.5%から88.1%へ改善した。

つまり「つないだ瞬間にコンテキストを食う」という前提は、既定の構成では成り立たなくなっている。

閾値方式を好むなら設定もできる。ENABLE_TOOL_SEARCH=auto を設定すると、スキーマがコンテキストウィンドウの10%以内に収まる場合は事前読み込みし、超過分だけを遅延させる。

それでも残る理由

では無制限につないでいいのか。3つの理由で、まだ絞る価値がある。

レイテンシ。 各ツールの初回呼び出しに検索の一手間が入る。頻繁に使うものほど、この差が積み上がる。

検索精度がサーバーの説明文に依存する。 MCPサーバーを作る側にとって、server instructions フィールドがツール検索の有効化で重要度を増した。この説明が、Claudeがいつそのツールを検索すべきかを理解する助けになる。なおClaude Codeはツールの説明と server instructions をそれぞれ2KBで切り詰める。説明が雑なサーバーは、必要な場面で見つけてもらえない。

既知の不具合がある。 遅延読み込みされたツールが最初のターンで利用できず、定期実行タスクが壊れるという報告や、圧縮の過程で遅延ツールへの参照が失われるという報告が上がっている。CI や自動実行では、予測可能な挙動を優先したい場面がある。

信頼境界が広がる。 これは技術的な話ではない。つないだサーバーの数だけ、信頼すべき相手と認証情報が増える。コンテキストの問題が解決しても、この問題は残る。

結論

「コンテキストを食うから絞る」という理由は弱まった。「説明できるものだけ入れる」に置き換える。

各サーバーについて「なぜこれが必要か」を一文で言えるか。言えないなら外す。この基準なら、仕様が変わっても陳腐化しない。

5. 設計まで丸投げする

「いい感じにアプリ作って」

出てくるのは、いい感じに見える地雷になる。

具体例を挙げたい。Swiftネイティブの PKPushRegistry を let のローカル変数で受けるコードが生成され、着信しない通話アプリができあがる。レジストリが解放されてプッシュが届かない。

このバグの性質をよく見てほしい。コンパイルは通る。実行もできる。テストも書きようがある。それでも動かない。

AIは「動くように見えるコード」を書くのが上手い。だから寿命、所有権、スレッドの問題は平気ですり抜ける。これらは型システムにもテストにも現れにくいからだ。

境界線

設計は人間、実装はAI。 この境界を譲らない。

「何を作るか」「どういう構造か」は人間が決める
AIは「どう書くか」の高速な手足になる
小さく投げる → 検証 → 直す → また投げる。一発完成を狙わない
ネイティブ層、並行処理、ライフサイクルが絡む箇所は、生成後に人間が所有権とスレッドを目視する

最後の項目は、前の記事でも触れた「荷重を受け持つ理解」の話につながる。それを知らないと生成物の誤りに気づけない領域は、委譲してはいけない。PushKitのケースは、まさにそれだった。

6. レビューを人間の善意に任せる

「AIが書いたから大丈夫」は逆になる。

生成速度が上がったぶん、レビューの重要性は上がる。バグの絶対量は減らず、流入速度だけが上がるからだ。手に入れたのはバグを高速生成する装置であって、品質保証ではない。

差分を小さく保つ

ここで押さえたいのは、レビューの質がレビュアーの能力ではなく差分の大きさで決まる点になる。

1500行のPRは、誰も真面目にレビューしない。ざっと眺めて、承認して、祈る。これはレビュアーの怠慢ではなく、人間の注意力の限界の話だ。

同じことがAIレビュアーにも起きる。大きな差分でノイズを返すレビュアーが、小さな差分では有用な指摘を返す。賢くなったのではなく、解ける問題を与えただけになる。

仕組みで守る

だから対策は「もっと丁寧にレビューする」ではない。差分を小さくする仕組みを入れる。

# 例：変更行数が閾値を超えたら落とす
- name: Diff size gate
  run: |
    CHANGED=$(git diff --shortstat origin/main...HEAD | awk '{print $4 + $6}')
    if [ "${CHANGED:-0}" -gt 400 ]; then
      echo "差分が大きすぎる（${CHANGED}行）。分割して出し直すこと。"
      exit 1
    fi

閾値はチームで決めればいい。重要なのは、人間の善意ではなくCIが止めるという点になる。

レビューの指示範囲を絞る

レビュー役に「問題点を探して」とだけ指示すると、実害のない指摘まで大量に返ってくる。それを律儀に全部潰すと、不要な抽象化と過剰な防御的コードが増える。

「正しさや要件に影響する問題だけ報告して、それ以外は任意扱いにして」と範囲を指定する。

そして「テストが通った」は「正しい」ではない。テストが何を保証していないかを、毎回聞く。

7. 同じ会話を朝から晩まで引きずる

1セッションで一日中作業を続ける。コンテキストは伸び続け、応答は少しずつズレ、トークンは静かに溶ける。それを「AIと深く対話している」と解釈してしまう。

タスクが変わったらセッションを切る。「Supabase関数を直す」と「多言語対応を足す」は、別の脳でやる。

長期の文脈は会話ではなくファイルに永続化する。CLAUDE.md、Skills、PLAN.md。会話は揮発、ファイルは不揮発。

会話を育てるのではなく、仕組みを育てる。 これが発想の転換として一番効く。

8. 権限を「全部確認」か「全部スキップ」の二択にする

ここからが追加分になる。速度の話をするとき、権限設計はほぼ議論されない。だが実際には、確認プロンプトが最大の摩擦になっている場面が多い。

そして多くの人が、二択で考えている。既定のまま毎回確認するか、--dangerously-skip-permissions で全部飛ばすか。

実際には段階がある。Claude Codeには複数の権限モードがあり、設定ファイルの defaultMode で指定する。

モード	動作	リスク
`default`	各ツールの初回使用時に確認	低
`plan`	読み取りと探索のみ	低
`acceptEdits`	ファイル編集と作業ディレクトリ内の基本的なfsコマンドを自動承認	中
`auto`	背後の安全チェック付きで自動承認	中
`bypassPermissions`	確認をほぼすべてスキップ	高

日常の答えは acceptEdits になることが多い。ファイル編集は通り、シェルコマンドは確認が入る。摩擦の大半が消えて、リスクの大半は残らない。

サンドボックスという上位互換

さらに良い選択肢もある。権限とサンドボックスは補完的なセキュリティ層になる。権限はどのツールをどのファイル・ドメインに使えるかを制御し、サンドボックスはBashツールとその子プロセスにOSレベルのファイルシステム・ネットワーク隔離を提供する。

サンドボックスを有効にし autoAllowBashIfSandboxed を既定の true のままにすると、サンドボックス内のBashコマンドは確認なしで実行される。サンドボックスの境界が、ツール全体への確認を代替する。

決定的な違いはここにある。プロンプトインジェクションがClaudeの判断を迂回した場合でも、サンドボックスの制限はBashコマンドが境界の外へ到達することを防ぐ。

許可リストは「Claudeが正しく判断すること」を前提にしている。サンドボックスはその前提を要らなくする。自律的に長く走らせたいなら、こちらを選ぶ。

最初に入れておくもの

.env の保護だけは、今日やっておきたい。

{
  "permissions": {
    "deny": ["Read(.env)", "Read(.env.*)"]
  }
}

ルールは deny、ask、allow の順に評価される。この順序での最初の一致が結果を決める。denyは他のどのレベルの許可よりも強い。

対応表

よくある状態	対策
CLAUDE.md が全部入り	200行を目安に。場面限定はスキル、強制はフック
1指示に全作業を詰める	サブエージェントで責務とコンテキストを分離
実装途中の `/compact`	区切りで打つ。計画は PLAN.md、保護は PreCompact フック
MCP を絞れず不安	ツール検索が既定。理由を説明できるものだけ残す
設計まで丸投げ	設計は人間。寿命・所有権・スレッドは目視
レビューを気合で回す	差分サイズをCIで止める。指摘範囲を指定する
同じ会話を延々使う	タスクで切る。文脈はファイルへ
権限が二択	`acceptEdits` かサンドボックス。`.env` は deny