会話型チャットUIシステム

会話型チャットUIシステム は何をしますか？

目的

会話型チャットUIシステムは、永続的なオンページチャットウィジェット、ライブサポートダイアログ、自動化されたチャットボットインターフェースを設計および構造化するための体系的な方法論を提供します。チャットウィンドウは高度にインタラクティブで、コンテンツ密度が高く、空間的に制約されているため、アクセシビリティとユーザビリティの深刻な障害が発生しやすくなっています。

このシステムは、非同期メッセージングオーバーレイのビジュアルおよび構造的な設計課題を解決します。メッセージストリームが非常に読みやすく、インタラクティブトリガー（クイックリプライ、アクションカード）がアクセス可能であり、支援技術ユーザーにフォーカスの中断なしに新しいメッセージが通知され、モバイルオーバーレイがシステム仮想キーボードやセーフエリアに完全に適応することを保証します。

ユースケース

• ライブチャットサポートパネル: 人間のカスタマーサポート担当者との直接コミュニケーションを可能にする永続的なウィジェット。
• 自動化されたAIチャットボット: オンボーディング、トラブルシューティング、製品発見を通じてユーザーをガイドするアプリ内またはサイト上の自動アシスタント。
• トランザクショナル会話型フォーム: インタラクティブな会話として設計された段階的なフォーム完了。
• フローティングヘルプセンターウィジェット: ビューポートに固定されたオーバーレイで、サポート記事を検索し、ライブチャットスレッドにフォールバックします。

使用すべきでない場合

• 専用メール/インボックスアプリケーション: Gmail、Slack、Zendesk Agent Workspaceなどの大規模な全画面コミュニケーションダッシュボード。高密度のマルチペインレイアウトが必要な場合は、dashboard-layout-system を使用してください。
• グローバルページナビゲーション: 永続的なサイトディレクトリをチャットベースのサイトマップに置き換えないでください。補助的なオプションとしてのみ使用可能です。その場合は site-navigation-system を使用してください。
• 複雑な階層コメント: ネストされたスレッド応答を含むブログや記事のコメント。comment-and-discussion-system を使用してください。

入力

1. 会話シナリオ: 主要なフローのマッピング（ユーザー主導 vs システムトリガー、ボット vs エージェントの引き継ぎ）。
2. ビジュアルスタイルとパレット: 背景サーフェス、送信/受信バブル、ステータスドット、フォーカスインジケータのデザイントークン（accessible-color-system および focus-indicator-design-system から）。
3. タイポグラフィスケール: コンパクトなレイアウト向けの流動的で読みやすいタイポグラフィルール（fluid-typography-system から）。
4. トリガーメトリクス: チャットランチャーボタンや自動ウェルカムメッセージがアクティブになるタイミングを決定するスクロールおよびイベントのしきい値。
5. インタラクティブメディアアセット: ファイル添付オプション、画像プレビューテンプレート、カスタムクイックリプライ形式。

出力

1. チャットウィジェットレイアウト仕様: フローティングランチャーとドッキングパネルの正確なピクセル/rem境界。
2. メッセージスレッド構造: 送信者タイプを区別するコンポーネント間隔、タイポグラフィの太さ、カラーマッピング。
3. レスポンシブモバイル設計図: デスクトップのフローティングパネルをモバイルの全高引き出しに変換するトランジションルール。
4. インタラクティブ状態マトリックス: メッセージバブル、テキストエリア、アクションチップ、ローディング状態の視覚的フィードバックマップ。
5. アクセシビリティランドマーク設計図: ARIAロール（role="log"、aria-live="polite"、aria-busy）とキーボードタブパスのマップ。

---

ワークフロー

1. フローティングランチャー（FAB）の配置

フローティングチャットトリガーボタンは主要なエントリポイントであり、ページの主要な本文項目をブロックせずに永続的に表示される必要があります。

