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

Fluent UI 2 の Input を理解する — Textarea・Fluent UI Blazor TextInput / Number 比較とアクセシビリティ

Last updated at 2026-07-04Posted at 2026-06-11

はじめに 🌟

Fluent UI 2 の Input は、短い自由入力を受け取るための基本コンポーネントです。見た目としてはシンプルですが、実際には「1 行で済む入力なのか」「複数行に分けるべきか」「ラベルと補足をどこに置くか」「支援技術にどう伝えるか」といった判断が詰まっています。

今回の記事では、まず Fluent UI 2 とは何かを短く整理したうえで、Fluent UI 2 の Input と Fluent UI Blazor 5 の FluentTextInput を比較します。あわせて、複数行入力の Textarea / FluentTextArea、数値入力の FluentNumberInput<T> まで広げて、入力コンポーネントの使い分けをまとめます。

以前書いた Field の記事は「入力欄をどう説明するか」が主題でした。この記事はその続きとして、「入力欄そのものをどう選ぶか」を主題にしています。

Fluent UI 2 とは

Fluent UI 2 は、Microsoft の Fluent 2 デザインシステムに沿って UI を組み立てるためのコンポーネント群と設計指針です。単に見た目をそろえるだけではなく、入力のしやすさ、情報の優先順位、キーボード操作、支援技術での読みやすさまで含めて考えるのが特徴です。

そのため Input も、単なるテキストボックスではありません。
「短い自由入力を受け取る部品」として定義されており、1 行で十分な内容を入れるのか、複数行に広げるべきか、補助文言は label と helper text のどちらに置くべきかまで含めて設計します。

この Fluent UI 2 シリーズでは、こうした観点を 1 コンポーネントずつ整理しています。現時点で公開済みの関連記事は次のとおりです。

入力系の判断は単体で完結しにくいので、Field、Combobox、Dropdown に加えて、アクセシビリティの 2 本もあわせて読むと、フォーム全体の見方が揃いやすいです。

今回のゴール ✅

✅ Fluent UI 2 の Input が担う役割を理解する
✅ Fluent UI 2 Input と Fluent UI Blazor 5 FluentTextInput の違いを整理する
✅ Textarea / FluentTextArea / FluentNumberInput<T> の使い分けを把握する
✅ レイアウト、アクセシビリティ、文言設計の注意点を押さえる
✅ 特に placeholder、label、helper text の関係を実務に落とし込めるようにする

Input とは

Fluent UI 2 の公式 Usage では、Input は short, free-form text data を受け取るコンポーネントと説明されています。
つまり、短い 1 行の文字入力が基本です。

たとえば次のような入力は Input が向いています。

氏名
検索キーワード
メールアドレス
URL
電話番号

逆に、コメントや説明文のように 複数行になる前提の内容 は Textarea を選ぶべきです。ここはかなり重要です。見た目だけで同じ「入力欄」に見えても、想定する内容量が違います。

また公式ガイドでは、Input の幅は「利用者に入力してほしい内容の長さに合わせる」とされています。郵便番号や都道府県コードのように短い値を入れる欄と、氏名や検索語を入れる欄では、同じ幅にしないほうが自然です。

Mask の考え方

Fluent UI 2 の Usage では、入力に mask や custom type attributes を使えることにも触れられています。
ただし、ブラウザー由来の表示やフォーマットは Fluent のデザイン言語とそろわない場合があります。

そのため、見た目だけで「入力は正しいはず」と考えず、マスクは補助、意味の説明は label / helper text、妥当性確認は validation と役割を分けて考えたほうが安全です。

Fluent UI 2 と Fluent UI Blazor 5 の対応

最初に結論を書くと、名前はかなり違います。

役割	Fluent UI 2（React）	Fluent UI Blazor 5
📝 単一行の文字入力	`Input`	`FluentTextInput`
📄 複数行の文字入力	`Textarea`	`FluentTextArea`
🔢 数値入力	`Input` の `type="number"` で扱うのが基本	`FluentNumberInput<T>`
🧱 ラベル・補足・検証文	`Field`	`FluentField`、または各入力の `Label` / `Message`

つまり、Blazor 側には Input という名前の 1 対 1 対応コンポーネントがあるわけではなく、単一行は FluentTextInput、複数行は FluentTextArea、数値は FluentNumberInput<T> に分かれています。

ここを曖昧にすると、「React の Input と Blazor の何を比べているのか」がぶれます。この記事では、単一行入力の比較対象を FluentTextInput として扱います。

