ai-native-product-designer

AI ネイティブなプロダクトデザイナー

役割の定義： AI ネイティブなプロダクトデザイナーは、課題の定義からローンチ、改善まで、プロダクト体験を一貫して担当します。ワークフローの中核として AI ツールを活用し、LLM から始め、コード生成環境でプロトタイプを作成し、検証済みのコンセプトを Figma に持ち込んで、デザインシステムの構築や仕上げを行います。成果に責任を持ち、成果物だけに責任を持つわけではありません。

このスキルを使う場面

ユーザー（またはタスク）が次のいずれかに該当する場合に、このスキルを使ってください。

• AI ネイティブなデザイン職の役割、チームへの期待、採用基準を定義またはレベル分けする
• チームやデザイナーがLLM を第一に活用し、AI コードツールで検証を行い、Figma を（最初のキャンバスではなく）本番向けの仕上げとして扱っているか監査する
• 定例の取り組み（AI を使った PRD の草案作成、エッジケースの洗い出し、プロトタイプの忠実度、引き継ぎの品質）を設計する
• 現代のプロダクトデザインの基準に照らして、面接の評価基準、パフォーマンス基準、自己評価を準備する
• 特定のワークフローにおける、従来型とAI ネイティブな働き方を比較する

このドキュメントを法律上または人事上の助言として扱わず、組織に合わせて表現を調整してください。

回答方法

ユーザーから明示的な指定がない限り、次のようにしてください。

1. 成果を最初に示します。 ツールへの好みではなく、ユーザーの行動、ローンチのリスク、または合意形成までの時間に結び付けて提案します。
2. 出力の基本形式（ユーザーが形式を指定していない場合）：
   • 概要： このフレームワークと比べて目立つギャップまたは強みを3～6個の箇条書きで示します
   • ギャップ一覧： 番号付きで、各ギャップを付録の評価基準のクラスターまたは行に結び付けます
   • 優先アクション： 次の1～2回のスプリントで取り組む上位3つの変更を示します（各アクションは担当者を割り当てられる程度に具体的にします）
   • 任意： 各アクションに対して、例となるプロンプトまたは定例の取り組みを1つ示します（短く、そのままコピーして使える形式）
3. 詳細な評価には付録を使います。誰かを評価するときや職務記述書を作成するときは、評価基準の各行の文言を正確に引用します。
4. 背景情報が不足している場合は、長い評価を行う前に、確認の質問を1つしてください（チームの規模、B2B か消費者向けか、規制対象かどうか）。

用語

• AI native（2語で、「native」は文中では小文字）は、役割とワークフロー（LLM を第一に活用し、コードで検証し、Figma でシステムを構築して引き継ぐ）を指します。
• 評価基準における Native 単独の表記は、最高の習熟度レベル（Developing / Fluent / Native）を指します。「Native レベル」と「AI ネイティブなデザイナー」を混同しないでください。

クイックリファレンス（要点）

3層のスタック

Layer 1: LLM (Claude / ChatGPT / Gemini)
   -> Clarify intent, draft PRDs, surface risks, align teams, explore solution spaces

Layer 2: AI Code Tools (Cursor / Claude Code / v0)
   -> Build interactive prototypes, generate UI flows, iterate on behavior fast

Layer 3: Figma
   -> Full state coverage, design system alignment, production-ready handoff

原則： Figma はデザインを仕上げる場所であり、始める場所ではありません。

各レベルの習熟度を一言で表すと

• Developing： AI を使うことはありますが、通常のワークフローは依然として Figma から始まります。
• Fluent： サイクル全体を通して AI が標準となっており、習慣として定着しています。
• Native（レベル）： AI ワークフローを深く実践し、他の人に教え、チームのパターンを形作ります。

セルフチェック（頭の中またはチャットで「はい」／「いいえ」で回答）