• 標準配置: ランチャーをビューポートの右下隅にドッキングします（RTLレイアウトの場合は左下）。
• デスクトップグリッドオフセット: ランチャーをビューポートの下端と側端からそれぞれ 24px オフセットします。
• モバイルグリッドオフセット: コンテンツ領域を確保するため、境界から 16px オフセットします。
• 衝突回避: 「トップに戻る」ボタンや永続的なCookieバナーが存在する場合は、それらを垂直方向に反対側に配置するか、最小 16px の間隔で積み重ねて視覚的な重なりを防ぎます。

2. チャットウィンドウコンテナの構造化

チャットウィンドウコンテナは、インタラクションフレーム全体を収容します。ベースページの上に配置され、標準的な構造階層に従う必要があります。

• ヘッダー（フレームアンカー）: チャット相手（エージェント/ボット）のアバター/ID、運用ステータス（オンラインインジケータ、稼働時間）、およびクイックコントロール（最小化 _、全画面/展開、閉じる X）を含む永続的なバナー。
• メッセージログ領域（スレッドビューポート）: 会話を表示するスクロール可能なボディ。スクロール中は常に表示されるスクロールバーを使用して、無限垂直スクロールを処理する必要があります。
• クイックリプライデッキ（ブリッジ）: 入力バーの真上に配置され、シングルタップでのプロンプト応答を提供する、水平/折り返しのインタラクティブチップブロック。
• 入力バー（下部に固定されたユーティリティ）: テキスト入力エリア、セカンダリユーティリティトリガー（絵文字、ペーパークリップファイル添付）、および主要な「送信」ボタンで構成される永続的なフォームコンテナ。

3. メッセージバブルの構造とリズムの設計

迅速な視認性を確保するため、視覚的および物理的な方向を使用してメッセージを区別します。

• 送信（ユーザー）メッセージ:
  • 配置: 右揃え（RTLでは左揃え）。
  • 色: ブランドのプライマリカラーまたはハイコントラストの暗い背景に白/明るいテキスト。
  • 境界半径: 右下（RTLでは左下）を除くすべての角が丸く、視覚的な「吹き出し」アンカーを作成します。
• 受信（エージェント/ボット）メッセージ:
  • 配置: 左揃え（RTLでは右揃え）。
  • 色: ニュートラルな薄いグレーまたはセカンダリブランドの色合いにハイコントラストテキスト。
  • 境界半径: 左下（RTLでは右下）を除くすべての角が丸くなっています。
• グループ化されたメッセージ: 同じ送信者が複数のメッセージを連続して送信する場合は、それらを近接して（4px ギャップ）積み重ね、送信者名、アバター、タイムスタンプは最後のバブルまたはグループヘッダーにのみ表示します。異なる送信者間では 16px の間隔を使用します。
• システム/アクションメッセージ: スレッド内で中央揃え、小さく、控えめで、フラットで境界線のないテキストとしてスタイル設定され、メタイベントを示します（例：「エージェントがチャットに参加しました」、「チャットのトランスクリプトがメールで送信されました」）。

4. インタラクティブ入力エリアの作成

テキスト入力エリアは、最も摩擦が発生する場所です。ユーザビリティを最大化するように設計します。

• 自動拡張入力: 単一行から始まり（最小 44px の高さ）、ユーザーが入力するにつれて垂直方向に拡張する <textarea> を使用します（最大4〜5行で、内部で垂直スクロールを有効にします）。これにより、長いメッセージも完全に表示されたままになります。
• 入力ボーダーとホバー状態: テキストエリアに明確な境界線（最小 1px、白いチャットボックスに対して最小 3:1 のハイコントラスト）を付けます。ホバー時に境界線のコントラストを高め、アクティブフォーカス時にはハイコントラストのフォーカスリング（最小 2px）をトリガーする必要があります。
• 送信ボタンのアフォーダンス: 送信ボタンは、テキストエリアが空の場合は視覚的に非アクティブ（無効で不透明度が低い）のままにします。文字が入力されると、ボタンをプライマリアクティブカラーに遷移させ、入力準備ができたことを知らせます。

