SPECS フレームワークとは
SPECS フレームワークは、すべてのプロンプトを気軽なチャットメッセージではなく小さな要件定義書のように扱う、仕様重視のプロンプトパターンです。 正確性・構造・再現性が自由な創造性よりも重要なタスク向けに設計されています。SPECS は指示から曖昧さを取り除くため、GPT-5.5、Claude Opus 4.8、Gemini 3.1 Pro、そしてローカルモデルなどのモデルと相性が良いです。
SPECS は、異なる担当者やシステムが同じプロンプトを実行して一貫した結果を得る必要がある場合に特に役立ちます。プロンプトを明確な仕様に変えることで、問題のデバッグ、モデル挙動の比較、ワークフロー全体での基準の徹底が容易になります。
SPECS の 5 つの構成要素
優れた SPECS プロンプトは 5 つの構成要素すべてを定義し、モデルが何を、なぜ、どのように回答を整形すべきかを正確に把握できるようにします。 各構成要素は指示の異なる部分に焦点を当てます。
一般的な定義は次のとおりです。
- Scope（範囲）：タスクが何をカバーし、何を明示的にカバーしないか。
- Purpose（目的）：出力が支援すべき根本的な目標や意思決定。
- Examples（例）：モデルを方向付けるための 1 つ以上のサンプル入力と出力。
- Constraints（制約）：長さ制限、フォーマット、禁止する挙動などの厳格なルール。
- Steps（手順）：モデルが出力に至るために従うべき内部的な順序。
SPECS フレームワークが役立つ理由
SPECS フレームワークは、読みやすい文章だけでなく機械で利用できる結果が必要な、分析・運用・統合系のタスクに役立ちます。 隠れた前提を減らし、プロンプトのあらゆる部分を明示化するため、本番ワークフローに不可欠です。
よくあるメリットは次のとおりです。
- 仕様の個々の構成要素を調整・テストできるため、デバッグが容易になります。
- 制約と例のおかげで、モデルや実行をまたいで出力がより安定します。
- 構造が事前に分かっているため、後続処理との相性が良くなります。
例：悪い SPECS プロンプト vs 良い SPECS プロンプト
同じタスクを両方の書き方で見ると、構造のないリクエストと SPECS ベースのリクエストの違いが一目瞭然になります。 ここでは、テキストから情報を抽出する例を示します。
悪いプロンプト
「この顧客メールを読んで、要点を要約してください。」
良いプロンプト
"Scope：単一の顧客サポートメールを分析し、サポートチームに関連する重要情報を抽出します。マーケティングや営業の機会は無視します。Purpose：チケットシステムに記録でき、エージェントがより速く返信するために使える構造化された要約を作成します。Examples：入力：'今日パスワードを2回リセットしようとしましたが、リンクが両方とも期限切れになりました…' 出力：{"issue_type": "password_reset", "urgency": "medium", "summary": "ユーザーがリセットを完了する前にパスワードリセットのリンクが期限切れになる"} Constraints：出力は `issue_type`、`urgency`、`summary` のキーを持つ有効な JSON でなければなりません。追加のフィールドは加えないでください。`urgency` は low、medium、high のいずれかでなければなりません。Steps：1) 主要な問題を特定する、2) 影響と不満の度合いに基づいて緊急度を推測する、3) 25 語未満の簡潔な要約を書く。"
SPECS 版では、モデルが何を出力すべきか、どのように考えるべきか、そして結果がどのように使われるかが正確に定義されています。
SPECS フレームワークを使うタイミング
主な目標が探索的なブレインストーミングではなく、構造化された信頼性の高い出力である場合は、SPECS フレームワークを使うべきです。 これには次のようなものが多く含まれます。
- メール、チャット、ドキュメントから固定スキーマへのデータ抽出。
- 厳格なルールに基づくコード変換、ドキュメント生成、リファクタリング。
- 見出し、指標、フォーマットが事前定義されたレポート生成。
- AI の出力が別のシステムやスクリプトに直接送り込まれるあらゆるワークフロー。
PromptQuorum が SPECS フレームワークをどう実装しているか
PromptQuorum はマルチモデルの AI ディスパッチツールで、SPECS フレームワークを組み込みのプロンプト構造の 1 つとして提供し、ユーザーがゼロから作らなくても仕様形式のプロンプトを設計できるようにします。 PromptQuorum で SPECS を選ぶと、アプリは Scope、Purpose、Examples、Constraints、Steps 専用のフィールドを表示し、それらを 1 つの構造化された指示にまとめます。
PromptQuorum 内では、SPECS フレームワークによって次のことができます。
- 各構成要素を別々のフィールドに記録し、仕様を読みやすく編集しやすい状態に保ちます。
- 同じ SPECS ベースのプロンプトを複数のモデルに並行して適用し、各ベンダーが厳格なフォーマットをどう扱うかを簡単に比較できます。
- チケット要約、レポート生成、コードレビューなどの繰り返し行うワークフロー向けに SPECS テンプレートを保存・共有できます。
SPECS を他のフレームワークと組み合わせて使う
SPECS フレームワークは構造化された出力の土台として位置づけ、補完的なタスクには他のフレームワークと組み合わせるべきです。 実用的なパターンは次のとおりです。
- 予測可能な構造を生み出す必要があるもの、またはツールに送り込む必要があるものすべてに SPECS を使います。
- マーケティングやコピーライティングには CRAFT のような創造的なフレームワークを使います。
- 途中の推論を可視化したい場合は、Analyze–Plan–Execute（APE）のような推論志向のフレームワークを使います。
- 完全な仕様を書くほどではない手軽なタスクには、単一ステップの汎用フレームワークを使います。
SPECS フレームワークの使い方
- 1Setting（設定）：環境、システム、ドメインに関するコンテキストを提供します。 例：'あなたはヘルスケア企業のデータアナリストです。患者のプライバシーが最重要です。すべてのクエリは HIPAA に準拠しなければなりません。'
- 2Problem statement（問題定義）：解決しようとしている具体的な問題を述べます。 例：'直近 90 日間で服薬アドヒアランスが低い患者コホートを特定してください。'
- 3Examples（例）：良い出力の具体例を 2〜3 個提供します。 分析の場合は、サンプルの出力テーブルや所見を示します。コード生成の場合は、あなたのスタイルに合った動作するコードを示します。
- 4Constraints（制約）：厳格なルールと好みを列挙します。 例：'SQL のみを使用（Python は不可）。クエリは 5 秒未満で実行される必要があります。出力は匿名化される必要があります（患者名なし）。'
- 5Style（スタイル）：好みのトーン、言語、フォーマットを指定します。 例：'技術的な読者。正確な用語を使用。markdown レポートとして返してください。'