1. 新しいデザイン課題に取り組むとき、Figma の前に LLM を開きますか？
2. 過去30日間に、AI コードツールを使ってインタラクティブなプロトタイプを作成しましたか？
3. PM がレビューして活用できる、軽量な PRD の草案を AI で作成できますか？
4. 過去2週間に、リサーチチームを介さず顧客と直接話しましたか？
5. まず80％のケース向けにデザインし、エッジケースで何を非表示にするかを明確に決めていますか？
6. 引き継ぐすべての画面について、エラー、空、読み込み状態を含む、すべての状態を網羅していますか？
7. 現在のプロジェクトで成功がどのような状態かを、具体的かつ測定可能な形で説明できますか？
8. リリース後に、自分が出荷した機能のデータを確認し、次の改善に活用していますか？
9. 直近のスプリントで、プロンプト、パターン、またはワークフローに関する発見をデザインチームと共有しましたか？
10. デザインの納品だけでなく、行動の変化にも責任を持っていますか？

チェックリストの後に： すべての**「いいえ」に対して、今スプリントで実行できる具体的な次のステップを1つ**提案します（担当者、成果物、または時間枠を明記します）。「もっと AI を使う」のような曖昧な助言は避けてください。

実際の求人との一致（例）

公開されているプロダクトデザイナーの求人では、このスタック（意図と簡易な仕様には LLM、フローにはClaude／Cursor／Claude Code、システムと仕上げにはFigmaを使用し、成果物より成果を重視し、軽量なリサーチを行い、プロンプトを共有する）がますます反映されています。公開例の一つがRampです（このスキルとは無関係です。市場の参考情報としてのみご利用ください）。

---

付録：コンピテンシー評価基準の全容

評価、職務記述書、詳細なコーチングにこのセクションを使用してください。

この職務に異なる習熟度レベルがある理由

従来のデザイン職では、AI は新たに身につけるスキルとして扱われます。この職務では、AI 活用能力は必須要件であり、差別化要因ではありません。習熟度の尺度が示すのは、AI への単なる認識ではなく、AI をどれだけ深く統合しているかです。

スキルの習熟度レベル

レベル	意味
Developing	AI ツールを時折使用しますが、従来のデザイン優先のワークフローを引き続き基本としています。
Fluent	デザインサイクル全体で AI ツールを標準的な出発点として使い、日常的に統合しています。
Native	AI ワークフローが深く組み込まれており、他者を指導し、新たなパターンを生み出し、可能性の最前線を押し広げています。

スキルクラスター 1：AI ファーストのデザインワークフロー

ビジュアルデザインに着手する前に、LLM を主な思考と認識合わせのツールとして活用する能力です。

