Windows 11のMicrosoft EdgeでPDFが開けない「Client side error is found」の原因と対処(AjaxRequestSettings/ServerActionSettings完全ガイド)

Windows 11 の Microsoft Edge で PDF を開こうとすると「Client side error is found…」という英語の警告が出て表示できない――。この症状は、PDF の配信に Ajax+カスタムヘッダーを使うサイトで起きがちです。本稿では、今すぐの回避策から、開発・運用側での恒久対応までを具体的な手順とチェックリストで整理します。

目次

症状とメッセージ

特定のサイトで PDF を開こうとした際、Edge の画面や埋め込みビューア上に次のメッセージが表示され、PDF が表示されないことがあります。

“Client side error is found. Please check the custom headers provided in the AjaxRequestSettings property and web action methods in the ServerActionSettings property.”

これはクライアント側(ブラウザー)での処理中に、Ajax リクエストやサーバー動作を前提とした PDF ビューアの処理が失敗していることを示唆します。多くの場合、サーバー側で設定すべき HTTP ヘッダーや CORS、認証ヘッダーの取り扱いに不整合がある、または ビューアが期待する「AjaxRequestSettings / ServerActionSettings」の実装が誤っていることが原因です。ユーザー側では完全修復が難しいため、まずは「一時回避」→「切り分け」→「サイト管理者への報告」という順序で進めるのが効率的です。

結論(まず何をすればよいか)

  • 今すぐ見たい:PDF を一旦ダウンロードしてローカルで開く/別ブラウザーを試す。
  • ブラウザー起因の切り分け:拡張機能をオフ、キャッシュ/Cookie を削除、InPrivate で再試行、Edge と Windows を最新に更新。
  • 恒久的な解決:サイト運営側に URL・発生時刻・再現手順・HAR ログを添えて報告。サーバーのヘッダー/CORS/認証/Range 対応/コンポーネント設定(AjaxRequestSettings/ServerActionSettings)を修正してもらう。

クイック対処一覧(ユーザー向け)

対処内容ポイント
① ダウンロードしてローカルで開くPDF リンクを右クリック → 「名前を付けてリンク先を保存」で保存し、保存後に Edge または Adobe Acrobat Reader で開く。ブラウザー内ビューアを迂回する最も簡単な回避策。
② 別ブラウザーを使う同じ URL を Google Chrome や Firefox、Edge の InPrivate で試す。サイト固有のスクリプトやヘッダー処理を回避できるケースが多い。
③ Edge 拡張機能を無効化設定 → 拡張機能で、PDF 閲覧・セキュリティ・広告ブロック系アドオンを一時的にオフにして再読み込み。拡張がリクエストヘッダーを改変し、ビューアが動作しない場合がある。
④ ブラウザーのキャッシュ・Cookie の削除設定 → プライバシー、検索、サービス → 閲覧データをクリアで、キャッシュされた画像とファイル・Cookie と他のサイトデータを削除。破損キャッシュや古い Cookie が Ajax エラーを誘発している可能性を除去。
⑤ Edge と Windows の最新更新を適用Windows Update と Microsoft Store(Edge のアプリ更新)から最新版へ。既知の不具合修正が含まれている場合がある。
⑥ サイト管理者へ連絡(恒久対策)エラー、対象 URL、発生時刻、再現手順、可能なら HAR(ネットワークログ)を添えて報告。
サーバー側の HTTP ヘッダー/CORS/認証/Range 対応/AjaxRequestSettings / ServerActionSettings の実装確認を依頼。
クライアント側だけでは完全解決できない。根本修正が必要。

なぜ起こるのか(技術的背景)

