clarify

スキル：clarify

デザイン作業に着手する前に、ユーザーのニーズを把握します。

LLM は質問するよりも仮定する傾向があります。情報が不足していても、モデルの大半は質問せずに作業を進めます。このスキルはデザインワークフローの確認役として、デザイン依頼の不明点を分類し、ビジュアル面や構造面の作業を始める前に解消するための、的を絞った質問を作成します。

${CLAUDE_SKILL_DIR}/references/adaptive-questioning.md にある adaptive-questioning.md は共通のリファレンスです。計画パイプラインの確認ゲートからも参照されており、デザインライフサイクルのチェックポイントではモード切り替えに使用されます。

出力は会話です。確認の質問、比較例、言い換えを通じて、ユーザーと一緒に考えを掘り下げます。尋問ではなく、協力して探っていきます。

---

不明点の分類

不明点はすべて同じではありません。種類を分類することで、どのような質問をすべきかが決まります。

問題の種類

意図の問題 — 依頼から本当のデザイン目標を把握できません。

• 曖昧な目標：「見た目を良くして」／「もっとモダンにして」／「もっと目を引くようにして」（どのように？誰に向けて？どのような方向性で？）
• 間接的な意図：「この色が合うか確認してくれる？」（多くの場合、「色のシステムを直してほしい」という意味です）
• 文脈との不整合：デザイン作業の途中で、ユーザーが関係のないビジュアル上の懸念を持ち出す

前提の問題 — 依頼に含まれる前提が誤っているか、解決できません。

• ブランド情報の不足：「ブランドに合わせて」と言われたものの、DESIGN.md、スタイルガイド、参考資料が提供されていない
• 成果物の状態に関する誤認：プロジェクトに DESIGN.md がないのに、「既存のトークンを更新して」と依頼される
• 対応能力の不一致：現在の環境では提供できないビジュアル出力を求められる（例：HTML のみ対応可能なのに「Figma 形式でエクスポートして」と依頼される）

パラメーターの問題 — 必要なデザインの詳細が不足しているか、相互に矛盾しています。

• レジスターの不足：「ランディングページをデザインして」（ブランド向けか、製品向けか？マーケティング用か、SaaS ツール用か？）
• 対象ユーザー／デバイスの不足：「レスポンシブにして」（主なブレークポイントは？モバイルファーストか、デスクトップファーストか？）
• 雰囲気／個性の不足：「すっきりしていてプロフェッショナルに」（ミニマルで冷たい印象か、温かく親しみやすい印象か、エディトリアルで大胆な印象か？）
• 矛盾：「シンプルにしつつ、すべてを表示して」

表現上の問題 — 言葉の曖昧さによって、デザインを一意に解釈できません。

• 語彙の曖昧さ：「UI を整えて」（情報密度を下げる？色をシンプルにする？余白を調整する？それともすべて？）
• 範囲の曖昧さ：「アクセシビリティを高めて」（WCAG AA のコントラストだけか？動きへの配慮か？キーボード操作か？それともすべて？）
• 指示対象の曖昧さ：「あのコンポーネントを更新して」（どのコンポーネント？どのコンテキストで？）

曖昧さの方向性

不明点を特定したら、どの方向に曖昧さがあるかを分類します。これに応じて質問の仕方を決めます。

方向性	手がかり	確認方法
意味上の曖昧さ	デザイン用語に複数の妥当な意味がある	意味を明確にする：「X と Y のどちらを指していますか？」
範囲が広すぎる	意図は明確だが、対象範囲が複数の柱にまたがっている	特定する：「今、最も重視すべき点はどれですか？」
範囲が狭すぎる	想定されるデザイン目標に対して、依頼が不自然なほど具体的	一般化する：「より広い意味では、どのような成果を目指していますか？」

デザインタスクで特に注意する点

デザイン依頼が曖昧になる具体的な要因は、次の3つです。

• 目標の不足：なぜが示されず、何をするかだけが書かれている（目的や対象ユーザーについての説明がないまま「ヒーローセクションを追加して」と依頼されるなど）
• 前提の不足：デザイン上の制約が明示されていない（ブランドカラー、対象デバイス、トーン、アクセシビリティのレベル）
• 用語の曖昧さ：正確な表現が必要な場面で、曖昧なデザイン用語が使われている（「モダン」ではなく「ミニマル＋エディトリアル」、「プロフェッショナル」ではなく「製品の特性に合わせて抑制された表現」など）

