Content last updated 2026-02-12

AI を活用したデザインのためのガイド

プロダクトデザイナーが AI プロジェクトをナビゲートするためのガイドラインです

このガイドは、テクノロジーがユーザー体験を高め、戦略的目的を満たすことを確実にするため、AI ソリューションを思慮深くデザインする のに役立ちます。

デザイン業務で AI をどのように使うか については、UX における AI 利用 を参照してください。

AI デザインの課題を理解する

AI 機能と従来の機能をデザインする際の主な違いは不確実性です。大規模言語モデル（LLM）では、以下の両方で不確実性に直面します。

ユーザーが何をしたり書いたりするか LLM がどう応答するか

デザイナーとして、これまでよりもユーザー入力やシステム出力に対する制御が少なくなります。このガイドは、既存のデザインツールキットを補完しつつ、この不確実な環境で作業するためのツールと方法を提供します。

このガイドが扱う主要な質問

  • 予測不可能な入力と出力で、ユーザーのハッピーパスをどうマップするか
  • 可変的なセッションでユーザビリティテストをどう実施するか
  • アンハッピーパスと潜在的な失敗をどう特定するか
  • 主観的な LLM の応答で、タスクの成功をどう測定するか
  • 予測不可能な会話の流れに対してどうデザインするか

AI 機能のためのデザインプロセス

デザインする前に

機会を定義する

問題検証 中、プロダクトマネージャーと密に連携して、誰のためにデザインしているのか、何をデザインしているのか、なぜデザインしているのかを理解する必要があります。

GenAI では、問題とソリューションのスペースが通常より広い場合があります。たとえば、Duo Workflow や Duo Chat のようなものに取り組むとき、チームは「機能はユーザーが尋ねることなら何でも支援できる」と言いたくなるかもしれません。このアプローチでは、後でソリューションを評価するのが困難になります。多くのことを下手にこなし、何も本当にうまくできないソリューションを構築するリスクもあります。

代わりに、以下のページを役立ててください:

  • 問題スペースを明確にスコープ
  • ソリューションが何を解決するか、何を解決しないかを定義
  • 測定可能な成功基準を設定

AI エンゲージメントガイドライン

デザインフェーズに移る前に、デザイナーが AI エンゲージメントガイドラインを作成することをお勧めします。これは Google の People + AI Research が提案したフレームワークで、ここでも使用することを提案します。このフレームワークは AI 関連のデザインおよび技術要件に関する整合性を確立する基盤を提供します。私たちはこのフレームワークを独自の Figjam テンプレート {tbd link} に適応させました。

リソース: Interaction Design Policies: Design for the opportunity, not just the task..

AI エンゲージメントガイドラインを作成することで、モデルのターゲット動作（UX）を定義します。PM と開発チームとの議論を通じて、モデルが何をすべきか、何をすべきでないか、システムやユーザーがどこで失敗する可能性があるかを明確に定義する必要があります。AI ガイドラインを確立することで、ステークホルダーがモデルの動作と期待される出力に整合していることを確保します。

ユーザーフローをマップする

AI のユーザーフローデザインは、出力を予測することではなく、ユーザーが AI と対話し、形作り、AI が失敗した状況から回復するための一貫した方法を作ることに焦点を当てます。ユーザーフローを作成するとき、ハッピーパスとアンハッピーパスを定義します。

ジェネレーティブ AI デザインのハッピーパスは、各対話で正確な入力と出力が異なる場合でも、明確な入力、適切な AI 出力、最小限の修正によって、ユーザーが目標を成功裏に達成できる場合です。

ハッピーパスの例: ユーザー開始: 「この長い文書から重要な洞察を分析して」 システムがリクエスト数を追跡し、明確な使用量メーターを表示 75% で「保存して後で続ける」オプション付きの警告が表示 完了タイムスタンプ付きで進捗が自動保存 翌日、保存された地点から分析を再開

アンハッピーパスは、AI 対話で予期しない出力を修正または回復するためにユーザーの介入が必要な場合に発生します。

アンハッピーパスの例: ユーザー開始: 「この長い文書から重要な洞察を分析して」 非公開のレート制限に達してシステムが失敗 「何かが間違っています」という汎用エラーを表示 リフレッシュ時にユーザーがすべての進捗を失う ユーザーが最初からやり直し

主要な失敗ポイント: システム制限の可視性なし 不明瞭なエラーメッセージ ユーザーの進捗の喪失 強制的なワークフローの再起動

これらのモーメントは、出力の可変性によりジェネレーティブ AI 対話で頻繁にあるため、デザイナーはこれらをエッジケースではなく中核フローとして扱うべきです。アンハッピーパスの例:

  • 技術的失敗
  • AI が誤ったまたは不完全な応答を返す
  • システムエラーやタイムアウト
  • トークン制限の問題
  • パフォーマンスの劣化
  • ユーザー行動の変動
  • 予期しないクエリ
    • 会話途中のコンテキスト切り替え（会話用にデザインする場合）
    • AI 能力の誤解（例: ユーザーが Duo は自分のコードベースを知っていると思う）
    • 複数の意図を組み合わせた複雑なクエリ（会話用にデザインする場合）
    • システム能力外のリクエスト（例: ユーザーが Duo は自分のコードベースを知っていると思う）

