クイックスタート: 統合プロジェクトから Azure Logic Apps への移行を自動化する (Standard) (プレビュー)

適用対象: Azure Logic Apps (Standard)

Note

このプレビュー機能は、 Microsoft Azure プレビューの追加使用条件に従います。

BizTalk Serverなどのレガシプラットフォームからクラウドにワークロードを移行する必要がある場合は、プロセスが複雑で時間がかかり、困難な場合があります。このタスクを簡略化して簡単にするために、Visual Studio CodeのAzure Logic Apps移行エージェントは、5 つのガイド付きステージを通じてこのプロセスを自動化します。

このクイックスタートでは、Visual Studio Codeの Azure Logic Apps Migration Agent を使用して、Azure Logic Appsの BizTalk Server から Standard ワークフローに統合ワークロードの例を移行する方法について説明します。拡張機能をインストールし、ソースプロジェクトを開き、エージェントに従って、移行ステージ (検出、計画、変換、検証、デプロイ) について説明します。

Note

移行エージェントはほぼ自律的に実行されますが、必要なタスクに対して特定のコマンドの実行を許可するように求められる場合があります。エージェントを続行するには、[許可] を選択します。

詳細については、「統合プラットフォームから Azure Logic Apps への移行自動化」を参照してください。

前提条件

開始する前に、次の要件を満たしていることを確認してください。

Requirement	Purpose
Azure サブスクリプション - 無料アカウントを取得します	Azureへのデプロイ (ステージ 5)
Azure CLI	Azure リソースのプロビジョニングとデプロイ
Visual Studio Code 1.85.0 以降	ローカル開発エクスペリエンス
Azure Logic Apps 移行エージェント拡張機能	Visual Studio Codeの移行エージェントで必要な拡張機能
Azure Logic Apps (Standard) 拡張機能	Azure Logic Apps Migration Agent 拡張機能に必要な依存関係
Azure Functions 拡張機能	ローカル関数のランタイムタスクと開発タスク
Azure Functions Core Tools	Azure Logic Appsのローカルランタイムホスト (Standard)
GitHub Copilot サブスクリプション	AI を利用した分析、計画、変換
Docker Desktop	接続のテストと実行のためのローカルコネクタリソースのデプロイ
BizTalk Server プロジェクトを含むフォルダー	ソース成果物とファイルを含む統合プロジェクトフォルダーを含むフォルダー。たとえば、BizTalk プロジェクトフォルダーには、ファイル名拡張子が `.btproj`、 `.odx`、 `.btm`、 `.xsd`、 `.btp`のファイルが含まれます。

1: 移行エージェント拡張機能をインストールする

Visual Studio Codeを開く。

