.claude フォルダを制した者が、Claude Code を制する——CLAUDE.md、commands、skills、agents で『命令待ち』から『自律』へ

クソ人間の達人氏が X で『.claude フォルダを制した者が、Claude Code を制する』と公開した。CLAUDE.md、commands、skills、agents を使い倒して、Claude Code を『命令待ちのツール』から『自律的に動く最強の部下』に変える仕組みを解説。200 行以内の CLAUDE.md、カスタムスラッシュコマンド、自律起動スキル、専門分業エージェント、権限の 3 層構造で完全制御。

2026年3月25日

2026 年 3 月、クソ人間の達人氏（@kuso_inc）が X で**「.claude フォルダを制した者が、Claude Code を制する」**と公開した。

CLAUDE.md、commands、skills、agents。全部使い倒して、Claude Code を「命令待ちのツール」から「自律的に動く最強の部下」に変えた仕組みを全部話す。

これは、Claude Code を真に使いこなすための完全ガイドだ。

本稿はこの仕組みの概要、各コンポーネントの役割、そして具体的な実装方法を解説する。

よくある間違い

まず、よくある間違いを並べておこう。

❌ 毎回チャットで丁寧に指示してる
❌ 「こういう書き方で」「ここはこうして」と一から説明してる
❌ プロジェクト変わるたびにゼロから設定し直してる

全部ハズレ。

正解は**「Claude が最初から文脈を知ってる状態を最初に作ること」**だ。

.claude フォルダとは何か