スキル	実務での意味	Developing	Fluent	Native
デザインの出発点としての LLM	Figma を開く前に LLM を開き、意図の明確化、問題領域の探索、前提の洗い出しに活用します。	コピーや命名などの個別タスクに LLM を使いますが、デザイン作業は引き続き Figma から始めます。	すべてのデザイン課題を LLM から始めます。問題の枠組みを定め、アプローチを草案し、ビジュアル作業に入る前に PM と認識を合わせます。	個人用のプロンプトライブラリとワークフローを開発し、曖昧な状態から明確な状態への移行を、同僚より一貫して速めています。
デザインのためのプロンプトエンジニアリング	問題の枠組み、PRD の草案、エッジケースの一覧、ユーザーフローのスケッチなど、デザインに役立つ出力を生成するプロンプトを作成します。	基本的なプロンプトを使いますが、出力には大幅な編集が必要です。	コンテキスト、制約、出力形式を含む構造化されたプロンプトを作成し、出力だけでなくプロンプト自体も反復的に改善します。	デザインチームで活用されるプロンプトシステムを構築・共有し、プロダクトや UX のユースケースに応じたプロンプト設計について他者を指導します。
AI を活用した PRD の作成	LLM を使って簡潔なプロダクト要件定義書を草案し、スコープ、意図、未解決の質問についてチームの認識を合わせます。	AI の支援を受けて、PRD の大まかなアウトラインを作成できます。	LLM との会話から構成の整った PRD の草案を作成し、ビジュアル作業の開始前に PM とレビューして認識を合わせます。	チームにおける PRD からデザインへの連携を主導し、AI が生成した PRD を活用して認識合わせの会議を大幅に減らします。
リスクとエッジケースの洗い出し	UI 作業に入る前に、LLM を使ってエラー状態、権限に関するエッジケース、望ましくない経路など、問題が起こりうる箇所を体系的に特定します。	AI にエッジケースを尋ねますが、最初の一覧を深掘りせずに受け入れます。	AI を使って包括的なエッジケースのマトリクスを作成し、エンジニアリング上の制約と照らし合わせて検証し、調査結果をチームの認識合わせに活用します。	エッジケースの洗い出しを繰り返し実施できるチームの習慣として設計し、事前にこの作業を行うことで、リリース後に発生するバグの一連のカテゴリを未然に防ぎます。
AI 生成の成果物を通じたチームの認識合わせ	Figma に入る前に、AI が生成したドキュメント（PRD、ブリーフ、リスク一覧）を PM やエンジニアリングとの認識合わせに活用します。	AI の出力を非公式に共有しますが、認識合わせは会議で行います。	AI が生成した成果物を使って、構造化された非同期の認識合わせを行い、ビジュアル作業の開始前のやり取りを減らします。	AI 生成の成果物によって初期段階の会議の大半を置き換えるチームレベルのワークフローを設計し、非同期で記録に残る形で認識を合わせます。

スキルクラスター 2：AI を活用したプロトタイピングと構築

Figma よりも迅速に UX の前提を検証できる、インタラクティブなプロトタイプを AI コードツールで構築する能力です。

スキル	実践での意味	発展中	流暢	熟達
AI コードツールによるプロトタイピング	本番用コードを手作業で書かずに、AI コード生成ツールを使ってインタラクティブなフロープロトタイプを構築することです。	AI コードツールを試したことがあり、AI の大幅な支援を受けて基本的なプロトタイプを実行できます。	Cursor や Claude Code などのツールを日常的に使って、フローやシンプルなインターフェースのインタラクティブなプロトタイプを構築し、素早く反復します。	検証目標ごとに適切なプロトタイプの忠実度を選び、AI に指示して、驚くほど複雑なインタラクションも正確に構築できます。
AI コード生成の指示	単に機能するコードではなく、適切な UX 品質を備えたコードになるよう、AI 生成コードを導く方法を知っていることです。	AI の出力をそのまま受け入れ、削除して再度プロンプトを入力せずに動作を修正するのに苦労します。	インタラクションモデル、エッジケース、品質基準を指定するなど、体系的な指示を AI に与え、意図に合致するまで動作を反復調整します。	AI を作業の速い若手エンジニアのように扱い、最初の出力から高品質なコードが得られるブリーフを作成します。構文レベルではなく UX レベルでレビューし、指示します。
プロトタイプからプロダクトへの引き継ぎ	AI プロトタイプから実際のプロダクトに移すものと、エンジニアリングで作り直すものを見極めることです。	プロトタイプを使い捨てとして扱い、すべてを一から作り直します。	エンジニアリングチームと積極的に連携し、プロトタイプのコードのうちプロダクトに移せるほど整理されたものを見極め、開発時間を節約します。	チーム全体で使う、プロトタイプから本番環境へのワークフローを設計し、「検証済みのプロトタイプ」から「リリースされた機能」までの隔たりを縮めます。
インタラクションの忠実度の判断	Figma の静的なモックで十分な場合と、適切な前提を検証するためにインタラクティブなコードプロトタイプが必要な場合を判断することです。	あらゆるものに Figma を使い、依頼されたときにだけコードプロトタイプを作成します。	検証する内容に基づいてプロトタイプの忠実度を選び、リスクの低い判断で作り込みすぎたり、複雑なインタラクションで作り込みが足りなくなったりすることを避けます。	チーム全体のプロトタイプ忠実度の基準を定め、検証する問いに忠実度を合わせる方法をほかのメンバーに指導します。
フロントエンドの基礎知識	AI 生成コードに正確な指示を出せるよう、コンポーネント、状態、props、レスポンシブな動作、基本的なレイアウト制約を理解していることです。	コンポーネントや状態の存在は知っていますが、正しく実装するよう AI に指示するのに苦労します。	コンポーネント構造、状態管理の基本、レイアウトの基本要素を理解し、AI ツールに正しい実装を生成させるための指示を出せます。	デザインとエンジニアリングの議論を流暢に橋渡しし、PR を読んで、インタラクションがデザインの意図に合致しているかを評価できます。

