ASP.NET アプリケーションで Excel Interop を使うべきではない理由

本番環境で発生する問題と、開発者が代わりに選ぶソリューション

多くの場合、きっかけはシンプルな要件から始まります。

「Excel ファイルをアップロードし、サーバー上で処理して、レポートを出力したい。」

そこで、多くの開発者は Microsoft.Office.Interop.Excel に手を伸ばします。使い慣れています。Microsoft のエコシステムの一部です。そして、少なくとも自分の開発マシン上では動作します。

ブックを開く。セルを読み取る。簡単なテストを書く。すべて問題なく通ります。

そして、本番環境へデプロイします。

数日後、少しずつ異変に気付き始めます。

• タスクマネージャーに Excel プロセスがひっそりと蓄積し、終了しない
• 一部のリクエストがエラーもタイムアウトも発生せず、永遠に処理中になる
• 中程度の負荷でも IIS が予期せずリサイクルされる
• ステージング環境では正常だったバックグラウンドジョブが、本番では断続的に失敗する
• 新しいサーバーへ移行するたびに Microsoft Office のインストールが必要になり、ライセンスキーの所在を探すことになる

これらの問題は、最初から大きな障害として現れるわけではありません。むしろ、徐々に発生します。そして原因が明確になった頃には、すでに本番インフラの一部として組み込まれてしまっています。

これが Excel Interop の罠です。一見すると便利なソリューションに見えます。API もシンプルです。しかし、それが本番システムの一部になった瞬間、状況は大きく変わります。

1. Excel Interop とは？

Excel Interop は、Microsoft Office 自動化 API の一部であり、Microsoft.Office.Interop.Excel 名前空間を通じて提供されています。これを利用すると、C# コードから人間が Excel を操作するのと同じように Excel を制御できます。ブックの開閉、セルの読み書き、数式の実行、マクロの実行、ファイル保存などが可能です。

Application excel = new Application();
Workbook workbook = excel.Workbooks.Open(@"C:\reports\data.xlsx");
Worksheet sheet = (Worksheet)workbook.Sheets[1];
string value = ((Range)sheet.Cells[1, 1]).Value?.ToString();

内部では、COM オートメーションを通じて動作します。.NET プロセスは Excel ファイル形式を直接解析するのではなく、実際の Excel インスタンスを起動し、COM インターフェース経由で命令を送信します。Excel が実行されているのです。（非表示であっても）ウィンドウを持ち、独自のメモリ、ファイルハンドル、プロセスライフタイムを管理します。

個人が対話的に実行するローカルツールのようなデスクトップオートメーションでは、これはかなりうまく機能します。

ASP.NET アプリケーションとサーバー環境では、話はまったく別です。

2. なぜ Excel Interop はサーバー環境で問題を起こすのか

問題は稀なケースではありません。構造的なものであり、本番環境では互いに悪影響を及ぼし合います。

2.1 Microsoft は Excel Automation を推奨していない

これは単なる意見ではありません。

Microsoft は、ASP.NET や Windows Service などの非対話型サーバー環境で Office Automation を利用することをサポートしていないと明確に説明しています。

Office アプリケーションは、インタラクティブなデスクトップでの使用を想定して構築されました。本番環境で何かが壊れた場合、それはバグのデバッグではなく、ソフトウェア自体のサポート対象外の境界で運用していることになります。

2.2 Excel はデスクトップ環境を必要とする

new Application() を呼び出すことは、ファイルを開くだけではありません。完全な Excel プロセスを起動します。それには GUI インフラストラクチャ、ユーザープロファイルの依存関係、そしてサーバー上では確実に存在するとは限らないデスクトップセッション要件が伴います。

Windows Update、グループポリシーの変更、またはアクセス許可の微調整によって、一夜にしてすべてが静かに壊れる可能性があります。エラーメッセージは曖昧で、修正方法は決して明白ではありません。

2.3 COM オブジェクトによるメモリリーク

Excel Interop で操作するすべての Excel オブジェクトは COM オブジェクトです。.NET のガベージコレクター（GC）は、これらを完全には自動解放できません。例外処理内、ループ処理内、ヘルパーメソッド内など、どこか一箇所でも Marshal.ReleaseComObject の呼び出しを忘れると、終了しない孤立した EXCEL.EXE プロセスが残ります。

// すべてのオブジェクトに対して、毎回手動で解放する必要があります。
Marshal.ReleaseComObject(range);
Marshal.ReleaseComObject(sheet);
Marshal.ReleaseComObject(workbook);
excel.Quit();
Marshal.ReleaseComObject(excel);

