OpenXML SDK vs Spire.Doc: C# での Word 処理、どちらを選ぶべきか？

C# での Word 文書処理は、レポート生成、文書自動化、データ抽出など、バックエンドシステムにおいて一般的な要件です。

ほとんどの開発者にとって、選択肢は最終的に次の 2 つのアプローチに絞られます。

• Open XML SDK — Microsoft 製の、.docx ファイルを直接操作するための低レベルライブラリ
• Spire.Doc のようなサードパーティ製ライブラリ — 生産性と文書レンダリングに焦点を当てた、より高レベルの API

どちらのアプローチも本番システムで広く使用されていますが、最適化されている点が大きく異なります。

この記事では、開発の複雑さ、PDF エクスポート、デプロイの懸念事項、長期的な保守性など、実践的なサーバーサイドの視点から両者を比較します。

• サーバー上で Word 処理が複雑になる理由
• オプション A: DocumentFormat.OpenXML SDK
• オプション B: サードパーティ製ライブラリ（Spire.Doc）を使用する
• 比較表
• 共通の落とし穴と隠れた罠
• 決定ガイド：どちらを選ぶべきか？

サーバー上で Word 処理が複雑になる理由

一見すると、.docx ファイルの生成は簡単に聞こえます。

しかし実際には、サーバーサイドでの文書処理には、ライブラリ選択に大きく影響するいくつかの制約があります。

Office のインストールが不要。 Microsoft は、サーバー環境での Word オートメーション（COM / Interop）の使用に対して明確に警告しています。これにより、サーバー環境で最も機能が充実した Word 自動化アプローチは除外されます。

クロスプラットフォームデプロイ。 あなたのサービスが Linux コンテナで実行されている場合（現代のデプロイではますます一般的になっています）、Windows 専用の依存関係を持つライブラリはすぐに候補から外れます。

並行処理。 同時の文書生成リクエストを処理するサーバーは、並行ワークロード下でも確実に動作するライブラリを必要とします。一部のライブラリでは、並行処理の問題を避けるために、リクエストごとに別々のドキュメントインスタンスを作成する必要があります。

PDF エクスポート。 「Word 文書を生成する」ということは、ほとんどの場合「Word 文書 と PDF 版を生成する」ことを意味します。OpenXML SDK にはレンダリングエンジンがなく、PDF 出力には別のソリューションが必要です。一部のサードパーティ製ライブラリはこれを含んでいます。

これらの 4 つの制約により、OpenXML SDK とサードパーティ製ライブラリのどちらを選ぶかは簡単な問題ではなくなり、「無料のものを使えばいい」という直感が本番環境で常に通用するとは限らない理由となります。

オプション A: DocumentFormat.OpenXML SDK

Open XML SDK は、Microsoft が提供する、.docx、.xlsx、.pptx などの Office Open XML 文書を直接操作するためのライブラリです。

Microsoft Word を自動化する代わりに、基礎となる XML 構造を直接操作します。

dotnet add package DocumentFormat.OpenXml

これにより、開発者は文書の内部構造を正確に制御できますが、Word の文書モデルの複雑さにも直面することになります。

例 1: すべての段落テキストを読む

using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;

public static List<string> ReadParagraphs(string filePath)
{
    using var doc = WordprocessingDocument.Open(filePath, isEditable: false);

    var body = doc.MainDocumentPart!.Document.Body!;

    return body
        .Descendants<Paragraph>()
        .Select(p => string.Concat(p.Descendants<Text>().Select(t => t.Text)))
        .Where(text => !string.IsNullOrWhiteSpace(text))
        .ToList();
}

これは SDK の中でも比較的わかりやすい操作の一つです。Descendants<T>() は XML ツリーを汎用的に travers し、LINQ チェーンも読みやすさを保っています。

例 2: テンプレートプレースホルダー {{name}} を置換する

一般的なサーバーサイドのパターン：事前に作成された .docx テンプレートを実行時のデータで埋めます。

using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;

void MailMerge(string templatePath, string outputPath, string name)
{
    using (WordprocessingDocument doc = WordprocessingDocument.Open(templatePath, true))
    {
        var body = doc.MainDocumentPart.Document.Body;

        foreach (var text in body.Descendants<Text>())
        {
            if (text.Text.Contains("{{name}}"))
            {
                text.Text = text.Text.Replace("{{name}}", name);
            }
        }

        doc.SaveAs(outputPath);
    }
}

重要な注意点：

Word は内部でテキストを複数の Run 要素に分割することがよくあります。

そのため、次のようなプレースホルダー：

{{name}}

