連載第2回：Cloud Runの甘い罠！「コンテナにすれば何でも動く」という誤解とWindows資産の逆襲

導入部

こんにちは！テックリードの皆さん。システムの移行要件で「帳票のフォントと1ミリもずらさないでね」と言われて冷や汗をかいたことはありませんか？

前回は、架空のプロジェクト「SampleProject」において、アーキテクトである上司が「ビッグバン・リリース」を避け、手堅く Compute Engine ＋ SQL Server というインフラ構成を選んだ背景をお伝えしました。

今回は、Web開発者の間で大人気のサーバーレス・コンテナサービス「Cloud Run」が、なぜこのプロジェクトで見送られなければならなかったのか、その技術的な障壁に迫ります。
「Dockerに入れればどこでも動くんでしょ？」という甘い期待を打ち砕く、エンタープライズの泥臭いリアルをお届けします。

【対象となる前提環境】

• 移行前システム：VB6 / ClassicASP, Windows Server, IIS, 帳票ツール（ActiveReports等）
• 移行先候補：Google Cloud (GCP)
• 対象読者：中級エンジニア、コンテナ化やCloud Runへの移行を検討している方

1. クラウド界の暗黙の了解「コンテナ＝Linux」の壁

【起結】⏱ 10秒まとめ：本章の結論

「コンテナ化すればどこでも動く」は半分正解で半分間違いです。Cloud Runのようなマネージドなサーバーレス環境は基本的に「Linuxコンテナ専用」であり、Windowsコンテナは持ち込めません。

【承】🌩 課題：こんなこと困るよね。難しいよね。

若手エンジニアからよくこんな提案を受けます。
「今回のシステム、.NET 8に書き換えるんですよね！.NET 8はクロスプラットフォームなんだから、DockerイメージにしてCloud Runで動かしましょうよ。オートスケールだし、サーバー管理もいらなくて最高ですよ！」

確かにその通りです。Dockerの技術自体には「Windowsコンテナ」も存在します。しかし、勇んでCloud Runにデプロイしようとすると、無情なエラーメッセージに弾き返されます。
Cloud Runの裏側で動いている基盤はLinuxであり、Linuxのカーネル（OSのコア）と通信できないWindowsコンテナは、絶対に起動しないという絶対的なルールが存在するのです。

【転】💡 解決策：採用理由と他の選択肢

Cloud Runが使えないと判明した時、アーキテクトはどう決断すべきか。

• 選択肢A：GKE（Google Kubernetes Engine）でWindowsノードを構築する（見送り）
  • 見送り理由： GKEを使えばWindowsコンテナを動かすことは可能です。しかし、Kubernetesという非常に複雑な基盤の運用ノウハウが必要になり、インフラ管理コストが跳ね上がります。「サーバー管理を楽にしたい」という当初の目的から本末転倒になるため。
• 採用案：Compute Engine (VM) で Windows Server をそのまま動かす
  • 採用理由： コンテナ化の夢は一旦あきらめ、GCP上にWindows Serverの仮想マシンを構築する。OSのパッチ当てなどの運用は残るが、インフラチームの既存の運用ノウハウ（Active Directory連携やRDP接続など）をそのまま活かせるため、最も確実な構成であると判断した。

【結】💻 具体例：コンテナ化を阻むOSの壁のイメージ

もし、既存のWindows依存のシステムを無理やりDocker化しようとした場合、Dockerfileは以下のようになります。しかし、このベースイメージ（mcr.microsoft.com/windows/servercore）を指定した瞬間に、Cloud Runへの切符は失われます。

# 現場の悲鳴が聞こえるDockerfile（※Cloud Runでは動きません）

# Windows Server Coreをベースにするしかない
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# IISをインストールする泥臭いコマンド群
RUN dism.exe /online /enable-feature /all /featurename:iis-webserver /NoRestart

# ...中略...
# レガシーなCOMコンポーネントやDLLを無理やりレジストリに登録する
COPY legacy-component.dll /windows/system32/
RUN regsvr32.exe /s /windows/system32/legacy-component.dll

【補足】🔰 初心者向け解説：コンテナとOSの関係とは？
貨物船の「コンテナ」を想像してください。
コンテナ（アプリ）の形は世界共通なので、どの港のクレーンでも持ち上げられます。これが「コンテナはどこでも動く」と言われる理由です。
しかし、中に入っているのが「200Vの電圧（Windows）でしか動かない冷蔵庫」だった場合、100Vの電圧（Linux）しか提供していない港（Cloud Run）にコンテナを降ろしても、冷蔵庫の電源は絶対に入りません。中身のアプリがどのOSの基礎機能（電圧）を求めているかが重要なのです。

2. ミドルウェアと帳票ツールの呪縛（脱Windowsの難しさ）

【起結】⏱ 10秒まとめ：本章の結論

システムをLinuxコンテナ（Cloud Run）に対応させるには、Windows特有の機能（IIS、フォント、描画エンジン）に依存したライブラリを全て捨てなければなりません。エンタープライズシステムにおいて、それは「帳票の全面作り直し」を意味します。

【承】🌩 課題：こんなこと困るよね。難しいよね。