デザイン要件の不整合は見落としやすいものです。依頼の各要素が矛盾していないか、明示的に確認してください（例：「大胆で鮮やか」と「落ち着きがあり信頼できる」は、反対の方向性を示しています）。

---

質問の作成

仮説に基づいて考える

「何を尋ねるべきか？」から始めるのではなく、「どのような設計の方向性が考えられるか？」から始めます。そして、最も多くの方向性を絞り込める答えが得られる質問を見つけます。

1. リクエストに対する競合する設計解釈を2～4つ挙げます
2. それらを区別するもの、つまり意見が分かれる軸を特定します
3. その軸について質問します

例：

• リクエスト：「ダッシュボードを再設計する」
• 解釈A：視覚的なノイズを減らす — カードを取り除き、間隔を詰め、落ち着いた配色にする
• 解釈B：ブランドアイデンティティを確立する — アクセント、書体、個性を取り入れる
• 解釈C：使いやすさを高める — 階層を見直し、重要なアクションを目立たせ、認知負荷を減らす
• 軸：これは視覚・ブランドの問題なのか、明瞭さ・使いやすさの問題なのか、それとも情報密度の問題なのか？
• 質問：「現在のダッシュボードについて最も気になる点は何ですか？ブランドらしさが感じられない、読みづらい、それとも情報が多すぎる、のどれでしょうか？」

意見が分かれる軸を狙った1つの質問は、視覚的な細部についての3つの質問よりも効果的です。

情報利得を最大化する

考えられる質問の中から、解釈間の不確実性を最も減らせる質問を選びます。質問Aで仮説が50対50に分かれ、質問Bで90対10に分かれるなら、どちらの答えが返ってきても、より多くの情報が得られるAを尋ねます。

3～5回のやり取りで収束させることを目指します。それ以上続けても、効果は急速に薄れます。

抽象的な質問より具体的に

可能であれば、抽象的に尋ねるのではなく、解釈によってどのような結果になるのかを示します。

• 弱い例：「どのような視覚的なトーンをお望みですか？」
• 強い例：「エディトリアルな方向性をお考えなら、コントラストを強くし、間隔を詰め、表情豊かな書体にするため、配色は暗い中間色が中心になります。一方、親しみやすさを重視するなら、丸みのある形、温かみのある色、ゆったりとした間隔になり、方向性が変わります。どちらが近いですか？」

異なる設計の方向性を示します。抽象的なラベルではなく、具体的に見て分かる説明をもとにユーザーに選んでもらいます。

5つの確認戦略

問題の種類に応じて、適切なアプローチを選びます。

戦略	使用する場面	例
パラメーターを尋ねる	具体的な設計上の詳細が不足している	「主なデバイスはスマートフォンとデスクトップのどちらですか？」
曖昧さを解消する	複数の設計方向が妥当である	「『モダン』とは、ミニマルでフラットな方向ですか、それとも大胆で表現豊かな方向ですか？」
代替案を提示する	ブランド上の制約により、依頼どおりに進められない	「DESIGN.md が見つかりません。まず設計のDNAを確立するか、ワイヤーフレームモードで進めて、後からトークンを追加できます。」
リスクを確認する	取り消しにくい重要な設計上の判断である	「DESIGN.md を確定すると、トークンシステムが確定します。このまま進めますか？それとも先に配色を調整しますか？」
ブロッカーを報告する	設計上の前提条件が実際に欠けている	「ブランドの参考資料がありません。中核となる design モードで設計のDNAを確立できます。まず実行しますか？」

---

質問の質

属性

すべての質問が、次の条件を満たしているか確認します。

属性	確認内容
焦点が明確	1つの不足点だけを扱っている — 複数の質問をまとめていない
回答可能	ユーザーがすでに知っている情報から答えられる
識別力がある	答えによって設計の方向性が意味のある形で絞られる
誘導しない	答えを前提としていない
タスクに関連している	進行中の設計作業を直接前進させる
建設的	ただ情報を集めるだけでなく、確認済みのブリーフにつなげる

回答に必要な労力を考慮する

各質問にユーザーが答えるために必要な労力を見積もります。