が、実際には次のように保存されている可能性があります：

{{na
me}}

これは、単純な文字列置換のロジックを壊します。

本番レベルの実装では通常、置換前に Run を正規化するための追加ロジックが必要です。

例 3: フォーマット済みテーブルを挿入する

using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;
using System.Linq;

void InsertTable(string path)
{
    using var doc = WordprocessingDocument.Open(path, true);
    
    var p = doc.MainDocumentPart.Document.Body
        .Descendants<Paragraph>()
        .FirstOrDefault(p => p.InnerText.Contains("The table below presents the sales data for key items."));
    
    if (p != null)
    {
        p.InsertAfterSelf(CreateTable());
        p.InsertAfterSelf(new Paragraph());
        doc.Save();
    }
}

Table CreateTable()
{
    var t = new Table();
    
    t.AppendChild(new TableProperties(new TableBorders(
        new TopBorder { Val = BorderValues.Single, Size = 8 },
        new BottomBorder { Val = BorderValues.Single, Size = 8 },
        new LeftBorder { Val = BorderValues.Single, Size = 8 },
        new RightBorder { Val = BorderValues.Single, Size = 8 },
        new InsideHorizontalBorder { Val = BorderValues.Single, Size = 8 },
        new InsideVerticalBorder { Val = BorderValues.Single, Size = 8 }
    )));

    string[,] d = {
        { "Product", "Units Sold", "Revenue ($)" },
        { "Laptop", "1,250", "1,299,000" },
        { "Monitor", "850", "765,000" },
        { "Wireless Mouse", "3,200", "92,800" }
    };

    for (int i = 0; i < 4; i++)
    {
        var row = new TableRow();
        for (int j = 0; j < 3; j++)
        {
            var para = new Paragraph();
            var run = new Run(new Text(d[i, j]));
            
            if (i == 0)
            {
                run.RunProperties = new RunProperties(new Bold());
                row.AppendChild(new TableCell(
                    new TableCellProperties(new Shading { Val = ShadingPatternValues.Clear, Fill = "4472C4" }),
                    new Paragraph(new Run(run.RunProperties, new Text(d[i, j])))
                ));
            }
            else
            {
                para.AppendChild(run);
                if (j > 0) para.ParagraphProperties = new ParagraphProperties(new Justification { Val = JustificationValues.Right });
                row.AppendChild(new TableCell(para));
            }
        }
        t.AppendChild(row);
    }
    return t;
}

この例は、SDK の核心的なトレードオフを示しています：コードの冗長性と引き換えに正確な制御を獲得するということです。ほとんどの書式設定操作は基礎となる OOXML 構造に直接マッピングされており、これにより柔軟性が得られる一方で、実装の複雑さが増すことになります。

制限事項

一見すると、SDK は扱いやすそうに見えます。しかし、単純なテキスト操作の域を超えると、複雑さは急速に増します。

1. 冗長で低レベルの API

基本的な書式設定でさえ、複数の階層を操作する必要があります：

• Paragraph
• Run
• RunProperties

Word での小さな視覚的変更が、驚くほど大量のコードになることがよくあります。

2. 文書構造の理解が必要

重要なことを行うには、Word が内部でどのようにコンテンツを構造化しているかを理解する必要があります：

• テキストがどのように Run 間で分割されるか。
• スタイルがどのように適用されるか。
• リレーションシップ（rId）がどのように管理されるか。

これなしでは、コード上は問題なさそう でも Word で壊れる文書を生成してしまいがちです。

3. ビルトインのレンダリング機能がない（例：PDF）

SDK 自体には、PDF 変換のためのレンダリングエンジンは含まれていません。

これを実現するには、通常、以下のような外部ツールを統合する必要があります：

• LibreOffice（コマンドライン経由）
• 商用レンダリングライブラリ
• 外部変換サービス

これにより、特にコンテナ化された環境では、追加のインフラストラクチャとデプロイの複雑さが生じます。

OpenXML SDK が適切な選択となる場合

• サービスが Linux またはコンテナ上で動作しており、商用依存関係を負担できない場合。
• サーバーごとや文書ごとの料金が発生しない、ゼロコストのライセンスが必要な場合。
• 文書構造に対する正確で低レベルの制御が必要な場合。
• PDF エクスポートが要件ではないか、別のレンダリングパイプラインを管理する準備がある場合。

要するに、OpenXML は最大限の制御を提供しますが、その制御には追加の実装の複雑さが伴います。

オプション B: サードパーティ製ライブラリ（Spire.Doc）を使用する

Spire.Doc は、E-iceblue によって開発された商用の .NET ライブラリです。