5. モバイルビューポート適応の確立（引き出しシフト）

デスクトップチャットボックスは小さなオーバーレイ（通常 360px 〜 400px 幅、500px 〜 650px 高さ）です。モバイルでは、これらの比率は使用できず、仮想キーボードと競合します。

• 全ビューポート占有: 576px のブレークポイント未満では、チャットコンテナをフローティングパネルから全画面引き出しに遷移させます（width: 100%; height: 100%; top: 0; left: 0; border-radius: 0;）。
• 仮想キーボードセーフエリア: 入力バーが position: sticky; bottom: 0; を使用し、モバイルブラウザの下部アドレスバーと仮想キーボードを考慮して、表示されているビューポートの下部に固定されていることを確認します。
• スクロールリークの防止: 全画面モバイルチャット引き出しがアクティブなときは、body { overflow: hidden; } または標準のタッチインターセプションクラスを使用して、背景の本文スクロールをロックします。

---

決定ルール

• トリガーボタンのサイズ: フローティングランチャーボタンの視覚的な直径は、デスクトップとモバイルの両方で少なくとも 56px とし、インタラクティブなタッチフットプリントは 64x64px として、親指での楽なアクティベーションを保証します。
• 「未読バッジ」の優先順位: パネルが最小化されているときに未読メッセージが到着した場合は、ランチャー上に赤またはブランドカラーの数字バッジを表示します。メッセージが非常に重要な場合は、ランチャーに隣接して一時的で自己消滅するテキストプレビューバブルを 5秒 間表示してから、バッジに折りたたみます。
• 入力中インジケータの表示: エージェント/ボットが入力中の場合は、トリプルドットのバウンスアニメーションを含む永続的なバブルを表示します。このインジケータを最も下の受信メッセージとして配置しますが、実際のメッセージブロックが到着したらすぐに削除します。
• 通知タイミングとオーディオキュー: タブがバックグラウンドにある場合にのみ、着信メッセージに対して控えめで高音のオーディオアラートを有効にします。サウンド通知を完全にミュートするための明確で永続的なトグルをチャットヘッダーに提供します。
• 動的スクロールアンカーリング: ユーザーがチャットログの一番下にいる場合は、スレッドコンテナを自動的にスクロールダウンして新しいメッセージを表示します。ただし、ユーザーが過去の履歴を読むために 上に スクロールした場合は、スクロール位置をロックして不快なジャンプを防ぎ、ビューポートの下部にフローティングの「新しいメッセージ ↓」ピルボタンを表示します。

---

制約

1. アクセシビリティ（WCAG AA準拠）

• ランドマークとARIAロール:
  • メインチャットウィジェットをランドマークコンテナでラップします：<section aria-label="Customer Chat"> または <div role="region" aria-label="Support Chat">。
  • スクロール可能なメッセージログエリアは role="log" と aria-live="polite" を使用する必要があります。これにより、スクリーンリーダーは新しいメッセージが追加されたときにそのメッセージをアナウンスし、ユーザーのアクティブなキーボードナビゲーションやテキスト入力を中断しません。
  • 入力中インジケータバブルは aria-busy="true" を設定し、非表示のテキスト代替を含める必要があります（例：<span class="sr-only">サポートエージェントが入力中です...</span>）。
• キーボードアクセスとフォーカストラップ:
  • 標準の Tab ナビゲーションは、ヘッダーコントロール、スクロール可能なメッセージストリーム、クイックリプライチップ、入力フィールドを論理的な順序で移動する必要があります。
  • モバイルの全画面チャット引き出しが開いているときは、キーボードフォーカスを引き出し内にトラップします。Escape キーを押すと、チャットパネルが即座に最小化または閉じられ、フォーカスがフローティングランチャーボタンに戻る必要があります。
