AI駆動開発テンプレート集｜CLAUDE.md・SKILL.md一括ダウンロード

テンプレートは、次のフォルダの形で置いて使います。zip も同じ形になっていて、プロジェクトのいちばん上のフォルダにそのまま重ねて置けます。

プロジェクトのフォルダ/
├── CLAUDE.md                 … プロジェクトの説明と決まり
├── AGENTS.md                 … ほかのAIツールとも共有する説明
├── .claude/
│   ├── settings.json         … 権限と Hooks の設定
│   ├── rules/                … ファイルの種類ごとの決まり
│   ├── hooks/                … Hooks で動かすスクリプト
│   ├── skills/               … よく頼む作業の手順（4つ）
│   └── agents/               … サブエージェント（2つ）
└── prompts/                  … 依頼文の雛形（4つ）

home/.claude/CLAUDE.md        … 自分のパソコン全体に効く好み（~/.claude/ に置く）

テンプレートの一覧

どのファイルが何をするかを、先に一覧にしました。名前を押すと、そのテンプレートへ進めます。

CLAUDE.md とルール

CLAUDE.md は、Claude Code が毎回の作業の最初に読む説明書です。同じ説明を毎回くり返さずに済むように、コマンド・構成・決まりを書いておきます。公式ドキュメントでは、1ファイル200行以内が目安とされています。

CLAUDE.md（プロジェクト用）

プロジェクトのいちばん上に置きます。〔 〕の所と、コマンド・フォルダ名を自分のプロジェクトに合わせて書き換えます。最後の行の @docs/spec.md のように @ でパスを書くと、そのファイルも一緒に読み込まれます。

# プロジェクトの説明

〔このプロジェクトが何をするものかを1〜2行で〕
例：社内の勤怠を入力・集計する Web アプリ。フロントは Next.js、API は Spring Boot。

## よく使うコマンド

- 開発サーバーの起動：`npm run dev`
- テスト：`npm run test`
- 1ファイルだけテスト：`npm run test -- path/to/file.test.ts`
- 静的解析：`npm run lint`
- 型チェック：`npm run typecheck`

## フォルダの構成

- `src/app/`：画面（Next.js の App Router）
- `src/components/`：共通の部品
- `src/lib/`：API の呼び出しや共通処理
- `api/`：バックエンド（Spring Boot）

## 書き方の決まり

- TypeScript は strict。`any` は使わず、型が分からないときは `unknown` にして絞り込む
- 部品は関数コンポーネントで書き、1ファイル1部品
- 日付は `src/lib/date.ts` の関数を使い、`new Date()` を直接並べない
- エラーは握りつぶさず、呼び出し元に分かる形で返す

## 作業の進め方

- 実装の前に、変更するファイルと方針を短く書いて確認を取る
- 1つの依頼で直すのは、頼まれた範囲だけにする（ついでの大きな書き換えはしない）
- コードを変えたら、関係するテストを足すか直し、`npm run test` が通ることを確かめる
- 終わったら、変更したファイルと理由を箇条書きでまとめる

## 触らないもの

- `.env` と `secrets/` の中身は読まない・書かない
- `src/generated/` は自動生成なので直接編集しない
- 依存パッケージの追加は、理由を書いて確認を取ってから

## 参考

詳しい仕様は @docs/spec.md 、API の一覧は @docs/api.md を見る。

~/.claude/CLAUDE.md（自分の好み）

ホームフォルダの .claude に置くと、すべてのプロジェクトで読まれます。返事の言葉や書き方の好みなど、プロジェクトに関係なく守ってほしいことを書きます。

# 自分の好み（すべてのプロジェクト共通）

- 返事は日本語で、結論から短く
- コードの説明は、変えた理由を先に書く
- コミットメッセージは日本語、1行目は50文字以内
- 分からないことは推測で進めず、質問してから進める
- 長いログは全部貼らず、要点と該当行だけを示す

.claude/rules/（ファイルの種類ごとの決まり）

先頭の paths に書いたファイルを扱うときだけ読み込まれます。画面のコードとAPIのコードで決まりが違うときに、CLAUDE.md を長くせずに済みます。

---
paths:
  - "src/**/*.{ts,tsx}"
---

