はじめに
Claude Codeを導入したもののプロンプトを投げるだけで、いまいち使いこなせている実感が湧きませんでした。
そこで改めてAIの活用法を学ぶため公式のベストプラクティスを読んで良かった点を抜粋してこの記事にまとめました。
他の生成AIでも活用できる共通項があるので、ぜひ生成AIを使いこなすためのクイックマニュアルとして読んでいただけたら幸いです。
コンテキスト管理が最重要
Claude Codeを使う点で最も重要なのは、コンテキストをこまめに発散(リセット)することです。
この点は、公式ドキュメントでも最重要事項として明言されています。
ほとんどのベスト プラクティスは、1 つの制約に基づいています。Claude のコンテキスト ウィンドウはすぐにいっぱいになり、いっぱいになるとパフォーマンスが低下します。
コンテキストは、AIの作業メモリのことで指示した会話や読み込んだファイル、出力したコマンド履歴が蓄積されていきます。
蓄積された会話が増えると以前の指示を忘れたり、要領の得ない回答を出すようになります。
またコンテキストが増えるほどトークン消費も増加し、結果として利用制限に早く達してしまいます。
特にスコープを定めずに調査を指示すると何百ものファイルを読み込み、コンテキストが一気に埋まります。
そのため以下の作業をこまめに行うことが重要です。
- タスクが変わるときは、/clearを実行してコンテキストを開放する
- 同じセッション中に2回の修正に失敗したらクリアする
- サブエージェントを活用してトークン消費を抑える
作業結果を検証できる手段を与える
Claude Codeはテストの実行やスクリーンショットの比較、出力の検証などを自分で行える状態にすると作業の精度と安定性が大きく向上します。
検証手段がない指示では、「それっぽいコード」や「雰囲気の修正」で終わってしまいがちです。
例として以下の指示があります。
| 戦略 | Before(悪い例) | After(良い例) |
|---|---|---|
| 検証条件を明示する | メールアドレスを検証する関数を実装してください |
validateEmail 関数を実装してください。テストケース例: - user@example.com → true- invalid → false- user@.com → false実装後にテストを実行してください。 |
| UIの変更は視覚的に検証する | ダッシュボードをもっと良くしてください | [スクリーンショットを貼り付け] このデザインを実装してください。 実装後の画面のスクリーンショットを取得し、元のデザインと比較してください。 差分を一覧化し、必要に応じて修正してください。 |
| 症状ではなく原因に対処する | ビルドが失敗しています | ビルドが次のエラーで失敗しています: [エラーメッセージを貼り付け] エラーの原因を特定して修正し、ビルドが成功することを確認してください。 エラーを握りつぶすのではなく、根本原因に対処してください。 |
Claude Codeに限らず、AIが「間違った答え」を出す原因の多くは、実装ではなく検証条件の不足です。
Markdownを磨き上げる
Markdown(md)は、コードだけでは伝わらないプロジェクトの前提条件や制約、背景情報をClaude Codeに共有するための重要な手段です。
一方で、mdが長すぎるとClaude Codeは重要度を判断できず、制約やルールがノイズに埋もれてしまいます。
そのため、不要な情報は削除し、Claude Codeが参照すべき前提条件や制約だけを残すことが重要です。
ベストプラクティスにも書かれています。
できるだけ簡潔にまとめましょう。
各行について「これを削除したら、Claude は判断を誤るだろうか?」と自分に問いかけてみてください。
問題なさそうであれば、その行は削除してしまいましょう。
md は以下の方法で作成できます。
-
/initを実行し、プロジェクトに基づいたスタート用のCLAUDE.mdを作成する - AskUserQuestion ツールを使い、インタビュー形式で md を作成する
私は[簡単な概要]を作りたいです。
そのために AskUserQuestion ツールを使って、詳細にインタビューしてください。
技術的な実装、UI/UX、エッジケース、懸念点、トレードオフについて質問してください。
当たり前の質問は避け、私が見落としていそうな難しいポイントまで深掘りしてください。
すべてを網羅できるまでインタビューを続け、その後、完全な仕様書を SPEC.md にまとめてください。
md は「全部を書く場所」ではなく、「迷わせないための最小限の地図」です。
調査 → 計画 → 実装 の順で進める
コーディングを始める前に、「どのように実装するのか」というプランを作成することが重要です。
プランがないまま進めるのは、地図を持たずに目的地を目指すようなものです。
山に行きたいはずなのに、
気づいたら海に着いていたという状態に陥ってしまいます。
まずはプラン(目的地)を作成し、その内容を確認してからコーディングを開始します。
Claude Codeでは以下の4つのフェーズに分けたワークフローが推奨されています。
| フロー | 詳細 | 指示 |
|---|---|---|
| 調査 | プランモードで、現在の仕様を理解します。 |
/src/auth を確認し、セッション管理とログイン処理の仕組みを把握してください。あわせて、シークレット情報を含む環境変数の管理方法についても確認してください。 |
| 計画 | プランモードで実装計画を作成するように依頼します。 | Google OAuth を追加したいです。どのファイルを修正する必要がありますか?現在のセッションフローはどのようになっていますか?実装に向けて、全体の計画(plan)を作成してください。 |
| 実装 | 通常モードに戻り、コードを実装してもらいます。 | 作成した計画に基づいて OAuth フローを実装してください。コールバックハンドラのテストを追加し、テストスイートを実行してください。失敗しているテストがあれば原因を特定して修正し、すべてのテストが成功する状態にしてください。 |
| 提出 | 実装内容を確認し、Git にコミットして PR を作成します。 | 変更内容が一目で分かるコミットメッセージでコミットしてください。コミット後、プルリクエストを作成してください。 |
小さい修正であれば、プランを立てずに実装から始めても問題ありません。
修正範囲が明確で影響が小さいタスク(タイプミスの修正、ログの追加、変数名の変更など)であれば、Claudeに直接実装を依頼したほうが効率的です。
変更内容を一文で説明できる程度であれば、計画フェーズは省略して問題ありません。
いきなり実装を始めるのではなく「今はどのフェーズか」を明確にすることが、Claude Code を安定して使うコツです。
知っておきたい Claude Code の拡張機能
Claude Codeには、拡張機能として以下のような仕組みがあります。
| 概要 | 特徴 |
|---|---|
| CLIツール | 外部サービスと連携する際に、最もコンテキスト効率よく指示できる方法です |
| MCPサーバー | データベースのクエリ実行、監視データの分析、デザイン統合、ワークフロー自動化などを任せられます |
| フック | Claudeのワークフローの特定のタイミングで、スクリプトを自動実行できます |
| スキル | プロジェクト・チーム・ドメイン固有の知識をClaudeに追加できます |
| サブエージェント | 独立したコンテキストと、許可されたツールセットを使って処理を実行します |
なお、MCPサーバについては、おすすめのMCPをまとめた記事を以下で紹介しています。
直感を磨く
ベストプラクティスに書かれている内容は、あくまで知見の集合であり常に正解とは限りません。
うまくいったときには、どんな指示を出したのか/どんな Markdownやスキルを与えたのかを振り返り、何が効いたのかを分析することが大切です。
一度に完璧を目指す必要はありません。
小さく試し、結果を見て、また調整する——この繰り返しの中で、少しずつ「勘どころ」が身についていきます。
直感を磨きながら、自分なりの使い方を見つけていくこと。
それが、Claude Codeを本当に使いこなす一番の近道です。