重要なポイント
- ワークフローの各プロンプトに同じ3つ以上のコンポーネントを追加するときはカスタムフレームワークを構築する
- 3〜6個のコンポーネントを使用：少ないとテクニック、多いと摩擦が生じる
- 文書化前に10の実際のプロンプトでテストする
- GPT-5.5とClaude 4.6 Sonnetでモデル横断的な信頼性を確認する
- テンプレートと3つの注釈付き例とともにフレームワーク仕様書をバージョン管理に保存する
フレームワーク vs テクニック：何が違うのか？
📍 In One Sentence
プロンプトフレームワークは各プロンプトに必要なコンポーネントを定義する構造テンプレートであり、テクニックはそのコンポーネントの一つの中で適用されるパターンです。
💬 In Plain Terms
フレームワークは各プロンプトの骨組みで、セクションを決めます。テクニックはあるセクションの中で行うことで、例えばモデルに段階的に考えさせることです。
プロンプトフレームワークは各プロンプトに必要なコンポーネントを定義する構造テンプレートであり、テクニックはそのコンポーネントの一つの中で適用されるパターンです。 チェーン・オブ・ソートプロンプティングはテクニック—フレームワークの「タスク」コンポーネント内で適用します。CO-STARはフレームワーク—プロンプト全体を構造化する6つのコンポーネントを定義します。
この区別は重要です。フレームワークとテクニックは異なる問題を解決するからです。フレームワークは一貫性を解決します：チーム全員が同じ構造のプロンプトを作成できます。テクニックは能力を解決します：モデルが特定のステップをどのように処理するかを変えます。
タスクタイプが既存フレームワークの設計目的に合致する場合は既存フレームワーク（CO-STAR、CRAFT、RISEN、RTF）を使用します。既存フレームワークにないドメイン固有コンポーネントを常に追加している場合はカスタムを構築します。
📌 核心的な区別
フレームワークはチーム全体の一貫性を解決します。テクニックは個別プロンプトステップの能力を解決します。両方が必要で、一方が他方に取って代わることはありません。
カスタムプロンプトフレームワークが必要なとき
特定のワークフローで毎回同じ3つ以上の変更を加えるときにカスタムフレームワークを構築します。 コンプライアンスアンカー、引用要件、専門用語集を常に追加している場合、それらはコンポーネントであり、アドホックな追加ではありません。
カスタムフレームワークが必要なサイン：
- 標準フレームワークに含まれない同じフィールドを毎回のプロンプトに追加している
- CO-STARやCRAFTを使っているのにチームがバラバラなプロンプトを作成している
- 新しいチームメンバーが許容できるプロンプトを書くのに1週間以上かかる
- 同じコンテキストを繰り返し説明するためプロンプトが平均600語を超える
- 全員がコピーして手動で修正する「ベースプロンプト」を作成してしまった
5ステップでカスタムプロンプトフレームワークを構築する
5ステッププロセス：目標定義 → コンポーネント特定 → 10プロンプトでテスト → 改良 → 文書化。 各ステップには明確な完了基準があります。ステップ5に飛ばないこと—テストされていないフレームワークの文書化は誤った信頼を生み出します。
- 1目標を1文で定義する
Why it matters: このフレームワークが確実に生成すべき出力を正確に書き出します。この1文がすべてのコンポーネント決定を支配します。 - 2必要なコンポーネント3〜6個を特定する
Why it matters: このワークフローの各プロンプトが必要とする入力要素を列挙します。まず5つのプロンプトを記憶から書き、共通点を抽出します。 - 310の実際のプロンプトに適用する
Why it matters: ワークフローからの実際のプロンプトを使用します（作り話は不可）。各出力を評価します。PromptQuorum経由でGPT-5.5とClaude 4.6 Sonnetでテストし、モデル横断的な信頼性を確認します。 - 4コンポーネントリストを改良する
Why it matters: 10プロンプト中7個未満に現れたコンポーネントを削除します。5回以上即興で追加したコンポーネントを追加します。改訂版フレームワークで10プロンプトテストを再実施します。 - 5文書化と標準化
Why it matters: 1ページの仕様書を作成：フレームワーク名、各コンポーネントの定義、プレースホルダー付き記入テンプレート、3つの注釈付き例題プロンプト。GitまたはPromptHubにバージョン管理で保存します。
⚠️ ステップ3をスキップしないこと
10の実際のプロンプトでテストせずにフレームワークを構築すると、時間のプレッシャーの下でスキップされるコンポーネントがほぼ必ず含まれます。まずテスト、その後文書化。
例：サポートチーム向けフレームワーク構築
あるサポートチームのカスタムフレームワーク — REPAIRと命名 — は5つのコンポーネントで構成されます：Role、Escalation condition、Policy anchor、Action path、Intent confirmation。 CO-STARやCRAFTなどの標準フレームワークには、すべてのサポートプロンプトが必要とするエスカレーションロジックやポリシーアンカリングが含まれていません。
REPAIR template:
- R (Role): "You are a tier-1 support agent for Product. Your authority covers scope."
- E (Escalation): "If the issue involves condition, escalate to tier-2. Do not attempt resolution."
- P (Policy anchor): "Apply policy ID for issue type. Quote the relevant clause in your response."
- A (Action path): "Classify the issue, confirm understanding, propose resolution, request confirmation."
- I (Intent confirmation): "End every response with: 'Does this address your issue, or would you like me to escalate?'"
REPAIRフレームワークをドキュメント化してチームのプロンプトライブラリに追加した後、新しいエージェントのオンボーディング時間は2週間から3日に短縮されました。プロンプト整合性スコア（Braintrust評価で測定）は最初の月以内に64%から89%に改善しました。
💡 効果を測定する
カスタムフレームワークを導入する前後でオンボーディング時間と整合性スコアを追跡します。4週間以内に改善が見られない場合、フレームワークは文書化ではなく改良が必要です。
独自フレームワーク構築時のよくある間違い
最も一般的な間違いは、20以上の実際のプロンプトを手動でテストする前にフレームワークを構築することです。 理論から構築されたフレームワークには、重要そうに見えても実際にはスキップされるコンポーネントが含まれます。
❌ コンポーネントが多すぎる（7個以上）
Why it hurts: 時間のプレッシャーの下でライターがセクションをスキップし、一貫性が損なわれます。
Fix: 6コンポーネントに制限します。ドメイン固有フィールドはコアフレームワークではなく拡張に移します。
❌ 標準フレームワークをコピーしてリネームする
Why it hurts: リネームされたCO-STARはカスタムフレームワークではありません。
Fix: 標準フレームワークに存在しないコンポーネントが少なくとも2つある場合にのみフレームワークを正式化します。
❌ 文書化前のテストセットなし
Why it hurts: 実際のプロンプトに耐えられないフレームワークを文書化してしまいます。
Fix: 仕様書を書く前に10の実際のプロンプトをドラフトフレームワークで実行します。
よくある質問
プロンプトフレームワークとは何ですか？
プロンプトフレームワークとは、プロンプトにどのコンポーネントをどの順序で含めるかを定義する構造化テンプレートです。一貫性を高め、プロンプト作成時間を短縮します。
カスタムフレームワークを構築すべきタイミングは？
ワークフロー内の各プロンプトで標準フレームワークに同じ3つ以上の修正を加える場合にカスタムフレームワークを構築します。
フレームワークのコンポーネント数は？
3〜6個のコンポーネントを使用します。3個未満はテクニック、6個超は摩擦を生みます。
カスタムフレームワークの命名方法は？
REPAIRのようなアクロニムで記憶しやすくします。新しいチームメンバーが名前だけで全コンポーネントを思い出せるかテストします。
カスタムフレームワークのバージョン管理は？
各バージョンを日付付きファイルに保存します。重大な変更はメジャーバージョン、改善はマイナーバージョンとします。
複数のフレームワークを組み合わせられますか？
CO-STAR、CRAFT、RISENのコンポーネントを組み合わせられますが、結果は新しいカスタムフレームワークとして扱い、名前を付け、文書化し、テストします。
関連記事
情報源
よくある質問
プロンプト技法とプロンプトフレームワークの違いは?
技法は単一の指示またはメソッドです（例：「ステップバイステップで考える」）。フレームワークは3+コンポーネントを持つ再利用可能な構造で、プロンプトの構築方法を定義します。フレームワークは繰り返し可能で、技法はアドホックです。
CO-STAR、CRAFT、RISENではなくカスタムフレームワークを構築すべき時は?
ワークフロー内の各プロンプトで既存フレームワークに同じ3+の修正を繰り返し適用する場合に構築します。常にCO-STARにコンプライアンス制約、ドメイン用語、出力スキーマを追加する場合、これらはあなたのフレームワークのコンポーネントになるべきです。
カスタムフレームワークは異なるAIモデル間で機能できるか?
はい、正しく設計されていれば可能です。モデル固有の構文を避けて、普遍的なコンポーネント（タスク、制約、出力形式）の周りに構築します。最終化する前にGPT-5.5とClaudeでテストします。フレームワークがモデルごとに大幅な言い換えを必要とする場合は、簡単にしてください。
カスタムフレームワークは何個のコンポーネントを持つべきか?
3～6個のコンポーネントを使用します。3個未満はテクニックで、フレームワークではありません。6個超は摩擦を生み、ライターはセクションをスキップします。もっと必要な場合は、異なるタスクタイプ用の2つの専門フレームワークに分割します。
カスタムフレームワークが実際に機能しているか確認するには?
ワークフロー内の10個の代表的なプロンプトに適用します。3つの基準に対して出力をスコアリングします：（1）タスク完了、（2）フォーマット準拠、（3）品質一貫性。機能するフレームワークは3つすべてで8/10以上のスコアを取得すべきです。PromptQuorumを使用して複数のモデル間でテストします。
カスタムフレームワークにどう名前を付ける?
REPAIR のようなアクロニムを使用して記憶に残りやすくします。アクロニムテスト：新しいチームメンバーが名前だけですべてのコンポーネントを思い出せるか?そうでない場合は、コンポーネントリストを単純化します。
複数の既存フレームワークのコンポーネントを組み合わせられるか?
CO-STAR、CRAFT、RISENのコンポーネントを組み合わせることはできますが、結果を新しいカスタムフレームワークとして扱い、命名、文書化、テストします。正式化なしで組み合わせると、文書化されていないアドホックパターンが作成されるだけです。
カスタムフレームワークのバージョン管理方法は?
各フレームワークバージョンを日付付きファイル（例：repair-v1-2026-05.md）でPromptライブラリディレクトリに保存します。重大な変更（コンポーネント追加/削除）をメジャーバージョンとしてタグします。改善（定義更新）をマイナーバージョンとしてタグします。各変更の理由をドキュメント化します。
カスタムフレームワークで何を文書化すべきか?
1ページの仕様を作成します：（1）フレームワーク名と目標、（2）例付きの3～6コンポーネント定義、（3）記入テンプレート、（4）フレームワークを使用した3つの注釈付き完全なサンプルプロンプト。バージョン制御でPromptライブラリの横に保管します。
構築したカスタムフレームワークをチームに使用させるには?
実際のタスク例を使用した30分間のウォークスルーから開始します。2～3のプロンプトで一緒にテストします。共有可能な1ページの仕様を作成します。最初の1ヶ月間のコンプライアンスと影響メトリクスを追跡します。フィードバックに基づいて反復します。