必要に応じて、統合プロジェクトが存在するフォルダーまたはディレクトリからVisual Studio Codeを開きます (例: C:\Migration\<project-folders>。
アクティビティバーで、[拡張機能] を選択 します。 (キーボード: Ctrl + Shift + X)
Extensions: Marketplace 検索ボックスで、Azure Logic Apps Migration Agent 拡張機能を見つけて、Install を選択します。

インストールが完了すると、アクティビティバーに Azure Logic Apps Migration Agent () のアイコンが表示されます。

2: ソースフォルダーを選択する

Visual Studio Codeのアクティビティバーで、Azure Logic Apps Migration Agent アイコン () を選択します。
Azure Logic Apps移行エージェント ウィンドウの Discovery Results セクションで、ソースフォルダーの選択 を選択します。

ヒント

このアクションをコマンドとして実行するには、コマンドパレットを開きます (キーボード: Ctrl + Shift + P)。「Azure Logic Apps移行エージェント: ソースフォルダーの選択を入力して実行します。
BizTalk、MuleSoft、またはその他の統合プロジェクトを含むソースフォルダーを見つけて選択し、 ソース Project フォルダーまたは MSI を選択します。

拡張機能はソースプラットフォームを自動的に検出し、検出ステージから移行ワークフローを開始します。
エージェントに従って、検出ステージから始まる各移行ステージを進みます。

移行ステージ 1: 検出

このステージでは、移行エージェントがソースプロジェクト内の統合成果物を検索してカタログ化します。検出段階では、移行エージェントは説明された順序で次のアクションを実行し、ユーザーからの入力を時々行います。詳細については、「移行エージェント: 検出ステージ」を参照してください。

手順 1: ソースプラットフォームを検出する

移行エージェントは、BizTalk Server (.btproj) ファイルなどのファイルパターンに基づいて、ソースプラットフォームを決定します。

次のスクリーンショットは、検出された成果物と依存関係の例を含む、識別されたプラットフォームを示しています。

手順 2: ソースファイルをスキャンする

移行エージェントは、プラットフォームの組み込みパーサーを使用して、検出されたソースファイルをスキャンします。スキャンが完了すると、@migration-analyser Copilot エージェントは検出された成果物を分析し、論理フローグループを検出します。これは、連携して動作する成果物のセットです。

次のスクリーンショットは、各統合プロジェクトの例が論理フローグループにどのようにマップされるかを示しています。

生成された論理フローは、レガシ統合アプリケーションとの 1 対 1 の関係を常に反映するとは限りません。移行エージェントは、Azure Logic Appsの Standard ワークフローとして、BizTalk ワークロードなどのレガシシステムの統合成果物を最もよく反映するフローを推測します。

ヒント

これらの論理フローを編集して 1:1 を統合ワークロードにマップするには、GitHub Copilotを使用し、フローを BizTalk アプリケーションにマップする必要があることを指定します。ただし、BizTalk に最適な機能は、Azure Logic Appsの Standard ワークフローに最適なワークフローと同じではないことを考慮してください。この概念は、最新化における最初のパラダイム変更の 1 つです。

手順 3: ソース設計を分析する

移行エージェントがスキャンを完了し、結果として得られる論理フローグループを表示したら、次の手順に従います。

[ ホーム ] タブで、目的の論理フローグループの [ ソースデザインの分析] を選択します。次に例を示します。

エージェントは、次のタスクを実行します。
1. オーケストレーション、スキーマ、マップ、パイプライン、バインドを含む成果物インベントリを構築します。
2. 成果物間のリレーションシップを示す依存関係グラフを生成します。
  
  依存関係グラフを生成するために、移行エージェントは次のタスクを実行します。
  - メッセージフローとコンポーネントを示すアーキテクチャ (人魚) 図を生成します。
  - 不足している依存関係を識別します。
  - フィーチャのギャップ解析を実行します。
  - パブリッシュ/サブスクライブ、要求/応答、バッチなどの統合パターンを検出します。
  - Azure Logic Appsまたはその他のサービスの代替手段のマッピングを提案します。
  - 結果に基づいて検出レポートを生成します。
  移行エージェントが依存関係グラフを正常に生成すると、フロービジュアライザーが開き、次の対話型タブが表示されます。
  - アーキテクチャ図
  - メッセージフロー
  - コンポーネント
  - 不足している依存関係
  - ギャップ分析
  - パターン
  - BizTalk について
  次の例は、生成されたフローの視覚化の例を示しています。
  
  詳細については、「ソース設計の分析と結果」を参照してください。
分析結果を確認するには、タブを選択して関連情報を確認します。

手順 4: 分析を更新またはエクスポートする

分析結果を確認した後、フロービジュアライザーのタイトルバーで、次のいずれかのアクションを選択します。

Action	説明
変更の提案	分析に直接変更を要求します。 Tip: フローグループの潜在的な更新または修正について説明するには、フロービジュアライザーで、Copilot チャットウィンドウを使用します。フローグループを選択し、検出されたアーキテクチャについて `@migration-analyser` エージェントに質問します。不足しているギャップに関する情報を提供し、分析を再生成します。
分析の再生成	不足している依存関係、成果物、仕様の追加など、分析を更新した後、分析を再実行します。
レポートのエクスポート	共有可能な形式で検出結果を含むレポートを生成します。

または、その他のフローを分析するには、[ ホーム ] タブまたはホームページアイコンを選択します。

完了したら、計画ステージの次のセクションに移動します。

移行ステージ 2: 計画

分析が完了したら、次の移行ロードマップを作成して計画ステージを開始します。詳細については、「移行エージェントステージ 2: 計画」を参照してください。

[ ホーム ] タブで、目的の論理フローグループを選択し、[ ロジックアプリデザインの計画] を選択します。

@migration-planner エージェントは、通常、次のセクションを含む移行計画を生成します。
- アーキテクチャ
- 追加Azure コンポーネント
- 操作マッピング
- 成果物の処理
- 移行のギャップ
- 統合パターン
- まとめ
- 工数の見積もり
- タスク計画
次の例は、生成された移行計画のサンプルを示しています。

詳細については、「計画ステージアクション」を参照してください。
変換ステージに進む前に、各プランをよく確認してください。必要に応じて更新を行います。

プランの精度は、変換出力の品質に大きく影響します。

プランに更新プログラムが必要かどうかを判断するには、Copilot チャットを使用して @migration-planner GitHub Copilot エージェントと対話し、次のタスクを完了します。
- 特定のマッピングについて質問します。
- ギャップ解決のための代替アプローチを要求します。
- 作業量の見積もりを調整します。
- 変換に進む前に、プランの変更を要求します。
準備ができたら、[ ホームページ ] を選択するか、[ ホーム ] タブに戻ってコンバージョンステージに進みます。

移行ステージ 3: 変換

移行計画に満足したら、変換ステージを開始して、ソース成果物をAzure Logic Appsのための標準ワークフロー、接続、およびその他のサポートファイルに変換する変換タスクを作成して実行します。

3.1: 変換タスクを作成する

[ ホーム ] タブで、論理フローの [ 変換タスクの作成] を選択します。

@migration-converter エージェントによって変換タスクが作成されます。これは、特定の論理フローグループによって異なります。次の一覧では、 Method Call Processingという名前の論理フローグループのサンプル変換タスクについて説明します。

Step	Task	説明
1	Scaffold Logic Apps Project	必要なフォルダー階層とファイルを含む Standard ロジックアプリプロジェクト構造を作成します。
2	入力スキーマの変換	InputSchema.xsd ファイルを BizTalk 形式 (BizTalk 注釈付き UTF-16) から標準 XSD (BizTalk 注釈なしの UTF-8) に移行します。
3	出力スキーマの変換	BizTalk 注釈を含む UTF-16 である BizTalk 形式から、BizTalk 注釈のない UTF-8 である標準 XSD に OutputSchema.xsd ファイルを移行します。
4	*< connector-name> 接続の生成*	必要な各接続の構成を含む connections.json ファイルを作成または更新します。
5	< > ワークフローを生成する	論理フローグループのAzure Logic Appsに標準ワークフロー定義を含むworkflow.json ファイルを作成します。
6	*ローカル関数の生成 (<function-names>)*	ソースコード.NETカスタムロジック用の 8 つのローカル関数を作成します。
7	ランタイムの検証 (func start)	`func start`を実行してロジックアプリプロジェクトを検証し、すべての関数とワークフローの準備ができていることを確認します。
八	E2E テスト (ハッピーパス & エラーパス)	満足のいくパス、エラーパス、フィールドレベルの検証に対してエンドツーエンドのテストを実行します。
9	ブラックボックステスト (省略可能)	指定した外部テストデータを使用するテストを実行します。
10	クラウドデプロイとテスト (省略可能)	Azureにデプロイし、クラウド E2E テストを実行します。

次の例は、 Method Call Processing 論理フローグループに対して生成された変換タスクの例を示しています。

次のセクションでは、 ホームページ を選択するか、[ ホーム ] タブに戻ります。

3.2: 変換タスクを実行する

@migration-converter エージェントで各変換タスクを実行するには、[実行] を選択しますが、クラウドデプロイとテストの前に停止します。または、[すべて実行] を選択します。これは、[ホーム] タブの [変換タスクの実行] を選択した場合と同じように機能します。

Note

変換タスクの実行中に、エージェントはファイルを編集するためのアクセスまたはアクセス許可を求めるメッセージを表示する場合があります。使用可能なオプションを確認し、適切に応答します。
次のセクションでは、 ホームページ を選択するか、[ ホーム ] タブに戻ります。

3.3 出力の完全性と品質を確認する

@migration-converter エージェントは、すぐに実行できる標準ワークフロー定義と配置可能なプロジェクト成果物を生成します。このエージェントは、 no-stubs-code-generation スキルを使用して、生成されたすべてのコードが完全に機能し、スタブ実装、プレースホルダーコード、または TODO コメントが存在しないことを確認します。

テスト用にワークフローをローカルで実行する検証ステージに対して生成された出力を準備するには、ワークフロー定義、接続、および生成された.NETローカル関数の不正確性を手動で検査してください。

Important

ベストプラクティスとして、AI で生成された出力を使用する前に必ず確認してください。このような出力には、正しくない情報が含まれている可能性があります。

生成された出力を確認するには、次の手順に従います。

[Home] タブで、論理フローの [Open in Visual Studio Code を選択します。
移行フォルダーで、 out ディレクトリに移動し、生成されたソリューションフォルダーを選択します。次に例を示します。
各 workflow.json ファイルを調べて、トリガーとアクションがソースの動作と一致することを確認します。

ヒント

生成された出力について質問したり、変更を要求したり、特定のワークフローを再生成したりするには、Copilot チャットを使用して @migration-converter エージェントと対話します。
connections.json ファイルで正しいコネクタ構成を確認します。
生成された.NETローカル関数の正確性を確認します。

移行ステージ 4: 検証

検証ステージでは、生成されたワークフローをソースの仕様に照らしてテストします。独自のテストケースと仕様を持ち込むことができます。 @migration-converter エージェントは、ランタイムの検証とテストのガイダンスを提供します。目標は、変換されたワークフローが期待どおりに動作し、ソースフローの動作と一致することを確認することです。

ヒント

直接比較を簡単に行えるようにするには、検証中にソースプラットフォームのテストデータと予想される出力をすぐに使用できるようにします。

たとえば、移行計画には、外部入力を使用するためのオプションのブラックボックステスト機能が用意されています。

ワークフローをローカルでテストするための要件

検証手順を開始する前に、テスト用に次の要件がインストールされていることを確認します。

Requirement	Purpose
Azure Logic Apps (Standard) 拡張機能	必要な拡張機能の依存関係
Azure Functions Core Tools	Azure Logic Appsのローカルランタイムホスト (Standard)
Docker Desktop	接続のテストと実行のためのローカルコネクタリソースのデプロイ

ワークフローをローカルでテストする

生成されたワークフローをローカルで実行するには、次の手順に従います。

[Home] タブで、論理フローの [Open in Visual Studio Code を選択します。
移行フォルダーで、 out ディレクトリに移動し、生成されたソリューションフォルダーを選択します。
生成されたロジックアプリプロジェクトフォルダーを開きます。
Docker Desktop が実行されていることを確認します。
Run メニューで、 デバッグの開始 (キーボード: F5) を選択して、Azure Logic Appsのランタイムをローカルで開始します。

ランタイムが開始され、ワークフローがローカルエンドポイントで使用できるようになります。
サンプル入力データを使用してテスト要求を送信するか、ワークフローをトリガーします。
生成されたワークフローの動作をソースの動作と比較して、不一致や不正確さを特定します。

次のチェックリストでは、検証する動作について説明します。
- すべてのトリガーが、想定される入力形式で正しく起動します。
- アクションシーケンスは正しい順序で実行されます。
- データ変換では、期待される出力が生成されます。
- 条件付きロジックは、入力データに基づいて予想される結果で正しく分岐します。
- ループコンストラクトは、すべての項目を想定どおりに処理します。
- エラー処理スコープは、例外を適切にキャッチして処理します。
- 接続構成は、正しいエンドポイントに確立されます。
- .NETローカル関数は、期待される結果を返します。
見つけた不一致や問題を調査して修正します。
ヒント

解決プロセスを支援するには、@migration-converter エージェントとの不一致や問題について、Copilotチャットを通じて話し合います。
1. Copilotチャットで、想定される動作と実際の動作について説明します。
2. エージェントの推奨される修正プログラムを確認します。
3. エージェントの推奨事項に同意し、変更を加えた場合は、ワークフローの更新された部分を再生成するようにエージェントに依頼します。

移行ステージ 5: デプロイ

デプロイステージでは、移行された Standard ソリューションを Azure ポータルの Azure Logic Apps にデプロイします。

ワークフローをデプロイするための要件

デプロイ手順を開始する前に、次の要件を満たしていることを確認してください。

Requirement	Purpose
Azure CLI	Azureリソースをプロビジョニングしてデプロイします。
Azure サブスクリプション	デプロイに使用するターゲットサブスクリプション。
共同作成者アクセス	ターゲットリソースグループにリソースを作成するためのロールベースのアクセス。

生成されたワークフローをローカルで実行し、その動作がソースの動作と一致することを確認するなど、移行エージェントのステージ 1 (検出) から 4 (検証) が完了していることを確認します。

手順 1: 展開の拡張機能の設定を設定する

Visual Studio Codeで、拡張機能の設定を開きます。 File メニューから、Preferences>Settings に移動します。 >Extensions>Azure Logic Apps Migration Agent。

必要に応じて、次のデプロイ設定値を更新します。

設定名	JSON 名	説明	デフォルト	Action
場所	`logicAppsMigrationAssistant.azure.location`	リソースをプロビジョニングするためのAzure リージョン。	`eastus`	この値を目的のリージョンに変更します。
リソースグループ	`logicAppsMigrationAssistant.azure.resourceGroup`	プロビジョニングとテスト用のAzure リソースグループ。	`integration-migration-tool-test-rg`	この値を、目的のリソースグループ名に変更します。
サブスクリプション ID	`logicAppsMigrationAssistant.azure.subscriptionId`	デプロイのAzure サブスクリプション ID。	(空)	Azure サブスクリプションの GUID を入力します。
デプロイメントモデル	`logicAppsMigrationAssistant.deploymentModel`	Azure Logic Apps (Standard) のターゲットデプロイモデル。	`workflow-service-plan`	必要に応じて、この値を `hybrid` に変更します。

手順 2: デプロイプロセスを開始する

Azureへのデプロイを開始するには、次の手順に従ってください。

Azure サブスクリプションでAzure CLIにサインインします。次に例を示します。
```
az login
```
Azure Logic Apps移行エージェント[ウィンドウから移行プランを開き、Cloud Deployment とテストタスクを実行を選択してください。

移行エージェントは、必要なインフラストラクチャをプロビジョニングし、Azure CLIを使用して Standard ロジックアプリのリソースとワークフローをデプロイします。

完全に移行されたソリューションの例を次に示します。

Visual Studio Code と完全に移行されたソリューションを示すスクリーンショット

手順 3: デプロイを確認する

デプロイが完了したら、Azure ポータルに Standard ワークフローが表示されることを確認します。

Azure ポータル検索ボックスに「logic apps」と入力し、Logic apps を選択します。
[ ロジックアプリ ] ページで、Standard ロジックアプリリソースを選択します。
ロジックアプリのサイドバーの [ ワークフロー] で、[ ワークフロー] を展開します。 [ ワークフロー ] ページで、必要なすべてのワークフローが表示されることを確認します。状態が有効になっていることを確認します。

Note

無効になっているワークフローの場合は、[ワークフロー] チェックボックスをオンにします。 [ ワークフロー ] ツールバーの [ 有効] を選択します。
サンプル入力を使用して各ワークフローをテストし、期待どおりに動作することを確認します。
ランタイムエラーやパフォーマンスの問題を見つけるには、Standard ロジックアプリリソースの Application Insights ページに移動します。
1. ロジックアプリのサイドバーの [ 監視] で、[ Application Insights] を選択します。
2. [ Application Insights リソースへのリンク] で、Application Insights リソースへのリンクを選択します。
詳細については、「 Application Insights でワークフローメトリックを表示する」を参照してください。

移行をリセットする

最初から移行を再開できます。次のコマンドは、移行状態をクリアし、探索ステージから再開できるようにします。

Visual Studio Codeで、コマンドパレットを開きます (キーボード: Ctrl + Shift + P)。
プロンプトで、「Azure Logic Apps Migration Agent: Reset Migration」と入力します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-05-06