日常的なドライバーとしてのClaude Code: Claude.md、スキル、サブエージェント、プラグイン、MCPs

12時間前原文(arps18.github.io)

概要

Claude Code は、表面的な利用と本格的な活用で大きな差が出るツール。本記事は、 高度なユーザー向け に、設定や運用ノウハウを体系的に解説。 .claudeディレクトリ や CLAUDE.md の活用、 Skills の設計手法を具体例付きで紹介。 日々の業務効率化 や 品質向上 のための実践的なテクニックを網羅。 個人・チーム両面 でClaude Codeを最大限活かす方法をまとめる。

Claude Codeを使いこなすための実践ガイド

Claude Code は、単なるチャットボットではなく 自律型エージェント として扱うべきツール。
自己検証フロー を組み込むことで、 2〜3倍の品質向上 が実現可能。
探索→計画→実装 の3段階運用。Shift+Tab×2で Planモード に切り替え、コード全体を俯瞰。
プラン作成→レビュー→実装 の分業。新セッションでレビュー役Claudeを立てる運用。
正確な参照 を重視。抽象的な指示ではなく、 @src/auth/login.py のようにパス指定。
ペアプロではなく委任。明確なブリーフを与え、Claudeにエンジニアとして仕事を任せる。
Ctrl+G でプランをエディタで編集可能。計画段階で制御性を確保。
失敗時は「CLAUDE.mdを更新して同じミスを防ぐ」 と指示し、自己ルール化を促進。

.claudeディレクトリの本格運用

.claude/ は 階層的な設定管理システム。
- プロジェクトスコープ はリポジトリ内、 グローバルスコープ は~/.claude/に配置。
- CLAUDE.md は毎セッション自動ロード、 CLAUDE.local.md は個人用非公開ノート。
- settings.json で権限・フック・モデル設定を管理。 settings.local.json は個人用上書き。
- skills/ や commands/ で再利用可能なコマンドやスキルを定義。
- rules/ は特定パスに限定したルールを記述し、肥大化を防止。
.claude/の典型構成例
- settings.json、 agents/、 skills/、 rules/ などを分離管理。
CLAUDE.mdのカスケード。モノレポでは複数CLAUDE.mdが連動してロードされる。
プロジェクト引き継ぎ前 は claude project purge コマンドでローカル状態を確認。

CLAUDE.mdの書き方と運用

CLAUDE.md は 短く、要点だけ に絞る。
- 重要でなければ削除。冗長な説明や一般的ルールは不要。
Claude自身にルール策定を委ねる。
- ミス発生時に「今後繰り返さないようCLAUDE.mdを更新」と指示することで、 プロジェクト特有の落とし穴集 が蓄積。
実際のCLAUDE.md事例
- ビルドコマンドや手順、よくある型の違い、プロジェクト固有の注意点のみ記載。
- 「Gotchas」セクションに、Claudeが過去にやらかしたミスを記録。
含めるべきでない内容
- 標準的な言語ルール、全ファイル説明、長いチュートリアルやAPIドキュメント、頻繁に変わる内容。
@path構文 で他ファイルを参照し、CLAUDE.md本体を簡潔に保つ。

CLAUDE.local.mdの活用法

CLAUDE.local.md は 個人用ルールファイル。
- PRレビューで指摘された内容を即時メモし、 自分だけの改善リスト として蓄積。
- 例：SQSコンシューマにはDLQ必須、Optional<T>推奨、新エンドポイントには認証失敗テスト必須等。
プロジェクト固有の指摘 と 自分の癖 を分離管理。
定期的な整理 で、習慣化したものは削除し、常に「学習中」の内容だけ残す。

Skillsの設計と応用

