はじめに 🌟

バックエンドは C# で書くのに、フロントエンドだけ別言語になる。
この分断を少しでも減らせないか、というのが私の考える「C# Web 大統一理論」です。

ここで言う Blazor は Blazor WebAssembly（Blazor WASM） を指します。
Blazor Server ではなく、ブラウザ上で .NET ランタイムを動かす構成を前提に話します。

もちろん、何でも C# に寄せれば正解という話ではありません。
それでも、条件が合うチームやプロダクトでは、フロントもバックエンドも C# に寄せることで、開発効率・保守性・設計の一貫性をまとめて引き上げられると私は感じています。

この記事で言いたいのは、単に「C# だけで書けてうれしい」という話ではありません。
型の整合、レビュー可能範囲、通信形式の選択肢、性能改善の知見、UI とアクセシビリティの再利用まで含めて見ると、Blazor WASM はかなり面白い立ち位置にあります。

この記事の評価軸 ✅

本記事では、開発効率を次の観点で見ます。

✅ 型の整合性: フロントとバックで同じ契約を保ちやすいか
✅ レビューと保守のしやすさ: チーム内で読める範囲を広げられるか
✅ 通信と性能設計の自由度: JSON 以外も含めて適材適所を選べるか
✅ 性能改善の知見の再利用: 同じ .NET の道具箱で横断的に考えられるか
✅ UI とアクセシビリティの再利用: 画面実装を部品化し、一貫性を保ちやすいか

つまり、ここでいう「効率」は実装速度だけではありません。
変更に強いこと、レビューしやすいこと、同じ知識を別レイヤーへ持ち込めることまで含めて考えます。

C# Web 大統一理論とは

要するに、Web アプリの実装を可能な範囲で C# に集約していく考え方です。

典型的な構成はこんなイメージです。

項目	よくある構成	C# Web 大統一寄り
🧠 型	フロントとバックで別定義になりやすい	共有クラスライブラリで寄せやすい
🛠 言語	JS / TS + C# の往復が発生しやすい	実装の多くを C# に寄せやすい
📦 通信形式	JSON が中心	JSON 以外も要件に応じて検討しやすい
🚀 改善手段	ツールや知見が分散しやすい	.NET の知見を横断利用しやすい
♿ UI 実装	生 HTML と JS の作り込みが増えやすい	コンポーネント再利用へ寄せやすい

この表が示しているのは、技術の優劣というより認知負荷の置き場所です。
フロントとバックで読む言語、型、道具立てが揃うと、設計の会話そのものがかなり進めやすくなります。

以下では、これがなぜ開発効率に効くのかを順に見ます。

論点 1: バックエンドとフロントで型共有しやすい

これは C# Web 大統一理論の土台です。

ASP.NET Core と Blazor WASM を組み合わせると、Blazor WebAssembly を ASP.NET Core でホストする構成や共有クラスライブラリを使って、DTO や一部の共通ロジックをクライアント / サーバー間で共有しやすくなります。
つまり、API の契約を「説明で合わせる」のではなく、同じ型として扱いやすいということです。

たとえば、こんな DTO を共有できます。

public sealed record TodoItem(int Id, string Title, bool IsDone);

バックエンドとフロントで別言語を使う構成でも、もちろん OpenAPI や codegen で整合は取れます。
ただ、Blazor WASM + ASP.NET Core のように同じ .NET ベースで揃えると、次の差が出やすいです。

観点	別言語で分離する場合	C# で共有する場合
🔁 契約変更	両側の型更新と同期が必要	shared project 側の変更を起点にしやすい
🧪 null 許容や列挙型	表現差でズレやすい	同じ C# の型として扱いやすい
🔍 レビュー	API 仕様書と実装の往復が増える	型定義を見れば意図が追いやすい
🛠 リファクタリング	片側だけ変更しやすい	同じ名前・同じ契約で追従しやすい

重要なのは、「コードが 1 か所になる」ことだけではありません。
大きいのは、設計の言葉が揃うことです。型名、プロパティ名、null 許容、列挙値の意味が一致すると、レビューもデバッグもかなり楽になります。

さらに、変更時の差分追跡も整理しやすくなります。
たとえばレスポンスに 1 プロパティ追加するとき、型・API・画面の変更点を同じ言語と同じ命名規則で追えるのは、日々の保守で効いてきます。
ただし、共有しやすいのは DTO や一部の共通ロジックであって、何でも共有すべきという意味ではありません。ブラウザー依存の処理やサーバー依存の処理まで無理に共通化すると、逆に責務が曖昧になります。

