Blazor 8.0を実行すると、Chromeの開発者ツール（Console）に「Information: Normalizing ‘_blazor’…」「Information: WebSocket connected…」などのログが流れ続け、他の警告やエラーが埋もれてしまうことがあります。本記事では、原因がblazor.web.js内のSignalRクライアントログである点を整理し、ログレベルをWarning以上に引き上げて静かにする実装手順を解説します。
症状：ChromeのConsoleに「Information: …」が出続ける
Blazor 8.0（.NET 8）のアプリを起動すると、Google Chromeの開発者ツール（DevTools）のConsoleに、次のような「Information」ログが繰り返し出力されることがあります。
Information: Normalizing '_blazor' to 'https://example.com/_blazor'.
Information: WebSocket connected to wss://example.com/_blazor?id=xxxxxxxxアプリ自体は正常に動いているのにログだけが賑やかだと、本当に確認したいWarningやErrorが流されて見落とす原因になります。特に、開発中にHot Reloadやリロードを繰り返すケース、もしくはタブの復帰やスリープ復帰で接続が張り直されるケースでは、コンソールがこの手の情報で埋まりがちです。
| よく見るログ例 | 意味（ざっくり） | 邪魔に感じやすい理由 |
|---|---|---|
| Information: Normalizing ‘_blazor’ to … | SignalR接続のURL（_blazor）を正規化している | 接続開始のたびに出るため、リロードや再接続で何度も表示される |
| Information: WebSocket connected to … | WebSocketで接続が確立した（または再確立した） | 「正常に接続できた」だけなのにログが積み重なりやすい |
原因：blazor.web.jsが内部で使うSignalR（WebSocket）のクライアント側ログ
結論から言うと、これらの「Information」ログは、Blazorがブラウザー側で動かしているJavaScript（blazor.web.js）が、内部で利用しているSignalR JavaScriptクライアントのログです。
Blazor 8.0の「Blazor Web App（Interactive Server）」では、ブラウザーとサーバーが継続的に通信するために、SignalRを使って“回線（circuit）”を確立します。その通信経路としてWebSocketが使われると、接続時に「WebSocket connected …」のようなメッセージが出ます。
ポイントは、このログが「エラー」ではなく「情報（Information）」であることです。つまり、表示されているだけなら正常系であることが多く、ログ量を減らしたいだけならログレベルの調整が最短ルートになります。
「_blazor」って何？（URL正規化ログの正体）
_blazor は、Blazor（Interactive Server）がブラウザーとサーバーをつなぐために使うエンドポイントの代表例です。SignalRクライアントは、相対パスで渡された '_blazor' を、現在のページURLやベースパスに基づいて絶対URLへ変換（正規化）します。その際に出るのが「Normalizing …」です。
このログ自体を消したいのが今回のテーマですが、逆に言えば、想定外のURLに正規化されている場合は、アプリのホストパス（サブディレクトリ配下での公開、リバースプロキシ、<base href> の設定など）を見直すヒントにもなります。
サーバー側ログとブラウザー側ログは別物
ここで混乱しやすいのが、ASP.NET Coreのログ設定（C#側）をいじっても、Chrome Consoleのログが消えないケースです。理由は単純で、出力元が違うからです。
| 項目 | サーバー側（ASP.NET Core） | ブラウザー側（blazor.web.js / SignalRクライアント） |
|---|---|---|
| ログの出力先 | サーバーのコンソール、ファイル、Application Insights等 | Chrome DevTools（Console） |
| 主な設定場所 | Program.cs の builder.Logging など | Blazor.start() のオプション（JavaScript） |
| 今回の「Information: …」への効き方 | 基本的に効かない（出力元が別） | 効く（SignalRクライアントのログレベル変更） |
| 典型的な誤解 | サーバーを静かにすればブラウザーも静かになると思いがち | ブラウザーはブラウザーで別の設定が必要 |
結論：SignalRクライアントのログレベルをWarning以上に引き上げる
この問題を根本的に静かにしたい場合は、SignalRクライアントのログレベルを「Warning以上」に引き上げるのが効果的です。つまり、Information相当のログを出さないようにします。
重要ポイント：Blazorの自動起動（auto-start）を止める
Blazor 8.0は通常、_framework/blazor.web.js を読み込むと自動で起動します。後から設定を書いて Blazor.start() を呼び直そうとすると、次のようなエラーに遭遇しがちです。
Uncaught Error: Blazor has already started.これを避けるため、scriptタグに autostart="false" を付けて自動起動を無効化し、設定を渡した上で手動起動します。
実装例：Informationログを抑制する最小構成
以下は、Consoleに出ていたInformation系ログを抑制するための基本形です（概念）。
<!-- 1) Blazor の自動起動を止める -->
<script src="_framework/blazor.web.js" autostart="false"></script>
この設定を入れるだけで、SignalRクライアントがInformationレベルで出していたメッセージ（今回の「Normalizing」「WebSocket connected」など）が、基本的に表示されなくなります。
どこに書く？（Blazor 8.0で編集する場所の目安）
Blazor 8.0のテンプレートでは、blazor.web.js を読み込む箇所はプロジェクト構成によって異なります。まずはプロジェクト内で blazor.web.js を検索し、見つかった script を差し替えるのが確実です。
| 構成 | 代表的な配置場所 | 探すキーワード |
|---|---|---|
| Blazor Web App（.NET 8） | App.razor 末尾付近 | _framework/blazor.web.js |
| Blazor WebAssembly | wwwroot/index.html | Blazor.start / blazor.webassembly.js |
| 従来のBlazor Server | Pages/_Host.cshtml | blazor.server.js |
ログレベル設定の選び方：Warning以外も選べる
「Warning以上」にすると静かになりますが、開発中に接続周りを調査したいタイミングではInformationが役に立つこともあります。用途に応じてログレベルを切り替えるのがおすすめです。
| 設定例 | Consoleに出る量 | 向いている場面 |
|---|---|---|
builder.configureLogging("information") | 多め | 接続確立・再接続・URL周りを追いたい |
builder.configureLogging("warning") | 少なめ | 普段の開発。警告以上だけ拾って見落としを減らす |
builder.configureLogging("error") | かなり少なめ | 失敗だけ見たい。コンソールを徹底的に静かにしたい |
builder.configureLogging("none") | ほぼ出ない | デモや画面共有など、とにかく見た目を優先したい |
開発環境だけInformationに戻したい場合（簡易切り替え）
「普段はWarningで静かにしたいが、ローカル開発ではInformationも見たい」という場合、ホスト名を使って切り替えると手軽です。
<script src="_framework/blazor.web.js" autostart="false"></script>
<script>
const isLocal = location.hostname === "localhost" || location.hostname === "127.0.0.1";
const level = isLocal ? "information" : "warning";
Blazor.start({
circuit: {
configureSignalR: function (builder) {
builder.configureLogging(level);
}
}
});
この形なら、ローカルでは詳細ログを残しつつ、本番相当の環境では余計なInformationを抑えられます。
ログが大量に出る場合の見方：実は「再接続」が頻発していることもある
「Information: WebSocket connected …」が短い間隔で何度も出る場合、単にInformationがうるさいだけでなく、接続の張り直し（再接続）が頻発している可能性があります。ログを抑える前に、原因がないかだけ軽く確認しておくと安心です。
| 状況 | 起こりがちな原因 | まず見る場所 |
|---|---|---|
| タブの復帰・スリープ復帰の直後にだけ増える | 端末の省電力でWebSocketが切れる | ChromeのNetworkタブ（WSの切断タイミング） |
| 会社ネットワークでだけ不安定 | プロキシ/ファイアウォールでWebSocketが不安定 | Networkタブ、サーバー側の接続ログ |
| サブパス配下で公開すると接続に失敗する | ベースパスやリライト設定の不整合 | 「Normalizing」の出力先URLと実際の公開パス |
本当に問題がないケースでは、今回のようにログレベルを上げて「普段は静かに運用」が最適解になります。一方で、接続が切れて機能に影響が出ているなら、Warning以上にも接続関連の警告が出ることがあるため、そこはログを消さずに対処した方が結果的に早いです。
よくある勘違い：builder.Logging.SetMinimumLevel を上げてもChromeのログは消えない
次のような設定は、ASP.NET Core（サーバー側）のログ制御です。
// Program.cs（例）
builder.Logging.SetMinimumLevel(LogLevel.Warning);サーバーのログが静かになるのは有益ですが、今回問題になっているのはブラウザー上の blazor.web.js / SignalRクライアントが出すログです。つまり、サーバー側のログ設定だけでChrome ConsoleのInformationログを止めようとすると「設定したのに変わらない」という状態になりやすい、というわけです。
ハマりどころ：設定してもログが減らないときのチェックリスト
手順通りに書いたつもりでも、状況によってはログが減らないことがあります。原因の切り分けに使えるチェックポイントをまとめます。
- scriptタグを差し替えた場所が正しいか：アプリのホストページに
blazor.web.jsが複数回読み込まれていないかも確認します。 autostart="false"が付いているか：付け忘れると起動が先に走り、後の設定が効きません。Blazor.start(...)を二重に呼んでいないか：二重起動はエラーや挙動不審の原因になります。- 別のJavaScriptがconsole出力していないか：拡張機能や別ライブラリのログと混ざる場合があります。
- ブラウザーキャッシュが残っていないか：script差し替え後はハードリロード（キャッシュ無視）で確認すると確実です。
応急処置：Chrome DevTools側でInformationを非表示にする
コードを触れない状況や、今すぐ見やすくしたいだけなら、Chrome DevToolsのConsoleで表示レベルを絞る方法もあります。例えば、Console上部のレベルフィルターでInfo（またはVerbose/Info）を外すと、Information相当が見えなくなります。
ただしこれは「表示を隠すだけ」であり、根本的にログ出力が止まるわけではありません。チーム開発で再現手順を共有する場合や、将来の運用を考える場合は、やはりSignalRクライアントのログレベルを適切に設定する方が管理しやすいです。
まとめ：Blazor 8.0のChromeコンソールを静かにする最短ルート
Blazor 8.0実行時にChromeコンソールへ出続ける「Information: …」は、blazor.web.jsが内部で利用するSignalR（WebSocket）のクライアント側ログです。サーバー側のログ設定では止まりにくいため、auto-startを無効化し、Blazor.start() で configureSignalR → configureLogging("warning")の順に設定して抑制するのが効果的です。
まずはWarningに上げてコンソールを整理し、接続問題を調査したいときだけInformationに戻す、といった使い分けをすると、開発効率とトラブルシューティングの両方でメリットがあります。
コメント