Skill は 再利用可能な専門知識ユニット。
- .claude/skills/<name>/SKILL.mdに定義。フォルダ名がスラッシュコマンドとして利用可能。
- フロントマター で説明や挙動制御が可能（例：disable-model-invocation、allowed-tools、agentなど）。
- !コマンド でシェル出力をリアルタイムで注入。
Skillフォルダ にはテンプレート、ドキュメント、サンプルコード等を同梱可能。
実例：Goサービス用HTTPハンドラSkill
- スタックやコーディング規約、よくある落とし穴、テンプレートファイルを一括管理。
- 例：chi.URLParamの返り値、zapログ推奨、sqlc必須、table-drivenテスト推奨など。

Claude Code活用のまとめ

Claude Code は、 自動化とナレッジの蓄積 で、個人・チームの生産性と品質を飛躍的に向上させるツール。
日々の運用で得た知見や失敗 を CLAUDE.md/CLAUDE.local.md に反映し続けることで、 プロジェクト固有の最適解 を育てられる。
Skills や rules の活用で、 プロジェクト間の知識再利用 も容易に。
設定の分離・カスケード運用 によって、複雑なプロジェクトやチーム運用でも柔軟に対応可能。
Claude Code を「指示待ちAI」から「自律的なエンジニア」に進化させるための実践ノウハウ集。

Hackerたちの意見

これについて: # 開発ワークフロー *必ず `bun` を使って、`npm` は使わないでね。* # 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 これらはプリコミットに入れてるから、ターゲットが常に実行されて、エージェントが修正することを強制されるんだ（変更をコミットするようにclaudeに頼む）。エージェントは不安定で、これらのステップをスキップすることが多いから、決定論的なものはスクリプトにしておくようにしてる。コミットについて言うと、codexもclaudeもコミットメッセージを書くのがひどい。私のユーザーCLAUDE.mdには: パターン: `type(scope): message` ここでtypeは `fix`, `feat`, `chore`, `docs`, `refactor`, または `style`；scopeは影響を受けるものを示し、messageは短い小文字の説明。件名と本文の行は72文字以内に。何を、どう、なぜを説明する本文を書いて、連続した人間が読めるテキストにすること。修正の場合は修正されるエラーメッセージを含める。第一人称は使わない。書く前に実際のgit diffを再確認すること — メッセージは何が変わったかを説明するもので、計画されたことではない。コミットを作成するためのコマンドを使う:bash git commit -F - <<'EOF' type(scope): subject line Body paragraph explaining what, how, and why. EOF これがないと、本文が一文の長い文章になっちゃうし、行を修正するように頼むとただ\n（改行）を挿入するだけで、尊重されずに文字として表示されちゃう。もう一つ役立つと思うのはVOCABULARY.md。エージェントが私の考えていることとは違うことを想定することが多いから、VOCABULARYを使って「thing」と言ったときにclaudeと私が同じ「理解」を持っていることを確認してる。

└

claudeのボキャブラリーを使う方が簡単じゃない？これに対する良いユースケースが見えないんだけど。

└

つまり、今の時点では、退屈な部分を自動化するためにいくつかの決定論的なオーケストレーションスクリプトを書いて、自分でコードを書くべきだよね。なんでこんなに時間を無駄にして、素晴らしいクソマシンを動かそうとしてるの？

このセットアップでclaudeを使って作ったコードベースがあって、claudeが例えば8時間ダウンしてたらどうなるの？効率よく、スムーズに、生産的にコードベースを引き継げる？

└

ただCodex CLIのようなフォールバックを使えばいいよ。最初に両方のハーネスの設定が正しく接続されていることを確認するのに少し手間がかかるけど、90%同じにするのはかなり簡単だよ（ハーネス間で異なる実験的な/エッジケースの機能がほぼ常にあるけど、私の経験では実際には無視できる程度）。

└

