Classic ASPをWindowsから引き剥がせないまま残る技術的負債の正体

社内に「あの1本だけ触れないシステム」がある方に向けた内容です。

APIはGoやNode.jsで新規に作り、コンテナで動かす体制に移行できている一方、経理や請求まわりの古いシステムだけがClassic ASP（Windows IIS上で動くMicrosoftの古いサーバーサイドスクリプト技術）のまま残っている、という状況は珍しくありません。

この記事では、なぜそのシステムだけが取り残されるのか、その構造を分解したうえで、Linux上でApacheと組み合わせて動かす選択肢と、その際に検討すべきトレードオフを整理します。

何が起きているか：Windows依存という名の技術的負債

Classic ASPは実行にIIS（Internet Information Services、Windows標準のWebサーバー）とWindows Serverのライセンスを必要とします。

そのため、他のアプリケーションはすべてLinux＋Apache／Nginxのインフラに寄せていても、そのシステム1本のためだけにWindows Server環境を維持し続けることになります。

影響範囲は単純な「サーバー代がもう1台分かかる」では終わりません。OSパッチ適用の担当者、IISの設定を理解できる人材、監視・バックアップの仕組みまで、Linux基盤とは別系統で維持する必要が出てきます。

これは典型的な技術的負債（設計判断の先送りが後から利息のように運用コストを増やす状態）の一種です。負債の元本は「ASPで書かれたコード」そのものではなく、「実行環境がWindowsに固定されている」という制約にあります。

なぜ起きるか：段階的な原因分解

原因を3段階に分けて見ていきます。

第一に、Classic ASPはVBScriptやJScriptをIISのASPエンジンが解釈する仕組みで動いており、この解釈エンジン自体がWindowsに強く結合しています。

第二に、書き換えのコストと業務停止リスクが釣り合わないケースが多い点です。請求や在庫管理のような基幹ロジックは、仕様書が失われていたり、書いた担当者が既に離職していたりすることがあり、フルリライトは工数もリスクも大きくなります。

第三に、「動いているものを触らない」という判断が積み重なり、結果としてインフラチームの選択肢を狭めていきます。新しいCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインやコンテナ化の恩恵を、その1システムだけが受けられない状態が固定化します。

自分のプロジェクトが該当するか確認する

以下のいずれかに当てはまる場合、この問題を抱えている可能性があります。

インフラ構成図の中に「Windows Server」と書かれたノードが1つだけ孤立している
サーバー室やクラウドの請求明細に、Windows Serverのライセンス費用が単独項目で残っている
.asp拡張子のファイルが本番環境に存在する（.aspxはASP.NETなので別物）
そのシステムの保守担当者が退職・異動すると「詳しい人がいなくなる」と社内で言われている

確認コマンドとしては、対象サーバーで以下のようにファイルを探すと実態を把握しやすいです。

find /var/www /inetpub -iname "*.asp" 2>/dev/null | head -n 50

Windows側であれば、IISマネージャーでサイトの物理パスを開き、拡張子とアプリケーションプールの設定（クラシックモードかどうか）を確認します。

対策の選択肢とトレードオフ

対策は大きく3つに分かれます。

1つ目はフルリライトです。Go、Node.js、PHPなど現行スタックへの書き換えで、長期的には最も負債が軽くなりますが、初期コストとリグレッション（意図せぬ動作変化）のリスクが最大です。

2つ目はWindows環境をそのまま維持する現状維持です。追加コストは発生しませんが、負債は減らずむしろOSサポート切れのたびに更新の是非を迫られます。

3つ目が、Classic ASPの実行環境自体をLinuxに移す方法です。ここでAxonASP（ブラジルのLucas Guimarães氏が開発した、Classic ASPコードをLinux上で直接処理するオープンソースのクロスプラットフォームサーバー）のような選択肢が候補になります。

AxonASPはFPM（FastCGI Process Manager、リクエストごとにワーカープロセスを管理する仕組み）方式を採用しており、Apacheのproxy_fcgiモジュール経由でUnixソケットにリクエストを渡す構成です。これはPHP-FPMを運用したことがあるエンジニアには馴染みのある構成です。

実際の設定は、まずDebian/Ubuntu向けのパッケージを取得します。

wget https://github.com/guimaraeslucas/axonasp/releases/download/v2.3.18/axonasp_2.3.18_amd64.deb
sudo dpkg -i axonasp_2.3.18_amd64.deb

次に、アプリケーションごとにFPMプール設定ファイルを作成します。ここではuidとgidを指定し、Linuxのユーザー権限単位でプロセスを分離します。

site_name = "legacy_billing"
uid = 1001
gid = 1001
socket = "/var/run/axonasp/legacy_billing.sock"
app_path = "/var/www/legacy-app"
memory_limit_mb = 256
max_restarts = 5

Apache側はProxyPassMatchで.aspリクエストをこのソケットへ振り分けます。

sudo a2enmod proxy proxy_fcgi
sudo systemctl restart apache2

この構成のアーキテクチャ上の利点は、単に「Linuxで動く」ことではありません。FPMがアプリケーションごとにプロセスとUID/GIDを分離するため、共有ホスティング環境（cPanelなど複数テナントが同居する環境）でも、あるアプリケーションが他のメモリやファイルにアクセスできない、という隔離性が担保される点です。あわせてmemory_limit_mbやmax_restartsのような設定でリソース上限とクラッシュ時の自動再起動も制御できます。

移行の本質は「コードを書き換えずに、実行環境の制約だけを外す」ことにあり、リライトとは別のリスク・コストの軸で評価する必要があります。

一方で見落とせない点もあります。AxonASPは2025年時点でコントリビューター10名規模のオープンソースプロジェクトであり、Microsoft公式のIISほど長期の実績や大規模障害対応の事例が積み上がっているわけではありません。本番導入前には、ステージング環境で既存のASPアプリケーションの主要機能（セッション管理、DB接続、ファイルアップロードなど）が同等に動作するかを個別に検証する作業が欠かせません。またサポート体制がコミュニティベースである点は、可用性要件（SLA、障害時の対応時間）を重視するシステムでは慎重に評価する材料になります。

判断基準の整理

最終的な選択は、以下の3点を軸に整理すると決めやすくなります。

選択肢	初期コスト	残るリスク
フルリライト	高い	リグレッション、仕様喪失
Windows現状維持	低い（既存踏襲）	OSサポート切れ、二重インフラの運用コスト
Linux移行（AxonASP等）	中程度	コミュニティ製ミドルウェアの実績不足

まとめ：次に確認すべきこと

Windowsだけに縛られたシステムが1本残っている状態は、コード自体の古さより「実行環境の制約」が負債の本体です。

まず着手できるのは、対象サーバーで.aspファイルの有無と本数を洗い出し、依存しているIISの機能（COMコンポーネント呼び出しの有無など）を棚卸しすることです。

そのうえで、フルリライト・現状維持・実行環境の移行という3つの選択肢を、初期コストと残存リスクの両面で比較し、ステージング環境での検証を経てから本番判断に進むのが安全な進め方です。