Skip to content
AI/エージェント

私が Claude Code を使う7つのコツ

Planモードから自分形アーキテクチャ、MCP 検索からエージェント協調まで、Claude Code の効率を倍増させる7つの実戦テクニックを共有する。

2026/2/8 8分で読める

私が Claude Code を使う7つのコツ

7つのコツの全体像

最近、社内共有で私が Claude Code を使う7つのコツを話したので、記事にまとめて X のフォロワーにも共有することにした。

Claude Code の創業者も似たような投稿を書いているが、本稿には新しい内容もあり、特に第3節の「自分形」がそうだ。

1. まず Plan、次にコード

どんな複雑な要件を書く前でも、私は Planモード を有効にして AI と要件をすり合わせる。

/plan コマンド、またはショートカット Shift + Tab で Planモードを開ける。

Planモードを使う最大の利点は、考えることを強制される点にある。そう、強制されるのは AI ではなく自分だ。

このモードでは、AI が細部に関する質問を繰り返し投げ、要件の境界と構造を段階的に確定していき、最後に詳細なタスク文書を出力してくれる。

そのタスク文書をもとに、変更点や欲しい結果を継続してすり合わせられるので、手戻りの確率を下げられる。

超大型タスクを処理する時は、タスクを文書として永続化するよう依頼してもよい。今の Claude Code には複数セッションで todo を共有する機能があるが、まだデフォルトでは有効化されていない。

2. Claude.md を使いこなす

Claude.md は Claude Code のデフォルト読み込みファイルだ。Claude Code は起動時、システム指示と MCP 以外は空白に近い状態なので、プロジェクトルートにある Claude.md を読み込んでプロジェクトを理解する。

私は通常、Claude.md に次の3つの指示を書く。

  1. 呼称ルール:毎回の返信前に必ず「Boss」を呼称として使うこと。
  2. 意思決定の確認:不確実なコード設計の問題に遭遇した時は、必ず先に Boss に確認し、勝手に行動しないこと。
  3. コード互換性:互換性コードを書かないこと。Boss が明示的に要求した場合を除く。

1つ目の指示は、指示遵守率を確認するためだ。

コンテキストが増えすぎると AI は指示に従わなくなる。返信に Boss という接頭辞がないと気づいた時点で、その会話のコンテキストは過負荷になっている可能性が高く、/new で会話を切り替えるべきだ。

2つ目の指示は、AI の自由意志を制約するためだ。

AI は確認せずに着手しがちなので、結果として手戻りが増える。この指示を入れると「xx はどう設計したいか」を頻繁に聞き、いくつかの選択肢も提示してくれる。

3つ目の指示も同様に AI を制約するためだ。

多くの場合、タスクを反復していると、こちらが誤りを認識して修正を指示しても、AI は既存コードに if 分岐を足して直そうとする。名目は「互換性」や「システムの堅牢性」だ。

私は過度な冗長コードが好きではないので、大半のケースでは要件の達成だけを求め、余計な先回りは求めない。

一般にコンテキストウィンドウの使用率が 40% を超えると、AI の指示遵守率は落ち始める。だから残りのコンテキスト量を頻繁に確認し、通常は 50% を下回ったら新しいウィンドウを開く。

できることは2つある。

  1. コンテキスト圧縮をオフにする。何もしなくても総コンテキストの 22.5% を占有する。
  2. showline ステータスバーでコンテキストの割合を表示する。/showline コマンドを伝えるだけで表示してくれる。

もう1点、すべてを Claude.md に詰め込む必要はない。必要な時だけ参照する遅延読み込みにするとよい。

これは遅延読み込みの例で、3つの指示を通して Claude Code に「この3つの場面に遭遇したら対応するファイルを見て、その規約に従う」ことを伝えている。

3. 自分形 & 自己記述を使う

バイブコーディングにおける自分形の概念は趙純想先生に由来するが、私は少し改良しており、要点は Claude Code の階層読み込み機構を活用することにある。

Claude Code はファイルを検索する時、該当ディレクトリ配下の Claude.md を自動読み込みする。例えば User というキーワードを検索してあるフォルダに到達すると、そのフォルダ配下の Claude.md を能動的に読み込む。これが階層読み込みであり、遅延読み込みとも言える。

