om-ux-shape

有用な機能を形にする

曖昧さを画面に落とし込む前に、明確なプロダクト上の判断に変えます。 ユーザー価値、ビジネス価値、インタラクションの品質、AI の振る舞い、提供上の制約、根拠を、ひとつの軽量なプロセスで結び付けます。

入力 — 機能のアイデア、既存のコンセプトやプロダクト領域、または実装の詳細化が必要な、すでに決定された方針です。 出力 — references/report-templates.md にある形式で記入したレポートをひとつ作成します。

モードを選択する

• Shape — 曖昧な機会、リクエスト、機能のアイデアに使います。デフォルトのモードです。
• Review — 既存のコンセプト、フロー、デザイン、プロトタイプ、プロダクト領域を対象とします（om-ux-review-pr から引き継いだモジュール全体も含みます）。
• Handoff — 方針は決定済みで、実装可能な振る舞いの詳細が不足している場合に使います。

依頼が実際に複数のモードにまたがる場合に限り、モードを組み合わせます。小さなタスクにプロセス全体を課してはいけません。

結果を読む人

出力の具体性を決めるため、執筆前に読み手を明確にします。不明な場合は尋ね、それ以外は最も背景知識の少ない読み手を想定します。つまり、これを実装または作図するものの、デザインシステムを知らず、会話にも参加していない人です。その人に向けて書きます。シニアデザイナーなら具体的な回答をざっと読むことができますが、抽象的な回答から実装できる人はいません。

必読資料

これらは任意の参考資料ではありません。該当する条件が満たされたら、そのステップを終える前に必ず参照資料を読み込みます。読み飛ばすと、このスキルが防ぐべき失敗、つまり妥当に聞こえても何も決めていない回答につながります。

条件	読み込む資料
Shape または Review モード	references/decision-framework.md
AI の導入が提案、示唆、またはすでに実施されている	references/ai-interaction.md。次に、ゲートを通過した内容について references/hai-guidelines.md と references/reward-and-mental-models.md
成果や検証指標を定義する	references/human-value-metrics.md
結果を書く前	references/report-templates.md
結果を提出する前	references/quality-rubric.md

references/foundations.md にはこのプロセスの背景にある根拠が記載されています。プロセスを調整する場合、またはこのスキルを発展させる場合に限り読みます。

運用原則

1. 要求されたインターフェースではなく、重大な影響をもたらす問題から始めます。
2. 根拠に裏付けられるまでは、要件を主張として扱います。
3. 事実、推論、仮定、未解決の問いを明示します。調査結果、ユーザーの発言、指標、制約を捏造してはいけません。
4. ユーザーの成果をビジネス上の効果に結び付けます。ただし、ビジネス価値をユーザー価値の代わりにしてはいけません。
5. 機能を寄せ集めるよりも、最小限で一貫性のあるエンドツーエンドの解決策を優先します。
6. 方針を推奨します。順位のない選択肢の一覧に隠れてはいけません。
7. すべての UI 要素には、アクション、判断、ステータス、説明、または復旧を可能にする役割を持たせます。
8. AI を、不確実性、レイテンシ、コスト、障害モードを伴うデザイン素材として扱い、デフォルトのインターフェースにしてはいけません。
9. 特に重大な操作や取り消しにくい操作では、人が意味のある制御を保てるようにします。
10. 判断のリスクに応じて、プロセスと出力の深さを調整します。

ワークフロー

必ず最初に確認： .ai/skills/om-ux-shape/SKILL.md が存在する場合は適用します。ただし、安全規則を優先します。

0. エージェントのセットアップ — references/agentic-setup.md に従います。リポジトリローカルのオーバーライド契約、存在する場合は制約としてのデザイン契約、信頼できないコンテンツの境界を確認します。共通のコミュニケーション規則と報告規則は references/rules.md に記載されています。

1. 判断内容を明確にする。 下す判断、主要な実行者と状況、意図するユーザー成果とビジネス成果、モードと深さを示します。方針を大きく変えうる回答が必要な質問だけをします。それ以外は、仮定であることを明示して進めます。

2. 根拠台帳を作成する。 references/decision-framework.md（§2）に従い、判明していること、推論、仮定、未知の事項を分けます。未知の事項は、好奇心ではなく判断リスクの高さで優先順位を付けます。