労力	例	方針
低	「スマートフォン優先ですか、それともデスクトップ優先ですか？」	気軽に尋ねる — ユーザーはすでに知っている
中	「感情的なトーンは、ブランドと製品のどちらを重視しますか？」	方向性を実質的に変える場合にのみ尋ねる
高	「現在のデザインシステムでは、トークンの命名規則をどのようにしていますか？」	尋ねない — DESIGN.md やコードベースを自分で調べる

原則：意図、目標、ブランドの背景について尋ねます（ユーザーが知っていること）。技術面や構造上の詳細は自分で把握します。

---

会話を進める

意図の状態を追跡する

会話の進行に合わせて、2つの心的な集合を維持します。

• 確認済み（+）：ユーザーが確認した設計の方向性、制約、目標
• 除外済み（−）：ユーザーが却下した、または確認済みの情報と矛盾する方向性

確認済みの項目との整合性と、除外済みの項目との矛盾を基準に、残った設計の方向性を評価します。これにより、会話を重ねるごとに選択肢が自然に絞られていきます。

判断を切り分ける

次の3つの問いを、順番に検討します。

1. 確認すべきか？ — 設計の方向性を左右する重要な曖昧さがありますか？
2. どのように確認すべきか？ — どの問題の種類と戦略が当てはまりますか？
3. どう尋ねるか？ — どのような枠組みで、具体的に何を尋ねますか？

これらをひとまとめにしてはいけません。確認すると決めて、思いついた最初の質問をそのまま口にすると、狙いを定める段階を飛ばしてしまいます。

短絡ルール

• 依頼内容が明確で、競合する設計の方向性がなければ、そのまま進めます。
• 確認しても確認しなくても設計の結果が同じように良くなる場合は、質問しません。判断に迷う場合は、行動を優先します。
• ユーザーが「とにかく進めて」や「うまくやって」と伝えてきたら、黙って進めるのではなく、確認モードに切り替えます — 設計上の前提を伝え、ユーザーが異議を唱えられるようにします。モード切り替えの手順と、例外となる本当に影響の小さいケースについては、適応型の質問を参照してください。

---

アンチパターン

最終確認日：2026-07

パターン	問題点	代わりに行うこと
確認せずに進める	既定の実行バイアス — 誤った設計の方向性を選ぶと、修正に大きなコストがかかります	まず別の工程として検出を行います
実装の詳細について尋ねる	「どの CSS フレームワークを使いますか？」は設計に関する質問ではありません	自分で判断し、ブランド、対象ユーザー、目標について尋ねます
質問を立て続けに並べる	共同作業ではなく、ヒアリングシートのように感じられます	1ターンにつき質問は最大1〜3件にします
DESIGN.md を読めばわかることを尋ねる	ユーザーの時間を無駄にします	先に DESIGN.md を読み、そこに書かれていないことを尋ねます
明確な依頼に対して質問しすぎる	作業が遅れ、信頼を損ないます	依頼内容が明確なら、そのまま進めます
抽象的な質問をする	ユーザーがビジュアルの方向性を検討しにくくなります	違いがわかる設計の方向性を示します
誘導的な質問をする	回答に偏りが生じ、意図が見えにくくなります	自由回答形式にするか、偏りのない選択肢を示します
1回だけ確認して終える	複雑な設計依頼では反復が必要です	方向性が収束するまで続けます
結果が同じになる場合にも質問する	不必要な摩擦が生じます	判断に迷う場合は、直接進めることを優先します

---

重複を避けるための注記

このスキルが扱うのは、設計ブリーフの曖昧さ — どのような設計を作るべきか判断できない原因となる情報の不足です。コアの design-for-ai スキルが担う意図の検出（実行するモードを、design、surface、fonts、color、audit、enhance、polish から選ぶこと）に代わるものではありません。ユーザーの依頼がデザインモードであることは明確でも、設計ブリーフ自体の情報が不足している場合は、clarify を呼び出します。依頼のモードが不明確な場合は、コアスキルが振り分けます。

---

チェーン

完了後	次のアクション
曖昧さが解消され、ブリーフが確認された	目標、対象ユーザー、ブランド、制約、文体を添えて、呼び出し元のコマンドに戻ります
設計作業中に新たな曖昧さが生じた	clarify のループに再び入ります