参考:

ASP.NET Core Blazor hosting models

論点 2: フロント実装の多くを C# に寄せられる

ここは誤解しやすいので、先に正確に書きます。
Blazor WASM を使っても、あらゆる場面で JavaScript が不要になるわけではありません。ブラウザー API や既存の JS ライブラリと連携するときは、JavaScript 相互運用（JS interop）が必要になることがあります。

それでもなお、この論点は強いです。
なぜなら、日常的な画面実装、状態管理、バリデーション、API 呼び出し、コンポーネント構成の多くを C# に寄せられるからです。

私がこれを大きいと感じるのは、単に「新しい言語を覚えなくてよい」からではありません。
レビューできる範囲が広がり、属人化しにくくなるからです。

視点	分離構成	C# に寄せた構成
🔍 レビュー	JS / TS と C# で担当が分かれやすい	C# を読める人が触れる範囲を広げやすい
🧩 実装作法	2 系統の文法・ツールに慣れる必要がある	.NET の流れに寄せやすい
🧪 テストとデバッグ	前後で道具が分かれやすい	ログ・例外・型の追跡をまとめやすい
👥 チーム運営	境界説明のコストが増えやすい	共通言語で会話しやすい

特に小〜中規模のプロダクトでは、この差が効いてきます。
「この画面はフロント専任でないと触れない」「API は別チームでないと読めない」という壁が薄くなるだけでも、保守性はかなり変わります。

また、オンボーディングの観点でも利点があります。
.NET の経験がある開発者なら、完全に別のフロントエンド文化へ移るより、Razor とコンポーネントの考え方を追加で学ぶほうが移行しやすい場面があります。

ここで、少し横道ですが Aspire の存在も挙げておきたいです。
Aspire は distributed application を code-first に構成・実行・観測するためのレイヤーで、いまは C# だけでなく TypeScript AppHost や各種多言語ワークロードにも広がっています。

そのため、「Aspire があるから C# Web 大統一理論が正しい」とまでは言えません。
ここを根拠にしすぎるのは弱いです。ですが、それでもなお Aspire の第一言語が依然として C# であることは重要です。

特に ASP.NET Core、Blazor WASM、各種 .NET サービスをまとめて扱うチームでは、AppHost、リソース参照、サービスディスカバリ、ダッシュボード、ローカル開発体験まで含めて、C# が Aspire の恩恵を最も自然に受けやすい言語の 1 つであることは間違いありません。
ここも「C# だけで全部やる」と言い切るのではなく、アプリケーション実装の重心を C# 側へ寄せられると捉えるほうが現実に合っています。

参考:

ASP.NET Core Blazor hosting models
ASP.NET Core Blazor JavaScript interoperability
What is Aspire?

論点 3: JSON だけに縛られなくてよい

これは「JSON を捨てよう」という話ではありません。
むしろ、JSON を使うべき場面と、別の形式を選んだほうがよい場面を切り分けやすくなるという話です。

外部公開 API や多言語クライアントとの連携では、JSON は依然としてとても強い選択肢です。
可読性、デバッグ容易性、相互運用性の高さは大きな利点です。

ただし、クライアント / サーバーの両方を自分たちで制御できる内部通信では、必ずしも JSON に固定する必要はありません。
C# 同士なら、たとえば MessagePack for C# や MemoryPack のような C# 向けバイナリシリアライザーを検討できます。

形式	向いている場面	強み	注意点
📄 JSON	外部公開 API、多言語連携、調査しやすさ重視	人が読みやすく相互運用しやすい	文字列化コストやサイズは重くなりやすい
📦 MessagePack for C#	内部 API、C# 中心の高速通信	コンパクトさと高速化を狙いやすい	相互運用やスキーマ運用を事前に考える必要がある
🧠 MemoryPack	C# 同士の強い制御下にある通信や永続化	C# との密な相性を活かしやすい	対応する C# スキーマ前提で考える必要がある

たとえば、次のような型を内部通信でやり取りするとします。

public sealed record SearchResult(string Query, int HitCount, string[] Items);

この型を JSON で運ぶか、バイナリで運ぶかは要件次第です。
大事なのは、「Web だから JSON 一択」と思い込まなくてよいことです。

