社内で使われているプロンプトが、誰かの個人フォルダやチャットの履歴に散らばっている——そういう状態は珍しくない。Domenico Tenace 氏が公開した「Spellbook of Prompt」は、そうした状態から脱するための設計思想を示す実例として参照する価値がある。
なぜプロンプト管理が技術的な問題になるのか
プロンプト（AI モデルに与える指示テキスト）は、コードと同様にバージョン管理と構造化が必要な「成果物」として扱うべきものになりつつある。しかし現実には、個人が試行錯誤した結果をそのまま共有したり、ドキュメントの片隅に貼り付けたりするケースが多い。
今回の Spellbook of Prompt の再設計は、まさにその問題への回答だ。前身の Daily Prompt と呼ばれていた旧プロジェクトは「プロンプトの置き場所」に過ぎなかった。カテゴリに一貫したロジックがなく、フラット（階層を持たない一覧形式）なリストに雑然と並んでいた。作者自身が「恥ずかしくて共有できない状態」と表現するほどだった。
設計の転換点：ユースケース軸の整理
再設計で最も重要な変更はカテゴリ構造だ。旧バージョンはプロンプトの「形式」で分類していたが、新バージョンは「使用場面（ユースケース）」で整理している。具体的には以下の 7 カテゴリに分類された。
- コンテンツ制作（スクリプト、記事、ニュースレター）
- コード生成・デバッグ（ボイラープレート、レビュー、リファクタリング）
- データ分析・レポート（要約、構造化出力、比較）
- ライティング・コピーライティング（トーン調整、説得的な文体、編集）
- デザイン・クリエイティブディレクション（ブリーフ、フィードバック）
- 学習・教育（説明、クイズ、学習ガイド）
- その他（上記に収まらない汎用テンプレート）
業務システム開発の観点では、このユースケース軸での分類は既存ドキュメント整備の考え方と一致する。たとえばコードレビュー用のプロンプトとリリースノート作成用のプロンプトを同列に並べると、利用者はどちらを探せばよいか迷う。目的別に分けることで検索性と再利用率が上がる。
「特定モデルに依存しない」設計の意味
もう一つ注目すべき設計方針が、モデル非依存（model-agnostic）の原則だ。Spellbook of Prompt では、各プロンプトを ChatGPT・Claude・Gemini の少なくとも 2 モデルで検証してからマージ（コードレポジトリに統合する操作）するルールを設けている。
この原則は業務システムに置き換えると分かりやすい。利用している AI ベンダーが切り替わった場合でも、プロンプト資産をそのまま持ち越せるかどうかを事前に確認しておく、という運用に相当する。特定モデルの挙動に強く依存したプロンプトを大量に抱えていると、ベンダーの仕様変更や価格改定の際に移行コストが跳ね上がる。
ドキュメント基盤の選択：Astro と Starlight
プロジェクトのドキュメント基盤には Astro（静的サイトジェネレーター）と Starlight（Astro 製のドキュメント特化テーマ）が採用されている。MDX（Markdown に JSX コンポーネントを埋め込める拡張形式）を使っているため、将来的にインタラクティブなサンプルを追加する際にもツール変更が不要になる。
プロンプト集のような「頻繁に更新されるテキスト資産」を管理する基盤としては、CMS（コンテンツ管理システム）よりも Git ベースの静的サイトが運用しやすい場面がある。変更履歴が自動で残り、PR（プルリクエスト）ベースのレビューフローをそのまま適用できるからだ。
既存プロンプト資産を整理するための手順
今回の事例から、散在するプロンプトを整理する際の考え方を整理すると次のようになる。まず既存プロンプトをすべて洗い出し、「どの業務場面で使うか」でグループを作る。次にグループごとにテンプレートの入力例・出力例を揃え、モデルをまたいで動作確認する。最後に Git リポジトリに格納して、変更は PR 経由にするルールを設ける。
この流れは、レガシーコードのリファクタリングと構造上ほぼ同じだ。「動いているから触らない」ではなく、再利用性と保守性を高める設計に置き直すという発想が共通している。
プロンプトをコードと同等の管理対象として扱い始めると、チーム内での属人化を減らし、モデル乗り換えコストを下げる土台ができる。Spellbook of Prompt は MIT ライセンスのオープンソースとして公開されているため、構造そのものを社内プロンプト管理の参照実装として利用することも現実的な選択肢になる。