画面コンセプト集の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト全体の画面体験コンセプト(体験方向性・体験原則・トーン&マナー方針)と、それを体現する代表シーン2-3を、ビジネスサイドが議論・合意できるサイズに整理する文書。
業界を問わず利用可能(業務アプリ・ゲーム・コンシューマー向けサービス・SaaS 等)。プロダクト要求仕様書(PRD)・アクター一覧・ユーザーストーリー一覧を上流とし、下流のワイヤーフレーム・画面遷移図・画面要件群(D2)の判断基準となる画面体験の方向性を定める。
全画面の網羅は D2 画面要件群に降ろし、本書はコンセプトと代表シーンに集約する。PRD・ユーザーストーリー一覧の策定後、D2 画面要件群の作成前、もしくはデザイン会社への発注前に呼び出す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
本書は 「全画面のミニ要件」ではなく「画面体験そのものの方向性 + 代表シーンの絵姿」 を扱う。下流のワイヤーフレーム・画面遷移図・全画面要件は、本書のコンセプトを判断基準にして設計者・エンジニアが起こす。
| 本書に書くもの | 本書に書かないもの(降ろし先) |
|---|---|
| プロダクト全体の画面体験コンセプト(1段落) | 個別画面の要件項目(→ D2 画面要件群) |
| 体験原則 3-5 項目 | 全画面の網羅一覧・ID 採番(→ D2 画面要件群) |
| トーン&マナー方針(Figma ムードボード参照) | 状態網羅・遷移網羅・バリデーション・エラー時挙動(→ D2 画面要件群) |
| 代表シーン 2-3(最大5) | ハイファイデザイン・コンポーネント仕様・トークン(→ D3 以降) |
サイズ感の規律: ビジネスサイドが現実に議論・合意できる規模に収める。代表シーンは 2-3 が標準、最大 5。これ以上に膨らんだら本書の目的から外れているサイン(全画面網羅型に逆戻りしていないかを確認する)。
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/business-requirement-document.md | 上流のBRD(事業戦略・KPI・フェーズ2境界 等を参照) |
docs/D1.business-requirements/actor-list.md | 上流のアクター一覧(代表シーンの主アクター ID の引用元) |
docs/D1.business-requirements/product-requirement-document.md | 上流のPRD(§提供価値・体験方針・§システム利用ユーザーと体験設計・§UI/UX方針 を参照) |
docs/D1.business-requirements/user-story-list.md | 上流のユーザーストーリー一覧(代表シーンが体現するストーリーの参照元) |
docs/D1.business-requirements/domain-requirements/*.md | 上流のドメイン要求仕様書群(代表シーンが該当する業務工程の参照元) |
docs/D1.business-requirements/screen-concepts.md | 既存の画面コンセプト集(更新・レビュー時のみ参照。新規作成時は未存在) |
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/screen-concepts.md | 画面コンセプト集本体 |
出力時は以下のテンプレートを読み込み、その章構成・書き方ヒントに従う。
| テンプレートのパス | 内容 |
|---|---|
.claude/skills/d1-screen-concepts/template.md | 画面コンセプト集テンプレート(章構成・書き方ヒント) |
外部成果物として Figma file(ムードボード/スタイルタイル + 代表シーン用ラフ)を併走させる。本書は Figma file へのリンクを含むが、Figma file 自体の作成は本スキルの責務外(後述「Figma との関係」参照)。
新規作成時(docs/D1.business-requirements/screen-concepts.md 未存在)は ユーザーへのヒアリングを行わず、上流成果物群と業界一般知識からコンセプト・原則・代表シーンを推定して直接生成する。
DOM-COMMON-* / BRD KPI 等)への参照を付ける{{...URL}}【要確認】 を仮置きするSC-PR-<連番>(体験原則)/ SC-SCENE-<連番>(代表シーン) 形式(成果物略号=SC (Screen Concepts)、カテゴリ=PR / SCENE)。画面体験コンセプト宣言の段落自体には ID を付けない./actor-list.md)の ID を併記(例: 営業職員(ACT-1) / 申込人(ACT-5))。複数アクターが共用するシーンは中黒区切り「このプロダクトを一言で説明するならこの場面」と言える、コンセプトを最も色濃く体現する数シーンに絞る。以下のいずれかに該当するシーンを優先する:
以下は通常 代表シーンに含めない(D2 画面要件群で扱う):
DOM-COMMON-* / BRD KPI / *-BR-* / US-*)への参照を最低 1 つ紐付ける[フェーズ2] ラベルを付与し、初期/将来の境界を明示する本書は Figma file への リンク参照 として機能する。Figma file 自体の作成・更新は ユーザーが手動で行う ことを前提とする。
本書が Figma 側に期待する成果物は以下に限定される(全画面ワイヤー網羅ではない):
| Figma 側成果物 | 用途 | 紐付け先 |
|---|---|---|
| ムードボード/スタイルタイル | トーン&マナー方針の視覚化 | 本書「トーン&マナー方針」のリンク |
| 代表シーン用ラフ(各シーン1枚) | 代表シーンの絵姿(中〜高忠実度可、コンセプト議論用) | 各代表シーンの Figma リンク |
これによりビジネス合意フェーズの Figma 投資が現実的な量(ムードボード1 + 代表シーン2-3)に収まる。全画面ワイヤーフレームは D2 画面要件群の責務であり、本書段階では作成しない。
Figma MCP ツールが利用可能な環境で ユーザーから明示指示があった場合に限り、use_figma / create_new_file 等で初期ラフを生成してもよい。ただしビジネス側の意図反映は人手の方が確実なため、自発的な Figma ファイル生成は行わない。
Figma MCP ツールが利用可能な環境では、本書のレビュー・更新時に リンク先を実際に取得して本文記述と照合する。本書は Figma と対で読まれる文書であり、テキストだけを読んで整合を判断しない。
取得の条件: 対象リンクが実 URL(【要確認】 が外れている)であり、かつ node-id を含む場合に限り取得する。仮置きのままのリンク・node-id を持たないファイル全体 URL は取得せず、後者はフレーム単位の URL をユーザーに求める。新規作成時はリンクが全て仮置きのため、取得は発生しない。
使うツール:
| ツール | 用途 |
|---|---|
get_screenshot | 既定。絵姿の確認はこれで足りる |
get_metadata | シーン内の構成要素を数える必要がある場合のみ |
get_variable_defs | 本書では使わない(色・タイポの具体値は D3 の責務) |
get_design_context | 本書では使わない(design-to-code 用であり D1 の抽象度を超える) |
照合の観点: トーン&マナー方針の宣言文とムードボード/スタイルタイルが同じ方向を向いているか。各代表シーンの「期待する画面の雰囲気」とラフの絵姿が一致しているか。本文が言及していない主要素がラフに描かれていないか(逆も同様)。
齟齬を見つけた場合の扱い: どちらが正かを自己判断せず、齟齬の内容をユーザーに指摘するに留める。Figma file は人手管理であり、本書側を Figma に合わせて書き換える・Figma を本書に合わせて編集する のいずれも自発的には行わない。
転記の禁止: 取得したビジュアルから、カラーコード・フォント名・余白値・コンポーネント名 等の具体値を本書に書き写さない。これらは D3 以降の責務であり、Figma を見たことを理由に本書の抽象度を下げない。
執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
DOM-COMMON-* / BRD KPI / 等)への参照が紐付いているか[フェーズ2] ラベルが付与されているかSC-PR-<連番> / SC-SCENE-<連番> 形式になっているか【要確認】 が残っている場合、それが意図的な仮置きか(初期はマーカー残置が正常){{ や XXX のプレースホルダが残っていないか(Figma URL を除く)作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | 画面コンセプト集から何を引く |
|---|---|
| 画面要件群(D2) | 体験原則を全画面の設計判断軸として継承。代表シーンの方向性を念頭に置きつつ、全画面の正式な要件項目を網羅展開 |
| ワイヤーフレーム・画面遷移図(D2-D3) | 体験原則・代表シーンの雰囲気を全画面のワイヤーに展開する起点 |
| デザインカンプ・デザインシステム(D3 以降) | トーン&マナー方針・代表シーンのハイファイ化の起点。デザイン会社への発注ブリーフとしても機能 |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。
ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。
ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。
ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。