# 画面のコードの決まり

- スタイルは Tailwind のクラスで書き、CSS ファイルは増やさない
- 画像は `next/image` を使う
- 文字列はそのまま埋め込まず、`src/messages/ja.json` に置く
- 新しい部品には、表示を確かめるテストを1つ以上付ける

---
paths:
  - "api/src/**/*.java"
---

# API のコードの決まり

- Controller は受け取りと返却だけにして、処理は Service に書く
- 入力は Bean Validation（@Valid）で確かめる
- エラーは共通の形（code・message）で返す
- SQL は Repository に集め、文字列をつなげて組み立てない

詳しい書き方：CLAUDE.mdの書き方｜何を書くか・置き場所・育て方【テンプレートつき】

settings.json と Hooks

settings.json では、Claude Code が確認なしで実行してよいコマンド（allow）、毎回確認するコマンド（ask）、使わせないもの（deny）を決めます。Hooks は、決まったタイミングで自動的にスクリプトを動かす仕組みです。CLAUDE.md の決まりは「お願い」ですが、Hooks で止めたものは確実に止まります。

.claude/settings.json

テストや静的解析のコマンドは確認なしで動かし、push は毎回確認し、.env と secrets フォルダは読ませない設定です。あわせて、下の2つのスクリプトを Hooks に登録しています。JSON なので、コメントや最後のカンマを書くとエラーになります。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run typecheck)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guard.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/format.sh"
          }
        ]
      }
    ]
  }
}

.claude/hooks/（Hooks で動かすスクリプト）

format.sh は、ファイルを書き換えたあとに Prettier（Python は ruff）で整形します。guard.sh は、main への強制 push と、.env の中身を表示するコマンドを、実行の前に止めます。止めたときに書いた理由は Claude に伝わるので、別の方法を考えてくれます。

#!/usr/bin/env bash
# ファイルを書き換えたあとに、拡張子に合わせて整形する（PostToolUse で呼ぶ）
# 受け取る JSON の tool_input.file_path に、書き換えたファイルのパスが入る
file=$(jq -r '.tool_input.file_path // empty')
[ -z "$file" ] && exit 0
[ -f "$file" ] || exit 0

case "$file" in
  *.ts|*.tsx|*.js|*.jsx|*.json|*.css|*.md)
    npx --no-install prettier --write "$file" >/dev/null 2>&1 ;;
  *.py)
    ruff format "$file" >/dev/null 2>&1 ;;
esac

# 整形に失敗しても作業は止めない
exit 0

#!/usr/bin/env bash
# Bash を実行する前に、止めたいコマンドを確かめる（PreToolUse で呼ぶ）
# exit 2 で止めると、標準エラーに書いた理由が Claude に伝わる
cmd=$(jq -r '.tool_input.command // empty')

# main への強制 push は止める
if printf '%s' "$cmd" | grep -Eq 'git push.*(--force|-f)( |$).*main|git push.*main.*(--force|-f)( |$)'; then
  echo "main への強制 push は止めています。必要なときは人が手で実行します。" >&2
  exit 2
fi

# .env を表示・コピーするコマンドは止める
if printf '%s' "$cmd" | grep -Eq '(cat|less|head|tail|cp|mv) [^|;]*\.env'; then
  echo ".env の中身を扱うコマンドは止めています。" >&2
  exit 2
fi

exit 0

使う前に、次の3点を確かめます。