MessagePack と MemoryPack をどう見るか

どちらも公式ドキュメントでは、高性能な C# 向けシリアライザーとして案内されています。
実際、文字列ベースの JSON より、よりコンパクトな表現やデコード効率を狙いやすい場面があります。

ただし、ここは断定しすぎないほうが安全です。
実際の差は、データ形状、圧縮、相互運用要件、バージョン互換性、デバッグのしやすさで変わります。

つまり、この論点の本質は「常に最速」ではありません。
重要なのは、C# でフロントとバックを揃えると、内部通信の設計でも選択肢が増えることです。
一方で、外部公開 API や多言語クライアント前提の境界まで安易にバイナリへ寄せるべきではありません。互換性、可観測性、運用性まで含めて考えるなら、まずは内部 API から検討するのが無難です。

論点 4: .NET の性能知見をフロントとバックで横断利用しやすい

ここは「C# は速いから勝ち」という単純な話ではありません。
私が重要だと思うのは、同じ .NET の道具箱で考えられることです。

.NET には、tiered compilation（段階的コンパイル）、AOT、Source Generator、Span / Memory 系 API など、性能改善のための道具がたくさんあります。
もちろん、それぞれ効く場所は違います。ですが、共通のランタイムと共通の言語の文脈で考えられること自体が大きいです。

観点	何が効くか	開発効率への意味
⚡ Tiered compilation / JIT	実行状況に応じて最適化される	.NET 側の性能知見をサーバー中心に蓄積しやすい
🧰 Source Generator	実行時反射依存を減らしやすい	シリアライズや DI の改善を同じ文化圏で理解しやすい
🪶 Span / Memory	余計なコピーを抑えやすい	ボトルネック分析の言葉を統一しやすい
🧩 AOT	WebAssembly 側の実行性能向上を狙える	フロントでも .NET の最適化手段を選択肢にできる

ここで大事なのは、性能そのものより、性能改善の会話を統一しやすいことです。
たとえば API のシリアライズ負荷、文字列処理、不要な割り当て、トリミングや AOT の判断を、別々の文化圏ではなく同じ .NET の前提で議論しやすくなります。

もちろん、注意点もあります。
Blazor WASM は非 AOT では server-side .NET の JIT 実行より遅くなりやすく、AOT は CPU 集約処理には効きやすい一方で、ダウンロードサイズを増やすというトレードオフがあります。

だからこそ、ここでの主張は「C# は常に最速」ではありません。
つまり、.NET の最適化手段をフロント / バック両方で共通の文脈として扱えることが、設計と改善の効率に効くという話です。

参考:

論点 5: Razor を UI コンポーネント合成の場として使いやすい

Blazor の面白さは、Razor ファイルの中で素の HTML を大量に書くことより、UI コンポーネントを合成して画面を組み立てる方向へ寄せやすい点です。

たとえば Fluent UI Blazor のようなコンポーネントライブラリを使うと、<button> や <input> を毎回組み立てる代わりに、<FluentButton> や <FluentTextField> のような部品を中心に画面を作れます。

<FluentCard>
    <FluentTextField @bind-Value="Title" Placeholder="タイトル" />
    <FluentButton Appearance="Appearance.Accent">保存</FluentButton>
</FluentCard>

この変化には、単にコードが短くなる以上の意味があります。
ブラウザ側でも .NET と Razor のコンポーネントモデルで統一できる Blazor WASM だからこそ、UI の表現とアプリケーションロジックを同じ文化圏で扱いやすいのが効いてきます。

観点	素の HTML を都度書く場合	UI コンポーネントを再利用する場合
🎨 見た目	class や属性を毎回組み立てる	デザイン規約に沿った部品を再利用しやすい
♿ アクセシビリティ	ラベル・状態・属性を毎回確認する	アクセシブルな土台を作りやすい
⌨️ キーボード操作	個別に作り込みが必要	フォーカスや操作体系を揃えやすい
🧱 一貫性	実装者ごとの差が出やすい	画面全体で同じルールを保ちやすい
🔍 レビュー	DOM と属性の細部を毎回追う	コンポーネントの意味単位でレビューしやすい

ここで重要なのは、アクセシビリティが自動で保証されると言いたいわけではないことです。
Fluent UI Blazor のようなライブラリは、セマンティクス、キーボード操作、フォーカス、コントラスト設計などの再利用可能な土台を持ち込みやすくします。