多くのサイトは、PDF を単純に「直リンクで配信」するのではなく、JavaScript の PDF ビューア(Syncfusion、Telerik、その他のコンポーネントや自作ビューワー)を用い、Ajax 経由で PDF バイナリやメタ情報を段階的に取得して表示します。この方式では、次の要素が正しく噛み合う必要があります。

  • HTTP レスポンスヘッダー:Content-Type: application/pdf、必要に応じて Content-Disposition: inline、Accept-Ranges: bytes(範囲リクエスト)など。
  • カスタムリクエストヘッダー:ビューアが付与するトークン・セッション情報・バージョン識別子等(例:X-... ヘッダー)。
  • CORS(クロスオリジン):埋め込み元と配信元が異なる場合、Access-Control-Allow-Origin、Access-Control-Allow-Headers、Access-Control-Allow-Credentials などが適切に設定されている必要。
  • 認証/Cookie:SSO・SAML・OpenID Connect 等の Cookie が SameSite=None; Secure であるか、サブドメイン跨ぎで正しく送受信できるか。
  • キャッシュ制御:認証済みコンテンツを no-store/private で返すか、逆に ETag/Last-Modified を使い差分最適化するかの整合。
  • サーバー/リバースプロキシ:Nginx/Apache/CDN が Range ヘッダーを透過し、カスタムヘッダーを削除しないこと。

これらのどれかが欠けると、ビューアが「想定したカスタムヘッダーを読めない」「プリフライト(OPTIONS)が失敗する」「Range 未対応で読み込み中に途切れる」といった現象につながり、冒頭のエラー文が表示されます。

ユーザー向け:詳細手順

PDF をダウンロードして開く

  1. PDF リンクを右クリックし、「名前を付けてリンク先を保存」を選択。
  2. ダウンロードしたファイルをエクスプローラーで右クリック → 「プログラムから開く」 → Edge または Adobe Acrobat Reader を選択。
  3. Windows の既定アプリで PDF を変更したい場合:設定 → アプリ → 既定のアプリ → ファイルの種類で既定のアプリを選ぶ → .pdf で Edge か Adobe を指定。

別ブラウザー・InPrivate での切り分け

Chrome/Firefox/Edge の InPrivate で同じ URL を開き、再現性を確認します。InPrivate は拡張機能と Cookie の影響を受けにくく、「ブラウザー環境」由来か「サイト側」由来かの判別に有効です。

拡張機能をオフにする

  1. Edge 右上の「…」 → 拡張機能。
  2. 広告ブロック、トラッキング防止強化、PDF/セキュリティ系などを一時的にオフ。
  3. ページを再読み込みし、改善があれば犯人特定のため 1 つずつオンに戻して再検証。

キャッシュ・Cookie を削除する

  1. Edge 右上の「…」 → 設定 → プライバシー、検索、サービス → 閲覧データをクリア。
  2. 「キャッシュされた画像とファイル」「Cookie と他のサイトデータ」にチェック → 消去。
  3. 業務システムの場合、SSO で再ログインが必要になる点に注意。

PDF に関する Edge 設定の見直し

設定箇所項目推奨備考
設定 → Cookie とサイトのアクセス許可 → PDF ドキュメント外部アプリで PDF を常に開くオフ(まずは Edge ビューアで試す)オンだと常に外部アプリへ迂回。表示できないサイトは一時的にオンも選択肢。
設定 → プライバシー、検索、サービストラッキング防止標準(バランス)厳重にするとカスタムヘッダーや Cookie の送信に影響する場合あり。検証時のみ一時変更。
設定 → ダウンロードダウンロード前に保存先を確認するオン保存してからローカルで開く回避策を取りやすい。

Edge/Windows を更新する

Windows Update と Microsoft Store から Edge を最新化します。企業環境では IT 管理者の配布ポリシーに従ってください。

企業・学校 PC での注意(管理者向け)

GPO(グループポリシー)や MDM(Intune 等)で PDF 関連の動作が固定されていると、ユーザーの設定変更が反映されません。以下を確認します。