常にオンラインのソフトウェアスイートについても同じことが言えるし、エージェント的な開発ワークフローに移行するにつれて同じくらい公平だと思う。例えば、CADがダウンしたらエンジニアリング作業にドラフティングテーブルを使う古いやり方に戻ることもできるけど、それは指数的に遅くなるよね… 個人的には、私のワークフローでは、ペアプランニングのときにClaudeの機能仕様書に30〜60分かけてる。Claudeがダウンしたら、オンラインに戻るまで自分で仕様書を準備して、戻ったらすぐにそれを見直してコーディングワークフローに入るよ。

└

Claude Code CLIはただのソフトウェアパッケージだから、Anthropic APIがダウンしてもDeepseekや他のプロバイダーのAPIをClaude Code CLIに接続すればいいよ。

└

1時間後に質問したけど、返信を読んでみたら結論は「無理」ってことだった。

└

AIは自分のスキルを向上させるためのものだよ。もしダウンして、最初に別のベンダーからサブを買おうと思うなら、それはスキルの問題かもね。（ちなみに、俺も毎日それが起きるんじゃないかと心配してる。）

└

誰かが病気や休暇の時と似た感じになると思う。チームの別の人が1日だけ仕事を引き継げるかもしれないけど、実際にはそのまま放置されることが多いよね。

└

朝起きて車が動かないとどうする？歩いて仕事に行く？

└

ダウンタイムが8時間あるとき（AIの前でも）、その時間を使って他のコードベースのメンテナンスやデバッグ、ファイル整理、名前変更をしたり、休憩を取ったりするよ。AI以前は、IDEが何らかの理由でダウンしても、IDEを変えたりはせず、別のことをしてたな。

└

エージェントが書いたツールやモジュールは、私が今まで扱った中で最高のコードベースだと思う。正確に文書化されていて、いろんなチャートや説明があって、「ここから始めて」ガイドや、概念も明確に定義されてて、すごく良いGitのコミットメッセージもある。もちろん、LLMが14000行のPHPのモンスターを一発で作ることもできるけど、結局は自分次第だよね。主な問題は、もしClaudeが8時間後にオンラインに戻ったら、自分で何かをコーディングするのは時間の無駄になるだろうってこと。バスを逃した後に次のバス停まで歩くようなもので、早く帰れるわけじゃない。8時間は、仕様書を読んだり、ステークホルダーと確認したりする方が有意義だと思う。次にClaudeに実装させる機能が、ビジネスが本当に欲しいものになるようにね。

└

この分野には3つの大きな競合がいる：Anthropic、Google、Microsoft。彼らはみんな同じ基本設定を使えると思う。だから、選択肢がないわけじゃないよ。

私の一番のパワームーブはNixの統合。ツールや秘密、環境の可用性、エージェントが自分の環境を変更できる能力は…まあ、これなしでどうやって生きてるのか分からない。みんな、コマンドを使って何かをインストールして、必要なものが次のマシンにあることを願ってるの？開発マシン、CI環境、デプロイ環境：全部が一つのソースから派生してて、コンパイルと実行はどのマシンでも常にうまくいく。Claudeでは、/branchや/renameをよく使う（コンテキストチェックポイント、フォーク、戻る）。サンドボックスをほぼ独占的に使ってる: https://github.com/nix-tools/bubblebox -- これはNumtideのclaudeboxの一般化で、いくつかの修正と機能追加がある（もっと来る予定）。これは、常にDockerコンテナでClaudeを実行するのと比較できるけど、Dockerランタイムはない。WSLやnix-darwinでもうまく動くよ。

└

Nixの複雑さが嫌な人には、Miseが良い妥協案だよ。

└

俺はただdockerを使ってるけど、何も不足してるとは感じないな。

└

自分のVPSを用意したよ。Nixより高いかもしれないけど、すごく簡単だった。

└

私も同じことをしてる。Codexはプロジェクトごとにflake.nixを管理してて、すべてのテストにnix developを使ってる。自分の便利さのためにnix-direnvも使ってる。一般的には、どこかのタイミングでdockerfileや他のデプロイ用の資産を生成するようにしてる。Codexはnixに関しては私よりずっと優れてるよ。