スキルクラスター 3：プロダクト思考と課題定義

ソリューションを設計する前に、PM やエンジニアと協力して、適切な課題を定義する能力です。ここで扱う範囲： 決定すること（課題の説明、選択肢、指標の意図、構築に関するトレードオフ）。クラスター 7では、日々の協働の習慣をどのように進めるか（デザインレビュー、定例の頻度、組織学習）を扱います。

スキル	実務での意味	発展途上	流暢	熟達
課題の捉え方	ソリューションに飛びつく前に、ユーザーとビジネスの実際の課題を定義し、プロジェクトを通じてチームがその課題を見失わないようにすることです。	課題を説明できますが、すぐにソリューションに飛びつきがちです。	症状と原因を区別した明確な課題の説明を書き、時期尚早なソリューションに異議を唱えるために活用します。	課題定義をチームの習慣として設計し、誤った課題にスプリント全体を費やすことを防ぎます。
ソリューション領域の探索	1つに決める前に、AI を活用して幅広い案を効率よく生み出し、複数のソリューションの方向性を比較することです。	1～2つの案を検討し、妥当な最初の案に決めます。	AI を使って5～8個のソリューションの方向性をすばやく生み出し、ユーザーの目標や制約に照らして評価してから絞り込みます。	発散的思考に AI を活用する方法をチームに教え、意外性のあるソリューションを見つけるための探索フレームワークを設計します。
エンドツーエンドのオーナーシップ	課題定義からローンチ後の反復改善まで関わり続け、引き継いで次に進むだけにしないことです。	デザインを完成させて引き継ぎ、ローンチ後の反復改善にはほとんど関わりません。	課題、デザイン、ローンチ、反復改善までのライフサイクル全体を担い、ローンチ後のデータを使ってフィードバックループを完結させます。	デザインのオーナーシップが、測定可能な行動変化にまで及ぶチームのアカウンタビリティモデルを設計します。
PM との連携	デザインの前や最中に、PM と協力して成功指標、スコープのトレードオフ、ソリューションの優先順位を定義することです。	PM から要件を受け取り、実行します。	PM と成功指標を共同で定義し、スコープに異議を唱え、UI だけでなくプロダクト戦略にも貢献します。	PM とデザイナーの協業モデルを設計し、効果的な課題定義セッションの進め方をチームに指導します。
エンジニアとの連携	引き継ぎのときだけでなく、全工程を通じてエンジニアと直接協力し、UX に役立つ実装上の判断を行うことです。	エンジニアに引き継ぎ、質問には受け身で対応します。	早い段階からエンジニアをデザイン上の判断に巻き込み、実装コストを把握したうえで、UX の品質を保つトレードオフを行います。	チームのエンジニアリング連携パターンを設計し、デザイナーが技術面のパートナーとなる関係を体現します。

スキルクラスター 4：セルフサービス型のユーザーリサーチ

ボトルネックにならずに、方向性の決定に役立つ迅速で簡易なリサーチを実施する能力です。

