Microsoft Build 2026（6月2日開催）で、Azure Integration Servicesに関する6つの重要発表が行われた。Logic Apps AutomationのSaaS SKU新設、C# SDKによるコードファースト開発、API ManagementのAIゲートウェイ強化など、統合基盤全体がAIエージェントの「生産インフラ」として機能するよう大幅に再設計されている。
Azure Logic Apps Automationとは何か
最大のトピックは「Azure Logic Apps Automation」の登場だ。パブリックプレビューとして公開され、auto.azure.com からアクセスできる。
既存のLogic Apps Standardの「置き換え」ではない点に注意が必要だ。同じランタイム・同じコネクタ基盤の上に、SaaS型の体験を乗せた新しいSKUとして位置づけられている。主な特徴をまとめると：
- AIアシスタント内蔵: 自然言語でワークフローを説明すると、AIがアクション設定・式記述・インラインコード生成まで自動で下書き
- エラスティックスケール: vCPU秒単位の従量課金。アイドル時はゼロスケール。年間コミットも席単位ライセンスも不要
- ガバナンス2層構造: 「プロジェクト」（セキュリティ境界）と「アプリケーション」の2層で管理。ネットワークポリシー・コネクタポリシー・承認済みAIモデルをプロジェクト単位で一括設定し、配下のアプリが継承する
ガバナンス設計は企業ニーズに沿っている。「開発者のスピード」と「中央管理」を両立させる構造は、IT部門とビジネス部門の間でよく起きる綱引きを緩和する仕組みだ。
AIエージェント対応も最初から織り込まれている。エージェントループのオーケストレーション、Microsoft Foundryのホスト済みエージェントをキャンバスから直接呼び出す機能、GitHub Copilotのようなエージェントハーネスのためのマネージドサンドボックス（シェルアクセス付き）も備える。
なお、現時点ではVNet統合は未対応。VNetが必要な場合は引き続きLogic Apps Standardが正解で、VNet対応はロードマップ上の項目にとどまっている。
提供リージョン（プレビュー時点）: East Asia・Sweden Central・Australia East・North Central US・UK South・Southeast Asia・West US。Japan EastおよびJapan Westは現時点で含まれていない。
コードで書くLogic Apps：C# SDK登場
「デザイナー画面が苦手でコードで書きたい」という開発者にとって待望の発表がLogic Apps Standard SDK（NuGetパッケージ Microsoft.Azure.Workflows.Sdk）だ。
workflow .AddTrigger(WorkflowTriggers.BuiltIn.Request()) .Then(WorkflowActions.BuiltIn.ParseJson(…)) .Then(WorkflowActions.Managed.Office365.SendEmail(…)) .Then(WorkflowActions.BuiltIn.Response());
フルーエントAPIでワークフローを記述すると、既存のLogic Apps Standardランタイムが実行するJSONにコンパイルされる。新しいランタイムではないため、既存資産との互換性は維持される。
メリットとして得られるものは大きい：
- 型安全性とIntelliSenseによる開発体験の向上
git diffでワークフロー変更がコードレビューできる- コンパイル時エラー検出でデプロイ前に問題を潰せる
- Condition・ForEach・Switch・Until・ScopeといったControl Flowがファーストクラスで使える
CustomCodeアクションでC#メソッドをインラインで書ける
ソフトウェアエンジニアがLogic Appsに参入しやすくなり、GitベースのCI/CDパイプラインへの統合も自然に進む。
AI Gateway強化・Azure API Center GA・Knowledge as a Service
API ManagementのAI Gateway機能がさらに強化されている。LLMへのトラフィック制御・コスト管理・セマンティックキャッシュ・プロンプトインジェクション対策など、AIワークロード固有の要件に対応する機能群が追加された。
Azure API CenterはGA（一般提供）に移行。組織全体のAPIインベントリを一元管理し、AI時代のAPIガバナンスを支える基盤として正式に位置づけられた。プレビュー段階での採用を見合わせていたチームには、本番導入を検討するタイミングが来ている。
Knowledge as a Serviceは、RAGパイプライン（Retrieval-Augmented Generation、検索拡張生成）をロジックとして組み込む仕組みだ。Logic Apps Automationに内蔵されており、エージェントが参照する「知識」を1,400以上のコネクタ経由で取得・格納するフローを低コードで構築できる。
日本のエンジニア・IT管理者への実務ポイント
今すぐ確認・試せること：
auto.azure.comでLogic Apps Automationのパブリックプレビューを確認する。本番投入前に機能可用性を必ず検証すること（プレビュー段階のため機能変更の可能性あり）- C# SDK（
Microsoft.Azure.Workflows.Sdk）をNuGetで追加し、既存のLogic Apps Standardプロジェクトにコードファースト開発を試験導入する - Azure API Centerを評価候補に加える（GAしたことで本番採用のハードルが下がった）
設計判断のヒント：
| 要件 | 推奨SKU |
|---|---|
| VNet統合が必要 | Logic Apps Standard（継続） |
| エージェントワークフローを素早く立ち上げたい | Logic Apps Automation |
| コードファーストで開発したい（既存インフラは維持） | Logic Apps Standard + C# SDK |
コスト面の注意： エラスティックスケールはvCPU秒課金のため、高頻度・高負荷のワークフローでは従量課金が想定外に膨らむことがある。事前のコスト試算を丁寧に行うこと。
日本リージョン対応の確認が必須： データレジデンシー要件がある場合、現時点でLogic Apps AutomationはJapan East・Japan Westに未対応。GAまでのロードマップを確認してから採用判断をすること。
筆者の見解
今回の発表群を見て率直に感じるのは、「統合基盤をAIエージェントの実行層として再定義しようとしている」という強いメッセージだ。Logic Apps・API Management・API Centerをそれぞれ強化するのではなく、「AIエージェントが安全に・スケーラブルに動くプラットフォーム」という一本の軸で全体を再設計している。この一貫性はMicrosoftの強みだと思う。
ガバナンス設計は特に評価したい。プロジェクト単位で承認済みAIモデルを設定し、配下のアプリケーションが継承するモデルは、「AIの利用を禁止するのではなく、安全に使える仕組みを作る」という方向性として正しい。禁止アプローチは必ず回避策を生む。公式ルートが一番便利と感じさせる仕組みを作ることが本質だ。
C# SDKも地味に大きい。Logic Appsはこれまで「ノーコード/ローコードのツール」として見られがちで、ソフトウェアエンジニアに敬遠されてきた経緯がある。コードファーストの選択肢が加わることで、GitベースのCI/CDとの統合が格段にやりやすくなり、エンジニアチームへの浸透が進むだろう。
一点だけ期待を込めて言えば、日本リージョンへの対応を急いでほしい。日本のエンタープライズ顧客はデータレジデンシーを重視しており、Japan Eastが使えてはじめて本格的な採用検討に入れる。Microsoft Foundry・Entra ID・Logic Apps・API Managementで一貫した実行基盤を作るという構図は一貫しており、日本市場での普及を加速させる意味でも、リージョン拡大のスピードに期待したい。
出典: この記事は Microsoft Build 2026: Everything New in Azure Integration Services の内容をもとに、筆者の見解を加えて独自に執筆したものです。