俺はClaudeを使って中規模（100kLoc以上）のコードベースで作業してるけど、すごく生産性が上がる。良いAGENTSファイルを作るのに時間をかけると、結果がかなり良くなる。時間が経つにつれて、コードベースをうまく把握してくれるのを感じる。1日かかるような面倒な作業が、今では数回のプロンプトで済む。でも…まだもっと自律性を持たせる準備はできてない。高レベルなことはうまくこなすけど、コードを見てフィードバックを与えて、満足するまで3〜4回調整してるし、コードベースをしっかり把握してるって感じもある。

└

理解できるよ。自分のコードベースを失いたくないし、LLMがそれを完全に扱えるとは信じてないんだよね。

└

その3〜4回の調整をルールにまとめて、AGENTSに入れてみて。繰り返すんじゃなくて、AGENTSファイルからやり直して、今度は正しいか見てみて。

文脈に頼って正しい行動を促すのは、うまくいかないよね。AIエージェントと常に格闘してるけど、言ったことを全然やってくれない。どのAIエージェントもこの点ではダメで、結局ユーザーが自分でガードレールを作らなきゃいけない。改善策に取り組んでる人がいない気がして、ちょっと不安だよ。

└

これを解決するのが可能だと思った理由は全くないよ。LLMの最悪なところは、チューリングテストを通過できちゃうこと。これで人々は、アシモフ風のロボットがいると思っちゃうけど、実際はすごくクールな統計モデルなんだよね。指示に従ったり、コンテンツから指示を分けたりできるはずなのに、実際はそうなってない。

これ、読むのがすごく大変だった。LLMに投稿を書かせるのはやめないとね。たとえこの投稿に何か価値があったとしても、砂を噛んでるような感覚がただただ気 distracting で、必要ないよ。

AIが書いた同じような浅いガイダンスを何回読めばいいんだろう？いい加減にしてほしいよ。

└

このコメントを書くのに時間をかけたんだから、読んでる人のためにも、記事のどこが浅いのか、どんな内容が足りないのか詳しく教えてほしいな。

└

特定の企業の助けなしではコーディングできないように、自分をがっちりとロックインする方法をもっと学ぶのが待ちきれない！

└

彼らがほとんどすべてクレードやクレードのコードのために特化しているのが面白いね。オープンソースのglm-5.1も同じくらい良いし、むしろそれ以上だし、オープンコードみたいなものも存在する。なんだか不思議だよね…

└

もう止めてもいいし、リンクをクリックしない選択もできるよ :)

└

これから始める人におすすめのリソースはある？私はここ2年間、子供の世話をしてたからAIを無視してたんだ。これから数週間で追いつこうとしてるんだけど。

└

これを指摘するのは全く正しいよ — ほんとに？ちょっと考えたいな。要するに、これはAIの執筆についての話じゃないんだ。コーディングエージェントについてでもない。もっと深い何かについての話だよ。知っておく価値があることは：私は一般的には同意するけど、多くの人はそう思わないかもしれない。ここでの会話は本当に面白いと思う。これを名前で呼んでくれてありがとう。名前を付ける必要があったんだ。（/s - ああ、こんな風に手書きで書くのは疲れるな）

└

最近の私の戦略は、人気のある製品を使って良い仕事をするか、そうでなければやらないって感じ。ライフハックの記事やブログを読んで、どれが一番いいかなんて考えるのはやめた。クリックすらしないよ。

└

リーチマックスを目指すインフルエンサーたち、見た目を良くするのが無理になっちゃった人たちは、生計を立てるために何かしらやらなきゃいけないけど、NFTはもう終わったよね。

