効いたプロンプトを使い捨てない：保存・命名・チーム共有とカスタムコマンド化

先週、めちゃくちゃ効くレビュー用プロンプトをその場で書いて、PRが一発で通りました。気分よく仕事を終えて、3日後。同じレビューをやろうとして、僕はそのプロンプトをどこにも見つけられませんでした。

Slackの履歴を遡り、ターミナルの上スクロールを試し、結局また一から書き直す。出来上がったのは、3日前より少し雑な指示文でした。

これ、自分だけかと思っていたら、チームの全員が同じことをやっていたんです。一番効く道具を、毎回その場で作って、毎回捨てている。プロンプトを「書くのが下手」なんじゃない。書いたあと、貯めて使い回す仕組みがないだけでした。

プロンプトの書き方そのものは姉妹記事のClaude Code/Codexプロンプト入門：初心者が成果を出す5つの型に任せます。この記事は、その先。効いた一文をどう保存し、どう名付け、どうチームで配り、どう捨てるかに絞ります。

この記事の要点

• 効いたプロンプトは「個人メモ」で終わらせず、IDと持ち主と版を付けた**台帳（JSON1ファイル）**にする。
• 名前は抽象語を禁止。checkout-cta-risk-review のように対象と成果を入れると、半年後の自分でも探せる。
• よく使う型は、Claude Codeの**カスタムコマンド（現在はスキルに統合）**にすると、長い指示文が /review の一語になる。
• 「全部CLAUDE.mdに書く」は逆効果。CLAUDE.mdは文脈、止めたい操作はフック。役割が違う。
• 棚卸しは月1回。削除ではなく移行にすると、誰の作業も止めずにライブラリが太らない。

まず「台帳」を1ファイル作る

最初の一歩は、立派なテンプレート集を作ることではありません。効いたプロンプトに、最低限の住所を付けて1か所に置くこと。それだけです。

僕が使っているのは、プロンプト本文ではなくメタ情報を先に固めるやり方です。本文はあとでいくらでも直せますが、「誰が直していいのか」「いつ捨てていいのか」が空白だと、誰も手を出せず、結局腐ります。

各プロンプトに付ける項目はこれだけで足ります。

項目	意味	例
id	探すときの一意な名前	review-risk-finder
version	major.minor.patch の版番号	1.2.0
owner	直していい責任者	platform
status	使えるか／下書きか／廃止か	active
useWhen	いつ使うか（迷わないための一言）	「決済やCTAを変えるPRのとき」
metrics	効いているかを測る数字	再利用回数、採用された指摘数

次のJSONはそのまま prompt-library.json として保存できます。最初は1件で十分です。

[
  {
    "id": "review-risk-finder",
    "version": "1.2.0",
    "owner": "platform",
    "status": "active",
    "useWhen": "決済・データの流れ・価格・CTAの導線を変えるPRのとき",
    "inputs": ["goal", "diff", "riskAreas", "expectedTests"],
    "output": "深刻度の高い順に、根拠と最小の修正案を並べる",
    "reviewGate": "ownerの承認 + 既知の危ないdiffで1回成功",
    "deprecates": ["[email protected]"],
    "metrics": ["reuse_count", "accepted_findings", "false_positive_rate"]
  }
]

ポイントは、useWhen を必ず日本語の一文で書くこと。ここが空欄のプロンプトは、半年後に「これ何だっけ」で必ず使われなくなります。

名前で9割決まる：抽象語を禁止する

僕がやらかした最大の失敗は、名前を good-review とか debug-helper にしていたことです。3つ増えた瞬間に、どれがどれだか分からなくなりました。

名前に入れるべきは対象と成果です。「何を見て、何を出すのか」が名前だけで分かるようにします。

ダメな名前	良い名前	何が変わったか
good-review	checkout-cta-risk-review	決済とCTAを見る、と分かる
debug-helper	build-log-first-failure	ビルドログの最初の失敗を見る
marketing-check	pricing-page-objection-check	価格ページの反論潰し、と分かる

長くなって構いません。Slackで「あのレビューのやつ」と呼んでいるうちは資産になりません。checkout-cta-risk-review のように声に出せる名前になって、初めてチームの共有財産になります。

もう一つのコツは、1プロンプト＝1成果物を守ること。レビューも修正もテストもドキュメント更新も1つの指示に詰め込むと、うまくいった日は便利でも、失敗した日に原因が特定できません。テンプレートはこんな形にして、使い道を1つに絞ります。

# checkout-cta-risk-review

あなたは本番リリース前のレビュアーです。事業とユーザーへのリスクだけを見ます。

前提:
- 目的: {{goal}}
- 差分または変更ファイル: {{diff}}
- リスク領域: {{riskAreas}}
- 期待されるテスト: {{expectedTests}}

指摘を先に出してください。各指摘には次を含めます。
1. 深刻度
2. 差分のどこを根拠にしたか
3. ユーザー影響または売上影響
4. 最小で安全な修正案
5. 確認用コマンド

