Microsoftの.NETアップデートで印刷が止まりました。本当の教訓は何でしょうか

WPF（Windows Presentation Foundation）は、Microsoftが開発したWindowsデスクトップアプリケーション用のフレームワークで、.NET Framework上に構築されています。代表的なWPFアプリケーションには、WindowsベースのERP、会計、物流、エンジニアリング、管理系などの業務アプリが含まれます。WPFは長年にわたりMicrosoft .NET Frameworkで開発されてきたエンタープライズ向けソフトウェアで特に多く使われています。

レポート、ラベル、請求書などの印刷可能なドキュメントを生成するアプリケーション、特に Windows経由で印刷するERP、POS、WMSは、まず確認する価値があります。Microsoftが2026年8月に配布した.NET Framework用の累積更新プログラムが原因で、Calibriを含む特定のフォントを使用した場合に、一部のWPFアプリで印刷やPDF/XPS出力の生成が失敗する問題が発生しています。 The Registerが最初に報じました。もしチームがこの更新を適用した後に突然印刷でエラーが発生し始めた場合、これが原因である可能性が高いです。

実際に何が問題になったのか

Microsoftの 8月11日付の.NET Framework更新プログラムが 一部のWPFアプリに次の例外をスローさせる原因となっています。 System.IO.FileFormatException 印刷やPDF/XPSの生成時に発生し、2007年以降Wordの既定フォントであるCalibriを含む特定のフォントの処理方法に起因します。この不具合はWindows 10、Windows 11、および2012年から2025年までのサポート対象のWindows Server各バージョンに影響し、フォントレンダリングの問題として影響範囲が非常に広いです。

Microsoftの対処は、設定ファイルのスイッチです。 Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtectionこの保護機能は、同じ8月のアップデートでセキュリティ上の脆弱性を修正するために追加されました。印刷の問題を解決するためにこれを無効化することは、数日前に意図的に導入された修正を元に戻すことを意味します。Microsoftもガイダンスでその点を示しており、このスイッチを一時的な対処と位置づけ、アップデートで修正された脆弱性に再びさらされる可能性があると警告しています。

Microsoftは現在も調査を続けており、正式な修正の提供時期は未定です。

パッチを適用する場合の注意点

ユーザーがこの問題に遭遇した場合、Microsoftの設定スイッチ（下記）を有効にすると、新しいフォント処理の保護が無効になり、印刷が再開します。ただし、Microsoft自身の説明どおりセキュリティ面では一歩後退となるため、あくまで一時的な対応です。この方法を採る場合は、どのマシンに適用したかを記録し、本格的な修正が提供されたら速やかに元に戻せるようにしてください。

応急処置。 影響を受けるアプリケーションの設定ファイルで、 <runtime>セクションの下に追加してください。これはアプリケーション単位の設定で、マシン全体には適用されません。そのため、もしアプリケーションにすでに <runtime> セクションに、ファイルを置き換えずにこの行を追加してください。

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection=true"/>
  </runtime>
</configuration>

長期的に見れば重要なのはこの一件のバグ自体ではなく、環境における印刷の位置づけです。印刷がWindowsの完全なスタック（ドライバー、印刷スプーラー、.NET、WPF、そしてアプリが取り込むその他の要素）に依存していると、当該パッチが印刷に関係するかどうかにかかわらず、そのスタックに含まれるあらゆるパッチのリスクを負うことになります。

Windowsに依存しない印刷環境の構築

このバグは、印刷ジョブがezeepを含む下流のどのコンポーネントにも到達する前に、WPFアプリ自体の内部で発生します。これは、25年以上のエンタープライズ向け印刷の経験があっても起こり得ることです。MicrosoftがWindows Protected Print Mode以降に進めてきたWindows印刷スタックの変更はこうしたパターンの一例であり、組織内で何をどのように印刷しているかを見直し、アプリが許す範囲でWindowsへの依存を減らすべき理由になっています。

WPFアプリに限れば、このバグはリスクの所在を明確に示しています。WPFは独自の印刷パイプライン（PrintDialog, FixedDocument, XpsDocument）を備えており、コンテンツのレンダリングと印刷またはPDF出力を同一のステップで行います。開発者にとっては最も手間のかからない経路で、追加のライブラリを導入する必要もなく、そのまますぐに動作します。そして、今回問題を引き起こしたのはまさにこのコードです。

WPFのフォントサブセットやレンダリングに一切触れない別のPDFライブラリで出力を作成すれば、この特定のコードへの依存をなくせます。それに加えて ezeepのAPI （またはその MCP server（AI支援の開発ツールで構築されたアプリ向け）で印刷を処理すると、アプリはこの特定のバグだけでなく、Windowsの印刷スタック全体への依存からも解放されます。 倉庫ラベルは注文イベントから直接、請求書は会計ソフトから、レポートはスケジュールに沿って印刷できます。これらはすべて、ログインしたユーザーや印刷ダイアログを介さずに行えます。

これは、すでに問題のあるアップデートが適用されたマシンを修復するものではありません。次にWindowsの印刷スタックでバグが発生しても自社の問題にならないよう、次期バージョンのアプリをその前提で設計するための提案です。