数時間稼働すると、これらのプロセスは徐々に蓄積します。メモリ使用量は増加します。ファイルはロックされたままになります。そして、最終的には誰かがリモートデスクトップ（RDP）でサーバーへ接続し、手動でプロセスを終了することになります。

もし本番運用手順書に、

「孤立した Excel プロセスがないか確認する」

という項目が存在するなら、それは根本的に何かがおかしいサインです。

2.4 スレッドセーフではない

ASP.NET は複数のリクエストを同時並行で処理します。

一方、Excel Interop は Single-Threaded Apartment（STA）モデルを使用しており、並列アクセスを前提として設計されていません。

負荷がかかると、これはデッドロック、ハングするリクエスト、IIS プロセスのリサイクルを意味します。アクセスをシリアル化するために手動でロックを追加することもできますが、そうすると、脆弱な基盤の上にボトルネックを構築しただけになります。

2.5 最新のデプロイ環境と相性が悪い

Excel Interop には、Windows、完全な Office インストール、そしてコードを実行するすべてのマシン（CI/CD エージェント、ステージングサーバー、自動スケーリングインスタンスを含む）で有効なライセンスが必要です。

これを実現する Docker イメージはありません。実際、多くのシステム刷新プロジェクトが、たった 1 つの Excel 依存によって停止しています。

2.6 セキュリティ上の懸念

見落とされやすいリスクが 3 つあります。

• マクロおよび DDE の実行
  アップロードされた Excel ファイルに含まれるマクロや DDE リンクが実行される可能性があり、サーバー上でコード実行につながるリスクがあります。

• 過剰な権限を持つプロセス
  Excel プロセスはアプリケーションプールの ID を継承します。そのため、悪意のあるファイルによる影響範囲が拡大する可能性があります。

• 一時ファイルの情報漏洩
  Excel は AutoRecover データやクリップボード情報をディスクへ保存します。共有環境では、これらのデータが想定以上に長く残る可能性があります。

3. 開発者が Excel Interop の代わりに利用しているもの

重要なのは、考え方の転換です。

現代的な Excel ライブラリは、Excel デスクトップアプリケーションを操作するのではなく、Excel ファイル形式そのものを処理します。

つまり、COM オートメーション、隠れた Excel プロセス、サーバーへの Office インストールは不要です。

ということです。

幸いなことに、.NET エコシステムにはすでに成熟した選択肢が複数存在します。

機能	Excel Interop	最新のライブラリ
Microsoft Office が必要	必要	不要
Docker/Linux で動作	不可	可能
COM 解放処理	必要	不要
サーバー利用向け設計	リスクあり	対応済み
バックグラウンド Excel プロセス	発生する	発生しない

以下は、一般的なものの実用的な概要です。

Open XML SDK

Open XML SDK は、Microsoft が提供する Office ファイル形式向けの公式オープンソースライブラリです。.xlsx ファイルの内部 XML 構造へ直接アクセスし、読み書きを行うことができます。

適しているケース：

ドキュメント構造を細かく制御したい開発者や、低レベルの API を扱うことに抵抗がないチームに向いています。

知っておくべき点：

API は比較的冗長です。セルの値を読み取る、行を書き込むといった単純な処理でも、想像以上に多くのコードが必要になります。複雑なスプレッドシートを扱う場合、コードの保守が難しくなる可能性があります。

EPPlus

EPPlus は、.NET エコシステムで広く利用されている Excel ライブラリの 1 つです。API は直感的で、ドキュメントも充実しており、一般的な Excel 操作を効率よく実装できます。

適しているケース：

生産性の高い API を求めており、ライセンスモデルを受け入れられるチームに向いています。

知っておくべき点：

EPPlus はバージョン 5 以降、商用利用において有料ライセンスへ変更されました。非商用プロジェクトでは引き続き無料で利用できますが、商用アプリケーションで本番利用する場合は有料ライセンスが必要です。

NPOI

NPOI は Java の Apache POI ライブラリを .NET 向けに移植したものです。無料で利用できるオープンソースライブラリで、.xls と .xlsx の両方の形式をサポートしています。

適しているケース：

既存の古いコードベースを移行する場合や、旧形式の .xls ファイルと最新の .xlsx ファイルの両方を扱う必要があるプロジェクトに適しています。

知っておくべき点：

API 設計は Java 由来であるため、動作はしますが、C# 開発者にとって必ずしも自然な書き方とは感じられません。また、近年ではコミュニティ活動も以前ほど活発ではありません。

Office 非依存型ライブラリ

Office 非依存型ライブラリとは、Excel Interop、COM、Windows 固有 API に依存せず、マネージドコードのみで Excel ファイル形式を処理するライブラリのカテゴリです。