指摘がなければ、何を確認し、何が未確認かを列挙してください。

よく使う型は「カスタムコマンド」に格上げする

台帳に貯まってきたら、毎回コピペしているものをカスタムコマンドにします。長い指示文が、ターミナルで /review の一語になります。

ここは仕様が最近変わったので注意してください。公式ドキュメントによると、カスタムコマンドはスキルに統合されました。.claude/commands/review.md というファイルと、.claude/skills/review/SKILL.md というスキルは、どちらも /review を作り、同じように動きます。今ある .claude/commands/ のファイルはそのまま動き続けるので、慌てて移す必要はありません（出典: Extend Claude with skills）。

ファイルの置き場所で、使える範囲が決まります。

置き場所	パス	使える範囲
個人用	~/.claude/commands/ または ~/.claude/skills/<名前>/	自分の全プロジェクト
プロジェクト用	.claude/commands/ または .claude/skills/<名前>/	そのリポジトリ（チーム共有）

チームで配るなら、プロジェクト用に置いてGitにコミットするのが正解です。これだけで、レビュー基準が「個人の頭の中」から「リポジトリに入った型」に変わります。具体的な作り方とフロントマター（description や argument-hint、disable-model-invocation など）はカスタムスラッシュコマンドで /review・/handoff・/release をチームの型にするに詳しくまとめました。

一番シンプルなコマンドはこれだけです。.claude/commands/review.md に置けば、すぐ /review で呼べます。

---
description: 本番リスク観点でPRをレビューする。決済・CTA・権限・データ削除を見る。
disable-model-invocation: true
---

次の差分を、本番リスクの観点でレビューしてください: $ARGUMENTS

決済・認証・CTA導線・権限・データ削除を必ず確認し、
深刻度の高い順に、根拠と最小の修正案を出してください。

$ARGUMENTS は、コマンドのうしろに付けた文字がそのまま入る場所です。/review この差分 と打てば、その文がここに展開されます。disable-model-invocation: true を付けると、Claudeが勝手にこのコマンドを発火しなくなり、自分が打ったときだけ動きます。デプロイのような副作用のある操作では、これを付けておくと安心です。

CLAUDE.mdに「全部入れる」をやめる

これも僕の失敗です。便利だからと、レビュー観点も禁止事項もデプロイ手順も、全部CLAUDE.mdに突っ込みました。結果、CLAUDE.mdが膨らみすぎて、肝心のルールが守られなくなりました。

公式ドキュメントははっきり書いています。CLAUDE.mdとメモリは文脈であって、強制設定ではない、と。どうしても止めたい操作（削除・本番DB・課金・force push）は、CLAUDE.mdに「やるな」と書くより、PreToolUseフックで止めるのが確実です（出典: How Claude remembers your project）。

役割を分けると、こう整理できます。

置き場所	向いているもの	向かないもの
CLAUDE.md	常に効かせたい事実・規約（命名、ビルドコマンド）	長い手順、絶対に止めたい操作
カスタムコマンド／スキル	呼び出して使う手順（レビュー、引き継ぎ）	セッション開始時の前提
フック	機械的に止める操作（削除・本番反映）	判断が要る曖昧なルール

プロンプトは「判断の型」としてコマンドに、止めたい操作は「関所」としてフックに。この住み分けは、CLAUDE.md側の原則を掘り下げたCLAUDE.mdは「何を書かないか」で決まる：粒度と更新の原則とセットで読むと腑に落ちると思います。

棚卸しは「削除」ではなく「移行」にする

貯める仕組みを作ると、今度は古いプロンプトが溜まります。ここで古いものをいきなり消すと、誰かの作業が止まります。

だから棚卸しは削除ではなく移行にします。古い版は deprecated にして、理由・代替ID・削除予定日を残す。これだけで「最新のつもりで古い挙動に依存する」事故が消えます。

{
  "id": "review-risk-finder",
  "version": "1.1.0",
  "status": "deprecated",
  "deprecatedReason": "ユーザー影響と根拠を分けて出せていなかった",
  "replacement": "[email protected]",
  "removeAfter": "2026-07-31"
}

判断の基準は、貯めた metrics で見ます。数字を見ずに「よく使ってる気がする」で残すと、倉庫が太るだけです。僕は4つだけ見ています。

指標	見る理由	低い/高いときの一手
reuse_count	実際に使われているか	低ければ名前か置き場所を直す
accepted_findings	指摘が採用されたか	低ければ出力形式を絞る
false_positive_rate	時間を奪っていないか	高ければ riskAreas を具体化する
time_to_fix_minutes	修正まで短くなったか	長ければ最小修正案を必須にする

この表を見るのは月1回で十分です。

コピペで動く：台帳の健康診断スクリプト

人の目だけでは、必ず漏れます。owner空欄・版番号なし・status不正のプロンプトが混じる前に、機械で弾きます。次のコードはNode.jsでそのまま動きます。日本語コメント付きです。