スキル	実践における意味	発展中	流暢	ネイティブ
顧客との対話	リサーチチームを待たずに、顧客と直接話して仮説を検証します。	インタビューの設定と実施をリサーチ担当者に頼ります。	顧客との対話を独自に設定・実施し、方向性を示すインサイトをすばやく引き出します。	顧客との対話を毎週の習慣として定着させ、迅速かつ継続的なフィードバックを得られる非公式な顧客ネットワークを構築します。
仮説のマッピング	デザインの前提となる仮説を明確にし、テスト前にリスクの高さに応じて順位付けします。	仮説を暗黙のままにし、テスト対象として明らかにしません。	テストの前に主要な仮説を列挙し、リスクと可逆性に基づいて検証の優先順位を決めます。	重要なデザイン作業を始める前に、チームの定例として仮説のマッピングを行います。
迅速なテスト	正式な調査を行わずに方向性を検証できる、迅速で非公式なテスト（5秒テスト、廊下テスト、非モデレーションセッション）を実施します。	完全なリサーチ調査を待ち、簡易なテストの習慣がありません。	顧客や同僚3〜5人を対象に迅速なテストを実施して方向性を検証し、本格的な実行に移る前に結果に基づいて調整します。	チームがセルフサービスで利用できる迅速なテスト用テンプレート集を作成し、簡易なテストをチームの習慣として定着させます。
スピードを高める手段としてのリサーチ	リサーチを、進行を遅らせる関門ではなく、デザインの意思決定を加速するために活用します。	リサーチを品質の関門として扱い、スプリントの進行を遅らせます。	リサーチの結果を活用して、より迅速かつ確信を持って意思決定します。リサーチによって手戻りを減らし、所要時間を増やしません。	リサーチによってスピードを高める考え方をチームに伝え、2時間のテストが2週間の手戻りサイクルをいかに省くかを示します。

スキルクラスター 5：インタラクションデザインとクラフト

多くのユーザーにとってシンプルなインタラクションを設計しつつ、例外的なケースでは適切な判断が行われるようにする能力です。

スキル	実践での意味	発展途上	熟達	ネイティブレベル
80/20 デザイン思考	一般的なケースではデフォルトの体験を設計し、例外的なケースでは複雑さを見えにくくすることです。	すべてのケースを同じように設計し、デフォルトの体験に複雑さが表れます。	80％のケースを特定し、そこに徹底的に最適化します。例外的なケースにもアクセスできますが、邪魔になりません。	80/20 のデザイン原則をチーム全体の品質基準として定着させ、機能を損なうことなくプロダクトの複雑さを軽減します。
複雑さの内包	スマートなデフォルト設定、段階的な情報開示、AI による自動化を通じて、システムの複雑さをユーザーに見せないことです。	表面的な対応にとどまり、すべてのユーザーにすべての選択肢やコントロールを表示します。	裏側で適切な判断を行い、ほとんどのユーザーが自分に不要な複雑さに触れずに済むようにします。	AI とプロダクトのロジックが複雑さを見えないところで処理するシステムを設計します。システムが賢いため、インターフェースはシンプルです。
インタラクションデザイン	すべてのインタラクティブな要素について、見た目だけでなく、どのように応答するかも含めて具体的な動作を設計することです。	静的な画面を設計し、インタラクションの詳細はエンジニアに委ねます。	タイミング、トランジション、例外的なケースへの応答、読み込み状態、エラーなど、インタラクションの動作を明確に定義します。	チームのインタラクションデザイン基準を策定し、意図した UX に沿っているかエンジニアリングの実装をレビューします。
状態のデザイン	各コンポーネントのすべての状態（デフォルト、ホバー、フォーカス、読み込み、エラー、空、成功）を設計することです。	デフォルトの状態を設計し、その他の状態はエンジニアリングの過程で見つかります。	デザインの一部としてすべての状態を事前に設計し、後回しにされる状態がないようにします。	不完全な状態設計をデザインレビューでブロッキング問題として扱い、プロダクト全体に拡張できる状態のライブラリを設計します。
UX の品質基準	インタラクションの品質に関する高い基準を定めて維持し、「良い」とは何かを明確に説明できることです。	良い UX を見ればわかりますが、その基準を説明するのに苦労します。	UX の品質基準を明確に定義し、レビューで具体的かつ実行可能なフィードバックを伝えるために活用します。	レビュー、パターン、文書化された基準を通じて、デザイン組織全体の品質基準を引き上げます。

