ハクソク

世界を動かす技術を、日本語で。

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

2026年5月27日原文(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を変えたりはせず、別のことをしてたな。

Hacker Newsで議論の続きを見る