← 2026-05-04
Claude Code Official 2026-05-04 Source →

Claude Code Tips — 公式ベストプラクティス2026年版：見落としがちな5つのパターン

Claude Code Tips — 公式ベストプラクティス2026年版：見落としがちな5つのパターン

Anthropicの公式ベストプラクティスドキュメントが2026年版として大幅にアップデートされた。基本的なことは変わっていないが、新しいコマンドや機能を前提にした実践的なパターンが多数追加されている。「そうだったのか」と思える内容をピックアップする。

1. Claude に仕様策定のインタビューをさせる

大きめの機能を実装するとき、「何を作るか」がまだ曖昧な状態でいきなりコーディングに入ると Claude が迷走しやすい。公式が推奨する方法がこれ：

[機能の概要] を実装したい。
AskUserQuestion ツールを使って詳細をインタビューしてほしい。

技術的な実装方法、UI/UX、エッジケース、懸念事項、トレードオフについて聞いて。
明らかなことは聞かなくていい — 私が考えていないかもしれない難しい部分を掘り下げて。

十分に網羅できたら、完全な仕様を SPEC.md に書いてほしい。

Claude が AskUserQuestion ツールで対話的にインタビューを実施し、洗い出せたら SPEC.md に仕様としてまとめる。その後、新しいセッションを開いてその仕様を元に実装を依頼する。

仕様策定セッションと実装セッションを分けるのがポイント。実装セッションはコンテキストがクリーンで、書かれた仕様に集中できる状態になる。

2. /btw — コンテキストを汚染しない「ちょっと聞き」コマンド

実装中に「あのAPIの仕様どうだっけ」「この変数名で合ってるっけ」と確認したいことが出てくる。これをメインの会話に入れると、無関係な内容がコンテキストを占有してしまう。

/btw はこの問題を解決するコマンド：

/btw このプロジェクトの Python バージョンって何?

答えがオーバーレイで表示されて、会話履歴には一切残らない。確認が終わったらオーバーレイを閉じるだけ。

コンテキストウィンドウを節約しながら気軽に確認できる。複雑な実装の途中でドキュメントやコードの内容を確認するときに特に便利。

3. Writer/Reviewer パターン — 別セッションで相互レビュー

一つのセッションで「実装して自分でレビューする」という使い方は、Claude が「書いたコードをそのまま正しいと判断しがちになる」という問題がある。

公式が推奨する Writer/Reviewer パターン：

セッション A（Writer） セッション B（Reviewer）
レート制限ミドルウェアを実装して
@src/middleware/rateLimiter.ts のレート制限実装をレビューして。エッジケース、競合状態、既存のミドルウェアパターンとの整合性を確認して。
レビューフィードバック：[セッションB の出力]。これらの問題を修正して。

レビュアーセッションは「書いていない」ので、コードに対してより批判的な視点を持てる。同じコードに対して独立した判断を得られる。

テスト先行パターンも同様：セッション A でテストだけを書き、セッション B でそのテストを通すコードを書く。

4. 調査にはサブエージェントを使ってコンテキストを守る

investigate や analyze という依頼をするとき、Claude はコードベースを広範囲に読み込む。これがメインのコンテキストウィンドウに蓄積されると、後の実装作業の精度が落ちる。

サブエージェントを使って、認証システムがトークンリフレッシュをどう処理しているか、
また再利用できる既存の OAuth ユーティリティがあるかを調査して。

サブエージェントは別のコンテキストウィンドウで動作し、調査結果のサマリーだけをメインセッションに返す。「調査で100ファイル読み込む → メインコンテキストが汚染される」という問題を避けられる。

実装後の検証にも使える：

サブエージェントを使ってこのコードのエッジケースをレビューして

コンテキストが汚染されていないサブエージェントが、より客観的なレビューをしてくれる。

5. CLAUDE.md の書き方：足し算より引き算

CLAUDE.md が長くなるほど Claude が内容を無視するようになる。これが最大の落とし穴。

入れるべき内容

入れてはいけない内容

チェック方法

各行に対して「これを消したら Claude がミスをするか？」と自問する。答えが No なら削除する。CLAUDE.md はプロジェクトと共に進化するもので、定期的なプルーニングが必要。

また、繰り返し同じルールを Claude が無視するなら、CLAUDE.md が長すぎるサインかもしれない。その場合はフックに変換するのが有効（フックはアドバイスではなく確定実行）。

まとめ

パターン コマンド/方法 効果
仕様インタビュー AskUserQuestion でインタビュー 実装前に要件を固める
サイドクエスチョン /btw コンテキスト汚染なし
Writer/Reviewer 2つのセッションで相互レビュー 客観性のあるレビュー
調査をサブエージェントに サブエージェントを使って調査して メインコンテキスト保護
CLAUDE.md の節制 引き算思考で管理 指示の遵守率向上

どれもすぐ試せる内容なので、次の作業セッションで一つずつ取り入れてみると良い。

ソース: Best practices for Claude Code