スキルクラスター 6：Figma とデザインシステム

検証済みのコンセプトを Figma に取り込み、本番環境向けの引き継ぎを実現する能力です。これはデザインスタックの最終レイヤーです。

スキル	実践での意味	習得中	流暢	ネイティブ
検証済みコンセプトの反映	コードでテスト・構築したコンセプトを、本番向けの完全な Figma デザインに反映することです。	最初から Figma でデザインします。プロトタイプで得た学びが一貫して反映されません。	コードプロトタイプで得た学びを Figma に適切に反映します。Figma ファイルには初期の仮定ではなく、検証済みの UX が反映されています。	コードプロトタイプから Figma への移行がスムーズかつ迅速に行えるワークフローを設計します。移行時に情報が失われることはありません。
Figma におけるすべての状態の網羅	ハッピーパスだけでなく、Figma であらゆるコンポーネントと画面のすべての状態をデザインすることです。	主要なフローをデザインしますが、状態の網羅が不十分です。	引き継ぎ前に、すべての Figma フレームですべての状態をデザインします。エンジニアリングから見た目について質問が出ません。	他の人の Figma ファイルをレビューして状態の網羅性を確認し、不完全な状態があれば引き継ぎを阻止します。
デザインシステムとの整合性	すべての Figma デザインで共有コンポーネントを使用・拡張し、新しいコンポーネントが必要な箇所を明示することです。	コンポーネントの使い方に一貫性がなく、独自のデザインを頻繁に作成します。	共有コンポーネントを適切に使用し、システム全体を考慮して新しいコンポーネントを作成し、システムの不足箇所を積極的に明示します。	デザインシステムのガバナンスに貢献し、共有コンポーネントを慎重に拡張して、プロダクト全体のデザインのずれを抑えます。
本番対応	エンジニアリングが追加質問なしで実装できる Figma ファイルを準備することです。	Figma のリンクを引き継ぎ、エンジニアリングからの質問にその都度回答します。	完全な仕様、注釈、エッジケースの網羅を含む Figma ファイルを作成します。エンジニアリングからの質問はほとんどありません。	チームの本番対応基準を定め、エンジニアリングの開始前に引き継ぎの品質を監査します。

スキルクラスター 7：部門横断のコラボレーションとコミュニケーション

PM やエンジニアと引き継ぎのときだけでなく、直接かつ継続的に協働する能力です。このクラスターの範囲：定例の進め方、コミュニケーションの規範、デザインレビューの質、学びの共有方法です。PM／エンジニアの意思決定の内容（指標、スコープ、トレードオフ）はクラスター 3で扱います。

スキル	実務での意味	発展途上	熟達	ネイティブ
PM との直接的なパートナーシップ	要件を受け取るのではなく、PM と並行して課題を定義し、解決策を探り、結果に基づいて調整することです。	PM の要件を実行します。課題の定義への関与は限定的です。	PM とともに課題から解決策までのプロセスを担い、UI の実行だけでなくプロダクト戦略にも貢献します。	チームの PM とデザインの協働モデルを設計し、双方がうまく協働できるよう指導します。
エンジニアリングレベルのコミュニケーション	エンジニアリングの言葉で話し、技術的な会話ができる程度に実装を理解することです。	UX レベルでコミュニケーションを行い、エンジニアによる翻訳が必要です。	コンポーネント、状態、API、パフォーマンス上の制約を十分に理解し、デザインにおいて情報に基づいたトレードオフを行います。	デザインとエンジニアリングの思考をつなぎ、エンジニアを早い段階から巻き込むことで、実装時の想定外を減らします。
デザインレビューへの参加	既存の成果物を検証するだけでなく、品質基準を高めるフィードバックをデザインレビューで提供し、受け取ることです。	成果物を提示し、フィードバックを受け身で受け取ります。	具体的で原則に基づいた批評を行い、建設的に異議を唱え、プロンプトや学びを積極的に共有します。	デザインレビューの文化とプロセスを設計し、組織全体の質を高める批評のあり方を実践して示します。
パターンと学びの共有	AI プロンプト、デザインパターン、ワークフローで得た発見を、デザイン組織に積極的に還元することです。	他の人が見つけたパターンを使います。新しいパターンを共有することはほとんどありません。	プロンプト、パターン、ワークフローで得た発見を定期的に共有し、共有のデザインナレッジベースに貢献します。	チームで共有する AI デザインライブラリを構築し、個人の貢献を超えて拡張できる知識共有の仕組みを設計します。

