.NETやAzure・Microsoft製品で学んだことや気づいたことを共有しよう

@tomokusaba(Tomomitsu Kusaba)Team Tea & Waterin

Fluent UI 2 の Tag picker を理解する — ガイダンス・レイアウト・アクセシビリティ・コンテンツ設計・Fluent UI Blazor 5 との違い

Last updated at 2026-06-22Posted at 2026-06-22

はじめに

Fluent 2 は、Microsoft が提供するデザインシステムです。Web 向けのコンポーネント実装は Fluent UI React v9（@fluentui/react-components）として提供されており、このシリーズでは両者を合わせて Fluent UI 2 と呼んでいます。単に見た目を整えるだけではなく、入力、選択、ナビゲーション、状態変化を、アクセシビリティと一貫した内容設計のもとで扱うことを重視しています。

今回取り上げる Tag picker も、その考え方をよく表すコンポーネントです。ユーザーはテキストを入力しつつ候補から選び、選択結果はタグとして見える形で残します。つまり、Tag picker は「入力欄」ではなく、「選択した内容を理解しやすく、操作しやすく、後から見直しやすくするための UI パターン」です。

この記事では、Fluent 2 の公式ガイダンスに沿って、Tag picker の役割、レイアウト、アクセシビリティ、そしてコンテンツの説明にフォーカスして整理します。参考にしたのは Fluent 2 の Tag picker ガイダンスと、Fluent UI Blazor 5 のデモサイトです。さらに、Fluent UI Blazor 5 との比較も含めて、どこまでが設計として共通で、どこからが実装上の差分になるのかを確認します。

Fluent UI 2 とは

Fluent UI 2 は、Fluent UI の次の設計思想として位置づけられるものです。React での実装ガイダンスが中心に見られますが、コンポーネント単位の使い方や、レイアウト、アクセシビリティ、コンテンツの書き方まで含めて、デザインシステムとしての考え方を学びやすい構成になっています。

特に重要なのは、UI を「部品」として並べるのではなく、「どのような情報を、どのような順序で、どのような操作を通して理解してもらうか」を設計対象にしている点です。たとえば Tag picker では、候補の選択、入力、削除、選択済み内容の可視化が同時に扱われます。単一の部品として考えるより、入力体験を一つの相互作用として捉えるほうが自然です。

これまでの Fluent UI 2 シリーズ記事

このシリーズでは、Fluent UI 2 の各コンポーネントを、実装の前に「何を解決するための UI なのか」を意識して整理してきました。これまでの主な記事は、次のとおりです。

こうした記事の流れの中で、Tag picker は「選択内容を見える形で保持しながら、入力と候補選択を切り替える UI」として位置づけられます。

Tag picker が解決するもの

Tag picker の価値は、単に選択肢を増やすことではありません。ユーザーが何を選び、何をまだ選んでいないのかを、視覚的に把握しやすくすることです。たとえば、関係者選択、ファイル選択、会議名選択、ラベル付けなどでは、選択済みの内容をタグとして残すことで、入力の途中でも「今の状態」を理解しやすくなります。

選択肢の多いフォームや、後から内容を見直したい場面に特に向いています。次のセクションでは、具体的にどのような振る舞いが設計されているかを確認します。

ガイダンス

Fluent 2 の公式ガイダンスでは、Tag picker は「テキスト入力」と「ドロップダウン」を組み合わせたコンポーネントです。ユーザーは候補から選ぶこともでき、必要に応じて自分の入力値を追加することもできます。選択結果はタグとして表示され、入力欄の中で選択済み内容を常に見える状態にします。

Tag picker を使うときに大切なのは、対象が「短い選択値の集まり」であることです。長文の入力や、自由記述を前提にしたフォームでは、Tag picker が最適とは限りません。むしろ、候補が明確で、複数選択を見える形で持ちたいときに向いています。

公式ガイダンスでは、次のような振る舞いが示されています。

ドロップダウンを開いて候補を選ぶ
入力中に候補を絞り込む
キーボードでも選択しやすいように操作性を持たせる
追加の操作として「Clear all」などの二次アクションを入れられる

このため、Tag picker は「候補を探す UI」だけではなく、「候補を選んだ後に、その結果をどのように保持するか」を含む、比較的高い認知負荷を持つ入力パターンです。導入するときは、選択対象が本当に複数で、かつタグとして見えるほうが理解しやすいかを確認するとよいでしょう。

次に、こうした振る舞いを支えるレイアウト設計の考え方を確認します。

レイアウト

Tag picker のレイアウトでは、選択済みのタグが入力欄内に自然に収まることが重要です。Fluent 2 のガイダンスでは、タグはデフォルトで折り返して表示され、必要に応じて入力欄の高さが伸びる構成が示されています。これは、選択数が増えても画面が乱れず、選択内容を見失わないための設計です。

設計上のポイントは次のとおりです。

タグのラベルは短く、要点が一目でわかるようにする
文字数が長すぎると、レイアウトが崩れやすいので、必要に応じて truncate などの表示方法を使う
タグが増えたときに、入力領域と候補表示が見えなくならないようにする
選択済み内容と候補の表示が、同じ視覚階層に混ざらないようにする

Tag picker は見た目の「詰め込み」よりも、選択済み内容を見失わないことが重要です。特に、複数のタグを並べる場面では、ラベルの長さ、改行の挙動、余白の取り方が UX に直結します。