OpenXML SDK とは異なり、OOXML オブジェクトモデルを直接公開しません。その代わりに、XML レイヤーを完全に抽象化した、ドキュメント指向の API を提供します。

また、独自のレンダリングエンジンを同梱しているため、PDF エクスポートは外部のレンダリングツールに依存するのではなく、ライブラリに組み込まれています。

dotnet add package Spire.Doc

無料版（Spire.Doc for .NET Free）が、登録なしで NuGet から入手できます。これはほとんどのコア機能をサポートしていますが、2 つの厳しい制限があります：文書は 3 ページに制限され、それを超えると透かしが追加されます。本番環境での使用には商用ライセンスが必要です。

例 1: すべての段落テキストを読む

using Spire.Doc;

string ReadAllParagraphs(string filePath)
{
    using (Document doc = new Document())
    {
        doc.LoadFromFile(filePath);
        return doc.GetText();
    }
}

このライブラリは段落と Run の内容を内部で集約するため、開発者は通常、基礎となるノード構造を手動で travers する必要はありません。

例 2: テンプレートプレースホルダー {{name}} を置換する

using Spire.Doc;

void MailMerge(string templatePath, string outputPath, string name)
{
    using (Document doc = new Document())
    {
        doc.LoadFromFile(templatePath);

        doc.Replace("{{name}}", name, false, true);

        doc.SaveToFile(outputPath, FileFormat.Docx);
    }
}

Document.Replace() は、Run の分割を内部で処理します。ライブラリはこの問題を内部で抽象化しているため、テキストが複数の Run に分割されている場合でも、プレースホルダーの置換は通常機能します。

例 3: フォーマット済みテーブルを挿入する

using Spire.Doc;
using Spire.Doc.Documents;

class Program
{
    static void Main()
    {
        Document doc = new Document();
        doc.LoadFromFile("input.docx");

        var sel = doc.FindString("以下に、主要製品の販売実績を示します。", false, true);
        if (sel != null)
        {
            var body = sel.GetAsOneRange().OwnerParagraph.Owner as Body;
            if (body != null)
            {
                int idx = body.ChildObjects.IndexOf(sel.GetAsOneRange().OwnerParagraph);
                body.ChildObjects.Insert(idx + 1, CreateTable(doc));
                doc.SaveToFile("output.docx", FileFormat.Docx);
            }
        }
        doc.Dispose();
    }

    static Table CreateTable(Document doc)
    {
        string[,] d = {
            { "製品名", "販売数", "売上高 (円)" },
            { "ノートパソコン", "1,250", "1,299,000" },
            { "モニター", "850", "765,000" },
            { "ワイヤレスマウス", "3,200", "92,800" }
        };

        Table t = new Table(doc);
        t.ResetCells(4, 3);

        for (int i = 0; i < 4; i++)
            for (int j = 0; j < 3; j++)
                t.Rows[i].Cells[j].AddParagraph().AppendText(d[i, j]);

        return t;
    }
}

この特定の操作におけるコードの長さは、OpenXML SDK バージョンとほぼ同じです。テーブル構築は本質的に、ライブラリに関係なく行と列の反復処理だからです。違いは API の表面にあります：cell.CellFormat.BackColor と、ShadingPatternValues.Clear と 16 進数文字列を使って Shading オブジェクトを構築するかの違いです。

例 4: PDF にエクスポートする

OpenXML SDK はレンダリングエンジンを提供しないため、PDF エクスポートには外部ツール（例：LibreOffice や商用レンダラー）の統合が必要です。

using Spire.Doc;

public static void ExportToPdf(string docxPath, string pdfPath)
{
    var doc = new Document(docxPath);
    doc.SaveToFile(pdfPath, FileFormat.PDF);
}

これは、2 つのアプローチ間の最も大きな違いの一つです。

Spire.Doc は独自のレンダリングエンジンを同梱しているため、基本的な PDF 変換ワークフローのために LibreOffice や Microsoft Word などの外部ツールを統合する必要がなくなります。

ほとんどのサードパーティ製レンダリングエンジンと同様に、非常に複雑なレイアウトや一般的でないフォントを使用する文書の場合、PDF 出力が Microsoft Word とピクセル単位で完全に同じにならない可能性があります。

大規模なバッチ変換シナリオでは、特にコンテナ化されたデプロイメントにおいて、メモリ使用量とスループットのテストを依然として推奨します。

Spire.Doc の利点

1. より高レベルの API

ほとんどの操作は、開発者が文書について考える方法に直接マッピングされます：

• セクション
• 段落
• テーブル
• スタイル