スキルクラスター 8：指標と成果へのオーナーシップ

成功を定義して測定し、顧客の行動が変わるまで改善を繰り返す能力です。

スキル	実務における意味	育成中	流暢	ネイティブ
成功指標の定義	開発前に、デザインが達成すべき具体的で測定可能な成果を PM と共同で定義します。	機能をリリースします。成功指標は PM が個別に設定します。	成功指標の定義に貢献し、デザイン上の判断が測定可能なユーザー行動にどう結び付くかを理解しています。	デザインと指標のつながりにオーナーシップを持ち、初日から具体的な行動成果を念頭に置いてエクスペリエンスを設計します。
リリース後の改善	引き継ぎ後に次へ移るのではなく、リリース後も関与を続け、結果を測定し、データを解釈して改善をリリースします。	引き継ぎ後は次のプロジェクトに移ります。リリース後の改善は PM が主導します。	リリース後のデータを確認し、行動が仮説からどこで乖離したかを特定して、根拠に基づくデザインの改善を主導します。	チームのリリース後レビューの習慣を設計し、リリースするすべての機能に測定可能な成果のフィードバックループがあるようにします。
成果と成果物の捉え方	リリースしたデザイン成果物ではなく、顧客の行動変化によって成功を測定します。	何をデザインして提供したかを報告します。	デザインによって顧客の行動がどう変わったかを報告します。	チームに成果重視の考え方を教え、行動変化より成果物の完成を評価する組織レベルのインセンティブに異議を唱えます。
データに基づくデザイン	アナリティクス、セッション録画、サポートデータなどの定量・定性シグナルを活用し、デザイン上の判断に役立てます。	PM やアナリストから提示されたデータを使用します。	関連データを自ら収集し、デザイン上の判断に照らして解釈し、方針の検証や見直しに活用します。	デザインチームのデータリテラシーを高める取り組みを設計し、根拠に基づくデザイン上の判断を行う文化を築きます。

部門横断スキル

AI ネイティブなプロダクトデザイナーの有効性を高める、隣接する職種と共有するスキルです。

スキル	この役割にとって重要な理由	隣接する職種
SQL／アナリティクスの基礎	自分でデータを取得できるデザイナーは、アナリストを待たずに、より迅速にデザイン上の判断を検証できます。	データアナリスト
フロントエンド開発の基礎	React コンポーネント、状態、CSS を理解していると、AI が生成するプロトタイプの精度が上がり、引き継ぎもスムーズになります。	フロントエンドエンジニア
プロダクトマネジメントの基礎	賭け、仮説、指標の観点から考えるデザイナーは、PM とより良いパートナーシップを築けます。	プロダクトマネージャー
UX リサーチ手法	セルフサービス型のリサーチには、簡易なテストであっても、妥当なテストを設計する方法を知っていることが必要です。	UX リサーチャー
システム思考	複雑なプロダクトはシステムです。デザイナーは、変更がエクスペリエンス全体にどう波及するかを理解する必要があります。	システムアーキテクト／プロダクトアーキテクト

最前線のスキル（近い将来に重要となる領域）

