非同期検索フィールドのUX：入力文字列と選択を混同しない設計

サーバーから候補を取得する検索フィールドには、似て見えても別々に扱うべきものが3つあります。入力中の文字列、候補一覧で注目している項目、実際に選択したレコードです。これらを混同すると、請求書の画面にはある顧客名が見えているのに、別の顧客IDで送信されることがあります。

まずフォームの各フィールドが受け付ける値と動作を定めます。この例の請求先フィールドが受け付けるのは、既存顧客1件のIDであり、自由な文字列ではありません。検索はそのレコードを見つける手段です。顧客名らしい文字を入力するだけでは、選択したことにはなりません。

一致する文字列だけでなく、レコードを識別できるようにする

架空の請求管理アプリに、Northstar Studio（ID：C-104）とNorthstar Supplies（ID：C-219）という2社が登録されているとします。請求書を作る人が「North」と入力すると、両社が候補に現れます。ドロップダウンには、選択前に両社を区別できるだけの補足情報を、閲覧権限の範囲内で表示する必要があります。

顧客名を主情報として示し、その横に識別に役立つ情報を添えます。この演習では顧客IDで区別できます。実際のサービスでは、表示が許可された所在地や取引先番号の方が分かりやすいかもしれません。検索しやすくするために非公開情報を見せたり、小さなアバターだけで似たレコードを区別させたりしないでください。

Northstar Studioを選んだ後は、フィールドがC-104を表していると分かる状態にします。表示名は後で変わることがありますが、請求先として関連付ける対象は選択したレコードです。その識別情報をどう保持し、後からレコードが利用できなくなった場合にどう対応するかを、プロダクト担当者と開発者で決めます。

検索語、操作中の候補、確定した選択を分ける

最後の状態は、気付きにくい不一致を防ぎます。StudioをSuppliesに書き換えたのに、フォーム内部でC-104を保持したままだと、表示と送信データが食い違います。選択済みレコードを明確な項目として表示して「変更」操作を設けるか、文字列を編集すると以前の選択がいつ無効になるのかを決めます。動作を曖昧にしないことが重要です。

WAI-ARIAのコンボボックスパターン（英語）では、編集可能なフィールド、許容する値、手動または自動で確定するオートコンプリートを区別しています。この記事では、1件のレコードを手動で確定する方式を選びます。複数選択のトークン入力やコマンドメニューすべてに、そのまま適用する仕様ではありません。

候補一覧は、どの検索語への結果かを明確にする

外部から候補を取得すると、応答順序の問題が生じます。「North」でリクエストAを送り、続けて「s」を加えた「Norths」でリクエストBを送ったとします。Bが先に完了し、Aが後から届いても、現在の一覧を古いNorthの結果に戻してはいけません。

この順序をインタラクションの仕様メモに残します。表示する候補と件数は、現在の検索語に対応させます。開発側では古いリクエストのキャンセル、古い応答の無視など、確実な方法を選べます。デザイン側では、読み込み表示を置けば解決すると考えず、利用者から見てどう動くべきかを定めます。

次の検索を読み込んでいる間、以前の結果を残すかどうかも決めます。残せば文脈を維持できますが、新しい検索語の結果と誤認させず、誤って選択されないことが条件です。短い顧客選択では、いったん消す方が単純な場合もあります。どちらにしても、応答前に検索完了後の「顧客が見つかりません」を表示する理由にはなりません。

デバウンスは不要なリクエストを減らせますが、あらゆるデータソース、端末、作業に合う待ち時間はありません。開発者と応答時の動作を調整し、現実的な遅延で試します。デザインファイルで即座に候補が出る、都合のよい状態だけをレビューしないでください。

一致する候補がない場合と、サービス障害では操作を変える

検索が完了し、表示可能な候補がなかった場合は、「『Norths』に一致する顧客はいません」のように具体的に伝え、検索語を編集できる状態にします。検索サービスが利用できない場合は、顧客を読み込めなかったことを伝え、対応していれば再試行の経路を用意します。通信に失敗したことは、顧客が存在しない証拠ではありません。

結果が空というだけで「顧客を作成」を追加しないでください。作成は、権限、必須項目、重複確認のルールを持つ別の操作です。請求管理アプリがその操作に対応するなら、既存顧客の選択と区別し、作成の完了を確認してから元の流れに戻します。

候補が見つからない理由には、アクセス制限もあります。エラーメッセージで非公開レコードの存在を漏らさないようにします。検索対象と返す情報は、利用者に開示してよい範囲に限ります。候補を選択不可に表示するだけでは、アクセス制御にはなりません。

確定と閉じる操作を予測できるようにする

状態と合わせてキーボード操作も記録します。この手動選択方式では、矢印キーで候補を移動し、Enterで操作中の候補を確定し、Escapeでは別のレコードを確定せずにポップアップを閉じます。Tabは採用する実装パターンに沿ってフォーム内を移動させ、候補を一つずつTabで通過させる構成にはしません。

APGの手動選択例（英語）は、操作と意味付けの参考です。そのまま本番で使えばアクセシビリティを保証できるものではありません。完成したコンポーネントを、製品が対応するブラウザーと支援技術で検証します。

通常の文字編集を妨げないことも大切です。カーソル移動、範囲選択、貼り付け、IMEによる文字入力を使えるようにします。特に、変換途中の各キー入力を完成した顧客名として扱ったり、文字を選んでいる最中にショートカットで候補を確定したりしないようにしてください。

結果が更新されても、フォーカスを突然移動させないようにします。操作中の候補が消えた場合は、どう初期化するかを決め、同じ画面位置に来た別レコードへ強調表示だけが残らないようにします。読み込み、件数、失敗は適切に通知しつつ、一時的なリクエストを毎回読み上げて操作を中断させないようにします。

Pixsoでフィールドの状態を順番に確認する

Pixsoのファイルに、請求先フィールドの4つの状態を作ります。Northの入力中、現在の候補一覧、Northstar Studio／C-104の選択済み、再編集して確定済みIDがなくなった状態です。レイアウトは再利用し、状態ごとの文字とフィードバックを変えます。候補にはNorthstar Supplies／C-219も残し、レビューで実際に見分ける必要がある構成にします。

フレームの横にはNorth → Northsのリクエスト順を置き、遅れて届いたNorthの応答を古い結果として示します。これは設計中の請求管理アプリの動作であり、Pixsoエディター自体の機能を示すものではありません。各時点でどのIDが送信されるか、Suppliesと入力するだけで顧客が変わるかを、レビュー担当者に説明してもらいます。

Pixsoで顧客検索の流れを設計する →

選択後も、送信時の検証は必要

選択してから送信するまでに、顧客がアーカイブ、統合されたり、現在の利用者からアクセスできなくなったりすることがあります。最終処理ではサーバー側の検証が必要です。C-104をその請求書に使えなくなった場合は、修正可能な問題を具体的に説明し、方針上許される範囲で、請求書の他の入力項目を保持します。

表示名を更新する処理で、黙って別のIDを選んではいけません。更新に失敗したときも、製品のルールで必要でない限り、有効な選択を消さないようにします。レコードを確認中に最後に確認できた名称を表示してよいかを決め、請求書を確定する前に不確かな状態が分かるようにします。

似た2つの名称、遅い応答、順序が逆転した応答、該当なし、サービス障害、キーボード選択、選択後の編集、送信時に使えなくなったレコードを通して確認します。どのケースでも問うのは同じです。画面のフィールドは、アプリがこれから使うレコードを正しく表しているでしょうか。