私たちは AI が何を言うかをデザインするのではなく、AI が何を言おうとも、ユーザーがどう作業するかをデザインしています。これらのパターンは出力が予測不可能でも、予測可能でデザイン可能です。

ジェネレーティブ AI のユーザーフローデザインはこのようになります:

  • 理想的なフローをまずマップ
    • ベストケースシナリオをステップごとに定義
    • ユーザーアクションとシステム応答の両方を含める
    • 主要な成功ポイントを特定
  • 起こり得る故障地点を特定
    • AI が誤解する可能性があるのはどこか？
    • システム制限に達する可能性があるのはいつか？
    • ユーザーの期待に応えられない可能性があるのはどこか？
  • 回復経路をデザイン
    • ユーザーが軌道に戻る方法
    • 明確なエラー説明
    • 成功への代替経路
  • フィードバックメカニズムを組み込む
    • ユーザーが問題を伝える方法
    • システムが理解を示す箇所
    • 修正または洗練する方法

理想的な出力を定義する

ジェネレーティブ AI の出力は非決定的（毎回異なる結果を生成）ですが、理想的な出力を定義することは、プロンプトエンジニアリングとインタラクションデザインの両方にとって重要です。理想的な出力の明確な定義により、生成間のユーザーの UX を合理化します。これらの定義は、プロンプト内でモデルに指示する方法とユーザーインタラクションをデザインする方法も形作ります。

定義する主要な要素

  • 出力構造
    • 長さ（文字制限、段落数）
    • フォーマット（JSON、Markdown、プレーンテキスト）
    • 構造（ヘッダー、セクション、箇条書き）
    • スタイル（フォーマル、カジュアル、技術的）
  • コンテンツ要件
    • 不可欠な情報（コアデータポイント、主要メトリック）
    • 必要なデータポイント（あれば、技術仕様、引用）
    • 必要な詳細レベル（要約 vs 詳細）
    • 正確性のニーズ（事実確認、検証）

例: 自動 API ドキュメント生成ツールを構築

  • 長さ: 各エンドポイントを 500 文字未満で記述
  • フォーマット: YAML の OpenAPI 仕様
  • 構造: エンドポイント、メソッド、パラメータの標準化されたセクション
  • スタイル: 標準化された用語の技術リファレンスフォーマット

正確な出力は予測できませんが、これらの要素を定義することで、一貫したユーザー体験とより良いプロンプトエンジニアリングを実現できます。Claude、LangSmith、またはローカルで理想的な出力を作成する実験をしてみてください。 {link to docs}

LLM ジャッジ評価

加えて、LLM が提供する回答をどう評価するかをチームと議論し始めてください。チームは最終的に LLM 評価用のデータセットが必要になります。データセットには早期に取り組むのが最善です。これにより、LLM に提供する（またはユーザーが LLM に提供する）と予想されるプロンプトの種類と、許容される回答について考えざるを得なくなります。チームが少なくとも予備データセットを自信を持って作成できない場合、ユーザーリサーチやその他のデータマイニングがこのステップに役立ちます。このステップはクロスファンクショナルなステップで、理想的にはすべてのチームメンバーの意見を取り入れます。

デザイン中

画面インタラクションをデザインするときは、Pajamas の GitLab Duo パターン を参照してください。

AI のためのその他の優れたインタラクションデザインリソースもあります。私たちのお気に入りの 1 つは Shape of AI です。

ソリューション検証中

どのプロジェクトでも同様に、ソリューションにどの程度自信があるか自問し、自信があまりない場合は、開発にコミットする前にユーザーで検証することをお勧めします。リサーチクエスチョンに最適な検証方法を選択する必要があります。

ジェネレーティブ AI ソリューション検証には、2 つの異なるテスト可能性があります:

  • 低忠実度または静的 Figma プロトタイプ（高度にモデレートされた）
  • インタラクティブな LLM プロトタイプ（できればモデレートなし）

低忠実度（Figma）プロトタイプを使用している場合

プロトタイピングツールが構築されるまで、ほとんどのソリューション検証は低忠実度プロトタイプの形式で行われます。これはプロセスの早い段階で発生するべきです。

モデレートされたテストから始めることで、ユーザーがワークフローのコンテキストでソリューションにどう関わるかを理解できます。LLM とどう対話することを期待しているかについての前提もテストできます。Figma プロトタイプでハッピーパス（と事前決定された出力）を示すソリューションをモックアップします。

セッション中、デザインを示す前にユーザーの現在のワークフローを理解することを目指します。ワークフローを理解したら、ソリューションの Figma プロトタイプを見せます。

LLM は言語によって制御される対話型ツールで、非線形なエンゲージメントのための複数の経路を提供することを思い出してください。Figma プロトタイプは線形で、可能性の幅を提供しません。期待される生成応答の理想となる複数のモック出力を示す準備をしてください。

Figma プロトタイプはユーザーのクエリへの応答を生成していないため、参加者にボタンや事前決定された出力からの結果を表示する前に、意図したクエリと期待される応答について声に出して考えてもらう必要があります。出力を見せた後、出力とその反応について話し合う時間を取り、期待に応えているかを判断します。

