2025年と2026年のClaude Code活用パターンには明確な違いがある。2025年は「コンテキスト管理」が腕の見せどころだったが、2026年はそこが自動化されており、開発者の役割が変わってきた。
以前は「セッションが長くなってきたらいったん会話をクリアして、必要な情報だけ引き継ぐ」というテクニックが当たり前だった。今はコンテキストの自動圧縮（autocompaction）が透過的に動くため、この手作業が要らない。
/plan がネイティブで存在する2025年は「実装に入る前に計画を立てさせる」ために、ユーザー側でプロンプトを工夫する必要があった。今は /plan コマンドがあり、探索・計画フェーズに入ることが明示的にできる。
/plan 認証システムをJWTからPasskeyに移行するこれを打つと Claude は実装せずに計画だけを立て、読み取り専用で調査する。
一番大きな思考の転換がこれだ。
2025年的なアプローチ（避けるべき）：
このファイルを読んで、次にあのファイルを読んで、
Aという箇所を確認してからBを修正して…2026年的なアプローチ：
ユーザー認証にバグがある。ログイン後にセッションが
正しく引き継がれないケースがある。原因を特定して
修正して、テストも追加して。Claude に「何をやるか（what）」を伝え、「どうやるか（how）」は任せる。探索はサブエージェントが並列でやってくれる。
以前は「長いセッション = 品質が落ちる」という経験則があったが、今は逆だ。長いセッションを続けることで：
1つのセッションで機能開発→デプロイ→デバッグ→インフラ移行→セキュリティ監査まで通してやるケースも現実的になっている。
/plan は「建築判断」のときだけ使う/plan の使いどころを見極めることが重要だ。
使うべき場面：
使わなくていい場面：
/plan は強力だが、毎回使うと遅くなる。必要な場面を絞る。
CLAUDE.md を「プロジェクトのすべてを書き込む場所」として扱いすぎると、逆に使いにくくなる。
書くべきもの：
書かなくていいもの：
読み込みに時間がかかるほど詳細に書く必要はない。
CDやデプロイコマンドへのアクセスを許可すると、Claude が開発から検証・デプロイまでをひとつながりで実行できる。
// settings.json での例
{
"permissions": {
"allow": [
"Bash(kubectl:*)",
"Bash(terraform:*)",
"Bash(gh:*)"
]
}
}「AIが本番環境のコマンドを叩く」ことへの心理的ハードルは高いかもしれないが、適切な権限設計とサンドボックスがあれば実用的なオプションになってきている。
2025年に自分で作った「リサーチフェーズ用プロンプト」「コンテキスト管理スクリプト」「バリデーションルーティン」は、今のClaude Codeの機能と重複していることが多い。
むしろそれらが残っていると Claude を混乱させることもある。定期的に「これ、今でも必要か？」と見直す価値がある。
2026年のClaude Code活用の核心は「メカニカルな操作を手放すこと」だ。コンテキスト管理・探索・計画の多くが自動化され、開発者がやるべきことは「何を作りたいか」の指定と「提案のレビュー」に集約されてきた。
使いこなしているエンジニアほど「意外と少ない指示でかなりのことをやってくれる」と感じているはずで、2025年に身につけた「うまく指示するテクニック」の一部は今や不要になっている。