ポリシー例目的推奨
Always open PDF files externally(PDF を常に外部で開く)Edge ビューアを使わず常に外部アプリへ。切り分け用途で一時的に 有効にするのは可。恒久は要要件検討。
Default PDF handler(既定 PDF ハンドラー)OS の既定 PDF アプリを制御。業務要件に合わせて Edge / Acrobat を明示。
SmartScreen/拡張機能制御セキュリティや拡張機能挙動の統制。過剰ブロックで Ajax/Cookie に影響しないか監査。

開発者・サイト管理者向け:恒久対策ガイド

以下は再発を防ぐための必須チェックです。Syncfusion などのコンポーネントで AjaxRequestSettings と ServerActionSettings を使っている場合は特に一致性を確認してください。

HTTP レスポンスヘッダーを正す

  • Content-Type:application/pdf を必ず返す。
  • Content-Disposition:埋め込み表示は inline; filename="..." を推奨。
  • Accept-Ranges:bytes を返し、Range リクエストに対応する。
  • Cache-Control:認証が必要な PDF は no-store、もしくは ETag/条件付き GET と整合する設定。

CORS とカスタムヘッダー

埋め込み元と PDF 配信元が異なる場合は CORS が鍵です。

  • Access-Control-Allow-Origin に埋め込み元オリジンを指定(ワイルドカード不可の場合あり)。
  • 認証 Cookie を使う場合は Access-Control-Allow-Credentials: true と SameSite=None; Secure の両立。
  • ビューアが送るカスタムヘッダー(例:X-SF-Token 等)を Access-Control-Allow-Headers に明示。
  • プリフライト(OPTIONS)に 2xx を返し、必要な Allow-* を含める。