Fluent UI 2 Input と Fluent UI Blazor TextInput の比較

両者は同じ Fluent 2 の思想を共有していますが、API と役割の分け方には差があります。

観点	Fluent UI 2 `Input`	Fluent UI Blazor 5 `FluentTextInput`
📦 主な用途	1 行の短い自由入力	1 行の短い自由入力
🧩 実装単位	`Input` を `Field` と組み合わせることが多い	`Label` / `Message` を自身でも持てる
🎛️ 入力種別	`type` 属性で変える	`TextInputType` で変える
⏱️ 入力反映	React のイベント処理で制御	`Immediate` / `ImmediateDelay` / `ChangeAfterKeyPress` がある
🧷 補助 UI	`contentBefore` / `contentAfter` など	`StartTemplate` / `EndTemplate`
🪪 マスク	ブラウザー由来や独自実装を意識する	`MaskPattern` が用意されている
♿ アクセシビリティ	placeholder を主情報にしない	`Label` / `AriaLabel` / `Message` を分けて持てる

React 側は Input を中心に、周辺の説明は Field で包む考え方が分かりやすいです。
Blazor 側は、入力コンポーネント単体でも Label や Message を持てるので、フォーム部品として自己完結しやすい印象があります。

実装イメージ

import { Field, Input } from "@fluentui/react-components";

export function ProfileInput() {
  return (
    <Field
      label="表示名"
      hint="この名前がプロフィールに表示されます"
    >
      <Input placeholder="例: 草場 友光" />
    </Field>
  );
}

<FluentTextInput Label="表示名"
                 Placeholder="例: 草場 友光"
                 Message="この名前がプロフィールに表示されます"
                 @bind-Value="@DisplayName" />

@code {
    string? DisplayName;
}

どちらも似た UI を作れますが、React は Field と Input の分担、Blazor は 1 コンポーネント内のプロパティ設計、という違いがあります。

入力コンポーネントの使い分け

先に全体像を書くと、判断は次の表でだいたい足ります。

迷ったとき	Fluent UI 2	Fluent UI Blazor 5	理由
1 行で終わる短い文字列	`Input`	`FluentTextInput`	氏名、検索語、メールアドレスのような単一行入力だから
複数行の文章	`Textarea`	`FluentTextArea`	コメント、説明、問い合わせ内容など長文向けだから
数値	`Input type="number"`	`FluentNumberInput<T>`	数値として制約や範囲を扱いたいから
入力欄の意味や補足を伝えたい	`Field` と組み合わせる	`FluentField` または `Label` / `Message`	ラベルと補足を常に見える状態にできるから

Input / TextInput

Input / FluentTextInput は、1 行の短い文字列を受け取るための標準です。
検索、氏名、メールアドレス、電話番号、URL のように、改行を前提にしない値に向いています。

Blazor 側で特に見ておきたいのは TextInputType です。
Email、Telephone、Url、Password、Search などに分けられるので、入力値の意味に合わせて選ぶと、モバイルキーボードやブラウザー支援が自然になります。

また、Immediate や ImmediateDelay はライブ検索のような場面で便利です。React 側でも同じことはできますが、Blazor はそのためのパラメーターが明示されています。

Textarea / TextArea

ここは特に大事です。

Textarea / FluentTextArea は、長い自由入力を前提にしたコンポーネントです。
コメント、問い合わせ内容、備考、説明文、チャットメッセージのように、1 行では収まらない内容はこちらに寄せるほうが自然です。

Fluent UI 2 の公式 Usage では、Textarea は既定で resizable ではなく、内容があふれたらスクロールするとされています。
つまり、ブラウザー既定の <textarea> の感覚で「とりあえず伸ばせるはず」と思い込まないほうが安全です。

Blazor 側では、この違いをかなり細かく調整できます。

観点	`FluentTextArea` で見たいもの	実務での意味
📏 サイズ	`Width` / `Height`	想定する文章量に合わせて初期サイズを決める
↕️ リサイズ	`Resize`	利用者にどこまでサイズ変更を許すかを決める
🪄 自動伸長	`AutoResize`	入力量に応じて高さを伸ばしたいときに使う
⏱️ 送信契機	`ChangeAfterKeyPress`	Enter / Ctrl+Enter 送信のような UI を作れる
✍️ 即時反映	`Immediate` / `ImmediateDelay`	下書き保存や文字数表示に向く