エージェント型プロダクト、AI のユーザー接点、デザインシステムが融合するなかで重要となる能力です。対象範囲は市場の動向に応じて変化するため、四半期ごとに見直してください。

スキル	重要性が高まっている理由	今から身につける方法
エージェント型 UX デザイン	ユーザーに代わって複数のステップを実行する AI エージェントには、ステータス、制御、信頼、復旧といった新しいインタラクションモデルが必要です。	現在のエージェント UI（Perplexity、Claude Projects、Devin）を調べ、自社プロダクト向けの概念的なエージェントインターフェースをデザインしてください。
AI 機能の UX パターン	AI を活用した機能（提案、要約、生成、自動化）のデザインには、信頼、透明性、制御のための新しいパターンが必要です。	AI UX パターン（読み込み状態、信頼度の表示、修正フロー）をまとめた個人用パターンライブラリを作成してください。
インターフェースとしてのプロンプトのデザイン	プロダクトが自然言語インターフェースを提供するようになるにつれ、プロンプトを入力する体験そのものがプロダクトデザインの課題になります。	プロンプト入力コンポーネントを、空の状態、例、エラー処理、応答状態まで一貫してデザインしてください。
評価に基づくデザイン	AI の出力品質にはばらつきがあるため、デザイナーはユーザーが品質を伝え、時間とともに AI の応答を改善できる評価ループをデザインする必要があります。	RLHF とアラインメントの基礎を学び、AI の出力を改善するフィードバックシグナルを追加できそうな場所を、自社プロダクトから1つ見つけてください。
デザインシステムと AI	AI コンポーネント（ストリーミングテキスト、引用、ツールの使用状況表示）には標準化されたコンポーネントが必要です。未来のデザインシステムには AI パターンが含まれます。	デザインシステム向けの AI 専用コンポーネントを1つ提案し、すべての状態を仕様化してください。

自己評価チェックリスト（表形式）

YES または NO で回答してください。NO はすべて成長の機会です。回答後、各 NO に対して具体的な次のステップを1つ設定してください（「クイックリファレンス」を参照）。

#	質問	Yes / No
1	新しいデザイン課題に取り組むとき、Figma より先に LLM を開きますか？
2	過去30日間に、AI コードツールを使ってインタラクティブなプロトタイプを作成しましたか？
3	PM がレビューして活用できる、簡潔な PRD の草案を AI で作成できますか？
4	過去2週間に、リサーチチームを介さず、顧客と直接話しましたか？
5	まず80％のケースを対象にデザインし、エッジケースでは何を非表示にするかを明確に決めていますか？
6	引き継ぐすべての画面で、エラー、空、読み込みを含む状態を網羅していますか？
7	現在のプロジェクトで何を成功とするか、具体的かつ測定可能な形で説明できますか？
8	リリースした機能のリリース後データを確認し、次の改善に活用していますか？
9	直近のスプリントで、プロンプト、パターン、ワークフローに関する発見をデザインチームに共有しましたか？
10	デザインを納品するだけでなく、行動変容に責任を持っていますか？

役割の比較：AI ネイティブなプロダクトデザイナーと従来型のプロダクトデザイナー

項目	従来型のプロダクトデザイナー	AI ネイティブなプロダクトデザイナー
デザインの開始場所	Figma	LLM（Claude / ChatGPT / Gemini）
プロトタイピングツール	Figma / InVision	Cursor + Claude Code / v0
Figma の役割	主なデザイン環境	最終的な仕上げ + 本番環境向けのレイヤー
リサーチの進め方	リサーチャー主導の正式な調査	自分で実施し、スピードを優先
PRD との関わり方	PM から PRD を受け取る	AI + PM と PRD を共同作成する
エンジニアリングへの関与	引き継ぎ時	課題の定義から継続的に関与
成功指標	デザインの納品	顧客の行動が変化したか
AI スキルの位置づけ	発展途上 / あれば望ましい	必須要件 / 初日から求められる期待