プロンプトライブラリとは何ですか？
📍 In One Sentence
プロンプトライブラリとは、チームが発見、再利用、時間をかけて改善できるプロンプトの共有、バージョン管理、検索可能なリポジトリです。
💬 In Plain Terms
プロンプトライブラリをAI指示のコードライブラリと考えてください：すべてが命名され、バージョン管理され、発見可能で、本番に行く前にレビューされます。
プロンプトライブラリとは、チームが検索、再利用、時間をかけて改善できるプロンプトの共有バージョン管理されたコレクションです。 3つの問題を解決します：発見性（必要なことをすでに行うプロンプトを見つける）、重複（同じプロンプトを2回書く）、品質ベースライン（共有前にすべてのプロンプトが最低基準を満たすことを確認する）。
ライブラリなしでは、プロンプトは個人のメモ、Slackメッセージ、ChatGPT履歴に存在します——チームにアクセスできず、バージョン管理されておらず、誰かが去るときに失われます。
3人以上が定期的にプロンプトを書くとき、チームが20種類以上の異なるプロンプトをアクティブローテーションで使用するとき、または誰も以前のバージョンを見つけられなかったために同じプロンプトが再作成されていることに気づいたときに、プロンプトライブラリを構築します。
📌 いつ構築するか
ライブラリを構築するトリガーはサイズではなく、プロンプトの再作成が始まったときです。チームメンバーが「これに対するプロンプトがすでにあると思う」と言ったことがあれば、構築の時です。
フォルダ構造と命名規則
**すべてのプロンプトファイルに `/prompts/テーマ/スラッグ-vバージョン.拡張子` というパターンを使用します。** この構造により、テーマでのフィルタリング、バージョンでのソート、フォーマットの一目での識別が可能になります。
命名規則：小文字のみ、スペースの代わりにハイフン、特殊文字なし。バージョンサフィックス（`-v1`、`-v2`）をファイル名に含めることで、バージョン管理ログを開かずにファイルリストでバージョン履歴が見えるようになります。
⚠️ これらの名前は絶対に使わない
「最新」「最終」「新」「コピー」をファイル名のバージョン識別子として使用しないでください。これらの識別子はすぐに意味をなさなくなり、バージョン履歴が読み取れなくなります。
プロンプトライブラリのバージョン管理戦略
Gitタグを使用してプロンプトの本番バージョンをマークします：そのバージョンが本番にデプロイされたときに `prompt/ticket-triage/v2` とタグを付けます。 これによりロールバックが決定論的になります。
並行編集には、コードと同じブランチング戦略に従います：フィーチャーブランチを作成し、プルリクエストを開き、レビューを得て、マージします。`main` でプロンプトを直接編集しないでください。
PromptHubは、Gitブランチを手動で管理せずにコメントスレッド、承認チェックボックス、ロールベースアクセスを必要とするチームに構造化されたレビューワークフローを提供します。
アクセス制御と所有権
3つのロールモデルがほとんどのチームをカバーします：コントリビューター（追加可）、オーナー/レビュアー（変更可）、承認者（本番にデプロイ可）。 これらのロールを統合することが共有ライブラリでのプロンプト回帰の主な原因です。
Gitでの実装：マージ前に1つのレビュー承認を必要とする `main` のブランチ保護ルールを設定します。各プロンプトフォルダを特定のレビュアーにマッピングするCODEOWNERSファイルを割り当てます。
すべてのプロンプトに指定されたオーナーが必要です。オーナーはプロンプトを最新の状態に保ち、問題をトリアージし、廃止するタイミングを決定する責任があります。
💡 所有権の移転
プロンプト所有権の再割り当てをチームのオフボーディングチェックリストに追加してください。オーナーのいない孤立したプロンプトはサイレントに劣化します——下流のシステムが失敗するまで誰も気づきません。
レビューと廃止ワークフロー
四半期ごとにプロンプトライブラリのレビューを実行します：使用メトリクスを確認し、現在のバージョンが品質標準を満たしているかを評価し、廃止の準備ができているプロンプトを特定します。 90日間誰も使用しないプロンプトはアセットではなくメンテナンスの負担です。
プロンプトを廃止する基準：過去90日間使用されていない、より良いバージョンが置き換えた、書かれてテストされたモデルが本番環境で使用されなくなった。これらのうち2つが当てはまれば廃止します。
廃止プロセス：(1) プロンプトのフロントマターに `status: deprecated` を追加、(2) ファイルを `/prompts/deprecated/` に移動、(3) 代替プロンプトが存在する場合はそれへのメモを追加、(4) 少なくとも1年間保持。ロールバックリクエストがなければ1年後に削除。
プロンプトライブラリ管理のよくある間違い
❌ テーマ整理なしのフラットなフォルダ構造
Why it hurts: 20以上のプロンプトがあると、ファイルが検索不可能になり、チームメンバーは既存のプロンプトを見つけられないため作業を重複する
Fix: テーマ別にプロンプトを整理する：/prompts/テーマ/スラッグ-vN.txt。テーマフォルダごとに最大20プロンプト。
❌ プロンプトファイルの命名規則なし
Why it hurts: "prompt1.txt"、"final.txt"、"final-v2.txt"と名付けられたファイルはプログラム的に発見や比較ができない
Fix: スラッグ-vメジャー.マイナー.txt形式を使用する。例：classify-intent-v2.1.txt。"final"、"copy"、"new"は使用しない。
❌ 廃止プロセスなし
Why it hurts: 古いプロンプトが蓄積し、チームメンバーはそれらが置き換えられていることを知らずに古いバージョンを使用する
Fix: 各フォルダにDEPRECATED.mdを追加し、廃止されたスラッグ、廃止日、置換スラッグのリストを含める。
❌ 本番プロンプトのアクセス制御なし
Why it hurts: チームメンバー誰でもレビューなしに本番プロンプトを変更でき、サイレントな品質回帰を引き起こす
Fix: ブランチ保護ルールを追加：/prompts/production/への変更にはPRレビュー + CI/CDパスが必要。
重要なポイント
- プロンプトライブラリは発見性、重複、品質ベースラインを解決——3人以上がプロンプトを書くか20以上のプロンプトが積極的に使用されている場合に構築する
- フォルダ構造：/prompts/テーマ/スラッグ-vバージョン.拡張子——小文字、ハイフン、ファイル名にバージョン
- Git：本番バージョンにタグを付け、フィーチャーブランチを使用し、mainへのマージ前にPRレビューを必須にする
- PromptHub：コメントスレッドとロールベース承認を持つ構造化されたレビューワークフローに使用する
- 3つのアクセスロール：コントリビューター（追加）、オーナー/レビュアー（変更）、承認者（本番デプロイ）
- 90日間使用されていないプロンプトを廃止；削除前に1年間アーカイブして保持する
よくある質問
プロンプトライブラリとは何ですか？
プロンプトライブラリとは、チームがプロンプトを保存、検索、再利用する共有のバージョン管理されたリポジトリです。フォルダ構造、命名規則、アクセス制御ルール、レビュープロセスが含まれます。
3人チームの最小限の構造とは？
GitリポジトリのPromptディレクトリ、テーマ別フォルダ（最大5テーマ）、命名規則、フォルダごとのREADME.mdが必要です。設定に30分未満かかります。
Gitベースのライブラリで検索するには？
grep -r "キーワード" /prompts/ を使用してコンテンツ検索を行います。各ファイルにYAMLフロントマターを追加してください。大きなライブラリにはPromptHubの検索を使用します。
PromptHubとGitのどちらを使うべきですか？
チームが主に開発者でGitHub PRでレビューしたい場合はGitを使用します。非開発者が含まれる場合やUI上での発見が必要な場合はPromptHubを使用します。