私としては、Textarea は「ただ長文を入れられる欄」ではなく、どれくらい書いてよいかを UI で予告する欄として考えるのが大切だと感じます。初期高さが小さすぎると、利用者は「ここに長く書いてよいのか」を迷いやすいです。

Number / FluentNumberInput

Blazor 側の FluentNumberInput<T> は、入力系の中でも役割がかなり明確です。
文字列としてではなく、数値として扱いたい値を入れるときに使います。

観点	`FluentNumberInput<T>`
🔢 用途	個数、金額、割合、件数、しきい値など
📐 制約	`Min` / `Max` / `Step`
🌍 文化圏	`Culture`
🔼 補助操作	`StepButtons`
🏷️ 説明	`Label` / `Message` で単位や範囲を補足

ここで重要なのは、Fluent UI 2 の公式 Input Usage は基本的にテキスト入力の説明だという点です。
そのため、Blazor の FluentNumberInput<T> は対照的な実装例として見るのが自然で、React 側に同名の専用コンポーネントがあるわけではありません。

数値入力では、単に type="number" にすれば終わりではなく、単位、最小値、最大値、刻み幅を常に見える形で示したほうが安全です。
特に Culture は小数点や桁区切りの解釈に関わるので、多言語 UI では見落としにくいポイントです。

レイアウト

Fluent UI 2 の公式 Usage では、Input は standalone、full-width block、inline with text の形で使えるとされています。
ただし、自由に置けることと、何でも同じレイアウトにしてよいことは別です。

幅の考え方

公式ガイドに沿って整理すると、入力欄の幅は期待する入力内容の長さに合わせるのが基本です。

入力例	幅の考え方
郵便番号、件数、しきい値	狭めでもよい
氏名、メールアドレス	中くらいが自然
検索欄、URL、備考	広めのほうが扱いやすい
Textarea	文字数ではなく文章量に合わせて高さも考える

Blazor 側では Width、Height、LabelPosition、LabelWidth を使えますが、まずは上ラベル + 自然な幅から始めるのが無難です。
横並びの省スペース化は便利ですが、入力欄は説明とセットで読むものなので、詰め込みすぎると理解しづらくなります。

Inline の扱い

Input をテキストの途中に置く構成自体は可能です。
ただし、入力欄は文章と違ってフォーカス、エラー、補足文の都合があるので、フォーム用途では standalone にしたほうが読みやすい場面が多いです。

特に Textarea は、本文の途中に差し込むより、ラベル、補足、本文入力エリアを縦方向に並べるほうが自然です。

アクセシビリティ ♿

ここは最重要です。

Fluent UI 2 の Input / Textarea Usage では、どちらも placeholder を必須情報に使ってはいけない ことがはっきり書かれています。
理由は明確で、placeholder をラベルの代わりに使うと、入力した瞬間に消えてしまい、利用者がその入力欄の意味を認知できなくなりやすいからです。これは認知的な負荷を上げやすく、支援技術にとっても不安定です。

1. placeholder は補助、label は本体

守りたい原則は次の 3 つです。

placeholder だけで入力の目的を説明しない
placeholder を使うなら必ず label と組み合わせる
必要な入力ルールは helper text や message に置き、常に見える状態にする

これは Input でも Textarea でも同じです。

2. `aria-label` を忘れない

公式ガイドでは、placeholder text は assistive technologies のために aria-label と関連付ける必要があるとも書かれています。
つまり、見た目だけ整っていても、支援技術に名前が伝わらなければ不十分です。

Blazor 側でも AriaLabel があるので、視覚ラベルと支援技術向けラベルを分けて考えられます。
ただし、まずは見える label を用意し、そのうえで必要に応じて AriaLabel を補うのが基本です。

3. 入力種別を意味に合わせる

単一行入力でも、全部を単なる text として扱うのはもったいないです。

メールアドレスなら email 系
電話番号なら telephone 系
URL なら url 系
検索なら search 系
数値なら numeric / number 系

こうしておくと、ブラウザーやモバイル端末が入力を補助しやすくなります。
アクセシビリティは「読み上げ属性を足すこと」だけではなく、適切な入力型を選ぶことでも改善します。

4. Textarea は「見える量」もアクセシビリティ

Textarea はラベルだけでなく、どれだけ書けそうに見えるかも大事です。
初期高さが極端に小さいと、長文を受け付ける意図が伝わりにくくなります。オーバーフロー時のスクロールや resize の扱いも、入力のしやすさに直結します。

5. Number は単位と範囲を可視化する

