Fluent UI 2 の Progress Bar を理解する — Fluent UI Blazor 5 比較と Skeleton 使い分け・アクセシビリティ

Posted at 2026-06-15

はじめに 🌟

Fluent UI 2 の Progress Bar は、処理の進み具合を「見える化」して、待ち時間の不安を減らすためのコンポーネントです。
ただし、単にバーを出せばよいわけではありません。進捗が測れるのか測れないのか、何を表示するのか、読み上げでどう伝えるのかまで含めて設計する必要があります。

この記事では、まず Fluent UI 2 そのものを短く整理し、これまでの Fluent UI 2 シリーズ記事をすべて紹介します。
そのうえで、Fluent UI 2 の Progress Bar と Fluent UI Blazor 5 の FluentProgressBar を比較し、機能差と使用方法の違いをまとめます。

あわせて、似た役割で混同しやすい Skeleton との使い分け、Progress Bar のガイダンス、種類（確定/不確定）、レイアウト、アクセシビリティ、コンテンツ設計、してはいけないことまで整理します。

参照した一次情報:

Fluent UI 2 とは

Fluent UI 2 は、Microsoft Fluent 2 デザインシステムに沿って UI を設計・実装するためのガイダンスとコンポーネント群です。
見た目をそろえるだけではなく、情報設計、操作の一貫性、アクセシビリティ、コンテンツ設計までを一体として扱うのが特徴です。

Progress Bar でもこの考え方は同じです。
「いま何が起きているか」「どれくらい進んだか」「待つべきか」を、視覚と支援技術の両方で誤解なく伝えることが主目的になります。

これまでの Fluent UI 2 シリーズ（公開済み）📚

※ 2026-06-16 時点で公開済みのシリーズ記事です。

今回のゴール ✅

Progress Bar の役割と、確定（determinate）/不確定（indeterminate）の使い分けを理解する
Fluent UI 2 と Fluent UI Blazor 5 の機能・使用方法の違いを整理する
Skeleton との使い分けを判断できるようにする
ガイダンス、レイアウト、アクセシビリティ、コンテンツ設計の要点を押さえる
してはいけない使い方を明確にする

Fluent UI 2 Progress Bar と Fluent UI Blazor 5 の比較

Fluent UI 2 側は「いつ・どう見せるか」の設計指針が中心で、Fluent UI Blazor 5 側は FluentProgressBar の実装 API が中心です。
この差を押さえると、設計と実装を分離して考えやすくなります。

観点	Fluent UI 2 (React / Usage)	Fluent UI Blazor 5 (`FluentProgressBar`)
🧭 主眼	ガイダンス中心（UX と情報設計）	実装中心（パラメーターと状態制御）
📊 進捗表現	determinate / indeterminate を明確に使い分け	`Value` あり = determinate、`Value=null` = indeterminate
🧱 構成	ラベル・ステータス文言・配置ルールを重視	`Min` `Max` `Value` + `FluentField` で文言や補助情報を構成
🎨 見た目	使い方ガイド中心	`Thickness` `Shape` `State` `Color` `BackgroundColor` で調整
⚠️ 状態表現	エラー時は状態テキストを置き換えて明示	`State=Error/Warning/Success` とメッセージを併用可能
♿ アクセシビリティ	内容説明と期待値制御を重視	コンポーネントに加え、周辺のラベル/説明文/ライブ更新設計が必要
🔁 多段タスク	進捗の巻き戻しを避け、1 本のバーで統合	実装側でステップを統合し、`Value` を前進のみで更新する設計が必要

React 側の実装イメージ

import { ProgressBar } from "@fluentui/react-components";

export function UploadProgress({
  value,
  max,
}: {
  value: number | null;
  max: number;
}) {
  const isIndeterminate = value === null;

  return (
    <div>
      <span id="upload-label">ファイルをアップロード中</span>
      <ProgressBar
        aria-labelledby="upload-label"
        value={isIndeterminate ? undefined : value}
        max={max}
      />
      <div>
        {isIndeterminate
          ? "アップロードを開始しています ..."
          : `${value}/${max} 件を処理済み`}
      </div>
    </div>
  );
}

Blazor 側の実装イメージ

<FluentField Label="ファイルをアップロード中"
             Message="@StatusMessage">
    <FluentProgressBar Min="0"
                       Max="100"
                       Value="@ProgressValue"
                       Width="320px"
                       Thickness="ProgressThickness.Large" />
</FluentField>

@code {
    int? ProgressValue = 42; // null にすると indeterminate
    string StatusMessage => ProgressValue is null
        ? "アップロードを開始しています ..."
        : $"{ProgressValue}% 完了";
}

Skeleton との使い分け（似た機能のコンポーネント）

Progress Bar と Skeleton はどちらも「待ち時間」を扱いますが、伝える情報が異なります。