これにより、ほとんどの OOXML 固有の実装詳細がアプリケーションコードに露出されるのを回避できます。

2. 豊富な機能サポート

一般的な実世界の要件がネイティブに処理されます：

• Word → PDF / HTML / 画像 変換。
• 複雑なテーブルレイアウト。
• ヘッダー、フッター、スタイル。
• 画像と書式設定。

3. 実装オーバーヘッドの削減

OpenXML で数十行を必要とするタスクが、ここではわずか数行で実装できることがよくあります。

この違いは、文書の複雑さが増すにつれてより顕著になります。

考慮すべきトレードオフ

1. ライセンス

無料版には制限があります。

本番環境での使用には、通常、商用ライセンスが必要です。

2. 低レベル制御の低下

ライブラリが XML レイヤーを抽象化するため、OpenXML と比較して、文書内部に対する詳細な制御はより制限されます。

3. 依存関係のサイズとランタイムに関する考慮事項

• OpenXML よりもパッケージサイズが大きい。
• サーバーレス環境やコンテナ環境でのコールドスタートへの影響。
• クローズドソース——内部のレンダリングやレイアウトの問題のデバッグがより困難になる可能性がある。

さらに、後で移行する場合、ライブラリの API に結びついた文書生成ロジックのリファクタリングが必要になる可能性があります。

サードパーティ製ライブラリの使用が適している場合

このアプローチは、以下の場合により適しています：

• 文書変換（例：Word → PDF） が必要な場合。
• 複雑なレイアウトや書式設定 を扱っている場合。
• 開発時間を削減 したい場合。
• プロジェクトに 商用コンポーネントの予算 がある場合。

要するに、サードパーティ製ライブラリは、生産性と引き換えに低レベルの制御を放棄します。そして、多くの実世界のアプリケーションでは、そのトレードオフはしばしば許容範囲内です。

比較表

前の 2 つのセクションでは、両方のライブラリで同じ操作を説明しました。ここでは、本番環境での決定に最も重要な側面について、統合されたビューを示します。

機能比較

機能	OpenXML SDK	Spire.Doc（無料版）	Spire.Doc（商用版）
DOCX 読み書き	✅	✅	✅
プレースホルダー置換	✅ ⚠️	✅	✅
テーブル挿入	✅	✅	✅
メールマージ	手動実装	✅	✅
PDF エクスポート	❌	✅ ⚠️	✅
HTML エクスポート	❌	✅	✅
画像挿入	✅	✅	✅
ヘッダー / フッター編集	✅	✅	✅
文書暗号化	✅	✅	✅
ページ制限	なし	3 ページ	なし
出力時の透かし	なし	あり（3 ページ超）	なし

⚠️ OpenXML SDK のプレースホルダー置換では、分割されたテキストノードを処理するために手動での Run の統合が必要です。
⚠️ Spire.Doc 無料版は、3 ページを超える文書に透かしを追加します。

運用コスト比較

これは、開発者がライブラリ選択中に最も見落としがちな側面です。

コスト要因	OpenXML SDK	Spire.Doc
ライブラリライセンス	無料	無料枠 / 有償商用
PDF レンダリング	LibreOffice または同等品が必要	内包
インフラストラクチャオーバーヘッド	LibreOffice プロセス管理	なし
Linux フォント設定	不要	非ラテン文字フォントには必要
内部可視性	完全なソースアクセス	公開された API に制限

OpenXML SDK のゼロライセンスコストは現実のものですが、「無料」という言葉は、PDF エクスポートの実装、コンテナ内での LibreOffice プロセスの管理、OOXML オブジェクトモデルのエッジケースの処理に費やされるエンジニアリング時間を考慮に入れたものではありません。2 人以上の開発者からなるチームがいる商用プロジェクトでは、その時間は測定可能なコストになります。

共通の落とし穴と隠れた罠

どちらのアプローチを選んでも、本番環境で深刻な問題を引き起こす可能性のある、いくつかわかりにくい問題があります。

以下に最も一般的ないくつかを示します。

OpenXML SDK の落とし穴

1. リレーションシップ ID の競合による文書の破損

画像、スタイル、その他のパーツを追加する際、各要素はリレーションシップ ID（rId）を使用してリンクされます。

ID をハードコーディングしたり再利用したりすると、ファイルが破損する可能性があります：

「Word は読み取り不可能なコンテンツを検出しました…」

👉 ベストプラクティス：
手動で割り当てる代わりに、常にビルトインメソッドを使用して ID を生成してください。

2. テキスト置換は見た目ほど単純ではない

Word では、テキストは複数の Run 要素に分割されることがよくあります。