このカテゴリには、Spire.XLS などのライブラリが含まれます。実際の開発では、これらのライブラリは一般的に以下の特徴を持っています。

• Open XML SDK より高レベルな API を提供
• サーバー環境やコンテナ環境で安定して動作
• 幅広い Excel 機能を標準でサポート

適しているケース：

レポート生成、アップロードされた Excel ファイルの処理、定期的なエクスポート処理などを行う ASP.NET アプリケーションに適しています。特に、シンプルなデプロイ環境を重視する本番システムでは有力な選択肢になります。

知っておくべき点：

このカテゴリの一部のライブラリでは、開発者単位またはサーバー単位のライセンスが必要です。商用プロジェクトで採用する前に、必ずライセンス条件を確認してください。

簡単な比較

ライブラリ	ライセンス	Office 必須	.xls 対応	API レベル
Open XML SDK	MIT	不要	非対応	低
EPPlus	商用（v5 以降）	不要	非対応	高
NPOI	Apache 2.0	不要	対応	中
Spire.XLS	商用	不要	対応	高

4. 例：Interop を使わずに Excel ファイルを読み取る

ここで具体的な例を見てみましょう。同じ処理を 2 つの方法で実装します。

まず 、Excel Interop を使用する方法、その後に Interop を使わない方法を紹介します。

**シナリオ：**ASP.NET アプリケーションでアップロードされた Excel ファイルを受け取り、最初のワークシートを読み込み、セル A1 の値を返します。

Interop を使用する場合

[HttpPost("upload")]
public IActionResult Upload(IFormFile file)
{
    var tempPath = Path.GetTempFileName() + ".xlsx";
    using (var stream = new FileStream(tempPath, FileMode.Create))
    {
        file.CopyTo(stream);
    }

    Application excel = null;
    Workbook workbook = null;
    Worksheet sheet = null;
    Range cell = null;

    try
    {
        excel = new Application();
        excel.Visible = false;
        workbook = excel.Workbooks.Open(tempPath);
        sheet = (Worksheet)workbook.Sheets[1];
        cell = (Range)sheet.Cells[1, 1];

        string value = cell.Value?.ToString();
        return Ok(value);
    }
    finally
    {
        if (cell != null) Marshal.ReleaseComObject(cell);
        if (sheet != null) Marshal.ReleaseComObject(sheet);
        if (workbook != null)
        {
            workbook.Close(false);
            Marshal.ReleaseComObject(workbook);
        }
        if (excel != null)
        {
            excel.Quit();
            Marshal.ReleaseComObject(excel);
        }
        System.IO.File.Delete(tempPath);
    }
}

これは最低限動作するバージョンです。しかし、すでに非常に壊れやすい構造になっています。実際の本番コードでは、通常さらに多くの防御的な処理が追加されます。1 か所でも例外発生時に適切なクリーンアップ処理が実行されなければ、Excel プロセスが終了しません。一時ファイルもロックされたままになります。本番環境で同時アクセスが発生すると、問題はさらに深刻になります。

Interop を使わない場合

ここでは Spire.XLS を例として使用します。他の Excel ライブラリでも基本的な考え方は同じです。

// Install-Package Spire.XLS
[HttpPost("upload")]
public IActionResult Upload(IFormFile file)
{
    if (file == null || file.Length == 0)
    {
        return BadRequest("No file uploaded.");
    }

    using var stream = file.OpenReadStream();

    var workbook = new Workbook();
    workbook.LoadFromStream(stream);

    var sheet = workbook.Worksheets[0];
    string value = sheet.Range["A1"].Text;

    return Ok(value);
}

COM オブジェクトはありません。手動クリーンアップもありません。一時ファイルもありません。バックグラウンドで実行されている Excel プロセスもありません。

わずかなコードで同じ結果が得られ、並行負荷下でも、コンテナ内でも、Linux ホスト上でも予測通りに動作します。

書き込み処理でも同じ考え方が適用される

読み取り処理は最もシンプルなケースです。

次に、Excel レポートを生成し、ダウンロード用ファイルとして返す例を見てみましょう。

[HttpGet("report")]
public IActionResult DownloadReport()
{
    var workbook = new Workbook();
    var sheet = workbook.Worksheets[0];

    sheet.Range["A1"].Text = "Product";
    sheet.Range["B1"].Text = "Revenue";
    sheet.Range["A2"].Text = "Widget A";
    sheet.Range["B2"].NumberValue = 84500;

    using var stream = new MemoryStream();
    workbook.SaveToStream(stream, FileFormat.Version2016);

    return File(stream.ToArray(),
        "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
        "report.xlsx");
}

インストールされた Office は不要です。クリーンアップの儀式も不要です。ただ、その通りに動作するコードがあるだけです。