観点	Progress Bar	Skeleton
🎯 伝えること	処理の進捗（どこまで進んだか / 進行中）	読み込み後のレイアウトの骨格
🧠 ユーザー期待	「どれくらい進んだか」を知りたい	「何が表示されるか」を先に把握したい
⏱ 向く場面	タスク進行、アップロード、インストールなど	非ブロッキングで段階的に描画するコンテンツ読み込み
📐 前提	進捗値がある or 進行中を示したい	最終 UI の構造がある程度分かっている
♿ 補助属性	ラベル・状態文・必要なら `aria-valuetext`	コンテナに `aria-busy`、必要に応じて `aria-live`

Fluent UI 2 の guidance では、読み込み構造が分かっていて UI をブロックしない場合は Skeleton を検討し、構造が不明な場合は Progress Bar / Spinner を検討する方針です。
また Skeleton は長時間処理向きではないため、処理時間が長いタスクでは Progress Bar の方が期待値を合わせやすくなります。

Progress Bar のガイダンス

Fluent UI 2 の Progress Bar usage で重要な要点は次のとおりです。

1 秒未満で終わる処理には基本的に使わない
可能なら determinate を優先する（安心感が高い）
不確定な処理は indeterminate を使うが、長時間は避ける
後から進捗算出できるなら determinate へ切り替える
複数ステップは 1 本のバーへ統合し、巻き戻しを避ける

Progress Bar の種類（確定 / 不確定）の使い分け

確定した進行度バー（Determinate）

進捗の母数と現在値が分かる場合に使います。
例: 100 件中 42 件完了、500MB 中 120MB 転送済み。

✅ 完了量と残量を伝えられる
✅ ユーザーが待機判断しやすい
✅ 可能なら最優先で採用する

不確定な進行度バー（Indeterminate）

処理時間や総量が分からない場合に使います。
例: サーバー応答待ち、開始直後で総量未確定の処理。

✅ 「処理中であること」を示せる
⚠️ 長時間表示し続けると不信感を招きやすい
✅ 進捗を計算できる状態になったら determinate へ切り替える

不確定バーは「何も示せないときの短時間の避難先」です。
長時間処理を indeterminate のまま放置しないでください。

レイアウト

Progress Bar の配置では、視線移動と文脈維持が重要です。

ラベルはバーの上、ステータスはバーの下に置く
左右に説明文を置く構成は避ける
タスク起点 UI の近く（直下・ドロワー・コールアウト）に置く
キャンセル可能な処理は、Close 操作を分かりやすい位置に置く

また、固定割合（例: ストレージ使用率）を示すだけなら、アニメーションなしの静的バーが適しています。
常時アニメーションは「進行中」と誤認されやすいため、意図を分けるのが安全です。

アクセシビリティ（重要）♿

Progress Bar のアクセシビリティは「値」だけでなく「状況説明」が鍵です。

ラベルを必ず関連付ける
何の進捗か不明なバーは、スクリーンリーダー利用時に意味を失います。
状態文を併記する
「同期中 ...」「42/100 件完了」のように、現在起きていることを文で示します。
エラー時は状態文を即座に差し替える
進捗表示を続けるより、失敗と次の行動を明示する方が重要です。
値の変化が細かすぎる場合は読み上げ負荷を下げる
更新粒度を調整し、必要なら意味単位で通知します。aria-live="polite" な状態文を「10%ごと」「フェーズ完了時」などの節目だけ更新すると、過剰読み上げを避けやすくなります。
Skeleton 併用時は aria-busy を適切に管理する
大きな読み込みブロックでは、読了タイミングが伝わる設計にします。

コンテンツ設計（重要）✍️

Progress Bar の文言は、待ち時間の体験を左右します。Fluent UI 2 の guidance を実務向けにまとめると次のとおりです。

観点	推奨	避けたい例
🏷 ラベル	短く明確、sentence case、ピリオドなし	長文タイトル、曖昧な語
📈 ステータス	進捗や現在処理を具体的に示す	「処理中」だけで情報不足
⏱ 時間表現	信頼できる単位を使う（件数/容量など）	不正確な残り時間表示を断定
🔄 進行表現	-ing 相当の進行文で継続を示す	完了形なのに終わっていない文言
🚨 異常時	何が起きたか + 次の行動を短く示す	エラー原因も対処も不明な文言

してはいけないこと ❌

不確定バーを長時間出し続ける
ステップごとにバーをリセットし、見かけ上の巻き戻しを起こす
ラベルなし・状態文なしでバーだけ表示する
1 秒未満の処理で過剰に Progress Bar を出す
進捗値がないのに determinate 表示をして誤認させる
Skeleton で長時間処理を代替し続ける

まとめ 📝

Progress Bar は「進んでいること」を伝えるための UI で、Skeleton は「これから表示される構造」を伝えるための UI です。
まずはこの役割分担を守ることが、待ち時間 UX を壊さない最短ルートです。

実装では、Fluent UI 2 でガイダンスを押さえ、Fluent UI Blazor 5 で FluentProgressBar の API に落とし込む流れが安定します。
特に、確定/不確定の使い分け、アクセシブルな説明文、エラー時の文言差し替えは優先して設計してください。

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