ASP.NET Core(C#)の実装例

// Program.cs - CORS(必要なヘッダーは環境に合わせて)
builder.Services.AddCors(options =>
{
    options.AddPolicy("PdfPolicy", policy => policy
        .WithOrigins("https://viewer.example.com")
        .WithHeaders("Authorization", "Content-Type", "X-SF-Token", "X-Requested-With")
        .WithMethods("GET", "OPTIONS")
        .AllowCredentials()
        .WithExposedHeaders("Content-Disposition", "Accept-Ranges", "ETag"));
});

var app = builder.Build();
app.UseCors("PdfPolicy");

// Controller - Range 対応で PDF を返す
[ApiController]
[Route("api/pdf")]
public class PdfController : ControllerBase
{
[HttpGet("{id}")]
public IActionResult Get(string id)
{
// 実際は認可チェックやストレージからの取得などを実装
var stream = System.IO.File.OpenRead($"/data/{id}.pdf");


    // Range 対応(.NET 6 以降)
    var fileResult = File(stream, "application/pdf", enableRangeProcessing: true);
    Response.Headers["Content-Disposition"] = $"inline; filename=\"{id}.pdf\"";
    Response.Headers["Accept-Ranges"] = "bytes";
    Response.Headers["Cache-Control"] = "no-store";

    // ビューアが期待するカスタムヘッダーを付与(必要に応じて)
    Response.Headers["X-SF-Token"] = "some-value";

    return fileResult;
}


} 

Syncfusion(例)での設定ポイント

コンポーネントのバージョン差異に留意しつつ、代表的なポイントを示します。

  • AjaxRequestSettings:送信するカスタムヘッダー(トークン等)を定義。サーバー側で 受理するヘッダー名を CORS にも反映。
  • ServerActionSettings:サーバー処理の URL、操作メソッドを定義。コントローラー側のアクションで application/pdf と Range を扱えるように。
  • ライブラリは最新へ更新。古い版では Edge/Chromium の制約変更に追随できないことがある。
  • EnableCaching=”false” 等で不要なキャッシュを抑止し、認証付き配信の整合を取る。

Nginx/Apache リバースプロキシの注意

# Nginx の例
location /pdf/ {
    proxy_pass http://app;
    proxy_http_version 1.1;


# Range を透過
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;

# CORS(必要に応じて)
add_header Access-Control-Allow-Origin https://viewer.example.com always;
add_header Access-Control-Allow-Credentials true always;
add_header Access-Control-Allow-Headers Authorization,Content-Type,X-SF-Token,X-Requested-With always;
add_header Access-Control-Expose-Headers Content-Disposition,Accept-Ranges,ETag always;


}

# Apache(抜粋)

Header always set Access-Control-Allow-Origin "[https://viewer.example.com](https://viewer.example.com)"
Header always set Access-Control-Allow-Credentials "true"
Header always set Access-Control-Allow-Headers "Authorization, Content-Type, X-SF-Token, X-Requested-With"
Header always set Access-Control-Expose-Headers "Content-Disposition, Accept-Ranges, ETag" 

クラウドストレージ配信時の落とし穴

  • オブジェクトの Content-Type が application/pdf になっているか。
  • 署名付き URL(SAS・Signed URL)で Content-Disposition=inline を指定しているか。
  • ストレージの CORS ルールに、必要な Allow Origin / Headers / Methods が入っているか。

認証と Cookie の相性

  • iframe 埋め込みやサブドメイン跨ぎの場合、認証 Cookie は SameSite=None; Secure が必要。
  • 認証トークンをヘッダーに載せる場合は、そのヘッダー名を Access-Control-Allow-Headers に含める。
  • リダイレクト(302)で認証画面へ飛ばすと、Ajax 側では 「成功なのに本文が HTML」 という事態になりやすい。JSON で 401/403 を返すなど API としての一貫性を確保。

キャッシュ戦略の整合

  • 機密 PDF:Cache-Control: no-store 推奨。
  • 大容量 PDF:ETag と Range を併用し、断続的な再開ダウンロードに備える。
  • CDN を挟む場合、Vary と Authorization の扱いに注意。誤ると他ユーザーにキャッシュが漏れる。

Service Worker/SPA の介在

Service Worker が fetch をフックしている環境では、PDF のレスポンスヘッダーが書き換わる/欠落することがあります。PDF パスを「ネットワークへ素通し」するルールを設けるか、PDF 配信は別オリジンで行い SW のスコープ外に置くことを検討してください。

原因切り分けの実践手順

開発者ツール(F12)での調査

  1. Edge で対象ページを開き、F12 → Network タブ。
  2. フィルタに pdf と入力して関連リクエストを抽出。
  3. 問題のリクエストを選び、Headers で以下を確認:
    • Request Headers:期待するカスタムヘッダーが付与されているか。
    • Response Headers:Content-Type: application/pdf、Accept-Ranges: bytes、Content-Disposition: inline があるか。
    • ステータス:200/206 か、302/401/403/500 になっていないか。
  4. 右クリック → Save all as HAR with content で HAR を保存。サイト管理者に提供。
  5. Console タブにエラーがあればテキストをコピーして共有。

テストマトリクス

条件状態期待結果備考
Edge(拡張オン)通常モード再現する/しないのいずれか再現するなら拡張の影響を疑う。
Edge(拡張オフ)通常モード改善すれば拡張が原因どの拡張かを 1 つずつ検証。
Edge InPrivate一時プロファイル改善すれば Cookie/キャッシュ起因業務 Cookie の再ログインが必要。
Chrome/Firefox最新同様に再現/非再現非再現なら Edge 固有または拡張/ポリシー影響。

補足情報(開発者向け)— 要点まとめ

  • Content‑Type を application/pdf に。
  • CORS ポリシーや認証ヘッダー(例:Authorization、Cookie)を Ajax 経由で正しく付与。
  • ASP.NET MVC/Syncfusion 等では、AjaxRequestSettings と ServerActionSettings はコンポーネントのプロパティ。最新版ライブラリに更新し、EnableCaching="false" などでキャッシュ制御を見直すと改善することがある。

よくある質問(FAQ)

Edge だけで発生します。ブラウザーの問題ですか?

ブラウザー差はありますが、根本はサーバー側設定(CORS/Range/認証/カスタムヘッダー)であることが大半です。Edge 固有の拡張機能やポリシーが影響する可能性もあるため、InPrivate・拡張オフ・別ブラウザーでの切り分けが有効です。

Adobe Acrobat Reader に切り替えれば安全ですか?

表示は安定しやすいものの、業務アプリが Ajax ベースのビューワーを前提にしている場合は機能(注釈・検索・ブックマーク連携等)が変わる可能性があります。恒久的にはサイト側修正が望ましいです。

セキュリティを弱めれば表示できますか?

一時検証としてトラッキング防止レベルを下げることはありますが、常用は推奨しません。セキュリティ設定を変更して改善した場合は、その事実を根拠としてサイト管理者へ報告し、安全な構成で動作するよう修正してもらいましょう。

モバイル端末でも同じ対処ですか?

基本方針は同じです。モバイルブラウザーは拡張機能の影響が小さいため、よりサーバー側の設定不備が露呈しやすくなります。

IE モード(レガシー)を使えば解決しますか?

一時的に動作が変わる可能性はありますが、推奨されません。モダンブラウザーの制約(CORS、Cookie、セキュリティモデル)に合わせてサーバー実装を正すことが本質的な解決です。

運用のベストプラクティス

  • 監視:サーバー側で 4xx/5xx とプリフライト失敗(OPTIONS)をモニタリング。
  • ログ:重要ヘッダー(Origin、Range、Authorization の有無、Set-Cookie、Vary など)をマスキング前提で記録。
  • 更新:PDF ビューア・JS ランタイム・サーバーフレームワークを定期更新し、Breaking Changes に追随。
  • リハーサル:CDN/WAF/プロキシ設定変更の前後で PDF 表示の回帰テストを自動化。

ユーザーからサイト管理者へ伝えるテンプレート

【現象】Windows 11 + Microsoft Edge で PDF が表示できない
【メッセージ】"Client side error is found. Please check the custom headers..."
【URL】https://<問題のページ>
【発生日時】2025-xx-xx xx:xx(タイムゾーン)
【再現手順】
  1) ページを開く → 2) PDF ボタンをクリック → 3) エラー表示
