Windows向け .NET MAUI（.NET 8）の ScrollView は、既定のスクロールバーが細くて掴みにくいことがあります。WinUI 側のテーマリソースと ScrollBar スタイルを App.xaml で上書きすれば、太さを増やし、ホバー／ドラッグ中も細く戻らない挙動に寄せられます。
今回のゴールと前提（Windows / .NET 8 / .NET MAUI）
この記事では、次の要件を満たす方向で解説します。
- Windows 向け .NET MAUI アプリで ScrollView のスクロールバーを太くする
- ホバー時やドラッグ中に細く戻らない（太さがブレない／常に太い寄り）
- できれば サードパーティ製コンポーネントのスクロールバーに影響させない／少なくとも影響範囲を理解した上で選ぶ
結論から言うと、Windows（WinUI）側の Theme Resource（リソース） と ScrollBar のスタイル を上書きするのが基本です。MAUI の XAML だけで完結させるというより、Platforms/Windows の App.xaml で WinUI の見た目を調整するイメージになります。
なぜ ScrollView のスクロールバーが「細い」「状態で戻る」のか
.NET MAUI の ScrollView は、Windows 上では WinUI のスクロールコンポーネント（ScrollViewer/ScrollBar）に載って動きます。スクロールバーの太さや表示形態は、WinUI 側の既定スタイルが持つ リソース値 と VisualState（状態遷移） に依存します。
つまり、アプリ側で「太さっぽい値」を変えても、ホバー・ドラッグ・クリックなどの状態遷移のタイミングで、既定スタイルが別の見た目（別の要素、別の太さ、別のアニメーション）に切り替えてしまい、結果として「一瞬太いけど、触ると元に戻る」といった現象が起きやすくなります。
まずは最短で太くする：App.xaml（Platforms/Windows）で ScrollBar のリソースを上書き
最初に試すべきは、Windows プロジェクト側の App.xaml で、スクロールバーに関するリソースを上書きする方法です。MAUI では Platforms/Windows/App.xaml の MauiWinUIApplication.Resources（ResourceDictionary）に値を書きます。
代表的に効くキーは次の 2 つです。
| キー | 意味（ざっくり） | 調整の目安 |
|---|---|---|
ScrollBarSize | スクロールバー全体の幅（太さ） | 大きくするほど太くなる |
ScrollBarVerticalThumbMinWidth | 縦スクロールのつまみ（Thumb）の最小幅 | ScrollBarSize と同等か少し小さめから |
App.xaml の例は次の通りです（値は好みで調整してください）。
<maui:MauiWinUIApplication
x:Class="YourApp.WinUI.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:maui="using:Microsoft.Maui">
<maui:MauiWinUIApplication.Resources>
<ResourceDictionary>
<!-- スクロールバー全体の太さ（まずは 16〜24 くらいから） -->
<x:Double x:Key="ScrollBarSize">20</x:Double>
<!-- 縦スクロールの Thumb（つまみ）の最小幅 -->
<x:Double x:Key="ScrollBarVerticalThumbMinWidth">20</x:Double>
</ResourceDictionary>
</maui:MauiWinUIApplication.Resources>
</maui:MauiWinUIApplication>
「ホバー／ドラッグでもっと太くしたい」という要望なら、まずは ScrollBarSize を大きくして効き方を確認します（例として 60 に増やす案も提示されています）。
太さのおすすめ値（例）
「太くしたい」の度合いはアプリの用途で変わるので、個人的に試しやすいレンジを整理します。
| 用途 | ScrollBarSize の例 | 狙い | 注意点 |
|---|---|---|---|
| 一般的な業務アプリ | 16〜22 | 掴みやすさを上げつつ見た目を崩しにくい | Windows の他 UI とのバランス確認 |
| タッチ運用（2-in-1 / タブレット） | 22〜28 | 指でも掴みやすい | 内容領域を圧迫しないか |
| キオスク / 高齢者向け / 現場端末 | 28〜40 | とにかく掴める太さ優先 | デザイン崩れと情報量低下のトレードオフ |
ポイント：まずは “見た目が許せる最大値” を探すより、「ドラッグして操作できる最小値」 を狙うと落とし所が見つかりやすいです（太くしすぎると逆に邪魔になります）。
ホバー／ドラッグで細く戻る場合：ScrollBar の既定スタイル一式をコピーして VisualState を調整する
リソースだけを上書きしても「ホバーやドラッグの瞬間に細く戻る」「押した時だけ別の見た目になる」などが残る場合、次の段階として ScrollBar の既定スタイル（ControlTemplate 含む）を App.xaml に丸ごとコピーして、状態遷移を潰します。
重要なのは、VisualState を“部分的に”追加するのではなく、ScrollBar スタイルの全体をコピーしてから修正することです。VisualState だけを抜き出して置いても効かないケースがあり、実際に「TouchIndicator だけコピーするのは間違いで、ScrollBar スタイル一式をコピーしてから追記する」という指摘がされています。
やること（全体像）
- WinUI の
generic.xamlから ScrollBar のスタイル定義を見つける - 該当スタイルを
Platforms/Windows/App.xamlのResourceDictionaryにコピーする <VisualState x:Name="TouchIndicator">を探し、setter を追加して挙動（アニメーション／切替）を抑える
WinUI の generic.xaml はどこにある？（ローカルで探す方法）
WinUI の既定スタイルは Windows App SDK（Microsoft.WindowsAppSDK）の NuGet パッケージ配下に含まれており、ローカルなら次のような場所にあります（バージョンやターゲットによりパスは多少異なります）。
%USERPROFILE%\.nuget\packages\microsoft.windowsappsdk\＜version＞\lib\...\Microsoft.WinUI\Themes\generic.xaml
ここを開いて「ScrollBar」「TouchIndicator」などで検索し、ScrollBar の Style/Template 一式を見つけます。Windows App SDK のバージョンで定義が変わることがあるため、自分のプロジェクトが参照しているバージョンの generic.xaml を参照するのが安全です。
TouchIndicator の VisualState に setter を追加する
VisualState 名が TouchIndicator のブロックに、次の setter を追加する手順が提示されています。
<Setter Target="VerticalRoot.IsHitTestVisible" Value="True" />
実際の Q&A では、TouchIndicator の VisualState.Setters 内で、Root の表示切替（Collapsed）や PanningRoot の Opacity を触っている箇所に対して「スクロールバーをクリックしたときのアニメーションを無効化するため」として上記 setter を追加しています。
ここでのコツは次の通りです。
- App.xaml に置くのは “VisualState だけ” ではなく、ScrollBar スタイルの全体（ControlTemplate まで含める）
- コピーしたスタイルが参照しているリソース（
ScrollBarSizeなど）も同じ ResourceDictionary に入れて、参照解決できる状態にする - ホバー／ドラッグで “細くなる側” の状態（Indicator 系）に、太さが固定されるような setter や参照が入っているか確認する
「どの状態で何が変わっているか」を把握したい場合は、Visual Studio の Live Visual Tree / Live Property Explorer を使うのが近道です。実行中 UI の要素ツリーとプロパティをリアルタイムに確認できます（.NET MAUI + Windows + .NET 8 でも利用できる旨が記載されています）。
“特定の ScrollView だけ” に適用したい場合はどうする？（結論：標準のやり方はグローバルになりやすい）
Platforms/Windows/App.xaml の MauiWinUIApplication.Resources に置く上書きは、基本的に アプリ全体へ効く（グローバル） 方向になりがちです。実際に「特定の ScrollViewer だけに適用できるか？」という問いに対して、グローバルスタイルになる旨が回答されています。
とはいえ現場感としては、「サードパーティ製の見た目を壊したくない」「画面 A だけ太くしたい」といった要件はよくあります。そこで、現実的には次の 2 択になります。
| 方針 | メリット | デメリット | おすすめ度 |
|---|---|---|---|
| App.xaml で全体を太くする（簡易） | 実装が最小、保守が楽 | アプリ内の全スクロールに影響しやすい | まず試す |
| Windows のハンドラー／ネイティブ側で対象だけに適用（発展） | 影響範囲を限定できる可能性 | 実装コストが上がる／WinUI の知識が必要 | 要件が強いなら検討 |
| サードパーティ側の設定/API を使う | そのコンポーネントの想定範囲で安全に調整できる | 設定が無いと詰む | 該当するなら最優先 |
サードパーティに影響させたくない場合の現実解
サードパーティ製コンポーネントのスクロールバーに影響を出したくない場合、最も確実なのは ベンダーが用意しているスクロールバー調整用の設定や API があるか確認することです。実際にその方向での案内（ベンダーへ問い合わせ）がされています。
（発展）どうしても “特定 ScrollView だけ” に寄せたいときの考え方
グローバル上書きが前提になりやすいとはいえ、実務では「画面内の 1 つだけ太くしたい」ケースがあります。その場合は MAUI 標準だけで完結させようとせず、Windows 側（WinUI）の世界に寄せていきます。
方向性としては、次のような発想です。
- 対象の ScrollView を カスタム派生（例：
ThickScrollView）にする - Windows の Handler マッピングで、対象だけ WinUI の
ScrollViewer（PlatformView）に対してリソース/スタイルを当てる
ただし、この手法は Windows App SDK / WinUI の実装差分の影響も受けやすいため、「できる可能性がある」レベルの発展策として捉え、まずはグローバル上書きで要件を満たせないかを優先してください（特にチーム開発では保守性が重要です）。
よくあるハマりどころ（チェックリスト）
App.xaml に書いたのに太さが変わらない
- 書いている場所が Platforms/Windows/App.xaml か（共有側 App.xaml に書いても Windows の ScrollBar には効かないことがあります）
<maui:MauiWinUIApplication.Resources>の下に<ResourceDictionary>を作り、その中に書いているか- ビルド設定・起動先が Windows になっているか（Android/iOS では当然効きません）
ホバー／ドラッグで細く戻る（または挙動が不安定）
- VisualState だけを足していないか（ScrollBar スタイル全体をコピーしているか）
TouchIndicatorの VisualState に setter を追加しているか- 太さに関わる値が、別状態（Indicator 系）で別値になっていないか
「どの要素が太さを変えているのか」調べたい
Windows 上で実行しながら、Live Visual Tree / Live Property Explorer を使って ScrollViewer 配下の ScrollBar を辿ると、実際にどのプロパティがリソース由来なのか、状態遷移で何が変わったのかを追いやすいです。
まとめ
Windows 向け .NET MAUI（.NET 8）で ScrollView のスクロールバーを太くする基本は、WinUI 側のリソース（ScrollBarSize / ScrollBarVerticalThumbMinWidth）を App.xaml で上書きすることです。これで多くのケースは改善します。
それでもホバー／ドラッグ中に太さが戻る場合は、既定 ScrollBar スタイルが VisualState で見た目を切り替えている可能性が高いので、ScrollBar スタイル一式をコピーして TouchIndicator など該当状態に setter を追加する方向で対処します。
「特定の ScrollView だけ」に限定するのは標準的には難しく、要件が強い場合は Windows のハンドラー／ネイティブ側で対象だけに当てる、または サードパーティ側の設定/API の有無を確認するのが現実的です。
コメント