したがって、特定の業務コードモジュール配下では次を行える。

  1. 各業務モジュールのフォルダごとに Claude.md を置き、そのモジュールの重要情報を記録する。地位(システム内で何を担うか)、ロジック(システム内で何をするか)、制約(モジュール利用時の制約ルール)、そして業務ドメイン一覧(子フォルダ配下の全サブモジュールと機能)。
  2. すべてのソースファイルに3行の先頭コメントを設定する。INPUT(何に依存するか)、OUTPUT(何を提供するか)、POS(システム内での地位)だ。AI はファイル先頭から読み込むので、必ず先頭に置くべきで、毎回そのファイルの業務情報を先に読ませられる。

これをやると次の変化が起きる。

Claude Code のコード検索が速くなる。説明的なコメントが加わることで、狙ったコードに当たりやすくなるためだ。

Claude Code のコード理解がより正確になる。何を検索して読み込んでも、対応する Claude.md が全体方針を説明してくれるので、方向を外しにくく、大局からコードを理解しやすくなる。

例えばあるファイルが第5階層のフォルダにある場合、Claude Code がそれを見つける時点で前4階層の Claude.md をすでに読み込んでおり、モジュール全体への理解が非常に明瞭になる。

4. 明確なプロンプト

現在のモデル能力で言えば、プロンプトの書き方が多少粗くても意味は通じる。だから押さえるべき原則は3つで十分だ。

  1. タスクの最終目的を明確かつ正確に述べる。例えば必要な機能点や、ページ上の要素。
  2. 参照すべきコンテキストを渡す。例えば API データ、API ドキュメント、既存ページ。
  3. テスト方法を伝える。例えばフロントエンドページなら、内蔵の Chrome を使って検証させる。

5. MCP を検索に活用する

MCP をインストールしていても、Claude Code はしばしばそれを呼ばず、同じところで足踏みする。

例えばページ実装中に、あるコードの使い方でコンパイル問題が繰り返し起きたり、想定した効果と一致しなかったりして、どうしても解決できない場面がある。その時は Context7 を呼び出してオンラインドキュメントを確認するよう明示的に指示すべきだ。オンラインドキュメントを読んでコンテキストが補完されると、より正確なコードを書きやすくなる。

ただし MCP を大量に入れる必要はない。私は一貫してこう考えている。

ローカルで解決できるなら、クラウドにはつながない。

MCP が多すぎるとコンテキストウィンドウを圧迫する。/context コマンドでコンテキストウィンドウの詳細な占有状況を確認できる。

6. エージェント協調

エージェントは今さら感のある話題だが、まだ小さなコツがある。

  1. 大量のコンテキストを消費しそうな検索は サブエージェント にやらせる。サブエージェントは独立コンテキストなので現在セッションを圧迫しない。検索後は結果だけを現在セッションに返すため、現タスクが進んでいない段階で検索だけでコンテキスト過負荷になる事態を避けられる。
  2. 1つの指示で複数エージェントを直接呼び、対抗式のエラーチェックを行う。例えば CodeReview Agent と Test Agent があるなら、タスク成功後に CodeReview Agent でコードレビューを行い、Test Agent でテストフローを検証するよう指示できる。1つのタスクで3つのエージェントによる交差チェックが走るため、コード精度が上がる。
  3. 並行開発として、複数ブランチでウィンドウを2つ追加し、異なるエージェントに異なるモジュールを同時開発させる。その後、別ウィンドウでエージェント間 PR を専任処理し、コードレビューとテスト検証(独自検証でも TDD でもよい)を行う。

7. Skill を使いこなす

今の Claude Code ではカスタムスラッシュコマンドと Skill が統合されているので、よく使うものはすべて Skill として蓄積していくべきだ。

例えば第3節で紹介した自分形について、私は専用の Commit Skill を作っている。この Skill はコミット対象コードを検査し、ヘッダー注釈の補完と上位フォルダ Claude.md の補完を行った上で Git コミットまで実施する。

Skill には Prompt のカスタマイズ、ワークフロー、サブエージェントのオーケストレーション能力がある。積極的に使えば、効果は非常に大きい。