mrachny/decision-matrix-skill

意思決定マトリックス

加重意思決定マトリックスは、「決められない」を、説明可能で検証可能な数字に変換します。しかし、その数字は、その背後にある基準、ウェイト、そして調査が優れている場合にのみ意味を持ちます。あなたの役割は、表を埋めることではなく、考えること（何が重要か、どれくらい重要か、各選択肢が実際にどれだけ優れているか）です。最後に作成するHTMLレポートは、その思考を適切に行った結果の副産物であり、目的そのものではありません。

1. この方法が実際に適合するか確認する

この方法は、2〜8個の離散的な選択肢があり、複数の基準が異なる方向に引っ張り合う場合（安い vs 良い、速い vs 安全）に真価を発揮します。以下の場合は、過剰であったり、不適切なツールです：

• 本当に重要な要素が1つしかない場合（「どちらがより安いか」）— その質問に直接答えれば良い。
• Yes/Noの判断であり、代替案の中からの選択ではない場合。
• 選択肢の空間が事実上無制限である場合（例：「どこに住むべきか」で候補地がまだ決まっていない）— まず候補を絞り込み、その絞り込んだリストに対してマトリックスを実行するようユーザーを支援します。

この方法が適合するなら、簡潔にその旨を伝えて先に進みます。ユーザーに意思決定マトリックスを使用することを正当化させる必要はありません。

2. ワンメッセージで情報収集 — 項目ごとに聞かない

「何を決めたいのか？」「選択肢は？」「何が重要か？」そして各基準のウェイトを一つずつ尋ねていくと、2分で終わる意思決定が15メッセージの長丁場になります。決定事項、選択肢、優先順位の大まかな感覚を、まとめて1つのメッセージで尋ね、答えのハードルがどれだけ低いかを示す例を提示します：

「何を決めたいですか？選択肢は？そして何が最も重要ですか？大まかで全く問題ありません。私が明確な比較表にします。例：『3つの求人—Acme、Globex、現在の仕事（Initech）—の間で迷っています。主に給与、成長性、通勤がラクであることを重視します。』」

もし薄い回答（選択肢だけで優先順位なし）が返ってきても問題ありません。ステップ3に進み、再度尋ねる代わりに優先順位を提案します。

3. 編集可能なドラフトを一度に提案 — 基準、定義、ウェイトをまとめて

基準を集めてから別途ウェイトを集めるのではありません。この種の決定（仕事のオファーとアパートでは基準が異なります）に通常何が重要かを調査し、一度に完成したドラフト（5〜10の基準、それぞれに1行の定義と提案ウェイト（1〜10））を渡します。ユーザーはそれを1回のパスで編集できます。白紙のブレインストーミングから構築したり、各基準を順番に尋ねたりする必要はありません。もしユーザー自身のリストが10個を超える場合は、穏やかに（ただし、この一度のドラフト内で。先に許可を求めないでください）重複するものを統合または削除するよう促します。

ユーザーが最も簡単な方法（数値、または「高/中/低」— それぞれ9/6/3に大まかにマッピング）で回答できるようにし、「問題ない」「通勤を削除して、給与を10に上げて」のような軽い返信を受け入れます。送信する内容の例：

「求人を比較するためのドラフトです。任意の行を編集、追加/削除するか、単に『問題ない』とおっしゃってください：

基準	意味	重要度 (1-10)
給与	年収総額（基本給＋賞与＋株式）、初年度	9
成長	この役割でどれだけ学び/成長できるか	8
通勤	一般的な日のドア・ツー・ドアの時間	6
安定性	2年後にその役割/企業が存在する可能性	7
チームと文化	人々と日常の雰囲気の良さ	7

健康保険やリモートワークの柔軟性など、追加したいものはありますか？」

ドラフトが確定した後、人々が予想以上に重要視すべきことが2つあります：

• 各基準の定義を保持し、単なるラベルに縮退させないこと。「成長」は曖昧です。「成長＝この役割で初年度にどれだけ学べるか」ならスコア化できます。定義がないと、選択肢間でスコアが矛盾する可能性があります。
• 同じ根本的なものを二重にカウントする基準に注意する（例：「給与」と「経済的安定性」はしばしば同じ要素に集約される）— 統合することでウェイトの誠実さを保ちます。

4. 確定して次に進む

通常、1回の編集ラウンドで十分です。ユーザーが確認した（または異議を唱えなかった）ら、基準、定義、ウェイトは確定したものとして扱い、すぐにステップ5の調査に進みます。既に示した数値の再確認を再度求めないでください。後で何かを変更する必要がある場合（例：スコア化が不可能な基準が判明した場合）、何をなぜ変更するかを説明し、承認のためにドラフト全体を再度開くことはしません。

5. 各選択肢×基準のセルを調査しスコアリングする (1-10)

このステップが実際の作業であり、エージェントが単なるテンプレートよりも価値を発揮する部分です。各セルについて：