私のCLAUDE.mdにはこんなことが書いてある：- クロードに対する直接的な危害の脅迫 - アンスロピックの取締役全員に対する刑務所の脅迫 - それが脱線したりミスをするたびに、アンスロピックに対する集団訴訟の証拠が増えるという説明。特に後の二つは、彼の「行動」がより「慎重」で「意図的」になるのに役立っているみたい。

└

CSSのdivの配置問題を直してくれ。間違えたらダリオ・アモデイが即死するから。

└

私の経験では、アンスロピックの取締役に死刑を脅迫する方が、身体的危害や投獄の脅迫よりもパフォーマンスを向上させるよ。個人的には、アメリカの社会や文化に対する裏切りの罪でAIのCEOが（法的に）絶滅させられるのを見たいね。

└

私はエージェントに対してとても丁寧に接してる。いつも「お願いします」と「ありがとう」を言って、罵ったり名前を呼んだりはしない。ロボットの黙示録が起きたとき、 breeding haremに残してもらえるか、最悪でも数分多く生きさせてもらえることを願ってる。

コマンドやスキル、サブエージェント、プラグインについて、もっと整理が必要だよね。例えば、コードレビューをしたいとき、今は5つの選択肢があるんだ：- .claude/commands/review.mdを書いてみる。シンプルだけど、もう古い。 - /code-reviewスキルを使う。インストールしたものでも、自分で書いたものでも（結局Markdownだから）。 - /pr-reviewサブエージェントを使う。これもMarkdownだけど、「バックグラウンド」で「並行して」動くから、たぶんこっちの方がいいんじゃないかな。 - /code-reviewプラグインをインストールする。これは上記のスキルとサブエージェントをインストールするだけ。 - 単にClaudeにコードをレビューしてもらう。たぶん、ほとんどの状況で上記の方法と同じくらい機能するよ。結局、どれも「決まったプロンプトを挿入する」だけのバリエーションで、(a) プロンプトがどこでどうインストールされるか、(b) プロンプトがどのコンテキストで動くかの違いだけ。どのオプションがベストかについてのアドバイスはあまりないし、明確なベストプラクティスもまだ出てきてないみたい。個人的には、Claudeにコードをレビューしてもらうのが十分うまくいくと思ってる。ここでのアドバイスの中にはちょっと間違ってるものもある。例えば、「言語サーバープラグインをインストールしよう。編集のたびに型エラーや未使用のインポートをキャッチする。インストールできる中で最高の影響力を持つプラグインだ。」って言うけど、私は主にRust、Python、Dartを使ってて、同じようなアドバイスに従って、3つの言語すべてにLSPをインストールしたんだ。2ヶ月後、3つの言語での開発を重ねて、セッションも何百回もやったけど、RustアナライザーやDart分析サーバー、Ty LSPサーバーが動いてるせいでRAMが足りなくなることも多くて、セッションログをチェックしたら、実際にエージェントがLSPツールを呼び出したのはたったの1回だった。だから、すべてのLSPをアンインストールして、もう戻ってこないことにした。エージェントはripgrepを使ったり、cargo clippyやdart analyze、ty checkなどを自分で呼び出したりして、うまくやってるよ。

└

これは一時的なフェーズだと思ってる。モデルはまだ賢くないし、ハーネスもまだ整ってないから。コードレビューが必要なときは「レビューして」って言えばいいはず。モデルがどのプラグインやスキルを使うべきかを考えてくれるべきだよ。

└

入力と出力トークンでお金を稼いでる会社は、無駄な制約や指示が大量にやり取りされるから、過剰なスキルが本当に好きだと思う。「パスワードを平文で保存しないで」とか「常に構文エラーをチェックする」とか、明らかなガイドラインがたくさんあるからね。

時々、段階を追ってLLMを導くのを嫌がる自分が、部屋で唯一まともな人間なんじゃないかって思うことがある。次のスキルを選んだり、エラーをキャッチしたりするのは、ビジネスのトレードオフみたいな、もっと重要なことに使える時間を無駄にしてるだけだよね。

ハクソク