negative-contrastive-framing

否定的対比による枠組み化

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Negative Contrastive Framing Progress:
- [ ] Step 1: Define positive concept
- [ ] Step 2: Identify negative examples
- [ ] Step 3: Analyze contrasts
- [ ] Step 4: Validate quality
- [ ] Step 5: Deliver framework

ステップ 1：肯定的な概念を定義する

まず肯定的な定義を作成し、曖昧さや不明瞭さの理由（解釈が複数ある、境界事例が不明確など）を特定し、目的（教育、意思決定、品質管理）を明確にします。典型的な用途については、一般的なパターンを参照してください。

ステップ 2：否定的な例を特定する

明確なアンチパターンがある単純なケースでは、resources/template.mdを使って、反目標、惜しい例、失敗パターンを構成します。境界が微妙な複雑なケースでは、対比マトリックスや境界マッピングなどの手法について、resources/methodology.mdを確認します。

ステップ 3：対比を分析する

次の内容を含むnegative-contrastive-framing.mdを作成します：肯定的な定義、3～5個の反目標、説明付きの5～10個の惜しい例、よくある失敗パターン、明確な判断基準（「合格する条件…」／「不合格となる条件…」）、境界事例。対比によって、基準の背後にある 理由 が明らかになるようにします。

ステップ 4：品質を検証する

resources/evaluators/rubric_negative_contrastive_framing.jsonを使って自己評価します。否定的な例が境界の範囲全体を網羅していること、惜しい例が実際に判断の難しい例であること、対比によって肯定的な定義だけの場合より基準が明確になっていること、失敗パターンが実行可能な防止策になっていることを確認します。最低基準：平均スコア ≥ 3.5。

ステップ 5：枠組みを提示する

否定的な例によって明確になった肯定的な定義、特に示唆に富む惜しい例、チェックリストとして具体化した判断基準、予防のために特定したよくある間違いを含む、完成した枠組みを提示します。

一般的なパターン

分野別

エンジニアリング（コード品質）：

• 肯定例：「保守しやすいコード」
• 否定例：何でも詰め込んだ巨大なオブジェクト、密結合、不明瞭な名前、マジックナンバー、例外の握りつぶし
• 惜しい例：コメントは充実しているがスパゲッティコード（構造がなく、ドキュメントだけがある）

デザイン（UX）：

• 肯定例：「直感的なインターフェース」
• 否定例：隠れた操作、一貫性のないパターン、難解なエラーメッセージ
• 惜しい例：美しいが使いにくい（機能より見た目を優先）

コミュニケーション（明快な文章）：

• 肯定例：「明快なドキュメント」
• 否定例：専門用語が多い、背景知識がある前提、例がない、受動態
• 惜しい例：技術的には正確だが、対象読者には理解できない

戦略（市場での位置付け）：

• 肯定例：「プレミアムブランド」
• 否定例：差別化がないのに高価格、実質が伴わない高級感の演出
• 惜しい例：価格は高いが、それに見合うサービス品質がない

用途別

教育：

• 学生がよく犯す間違いを示す
• 誤解が表れる惜しい解答を提示する
• 「正しそうに見えるが間違っている」パターンを特定する

判断基準：

• 不合格条件（自動的に却下する基準）を定義する
• 合格しそうな境界事例を示す
• 曖昧な中間領域を明確にする

品質管理：

• 避けるべきアンチパターンを特定する
• 検査をすり抜ける可能性のある微妙な欠陥を示す
• 明確な合否の境界を定義する

ガードレール

惜しい例の選定：

• 惜しい例は、肯定例に実際に近いものでなければなりません
• 全体的に悪いのではなく、失敗している特定の側面を明らかにする必要があります
• 些細な失敗は避け、微妙な違いに焦点を当てます

対比の質：

• 否定的な例がそれぞれなぜ失敗するのかを説明します
• どの側面が基準に反しているのかを示します
• 単なるリストではなく、学びにつながる対比にします

網羅性：

• 主要な側面にわたる失敗モードを網羅します
• 都合のよい例だけを選ばず、分類が難しいケースも含めます
• 明確な合格から明確な不合格までの幅を示します

実行可能性：

• 得られた知見を判断ルールに落とし込みます
• 失敗を防ぐためのガードやチェックを用意します
• 基準を実際に検証できる形にします

避けること：

• ストローマン的な否定例（非現実的に悪い例）
• 説明のない否定例（何が、なぜ問題なのかを示す）
• 「判断の難しい」領域の欠落（すべての例が明確に合格または不合格）

クイックリファレンス

リソース：

• resources/template.md - アンチゴール、ニアミス、失敗パターンのための構造化フォーマット
• resources/methodology.md - 高度な手法（対比マトリックス、境界マッピング、失敗の分類体系）
• resources/evaluators/rubric_negative_contrastive_framing.json - 品質基準

出力： ポジティブな定義、アンチゴール、分析付きのニアミス、失敗パターン、判断基準を含む negative-contrastive-framing.md

成功基準：

• ネガティブな例が境界領域を網羅している（極端な例だけではない）
• ニアミスが示唆に富む際どい例になっている
• 対比によって曖昧な基準が明確になっている
• 失敗パターンが具体的な防止策になっている
• 判断基準が実際に適用できる形になっている
• ルーブリックのスコアが 3.5 以上

クイック判断：

• 明確なアンチパターンがあるか？ → テンプレートのみを使用
• 境界が微妙か？ → 対比マトリックスの手法を使用
• 適用方法を教えるのか？ → 誤解を明らかにするニアミスを重視
• 品質管理が目的か？ → 失敗パターンの分類体系に注力

よくある間違い：

1. 極端なネガティブ例だけを示す（示唆に富むニアミスがない）
2. 分析なしのリストにする（例がなぜ失敗するのか説明しない）
3. 簡単な事例だけを選ぶ（難しい境界判断を避ける）
4. わざとらしいネガティブ例を使う（非現実的に悪い）
5. 実際に適用できる形にしない（対比しても基準が曖昧なまま）

重要な洞察： ネガティブな例は、ポジティブな例にほとんど近いときに最も価値があります。際どい例は、ポジティブな定義だけでは見えない微妙な基準を明確にする必要性を生み出します。