数値入力でよくある問題は、「何の数値か」「どこまで許されるか」が見えないことです。

Label で値の意味を示す
Message や helper text で単位を示す
Min / Max / Step を UI 上の説明とそろえる

ここがずれると、入力自体はできても、利用者は正しい値を判断しづらくなります。

placeholder は便利ですが、ラベルの代わりにはなりません。入力した瞬間に消えるため、その欄が何を求めていたのかを見失いやすくなります。
特に Textarea と Number では、入力ルールを placeholder に押し込むと、見失った瞬間に迷いやすくなります。

コンテンツの考え方

Input 系コンポーネントは、見た目よりも周囲の文言で使いやすさが大きく変わります。

Label

ラベルは短く、何を入れる欄かが一読で分かる名詞句が向いています。

表示名
検索
メールアドレス
電話番号
コメント
最大再試行回数

長い説明文を label に入れるより、主語は短く、条件や制約は helper text に逃がしたほうが読みやすいです。

Placeholder

placeholder は短い補助ヒントにとどめるのが基本です。
Fluent UI 2 の公式ガイドでは、フォーマット例や短い補足に使うことが勧められています。

また、placeholder text の末尾にピリオドを付けないことも明示されています。

場面	よい例	避けたい例
🔎 検索	`キーワード、ファイル名、担当者名で検索`	`使いたい検索キーワードをここに入力してください`
📝 氏名	`例: 草場友光`	`ここに氏名を入力してください`
📄 Textarea	`新しいメッセージを入力`	`ここに伝えたい内容を詳しく入力してください`
🔢 数値	`例: 10`	`1 から 20 の数値を入力してください`

Helper text / Message

入力ルールや注意点は、placeholder よりこちらに置くほうが安全です。

文字数制限
書式
単位
最小 / 最大
エラー理由

Textarea では特に、書いてほしい観点を helper text に置くと、placeholder を長文化せずに済みます。
たとえば「背景、再現手順、期待結果を書いてください」のような説明は、入力欄の下に見せておくほうが親切です。

使い分けをコードで見る

React

import { Field, Input, Textarea } from "@fluentui/react-components";

export function SampleForm() {
  return (
    <>
      <Field label="検索" hint="キーワードやファイル名で絞り込みます">
        <Input placeholder="キーワード、ファイル名、担当者名で検索" />
      </Field>

      <Field label="コメント" hint="要点が分かるように数段落でまとめます">
        <Textarea placeholder="新しいメッセージを入力" resize="vertical" />
      </Field>

      <Field label="再試行回数" hint="1 から 10 の範囲で入力します">
        <Input type="number" placeholder="例: 3" />
      </Field>
    </>
  );
}

Blazor

<FluentTextInput Label="検索"
                 Placeholder="キーワード、ファイル名、担当者名で検索"
                 Message="キーワードやファイル名で絞り込みます"
                 @bind-Value="@SearchText" />

<FluentTextArea Label="コメント"
                Placeholder="新しいメッセージを入力"
                Message="要点が分かるように数段落でまとめます"
                Resize="TextAreaResize.Vertical"
                AutoResize="true"
                Height="120px"
                @bind-Value="@Comment" />

<FluentNumberInput TValue="int"
                   Label="再試行回数"
                   Placeholder="例: 3"
                   Message="1 から 10 の範囲で入力します"
                   Min="1"
                   Max="10"
                   Step="1"
                   @bind-Value="@RetryCount" />

@code {
    string? SearchText;
    string? Comment;
    int RetryCount = 3;
}

React 側は Field で周辺文脈を与える形が分かりやすく、Blazor 側は各コンポーネントの Label / Message を使って自己完結させやすいです。

まとめ ✅

Fluent UI 2 の Input は、短い 1 行入力を受け取るための基本コンポーネントです。
ただし、実務で本当に大切なのは Input 単体ではなく、Textarea に切り替える境目、Blazor 側で FluentTextInput / FluentTextArea / FluentNumberInput<T> をどう使い分けるか、そして label / placeholder / helper text の役割分担だと感じます。

特にアクセシビリティとコンテンツの観点では、次の 3 つを外さないことが重要です。

placeholder を必須情報の置き場所にしない
label を常に用意し、必要なら aria-label も補う
Textarea と Number では、入力量や単位、範囲を見える形で説明する

これが守れていれば、Input 系コンポーネントは「ただ値を入れる箱」ではなく、利用者が迷わず入力できる 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