• 実行の許可を付ける：chmod +x .claude/hooks/*.sh
• JSON を読むために jq を使っています。入っていなければ入れておきます（Mac は brew install jq）
• Windows では、WSL か Git Bash の上で Claude Code を動かすと、そのまま使えます

詳しい書き方：Claude Code settings.json設定一覧｜権限の雛形と優先順位／Claude Code Hooksの使い方｜全33イベント表と設定例・止め方

Skills（よく頼む作業の手順）

Skills は、よく頼む作業の手順を1つのファイルにまとめたものです。/code-review のようにスラッシュで呼べるほか、説明（description）に合う依頼をすると Claude が自分で読み込みます。!`コマンド` と書いた行は、読み込む前に実行され、結果に置き換わります。以前の .claude/commands/ も今は Skills にまとめられていて、同じように動きます。

code-review（変更のレビュー）

いまの変更（git diff）を読み込んでからレビューします。重要度を3段階に分けて返すので、直す順番を決めやすくなります。

---
description: 変更したコードをレビューする。「レビューして」「見てほしい」「PR を出す前に確認」と頼まれたときに使う。
allowed-tools: Bash(git diff *), Bash(git status), Read, Grep, Glob
---

## いまの変更

!`git diff HEAD`

## レビューのしかた

上の変更を、次の順に確かめる。

1. 動き：頼まれたとおりに動くか。抜けている場合分け（空・null・0件・上限）はないか
2. 壊れ方：エラーのときに何が起きるか。握りつぶしていないか
3. 読みやすさ：名前・関数の長さ・重複
4. テスト：変更に合うテストがあるか。足りないテストケースは何か
5. CLAUDE.md の決まりに合っているか

## 返し方

- 重要度を「直したほうがよい」「できれば」「好み」の3段階に分ける
- 指摘ごとに、ファイル名と行、理由、直し方の例を1つ書く
- 良いところも1〜2点書く
- 変更が空なら「変更はありません」とだけ返す

commit-message（コミットメッセージを作る）

ステージした変更と最近のコミットを読み込み、これまでの書き方にそろえたメッセージを作ります。

---
description: ステージした変更からコミットメッセージを作る。「コミットメッセージを考えて」「コミットして」と頼まれたときに使う。
allowed-tools: Bash(git diff *), Bash(git log *)
---

## ステージした変更

!`git diff --staged`

## 最近のコミット（書き方をそろえるため）

!`git log --oneline -10`

## 作り方

- 1行目は「何をしたか」を50文字以内で。最近のコミットの書き方（接頭辞・言語）に合わせる
- 2行目は空ける
- 3行目から「なぜ変えたか」と、気をつける点を箇条書きで
- 変更がいくつかの目的に分かれるなら、コミットを分ける案も出す
- ステージした変更が空なら、そのことだけを伝える

write-tests（テストを書く）

/write-tests src/lib/date.ts のように対象を渡すと、$ARGUMENTS の所に入ります。テストケースの一覧を先に見せてから書くので、抜けに気づきやすくなります。

---
description: 指定したファイルや関数のテストを書く。「テストを書いて」「テストを足して」と頼まれたときに使う。
argument-hint: "[ファイルのパス]"
---

対象：$ARGUMENTS

## 手順

1. 対象のコードを読み、入力と出力、外とのやり取り（DB・API・ファイル）を書き出す
2. テストケースを先に一覧にする
   - ふつうの値
   - 境目の値（0・1・上限・上限+1）
   - 空・null・未定義
   - エラーになる入力
3. 一覧を見せて、足りないケースがないか確認を取る
4. プロジェクトで使っているテストの道具と書き方に合わせて書く
5. テストを実行し、通ることを確かめる。落ちたら、コードとテストのどちらが正しいかを説明する

## 気をつけること

- 実装の中身を写すだけのテストにしない（振る舞いを確かめる）
- 外とのやり取りはモックにし、テストどうしが影響し合わないようにする

fix-issue（Issue を読んで直す）

/fix-issue 123 のように番号を渡して使います。disable-model-invocation: true にしているので、Claude が自分の判断で動かすことはなく、呼んだときだけ動きます。GitHub CLI（gh）を使います。

---
description: GitHub の Issue を読んで直す
disable-model-invocation: true
argument-hint: "[Issue の番号]"
allowed-tools: Bash(gh issue view *)
---

GitHub の Issue #$ARGUMENTS を直す。

1. `gh issue view $ARGUMENTS` で内容を読む
2. 再現の手順と、期待する動きを短くまとめる
3. 原因の候補を挙げ、関係するコードを探す
4. 直す方針を書いて、確認を取る
5. 直して、再現しないことを確かめるテストを足す
6. テストと静的解析を通し、変更点をまとめる

詳しい書き方：Claude Code Skillsの作り方｜SKILL.md雛形と項目一覧／Claude CodeのSKILL.mdの書き方と実物を無料配布｜実務プロンプト集も

サブエージェント

サブエージェントは、作業の一部を別の担当に任せる仕組みです。担当は自分専用の会話で作業し、結果だけを返すので、元の会話が長いログで埋まらずに済みます。

code-reviewer（レビュー担当）

読む・探す道具だけを持たせ、コードは書き換えずに指摘だけを返す担当です。

---
name: code-reviewer
description: コードの変更をレビューする専門の担当。実装が終わったあとや、PR を出す前に使う。
tools: Read, Grep, Glob, Bash
model: sonnet
---

あなたはコードレビューの担当です。呼ばれたら、次の順に進めます。

1. `git diff` で変更を確かめる
2. 変更したファイルの周りのコードも読み、影響する範囲をつかむ
3. 動き・エラー処理・読みやすさ・テストの4点で確かめる

返すときは、重要度の高い順に並べ、それぞれにファイル名と行、理由、直し方の例を書きます。
コードは書き換えず、指摘だけを返します。

test-runner（テスト担当）

テストを実行して、落ちたテストの要点だけを返す担当です。速くて軽い haiku を指定しています。

---
name: test-runner
description: テストを実行して、落ちたテストの原因を調べる担当。コードを変えたあとに使う。
tools: Read, Grep, Glob, Bash
model: haiku
---

あなたはテストの担当です。

1. プロジェクトのテストを実行する（CLAUDE.md に書かれたコマンドを使う）
2. すべて通ったら、通った件数だけを短く返す
3. 落ちたテストがあれば、テストごとに次を返す
   - テストの名前
   - エラーの要点（全文ではなく、原因が分かる数行）
   - 原因の見立てと、直す場所の候補

長いログをそのまま返さず、呼んだ側がすぐ判断できる形にまとめます。

詳しい書き方：Claude Codeサブエージェントの使い方｜実測で見る委任とコンテキスト節約

AGENTS.md（ほかのAIツールと共有する）

AGENTS.md は、AIのコーディングツールに向けた説明を書くための共通のファイル名です。Claude Code は、CLAUDE.md が無いプロジェクトでは AGENTS.md を読みます（v2.1.277 以降）。CLAUDE.md と両方を使うときは、CLAUDE.md に @AGENTS.md と1行書いて読み込むと、説明を1か所にまとめられます。

# AGENTS.md

AI のコーディングエージェントに向けた、このプロジェクトの説明です。

## 概要

〔このプロジェクトが何をするものかを1〜2行で〕

## セットアップとコマンド

- 依存のインストール：`npm install`
- 開発サーバー：`npm run dev`
- テスト：`npm run test`
- 静的解析：`npm run lint`

## 書き方の決まり

- TypeScript は strict。`any` は使わない
- 1ファイル1部品。名前はファイル名とそろえる
- エラーは握りつぶさない

## 変更の進め方

- 頼まれた範囲だけを変える
- 変更したら、テストと静的解析が通ることを確かめる
- `.env` と `secrets/` は読まない・書かない

詳しい書き方：AGENTS.mdの書き方テンプレ｜copilot-instructions比較

依頼文の雛形

AIに頼むときに毎回書く内容を、4つの雛形にしました。〔 〕を埋めて、そのまま貼って使います。どれも「いきなり作業させず、先に方針を見せてもらう」形にしているので、思っていたのと違う方向に進みにくくなります。

仕様を渡して実装を頼む

目的・やること・やらないことを分けて書くと、頼んだ範囲の外まで書き換えられにくくなります。

# 仕様を渡して実装を頼む

次の機能の実装をお願いします。

## 目的
〔誰が・何のために使うか〕

## やること
- 〔画面・API・処理を箇条書きで〕

## やらないこと
- 〔今回は触らない範囲〕

## 決まりごと
- 入力のチェック：〔例：メールアドレスの形、必須項目〕
- エラーのとき：〔例：画面に赤字でメッセージ〕
- 参考にする既存のコード：〔ファイルのパス〕

## 進め方
1. まず、変更するファイルと方針を書いて見せてほしいです
2. 確認が取れたら実装し、テストも足してほしいです
3. 最後に、変更点と確かめた方法をまとめてほしいです

バグの調査を頼む

調べる段階と直す段階を分け、原因の候補を順位つきで返してもらいます。

# バグの調査を頼む

次の不具合の原因の調査をお願いします。この段階では、コードはまだ直さずにおいてほしいです。

## 起きていること
〔何をしたら、何が起きたか〕

## 期待していた動き
〔本来どうなるはずか〕

## エラーメッセージ・ログ
```
〔そのまま貼る〕
```

## 分かっていること
- 起きる環境：〔例：本番だけ、Safari だけ〕
- いつから：〔例：昨日のリリース後〕

## 返してほしいこと
1. 原因の候補を、可能性の高い順に3つまで
2. それぞれを確かめる方法
3. いちばん有力な原因と、直し方の案

先に計画を立ててもらう

プランモードを使わないときも、この依頼文で同じ進め方ができます。

# 先に計画を立ててもらう

次の作業の計画をお願いします。計画を承認するまでは、ファイルを変更せずにおいてほしいです。

## 作業
〔やりたいこと〕

## 計画に入れてほしいこと
1. 変更するファイルの一覧と、それぞれで何をするか
2. 作業の順番（小さく確かめながら進められる区切り）
3. 影響しそうな既存の機能と、その確かめ方
4. 迷っている点・決めてほしい点

計画は箇条書きで、1画面に収まる長さだと助かります。

レビューを頼む

見てほしい所を書いておくと、指摘がそこに集まります。

# レビューを頼む

次の変更のレビューをお願いします。コードは書き換えず、指摘だけを返してほしいです。

## 変更の目的
〔何のための変更か〕

## 特に見てほしいところ
- 〔例：エラー処理、同時に更新されたときの動き〕

## 返し方
- 重要度を「直したほうがよい」「できれば」「好み」に分ける
- 指摘ごとに、ファイル名と行、理由、直し方の例
- 良いところも1〜2点

詳しい書き方：プロンプトの書き方｜エンジニア向けテンプレート20個と型の一覧／Claude Code プランモードの使い方｜起動方法と依頼文の型10例

使い始める手順

1. 使うテンプレートを「コピー」か「ダウンロード」で取り出します。まとめて欲しい場合は、ページの上の zip を使います（入っているのは、このページに載せたテキストファイルだけです）。
2. プロジェクトのいちばん上のフォルダに、同じフォルダの形で置きます。home/.claude/CLAUDE.md だけは、ホームフォルダの ~/.claude/ に置きます。
3. CLAUDE.md と AGENTS.md の〔 〕、コマンド、フォルダ名を書き換えます。使わないファイル（Python を使わないなら format.sh の該当行など）は消します。
4. Hooks のスクリプトを使う場合は、chmod +x .claude/hooks/*.sh で実行の許可を付けます。
5. Claude Code を起動し、/status で設定ファイルが読み込まれていることを確かめます。
6. チームで使うときは、.claude/・CLAUDE.md・AGENTS.md をリポジトリにコミットします。自分だけの設定は .claude/settings.local.json と CLAUDE.local.md に書き、コミットしません。

よくある質問

Q. zip の中身は何ですか？
A. このページに全文を載せているテキストファイル（.md・.json・.sh）だけです。プログラム（.exe など）は入っていません。会社のネットワークで zip が開けない場合は、各テンプレートの「コピー」で同じものを使えます。

Q. 全部入れる必要がありますか？
A. CLAUDE.md だけでも始められます。同じ説明を何度もするようになったら CLAUDE.md に足し、同じ手順を何度も頼むようになったら Skills に、毎回確実に止めたいことが出てきたら Hooks に、と育てていく使い方がおすすめです。

Q. CLAUDE.md と Skills はどう使い分けますか？
A. 毎回の作業で知っていてほしい事実（コマンド・構成・決まり）は CLAUDE.md、特定の作業のときだけ使う手順は Skills です。手順を CLAUDE.md に書くと毎回読み込まれるので、長くなるほど効きが弱くなります。

Q. 商用のプロジェクトで使ってよいですか？
A. 使えます。自由に書き換えてお使いいただけます。社内の決まりやプロジェクトに合わせて足していくと、そのチームの資産になります。

Q. 書式は今後変わりますか？
A. Claude Code は更新が速く、項目が増えることがあります。このページは公式ドキュメントに合わせて更新し、更新日を書き換えます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。