• テキストとコンポーネントのコントラスト:
  • メッセージバブル内のすべてのテキスト（送信と受信の両方）は、それぞれのバブル背景に対して最小 4.5:1 のコントラスト比を満たす必要があります。
  • インタラクティブアイコン（添付クリップ、送信矢印、閉じるX）とフォーム境界は、隣接する背景サーフェスに対して最小 3:1 のコントラスト比を満たす必要があります。

2. レスポンシブ性とレイアウトの維持

• アスペクト比の安定性:
  • メッセージスレッドは、フレキシブルなパーセンテージまたはフレックスグローモデルを使用してコンテナの高さを埋め、テキストのオーバーフローやコンテナの崩壊を防ぐ必要があります。
  • チャットバブル内で送信された画像やカードは、固定アスペクト比または最大幅制限（バブルの幅の max-width: 80%）を持ち、チャットレイアウトの視覚的な破損を防ぐ必要があります。
• レイアウトシフトの防止:
  • 過去のメッセージをロードするとき（例：無限スクロールアップ）、スクロールアンカーリング技術を使用して、アクティブなスクロール位置が下にスナップするのを防ぎ、ユーザーのビューポートを読んでいるメッセージに完全にロックしたままにします。

---

一般的な障害パターン

• 「フォーカスハイジャック」トラップ: ページ読み込み時にチャットウィジェットを自動的に開き、キーボードフォーカスを即座にチャットテキストエリア内にトラップします。これにより、キーボードユーザーとスクリーンリーダーユーザーがメインページのコンテンツを読むのを完全にブロックします。
• 「キーボードによる隠蔽」: モバイルで、入力バーを absolute 座標で配置し、アクティブなタイピング中にデバイスの仮想キーボードがテキストエリアと送信ボタンを覆い隠してしまうこと。
• 「アナウンスされないストリーム」: role="log" または aria-live なしで、新しいメッセージを純粋に視覚的にスレッドに追加し、視覚障害や弱視のユーザーにエージェントが応答したことをまったく知らせないこと。
• 「スクロールジャンプ」バグ: 受信メッセージごとにスクロールビューポートを強制的に絶対的な最下部にジャンプさせ、スレッドの上部にある過去の指示を読もうとしているユーザーの操作を中断すること。
• 「コントラストフェードアウト」傾向: 受信バブルを極薄のグレー背景と細い白いテキストでスタイル設定し、コントラスト比に違反し、通常の環境光の下でテキストを読めなくすること。

---

検証基準

• アクセシビリティランドマークチェック: チャットウィジェットが <section> または role="region" でラップされ、説明的な aria-label が設定されている。
• スクリーンリーダー通知チェック: メッセージスレッドが role="log" と aria-live="polite" を使用しており、受信テキストを動的にアナウンスすることが確認されている。
• コントラスト検証: 送信バブルと受信バブルが 4.5:1 のテキスト対背景コントラスト基準を満たし、フォーム境界が 3:1 基準を満たしている。
• キーボードパス検証: フォーカストラップがモバイルビューポートで正しく機能し、Escape キーを押すとウィジェットが閉じられ、フォーカスがランチャーに戻る。
• モバイル引き出し適応: 576px 未満でパネルがビューポートの高さと幅の100%を占有し、背景ページ本文にスクロールリークがない。
• 最小タッチターゲット: ランチャートリガー、閉じるボタン、送信コントロール、およびクイックリプライチップのインタラクティブフットプリントが少なくとも 44x44px である。
• メッセージバブルのリズム: 同じ送信者からの連続メッセージは 4px のタイトなパディングでクラスタリングされ、送信者の切り替えには 16px の十分なギャップが使用されている。
• 空状態のガード: 入力テキストエリアに空白のみが含まれている場合、送信ボタンは無効になり、視覚的にミュートされている。