.NET Framework 4.8 の WCF（SOAP）サービスを抱えたまま、.NET 8 や Azure／コンテナへの移行を検討しているものの、「AI で一気に変換できないか」「CoreWCF って何？」と悩んでいる方は多いと思います。本記事では、現時点での最適解である CoreWCF＋ASP.NET Core への移行パターンと、Azure App Service や ACA/AKS への展開、JWT 認証までを、実務でそのまま使えるレベルで整理します。
.NET 4.8 WCF（SOAP）から .NET 8 への移行の全体像
まず前提として、.NET 5 以降では WCF サーバー側（System.ServiceModel のサービスホスト）は公式には提供されていません。クライアント側は一部ライブラリで継続利用できますが、サーバー側を .NET 8 へ持っていくには次のような選択肢になります。
| 選択肢 | 概要 | メリット | デメリット |
|---|---|---|---|
| 現状維持（4.8 + WCF） | Windows Server + IIS 上でそのまま運用 | コード改修なし、即時のリスク最小 | .NET 4.8 依存が残り、将来の技術的負債が大きい |
| Azure App Service（Windows）へリホスト | アプリは 4.8 のままクラウドへ移転 | コード変更を最小化しつつクラウド運用へ移行 | .NET 8 ではない／IIS ベースの制約が残る |
| .NET 8 + CoreWCF へ移行 | ASP.NET Core 上で CoreWCF による SOAP サービスを構築 | クロスプラットフォーム、コンテナ対応、長期的なモダン基盤 | コードと構成のリファクタが必須、検証コストが高い |
| REST/gRPC への作り直し | SOAP を捨て、Web API や gRPC として再設計 | 最新アーキテクチャにフィットしやすい | 既存クライアントと互換が取れない、工数大 |
本記事のテーマは「既存 SOAP クライアントとの互換を維持しながら .NET 8 へ移行する」ことなので、中心となるのは CoreWCF + ASP.NET Core を使ったアプローチです。CoreWCF は、WCF サーバー側を .NET / .NET Core 上に移植し、既存の WCF サービスを移行しやすくする OSS プロジェクトです。
結論サマリ：AI 全自動はないが、現実解は「CoreWCF＋段階的モダナイズ」
| 質問 | 要点 |
|---|---|
| Microsoft 製の AI 自動変換ツールは？ | 「一括全自動変換」は存在しない。 AI 支援として GitHub Copilot app modernization chat agent が提供され、.NET Upgrade Assistant（レガシー版）と組み合わせて移行を補助する形になる。 |
| 単純なバージョンアップで移行できる？ | 不可。プロジェクト形式、構成（web.config）、ホスティング（IIS→Kestrel）、認証方式などを 手動でリファクタする必要がある。 |
| サーバー WCF は .NET 8 でどうなる？ | .NET 8 にサーバー WCF は存在しないため、CoreWCF 上で ASP.NET Core ホスティングへ移行するのが一般的。 |
| バインディングや WS-* の互換性は？ | BasicHttp/BasicHttps/NetTcp/WSHttp などは概ねサポートされるが、WS-* の一部機能や分散トランザクション、メッセージキューは未実装。 |
| ホスティング方法は？ | Kestrel 単体、IIS 連携、Windows サービス、Linux/Windows コンテナ、Azure App Service、Azure Container Apps（ACA）、AKS など目的に応じて選択する。 |
| トークン認証（JWT）は必須？ | 必須ではないが、クラウド／コンテナ化を前提とするなら OAuth2/OIDC + JWT（Microsoft Entra ID など）への移行が実務的にはほぼ必須レベル。 |
Microsoft 製ツールと AI 支援の現状
.NET Upgrade Assistant（レガシー版）
.NET Upgrade Assistant は、既存の .NET Framework アプリを .NET 6/7/8 にアップグレードするための公式ツールです。WCF サーバー プロジェクト向けには、CoreWCF ベースのコードに変換する拡張が提供されています。
ただし、WCF 用のサポートは現在「レガシー版（特定バージョン）の Upgrade Assistant」でのみ利用可能であり、最新版の Upgrade Assistant とは別扱いになっています。
- WCF 拡張が動作するバージョン（例：0.4.x）を個別にインストール
- プロジェクトファイルや構成ファイルを書き換え、CoreWCF のテンプレートコードを追加
- 「自動で変換できなかった箇所」はコメントアウトや TODO で残される
つまり Upgrade Assistant は、「8〜9割を機械的に移し替えて、残りは人間が仕上げる」タイプのツールであり、「実行ボタンを押したら完全に .NET 8 + CoreWCF に移行完了」というものではありません。
GitHub Copilot app modernization chat agent（AI 支援）
Upgrade Assistant のドキュメントでは、WCF プロジェクトを含むレガシー アプリのモダナイズについて、GitHub Copilot app modernization chat agent の利用が推奨されています。
- Visual Studio 2022 以降と統合され、ソリューション全体を解析
- 依存関係を踏まえた 移行計画とステップを提案
- 一部の変更は 自動コード修正（pull request 形式）の形で適用
ただし、これは 「WCF→CoreWCF 専用ワンクリック変換ツール」ではなく、移行の相談役＋部分自動化ツールに近い存在です。設計判断（バインディングの扱い、認証方式の変更、分散トランザクションの代替設計など）は、依然として人間側の責任になります。
その他のツール（Porting Assistant for .NET など）
AWS の Porting Assistant for .NET のように、.NET Framework から .NET 6 以降への移行を支援する OSS ツールもあります。実際の事例では、Porting Assistant を用いて WCF サービスを .NET 6 に移行し、IIS 依存を外して Linux 上で動作させたケースも報告されています。
ただし WCF のサーバー機能そのものを代替するわけではないため、最終的には CoreWCF などと組み合わせて設計し直す必要がある点には注意してください。
移行戦略：短期「リホスト」＋中長期「モダナイズ」の二本立て
短期：Azure App Service（Windows）へリホストして延命
すぐに .NET 8 へ書き換えるのが難しい場合、まずは 既存の .NET 4.8 WCF サービスを Azure App Service（Windows）へそのまま載せ替えるのが現実的です。
- オンプレ IIS で動作中の WCF サービスを Visual Studio から発行プロファイル／ZIP などで App Service にデプロイ
- 接続文字列・環境変数・証明書（pfx）などを App Service の「構成」に移行
- App Service 側でカスタムドメイン＋ HTTPS バインドを設定
- ステージングスロット（staging）を作成し、テスト後に production へスワップ
| 観点 | オンプレ IIS | Azure App Service（Windows） |
|---|---|---|
| コード改修 | 不要 | 基本的に不要（構成のみ変更） |
| ファイル書き込み | ローカルディスクへの書き込みが前提 | 基本は読み取り専用。書き込みは Blob / File Storage など外部ストレージへ |
| Windows 認証 | オンプレ AD と密結合しやすい | そのままは難しい。Entra ID/Federation 等への移行検討が必要 |
| スケール/冗長化 | 手動でサーバー台数を増やす | スケールアウト（インスタンス増減）がポータルから容易 |
この段階では アプリケーション構造は変えないため、モダナイズというよりは「運用基盤だけ先にクラウドへ寄せる」というイメージです。その間に、次で紹介する .NET 8 + CoreWCF への移行計画を進めておくとスムーズです。
中期：.NET 8 + CoreWCF + ASP.NET Core ホストへ本格移行
本命となるのが、次の構成です。
- .NET 8（もしくは最新 LTS）の ASP.NET Core Web アプリ
- サービス部分は CoreWCF により SOAP エンドポイントとして公開
- ホスティングは Kestrel（IIS 連携 or コンテナ内）
- 認証は Entra ID 等の OAuth2/OIDC + JWT を前提
CoreWCF 1.0 以降は BasicHttpBinding / NetHttpBinding / NetTcpBinding / WebHttpBinding / WSHttpBinding など主要バインディングをサポートしつつも、WS-* の一部機能やキューイング、分散トランザクションは未対応であることが公式ブログでも明言されています。 この差分をどう設計し直すかが、モダナイズの肝になります。
長期：コンテナ化して Azure Container Apps / AKS へ
さらに先を見据えるなら、.NET 8 + CoreWCF サービスを Linux コンテナとして標準化し、
- 中小規模・シンプル構成：Azure Container Apps（ACA）
- 大規模・Kubernetes 前提：Azure Kubernetes Service（AKS）
へ載せるのが王道です。
4.8 のままコンテナ化することも可能ですが、Windows コンテナ前提となり、イメージのサイズや運用コストが高くなりがちです。新規開発・本格移行部分は .NET 8 + Linux コンテナに揃えるのがおすすめです。
CoreWCF を使った .NET 8 への標準移行ステップ
ステップ 1：WCF サービスの棚卸し
最初に、既存サービスで何を使っているかを一覧化します。ここを曖昧にすると「移行してみたら動かない機能」が後から噴出します。
| 項目 | 確認内容 |
|---|---|
| バインディング | BasicHttp/WSHttp/NetTcp/WebHttp/CustomBinding などの種類と設定値（セキュリティ・タイムアウト・メッセージサイズ） |
| セキュリティ | Transport / Message / TransportWithMessageCredential、Windows 認証 or ユーザー名・証明書／発行トークンなど |
| トランザクション | 分散トランザクション（TransactionScope）や WS-AtomicTransaction を利用していないか |
| セッション | セッションフル（InstanceContextMode=PerSession）か、コール単位か |
| 拡張機構 | IServiceBehavior / IEndpointBehavior / MessageInspector / メッセージロギング など独自拡張の有無 |
| 外部ライブラリ | サードパーティ NuGet / DLL が .NET 8 で動作するか（代替の有無） |
ステップ 2：ASP.NET Core + CoreWCF プロジェクトを作成
dotnet new web（ASP.NET Core Web アプリ）で新規プロジェクトを作成CoreWCF関連の NuGet パッケージを追加（CoreWCF.Httpなど）- Program.cs で
AddServiceModelServices/AddServiceModelMetadataを登録
// Program.cs（.NET 8 / 最小ホストの例）
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddServiceModelServices();
builder.Services.AddServiceModelMetadata();
// DI でサービス実装を登録
builder.Services.AddSingleton<IMyService, MyService>();
var app = builder.Build();
app.UseHttpsRedirection();
app.UseServiceModel(builder =>
{
builder.AddService<MyService>();
builder.AddServiceEndpoint<MyService, IMyService>(
new CoreWCF.BasicHttpBinding(), "/soap");
var smb = app.Services
.GetRequiredService<CoreWCF.Description.ServiceMetadataBehavior>();
smb.HttpGetEnabled = true; // WSDL 公開
});
app.Run();
このように、従来 web.config に書いていたバインディングやエンドポイント定義は、コードまたは appsettings.json 側へ寄せていくことになります。
ステップ 3：契約（Contract）とデータ契約（DataContract）の移植
[ServiceContract]/[OperationContract]/[DataContract]/[DataMember]はそのまま再利用可能- できるだけ 同期メソッドを非同期（Task<T> 戻り値）に置き換え、ASP.NET Core のスレッドプールを枯渇させないようにする
- 古い型（ArrayList や非ジェネリックコレクションなど）は
List<T>等にリファクタ
WCF 時代に「例外をそのまま投げている」実装が多い場合は、FaultException<T> をきちんと定義し、期待された Fault 以外は内部ログに閉じ込めるように整理しておくと、クラウド運用時のトラブルシュートが楽になります。
ステップ 4：web.config から Program.cs / appsettings.json へのマッピング
| WCF（web.config） | CoreWCF + ASP.NET Core |
|---|---|
| <bindings> / <basicHttpBinding> | new BasicHttpBinding() のプロパティ設定 ／ appsettings.json から読み込んでコードで適用 |
| <services> / <endpoint address=”…” binding=”basicHttpBinding” …> | AddServiceEndpoint<TService, TContract>(binding, "relativePath") |
| <behavior> / <serviceMetadata httpGetEnabled=”true” /> | ServiceMetadataBehavior.HttpGetEnabled = true |
| MessageInspector / Behavior の設定 | CoreWCF の IServiceBehavior / IEndpointBehavior 実装を DI で登録して適用 |
| appSettings / connectionStrings | appsettings.json + 環境変数 + Azure Key Vault 連携 |
「設定をコードに寄せる」ことで複雑な XML を脱却できますが、環境ごとに値を差し替えたい部分は必ず appsettings.*.json や Key Vault に逃がすようにして、再ビルドが不要な構成を意識すると運用が楽になります。
ステップ 5：ホスティング方式の検討（IIS / Kestrel / コンテナ）
| ホスティング方式 | 特徴 | 向いているケース |
|---|---|---|
| IIS + ASP.NET Core モジュール | Kestrel を IIS の背後で動かす構成。Windows Server 前提。 | 既に IIS ベースの運用があり、OS を Windows のままにしたい場合 |
| スタンドアロン Kestrel（Windows サービス） | 自己ホスト型。サービスとして登録して常駐。 | オンプレでシンプルに .NET 8 アプリを動かしたい場合 |
| Linux コンテナ（Docker） | .NET 8 ランタイムイメージ上で動作。Azure/クラウドとの相性が良い。 | Azure Container Apps / AKS・他クラウド K8s で運用する場合 |
| Azure App Service（Linux） | ビルド済みコンテナ or ソースからビルドして動作させる PaaS。 | インフラ管理を最小にしつつスケールアウトしたい場合 |
新規構築であれば、Linux コンテナ（Kestrel）＋ ACA / AKS を前提に設計するのが、将来のポータビリティやコスト最適化の面で有利です。
WCF と CoreWCF の互換性・バインディング差分
CoreWCF は WCF サーバー側の主要機能をポートしていますが、現時点でも「完全互換」ではなく、特に WS-* やトランザクション周りで差分があります。
| バインディング | CoreWCF の対応状況（概要） | コメント |
|---|---|---|
| BasicHttpBinding / BasicHttpsBinding | サポートあり | ASMX 互換の典型的な SOAP。最も移行しやすい。HTTPS + OAuth2/JWT との相性も良い。 |
| NetTcpBinding | サポートあり（一部 WS-* 機能は未対応） | WCF 〜 WCF 間の高速通信に適する。ファイアウォール/ポート設計に注意。 |
| WSHttpBinding | サポートありだが、WS-* の一部機能は未実装 | WS-Security/WS-RM 等を多用している場合は、要求を洗い出し簡素化（HTTPS + JWT など）を検討。 |
| WebHttpBinding | サポートあり | REST 風エンドポイント。CoreWCF での利用も可能だが、長期的には ASP.NET Core Web API への移行がおすすめ。 |
| NetNamedPipeBinding / MSMQ 系 | 一部は開発中 or 別パッケージで提供予定 | 同一マシン間やメッセージキューへの依存が強い場合は、キューサービス（Service Bus, SQS 等）への置き換えを検討。 |
また、CoreWCF の公式情報では、
- HTTP と NetTCP 以外のトランスポート
- Message セキュリティの一部高度な機能
- 分散トランザクション
- メッセージキュー（MSMQ など）
などは「まだ未実装の主要機能」として挙げられています。 これらに依存している場合、単純な移植ではなく、アーキテクチャレベルでの見直しが必須です。
認証・認可：Windows 認証から OAuth2 / OIDC + JWT への移行
オンプレ WCF では、Active Directory を前提とした Windows 認証（Kerberos/NTLM） や WS-Security ベースのメッセージセキュリティが多用されています。一方、クラウド／コンテナ環境では、これらをそのまま再現するのは難しく、OAuth2 / OIDC + JWT トークン への移行が現実解になります。
| 現状の方式 | 移行後のおすすめ | メモ |
|---|---|---|
| Windows 認証（IIS + AD） | Entra ID + OIDC（JWT） | オンプレ AD は Entra ID Connect 等で連携し、アプリは Bearer トークンを検証。 |
| ユーザー名＋パスワード（WS-Security） | OAuth2 Password/ROPC ではなく、Auth Code Flow + PKCE など標準フロー | アプリがパスワードを直接扱わないよう、IdP に任せる設計に変更。 |
| カスタムトークン / IssuedToken | OIDC クレームを利用したロールベース認可 | 必要に応じてトークン変換ゲートウェイを導入。 |
実装レベルでは、ASP.NET Core 側で AddAuthentication().AddJwtBearer(...) を設定し、CoreWCF 経由のリクエストに対しても同一の認証フィルタを適用する形になります。SOAP のメッセージセキュリティヘッダにこだわるのではなく、「HTTPS + Authorization ヘッダの Bearer トークン」 へ寄せる方が、保守性・運用性の面で優れています。
Azure App Service（Windows）へのリホスト詳細手順と影響
手順（サマリ）
- 前提確認：.NET Framework 4.8 / IIS ホストの WCF サービスであることを確認
- App Service（Windows）を作成：リージョン／SKU／診断設定を選択
- デプロイ方法を決定：発行プロファイル／ZIP デプロイ／Azure DevOps パイプライン／GitHub Actions など
- 構成を移行：接続文字列・appSettings を App Service の「構成」に反映、証明書をアップロードして HTTPS バインド
- 監視を設定：Application Insights とヘルスチェックエンドポイントを設定
- スロット運用：staging スロットでテスト → production スロットへスワップ
想定される影響と必要なリファクタ
- ローカルファイル書き込み：ログやテンポラリファイルをローカルディスクへ書いている場合、Azure Storage / Azure Files 等へ移行が必要
- 長時間処理：App Service のタイムアウト制限を意識し、非同期処理やキュー（Service Bus 等）へのオフロードを検討
- Windows 認証：オンプレ AD 連携前提の設計は、そのままクラウドでは動作しないため、Entra ID 等への移行計画を並行して立てる
- IIS モジュール依存：URL Rewrite 等のモジュールを使っている場合、App Service 側での設定やアプリ側のリファクタが必要
これらを踏まえつつ、アプリ本体の .NET 4.8 コードには極力手を入れず、運用基盤だけクラウドへ移すのがこのフェーズのゴールです。
.NET 8 + CoreWCF のコンテナ化と Azure への展開
Dockerfile のイメージ
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /out
FROM base AS final
WORKDIR /app
COPY --from=build /out .
ENTRYPOINT ["dotnet", "MyCoreWcfService.dll"]
Azure Container Apps（ACA）への基本フロー
- 上記 Dockerfile でイメージをビルドし、Azure Container Registry（ACR） へ push
- ACA で「コンテナアプリ」を作成し、ACR のイメージを指定
- Ingress を有効化し、HTTPS エンドポイントとスケールルール（CPU/メモリ or キュー長など）を設定
- 接続文字列や JWT 設定は、ACA のシークレット & 環境変数として注入
- ログは Container Insights / OpenTelemetry 連携で可視化
AKS を使う場合のポイント
- 複数サービス間でのサイドカー（認証/ログ）パターンや Ingress Controller（NGINX 等）を設計
- Helm チャートや Bicep/Terraform など IaC でデプロイ定義をコード化
- Pod のローリングアップデートと HPA（Horizontal Pod Autoscaler）でスケール戦略を構築
いずれのパターンでも、「コンテナ内で Kestrel + CoreWCF が動いている」という点は共通です。IIS は不要であり、Linux ベースでの運用が可能になります。
移行時の実務チェックリスト
- [ ] 依存ライブラリが .NET 8 対応か確認（NuGet の更新／代替ライブラリの検討）
- [ ] すべての WSDL が CoreWCF 側でも同等に生成されるか確認（ネームスペース／SOAPAction／エンコーディング）
- [ ] メッセージサイズ・タイムアウト・スロットリング（同時接続数）などのしきい値を再設計
- [ ] 失敗時のリトライ／サーキットブレーカ（Polly など）を導入し、ネットワークエラー時の挙動を統一
- [ ] 負荷試験（ピーク時のスループット／レイテンシ、スケールアウト時の挙動）を実施
- [ ] デプロイ／ロールバック手順、証明書更新、キーのローテーションなどの Runbook を整備
CoreWCF 最小サンプル（おさらい）
最後に、.NET 8 + CoreWCF で SOAP エンドポイントを立てる最小イメージをもう一度まとめておきます。
public interface IHelloService
{
[OperationContract]
string Say(string name);
}
public class HelloService : IHelloService
{
public string Say(string name) => $"Hello, {name}";
}
// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddServiceModelServices();
builder.Services.AddServiceModelMetadata();
builder.Services.AddSingleton<IHelloService, HelloService>();
var app = builder.Build();
app.UseHttpsRedirection();
app.UseServiceModel(smBuilder =>
{
smBuilder.AddService<HelloService>();
smBuilder.AddServiceEndpoint<HelloService, IHelloService>(
new CoreWCF.BasicHttpBinding(), "/hello");
var smb = app.Services
.GetRequiredService<CoreWCF.Description.ServiceMetadataBehavior>();
smb.HttpGetEnabled = true;
});
app.Run();
この状態でアプリを起動し /hello?wsdl をブラウザで開くと、従来の WCF と同じように WSDL が取得でき、既存の SOAP クライアントからも接続可能になります。
まとめ：意思決定の指針
ここまで見てきたように、.NET Framework 4.8 の SOAP WCF サービスを .NET 8 に移行するには、
- AI の「全自動変換」ボタンは存在しない
- .NET Upgrade Assistant（レガシー版）＋ CoreWCF ＋ GitHub Copilot の組み合わせで、機械的な移行と設計判断をうまく分担する
- バインディングや WS-* 機能、トランザクション／メッセージングなど、CoreWCF でカバーできない部分は設計し直す
- 短期は Azure App Service（Windows）へのリホストでリスクを抑え、中長期で .NET 8 + CoreWCF ＋ コンテナへ段階的に移行する
- 認証は Windows 認証から OAuth2/OIDC + JWT へシフトし、Entra ID を軸とした ID 基盤を整える
ポイントは、「単純アップグレード」ではなく「構成・認証・ホスティングの作り替え」こそが移行の本体だと割り切ることです。記事中のステップやチェックリストをベースに、自身のシステムの要件とギャップを洗い出し、「まずはリホスト」「次に CoreWCF」「最後にコンテナ化」というロードマップに落とし込んでいけば、無理なく .NET 8 世代への移行を進められるはずです。
コメント