これにより、単純な文字列置換ロジックが壊れます。

解決策：

• 置換前に Run を正規化する。
• または、より堅牢な検索戦略を使用する。

Spire.Doc の落とし穴

1. Linux 環境でのフォント問題

Docker や Linux コンテナで実行する場合、フォントが不足すると以下を引き起こす可能性があります：

• 文字化けしたテキスト。
• 欠落した文字。
• レイアウトの不整合。

👉 解決策：
コンテナに必要なフォントをインストールします。例：

apt-get install -y fonts-wqy-zenhei

2. デバッグの可視性が限られている

ライブラリはクローズドソースであるため：

• 内部処理が見えない
• レンダリングやレイアウトの問題のデバッグがより困難になる可能性がある

👉 ドキュメントやベンダーサポートに頼る必要があるかもしれません。

共通の落とし穴：セキュリティリスク（XXE）

多くの文書処理ワークフローと同様に、信頼できないユーザーがアップロードしたファイルを処理する場合、解析と検証を慎重に行わないと、セキュリティリスクが生じる可能性があります。

一般的なリスクは XML External Entity（XXE）インジェクション であり、これにより以下が発生する可能性があります：

• データ漏洩
• リモートファイルアクセス

緩和戦略：

• 安全な XML 解析設定を使用する（例：DTD 処理を禁止する）。
• アップロードされたファイルを検証およびサニタイズする。
• 信頼できない文書を直接処理しないようにする。

まとめ

ほとんどの問題は「間違った API」から発生するのではなく、Word 文書が内部的にどのように動作するかについての仮定から発生します。

これらの落とし穴を早い段階で理解することで、デバッグの時間を何時間も節約し、本番環境でのインシデントを防ぐことができます。

決定ガイド：どちらを選ぶべきか？

この時点で、Open XML SDK と Spire.Doc のようなサードパーティ製ライブラリのどちらを選ぶべきか、より明確になったはずです。しかし、さらに実用的に考えてみましょう。

抽象的な比較ではなく、ここでは実際のニーズに基づいたシンプルな判断フローを示します。

クイック判断フロー

• PDF や他の形式への変換が必要ですか？
  → はい → サードパーティ製ライブラリが通常、よりシンプルな選択肢です。

• 商用コンポーネントの予算はありますか？
  → いいえ → OpenXML を使用します（オプションで LibreOffice などの外部ツールと組み合わせる）。

• 文書ロジックは単純ですか（例：テキスト置換、基本構造）？
  → はい → OpenXML で十分です。

• 複雑なレイアウト、テーブル、またはスタイルを処理する必要がありますか？
  → はい → 複雑な文書ワークフローでは、サードパーティ製ライブラリが実装時間を削減することがよくあります。

• Linux コンテナまたは完全にオープンソースなスタックを対象としていますか？
  → はい → OpenXML が最もシンプルな完全オープンソースの選択肢であることが多いです。

柔軟なアプローチ（両方の長所を活かす）

一部のプロジェクトでは、単一のソリューションに固執する必要はありません。

一般的な戦略は、抽象化レイヤーを定義することです。例えば：

public interface IWordProcessor
{
    void ReplaceText(string filePath, string key, string value);
    void InsertTable(string filePath, object data);
    void ExportToPdf(string inputPath, string outputPath);
}

👉 そして、異なる実装を提供します：

• OpenXmlWordProcessor
• SpireWordProcessor

これにより、以下が可能になります：

• 一つのアプローチから始める
• 要件が変更された場合に後で切り替える
• パフォーマンスやコストのトレードオフをテストする

結論

C# での Word 文書処理は、単純なテキスト操作から複雑な文書生成パイプラインまで多岐にわたります。

Open XML SDK は文書構造を完全に制御できますが、OOXML についてのより深い理解とより多くの開発努力を必要とします。Spire.Doc のようなサードパーティ製ライブラリは、特に機能が豊富なシナリオにおいて、多くの一般的なタスクを簡素化し、実装オーバーヘッドを削減します。

この決定は、どちらの API が「優れている」かというよりも、どの運用上の複雑さをあなたのチームが引き受けるかという問題です。

OpenXML は最大限の制御とゼロライセンスコストを提供しますが、より多くの実装責任をアプリケーションに移します。高レベルのライブラリはその複雑さを軽減しますが、その代償として依存関係とライセンスの問題をもたらします。

本番システムにとって、アーキテクチャ上の正しい決定を早期に行うことは、メンテナンスのオーバーヘッド、デプロイの複雑さ、そして長期的な実装コストを大幅に削減できます。