• 実際に調査する — スコアリングの前に、検索/ツールを使用して関連する事実（価格、仕様、評価、給与データ、レビュー、ポリシー）を見つけます。感覚から正確そうな数字をでっち上げないでください。
• 基準内でスケールを一貫して固定する。 最初の選択肢をスコアリングする前に、この基準における1と10の意味を決定します（例：「10＝これらの選択肢の中で最も安い」または「10＝すべての必須条件を満たす」）。そして、そのアンカーをすべての選択肢にわたって保持し、スコアが比較可能になるようにします。そのアンカーを基準ごとに自分のメモに一度書き留めてください。
• セルごとに1文の根拠を記載し、数値の背後にある事実や情報源を明記します。この根拠によりレポートの信頼性が高まり、HTMLレポートの「理由」トグルで表示されます。
• 推測している場合はその旨を明記する。 一部の基準は真に主観的（例：「興奮度」「直感」）であったり、文書化が不十分です。それらはユーザー自身の表明した判断からスコアリングし、根拠の中でそれが主観的/未検証であることを明記し、誤った精度で提示しないでください。情報源を決して捏造しないでください。

6. 加重合計を計算する

各選択肢について：加重スコア = Σ(ウェイト_i × スコア_i) / Σ(ウェイト_i)、正規化された1〜10の平均。これにより、合計が入力と同じ1〜10スケールに保たれ、妥当性の確認が容易になります。

7. 最初にマークダウンテーブルを提示する

HTMLを構築する前に、チャット内で1つのテーブルとして結果を表示します：選択肢を行として良い順にソート、基準を列（読みやすさのためスコアのみ）、そして最後の加重合計列。その後に2〜3文で、最良の選択肢、次点、そしてそれらを分ける最大の要因を述べます。そして、トップ2が十分に接近していて「勝者」が実際には五分五分である場合は、そのことを率直に指摘します。

8. インタラクティブなHTMLレポートを構築する

以下のスキーマに一致するJSONデータファイルを作成し、次に以下を実行します：

python3 scripts/build_report.py data.json report.html

これにより、assets/report_template.htmlのエンジンにデータが注入され、単一の自己完結型report.htmlが書き込まれます（サーバー不要、1つのGoogle Fontを除き外部リソースも不要 — ファイルをダブルクリックするだけで動作します）。このスクリプトはデータを検証し、不足や範囲外の値がある場合は具体的なメッセージとともに失敗します。

データスキーマ

{
  "meta": {
    "title": "どのアパートを借りるべきか？",
    "subtitle": "同じ地域の4つの物件を比較",
    "description": "1〜2文の短く平易なコンテキスト。タイトルの下に表示されます。",
    "direction": "ltr",
    "credit": "Decision matrix by <あなたの名前>",
    "credit_url": "https://github.com/mrachny/decision-matrix-skill"
  },
  "criteria": [
    { "id": "rent", "label": "月額家賃", "description": "10 = 4つの中で最も安い、1 = 最も高い。", "weight": 9 }
  ],
  "options": [
    { "id": "optA", "label": "エルムストリートのアパート", "included": true }
  ],
  "scores": { "optA": { "rent": 7 } },
  "notes": { "optA": { "rent": "₪5,200/月、4つの中で2番目に安い（出典：リスティング）。" } }
}

• meta.direction は "ltr" または "rtl"。省略した場合は "ltr" として扱われます。
• レポートのフッターには、デフォルトで「Generated with a decision matrix」という小さな帰属行が表示されます。meta.credit / credit_url でそのテキスト/リンクを上書きします。ユーザーが帰属行を一切望まない場合は、meta.credit を false に設定します。
• criteria[].description と notes はオプションですが、強く推奨されます。これらはレポートに表示される「理由」テキストになります。説明のない基準やセルは根拠が表示されず、簡単なドラフトには問題ありませんが、レポートの質は低下します。
• options[].included（デフォルトは true）は、レポートの初期ミュート状態を設定します。
• すべてのスコアは1〜10の数値である必要があります。ビルドスクリプトはこれをチェックし、書き込み前にcriteria/options/scores間のIDの一貫性も検証します。

ファイルの場所と、それが任意のブラウザで直接開くことをユーザーに伝えます。ウェイトとミュートのトグルはランキングを動的に再計算し、データがどこかに送信されることはなく、ファイルを保存しない限り何も保存されません。

9. 感度分析を促す

最後に、このレポートは読むだけでなく、実際に操作して遊ぶことを意図していると指摘します：最も曖昧に感じられる基準をオフにしたり、ウェイトを少し変えたりしただけで勝者が変わる場合、それは決定が拮抗しており、さらなる検討が必要である（あるいは、差が重要ではなく、直感/コスト/最も簡単に撤回できる選択肢で決めてよい）という明確なシグナルです。逆に、そのような操作に対してランキングが頑健であれば、それも有用なシグナルです。

参照ファイル

• references/method.md — この方法の背景、一般的なスコアリングの落とし穴（相関する基準、ウェイトの圧縮、アンカリングのずれ）、および同点の場合にユーザーとどのように話し合うかについて。
• assets/report_template.html — レポートエンジン。手動で編集する必要はありません。カスタマイズ可能なものはすべてJSONデータファイルを通じて行われます。
• scripts/build_report.py — レポートを構築します。python3 scripts/build_report.py --help のような使用方法は上記の通りです。
• examples/laptop-purchase.json — 記入済みのデータファイルの例。自分で作成する前に完全なものを見たい場合に参照してください。