一方で、アプリ側では引き続き、次の確認が必要です。

ラベルや見出し構造が適切か
フォーカス順が画面フローに合っているか
コントラストや状態変化が文脈に合っているか
支援技術に必要な名前や説明が不足していないか

それでも、このアプローチには大きな利点があります。
大きいのは、アクセシビリティを部品選択の段階で前倒ししやすいことです。

この視点で見ると、Blazor は「HTML を C# に置き換える」というより、UI の意味と振る舞いをコンポーネントとして再利用しやすい仕組みだと言えます。

Blazor WASM の弱点はどう見るか

ここはフェアに書いておきたいです。
Blazor WASM は、昔から 初回ロードの重さ を指摘されてきましたし、この弱点が完全に消えたわけではありません。

公式ドキュメントでも、Blazor WebAssembly には次のような前提があります。

アプリ本体と .NET ランタイムをブラウザへダウンロードする
server-side .NET の JIT 実行と比べると、非 AOT の実行は遅くなりやすい
AOT は実行性能を改善できる一方で、アプリサイズは増える

つまり、ロード時間と実行速度は一つの軸では語れません。
初回表示を優先するか、CPU 集約処理の実行性能を優先するかで、最適な設定は変わります。

ただし、ここ数年で調整の選択肢はかなり増えています。

📦 HTTP 圧縮
🗃️ ブラウザキャッシュ（browser cache）の活用
✂️ IL trimming やランタイム再リンク（runtime relinking）
🧩 lazy loading
⚡ AOT

私はこの点を、「弱点が消えた」とは見ていません。
むしろ、弱点を前提にしたうえで、どこまで寄せるかを選びやすくなったと見ています。

たとえば、次のような条件なら、Blazor WASM の初回ロードを比較的受け入れやすいです。

社内向けやログイン後利用が中心で、初回表示だけでなく継続利用を重視する
同じ画面を長く使い、型共有やレビュー容易性の価値が大きい
キャッシュが効きやすく、複数回利用が前提になる

逆に、次のような条件では慎重さが必要です。

SEO や初回表示が極端に重要
ランディングページのように一瞬の表示体験が勝負になる
ブラウザ向け配布サイズに強い制約がある

参考:

それでも万能ではない

C# Web 大統一理論は、すべての Web アプリに効く魔法ではありません。

たとえば、次のような場合は慎重であるべきです。

React / Vue などの既存資産や人材がすでに厚い
外部公開 API が多言語クライアント前提で、境界の相互運用性が最優先
高度なブラウザ固有ライブラリへ深く依存している
初回ロードの厳しさがプロダクト価値へ直結する

一方で、次のような条件ではかなり相性がよいと思います。

ASP.NET Core をすでに採用している
DTO や契約変更の追従コストを下げたい
小〜中規模チームで、担当境界を薄くしたい
内部向けアプリや業務画面で、継続利用の効率を重視したい
UI コンポーネントとアクセシビリティの再利用を進めたい

つまり、これは「C# 以外を否定する話」ではありません。
私の主張は、条件が合うなら、Blazor WASM を含む C# 中心の構成は有力だということです。

おわりに 🏗️

私が言いたいのは、Web のフロントとバックを C# に寄せると、単に言語が揃う以上の価値があるということです。

型共有で、契約のズレを減らしやすい
フロント実装の多くを C# に寄せて、レビュー可能範囲を広げやすい
Aspire のような code-first な周辺体験でも、C# は依然として強い第一言語になっている
JSON だけに閉じず、内部通信では MessagePack や MemoryPack も検討しやすい
.NET の性能改善知見をフロント / バックで横断利用しやすい
Fluent UI Blazor のような部品群で、UI とアクセシビリティの土台を再利用しやすい

もちろん、Blazor WASM には初回ロードという弱点があります。
ですが、その弱点を認めたうえでも、型の整合、保守性、レビュー効率、内部設計の自由度を重視するなら、かなり魅力的な選択肢です。

少なくとも私は、ASP.NET Core を使うプロダクトで「フロントは別言語で分けるのが当たり前」と決めつける前に、
Blazor WASM を候補に入れ、どこまで C# を貫くとチームが楽になるのかを一度は真面目に考える価値があると思っています。