Claudeを使うほど、なぜか疲れる
Claude Codeを使い始めた頃、すべてがメインチャットで完結していた。
シンプルで分かりやすかった。
ところが使い込むうちに、CLAUDE.mdを知り、コマンドを覚え、スキルやサブエージェントという概念に出会いました。
便利になるはずが、「これはどこに書くべき？」「この処理はコマンド？スキル？」と、なぜか迷う時間が増えていきました。
気づけば、Claudeに指示を出す前の「準備」で疲れてしまっている。
もしあなたが同じような状況にいるなら、この記事が役に立つかもしれません。
今回は、私自身が混乱から抜け出すために整理した「使い分けの考え方」を共有したいと思います。
4つの機能を一言で整理してみる
まず、各機能の役割を一言で把握しておきましょう。
| 機能 | 一言で言うと | 具体例 |
|---|---|---|
| CLAUDE.md | 前提・思想・ルール | 「このプロジェクトは TypeScript で書く」「テストは必ず書く」 |
| コマンド | 呼び出しの入口 | /blog:new で記事作成フローを開始 |
| スキル | 再利用可能な処理 | 「SEO最適化」「校正」などの定型処理 |
| サブエージェント | 役割を持った相談相手 | 「インタビュアー」「エディター」など |
いかがでしょうか？
実際に使い始めると「で、この場合はどっち？」という場面が必ず出てきます。
よくある間違った使い分け
私自身がやってしまった失敗パターンを紹介します。
失敗1：CLAUDE.mdに「すべて」を書く
「Claudeへの指示はCLAUDE.mdに書けばいい」と思い、プロジェクトのルール、よく使うコマンド、作業手順まで全部詰め込んでしまいました。
結果、CLAUDE.mdが肥大化。
Claudeの応答が遅くなり、しかも指示が多すぎて肝心なルールが埋もれてしまいました。
失敗2：コマンドとスキルを同じものだと思っていた
「どっちも処理を呼び出すものでしょ？」と混同していました。
確かに似ていますが、役割が違います。
コマンドは「入口」で、スキルは「中身」。
玄関と部屋の違いのようなものです。
失敗3：サブエージェントを作りすぎる
「役割分担すれば効率的」と考え、細かい作業ごとにサブエージェントを定義しました。
管理が大変になり、どのエージェントを呼べばいいか分からなくなりました。本末転倒でした。
Claude Codeでよくある失敗パターンでも触れていますが、「便利にしようとして複雑にする」のは典型的な落とし穴でした。
「前提・判断・作業」で分ける
混乱を抜け出すために、私は3つの軸で整理することにしました。
前提：CLAUDE.md
「Claudeが常に知っておくべきこと」を書く場所。
- プロジェクトの技術スタック
- コーディング規約
- 絶対に守るべきルール
ポイントは「毎回伝える必要があること」だけを書くこと。
一度きりの指示や、特定の作業手順は書かないことにしました。
CLAUDE.mdの育て方で詳しく記載しましたが、最初は3〜5行で十分。
使いながら育てていくのがコツだと感じています。
判断：コマンド
「何をするか決める入口」がコマンド。
ユーザーが「この作業をやりたい」と意思表示する手段です。
コマンドを実行すると、必要なスキルやサブエージェントが呼び出されます。
例えば `/blog:new tech` と打てば、「techカテゴリの新規記事を作る」という判断が伝わり、適切な処理フローが始まります。
作業：スキルとサブエージェント
「実際に手を動かす部分」がスキルとサブエージェント。
では、この2つはどう違うのか？
- スキル：定型的で、毎回同じように実行される処理
- サブエージェント：状況に応じて判断しながら進める処理
SEO最適化のように「決まったチェック項目を確認する」のはスキル向き。
インタビューのように「相手の回答に応じて質問を変える」のはサブエージェント向き。
最小構成のおすすめ例
「結局どこから始めればいいの？」という人のために。
Step 1：CLAUDE.mdだけ作る
まずはこれだけ。
# プロジェクト概要
このプロジェクトは〇〇です。
# 技術スタック
- TypeScript
- React
# ルール
- 関数には必ずJSDocを書くこれだけで、Claudeの出力がプロジェクトに合ったものになります。
Step 2：よく使う作業をコマンド化
同じ指示を3回以上繰り返したら、コマンドにする。
.claude/commands/review.md中身は、いつも打っている指示をそのまま書けば大丈夫です。
Step 3：必要になったらスキル・サブエージェントを追加
「コマンドの中身が複雑になってきた」「役割を分けた方が管理しやすい」と感じたら、初めてスキルやサブエージェントを検討します。
最初から全部揃える必要はありません。
迷ったときの判断基準
それでも「これはどこに書く？」と迷うことがあります。
そんなときの判断基準です。
Q: 毎回Claudeに伝える必要がある？
- Yes → CLAUDE.md
- No → 次へ
Q: ユーザーが明示的に呼び出す？
- Yes → コマンド
- No → 次へ
Q: 処理は定型的？
- Yes → スキル
- No → サブエージェント
この順番で考えれば、大体の場合は整理できると思います。
/compactと/clearの使い分けのように、具体的なコマンドの使い方を知ると、この判断基準がより腑に落ちるようになるでしょう。
慣れないうちは複雑に感じてしまうと思いますが、ひとつづつ理解していく感じで大丈夫です。
今日からできる1アクション
最後に、今日からできることを1つ。
「次にClaudeを使うとき、CLAUDE.mdに1行だけ追加してみる」
大げさな設計は要いりません。
「このプロジェクトではsnake_caseを使う」でも「日本語で返答する」でもいいです。
その1行が、Claudeとの会話を少しだけ楽にしてくれます。
そこから少しずつ育てていけばいいのです。
機能が増えて複雑に見えても、本質は「Claudeとの会話をどう設計するか」だけ。
前提・判断・作業という3つの置き場所を意識するだけで、混乱はかなり減るとおもいます。
Claudeを使うことが負担ではなく、本当の意味で「楽」になることでしょう。