なぜコード以外の部分でも重要なのか

違いは単なるコードの書き方だけではありません。

本質的な違いは運用面にあります。

• Excel プロセスが存在しない
  → メモリリークの原因になるものがなく、孤立プロセスを削除する必要もありません。

• Office への依存がない
  → 開発環境、CI/CD、ステージング、本番環境で特別なセットアップなしに同じコードを利用できます。

• ストリームベース API を利用できる
  → アップロードされたファイルをディスクへ保存せず、直接処理できます。

同じカテゴリに属する他のライブラリも、基本的には同じ考え方で動作します。具体的な API は異なりますが、根本的なメリットは共通しています。つまり、デスクトップアプリケーションをリモート操作するのではなく、ファイル形式そのものを処理しているという点です。

5. それでも Interop が適しているケース

ここでは、正直なところを説明する必要があります。

Interop が常に間違った選択というわけではありません。

もし作成しているものが以下の条件を満たす内部向けデスクトップツールであれば、Interop は合理的な選択肢になり得ます。

• Office がすでにインストールされたマシン上で動作する
• 1 人のユーザーが対話的に利用する
• サーバーへデプロイされない

このようなケースでは、Excel を Excel 本来の用途で利用しています。

また、ファイル形式を扱う一般的なライブラリでは対応できない、Excel 固有の機能が本当に必要な場合もあります。

例えば：

• 特定のマクロ操作
• OLE 埋め込み
• 非常に厳密な Excel レンダリング結果

などです。

このような場合、Interop が唯一の現実的な選択肢になる可能性があります。

問題は技術そのものではありません。

問題は、Interop が設計された用途と、実際に利用されている場所が一致していないことです。

ASP.NET アプリケーション、バックグラウンドサービス、API、サーバーやコンテナ上で動作するシステムでは、このミスマッチが根本的な問題になります。

不安定なデプロイ、メモリリーク、同時実行問題、ライセンス管理の負担など、運用コストは最終的に API の使いやすさというメリットを上回ります。

6. Interop から移行する方法

すでにコードベースに Interop が組み込まれている場合でも、すべてを書き直す必要はありません。多くのチームは段階的に移行しており、実際のプロジェクトでもこの方法が効果的です。

合理的なアプローチは次のようになります。

1. Interop を多用するワークフローを特定する — using Excel = Microsoft.Office.Interop.Excel や new Excel.Application() のようなパターンを検索します。これらは、Office オートメーションがコードベースのどこに潜んでいるかを示す信頼できる指標です。
2. 既存のロジックをインターフェースの背後にラップする — Interop の呼び出しをその場で書き換えたりしないでください。最初にサービスの境界の背後にカプセル化することで、置き換えが散在したリファクタリングではなく、封じ込められたスワップになります。
3. 操作を段階的に置き換え — 最もリスクの高い領域から始めます。ASP.NET リクエストパイプライン内のすべてです。デスクトップユーティリティや内部ツールは後回しにできます。
4. ファイルの互換性を慎重に検証する — ライブラリによって、エッジケースの処理方法が異なります。本番環境で切り替える前に、既存のテストファイルを新しい実装で実行してください。
5. 本番に近い条件で負荷テストを実施する — Interop のシリアル化された動作によって隠蔽されていた並行性の問題が、移行中に表面化する可能性があります。早期にテストしてください。

実際には、Interop を多用するシステムのほとんどは、ごく一般的なタスク（アップロードの読み取り、レポートの生成、スプレッドシートのエクスポート）にしか Excel を使用しておらず、それらはすべて、Excel 自体を起動することなく、最新のライブラリで既に十分に処理できます。

まとめ

Excel Interop が本番コードベースに生き残る理由は一つです。それはローカルでは動作し、問題が表面化する頃には、すでに深く組み込まれているからです。

しかし、この記事で取り上げた問題は、不運や設定ミスではありません。孤立したプロセス、ハングするリクエスト、並行性の失敗、デプロイの妨げ、これらはデスクトップアプリケーションをサーバー環境で実行することによる予測可能な結果です。これらはより注意深いコーディングによって解消されるものではありません。間違ったツールを仕事に使うのをやめれば、解消されます。

.NET エコシステムには、Excel ファイルを扱うための成熟した、サーバーセーフな代替手段があります。それらはデプロイが容易で、理解しやすく、「孤立した Excel プロセスを強制終了する」という本番運用手順書の項目を必要としません。

新しく始めるなら、選択は明白です。既存のコードを保守しているなら、移行パスは段階的です。しかし、その方向性にコミットする価値はあります。

スプレッドシートが依然として Excel であっても、あなたのアーキテクチャまでそうである必要はありません。