レイアウトが整っても、操作が伝わらなければ意味がありません。次はアクセシビリティを見ていきます。

アクセシビリティ

アクセシビリティは、Tag picker を実装するうえで最も注意したいポイントです。Fluent 2 の公式ガイダンスでも、入力欄に明確な名前を付けること、そして削除操作をユーザーに伝えることが強調されています。

まず、入力欄には aria-label のような明確な名前を付けるべきです。これは、スクリーンリーダーに「この入力欄は何のためのものか」を伝えるための基本です。Tag picker は単なるテキストボックスではなく、候補選択と選択済み内容の管理を行う入力要素なので、ラベルだけでなく、その目的が自然に伝わる名前にしておきたいです。

次に、削除操作は見落としやすいです。Fluent 2 のガイダンスでは、入力にフォーカスした状態で Backspace を押すと直前のタグが削除される挙動があるため、この動作をユーザーへ伝えておくべきだと説明されています。これは、タグが見えているだけでは「どのように消すのか」が分かりにくいという現実に起因しています。

さらに、キーボード操作の整合性も重要です。候補の絞り込み、矢印キーによる移動、Enter キーでの選択、Escape での閉じる動作などが一貫していると、支援技術を使うユーザーだけでなく、一般のキーボードユーザーにとっても扱いやすくなります。特に、Tag picker は候補一覧と入力欄が結びついているため、フォーカス移動と選択状態の伝達が曖昧だと、操作の意図が伝わりません。

Tag picker を実装する際に、アクセシビリティを後から足すのは難しいです。入力欄の名前、キーボード操作、削除動作、選択結果の読み上げを、最初から設計に含めるべきです。

操作性と合わせて重要なのが、タグそのものが伝える内容です。次に、コンテンツの設計について整理します。

コンテンツの説明

Tag picker で最も見落としがちなのが、コンテンツそのものの説明です。Fluent 2 のガイダンスでは、Tag picker が「タグとして表示される選択内容」を扱うことが中心ですが、実際に重要なのは、そのタグがユーザーにとってどのような意味を持つかです。ラベルが曖昧だと、タグを見たときに「何が選ばれているのか」が伝わりません。

コンテンツ設計で意識したいポイントは次のとおりです。

タグのラベルは、内部 ID ではなくユーザーが見て理解できる文言にする
役割が異なる情報は混ぜない（人名・部署名・ファイル名などは用途に応じて分ける）
すでに選ばれている内容が、候補一覧の内容と整合していることを確認する
追加・削除・クリアの操作ラベルが、目的に合った言葉になっていることを確認する

たとえば、担当者選択の UI で「User-001」や「IT-03」のようなコードをタグにしてしまうと、視覚的には選択済みのように見えても、内容の意味が伝わりません。人名や部署名、役職名のように、ユーザーが文脈を理解しやすい語を使うほうが自然です。

また、Tag picker は「その場で選んだ内容を保持する」ため、コンテンツの説明責任が比較的大きいです。選択した内容を一時的に残すだけでなく、後から見直したときに、その意味が失われないようにする必要があります。これは、アクセシビリティと同じく、UI の構造ではなく、情報の意味設計に関わる話です。

Fluent UI Blazor ではどうか

ここまで Fluent 2 の設計観点で Tag picker を整理しました。最後に、Fluent UI Blazor 5 との関係を確認します。

Fluent UI Blazor 5 の公式デモサイトでも、Fluent 2 のコンポーネントを意識した構成は確認できます。しかし、Tag picker については、Fluent UI Blazor では直接的な相当コンポーネントとして見当たりません。

特に重要なのは、Fluent UI Blazor では Tag そのものが見当たらない点です。Fluent 2 の設計上、Tag picker の前提には「選択結果をタグとして表現する」という考え方がありますが、Blazor 側ではその概念がそのまま提供されていないため、実装は別途組み合わせる必要があります。

観点	Fluent UI 2 (React)	Fluent UI Blazor 5
位置づけ	設計ガイダンスと React 実装	Blazor 向けコンポーネント実装
Tag / Tag picker	公式ガイダンスあり	直接の相当コンポーネントは存在しない
実装方針	そのまま使うか、要件に合わせて調整	テキスト入力・候補表示・タグの見た目を自前で組み合わせる

そのため、Blazor で Tag picker の体験を作る場合は、TextField や Combobox などの入力系コンポーネント、Listbox や Popover 系の候補表示、そして選択済み要素の表示を組み合わせる形になります。Fluent 2 の設計意図を理解したうえで、実装の粒度を分解することが大切です。

まとめ

Fluent UI 2 の Tag picker は、入力と選択を一つの流れとして扱うためのコンポーネントです。候補を選び、入力し、選択結果をタグとして残す。こうした一連の動作は、単なるフォーム入力よりも、ユーザーの理解を支える性質を持っています。

特に重要なのは、ガイダンスだけでなく、レイアウト、アクセシビリティ、コンテンツの説明までを一貫して設計することです。タグの見た目、削除操作、入力欄の名前、選択内容の意味を、いずれもユーザーが自然に理解できるようにする必要があります。

Fluent UI Blazor 5 では、Tag picker の直接的な相当コンポーネントは見当たらないため、実装は自前で組み合わせる必要があります。その分、Fluent 2 の思想を理解していることが重要です。Tag picker を導入するときは、見た目の再現だけではなく、操作性・支援技術・情報の意味をまとめて考えることが、結果としてより良い UI につながります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up