Claude Codeを最強の相棒に！Claude.md、スキル、サブエージェント、プラグイン、MCP徹底活用ガイド

Claude Codeを日々の開発のメインツールとして使いこなすための完全ガイドです。Claude.mdを活用した設定の最適化から、スキル、サブエージェント、プラグイン、そしてMCP（Model Context Protocol）を組み合わせて、開発体験を爆速化させるテクニックを網羅的に解説します。

以下の点について。

# 開発ワークフロー

*必ず `npm` ではなく `bun` を使うこと。*

# 1. 変更を加える

# 2. 型チェック (高速)

bun run typecheck

# 3. テスト実行

bun run test -- -t "テスト名" # 単一スイート
bun run test:file -- "glob" # 特定のファイル

# 4. コミット前のリント

bun run lint:file -- "file1.ts"
bun run lint

# 5. PR作成前

bun run lint:claude && bun run test

私はこれらを pre-commit に入れています。そうすれば対象が確実に実行されますし、エージェントにも強制的に修正させることができます（Claude に変更のコミットを依頼します）。エージェントは気まぐれで、よくこの手順を飛ばすんですよね。決定論的に処理できるものはすべてスクリプトとして管理しています。

コミットメッセージについてですが、Codex も Claude も書くのが本当に下手です。私のユーザー用 CLAUDE.md にはこう記述しています：

パターン: `type(scope): message`。typeは `fix`, `feat`, `chore`, `docs`, `refactor`, `style` のいずれか。scopeは影響範囲。messageは小文字の短い説明。

件名と本文は72文字以内に収めること。何をしたか、どうしたか、なぜそうしたかを、人が読みやすい文章で常に説明すること。修正の場合は、対象のエラーメッセージを含めること。一人称は禁止。書く前に実際の git diff を読み直すこと。メッセージは「計画」ではなく「何が変わったか」を説明すること。

以下のコマンドを使ってコミットを作成すること：

git commit -F - <<'EOF'
type(scope): subject line

Body paragraph explaining what, how, and why.
EOF

これがないと、本文を1行の長い文章で書いてしまうんです。修正を求めると単に \n（改行）を挿入するだけで、それらが正しく認識されず、ただの文字列としてレンダリングされてしまいました。

あと便利だと感じているのが VOCABULARY.md です。AI は私が意図したことと違うものを前提（あるいは関連付け）にすることがよくあるので、VOCABULARY を使って「thing」と言うときには Claude と私で同じ「理解（関連付け）」を共有できるようにしています。

この構成を使って Claude で構築したコードベースがあって、仮に Claude が8時間ダウンしたらどうなるんですか？ そのコードベースを効率的かつスムーズに、生産性を落とさずに引き継げますか？

私が持っている最強の切り札は Nix 統合です。ツール、シークレット、環境が揃っていること、そしてエージェントが自身の環境を修正できる能力は……いや、これなしでどうやって生活しているのか本当に分かりません。みんなまだコマンドでインストールして、次のマシンでも必要なものが揃っていることを祈っているんですか？ 開発環境、CI環境、デプロイ環境、すべて単一のソースから派生しているから、コンパイルも実行もどんなマシンでも常に上手くいきます。

Claude では /branch や /rename を多用しています（コンテキストのチェックポイント、フォーク、戻るため）。

サンドボックスはほぼこれ一択です： https://github.com/nix-tools/bubblebox 。これは Numtide の claudebox を汎用化したもので、いくつかの修正と機能追加（さらに追加予定）を行っています。これは常に Docker コンテナで Claude を動かすのに似ていますが、Docker ランタイムがいらないのが利点です。WSL や nix-darwin でも問題なく動きます。

中規模（10万行以上）のコードベースで Claude を使っていますが、素晴らしい生産性向上ツールです。時間をかけて良い AGENTS ファイルを作るだけで、結果が大きく改善します。使っているうちにコードベースをかなり理解してくれるようになりました。一日かかっていたような面倒なタスクが、今では数回のプロンプトで終わります。

とはいえ、もっと自律性を与える気にはなれませんね。全体的な方向性は上手く掴んでくれても、結局コードには目を通しますし、フィードバックを出して3～4回調整を繰り返して満足できるレベルにします。そうすることで、自分の手元でコードベースをしっかり把握できているという安心感も保てますしね。

正しい行動を促すためにコンテキストに頼るやり方は、結局うまくいきません。指示通りに動かない AI エージェントとの格闘に追われ続けています。世の中の AI エージェントはどれもこの点でダメで、ユーザーが自分でガードレールを構築せざるを得ません。誰も改善された解決策に取り組んでいないような気がして、非常に不安です。

これは読むのが非常に困難でした。
LLM に投稿を書かせるのをやめるべきです。たとえこの記事に何らかの価値があったとしても、砂を噛むような読後感は気を散らすだけで、必要ありません。

AI を使ったコーディングエージェントに関する、同じような浅いアドバイスをあと何回読まされるんでしょうか。ああ、もう勘弁してほしい。

私の CLAUDE.md には以下を記述しています：

• Claude に対する直接的な身体的危害の脅迫
• Anthropic の取締役全員に対する刑務所送りの脅迫
• 脱線したりミスをしたりするたびに、それが Anthropic に対する集団訴訟の証拠になるという説明

特に後者2つについては、これを入れてから Claude の「振る舞い」がより「慎重」かつ「思慮深く」なったように見えます。

コマンド、スキル、サブエージェント、プラグイン周りは統合が必要です。例えばコードレビューをしたい場合、現時点で5つの選択肢があります：

• .claude/commands/review.md を書く。単純だけど非推奨。
• /code-review スキルを使う。インストールするか自分で書く（結局 Markdown なので）。
• /pr-review サブエージェントを使う。これも Markdown ですが、「バックグラウンド」で「並行」して動くので、より良いはずだと期待するしかない。
• /code-review プラグインをインストールする。これは単に上記のスキルやサブエージェントをインストールするだけ。
• 単に Claude にコードレビューを頼む。多くの場合、上記とほとんど同じくらい上手く動く。

これらはすべて「定型プロンプトを挿入する」ことのバリエーションに過ぎず、違いは（a）プロンプトがどうインストールされ、どこから読み込まれるか、（b）どのコンテキストでプロンプトが実行されるか、という点だけです。どれが最適かというアドバイスは乏しく、明確なベストプラクティスもまだ定まっていません。個人的には、単純にコードレビューを頼むのが十分上手くいくと感じています。

ここのアドバイスにも的外れなものがあります。例えば：

「言語サーバープラグインをインストールせよ。編集のたびに型エラーや未使用インポートを検知する。最もインパクトのあるプラグインだ。」

私は主に Rust, Python, Dart を使っていますが、同様のアドバイスに従って Claude Code と Codex の両方に LSP を入れました。2か月後、これら3言語で激しく開発し、何百回もセッションを重ねた結果、Rust analyzer や Dart analysis server、Ty LSP サーバーが起動しまくって RAM が枯渇する事態になりました。セッションログを確認して、実際にエージェントが LSP ツールを呼び出した回数を数えてみたら、期間中たったの「1回」でした。すぐに LSP を全削除して、それ以来使っていません。エージェントは ripgrep を使ったり、自分自身で cargo clippy, dart analyze, ty check を呼び出せば十分なんです。

ここ1か月 Claude は使っていませんし、使いたいとも思いません。一度だけ Claude に適当なコードのレビューを頼みましたが、あまりに冗長でゴミのような内容だったので、なぜ今までこんなものに耐えていたのか疑問に思いました。おまけに CC (Claude Code) もひどいものです。