IronPDF チュートリアル PDF アクセシビリティ (PDF/UA) C# での PDF アクセシビリティ: PDF/UA ドキュメントの作成、変換、検証 カーティス・チャウ 更新日:2026年2月24日 IronPDF をダウンロード NuGet ダウンロード DLL ダウンロード Windows 版 無料トライアル LLM向けのコピー LLM向けのコピー LLM 用の Markdown としてページをコピーする ChatGPTで開く このページについてChatGPTに質問する ジェミニで開く このページについてGeminiに問い合わせる Grokで開く このページについてGrokに質問する 困惑の中で開く このページについてPerplexityに問い合わせる 共有する Facebook で共有 Xでシェア（Twitter） LinkedIn で共有 URLをコピー 記事をメールで送る This article was translated from English: Does it need improvement? Translated View the article in English アクセシビリティに関する法律は、 .NET開発者にとって将来の懸念事項ではなくなりました。 ここでは期限は現実であり、罰則は執行可能です。 PDF/UA C#準拠、アクセス可能な PDF .NET生成、 Section 508 PDF C#準拠、およびWCAG PDF 準拠 C#は、政府、医療、教育、法律、金融サービスに関わるチームビルディング ドキュメント ワークフローの日常的な要件となっています。 IronPDFは、タグ付きPDFエンジン、RenderHtmlAsPdfUAのメソッド、バッチ変換機能、クロスプラットフォーム for .NETランタイムサポートを提供し、レガシーアーカイブの変換やHTMLからのアクセシブルなドキュメントの生成に関わらず、PDF/UA-1およびPDF/UA-2の基準に準拠したPDF出力を可能にします。 TL;DR: クイックスタート ガイド このチュートリアルでは、規制のコンテキストから実装、検証、大規模な修復まで、C# での PDF/UA アクセシビリティについて説明します。 -対象者: PDF を作成、変換、または配布するアプリケーションでのドキュメントのアクセシビリティを担当する.NET開発者、アーキテクト、コンプライアンス リーダー。 これには、セクション 508 監査の準備をしている政府請負業者、アクセス可能なレポート パイプラインを構築している SaaS チーム、ADA Title II の期限に間に合うようにドキュメント修復プロジェクトを計画しているエンタープライズ アーキテクトが含まれます。 構築する内容: 既存のPDFからのConvertToPdfUAによるメモリ内変換、並列処理とエラーハンドリングを使用したバッチ修正パイプライン、およびveraPDFとMatterhornプロトコルを使用した検証ワークフロー。 -実行環境: .NET 6+、. .NET Framework 4.6.2+、. .NET標準2.0。Windows、Linux、macOS、Docker、Azure、AWS。 すべてのレンダリングでは、外部ブラウザに依存しない IronPDF の組み込み Chromium エンジンが使用されます。 -このアプローチを使用する場合: PDF が、セクション 508、ADA タイトル II (期限 2026 年 4 月/2027 年)、EU アクセシビリティ法 (2025 年 6 月)、または組織の WCAG 2.1 レベル AA ポリシーで義務付けられているアクセシビリティ標準を満たす必要がある場合。 -技術的に重要な理由: IronPDF の Chromium レンダリング エンジンは、変換を通じて HTML のセマンティック構造を保持し、見出し、リスト、表、代替テキストが PDF 構造要素に直接マップされるタグ付き PDF を生成します。 既存ファイルの単一メソッドSaveAsPdfUA変換と組み合わせることで、手動のタグ操作なしで生成パスと修正パスの両方を得られます。 既存の PDF を 2 行で PDF/UA 形式に変換します。 IronPDF をNuGetパッケージマネージャでインストール PM > Install-Package IronPdf このコード スニペットをコピーして実行します。 using IronPdf; PdfDocument pdf = PdfDocument.FromFile("quarterly-report.pdf"); // Convert and save asPDF/UA-1compliant pdf.SaveAsPdfUA("quarterly-report-accessible.pdf"); 実際の環境でテストするためにデプロイする 今日プロジェクトで IronPDF を使い始めましょう無料トライアル Free 30 Day Trial IronPDFを購入または30日間のトライアルにサインアップした後、アプリケーションの最初にライセンスキーを追加してください。 IronPdf.License.LicenseKey = "KEY"; IronPdf.License.LicenseKey = "KEY"; $vbLabelText $csharpLabel 今日あなたのプロジェクトでIronPDFを無料トライアルで使用開始。 最初のステップ： 無料で始める 購入の準備ができていませんか？ PM > Install-Package IronPdf IronPDF を NuGet でチェックしてください。1000万回以上のダウンロードで、C#によるPDF開発を変革しています。 DLL または Windowsインストーラー をダウンロードすることもできます。 目次 -標準を理解する PDF/UA とは何ですか? なぜ今必須になっているのですか? -法的な転換点 PDF/UAに実際に必要なもの PDF/UA vs WCAG: 2つの標準規格の連携 -遡及要件 PDF/UA バージョン間の違いは何ですか? PDF/UA-1 (ISO 14289-1、PDF 1.7 ベース) PDF/UA-2 (ISO 14289-2:2024、PDF 2.0 に基づく) WTPDF（適切にタグ付けされたPDF）とその関連性 -どのバージョンをターゲットにすべきですか? HTMLから生成 HTML からアクセシブルな PDF を作成するにはどうすればよいですか? -アクセシビリティ対応の HTML の作成 RenderHtmlAsPdfUAを使用したHTMLからPDF/UAへのレンダリング -変換による構造の維持 -アクセシビリティを損なう一般的なHTMLパターン -バージョン管理 PDF/UA-1 とPDF/UA-2のどちらを選択すればよいですか? -デフォルト出力（PDF/UA-1） -バージョンパラメータを使用してPDF/UA-2としてエクスポート PDF/UA-2 を使用する場合 -検証 PDF/UA コンプライアンスをどのように検証しますか? -自動検証のためのveraPDFの使用 -マッターホルンプロトコルを理解する -よくあるコンプライアンス違反とその解決方法 フォント、カラースペース、およびメタデータの要件。 -自動化では検出できない手動チェック -大規模な修復 -準拠していない PDF を大規模に修正するにはどうすればよいですか? -ドキュメントライブラリを PDF/UA に一括変換 80～90%の自動アクセシビリティ変換を実現 -修復の優先順位付け PDF/UAとマージ、署名、メタデータワークフローを組み合わせる -実世界への応用 -実際の PDF/UA コンプライアンスの使用例は何ですか? PDF/UA と PDF/A の二重準拠をどのように実現しますか? -アーカイブとアクセシビリティの両方が必要な場合 PDF/UAとデジタル署名の組み合わせ -進化する標準規格に対応した将来を見据えた文書 PDF/UA とは何ですか? なぜ今必須になっているのですか? PDF のアクセシビリティは、かつてはチームが最終的に取り組むものでした。 ベストプラクティスであり、厳密な要件ではありません。 それは変わりました。 厳格な期限が定められた複数の重複した規制により、現在では多くの組織にとってそれが法的義務となっており、違反した場合の影響は監査の指摘から訴訟まで多岐にわたります。 法的な転換点 3 つの規制の進展により、PDF/UA コンプライアンスが緊急なものとなりました。 これらは理論上のリスクではありません。 アクセシビリティ訴訟は年々増加しており、裁判所は一貫して、デジタル文書は障害者差別法の適用範囲に含まれるとの判断を下しています。 アクセシビリティを将来の問題として扱う組織では、数か月または数年前に自社のソフトウェアで作成された文書に対する苦情、監査結果、訴訟を弁護しなければならない状況が増えています。 リハビリテーション法第508条は、米国 連邦政府機関とその請負業者は、長年にわたってアクセシブルな電子情報技術を生み出すことに尽力してきました。 PDF は明示的にカバーされます。 ソフトウェアが連邦政府機関によって、または連邦政府機関に代わって使用される文書を生成する場合、それらの文書はアクセス可能でなければなりません。 司法省は苦情を調査し、違反している組織に対して強制措置を講じます。 ADA Title II は、アクセシビリティ義務を州政府および地方政府にまで拡大します。 2024年に公表された司法省の最終規則では、人口5万人以上の事業体については2026年4月、小規模事業体については2027年4月を遵守期限と定めた。 適用範囲は広く、政府の Web サイトで公開される、電子メールで配布される、または構成員向けアプリケーションを通じて生成されるすべての PDF は、WCAG 2.1 レベル AA に準拠する必要があります。 これには、会議の議題、予算書、許可申請書、裁判記録、区画地図、評議会の議事録など、さまざまな文書の種類が含まれます。 欧州アクセシビリティ法 (EAA) は2025 年 6 月に施行され、EU で販売される製品とサービスはアクセシビリティ要件を満たすことが求められます。 EU の顧客にサービスを提供するソフトウェア企業の場合、アプリケーションが生成するドキュメントにアクセス可能である必要があります。 これは政府に限ったことではありません。 これは、幅広いカテゴリーにわたる民間部門の製品およびサービスに適用されます。 PDF/UAに実際に必要なもの PDF/UA (ISO 14289) は、支援技術が PDF を確実に処理するために満たす必要がある技術要件を定義します。 準拠文書には次の内容が含まれている必要があります。 完全なタグ構造。 すべての意味のあるコンテンツは、標準のPDFタグを使用して論理構造ツリーで表現されなければなりません。<l>はリスト用です。 純粋に装飾的なコンテンツは、スクリーン リーダーがスキップできるようにアーティファクトとしてマークする必要があります。 正しい読み上げ順序。タグツリーは、ページに表示される視覚的な順序ではなく、コンテンツが読み上げられる論理的な順序を反映する必要があります。 複数列のレイアウトやサイドバーのあるドキュメントの場合、この区別は非常に重要です。 非テキストコンテンツの代替テキスト。 情報を伝えるすべての画像、チャート、ダイアグラムには、<Figure>タグにaltテキストを添付する必要があります。 装飾画像はアーティファクトとしてマークする必要があります。 適切なメタデータ。ドキュメントは自然言語（例：英語の場合は"en"）を宣言し、意味のあるタイトルを持ち、XMPメタデータにPDF/UA識別子を含める必要があります。 Unicode マッピング付きの埋め込みフォント。すべてのフォントは埋め込まれている必要があり、テキストを正確に抽出して読み上げるためには、Unicode 文字マッピング（ToUnicode CMap）が存在している必要があります。 PDF/UA vs WCAG：2つの標準規格の連携 開発者は、PDF/UA と WCAG のどちらをターゲットにすべきかよく尋ねます。 答えは両方です。なぜなら、それらは異なるレイヤーで動作するからです。 WCAG (Web コンテンツ アクセシビリティ ガイドライン) は、Web コンテンツのアクセシビリティの原則と成功基準を定義します。 これは、セクション 508、ADA Title II、および EAA によって参照される標準です。 WCAG は、アクセシブルなコンテンツが実現すべきこと、すなわち、認識可能、操作可能、理解可能、堅牢性について規定しています。 PDF/UAは、PDFファイル内でこれらの目的を達成する方法を規定する、技術的な実装標準です。 PDF/UA に準拠した PDF は、ドキュメント コンテンツに適用される WCAG 成功基準を満たします。 これら 2 つの規格は競合するものではなく、補完的なものです。 実際には、ワークフローによって PDF/UA 検証に合格する、タグ付きの適切に構造化された PDF が生成される場合、WCAG 準拠にも十分対応できることになります。 遡及要件 組織が不意を突かれる 1 つの点は、これらの規制が新しい文書にのみ適用されるわけではないということです。 ウェブサイトで公開されたり、アプリケーションを通じて配布された既存の PDF も修正する必要がある可能性があります。 ADA Title II では、州政府および地方自治体が公開する Web コンテンツ (PDF を含む) が WCAG 2.1 レベル AA に準拠することが求められています。 レガシードキュメントに対する包括的な免除はありません。 このため、プログラムによる変換ツールが不可欠になります。 何千もの PDF を手動で修正するのは現実的ではありません。 バッチ修復パターンについては、このチュートリアルの後半で説明します。 PDF/UA バージョン間の違いは何ですか? PDF/UA-1(ISO 14289-1、PDF 1.7 に基づく) PDF/UA-1 は 2012 年に公開され、現在でもこの標準の中で最も広く採用されているバージョンです。 これは PDF 1.7 仕様に基づいており、タグ付き PDF 構造、メタデータ、フォント、および支援技術の互換性に関する包括的な要件セットを定義します。 veraPDF や Adobe Acrobat のアクセシビリティ チェッカーを含むほとんどの検証ツールは、PDF/UA-1 を主なターゲットとしてサポートしています。 新しいアクセシビリティ プロジェクトを開始し、既存のツールやワークフローとの幅広い互換性が必要な場合は、PDF/UA-1 が安全なデフォルトです。 これは、セクション 508、ADA Title II、および EU アクセシビリティ法の要件を満たしています。 PDF/UA-2(ISO 14289-2:2024、PDF 2.0 に基づく) PDF/UA-2 は 2024 年に公開され、重要な更新を表しています。 PDF 2.0 仕様 (ISO 32000-2:2020) に基づいて構築されており、注釈、フォーム フィールド、マルチメディア コンテンツ、複雑なドキュメント構造などの最新の PDF 機能の処理が改善されています。PDF/UA-2は、進化する Web アクセシビリティ標準との整合性も向上させます。 IronPDF は両方のバージョンをサポートしています。 以下のコード例に示すように、エクスポート時にどちらをターゲットにするかを指定できます。 WTPDF（適切にタグ付けされたPDF）とその関連性 Well-Tagged PDF の略である WTPDF への参照に遭遇することがあります。 PDF 協会が発行する WTPDF は、適切にタグ付けされた PDF を作成する方法を明確にする一連の技術ガイダンスです。 これは独立した標準ではなく、PDF/UA-2 および PDF 2.0 の実用的な補足資料です。WTPDF は、PDF/UA 仕様自体の定義を超えた、タグの使用、構造要素のマッピング、コンテンツのタグ付けに関する詳細なルールを提供します。 正式な標準と並んで存在する実装ガイドとして考えてください。 どのバージョンをターゲットにすべきでしょうか? PDF/UA-1 PDF/UA-2 出版 2012 2024 基本仕様 PDF 1.7 (ISO 32000-1) PDF 2.0 (ISO 32000-2) 規制対象範囲 ADA第II編第508条、EUアクセシビリティ法 同じ規制との互換性 検証ツール veraPDF、Adobe Acrobat Pro、PAC 2024 veraPDF（サポート拡大中） フォームフィールドのセマンティクス 標準 強化（アクセシビリティ メタデータの強化） 最適な用途 今日のほとんどのプロジェクト PDF 2.0の機能を必要とする新しいシステム 今日のほとんどのプロジェクトにとって、 PDF/UA-1は最適な選択肢です。最も幅広いツールサポートと最も成熟した検証エコシステムを備え、現在のあらゆる規制要件を満たしています。 強化されたフォーム フィールドのセマンティクス、改善された注釈処理、新しい標準との前方互換性などの PDF 2.0 機能が特に必要な場合は、PDF/UA-2 を選択します。 IronPDF はデフォルトでPDF/UA-1に設定されており、準備ができたら簡単にPDF/UA-2に切り替えることができます。 HTML からアクセシブルな PDF を作成するにはどうすればよいですか? アプリケーションがHTML コンテンツ (レポート、請求書、明細書、通信文) から PDF を生成する場合、事後に修正するのではなく、最初からアクセシビリティを組み込むことができます。 IronPDFのRenderHtmlAsPdfUAメソッドは、HTMLを直接PDF/UA準拠の出力にレンダリングし、結果の品質は大きくHTML入力の品質に依存します。 アクセシビリティ対応の HTML を書く アクセシブルな HTML は、アクセシブルなタグ付き PDF 構造に自然に変換されます。 最も重要な実践は次のとおりです。 セマンティックHTML要素を使用。 コンテンツを<section>のページ構造に対応させます。 すべての意味のある画像にaltテキストを提供。 すべてのalt属性を使用します。 装飾目的の画像には、空のalt=""を使用して、画像がアーティファクトとして扱われることを示します。 論理的な見出し階層を維持。 単一の<h1>で始め、レベルを飛ばさないこと。 文書が<h3>にジャンプすると、PDF出力に壊れた見出しツリーが生成されます。 フォームフィールドにラベルを付ける。 HTMLにフォーム要素が含まれている場合、すべての入力とfor属性を使って関連付けます。 文書の言語を設定。 あなたのlang属性を含める (例: <html lang="en">)。 RenderHtmlAsPdfUAを使用したHTMLからPDF/UAへのレンダリング 以下は、アクセス可能な HTML ドキュメントを PDF/UA に直接レンダリングする完全な例です。 セマンティック見出し、データ テーブル、順序付きリスト、代替テキスト画像を含む HTML 文字列を PDF/UA 準拠のドキュメントに直接レンダリングします。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-render-html.cs using IronPdf; ChromePdfRenderer renderer = new ChromePdfRenderer(); string accessibleHtml = @" <!DOCTYPE html> <html lang='en'> <head> <meta charset='UTF-8'> <title>Quarterly Accessibility Report</title> <style> body { font-family: Arial, sans-serif; line-height: 1.6; color: #333; max-width: 800px; margin: 0 auto; padding: 20px; } h1 { color: #1a1a1a; border-bottom: 2px solid #0066cc; padding-bottom: 8px; } h2 { color: #2a2a2a; margin-top: 24px; } table { border-collapse: collapse; width: 100%; margin: 16px 0; } th, td { border: 1px solid #ccc; padding: 10px; text-align: left; } th { background-color: #f0f0f0; font-weight: bold; } .summary { background-color: #f9f9f9; padding: 16px; border-left: 4px solid #0066cc; margin: 16px 0; } </style> </head> <body> <h1>Q3 2025 Accessibility Compliance Report</h1> <div class='summary'> <p>This report summarizes the accessibility remediation progress for all public-facing PDF documents across the organization.</p> </div> <h2>Document Inventory</h2> <p>The following table shows the current status of document remediation by department.</p> <table> <thead> <tr> <th scope='col'>Department</th> <th scope='col'>Total Documents</th> <th scope='col'>Compliant</th> <th scope='col'>Pending</th> </tr> </thead> <tbody> <tr> <td>Legal</td> <td>1,247</td> <td>892</td> <td>355</td> </tr> <tr> <td>Finance</td> <td>3,891</td> <td>3,102</td> <td>789</td> </tr> <tr> <td>Human Resources</td> <td>567</td> <td>401</td> <td>166</td> </tr> </tbody> </table> <h2>Key Findings</h2> <p>Three areas require immediate attention before the April 2026 deadline:</p> <ol> <li>Legacy court filing templates lack heading structure entirely.</li> <li>Financial statement PDFs generated before 2023 have no tagged content.</li> <li>HR onboarding packets contain scanned images without OCR text layers.</li> </ol> <h2>Remediation Timeline</h2> <p>The project team recommends prioritizing public-facing documents first, followed by internal documents accessed by more than 50 employees.</p> <img src='timeline-chart.png' alt='Gantt chart showing remediation phases: Phase 1 covers public documents from October through December 2025, Phase 2 covers internal documents from January through March 2026.' /> </body> </html>"; // Render directly to PDF/UA-compliant output PdfDocument pdf = renderer.RenderHtmlAsPdfUA(accessibleHtml); // Set document metadata (required by PDF/UA) pdf.MetaData.Title = "Q3 2025 Accessibility Compliance Report"; pdf.MetaData.Author = "Compliance Department"; pdf.SaveAs("accessibility-report-pdfua.pdf"); $vbLabelText $csharpLabel 出力 ご覧のとおり、セマンティック HTML 要素 (見出し、列ヘッダーを含むデータ テーブル、順序付きリスト、代替テキスト画像) は、レンダリングされた出力で適切な PDF/UA 構造タグとして保持されます。 変換による構造の保存 IronPDF は、Google Chrome や Microsoft Edge と同じテクノロジーである組み込みの Chromium レンダリング エンジンを使用します。 Chromium はすでに HTML セマンティクスを理解しているため、これはアクセシビリティにとって重要です。 IronPDF はHTML を PDF/UA にレンダリングするときに、HTML 要素を対応する PDF タグにマッピングします。 <h6>の見出しタグになります。 <p>の段落タグになります。 <td>の構造要素になります。 <li> (リストアイテム) を持つ<l> (リスト) になります。 altテキストを持つ/Altエントリがあります。 このマッピングは自動的に行われます。 PDF タグ ツリーを手動で構築したり、構造要素コードを記述したりする必要はありません。 アクセシビリティを損なう一般的なHTMLパターン 一般的にきれいな HTML を記述する開発者でも、アクセスできない PDF 出力を生成するパターンを使用する場合があります。 以下の点に注意してください: <div>をすべてに使用。 無スタイルの<div>要素から完全に構築されたドキュメントは、平坦で構造化されていないタグツリーを生成します。 スクリーン リーダーでは意味のあるナビゲーションができません。 代わりにセマンティック要素を使用してください。 CSSグリッドやフレックスボックスで表のシミュレーション。 CSSを使用して視覚的にグリッドレイアウトを示しても、実際の<table>要素でない限り、PDFに適切な表タグを生成しません。 コンテンツが表形式のデータである場合は、実際の<table>を使用します。 見出しレベルのスキップ。 <h3>にジャンプすると、見出し階層に空白が生じ、アクセシビリティチェッカーから失敗としてフラグされます。 altテキストのない画像。 <Figure>タグが生成され、これは直接のPDF/UA違反です。 画像に埋め込まれたテキスト。HTML に画像としてレンダリングされたテキスト（表のスクリーンショット、ラスタライズされたグラフなど）が含まれている場合、そのコンテンツはスクリーンリーダーには表示されません。 可能な限り実際の HTML テキストを使用し、残りの画像には包括的な代替テキストを指定します。 PDF/UA-1とPDF/UA-2のどちらを選択すればよいですか? デフォルト出力（PDF/UA-1） デフォルトでは、 IronPDF はPDF/UA-1 出力を生成します。PDF/UA-2をターゲットにする特別な理由がない限り、デフォルトのままにしてください。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-default-output.cs using IronPdf; PdfDocument pdf = PdfDocument.FromFile("standard-report.pdf"); // Default: saves as PDF/UA-1 pdf.SaveAsPdfUA("accessible-report.pdf"); $vbLabelText $csharpLabel 出力 同じレポートがPDF/UA-1に準拠し、完全なタグ構造と ISO 14289-1 識別子が XMP メタデータに埋め込まれています。 バージョンパラメータを使用してPDF/UA-2としてエクスポートする PDF/UA-2 が必要な場合は、バージョン パラメータを指定します。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-export-pdfua2.cs using IronPdf; PdfDocument pdf = PdfDocument.FromFile("modern-form.pdf"); // Export as PDF/UA-2 (based on PDF 2.0) pdf.SaveAsPdfUA("accessible-form-ua2.pdf", PdfUAVersions.PdfUA2); $vbLabelText $csharpLabel 出力 フォーム フィールドのアクセシビリティ メタデータがより豊富になった PDF 2.0 内部構造を使用して、PDF/UA-2 としてエクスポートされたフォーム。 ご注意上記の iframe プレビューには、ドキュメントの視覚的なコンテンツが表示されます。 ファイルに埋め込まれたPDF/UA-2準拠識別子と ISO 14289-2 XMP メタデータは、ビューアでは表示されません。 メタデータが存在することを確認するには、外部の PDF/UA バリデーターを使用してください。 メモリ内で変換して個別に保存することもできます。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-in-memory-pdfua2.cs using IronPdf; PdfDocument pdf = PdfDocument.FromFile("complex-document.pdf"); // Convert to PDF/UA-2 in memory pdf.ConvertToPdfUA(PdfUAVersions.PdfUA2); // Perform additional modifications pdf.MetaData.Title = "Complex Document - Accessible Version"; // Save the converted document pdf.SaveAs("complex-document-accessible.pdf"); $vbLabelText $csharpLabel 出力 メモリ内で変換されたドキュメントはPDF/UA-2として保存されます。注:PDF/UA-2は内部的に PDF 2.0 形式を使用します。 切り替える前に、ダウンストリーム ツールが PDF 2.0 をサポートしていることを確認してください。 PDF/UA-2を使用する場合 ドキュメントがPDF/UA-1では完全に対応できない PDF 2.0 機能に依存している場合は、PDF/UA-2 を検討してください。 これには、より豊富なセマンティック情報によるフォーム フィールドのアクセシビリティの強化、コメント、マークアップ、レビュー ワークフローの注釈処理の改善、PDF に埋め込まれたマルチメディア コンテンツのサポートの強化、PDF 2.0 に基づいて構築された新しいアクセシビリティ標準との前方互換性が含まれます。 今日のほとんどのコンプライアンス プロジェクトでは、PDF/UA-1 で十分です。PDF/UA-2は、従来のツールで出力を処理する必要のない新しいシステムにとって将来を見据えた選択肢です。 PDF/UA コンプライアンスをどのように検証しますか? PDF/UA ドキュメントの作成は作業の半分にすぎません。 出力が実際に標準を満たしているかどうかを確認する必要があります。 検証により、開発中に見逃されやすい問題が検出され、コンプライアンス監査に必要な文書化された証拠が提供されます。 veraPDFで検証する veraPDF は、PDF/UA および PDF/A 標準に照らして PDF をチェックするための、無料のオープンソースのコマンドラインおよび GUI ツールです。 変換されたファイルとua1プロファイルを渡してチェックします。 入力 検証の準備が整った IronPDF 生成の PDF/UA ドキュメント。 これはSaveAsPdfUAからの出力です。 verapdf --profile ua1 output-quarterly-report-accessible.pdf verapdf --profile ua1 output-quarterly-report-accessible.pdf SHELL 出力 136 回のチェックに合格、0 回が失敗しました。 IronPDFの出力はISO 14289-1に完全に準拠しています。HTMLレポートには、Matterhornプロトコルのすべてのチェックポイントとその結果がリストされます。 CLI を CI/CD パイプラインに統合して、本番環境に到達する前に回帰を検出します。 マッターホルン・プロトコルを理解する Matterhorn プロトコルは、PDF 協会が発行する一連のテスト条件であり、PDF がPDF/UA-1に準拠しているかどうかを正確にチェックする方法を定義します。 チェックは、136 の特定の障害条件をカバーする 31 のチェックポイントに編成されます。 各失敗条件は、PDF/UA-1 仕様の句にマッピングされます。 たとえば、チェックポイント 01 では、ドキュメント カタログに必要な PDF/UA 識別子が含まれているかどうかがチェックされます。 チェックポイント 06 では、すべてのフォントが有効な Unicode マッピングで埋め込まれているかどうかを確認します。 チェックポイント 13 では、グラフィックに適切な代替テキストがあるかどうかを確認します。 Matterhorn プロトコルを理解すると、検証結果を解釈し、修正の優先順位を決定するのに役立ちます。 すべての障害条件が同等の重みを持つわけではありません。 ドキュメントのタイトルが見つからない場合、5 分で修正できます。 完全にタグが付いていないドキュメントでは完全な変換が必要です。 よくあるコンプライアンス違反とその解決方法 PDF/UA 出力を検証するときに最も頻繁に発生する問題は次のとおりです。 ドキュメントのタイトルがありません。ドキュメントのメタデータにはタイトルエントリが含まれている必要があり、ViewerPreferences 辞書でウィンドウのタイトルバーにタイトル（ファイル名ではなく）が表示されるように指定する必要があります。 保存する前にメタデータを設定してこれを修正します。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-fix-document-title.cs using IronPdf; PdfDocument pdf = PdfDocument.FromFile("input.pdf"); // Set the required document title pdf.MetaData.Title = "Annual Budget Report - FY2025"; pdf.SaveAsPdfUA("budget-report-accessible.pdf"); $vbLabelText $csharpLabel 出力 出力はドキュメント タイトル チェックに合格し、ファイル名の代わりにタイトルが PDF ビューアーのウィンドウ タイトル バーに表示されるようになります。 図に代替テキストがありません。意味を伝える画像には必ず代替テキストが必要です。 レンダリングする前にソース HTML に追加するか、ソース PDF を直接修正します。 見出し階層が正しくありません。見出しレベルが省略されていたり、順序が間違っていたりする文書は検証に失敗します。 変換する前にソース内の見出し構造を修正します。 フォントが埋め込まれていないか、Unicodeマッピングがありません。これは通常、非標準のフォントエンコーディングを使用している古いPDFで発生します。 IronPDF は変換中にフォントの埋め込みを処理しますが、非常に古いまたは破損したソース ファイルには特別な注意が必要になる場合があります。 フォント、色空間、およびメタデータの要件 PDF/UA には、自動化ツールがチェックする視覚的なプレゼンテーションに関する特定の要件があります。 すべてのフォントは正しい ToUnicode マッピングを使用して埋め込む必要があります。 テキストは Unicode 文字として抽出可能である必要があります。 カラースペースはデバイスに依存しないか、関連付けられたICCプロファイルを持っている必要があります。フォームフィールドには適切なラベルと説明が必要です。 IronPDF は、変換中にフォント埋め込み、カラー スペース、構造要件を自動的に処理します。 このチュートリアル全体の例に示されているように、言語とメタデータはコード内で簡単に設定できます。 自動化では検出できない手動チェック アクセシビリティのいくつかの側面では、人間によるレビューが必要です。 自動検証ツールは、画像に代替テキストがあるかどうかはわかりますが、代替テキストが実際に役立つかどうかを判断することはできません。 見出しが存在することは確認できますが、見出しのテキストがそれに続く内容を正確に説明しているかどうかは検証できません。 優先度の高いドキュメントのワークフローに手動レビュー手順を組み込みます。 代替テキストが画像の内容を正確に説明しているかどうか、直線的に消費したときに読み上げ順序が論理的に意味を成しているかどうか、リンク テキストが説明的であるかどうか (単に"ここをクリック"ではない)、言語宣言がドキュメントの実際の内容と一致しているかどうかに注目します。 追加の検証ツール veraPDF は PDF/UA 準拠の自動チェックの標準ですが、他のツールも併用すると便利です。 Adobe Acrobat Pro には、"ツール">"アクセシビリティ">"完全チェック"にアクセシビリティ チェッカーが含まれています。 これは開発中の素早い視覚的なスポットチェックに役立ち、人間が読めるレポートを生成します。PDF/UA-1については、veraPDF ほど広範囲ではありませんが、ほとんどのチームで広く利用できます。 PDF Association のPAC 2024 (PDF アクセシビリティ チェッカー、Windows 用無料) は、PDF/UA および WCAG に対する準拠チェックとともに、視覚的なタグ ツリー検査を提供します。 これは、テキスト レポートではなく視覚的に読み取り順序と見出し構造を検査する場合に特に便利です。 Acrobat Reader では、"表示">"表示/非表示">"ナビゲーションパネル">"タグ"でタグパネルを直接開くことができます。 これは検証ツールではありませんが、Acrobat Pro を必要とせずに構造ツリーを素早く視覚的に検査できます。 最も信頼性の高いアプローチは、自動化された CI/CD チェック用の veraPDF と、優先度の高いドキュメント用の Acrobat または PAC での手動パスを組み合わせることです。 準拠していない PDF を大規模に修正するにはどうすればよいでしょうか? 大規模なドキュメント ライブラリを持つ組織の場合、個々のファイルの変換は現実的ではありません。 監査によってアーカイブがアクセシビリティ基準を満たしていないことが判明した場合、または期限が迫っていて処理すべき文書が何千もある場合、最小限の手動介入でボリュームを処理できるプログラムによるアプローチが必要です。 ドキュメントライブラリを PDF/UA に一括変換 IronPDFはスレッドセーフなので、複数のドキュメントを並行して処理できます。 以下は、同時実行制御、エラー処理、進行状況レポートを備えた本番レベルのバッチ変換実装です。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-batch-conversion.cs using IronPdf; using System; using System.Collections.Concurrent; using System.IO; using System.Linq; using System.Threading; using System.Threading.Tasks; public class PdfUaBatchConverter { private readonly SemaphoreSlim _semaphore; private readonly ConcurrentBag<string> _failures; private int _processed; public PdfUaBatchConverter(int maxConcurrency = 4) { _semaphore = new SemaphoreSlim(maxConcurrency); _failures = new ConcurrentBag<string>(); _processed = 0; } public async Task ConvertDirectoryAsync( string inputDirectory, string outputDirectory, NaturalLanguages language = NaturalLanguages.English) { Directory.CreateDirectory(outputDirectory); string[] pdfFiles = Directory.GetFiles(inputDirectory, "*.pdf"); int totalFiles = pdfFiles.Length; Console.WriteLine($"Starting PDF/UA conversion: {totalFiles} files"); Console.WriteLine($"Concurrency: {_semaphore.CurrentCount} parallel operations"); Console.WriteLine($"Language: {language}"); Console.WriteLine(new string('-', 50)); var stopwatch = System.Diagnostics.Stopwatch.StartNew(); var tasks = pdfFiles.Select(async inputPath => { await _semaphore.WaitAsync(); try { string fileName = Path.GetFileName(inputPath); string outputPath = Path.Combine(outputDirectory, fileName); using (PdfDocument pdf = PdfDocument.FromFile(inputPath)) { pdf.SaveAsPdfUA(outputPath, NaturalLanguage: language); } int count = Interlocked.Increment(ref _processed); // Log progress every 10 files if (count % 10 == 0 || count == totalFiles) { double rate = count / stopwatch.Elapsed.TotalSeconds; Console.WriteLine( $" [{count}/{totalFiles}] " + $"{rate:F1} files/sec"); } } catch (Exception ex) { _failures.Add( $"{Path.GetFileName(inputPath)}: {ex.Message}"); Interlocked.Increment(ref _processed); } finally { _semaphore.Release(); } }); await Task.WhenAll(tasks); stopwatch.Stop(); // Summary report Console.WriteLine(new string('-', 50)); Console.WriteLine($"Completed in {stopwatch.Elapsed.TotalSeconds:F1}s"); Console.WriteLine( $"Succeeded: {totalFiles - _failures.Count} " + $"Failed: {_failures.Count}"); if (_failures.Any()) { Console.WriteLine("\nFailed files:"); foreach (string failure in _failures) Console.WriteLine($" - {failure}"); // Write failures to log file for later review File.WriteAllLines( Path.Combine(outputDirectory, "_failures.log"), _failures); } } } // Usage var converter = new PdfUaBatchConverter( maxConcurrency: Environment.ProcessorCount); await converter.ConvertDirectoryAsync( inputDirectory: @"C:\Documents\Legacy", outputDirectory: @"C:\Documents\Accessible", language: NaturalLanguages.English ); $vbLabelText $csharpLabel 出力 処理されたファイル1つのPDF/UA-1出力です。このパターンは並列処理の制御、ファイルごとのエラーキャッチ、メモリリークを防ぐSemaphoreSlimベースの廃棄、および進行するファイル毎秒の進行率を使用します。 80～90%の自動アクセシビリティ変換を実現 コンプライアンス作業の残りの 10 ～ 20% には、複雑な画像に意味のある代替テキストを付ける、通常とは異なるレイアウトの読み取り順序を修正する、ソースで適切に構造化されていないドキュメントに意味的な見出しを割り当てるなど、人間の判断が必要です。 自動パスが完了したら、最も優先度の高いドキュメントを手動でレビューする手順を計画します。 修復の優先順位付け すべての文書が同等のコンプライアンス リスクを伴うわけではありません。 修復作業を戦略的に集中させます。 公開文書を最優先にしてください。ウェブサイトに掲載するもの、顧客に配布するもの、政府機関に提出するものはすべて最優先です。 これらは、苦情や監査のきっかけとなる可能性が最も高い文書です。 次に、頻繁にアクセスされる社内文書です。多くの従業員が日常的に使用する研修資料、ポリシーハンドブック、人事フォームなどは、速やかに修正する必要があります。 アーカイブ文書やアクセス頻度の低い文書は長期間保存されます。アクセス頻度の低い古い文書は、定期的に修復するか、リクエストに応じてオンデマンドで変換できます。 このトリアージ アプローチにより、アーカイブのロングテールを時間をかけて処理しながら、最も目立つドキュメントのコンプライアンスの進捗状況を示すことができます。 PDF/UAとマージ、署名、メタデータワークフローを組み合わせる 制作パイプラインでは、PDF/UA 変換が単独で行われることはほとんどありません。 多くの場合、これを他のドキュメント操作と組み合わせる必要があります。 IronPDF はこれらを連鎖することをサポートしています: 入力 2 つのソース ドキュメント: 表紙と財務レポート。それぞれが PDF/UA に変換され、アクセス可能な 1 つのファイルに結合されます。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-merge-metadata.cs using IronPdf; // Load and convert to PDF/UA in memory PdfDocument report = PdfDocument.FromFile("financial-report.pdf"); report.ConvertToPdfUA(); // Set comprehensive metadata report.MetaData.Title = "Annual Financial Report 2025"; report.MetaData.Author = "Finance Department"; report.MetaData.Subject = "Year-end financial summary and analysis"; // Merge with a cover page (also converted to PDF/UA) PdfDocument coverPage = PdfDocument.FromFile("cover-page.pdf"); coverPage.ConvertToPdfUA(); PdfDocument finalDocument = PdfDocument.Merge(coverPage, report); // Save the combined, accessible document finalDocument.SaveAs("annual-report-final-accessible.pdf"); // Dispose of intermediate documents report.Dispose(); coverPage.Dispose(); $vbLabelText $csharpLabel 出力 ご覧のとおり、2 つのソース ドキュメントが、デジタル署名と包括的なメタデータが適用された 1 つの PDF/UA 準拠ファイル (表紙とそれに続く財務レポート) に結合されています。 ご注意上記の iframe プレビューには、結合されたドキュメントのビジュアル コンテンツが表示されます。 PDF/UA 準拠識別子、デジタル署名、および埋め込まれたメタデータはビューアには表示されません。 外部の PDF/UA バリデータを使用して、結合された出力の構造の準拠性を確認します。 PDF/UA 変換は、デジタル署名、パスワード保護、PDF/A アーカイブ形式とも互換性があります。 実際の PDF/UA コンプライアンスの使用例は何ですか? PDF アクセシビリティ要件はあらゆる分野で発生し、具体的な課題は業界によって異なります。 政府機関は最も具体的な期限に直面しています。 ADA Title II の対象となる州政府および地方自治体は、2026 年 4 月と 2027 年 4 月の期限までに、数万件の旧文書 (会議議題、許可申請、ゾーニング マップなど) を処理しています。 前述のバッチ修復パターンはここで直接適用できます。 法律関連組織は、提出書類、概要、訴訟記録、契約書、証拠開示資料など、膨大な量の PDF を作成します。 文書を電子的に保存したり、障害を持つ可能性のある関係者と共有したりする場合は、アクセシビリティ要件が適用されます。 ドキュメント管理システムの出力ステージに PDF/UA 変換を組み込むと、コンテンツの作成方法に関係なくコンプライアンスが確保されます。 高等教育機関は、コース教材、シラバス、研究論文、管理フォーム、機関レポートを作成します。 セクション 508 (連邦政府の資金援助を受けている機関向け) および ADA Title II (公的機関向け) に基づき、これらの文書はアクセス可能でなければなりません。 多くの学術コンテンツは Web コンテンツとして作成されたり、テンプレートから生成されたりするため、HTML から PDF/UA へのワークフローは特に役立ちます。 医療機関は、セクション 508 およびさまざまな州法に基づいてアクセス可能でなければならない患者の明細書、保険の説明、検査結果、教育資料を作成します。 これらのドキュメントには表形式のデータやグラフが含まれることが多いため、適切な表のタグ付けと画像の代替テキストが特に重要になります。 金融サービス企業は、口座明細書、開示文書、規制書類、レポートを作成します。 これらの多くは、顧客に配布されるときや政府機関に提出されるときにアクセス可能である必要があります。 量が多いため、バッチ処理が必須となります。 PDF/UA と PDF/A の二重準拠をどのように実現しますか? アーカイブとアクセシビリティの両方が必要な場合 PDF/A は、文書が長期にわたって表示および再現可能であることを保証するアーカイブ標準です。 PDF/UA はアクセシビリティ標準です。 組織によっては、永続的に保存され、アクセス可能なドキュメントの両方を必要とします。 これは、政府の記録保管、法的アーカイブ、医療文書では一般的です。 PDF/A-3a 準拠レベルでは、アーカイブ準拠と完全なアクセシビリティ ("a"は"accessible"の略) の両方が具体的に求められます。 PDF/A-3a を達成すると、PDF/A と PDF/UA の両方の要件を実質的に満たすことになります。 IronPDF は両方の標準をサポートしています。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-dual-compliance.cs using IronPdf; PdfDocument pdf = PdfDocument.FromFile("government-record.pdf"); // Convert to PDF/UA for accessibility pdf.ConvertToPdfUA(); // Set required metadata pdf.MetaData.Title = "Public Hearing Minutes - January 2025"; pdf.MetaData.Author = "City Clerk's Office"; // Convert to PDF/A for archival compliance pdf.SaveAsPdfA("government-record-archive.pdf"); $vbLabelText $csharpLabel 出力 ドキュメントは、アーカイブ (PDF/A) とアクセシビリティ (PDF/UA) の両方の要件を同時に満たす準拠レベルである PDF/A-3a として保存されます。 PDF/UAとデジタル署名の組み合わせ 認証も必要なアクセス可能なドキュメントでは、PDF/UA 変換とデジタル署名を組み合わせることができます。 まず PDF/UA 変換を適用し、次にドキュメントに署名します。 :path=/static-assets/pdf/content-code-examples/tutorials/pdf-accessibility-csharp-pdfua-tutorial/pdfua-digital-signature.cs using IronPdf; using IronPdf.Signing; PdfDocument pdf = PdfDocument.FromFile("contract.pdf"); pdf.ConvertToPdfUA(); pdf.MetaData.Title = "Service Agreement - Executed Copy"; // Apply a digital signature to the accessible document var signature = new PdfSignature("certificate.pfx", "password"); pdf.Sign(signature); pdf.SaveAs("contract-accessible-signed.pdf"); $vbLabelText $csharpLabel 進化する標準規格に対応した将来を見据えた文書 アクセシビリティ標準は進化し続けています。 WCAG 2.2 は 2023 年に公開され、WCAG 3.0 の作業が進行中です。PDF/UA-2は、PDF/UA-1 よりも最新の Web 標準に準拠しています。 今すぐドキュメント パイプラインに PDF/UA 準拠を組み込むことで、後で完全な改修に直面するのではなく、標準の進化に合わせて更新できる基盤を構築できます。 アクセス可能なドキュメント インフラストラクチャへの投資は、コンプライアンスを超えた利益をもたらします。 適切にタグ付けされた PDF は検索性が向上し、モバイル デバイス上でのリフローが改善され、テキスト抽出結果が向上し、さまざまな PDF ビューアやプラットフォーム間でより確実に動作します。 アクセシビリティは単なる法的要件ではありません。 それはより優れたエンジニアリングです。 次のステップ PDF/UA準拠は単一のチェックボックスではありません。 これには、規制の理解、適切な HTML 作成、プログラムによる変換、自動検証、既存のアーカイブの大規模な修復が含まれます。 しかし、大規模なドキュメント ライブラリと厳しい期限を持つ組織でも管理しやすくするためのツールとパターンが存在します。 IronPDFは、タグ付きPDFエンジン、RenderHtmlAsPdfUAメソッド、バッチ処理機能、クロスプラットフォーム for .NETサポートを提供し、あらゆるアクセシブルPDF .NETパイプラインの基盤を形成します。政府契約のためのSection 508 PDF C#準拠が必要な場合でも、企業報告プラットフォームのためのWCAG PDF compliance C#が必要な場合でも、期限が厳しいドキュメント修正プロジェクトのためのPDF/UA C#変換が必要な場合でも、このチュートリアルのパターンは築くための確立されたフレームワークを提供します。 単一ファイル変換から始めて、SaveAsPdfUAが何を生成するかを理解します。 veraPDF と Matterhorn プロトコルを使用して出力を検証します。 セマンティック要素と適切な見出し階層を使用する、アクセス可能な HTML テンプレートを構築します。 既存のアーカイブをバッチ変換パイプラインで拡張できます。PDF/UAとPDF/Aアーカイブコンプライアンス、デジタル署名、メタデータ管理、 PDF圧縮を組み合わせることで、組織のあらゆる要件を満たすドキュメントワークフローを構築できます。 さらに詳しい情報については、 IronPDF のPDF/UA ハウツー ガイドでAPI サーフェスの詳細が説明されており、 PDF/A アーカイブ チュートリアルでは、両方の標準を同時に必要とする場合の完全なアーカイブ コンプライアンス ワークフローが説明されています。 構築開始の準備はできましたか？ IronPDFをダウンロードして無料トライアルでお試しください。 同じライブラリが、単一ファイルのアクセシビリティ変換からエンタープライズ規模の修復パイプラインまですべてを処理します。 特定のユースケースの実装、コンプライアンス戦略、またはアーキテクチャについてご質問がある場合は、エンジニアリング サポート チームにお問い合わせください。 当社は、あらゆる規模のチームがドキュメントのアクセシビリティを適切に行えるよう支援してきました。お客様にも同様の支援をさせていただきます。 よくある質問 PDF/UAとは何ですか？ PDF/UA（ユニバーサルアクセシビリティ）は、アクセシブルなPDF文書のためのISO基準であり、障害を持つ人々がPDFコンテンツにアクセスして対話できるようにするものです。Section 508やEUアクセシビリティ法のようなアクセシビリティ規制の準拠にとって重要です。 既存のPDFをC#でPDF/UAに変換するにはどうすれば良いですか？ IronPDFのSaveAsPdfUAメソッドを使用して、C#で既存のPDFをPDF/UAに変換できます。これにより、必要なタグと構造を埋め込むことで文書がアクセシビリティ基準を満たすようにします。 HTMLをアクセシブルPDF/UAにレンダリングするためにIronPDFはどのようなツールを提供していますか？ IronPDFはRenderHtmlAsPdfUAメソッドを提供しており、開発者がHTMLコンテンツをPDF/UAのアクセシビリティ基準に準拠したタグ付きPDFに変換できます。 IronPDFは大規模なPDF/UA修正プロジェクトを扱うことができますか？ はい、IronPDFは並列処理パイプラインを通じて大規模な文書アーカイブのバッチ修正をサポートしており、広範なPDF/UA修正プロジェクトの処理に効率的です。 IronPDFを使用してPDF/UAの準拠をどのように検証しますか？ IronPDFはMatterhornプロトコルに対するPDF/UA準拠を検証するのに役立つveraPDFツールと統合されており、文書がアクセシビリティ基準を満たしていることを確認します。 IronPDFが解決できる一般的なPDF/UAの準拠問題は何ですか？ IronPDFはPDF/UA文書における文書タイトルの欠如、フォント埋め込みの欠如、および壊れた見出し階層など、一般的な準拠問題を修正するのに役立ちます。 IronPDF は異なる .NET 環境と互換性がありますか? はい、IronPDFは.NET 6+、.NET Framework 4.6.2+、.NET Standard 2.0に対応しており、Windows、Linux、macOS、Docker、Azure、AWSへのデプロイをサポートしています。 IronPDFを使用してPDF/UA文書をデジタル署名と組み合わせるにはどうすれば良いですか？ IronPDFを使用すると、PDF/UA準拠の文書をデジタル署名と組み合わせることで、文書のセキュリティとコンプライアンスを強化できます。 2026年4月と2027年4月のADA Title IIの締切の重要性は何ですか？ これらの締切は、特定の公衆向けアプリケーションがADA Title IIの更新されたアクセシビリティ基準に準拠する必要がある時期を示しており、IronPDFのようなツールが開発者にとって重要になります。 IronPDFはPDF/UA文書でのメタデータワークフローをサポートできますか？ はい、IronPDFはPDF/UA文書にメタデータワークフローを統合することをサポートしており、アクセシビリティとコンプライアンスの維持に不可欠です。 カーティス・チャウ 今すぐエンジニアリングチームとチャット テクニカルライター Curtis Chauは、カールトン大学でコンピュータサイエンスの学士号を取得し、Node.js、TypeScript、JavaScript、およびReactに精通したフロントエンド開発を専門としています。直感的で美しいユーザーインターフェースを作成することに情熱を持ち、Curtisは現代のフレームワークを用いた開発や、構造の良い視覚的に魅力的なマニュアルの作成を楽しんでいます。開発以外にも、CurtisはIoT（Internet of Things）への強い関心を持ち、ハードウェアとソフトウェアの統合方法を模索しています。余暇には、ゲームをしたりDiscordボットを作成したりして、技術に対する愛情と創造性を組み合わせています。 準備はできましたか？ Nuget ダウンロード 17,803,474 | バージョン: 2026.3 リリース 無料トライアル NuGet 無料版 総ダウンロード数: 17,803,474 ライセンスを見る まだスクロールしていますか? すぐに証拠が欲しいですか? PM > Install-Package IronPdf サンプルを実行するHTML が PDF に変換されるのを確認します。 NuGet 無料版 総ダウンロード数: 17,803,474 ライセンスを見る