【検証結果】
  - Chrome/Firefox:<再現/非再現>
  - InPrivate/拡張オフ:<改善/変化なし>
【添付】HAR(保存したネットワークログ), スクリーンショット
【要望】CORS/認証/Range/Content-Type、AjaxRequestSettings/ServerActionSettings の設定確認と修正

まとめ

Edge での「Client side error is found…」は、見かけ上はクライアントエラーでも、実体は サーバー側のヘッダー/CORS/認証/Range 対応/コンポーネント設定の不整合が主因です。ユーザーはまず「保存してローカルで開く」「別ブラウザー」「拡張オフ」「キャッシュ削除」「最新化」という応急処置で閲覧可否を確保しつつ、サイト運営側に再現情報と HAR を提供して恒久対策を依頼しましょう。開発・運用側は、Content-Type: application/pdf、Range 対応、CORS、Cookie の SameSite、カスタムヘッダーの取り扱い、Syncfusion 等のコンポーネント設定の整合を一つひとつ是正することで、安定して Edge でも表示できる環境を再構築できます。

参考:チェックリスト(配布用ミニポスター)

項目見るべき値OK 条件
Content-Typeapplication/pdfPDF で固定されている
Content-Dispositioninline / attachment埋め込みなら inline
Accept-RangesbytesRange 対応あり
CORSAllow-Origin / Headers / Credentials埋め込み元に一致、必要ヘッダーを許可
認証 CookieSameSite=None; Secureクロスサイトでも送信される
プリフライトOPTIONS 2xx必要な Allow-* を返す
キャッシュno-store/ETag要件に応じた一貫性
プロキシ/CDNRange 透過/ヘッダー保持削除・書換なし
コンポーネントAjaxRequestSettings / ServerActionSettingsバージョン最新・設定整合

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次