Claude Code には**.claude/**というフォルダがある。

存在は知ってた。でも開いたことがなかった。当然、使い方も知らなかった。

これが最も勿体なかった発見だ。

「.claude フォルダ」とは何か？ Claude にとっての「脳の OS」だ。何を知っていて、何をしていいか、何をしてはいけないか。全部ここに書いてある。

このフォルダさえ設計してしまえば、Claude は毎回説明しなくていい状態で起動する。「初日から文脈を知ってる即戦力」として。

構成

your-project/
├── CLAUDE.md              # Claude への「脳の設定書」（チーム共有）
├── CLAUDE.local.md        # 自分だけの個人設定（gitignore）
└── .claude/
    ├── settings.json      # 権限設定（commit 可）
    ├── commands/          # カスタムスラッシュコマンド
    ├── rules/             # モジュール型の追加指示
    ├── skills/            # 自律起動するワークフロー
    └── agents/            # 専門分業の「部下エージェント」

順番に全部解説する。

① CLAUDE.md ── セッション開始時に一番最初に読まれるファイル

これが最重要ファイルだ。

Claude Code はセッション開始時、真っ先にCLAUDE.mdを読み込む。

それ以降ずっとその内容を頭に入れたまま動く。

つまり**「CLAUDE.md に書いたことは Claude が必ず守る」**。

「テストは npm run test で走らせろ」「console.log は禁止、logger モジュールを使え」「TypeScript の strict モードがオンだ」。

こういうことを毎回説明しなくてよくなる。

注意点

CLAUDE.md は200 行以内に収めること。

それ以上になると、Claude の指示遵守率が実際に下がる。長すぎるファイルはコンテキストを圧迫する。

書くべきこと・書くべきでないこと

書くべきこと

✅ ビルド、テスト、lint のコマンド
✅ プロジェクトのアーキテクチャの重要な決定（「モノレポで Turborepo を使ってる」等）
✅ 非自明な地雷（「TypeScript strict モードがオン、未使用変数は即エラー」等）
✅ import 規則、命名パターン、エラーハンドリングのスタイル

書くべきでないこと

❌ linter や formatter 設定に書くべき内容
❌ リンクで代替できるドキュメント
❌ 長い理論的な説明

【保存推奨】今すぐ使える CLAUDE.md テンプレート

これをプロジェクトルートに置くだけで、Claude が「初日採用した即戦力」として動き始める。

# Project: [プロジェクト名]

## Commands
npm run dev      # 開発サーバー起動
npm run test     # テスト実行（Jest）
npm run lint     # ESLint + Prettier チェック
npm run build    # 本番ビルド

## Architecture
- Express REST API, Node 20
- PostgreSQL via Prisma ORM
- 全ハンドラーは src/handlers/ に置く
- 共有型定義は src/types/ に集約

## Conventions
- リクエスト検証は必ず zod を使う
- レスポンス形式は常に { data, error } で返す
- スタックトレースをクライアントに絶対に露出させない
- console.log は禁止。必ず logger モジュールを使う

## Watch out for
- テストはモックではなくローカル DB で実行。事前に npm run db:test:reset を走らせること
- TypeScript strict モードがオン。未使用の import は即エラーになる

② .claude/commands/ ── カスタムのスラッシュコマンドを量産する

ここに markdown ファイルを 1 個置くだけで、カスタムのスラッシュコマンドが生まれる。

ファイル名	生成されるコマンド
review.md	/project:review
fix-issue.md	/project:fix-issue
deploy.md	/project:deploy

今まで毎回手で打ってた指示が、1 コマンドに集約される。

しかも、コマンドファイルの中に**!git diff main...HEAD**のような記法を使えば、シェルコマンドの実行結果をそのまま Claude のプロンプトに埋め込める。

「どのファイルが変わったか」を Claude が自動で把握した上でコードレビューする、という芸当が可能になる。

【保存推奨】コードレビューコマンドのテンプレート

.claude/commands/review.mdとして保存すれば/project:review コマンドが即完成する。

---
description: マージ前にカレントブランチの差分をレビューする
---
## 変更対象ファイル

!`git diff --name-only main...HEAD`

## 詳細な Diff

!`git diff main...HEAD`

以下の観点で上記の変更をレビューしてください：
1. コード品質の問題
2. セキュリティの脆弱性
3. テストカバレッジの欠落
4. パフォーマンスへの懸念

ファイルごとに具体的で実行可能なフィードバックを出してください。

③ .claude/skills/ ── Claude が「自律的に」起動するワークフロー

commands との違いが分かるか？

❌ commands：お前がスラッシュコマンドで明示的に呼び出す
⭕️ skills：Claude が会話を読んで、自律的に判断して動かす

「PR のセキュリティチェックして」と言うだけで、Claude が「これは security-review のスキルを使う場面だ」と判断して、自動でワークフローを走らせる。呼び出しすらいらない。

skills は単一ファイルではなく「パッケージ」で管理できる点も大きい。

.claude/skills/
├── security-review/
│   ├── SKILL.md          # スキルの定義
│   └── DETAILED_GUIDE.md # 詳細な基準ドキュメント
└── x-post-writer/
    ├── SKILL.md
    └── style-reference.md # 文体のリファレンス

【保存推奨】セキュリティレビュースキルのテンプレート

.claude/skills/security-review/SKILL.mdとして保存する。

---
name: security-review
description: セキュリティ監査。コードのレビュー時、デプロイ前、
  またはユーザーがセキュリティに言及した際に使用する。
allowed-tools: Read, Grep, Glob
---
以下の観点でコードベースのセキュリティ脆弱性を分析してください：

1. SQL インジェクションと XSS のリスク
2. 認証情報やシークレットの露出
3. 安全でない設定
4. 認証・認可のギャップ

深刻度の評価と具体的な修正手順を含めてレポートしてください。

④ .claude/agents/ ── 専門分業の「部下エージェント」

複雑なタスクを専門家に分業させる仕組みだ。

.claude/agents/
├── code-reviewer.md      # コードレビュー専門
└── security-auditor.md   # セキュリティ監査専門

それぞれのエージェントは独立したコンテキストウィンドウで動く。メインセッションが汚染されない。そして「使えるツールの権限」を個別に設定できる。

セキュリティ監査のエージェントにはファイルの読み取り（Read, Grep, Glob）しか持たせない。書き込みは絶対させない、という設計だ。

主人（お前）が権限を握る。これが支配者の設計思想。

model フィールドでモデルを指定できるのも大きい。単純な読み取り探索は Haiku で十分。Sonnet と Opus は本当に必要な判断業務にだけ使う。これでコストを劇的に削減できる。

⑤ settings.json ── 権限の 3 層構造でリスクを完全に制御する

Claude が「できること・できないこと」を定義する。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Read",
      "Write",
      "Edit"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

権限の 3 層構造

層	操作	動作
allow	書いた操作	確認なしで即実行
deny	書いた操作	絶対に実行されない
どちらにもなければ	-	都度 Claude が確認してくる

この 3 層構造でリスクコントロールが完璧になる。特に deny に.env の読み取りを入れることは必須だ。

よくやってる間違い

❌ 「なんとなく CLAUDE.md に全部書く」→ 300 行になって誰も管理しない
❌ 「毎回チャットで同じ説明をする」→ 認知資源の垂れ流し（毎日消えていく）
❌ 「設定は後でいい、まず使う」→ 最初の設計ミスが永遠に残る
❌ 「チームで共有しない」→ 自分だけが使いこなせる属人化の地獄

全部ハズレ。

正解は、初日に.claude フォルダを設計して、Claude が「文脈ごと理解してる部下」として最初から動く状態を作ること。

そのために「.claude/rules/」もある。CLAUDE.md が肥大化してきたら、ここに役割ごとにファイルを分割する。code-style.md、testing.md、api-conventions.md。担当者ごとに管理できて、互いに干渉しない。

整備後の開発フロー

設計 → Antigravity が自動で出す
実装 → Claude Code が自律的に走らせる
コードレビュー → code-reviewer エージェントが専任で見る
セキュリティ → security-auditor エージェントが別コンテキストで並列に走る
最終確認 → 俺が方向性の判断だけする

人間がやるのは「どこを作るか」の意思決定だけ。

これが"AI ネイティブ個人"の正体だ。

結論：真の自動化

X を見ると「AI で全自動化！」「寝てるだけで投稿できる！」があふれてる。

蓋を開けてみれば、裏で人間がコピペして、毎回 ChatGPT に同じ指示を打ち込んでいるだけだ。

「自動化してる風」の手作業
「AI を使いこなしてる風」のコピペ作業

ツールが増えただけで、本人の時間は全然減っていない。

Claude が実際にブラウザを開いて、ファイルを保存して、レビューを走らせる。人間が「実行」に使っていた時間が、本当にゼロになる仕組み。

それが真の自動化だ。

参考：

引用元・参考リンク

クソ人間の達人氏の X 投稿

.claude フォルダの活用術

X Articles

.claude フォルダを制した者が、Claude Code を制する

詳細記事

#Claude Code #.claude #CLAUDE.md #skills #agents #commands #AI 自動化 #開発効率

免責事項 — 掲載情報は執筆時点のものです。料金・機能は変更される場合があります。最新情報は各公式サイトをご確認ください。