本文へスキップ
Blazor 入門 — C# だけで作る Web UI の始め方のアイキャッチ画像
Architecture

Blazor 入門 — C# だけで作る Web UI の始め方

公開: 更新: 約6分で読めます

Web フロントエンドといえば JavaScript や TypeScript、そして React や Vue といったフレームワーク——それが長らく常識でした。しかし .NET には、C# だけで対話的な Web UI を作れる Blazor という選択肢があります。既存の C# 資産とスキルをそのままフロントに活かせるため、バックエンドが .NET のチームには特に相性が良いのが魅力です。本記事では、Blazor の全体像から、ホスティングモデルの選び方、コンポーネントの書き方、状態管理、データ取得までを、はじめての方向けに解説します。

Blazor とは何か

Blazor は、C# と Razor 構文で UI コンポーネントを作り、ブラウザ上で動作させる .NET の Web UI フレームワークです。ボタンのクリックや入力の反映といった対話的な処理を、JavaScript を書かずに C# で記述できます。UI はコンポーネントという再利用可能な単位で組み立て、入れ子にして画面を構成します。この考え方は React や Vue と共通しており、モダンなコンポーネント指向をそのまま C# で実践できると考えると分かりやすいでしょう。

バックエンドと同じ言語・型・ツールでフロントを書けるため、DTO やバリデーションのロジックをサーバーとクライアントで共有でき、二重実装や型のズレが減ります。これが Blazor 最大の実務的メリットです。

3つのホスティングモデルを理解する

Blazor を始めるうえで最初に押さえるべきが、UI をどこで実行するかという「ホスティングモデル」です。大きく3種類あり、要件に応じて選びます。

Blazorの3つのホスティングモデル。Server、WebAssembly、Autoの実行場所と特徴の比較。
3つのホスティングモデル。UI の実行場所が異なる。迷ったら Blazor Auto が無難。
  • Blazor Server——UI はサーバーで動き、画面の差分だけを SignalR でブラウザへ送ります。初期表示が速く配信サイズも小さい反面、常時接続と通信遅延の影響を受けます。
  • Blazor WebAssembly(WASM)——.NET を WebAssembly としてブラウザに読み込み、クライアント側で完結します。オフラインや静的ホスティングに強い一方、初回ダウンロードがやや大きくなります。
  • Blazor Auto(.NET 8 以降)——初回は Server で素早く表示し、WASM の読み込み完了後にクライアント実行へ移行します。速さと快適さの両取りで、多くの新規プロジェクトの既定候補です。

判断に迷ったら、まず Auto で始め、オフライン必須や常時接続が難しいといった制約が明確な場合に個別のモデルへ倒す、という進め方が安全です。

最初のコンポーネントを作る

Blazor の UI は .razor ファイル(コンポーネント)で作ります。特徴は、マークアップ(HTML)と C# ロジックが1つのファイルに同居することです。定番のカウンターを見てみましょう。

.razorコンポーネントの構造。@page、マークアップ、@onclick、@codeの役割を注釈した図。
.razor コンポーネントの構造。マークアップと C# ロジックが1ファイルに同居する。
@page "/counter"

<h1>カウンター</h1>
<p>現在の値: @count</p>
<button @onclick="Increment">+1</button>

@code {
    private int count = 0;
    private void Increment() => count++;
}

@page でこのコンポーネントの URL を宣言し、@onclick で C# のメソッドをクリックイベントに直接バインドしています。count の値が変わると Blazor が差分を検知し、画面が自動で再描画されます。DOM 操作を手で書く必要はありません。

状態とデータバインディング

入力フォームは @bind を使うと、変数と入力欄が双方向に同期します。値の取得・反映のためのイベント処理を書かずに済みます。

<input @bind="name" placeholder="お名前" />
<p>こんにちは、@name さん</p>

@code {
    private string name = "";
}

入力するたびに name が更新され、@name の表示もリアルタイムに変わります。フォームの検証には EditForm と DataAnnotations を組み合わせると、サーバーと同じバリデーション属性をそのまま再利用できます。

データ取得とサービス注入

実アプリでは API からデータを取得します。Blazor は 依存性注入(DI)が標準で、@inject でサービスやクライアントを受け取れます。コンポーネントの初期化時に非同期でデータを読み込むのが定石です。

@page "/weather"
@inject HttpClient Http

@if (forecasts is null)
{
    <p>読み込み中...</p>
}
else
{
    <ul>
        @foreach (var f in forecasts)
        {
            <li>@f.Date: @f.TemperatureC ℃</li>
        }
    </ul>
}

@code {
    private Forecast[]? forecasts;

    protected override async Task OnInitializedAsync()
    {
        forecasts = await Http.GetFromJsonAsync<Forecast[]>("api/weather");
    }
}

ポイントは、取得するデータの型(Forecast)をサーバーと共有できることです。JSON の手動パースやプロパティ名のズレに悩まされず、コンパイル時に型で守られた状態でフロントを書けるのが Blazor の強みです。

どう選び、どこから始めるか

Blazor が特に向くのは、バックエンドが .NET で、フロントも C# で統一したいチーム、管理画面や社内業務アプリ、そして既存の Web Forms や Silverlight からの移行先です。逆に、極端に大規模な公開向け SPA や、既に成熟した JavaScript エコシステムのライブラリが不可欠な場合は、React などが向くこともあります。

始めるなら、dotnet new blazor(または Visual Studio のテンプレート)でプロジェクトを作り、まず Auto で小さな画面を1つ作ってみるのが近道です。コンポーネントの再利用、@bind、DI に慣れれば、業務アプリの多くはカバーできます。レンダリングモードの細かな選定は、次のステップで深掘りしていきましょう。

開発者の声(X より)

実際に Blazor を使う .NET 開発者は、どんな手応えを感じているのでしょうか。SNS 上のリアルな声を紹介します。まずは採用の考え方について、Microsoft のエバンジェリストである かずき氏(@okazuki)の投稿です。一般公開のサイトは慎重に、一方で .NET チームが内部で使う業務アプリには積極的に、という現実的な線引きが参考になります。

次は、AI 駆動開発と組み合わせた体験談です。GitHub Copilot のエージェントモードで、ASP.NET Core Blazor のアプリを短時間で組み上げられたという手応えが語られています。C# で完結する Blazor は、AI コーディング支援とも相性が良いことがうかがえます。

よくある質問

Blazor は JavaScript の知識が必要ですか?

基本的な UI 構築だけなら不要です。C# と Razor 構文で完結できます。ただし既存の JS ライブラリを使いたい場合は、JS 相互運用(IJSRuntime)で連携できます。

Blazor Server と WebAssembly はどちらを選ぶべきですか?

.NET 8 以降なら、まず両方の利点を自動で取る Blazor Auto を推奨します。オフライン動作や静的ホスティングが必須なら WebAssembly、常時接続が前提の社内アプリなら Server が向きます。

Blazor は React や Vue と比べてどうですか?

コンポーネント指向という点は共通です。違いは言語で、Blazor は C# で書けるためバックエンドと型やロジックを共有できます。.NET 中心のチームでは開発効率と保守性で優位に立ちます。

参考リンク

この記事をシェア

コピーしました

関連記事