たとえば「Issue を要約すると入力したと仮定しましょう」と言って結果へのフィードバックを求める代わりに、質問をオープンエンドでユーザー主導に保ちます。参加者に「このフィールドに何を入力しますか？」「なぜ？」と尋ねます。その後、結果を見せます。それからモック出力へのフィードバックを求めます。「この応答についてどう思いますか？」「あなたが入力したものから何を期待しますか？」

会話を通じて、ユーザーが制御を望む箇所、信頼の懸念を表す箇所、または AI 出力を編集したい箇所を注意深く観察します。これらは AI インターフェースにおける重要な摩擦点だからです。

セッションは常に採用の可能性と潜在的なデールブレイカーについて尋ねて締めくくります。ユーザーはセッション全体を通じて肯定的なフィードバックを提供しても、最終評価で重要な採用障壁を明らかにすることがあるからです。

これらのセッションは、出力を改善し、ユーザー行動により合うようにプロンプトを調整することにつながる可能性が高いです。

ソリューションを検証していて、インタラクティブな LLM プロトタイプがある場合

または、ユーザーがライブでテストしてフィードバックを提供できる機能がある場合、モデレートなしテストが理想的です。ユーザーに完了してほしいタスクを定義し、必ずセッションを録画します。

モデレートなしセッション中、以下に注意してください:

  • ユーザーのメンタルモデル
    • ユーザーがリクエストをどう組み立てるか
    • AI がコンテキストを理解することを期待するのはいつか
    • 存在しない能力をどこで仮定するか
    • 誤解からどう回復するか
  • インタラクションパターン
    • 自然な入力 vs プロンプトされた入力
    • 異なる AI 出力スタイルへの反応
    • ユーザーが放棄して再起動するのはいつか
    • 可変的な出力をどう処理するか
  • 信頼のシグナル
    • ユーザーが情報を検証する箇所
    • AI 応答を疑うのはいつか
    • システムへの信頼をどう構築するか
    • 信頼の破綻を引き起こすものは何か
  • タスク完了
    • ユーザーが目標を達成するか
    • 成功への代替経路を見つけるか
    • 人的介入が必要なのはいつか
    • AI を他のツールとどう組み合わせるか
  • 回復行動
    • AI が失敗したときユーザーが何をするか
    • どう言い換えたり再試行するか
    • 完全に諦めるのはいつか
    • 制限を回避する方法

MR レビューや UX スコアカードのためのガイダンス

MR レビューや UX スコアカードを行うとき、ワークフローをライブでテストすることがよくあります。

UX テストは、評価が見逃す可能性のある潜在的な問題をデザイナーが特定することを確保します。UX テストの焦点は、モデルの正確性ではなく、モデルとインターフェースが異なる入力、失敗、エッジケースをどれだけうまく処理するかにあります。

  • UX テスト
    • インターフェースとの対話方法に焦点
    • 特定の機能、ワークフロー、ハッピーパス、アンハッピーパスをテスト
    • ユーザビリティの問題と摩擦点を特定
    • インタラクションパターンの洗練に役立つ
  • LLM 評価
    • AI システムのパフォーマンスと出力を評価
    • 応答の正確性と有用性を測定
    • バイアスとエラーをチェック
    • ビジネス要件に対して検証
    • モデル動作の改善に役立つ

UX テストは、ステークホルダーが AI 対話をナビゲートするためのユーザーの行動、戦略、メンタルモデルをよりよく理解する助けとなります。

たとえば、LLM 評価では AI が関数を効率的にリファクタリングしたかを測定するかもしれませんが、UX テストでは開発者がリファクタリング目標を反復的にどう記述し、提案されたコード変更をどう解釈し、マージ競合をどう処理し、AI の推奨を信頼するか検証することを学ぶかを検証します。

新しいジェネレーティブ AI 機能の UX テストを行うには、プロジェクトの開始時に作成したデータセットに戻ります。そのデータセットを使ってソリューションのパフォーマンスをテストします。会話機能をテストする場合、データセットに関連するフォローアップ質問を尋ね、モデルが適切なコンテキストを保持し正しく応答するかを確認する必要があります。

UX テストには、ハッピーパスとアンハッピーパスのテストを含めるべきです。

  • データセットからさまざまな入力を試す
  • ハッピーパスとアンハッピーパスをマップ
  • ユーザビリティの問題を文書化
  • 摩擦点を特定

エッジケースをテスト:

  • 空または最小限の入力
  • 極端に長い入力
  • 特殊文字／フォーマット
  • レート制限の境界
  • システムエラー／タイムアウト
  • 複数の素早いリクエスト
  • コンテキストの切り替え（会話ソリューション用）
  • 不完全なクエリ

データセットを使った UX テストフローの例:

  • テストプロンプトを入力
  • AI の応答をレビュー
  • インタラクションパターンをメモ
  • 会話ソリューションをテストしているならフォローアップ質問
  • エラーシナリオをテスト
  • 回復経路を文書化

リンクとリソース

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License