// check-prompt-library.mjs
// 使い方: node check-prompt-library.mjs prompt-library.json
import fs from "node:fs";

const file = process.argv[2] ?? "prompt-library.json";
const entries = JSON.parse(fs.readFileSync(file, "utf8"));

// 必須項目。1つでも欠けたら不合格にする
const required = ["id", "version", "owner", "status", "useWhen", "metrics"];
const validStatus = ["draft", "active", "deprecated"];
const semver = /^\d+\.\d+\.\d+$/; // 1.2.0 のような版番号だけ通す

// 抽象的すぎる名前を禁止リストで弾く（半年後に探せなくなる）
const bannedNames = ["good", "helper", "check", "test", "tmp", "new"];

let failed = false;
for (const e of entries) {
  const id = e.id ?? "(idなし)";
  const missing = required.filter((key) => !e[key]);

  if (!semver.test(e.version ?? "")) missing.push("versionはsemver形式に");
  if (!validStatus.includes(e.status)) missing.push("statusはdraft/active/deprecatedのみ");

  // idが単語1つだけ、または禁止語そのものなら名前を直させる
  const looksVague =
    typeof e.id === "string" &&
    (!e.id.includes("-") || bannedNames.includes(e.id.toLowerCase()));
  if (looksVague) missing.push("idが抽象的（対象と成果を名前に入れる）");

  if (missing.length > 0) {
    failed = true;
    console.error(`NG ${id}: ${missing.join(" / ")}`);
  }
}

if (failed) {
  console.error("\n不合格の項目があります。修正してから登録してください。");
  process.exit(1);
}
console.log(`OK: ${entries.length}件のプロンプトを確認しました`);

このスクリプトは品質を保証しません。でも、住所のないプロンプトが増えるのは止められます。チームが大きくなるほど、この地味な関所が効きます。CIに組み込めば、台帳を壊す変更がマージ前に止まります。

よくある質問

Q. プロンプトはどこに保存するのが正解ですか？ A. チームで使うなら、リポジトリの .claude/commands/（または .claude/skills/）に置いてGitで共有するのが一番確実です。SlackやNotebookだけだと、検索性と版管理が弱く、結局「あのときのやつ」を探す時間が増えます。台帳JSONとコマンド本体をリポジトリに入れて、レビューと一緒に育てるのがおすすめです。

Q. カスタムコマンドとスキル、どっちで作ればいいですか？ A. 1ファイルで完結する短い手順なら .claude/commands/review.md で十分です。スクリプトや参照資料を同梱したい、Claudeに自動で選んでほしい、といった場合はスキル（.claude/skills/<名前>/SKILL.md）にします。既存のコマンドはそのまま動き続けるので、必要になったときに移せば大丈夫です。

Q. プロンプトの版番号はどう付ければいいですか？ A. major.minor.patch で十分です。出力形式を壊す変更は major、入力項目を足す変更は minor、言い回しや例の修正は patch。誰かが「最新のつもり」で古い挙動に依存しないことが目的なので、厳密さより一貫性を優先します。

Q. 全部CLAUDE.mdに書けば管理が楽では？ A. 逆効果になりがちです。CLAUDE.mdは長くなるほど守られにくくなり、公式も「文脈であって強制設定ではない」としています。常に効かせたい事実だけをCLAUDE.mdに、呼び出して使う手順はコマンドに、絶対に止めたい操作はフックに。役割で分けるのが結局いちばん楽です。

Q. 使わなくなったプロンプトは消していいですか？ A. いきなり消すと、それに依存していた人の作業が止まります。status を deprecated にして、代替IDと削除予定日を残し、期日が来てから消すのが安全です。研修や有料テンプレートに載せたものは特に、履歴を残すほうが信頼につながります。

実際に試した結果

最初、僕は30個くらいプロンプトを貯めようとして失敗しました。数が多いほど安心に見えるのに、実際は「どれを使うべきか」で迷う時間が増え、ownerも曖昧になったんです。

そこで、レビュー・デバッグ・商品ページ・研修ページの4カテゴリに絞り、各カテゴリで active は3個までと決めました。一番効いたのは、成功例より失敗例を残したことです。「この入力では価格ページの古いリンクを見逃した」と1行残すだけで、次の版で直すべき点がはっきりしました。

冒頭の「3日後に同じプロンプトを書き直した」問題は、台帳1ファイルと /review コマンド1個で消えました。立派なテンプレート集はいりません。効いた一文に住所を付けて、名前で呼べるようにする。これだけで、プロンプトは「個人の勘」から「チームで改善できる資産」に変わります。

型をそのまま使いたい人はClaudeCodeLabの教材テンプレートに、チームで owner・レビュー・棚卸しまで一緒に設計したい人は導入トレーニングを見てみてください。まずは今日、効いたプロンプトを1つだけ prompt-library.json に書き写すところから始めるのが、いちばん速い第一歩です。