Claude Codeプロンプトライブラリの育て方: 使い捨て指示を資産に変える

プロンプトは使い捨てにしない

Claude Codeの成果が安定しないチームほど、毎回その場でプロンプトを書いています。よい指示文を見つけても、名前、用途、入力、期待出力、検証例が残らないため、次の人が再利用できません。

この記事は レビュー運用チェックリスト と 最初の30分チェックリスト の続きです。無料PDFで基本を覚えたあと、よく使う指示を小さなライブラリにして、最終的にテンプレート集や導入相談へつなげます。

1プロンプト1目的で登録する

最初のルールは、1つのプロンプトに1つの目的だけを持たせることです。「レビューもして、テストも作って、ドキュメントも直して」は便利そうですが、失敗時にどこが悪いのか分かりません。

{
  "id": "review-risk-finder",
  "owner": "platform",
  "useWhen": "A pull request changes behavior, data flow, or CTA routing.",
  "inputs": ["diff", "goal", "riskAreas"],
  "output": "Findings ordered by severity with file references.",
  "proof": "Run once on a known risky diff before adding it to the library."
}

このメタ情報があると、記事、商品、社内wikiのどこに置いても同じ説明で使えます。特に “proof” を入れると、単なる思いつきではなく検証済みの資産になります。

コピペできる基本テンプレート

レビュー用なら、目的、差分、リスク領域、出力形式を固定します。Claude Codeに「よしなに見て」ではなく、何を危険とみなすかを先に渡します。

あなたは本番リスクを見るレビュアーです。
前提:
- 目的: {{goal}}
- 差分: {{diff}}
- リスク領域: {{riskAreas}}

指摘を先に返してください。
各指摘には重要度、根拠、利用者への影響、最小修正を含めます。
指摘がない場合は、確認した範囲と未検証の範囲を書いてください。

この形なら、コードレビュー、CTA変更、フォーム修正、商品ページ編集に横展開できます。違いは “riskAreas” だけです。

失敗例: 名前が抽象的すぎる

“good-review-prompt” や “debug-helper” のような名前は、あとで探せません。名前には用途と成果を入れます。たとえば “review-risk-finder”、“build-log-first-failure”、“cta-copy-clarifier” のようにします。

もう一つの失敗は、成功例だけ保存することです。悪い出力が出た入力も残すと、テンプレートの境界が見えます。Claude Codeのプロンプト資産は、成功例と失敗例のセットで強くなります。

小さな検証スクリプトを持つ

ライブラリが10個を超えたら、最低限の項目漏れをチェックします。

const required = ["id", "owner", "useWhen", "inputs", "output", "proof"];

export function validatePrompt(entry) {
  const missing = required.filter((key) => !entry[key]);
  return {
    ok: missing.length === 0,
    missing,
    ready: missing.length === 0 && entry.proof.includes("Run once"),
  };
}

これだけでも、所有者不明、用途不明、検証なしのプロンプトが増えるのを防げます。収益導線の記事では、無料PDFの基本プロンプトから有料テンプレート集へ自然に進める説明も書きやすくなります。

3つの置き場所を分ける

プロンプトライブラリは、置き場所を間違えるとすぐ使われなくなります。おすすめは、用途ごとに3つの層に分けることです。

1つ目は、リポジトリ内の docs/prompts/ や CLAUDE.md に置く作業プロンプトです。これは日々の開発で最も使います。レビュー、テスト生成、ビルドログ整理、リリースノート作成のように、リポジトリ固有の前提が必要なものを置きます。

2つ目は、社内wikiやNotionに置く説明用プロンプトです。なぜそのプロンプトがあるのか、いつ使うのか、失敗例は何かを書きます。新しく入った人はここを読み、実際のコピー元はリポジトリを見る、という分担にします。

3つ目は、有料商品や無料PDFに近い外向きのプロンプトです。ここでは、社内事情を消し、誰でも使える形に整えます。ClaudeCodeLabなら、無料チートシートは短い型を渡し、Prompt Templatesは実務で使える完成形を渡す、という分け方です。

このプロンプトをライブラリ登録用に整えてください。
返してほしい形式:
- id
- 使う場面
- 必要な入力
- 期待する出力
- 悪い使い方
- 検証済みの例
- 無料PDF向きか、有料テンプレート向きか

この整理をすると、単に「便利なプロンプト集」ではなく、無料PDF、Gumroad教材、導入相談につながる階段になります。読者はまず短い型で試し、次に完成済みテンプレートを買い、チーム展開で詰まったら相談する、という順番を理解しやすくなります。

月1回のメンテナンス手順

プロンプトライブラリは、作った日よりも更新日の方が重要です。月1回だけ、次の順番で見直すと腐りにくくなります。

見る項目	確認すること	修正例
名前	用途が名前で分かるか	debug-helper を build-log-first-failure に変える
入力	必要な情報が抜けていないか	diff、goal、riskAreas を必須にする
出力	レビューしやすい形か	重要度、根拠、影響、最小修正を固定する
証拠	実際に試した記録があるか	成功例と失敗例を1つずつ残す
導線	次に買う/相談する理由が自然か	無料PDF、Prompt Templates、導入相談に分ける

この見直しで一番削るべきなのは、似たプロンプトです。たとえば「レビューして」「セキュリティを見て」「リスクを探して」が別々に存在すると、使う人が迷います。1つの強いレビュー用プロンプトにまとめ、riskAreas だけを変える方が運用しやすくなります。

商品導線にも同じ考え方が使えます。無料PDFは「まず迷わず使える短い型」、Gumroad教材は「完成済みでそのまま使える型」、導入相談は「チームや業務に合わせて型を設計する場」と役割を分けます。記事本文でこの違いを説明しておくと、読者は押し売りではなく、自分の段階に合う次の行動として受け取りやすくなります。

判断に迷うプロンプトは、まだ商品にしない方が安全です。まず無料PDFや記事の中で短い形として試し、読者が何度も使う場面が見えたらテンプレート集に入れます。さらに、チームごとの承認ルールやレビュー文化まで絡むなら、テンプレート販売ではなく導入相談の対象にします。

この線引きを残しておくと、次に似たプロンプトを作るときも判断がぶれません。迷った記録そのものが、あとでライブラリの改善材料になります。小さな記録でも、次のテンプレート販売文や記事CTAを直す根拠になります。

この記事で紹介した内容を実際に試した結果

実際にプロンプトを id と proof つきで保存すると、再利用率が上がります。特にレビュー用プロンプトは、毎回の口頭説明が減り、出力のばらつきも小さくなりました。良いプロンプトを見つけた直後ではなく、1回失敗したあとに直して保存したものの方が長く使えます。

失敗したのは、ライブラリを大きくしすぎたときです。30個以上を一気に並べると、結局どれを使えばよいか分からなくなります。最初は「レビュー」「デバッグ」「ドキュメント」の3カテゴリだけで十分です。検索性より、次の仕事で迷わず選べることを優先してください。

次の導線

まだ型を覚える段階なら 無料チートシート で十分です。レビュー、デバッグ、リファクタ、ドキュメントのプロンプトをすぐ揃えたい場合は 50 Prompt Templates を使ってください。チームでライブラリ運用まで設計するなら 導入相談 が向いています。