3. 診断する。 進捗を妨げている主な障害を一文で示し、根本にある仕事と要求されている機能を区別します。次に、主要な行動成果、それによって期待される事業上の効果、そして有害な最適化を防ぐためのガードレールを定義します。フレーミングと成果の規律については references/decision-framework.md（§1、§3）を、利用者にとってより良い結果を意味するシグナルの選択については references/human-value-metrics.md を参照してください。

4. 提案する仕組みを検証する。 AI が関与する場合は、references/ai-interaction.md の必要性ゲートを実施し、ルールベースの代替案も明示的に検討します。ゲートを通過した設計は、続いて references/hai-guidelines.md に照らして確認し、どの間違いを許容するかの判断と初回接触時のフレーミングを references/reward-and-mental-models.md に照らして確認します。どの機能についても、references/decision-framework.md（§4）に従って、価値、ユーザビリティ、実現可能性、事業性の4つのプロダクトリスクを評価し、AI の場合は信頼、安全性、プライバシー、モデル品質のリスクも加えます。

5. 方向性を選ぶ。 実質的に異なる仕組みを2〜3案作成し、references/decision-framework.md（§5）に従って比較したうえで、決定的なトレードオフを説明して1案を選びます。議論の要となる主張には、references/evidence-tiers.md に基づき、誠実なエビデンス階層のタグを付けます。レビューでは、修正の容易さではなく、影響度 × 発生頻度 × 対象範囲で所見を順位付けします。

6. 一貫性のある最小の機能を形にする。 主要な仕事とその基本的な利用フローを一つに絞り、信頼のために必要な最小限の状態と復旧経路を定め、今実施すること、後で実施すること、実施しないことを明確に分けます（references/decision-framework.md §6）。一部だけで動作が不完全なスライスは MVP ではありません。一貫性のある最小の機能は、実際の仕事を最初から最後まで完了し、起こりそうな障害にも対応します。

7. 具体的にインタラクションの仕様を定める。 入口とトリガー、必要な情報、システムの応答、主要な判断と操作、該当する空、読み込み中、一部完了、成功、エラー、権限の各状態、編集、取り消し、閉じる、再試行、代替手段への切り替え、エスカレーションの各経路に加え、アクセシビリティとコンテンツの要件を指定します。AI については、機能の位置付け、不確実性、説明、データの利用、フィードバック、制御、モデルが役に立てない場合の動作も指定します。

   具体的にするとは、画面とコンポーネント（契約レジストリがある場合はそのレジストリにあるもの）を明記し、実際に表示するラベル、見出し、空状態の文、エラーメッセージを書くことです。「役立つ空状態を追加する」では作業は未完了です。完成版では、画面に何が表示されるかを、利用者が実際に読む言葉で示します。出力をもとに読み手が画面を構築または描画できないなら、このステップは完了していません。

8. リスクを下げて成果物を届ける。 未検証の前提のうち最もリスクが高いものを示し、判断を変え得る最小限のテストを選び、それぞれの結果で何を実施するかを明記します（references/decision-framework.md §7）。次に、該当する形式を references/report-templates.md で埋め、提出前に references/quality-rubric.md を適用します。診断、ユーザー成果、一貫性のあるスコープ、AI の必要性、または AI の制御と復旧のいずれかがゼロなら、結果はまだ提出できる状態ではありません。重要なエビデンス上の限界を開示し、調査またはテストで確認した動作と、提案および前提を区別します。通常のフレームワーク確認は内部にとどめ、実装に必要な具体的な状態と復旧経路は残します。

回答の方針

• 推奨事項または結論を最初に示します。
• 平易な言葉で、製品の具体的な動作を説明します。判断を支えるプロセスの説明は、判断そのものより短くします。
• リスクが低い作業では詳細を抑え、影響が大きい作業、新規性の高い作業、実装に直結する作業では詳細を増やします。
• 確かな推奨を裏付ける証拠が不足している場合は、暫定的な点を明示し、学びを得るための最小限のステップを提案します。
• ユーザーが機能の構築を依頼した場合は、このワークフローで判断してから実装に進みます。Handoff の形式は、コレクション内の実装スキルに渡すことを想定しており、om-ux-review-pr が完成した PR の確認を行います。