「OSの壁があるなら、アプリのコードを直してLinuxコンテナで動くようにすればいいじゃないか！」
正論です。.NET 8への移行を機に、IISを捨ててKestrel（.NET標準の軽量サーバー）にし、LinuxベースのDockerイメージを作ればCloud Runで動かせます。

しかし、現場のコードを見て絶望します。そこには、ActiveReportsなどの帳票出力ツールが鎮座しています。
「請求書のフォントは必ず『MS明朝』で」「ここの罫線は1ミリずれてもダメ」
こういった帳票ツールは、Windowsが持っているグラフィック描画機能（GDI+）や、Windowsにインストールされているフォントにゴリゴリに依存しています。これをLinuxコンテナに持っていくと、文字化けやレイアウト崩れが多発します。（そもそもLinux用のマネージドDLLが提供されていない古いバージョンを使っていることも多いです）。

【転】💡 解決策：採用理由と他の選択肢

帳票ツールという「ビジネスの出力物」の互換性をどう守るか。

• 選択肢A：Linux対応の帳票ライブラリへ全面リプレースし、Cloud Runへ（見送り）
  • 見送り理由： 数百種類ある帳票のデザインをすべて新しいツールで引き直し、全パターンの出力テストを行う必要がある。開発工数が爆発し、「レガシーの安全な移行」というプロジェクトの主目的を達成できなくなるため。また、Linuxコンテナへの商用フォントの埋め込みはライセンス的なグレーゾーン（または追加費用）に踏み込むリスクがある。
• 採用案：帳票ツールは既存のまま、Windows環境（Compute Engine）で動かす
  • 採用理由： お客様の業務に直結する「出力物（帳票）」の互換性を100%保証することを最優先とする。システムの裏側のインフラがどれだけモダン（Cloud Run）になっても、帳票のレイアウトが崩れて現場が混乱すれば「失敗プロジェクト」の烙印を押されるため。

【結】💻 具体例：ADR（アーキテクチャ・ディシジョン・レコード）の記載例

上司が残したADR（意思決定記録）の抜粋です。「技術的な優劣」ではなく「ビジネスへの影響」を天秤にかけていることがわかります。

# ADR: Webアプリケーションのホスティング環境（Cloud Runの不採用について）

## ステータス
承認済み

## コンテキスト
.NET 8へ移行したアプリケーションのGCP上でのホスティング先として、Cloud RunとCompute Engineを比較する。

## 決定
* Cloud Runの採用を見送り、Compute Engine (Windows Server) を採用する。

## 理由
1. 既存システムで利用している帳票出力ライブラリがWindows特有の描画エンジン（GDI+）およびフォントに依存している。
2. Cloud Run（Linuxコンテナ）環境へ対応させるためには、帳票システムの全面再構築が必要となり、許容できる開発コストとリスクを大きく超えるため。

## 影響
* サーバーレスの恩恵（ゼロスケール等）は受けられない。
* (将来への展望) 移行完了後、帳票機能を別サービス（API等）に切り出すマイクロサービス化を行い、本体のWebアプリだけをCloud Runへ移行する計画をPhase2として検討する。

【補足】🔰 初心者向け解説：ライブラリとミドルウェアとは？
料理に例えましょう。

• ライブラリ（帳票ツールなど）： 料理人が使う「便利な調理器具（ミキサーなど）」。コンセントの形状（OS）が合わないと動きません。
• ミドルウェア（IISやSQL Serverなど）： 厨房の「ガスコンロや巨大冷蔵庫」。これがないとそもそも料理（Webサービス）を提供できませんが、これも専用のガスの規格（OS）が必要です。
  OSを変えるということは、厨房の規格を全部変えることなので、今まで使っていた調理器具も冷蔵庫も買い替え・調整が必要になるのです。

単語一覧 (Glossary)

• Cloud Run: Google Cloudが提供する、コンテナをサーバーレスで動かす大人気サービス。アクセスがない時は勝手にゼロ台になり、アクセスが来ると一瞬で増える魔法のような環境だが、Linuxコンテナしか受け付けない。
• GKE (Google Kubernetes Engine): 大量のコンテナをオーケストラの指揮者のように管理するシステム（Kubernetes）のGoogle版。強力だが、設定や運用が非常に難解。
• GDI+ / 帳票ツール: Windowsが画面に文字や図形を描画するための標準機能（GDI+）。日本の業務システムでよく使われる帳票（PDFなどを綺麗なレイアウトで出力する）ツールは、この機能に依存していることが多く、脱Windowsの最大の壁になりやすい。

いかがでしたか？
「最新技術を使いたい！」というエンジニアの欲求と、「お客様の業務（帳票の1ミリのズレ）を守る」というアーキテクトの責任。上司の決断は、技術的な敗北ではなく、プロジェクトを成功に導くための「最適解」だったのです。

次回、第3回では、もう一つの壁である「データベース」について語ります。「DBなんてデータを置くだけだから、PostgreSQL（AlloyDB）に変えればいいじゃん！」という考えが引き起こす、システム崩壊のドミノ倒しについて解説します。お楽しみに！