Azure

Microsoft は2026年6月のBuild 2026（サンフランシスコ）において、Microsoft Foundryに対してエンタープライズ向けAIエージェントの本番運用を支える大規模な機能拡張を発表した。単なる「新しいモデルエンドポイントの追加」ではなく、ランタイム・ツール管理・メモリ・知識検索・ガバナンスまでを一体で提供する「AIエージェント工場」へと進化した形だ。 Foundryとは何か——改めて整理する Microsoft Foundryは、Azureを基盤とした統合AIアプリ・エージェント開発プラットフォームだ。Azure サービスとのネイティブ連携、Microsoft 365データソースへのアクセス、そしてフレームワーク間の相互運用を特徴とする。今回のアップデートは、2025年にGA（一般提供）となったAzure AI Foundry Agent Serviceをさらに拡張するものとなっている。 今回追加された主要機能 ホスト型エージェントインフラ（Foundry Agent Service） マネージドなサンドボックスセッションが提供され、エージェントは状態・ファイルシステムアクセス・複数フレームワーク対応を持ったまま動作できる。APIはステートフルな「Responses API」と軽量な「Invocations Protocol」の2種類が用意され、用途に応じて使い分けが可能だ。 注目すべきはルーティン（Routines）機能がパブリックプレビューに入ったことだ。エージェントをスケジュール実行できるようになり、「夜間のチケットトリアージ」「日次レポート生成」といったバッチ的な自動化がFoundry上で完結する。OpenClawやHermesといった長時間稼働エージェントも、永続的な状態とファイルを持ったまま動作できる。 Toolbox——ツール管理の一元化 ツール・スキル・MCPクライアント・エンタープライズデータ統合を一本のマネージドエンドポイントに集約する「Toolbox」がパブリックプレビューになった。これまでは各エージェントにツールをハードコードする必要があったが、Toolboxでは登録したツールをランタイムに動的に検索・呼び出せる。 特に重要なのがTool Search機能だ。モデルに全ツールを渡すのではなく、タスクに関連する少数のツールだけを選択してモデルに提示する。これはコストとレイテンシの両方に効く実用的な設計だ。 また、Microsoft TeamsおよびMicrosoft 365 Copilotへの直接パブリッシュが2026年6月にGA予定となった。Foundryで構築したエージェントを、IDやポリシーが自動適用された状態で従業員の日常作業環境に展開できる。 メモリ機能——「何を話したか」から「どうやるか」へ Foundry Agent Serviceのメモリは、手続き記憶（Procedural Memory）・ユーザー記憶・セッション記憶の3種類に体系化された。 中でも手続き記憶はBuild 2026での新機能だ。従来のメモリが「何を話したか」を記録するものだったのに対し、手続き記憶は「どうやって仕事をこなすか」をエージェントが学習し次回以降に活かす機能だ。初期ベンチマーク（Tau bench）では、タスク成功率が7〜14ポイント改善したと報告されている。コストはほぼ変わらない水準での改善だという点も評価できる。 メモリストアはMicrosoft Entra IDをスコープ識別子として使い、保持期間や内容の検査も制御できる。 Foundry IQ——知識レイヤーの統一 Work IQ・Fabric IQ・Azure SQL・ファイル検索など複数の情報源を単一のSLA付きナレッジレイヤー「Foundry IQ」として統合した。グラウンディング（文脈付与）と検索を一元化することで、エージェントが参照すべき情報源を個別に実装する手間をなくす設計だ。 日本のエンジニア・IT管理者への影響 AIエージェント導入の「本番稼働」ハードルが下がる これまで日本企業がAIエージェントの本番導入を躊躇する理由の一つは、「ガバナンスや監査対応をどうするか」という問題だった。今回のFoundry強化により、Entra IDと統合した権限管理・ポリシー適用・オブザーバビリティがプラットフォームレベルで提供される。セキュリティポリシーの実装をエージェントごとにゼロから作る必要がなくなる。 Toolboxは「AIエージェントのマイクロサービス化」 Toolboxの思想は、エンタープライズ内の業務機能をMCPスキルとして登録し、複数エージェントから再利用するアーキテクチャを促進する。日本企業で多い「部署ごとに似たようなツールを個別実装」という状況を、組織横断で共有するツールカタログへと変えていく布石になり得る。 ルーティン機能で既存の自動化ニーズを取り込む 「夜間バッチで稼働するAgentにする」という需要は日本のSI現場でも強い。Foundry上でスケジュール実行が完結するようになれば、既存の定時ジョブをAIエージェントとして再設計する際の移行コストが下がる。 筆者の見解 Microsoft Foundryの今回の発表を見て、「ここにいた」と感じた。モデルをAPIで呼ぶだけなら誰でもできる。難しいのは、エンタープライズがAIエージェントを安全に、監査可能な形で、既存のIDインフラと統合して動かすことだ。その「難しい部分」をプラットフォームが引き受けるという方向性は、正しいと思う。 Entra IDをエージェントの管制塔として使う設計は長期的に見ても筋が良い。ゼロトラストの観点からも、エージェントのアイデンティティ管理は人間と同じ仕組みに統合されるべきであり、Foundryはその方向に向かっている。 一方で、手続き記憶の「7〜14ポイント改善」という数字はベンチマーク環境での話だ。実運用での再現性はこれから問われる。日本企業が本番導入を進めるには、ガバナンス設定の複雑さや既存システムとの統合コストをどう下げるか、ドキュメントとサポート体制がカギになるだろう。 ツールチェーン全体を統合し、エージェントが安全に動ける場所を作るというのはMicrosoftが最も強みを持てる勝負だ。その力を存分に発揮できるよう、実装の細部まで丁寧に仕上げてほしいと思う。 出典: この記事は Microsoft Foundry Adds Runtime, Tooling, and Governance for Production Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は「MSBuild 2026」にて、Azure App Service に「Easy AI」と呼ばれる新機能群を追加し、既存の Web アプリケーションを Model Context Protocol（MCP）エンドポイントとして公開できる仕組みを発表した。コードのリアーキテクチャなしに既存の Web API を AI エージェントの「道具」として接続できるようになる、エンタープライズにとって実用性の高いアップデートだ。 Easy AI とは何か Easy AI は、Azure App Service 上で稼働する既存 Web アプリを、最小限のコード変更で AI エージェントから呼び出し可能なサービスに変換するための機能セットだ。 中核にあるのが MCP エンドポイント化の仕組みだ。MCP（Model Context Protocol）は Anthropic が提唱し、各社が採用を進めているオープンなプロトコルで、AI エージェントが外部ツールやデータソースと標準的な方法でやり取りするための仕様だ。Azure AI Foundry・各種 IDE プラグイン・サードパーティ製エージェントフレームワークなど、あらゆる AI エコシステムが対応を進めており、事実上の業界標準になりつつある。 今回の発表により、Azure App Service 上の Web API は既存のコードベースを大きく変えることなく MCP サーバーとして機能するようになる。 リアーキテクチャ不要の意味 従来、AI エージェントから業務システムを呼び出そうとすると、以下の課題があった。 既存 API を MCP 形式に対応させるための書き直し 認証・認可の仕組みを再設計する必要性 エージェントランタイムとのセッション管理の複雑さ Easy AI はこれらを App Service のプラットフォームレイヤーで吸収し、アプリケーション開発者が意識しなくてよい部分を自動化する。裏側では Microsoft Entra ID による認証フローと統合されており、エージェントが安全にエンドポイントを呼び出せる仕組みが整っている。 ...

AnthropicのClaude Fable 5が2026年6月9日よりMicrosoft Foundry（Azure AI Foundry）で利用可能になり、AzureはOpenAI・Anthropicという2大フロンティアモデルプロバイダー双方を提供する唯一のクラウドプラットフォームとなった。 Claude Fable 5の主な特徴 Claude Fable 5は「エージェントファーストアーキテクチャ」を掲げて設計された最新世代モデルだ。単純な質問応答にとどまらず、複数ステップにわたるタスクを自律的にオーケストレーションできる点が最大の特徴となる。 コンテキストウィンドウは標準50万トークン（500K）、拡張版では200万トークン（2M）と、長大なドキュメントや複雑なコードベース全体を一度に処理できる容量を持つ。数百ページの仕様書、大規模なコードリポジトリ、複数の会話履歴を同時に扱うエージェント型アプリケーションの構築に直結する能力だ。 エージェントファーストアーキテクチャとは 「エージェントファースト」は昨今のAI業界のキーワードだが、Claude Fable 5の文脈では具体的に以下を意味する： マルチステップタスクの自律実行: ツール呼び出し、外部API連携、中間判断を人間の介在なしに連鎖実行 長期コンテキスト保持: 大容量のコンテキストウィンドウにより、セッション全体を通じた一貫した判断が可能 並列エージェントオーケストレーション: 複数のサブタスクを並行処理する構成が組みやすい 従来のRAG（Retrieval-Augmented Generation）パターンがデータ取得に特化していたのに対し、エージェント型アーキテクチャは「思考→ツール使用→判断→次のアクション」というループを自律的に回す点で質的に異なる。 Microsoft Foundryとの統合 Microsoft Foundry（旧称Azure AI Foundry）は、Azure上で複数のAIモデルを統合的に管理・デプロイするためのプラットフォームだ。Claude Fable 5の追加により、以下が一つのプラットフォーム上に揃うことになる： 提供元 主なモデル OpenAI GPT-4o、o3シリーズ等 Anthropic Claude Fable 5、Claude 3.xシリーズ Microsoft Phi-4等のオープンモデル エンタープライズ利用では、Microsoft Entra IDによるアクセス管理、Azure Private Linkによるプライベートネットワーク接続、各種コンプライアンス認証（ISO 27001、SOC 2等）がそのまま適用される。既存のAzureインフラとの親和性は高い。 実務への影響 日本のエンジニア・IT管理者へのポイント： 1. モデル選定の自由度が増す Azureの契約・セキュリティ要件を維持しながら、ユースケースに応じてOpenAIとAnthropicのモデルを使い分けられる。長文処理や複雑なエージェントタスクにClaude Fable 5、既存のGPT連携はそのままという運用も現実的だ。 2. エンタープライズセキュリティの継続 Microsoft Entra IDとのID管理統合、VNetプライベートエンドポイント対応はそのまま利用可能。セキュリティポリシーを変えずに最新モデルを評価できる。 3. 2Mトークンの実用性 200万トークンは日本語換算で概ね100万〜150万字程度に相当する。大規模なシステム仕様書、複数のソースコードファイル、長期にわたる会話ログを「丸ごと渡す」設計が現実的になる。コンテキスト管理の複雑さが大幅に軽減されるため、エージェント設計の初期コストが下がる。 4. エージェント設計への投資タイミング マルチステップエージェントの本格実装を検討しているチームは、今がアーキテクチャ設計を始める適切な時期だ。モデル側の能力がエージェント型ワークフローを実用的に支えるレベルに達しつつある。 筆者の見解 Azureが「モデルを選べるプラットフォーム」として機能し始めたことは、Microsoft基盤を使い続けるための非常に強い理由になる。 ...

Microsoftが2026年6月Patch Tuesdayで史上最多となる208件のCVE（Chromiumなど第三者ソフトを含めると571件）を一挙公開した。Azure Logic AppsとAzure HorizonDBには権限昇格（Privilege Escalation）の重大脆弱性が確認されており、セキュリティチームは優先度を上げた対応が求められる。 過去最大規模のパッチリリース Zero Day Initiative（ZDI）のDustin Childs氏が2017年からPatch TuesdayのCVEを集計してきたが、今月は過去最高記録を大幅に更新した。従来の記録は2025年に記録された177件だったが、今月は自社製品だけで208件、第三者ライブラリ込みで571件という桁外れの規模になった。 内訳は以下の通りだ： Critical（緊急）: 38件 Important（重要）: 残りすべて 実際に悪用が確認されている脆弱性: 1件 公開済みの脆弱性（悪用の可能性あり）: 3件 対象製品はWindows、Office、Microsoft Edge（Chromium）、Azure、.NET/Visual Studio、GitHub Copilot、Defender、Exchange Server、Hyper-V、Secure Boot、BitLockerと広範にわたる。ちなみに2026年上半期だけで出荷されたCVE数は、2018年の年間総数をすでに超えている。 Azureで注目すべき重大脆弱性 Azure関連では特に2点に注意が必要だ。 Azure Logic Apps と Azure HorizonDB に権限昇格（EoP: Elevation of Privilege）の重大脆弱性が確認されている。Logic AppsはさまざまなAzureサービスやSaaSとの自動ワークフローを担うコンポーネントであり、ここに権限昇格の穴があると攻撃者がワークフロー実行コンテキストを乗っ取れる可能性がある。HorizonDBはAzureの分析・データ基盤コンポーネントであり、大量のビジネスデータを扱う環境では侵害時の影響範囲が広い。 悪用が確認されている脆弱性はWindows関連の1件のみとされているが、AzureのEoP脆弱性は「研究者に積極的に調査される」タイプの案件であり、公開後の悪用PoC（実証コード）出現まで猶予は短いと考えておくべきだ。 Adobeも大規模パッチ——Campaign ClassicとColdFusionは最優先 Microsoftと並行して、Adobeも11本のセキュリティ情報で123件のCVEを修正した。対象製品はAcrobat Reader、ColdFusion、Experience Manager、InDesign、Dreamweaver、Campaign Classicなど多岐にわたる。 ZDIが「デプロイ優先度1」と評価するのは次の2件だ： 製品 CVE数 最高CVSS 優先度 Adobe Campaign Classic 2 10.0 1 Adobe ColdFusion 7 9.6 1 CVSS 10.0は「理論上の最悪スコア」であり、1つ出るだけでも珍しい。Campaign Classicの同一セキュリティ情報に2件並ぶのは極めて異例だ。現時点では野外攻撃は確認されていないが、「すぐに悪用コードが書かれる」とZDI自身が想定している。ColdFusionも歴史的に攻撃者に好まれるターゲットであり、放置は禁物だ。 Acrobat Readerのパッチ（20件）もランサムウェア攻撃での悪意あるPDF悪用が多い点から目が離せない。 AI生成パッチへの疑問——品質と「新たな常態」 ZDIのChilds氏が今月特に強調しているのが、パッチ品質と持続可能性への問いだ。 これほど多くの脆弱性がAIツールで発見されたのか？ パッチ生成や検証にAIが関与しているとしたら、品質担保はどうなっているのか？ 先月・先々月も大規模リリースだった。「200件超」が新たな月次標準になるのか？ Microsoftはこれらの問いに現時点で回答していない。なお今回のリリースには2020年のCVEが誤って混入するというミスもあり、リリース管理プロセスに何らかの問題が生じていることを示唆している。 ...

検証やお客様対応などで複数のMicrosoft Entra ID（旧Azure AD）テナントを行き来している方、毎回 az login していませんか？「またログインか…」続きをみる note.com で続きを読む →

Microsoftは2026年6月2日、Azure Kubernetes Service（AKS）をベアメタルのスモールフォームファクターデバイス上で直接稼働させる「AKS on bare metal」をパブリックプレビューとして公開した。ハイパーバイザーや仮想化レイヤーを一切必要とせず、Azure Linuxネイティブに動作し、Azureポータルからクラウドと同一の操作感でエッジ環境全体を管理できる。 「AKS runs everywhere」——ベアメタルが最後のピースに AKSプロダクトチームが長年追い求めてきたビジョン「AKS runs everywhere」がいよいよ現実のものとなった。これまで、AKSはAzureリージョン、ソブリンクラウド、OEMハードウェア（Azure Local）と展開先を広げてきた。今回のベアメタル対応は、そのロードマップにおける最後のパズルピースに相当する。 エッジ環境は、データセンターとは根本的に異なる制約を抱えている。スペース・電力・予算がタイト。ハードウェアはコンパクトで、場合によっては過酷な環境向けに堅牢化されている。そして何より、ネットワーク接続が不安定だ。 これまでエッジでKubernetesを動かすには「ハイパーバイザーのライセンスや管理コストを受け入れるか、エッジ専用の別製品に乗り換えるか」の二択を迫られてきた。AKS on bare metalはこのジレンマを解消する。 ゼロタッチプロビジョニング——現地作業はUSBの差し込みだけ セットアップのフローは意図的にシンプルに設計されている。 AzureポータルからOSイメージが入ったUSBドライブを作成する 現地担当者がUSBを差し込み、デバイスの電源を入れる 数分待ってUSBを抜くだけ。それ以外の作業は不要 プロビジョニング中、デバイスボウチャー（認証情報）がUSBドライブに書き戻される。現地にインフラエンジニアは不要だ。その後はAzureポータルの「Azure Local スモールフォームファクター」作成画面でサイトを作り、ボウチャーをアップロードするだけで、デバイスは「Provisioned（プロビジョニング済み）」状態になる。 クラスター作成はクラウドのAKSと同じ操作だ。Azure RBAC設定、コントロールプレーンのネットワーキング構成、Azure Monitorの有効化、デプロイ——手順は共通で、Azure Linuxのベアメタルクラスターが完成する。 接続断でもワークロードは継続稼働 エッジ環境の最大の懸念点はネットワーク断だ。AKS on bare metalは、Kubernetesコントロールプレーンをデバイス上でローカルに実行するため、接続が切れてもデプロイ済みワークロードは通常通り動き続ける。 影響を受けるのはAzureポータルからの可視性と管理操作のみ。接続が回復すれば即座に同期が再開される。工場の製造ラインや小売店舗のPOSシステムのような「止められない」業務に適した設計だ。 Azure Kubernetes Fleet Managerで統合管理 AKS on bare metalは「エッジ専用の別物」ではなく、ファーストクラスのAKSクラスターとして扱われる。Azure Kubernetes Fleet Managerのダッシュボードに、クラウドのAKSクラスターと並んで表示され、同じツール・同じ操作で管理できる。 これはオペレーションコストの観点から非常に重要だ。エッジ固有のコンソールや手順を別途習得する必要がなく、既存のAKS運用スキルがそのままエッジに転用できる。 実務への影響——どんな現場が恩恵を受けるか AKS on bare metalが特に有効な日本の現場をいくつか挙げてみよう。 業種 想定ユースケース 製造業 工場フロアの生産ラインモニタリング・予知保全 小売・外食 店舗バックルームの在庫管理・POSシステム 金融・銀行 地方支店の業務システム（接続断対応が特に重要） 物流 倉庫・配送センターのリアルタイム仕分けシステム 「クラウドとエッジで別々のKubernetes基盤を管理する」というアーキテクチャは、運用コストとスキルの分散を招いてきた。AKS on bare metalはその構造問題を根本から解決するアプローチだ。 始める前に確認しておくこと 対応デバイスはスモールフォームファクター機器。現時点でのサポートハードウェアはAzureドキュメントを要確認 コントロールプレーンはデバイスローカルで動作するため、デバイスのスペック（CPU・RAM）がクラスターのキャパシティに直結する パブリックプレビュー段階のため、本番クリティカルシステムへの適用前に評価環境での検証を推奨 筆者の見解 「エッジのKubernetes管理が面倒くさすぎる」という声は、現場のエンジニアから何年も聞かされてきた。クラウドはAKS、エッジはk3sやMicroK8s、管理コンソールは別々、CIパイプラインも別々——という状況は、チームの認知負荷を不必要に高めてきた。 ...

MicrosoftがAzure Kubernetes Service（AKS）専用に設計した新OS「Azure Container Linux（ACL）」を一般提供（GA）開始した。従来AKSで利用されてきたFlatcar Container Linuxのサポートが2026年6月8日——つまり明日——廃止となるため、該当ユーザーには即時対応が求められる。 Azure Container Linux（ACL）が目指すもの ACLはMicrosoftがAKSのノードOS向けに新たに設計したコンテナ最適化イミュータブルOSだ。「イミュータブル（Immutable）」とは「変更不能」を意味し、OSのファイルシステムが実行中に書き換えられない設計になっている。 従来のLinuxは管理者がパッケージを個別にインストール・アップデートできる「ミュータブル（変更可能）」な設計だった。これは柔軟性が高い反面、アップデートの状態管理が複雑になり、「ドリフト」と呼ばれる構成の意図しない変化が発生しやすかった。ノードごとに微妙に状態が異なり、「あのノードだけ挙動が違う」という問題の温床でもある。 ACLはこの問題を根本から解決する。OSイメージ全体を一つの単位として管理し、アップデートはアトミックスワップ——つまりOSイメージ全体の切り替え——で適用する。部分的な更新途中での失敗が起きない設計で、切り替えに失敗した場合でも前のイメージへのロールバックが容易だ。 イミュータブルOSがもたらすセキュリティ上のメリット この設計はゼロトラスト・セキュリティとの相性が抜群だ。 読み取り専用のOSでは、仮にコンテナの脆弱性を突いた攻撃が成功しても、攻撃者がOSのバイナリや設定ファイルを直接改ざんすることができない。マルウェアがOS層に永続化するための足がかりを構造的に奪う。 また「構成ドリフト」の排除は、コンプライアンス観点でも重要だ。「先週まで問題なかったのに今日はこうなっている」というノード間の状態のばらつきがなくなり、監査対応や障害再現性の確保が格段に楽になる。「今動いているから大丈夫」という根拠のない安心感ではなく、設計によって状態の一貫性を保証できる点が大きい。 サポートライフサイクルと移行タイムライン ACLは3年間のサポートライフサイクルを提供する。エンタープライズ用途として標準的な期間だが、OSアップデートがアトミックスワップで適用されるため、従来より計画的なメンテナンスが可能になる。 Flatcar Container LinuxのAKSサポートは2026年6月8日——つまり明日——廃止となる。AKSクラスターでFlatcarを利用中のユーザーは今すぐ確認を要する。 実務への影響 AKSを本番利用している日本のエンジニアやインフラ担当者にとって、今日確認すべきことは2点だ。 1. ノードプールのOS設定確認 az aks nodepool show コマンドでノードプールのOS設定を確認し、Flatcarを使用しているノードプールがないかをチェックする。AzureポータルのAKSクラスター画面からも確認可能だ。 2. ACLへの移行計画 新規クラスターではACLがデフォルトになる方向にある。既存クラスターの移行はノードプールの再作成が基本的なアプローチとなる。 イミュータブルOSという特性上、ノード上に直接ファイルを配置したり、OS層にカスタムパッケージをインストールしたりしている運用は設計の見直しが必要だ。「DaemonSetでツールをデプロイする」「initContainerで初期設定を行う」といったKubernetesネイティブなアプローチへの移行を推奨する。 筆者の見解 イミュータブルOSをAKSの標準として採用するという判断は、Azureプラットフォームの方向性として筋がいいと思う。コンテナ基盤のノードOSが可変であることは、長年「仕方がないもの」として受け入れられてきたが、本来それはリスクだった。 ゼロトラストを語る文脈ではネットワーク層や認証層の話が先行しがちだが、ノードOSのイミュータビリティはインフラ層のゼロトラスト実装として「構造でセキュリティを担保する」設計思想だ。小手先のパッチ当てではなく、OSの設計レベルから変えてきたのは評価に値する。 FlatcarからACLへの移行は、単なるOS切り替えではなく、運用モデルそのものの見直しを迫るものでもある。「ノードに直接入って設定する」という昔ながらの運用スタイルを持ち込んでいるチームには変化が必要になるが、それはKubernetesの本来の思想に立ち返るという意味で悪い変化ではない。Azureプラットフォームの上でコンテナ基盤を動かすなら、その基盤の進化と足並みをそろえることが長期的な運用コスト削減の最短ルートだ。 出典: この記事は Introducing Azure Container Linux (ACL) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Azure FunctionsにAIエージェント向けサーバーレスランタイム（プレビュー）を追加し、.agent.mdファイルというMarkdownファーストのアプローチでエージェント定義を可能にした。 Azure Functions エージェントランタイムとは これまでAIエージェントを構築するには、オーケストレーション基盤・スケーリング設定・ツール接続などを個別に実装する必要があった。今回プレビュー公開された「Azure Functions サーバーレス エージェント ランタイム」は、この複雑さを一気に解消しようとする試みだ。 最大の特徴は .agent.mdファイルによるエージェント定義。YAML/JSONではなく、読みやすいMarkdown形式でエージェントの振る舞い・ツール・トリガーを記述できる。プロンプトエンジニアリングとコード定義を自然に統合した設計思想であり、AIエージェント開発の敷居を下げる明確なメッセージが込められている。 主な機能 スケールゼロ経済性 Azure Functionsの「使った分だけ払う」モデルをエージェントに適用。エージェントがアイドル状態のときはリソースゼロ、リクエストが来た瞬間に起動する。常時稼働のエージェントサーバーを維持するコストと比較すると、実験フェーズや低頻度ユースケースでの経済性は圧倒的だ。 MCPツールサーバーへのアクセス MCP（Model Context Protocol）に対応し、外部ツールをエージェントに統合できる。MCPはオープンプロトコルとして業界での採用が広がっており、MicrosoftがこれをAzure Functionsで公式サポートする動きはエコシステム全体にとって重要なシグナルだ。 1400以上のコネクタカタログ イベントドリブントリガーと組み合わせて、Logic AppsやPower Automateでおなじみの1400以上のコネクタにアクセス可能。SalesforceやSAP、ServiceNowなど既存の業務システムとエージェントを接続するハードルが大幅に下がる。 実務への影響──日本のエンジニア・IT管理者へ 今すぐ試せるポイント: PoCコストが激減: スケールゼロ設計により、エージェントの試験導入で余計なコストを気にせずに済む。まず動かして評価する文化を作りやすい 可読性の高い.agent.md設計: インフラエンジニアでなくても定義ファイルを読み書きできる。開発とビジネス側の会話コストが下がる 既存コネクタ資産の活用: すでにLogic AppsやPower Automateを使っている組織なら、コネクタ知識がそのまま転用できる MCP対応でAIモデルの選択肢が広がる: 特定AIモデルへのロックインを避けながら業務エージェントを構築できる設計になっている プレビュー段階のため本番利用は慎重に。ただしPoC開始のタイミングとしては今が最適だ。 筆者の見解 Azure Functionsがエージェントランタイムという新たな役割を担いはじめたことは、Microsoftのエージェントプラットフォーム戦略の具体化として注目に値する。 個人的にこの設計で評価しているのは、MCPという業界標準プロトコルを正面から採用している点だ。独自プロトコルで囲い込むのではなく、オープンな標準に乗ることで、Azure上で動かすAIモデルの選択肢をエンジニアに開放している。「エージェントが安全に動くプラットフォームとしてのAzure」というポジションを着実に固めている印象があり、これはMicrosoftが本来持っている強みを最大限に生かした戦略だと思う。 Markdownファースト設計も、開発者体験（DX）への本気度が伝わる。YAMLの深いネストに疲弊したエンジニアには朗報だろう。 一方、プレビュー段階であることは忘れてはならない。スケーリングの挙動やコールドスタートのレイテンシ、MCP接続の安定性など、本番ワークロードで必要な品質水準に達するまでの道のりはある。Microsoftにはここで手を抜かず、早期フィードバックを丁寧に拾い上げてGA品質に仕上げてほしい。エージェント基盤の信頼性こそが、この戦略の生命線になるはずだから。 出典: この記事は Introducing the Azure Functions serverless agents runtime (preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはBuild 2026において、Azure Managed Redisに「Agentic Memory」と呼ばれる新機能群を追加し、AIエージェントアプリケーション向けの記憶・検索基盤を大幅に強化した。ベクトル検索、セマンティックキャッシュ、RAG（Retrieval-Augmented Generation）パターンへの対応が柱となっており、エージェントがミリ秒単位でコンテキストを保持・取得できる設計になっている。 Agentic Memoryとは何か AIエージェントの最大の課題のひとつが「記憶の持ち方」だ。LLM（大規模言語モデル）はコンテキストウィンドウが有限であり、長期的な状態や過去のやり取りを保持するには外部のメモリストアが不可欠になる。 Azure Managed Redisに追加されたAgentic Memoryは、この課題に直接応えるものだ。具体的には以下の3つが軸になる。 ベクトル検索: テキストや画像などをベクトル化して保存し、意味的な類似度検索を超低レイテンシで実行できる。エージェントが「過去に似たような処理をしたか」を高速に参照する際に使われる セマンティックキャッシュ: 同一または意味的に近いクエリに対してキャッシュされた応答を返す仕組み。LLMへのAPIコールを削減し、コストと遅延の両方を改善する RAGパターン対応: 外部ドキュメントや社内ナレッジをRedis上に格納し、エージェントの応答生成時に関連情報をリトリーブするRAGフローをネイティブに構成できる エンタープライズ対応も同時強化 Agentic Memory機能と合わせて、以下の2点も発表された。 Entra IDベースのRBAC（パブリックプレビュー） Azure Managed RedisへのアクセスをEntra ID（旧Azure AD）のロールベースアクセス制御で管理できるようになった。これまでキーベースの認証が主流だったが、Entra IDと統合することでNon-Human Identities（NHI）——つまりエージェントやサービスプリンシパル——に対しても最小権限の原則を適用できる。 Flash最適化SKUのGA（一般提供開始） 最大1.5TBに対応するFlash最適化SKUが正式GA。大規模なベクトルインデックスや長期記憶を持つエージェントシステムでも、コストを抑えながらスケールアウトできるようになった。 日本のエンジニア・IT管理者への影響 AIエージェント開発への直接的な恩恵 AIエージェントをAzure上で開発している組織にとっては、記憶基盤の設計選択肢が広がる。これまでベクトルDBには別途Azure AI SearchやChromaDBを組み合わせるケースが多かったが、Redisに一元化できると構成がシンプルになる。マルチエージェント環境でのセッション状態管理にも有効だ。 RBACとNHI管理の整備 Entra ID統合RBACは見逃せない。エージェントが増えると、それぞれに適切な権限を付与する管理コストが跳ね上がる。Entra IDベースの制御が効くようになれば、Privileged Identity Management（PIM）との組み合わせでJust-In-Time（JIT）アクセスもエージェントに適用できる可能性が開ける。セキュリティと自動化の両立を目指す組織には朗報だ。 コスト管理の観点 セマンティックキャッシュによるLLMコール削減は、従量課金コストの最適化に直結する。エージェントが頻繁に類似クエリを発行するシナリオ——例えばナレッジQAボットや定型分析エージェント——では、キャッシュヒット率次第で費用を大幅に抑えられる。 筆者の見解 Microsoftのこのアップデートが示しているのは、Azureをエージェント基盤として本気で整備しようという意志だ。「最も多くのエージェントが安全に動作するプラットフォーム」という戦略上のポジショニングと完全に一致している。 特にEntra IDとの統合強化は、長期的に見て正しい方向性だと思う。AIエージェントが増えれば増えるほど、NHIの管理が業務効率のボトルネックになっていく。そこをプラットフォームレベルで解決しようとしている姿勢は評価したい。「常時アクセス権を付与しっぱなし」という状態がいかにリスクかを考えると、JIT方向への進化は避けられない必然だ。 Agentic Memory自体のアーキテクチャも理にかなっている。ベクトルDBをアプリ側で別途管理するより、Redisに一本化した方が運用は確実にシンプルになる。ただし、実際のパフォーマンスはワークロードの性質に大きく依存するため、既存構成からの移行判断は慎重に行うべきだ。今すぐ乗り換えを急ぐのではなく、新規プロジェクトで試してノウハウを積む——それが道のド真ん中の使い方だろう。 Flash最適化SKUの1.5TB対応も、中長期的に大規模エージェントシステムを視野に入れている組織には選択肢として把握しておく価値がある。コストモデルの詳細は実際に試算して判断してほしいが、方向性は正しい。 出典: この記事は Build 2026: New Azure Managed Redis Capabilities for AI-Ready Applications の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはBuild 2026において、Azure Functionsをサーバーレスなエージェント実行基盤として大幅に強化する複数のアップデートを発表した。MCPサポート、Go言語対応、M365/Teams連携コネクタ、そしてDurable Tasksが一挙に追加され、AI時代のサーバーレスアーキテクチャにおける中核的な位置付けが鮮明になった。 サーバーレスエージェントとしての再定義 これまでAzure Functionsはイベント駆動型のシンプルなサーバーレス実行環境として知られてきた。Build 2026のアップデートでMicrosoftが明確に打ち出したのは、「エージェントの実行基盤」としての新たなポジショニングだ。 AIエージェントはHTTPリクエストを受けて何かを返すだけでなく、複数のツールを呼び出し、状態を管理しながら長時間にわたってタスクを処理する。Azure Functionsはこの要求に応えるべく、以下の機能を拡充した。 主要アップデート詳細 MCPサポート（Model Context Protocol） Model Context Protocol（MCP）はAIエージェントが外部ツールやサービスと通信するためのオープンプロトコルだ。Azure FunctionsがMCPをネイティブにサポートすることで、Functionsで実装した処理をAIエージェントのツールとしてそのまま公開できるようになる。既存のビジネスロジックをAIエージェントから呼び出す際の「接続層」を標準化できる点は、エンタープライズ環境での採用を大きく後押しする。 Durable Tasks Durable Functionsで実績のあるオーケストレーション機能が、より汎用的な「Durable Tasks」として整備された。長時間実行・状態管理・再試行ロジックを持つ複雑なワークフローをサーバーレスで記述できる。エージェントが複数ステップのタスクを処理するシナリオ、たとえば「メール確認→承認待ち→後処理」のような人間を介したフローにも対応しやすくなっている。 M365/Teams連携コネクタ Microsoft 365やTeamsと直接連携できるコネクタが追加された。Teams上のメッセージやイベントをトリガーにしてFunctionsを起動したり、処理結果をTeamsチャンネルに投稿したりといったシナリオを、低コードに近い形で実装できる。業務フロー自動化の文脈では即戦力になる機能だ。 Go言語サポート Azure FunctionsのサポートはこれまでC#、JavaScript/TypeScript、Python、Javaが主力だったが、ここにGoが加わった。GoはCloud Nativeな開発者コミュニティで広く使われており、特にマイクロサービス・プラットフォームエンジニアリング領域での普及が顕著だ。既存のGoコードベースをAzure Functionsに移植するコストが下がる。 実務への影響——日本のエンジニア・IT管理者に向けて 今すぐ動けるポイントを3つ挙げる。 1. 既存のFunctionsをMCPエンドポイントとして公開する設計を検討する すでにAzure Functionsで業務APIを実装している組織は多いはずだ。MCPサポートを活用すれば、その資産をそのままAIエージェントのツールとして再利用できる。新規開発コストをかけずにエージェント統合の土台を作れる。 2. Teams連携の自動化フローをFunctionsベースで設計し直す Power Automateで組んだTeams連携フローの中に「もう少し複雑なロジックを入れたいが、Power Automateでは限界」と感じているケースは多い。そのロジックをFunctionsに委譲することで、スケーラビリティと開発の柔軟性を両立できる。 3. エージェントのオーケストレーションレイヤーとしてDurable Tasksを評価する 社内向けAIエージェントを構築する際、「エージェントに何かを長時間やらせる」仕組みのどこにDurable Tasksを置くかを設計段階から考えておくと、後の改修コストが下がる。 筆者の見解 Azure FunctionsのMCPサポートとDurable Tasksの整備は、Microsoftのエージェント戦略が「作れるだけ」から「安全に・管理しながら動かせる」フェーズに進んでいることを示している。これはMicrosoftらしい着実な一手だと思う。 AIエージェントの実行基盤として重要なのは、モデルの賢さだけではない。スケーラビリティ、コスト制御、セキュリティポリシーの適用、監査ログ——これらをプラットフォームとして提供できるかどうかが、エンタープライズ採用の分かれ目になる。その観点でAzure Functionsは良い選択肢であり続けている。 Microsoft Foundry経由でAnthropicやOpenAIのモデルをAzure上で使うアーキテクチャと、今回のFunctionsアップデートは非常に相性が良い。「Azure基盤の上でベストなAIを動かす」という構成を組む際の実行レイヤーとして、Functionsの選択肢がぐっと広がった。 Go言語対応については、地味だが評価したい。日本でもSRE・プラットフォームエンジニアリング領域でGoを使うチームは増えており、言語の選択肢が広がることで「Azureを選ばない理由」が一つ減る。 欲を言えば、Durable Tasksの可観測性まわりの充実も早期に期待したい。エージェントが複雑な処理をするほど、何がどこで詰まっているかを把握するのが難しくなる。ここの整備がエンタープライズ採用の次のハードルになるはずだ。 出典: この記事は Azure Functions at Build 2026 Update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Azure上の可用性管理機能を一元化する「Azure Infrastructure Resiliency Manager」をパブリックプレビューとして公開した。AIエージェント「Resiliency Agent」がARM・Bicep・Terraformのテンプレートを自動生成し、ゾーン冗長構成の一括設定を可能にする。 Azureの可用性管理、これまでの課題 Azureにはすでに可用性ゾーン（Availability Zones）、Azure Advisor、Chaos Studio、Azure Monitorといった強力なツールが揃っている。しかし、これらは個別に存在しており、組み合わせて使うには相当なノウハウと手間が必要だった。 「ゾーン冗長にしたいが、何から手を付ければいいかわからない」「Advisorの推奨に従ってみたが、Chaos Studioで試験したらすぐ落ちた」――そんな経験をしたエンジニアは少なくないだろう。個々の機能の品質は高くても、統合体験がなければ全体最適は生まれない。 Infrastructure Resiliency Managerとは Azure Infrastructure Resiliency Managerは、これらの個別機能を一つの管理画面に統合する新サービスだ。Azureポータルから操作でき、以下の機能が統合されている： Availability Zones：マルチゾーン構成の推奨と確認 Azure Advisor：可用性に関するベストプラクティス推奨 Azure Chaos Studio：耐障害性テスト Azure Monitor：稼働状況の継続的な可視化 中心的な機能はResiliency Agentだ。このAIエージェントがAzureポータル上でインタラクティブに動作し、現在の構成を分析した上で、ゾーン冗長化に必要なARMテンプレート・Bicepファイル・Terraformコードを自動生成する。 実務への影響 IaCで即適用できる点が大きい 自動生成されたテンプレートをそのままCI/CDパイプラインに組み込めれば、レビュー → 適用のサイクルが大幅に短縮される。特に「可用性を上げたいが、BicepやTerraformの書き方がわからない」という中堅エンジニアにとって、実践的な学習ツールとしても機能する。 日本のIT現場への示唆 日本の大規模エンタープライズでは、可用性ゾーンの活用率がまだ低い。「以前から動いているから大丈夫」という判断で、シングルゾーン構成のワークロードが多く残っているのが実態だ。 Resiliency Managerのように「現状診断 → 推奨 → テンプレート自動生成 → 適用」が一貫して提供されると、「何を直せばいいかわからない」という初動コストが解消される。ゾーン冗長化の普及を後押しする効果が期待できる。 担当者が押さえるべきポイント パブリックプレビュー中は機能の変更や廃止が起こりうる。本番環境への適用は慎重に 生成されたテンプレートは必ずレビューする。AIが生成するコードは概ね正確だが、組織固有のポリシー（タグ付け規則・命名規則等）との整合は人間が確認する必要がある Chaos Studioとの統合により、冗長構成を設定した後に障害試験まで一気通貫で実行できるのは実務上の大きなメリット 筆者の見解 個別に優れた機能を束ねるだけでは「部分最適の寄せ集め」になりがちだが、Infrastructure Resiliency Managerは設計コンセプトが明快だ。「現状を診断して、何をどう直せばいいかをAIが提示し、コードまで吐き出す」という流れは、実務者の作業手順に沿っている。 可用性ゾーンの活用はクラウド運用の基本中の基本のはずだが、日本の現場では「やった方がいいとは知っているが、手が回らない」という状況が根強い。こういったツールが整備されることで、「知識はあるが実装できていない」というギャップが埋まる可能性がある。 正面から取り組んでほしい点は、生成されるテンプレートの品質と継続的なアップデートだ。Azureが出すツールの中には初期は期待外れで、半年後に別物になったという経験を何度かしてきた。Infrastructure Resiliency Managerが「リリースして終わり」ではなく、現場フィードバックを取り込みながら育つツールになれれば、本当に価値のある存在になる。Azureにはその力がある。パブリックプレビューの今こそ、積極的にフィードバックを送ることをお勧めしたい。 出典: この記事は Announcing Azure Infrastructure Resiliency Manager Public Preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年のMicrosoft Buildにおいて、科学・工学研究開発（R&D）向けエージェントAIプラットフォーム「Microsoft Discovery」の正式提供開始（GA）を発表した。昨年のBuildで限定プレビューとして登場した同プラットフォームが、すべての組織に向けて本番利用可能な形で展開される。 Microsoft Discoveryとは何か Microsoft Discoveryは、単なるチャット型AIアシスタントではなく、研究開発の複雑なワークフロー全体を管理・自動化するための基盤プラットフォームだ。材料科学、半導体設計、ライフサイエンスといった分野のR&Dチームが、AI エージェントを組み合わせて研究サイクルを回せるよう設計されている。 プラットフォームの中核を担う「Microsoft Discovery Engine」は、科学的探求の基本サイクル——仮説立案 → 実験 → 分析 → 次のイテレーション——を支援する。研究者は個々のモデル応答を得るだけでなく、推論のプロセスをトレース可能な形で記録し、再現性のある探索を繰り返せる。 R&D特有の要件にどう応えるか 科学・工学のR&D環境では、汎用のAIツールでは補えない要件が多い。Microsoft Discoveryが対応を明示している主な要件は以下のとおりだ。 組織固有の知識・ドメイン専門知識との統合: 企業内の文献、実験データ、プロプライエタリな知識ベースをエージェントに接続できる 専門シミュレーション・解析ツールとの連携: 既存の計算ツールやシミュレーション環境をそのまま活用できるよう設計されている 証拠とトレーサビリティの保持: 研究判断の根拠となったデータ・推論パスが記録・参照可能な状態で維持される ガバナンスと監査への対応: プロプライエタリな知識の取り扱いポリシーを組織として管理できる 材料科学者が性能・安全性・コスト・製造容易性・規制制約を同時に評価する場面や、半導体チームが物理的な忠実性を保ちながら大きな設計空間を探索する場面など、単一のモデルが一問一答するだけでは到底カバーできないユースケースが想定されている。 デスクトップアプリ「Microsoft Discovery app」もプレビュー公開 GA発表と同時に、Microsoft Discovery appのプレビューも公開された。研究者や学生、科学チームがすぐに利用を始められるローカルデスクトップ体験として提供される。組織としての本格展開を始める前に、個人または小規模チームで試用できる入口として機能する位置づけだ。 実務への影響：日本のエンジニア・IT管理者はどう向き合うか Microsoft Discoveryのターゲットはいわゆる「SaaS業務効率化」ではなく、製造業・製薬・研究機関などドメイン知識が勝負になるR&D現場だ。日本においては以下のような組織が優先的に検討対象となるだろう。 製造業の研究部門: 材料・デバイス開発においてシミュレーションと実験データを組み合わせるサイクルを自動化したい企業 ライフサイエンス: 臨床文献・コホートデータ・モデルを横断的に接続して仮説検証を加速したい研究チーム 社内IT・AI推進部門: エージェントAIの導入を検討している場合、ガバナンスと再現性の要件を満たすプラットフォームを探している組織 実務的なポイントとして、既存のR&D環境を置き換えるのではなく、上位レイヤーとして重ねる設計であることは評価できる。既に使っているシミュレーションツールやデータ基盤を捨てずに済むなら、導入ハードルは相当低くなる。まずはMicrosoft Discovery appで小規模実験から始め、組織としての正式導入可否を判断する進め方が現実的だ。 なお、ガバナンス面での要件整理——特にプロプライエタリデータをどの範囲でエージェントに接続するか——は事前に詰めておくべきだ。研究データは知財そのものであり、エージェントへの接続ポリシーは法務・情報セキュリティ部門と連携して設計する必要がある。 筆者の見解 Microsoft Discoveryは、Microsoftが「エージェントの管制塔」戦略を着実に実行していることを示す、わかりやすい事例だと思う。汎用チャットではなく、特定ドメインのワークフロー全体をエージェントで覆い、ガバナンスをMicrosoft基盤で担う——この方向性はMicrosoftが最も得意とするアプローチだ。 Azure基盤やMicrosoft Entra IDを中心に据えたエンタープライズガバナンスの強みを、そのままエージェント時代に持ち込もうとしている点は理にかなっている。これはAIモデルの性能勝負ではなく、プラットフォームとしての信頼性・管理性・統合性の勝負であり、Microsoftが本来最も強い土俵だ。 R&D向けという切り口も興味深い。これまでのCopilotシリーズは「業務効率化」という文脈が中心だったが、Discovery は「科学的探求の加速」という別の次元に踏み込んでいる。材料科学や創薬といった分野に具体的な成果事例が積み上がってくれば、「AIが実際に何かを発見した」という説得力ある実績になる。そこまで行けるかどうかが、今後の注目点だ。 日本の製造業・研究機関はこの流れに乗り遅れると差が開く。今のうちに小さくはじめて知見を蓄える組織が、数年後に差をつける。 出典: この記事は Announcing Microsoft Discovery general availability and Microsoft Discovery app preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがBuild 2026（2026年6月2日）にて、エージェントAIワークロード向けに設計されたPostgreSQL互換データベース「Azure HorizonDB」のパブリックプレビューを正式に開始した。昨年12月のアナウンスから半年、開発者が実際に触れる段階にようやく到達した。 何が使えるようになったのか リリース時点で利用可能なリージョンはAustralia East、Central US、Sweden Central、West US 2、West US 3の5か所。Japan East（東日本）、Korea Central、Canada Centralなどは「coming weeks（数週間以内）」での追加が予告されており、日本のユーザーも間もなく国内リージョンから利用できる見通しだ。 プロビジョニングはAzureポータル、REST API、VS Code PostgreSQL拡張機能の3経路から可能。料金体系はvCore単位のコンピュート課金とGiB/月のストレージ課金による従量制だが、具体的な料金は現時点で非公開。本番導入を検討するチームはGA前の価格発表を待ってからROI試算に入ることを強く勧める。 DiskANN Advanced Filtering：なぜ重要なのか 2026年のAIアプリ開発でベクター検索はもはや標準機能だ。pgvectorを搭載したマネージドPostgreSQLサービスは各社が出揃っている。HorizonDBが差別化を図るのがDiskANN（Disk-based Approximate Nearest Neighbor）の先進フィルタリング実装だ。 標準的なpgvector（HNSW）によるベクター検索は2パス構成を取る。①ベクター空間で近傍候補を取得、②WHERE句でフィルタリング。問題は、実際のエージェントクエリのほとんどが「特定ユーザーが過去7日間に生成した、価格に関連する上位10件のメモリ」のように多条件フィルタを伴う点にある。後処理フィルタでは「計算してから捨てる」という無駄が生じる。 DiskANNのAdvanced Filteringはグラフ探索とフィルタ評価を1パスで同時実行する。Microsoftが公表したベンチマークでは、フィルタの選択性によってはクエリレイテンシを最大3分の1に削減できるとしている。独立機関によるベンチマークはプレビュー段階のためまだ存在しないが、アルゴリズム的な根拠は妥当であり、単なるマーケティングトークではないと評価できる。 Microsoft Foundry経由のインデータベースAI推論 HorizonDBの特徴のひとつが、Microsoft FoundryとのネイティブSQL統合だ。エンベディング生成、生成AIモデルの呼び出し、リランキングをSQL内から直接実行でき、アプリケーション側にAPIキーもHTTPクライアントも不要になる。モデル費用はFoundryの標準レートで課金される。 RAGパイプラインやエージェントメモリ基盤を構築するチームにとっては、APIプロキシ・エンベディングサービス・モデルルーティングといったインフラレイヤーを丸ごと省略できる可能性がある。ただしプレビュー段階のデータベースをこの用途でプロダクション投入するかどうかは、チームのリスク許容度と照らし合わせて慎重に判断すべきだ。 VS Code PostgreSQL拡張機能がGA HorizonDB関連の発表の中で見落とされがちだが、VS Code PostgreSQL拡張機能が50万インストールを突破しGAに到達した。GitHub Copilotとのスキーマコンテキスト統合により、スキーマを理解した補完候補とワンクリックパフォーマンスデバッグが可能になっている。 プレビューとして注目したいのがOracleマイグレーションツールだ。AIを活用してOracleスキーマをPostgreSQLへ変換し、複雑な構文は「Review Tasks」として人間のレビューに回す仕組みを採る。OracleのCPUライセンスコストに頭を抱えているエンタープライズ企業にとって、構文のsed置換ではなくスキーマを理解した自動変換ツールは現実的な選択肢になり得る。 正直な制約事項 HorizonDBはサーバーレスではない。コンピュートは手動設定が必要で、スループット需要に応じてレプリカを自分で追加・削除する運用が求められる。ストレージは自動スケールするがコンピュートはしない。Aurora Serverlessのような完全自動スケーリングに慣れたチームには運用負荷の増加となる点は正直に認識しておきたい。 実務への影響 日本のエンジニア・アーキテクト向けの実践的な観点を整理する。 Japan Eastリージョンの追加を待ってから評価開始が現実的。現時点でのサインアップはアーキテクチャの事前検討と割り切る RAGパイプラインの再設計チャンス: 既存のエンベディングサービスをHorizonDBのインデータベース推論に移行できれば、インフラ構成がシンプルになる可能性がある 料金情報が出るまで本番移行計画はペンディング: vCore単価とストレージ単価によっては、Flexible Serverと比較して割高になるケースもある Oracle脱却プロジェクトで有望な候補: VS Code拡張のマイグレーションツールは、Oracle→PostgreSQL移行の検討段階から試用する価値がある Microsoft Foundryとの組み合わせが前提設計: HorizonDBを最大活用するには、AI推論基盤としてFoundryをセットで検討する構成が自然な流れになる 筆者の見解 Azure HorizonDBが取り組んでいる問題設定は正しい。エージェントAIのワークロードは「多条件フィルタ付きベクター検索を高速に、かつAIモデル推論と密結合で」という要求を持っており、汎用PostgreSQLをそのまま使い続けることへの不満は確かに存在する。DiskANNのアーキテクチャは技術的に筋が通っており、独立ベンチマークが出揃えばより明確な評価が下せるだろう。 Microsoft Foundryとのネイティブ統合という方向性も、「Azure基盤の上で動かすAIを柔軟に選ぶ」というプラットフォーム戦略と一致している。エージェントが安全に動作するプラットフォームを提供するという競争でMicrosoftが優位にいる、という筆者の見立てに沿った動きでもある。 ただし、価格を非公開のまま「まず触ってみて」というアプローチはエンタープライズ向けには機能しづらい。 日本の大手企業では、概算コストが出ないと検証予算すら通らないケースが多い。GAまでに明確な料金体系を提示してほしいところだ。また、サーバーレス対応が見送られた点は、競合サービスと比較した際に弱点になる。コンピュートの自動スケールはGAまでのロードマップに入っているのか、Microsoftには是非明らかにしてもらいたい。 HorizonDBが目指している世界は正しい方向にある。あとはプレビューから本番グレードへの仕上げを、スピードを落とさずにやり切れるかだ。 ...

MicrosoftはBuild 2026において、MCPネイティブのAIファースト検索スタック「Web IQ」を発表した。AIエージェントが関連パッセージを競合比約2.5倍の速度で取得できると主張しており、現在は一部のAzureユーザーに限定アクセスを提供している。 Web IQとは何か Web IQは、Microsoftが「IQプラットフォーム」の一環として位置づける検索スタックだ。最大の特徴はMCP（Model Context Protocol）ネイティブで設計されている点にある。MCPはAnthropicが主導し、現在は主要AIベンダーが軒並み採用を表明しているオープン標準プロトコルで、AIエージェントが外部ツールやデータソースと標準化された手順で接続するための「共通語」として急速に普及が進んでいる。 Web IQのコアコンセプトは「エージェントが正しい情報を、適切なタイミングで取得できる」こと。単なる検索APIではなく、エージェントのワークフローに自然に組み込まれる設計を目指しており、Azure AI Foundryとの統合が前提とされている。 「2.5倍速」が意味するもの Microsoftは、Web IQが関連パッセージを返す速度が競合比で約2.5倍と主張している。エージェントAIにとって検索速度は単なる体験の問題ではなく、コストと精度に直結する。 コスト面：待機中もLLMのコンテキストウィンドウが占有される。検索が遅いほど、1回のエージェント実行にかかるトークンコストが膨らみやすい 信頼性面：複数ステップのワークフローでは、一箇所のタイムアウトが連鎖的なエラーを引き起こす。レスポンスが速いほど安定したパイプライン設計が可能になる リアルタイム性：ニュースや株価、障害情報など鮮度が命のユースケースでは、取得の遅延が「古い情報での判断」に直結する ただし、どの条件・どのベンチマークでの比較かはまだ公式に詳細が明かされていない。この点は後述する。 IQプラットフォームとしての戦略的意味 Web IQは単独製品ではなく、Microsoftが構想する「IQプラットフォーム」の構成要素のひとつとされている。エージェントが行動するために必要な「知識・情報・推論」をまとめて提供するインフラとして設計されており、Copilot Studio や Azure AI Foundry 上のエージェント開発に統合されていく見通しだ。 MCP準拠のため、Azure以外の環境で動くエージェントからも呼び出しやすい設計になっている点は見逃せない。特定環境に閉じず、MCPエコシステム全体に開かれた形にすることで、より多くのエージェントをAzureのインフラ上に引き込む狙いが透けて見える。 実務での活用ポイント 1. RAGパイプラインの刷新機会 現在、多くの日本企業がAzure AI SearchベースのRAG構成を採用している。Web IQがリアルタイムのウェブ情報と社内ドキュメントを統合的に扱えるなら、既存のRAGアーキテクチャを拡張する選択肢として検討に値する。 2. MCPエコシステムへの先行適応 MCPネイティブという設計は、今後のエージェントAI開発の主流に合致している。Web IQを評価する過程でMCPの実装パターンを習得しておくことは、将来的な他ツールへの応用にも生きてくる。 3. 限定アクセス期間の活用 現在は限定公開段階。Azure Enterprise Agreement契約があるなら、プレビューアクセスを積極的に申請し、早期に実環境での性能を確認しておく価値がある。限定期間中のフィードバックがGA後の機能に反映されることも多い。 筆者の見解 Web IQが示す方向性は正しいと思う。エージェントAIが実務で本当に役立つものになるためには、「推論エンジン」だけでなく「情報取得インフラ」の整備が不可欠だ。Microsoftがその検索レイヤーをエージェントファーストで再設計しようとしている点は素直に評価できる。 MCPネイティブという設計選択も賢明だ。プロプライエタリな独自プロトコルで囲い込むのではなく、業界標準に乗ることで、Azure AI Foundryを中心に多様なエージェントを引き込める。「最も多くのエージェントが安全に動作するプラットフォームを提供する競争」という観点では、Microsoftは他社より有利な立場にある。Web IQはその戦略と綺麗に整合している。 ただ一点、2.5倍という速度主張については透明性を示してほしいところだ。エージェントAI向け検索の性能比較は測定条件によって大きく変わる指標だけに、独立した検証に耐えられる評価手法を公開することが信頼につながる。実力は十分あるはずなのだから、数字の根拠をちゃんと見せてほしい。 限定アクセスが一般提供へ移行したとき、Web IQは多くの日本企業にとって「初めて本格的に触るMCPネイティブツール」になる可能性が高い。そのタイミングを見逃さないよう、今のうちにMCPの概念とAzure AI Foundryの統合パターンを把握しておくことをお勧めする。 出典: この記事は Web IQ: Microsoft’s MCP-native AI-first Web Search Stack の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Build 2026において、Azure Kubernetes Fleet ManagerのArc対応クラスタ向け機能がGA（一般提供開始）に到達し、Azureの境界を超えてオンプレミスや他クラウドのKubernetesクラスタをフリートとして統合管理できる体制が整った。 Kubernetesクラスタの「バラバラ問題」をついに解決 企業がKubernetesを本番導入すると、多くの場合は複数のクラスタが乱立する状態になる。Azure上のAKSクラスタ、オンプレミスの自社データセンター、他クラウドの環境——それぞれが個別管理されていると、ポリシーの一貫性確保やワークロードの配置最適化が極めて困難になる。 Azure Kubernetes Fleet Managerは、この「クラスタ群を束ねるレイヤー」として設計されたサービスだ。今回GAに到達した機能により、Azure Arc経由で接続されたクラスタ（オンプレミスや他クラウド上のKubernetesクラスタ）もフリートのメンバーとしてファーストクラスに扱われるようになった。 今回のGAで何ができるようになったか フリートレベルのポリシー一元適用 従来はAzureのAKSクラスタのみが対象だったポリシー管理が、Arc接続クラスタにも拡張された。Azureポータルから設定したポリシー（特定コンテナレジストリの強制利用、privilegedコンテナの禁止など）をフリート全体に一斉適用できる。 マルチクラスタへのワークロード配置 どのクラスタにワークロードを配置するかの判断をFleet Managerが担う。リソース使用率・地理的な配置要件・クラスタのヘルス状態をもとに、オンプレを含む全クラスタを横断してワークロードをスケジューリング可能になった。 統合されたメンバーシップ管理 Arc接続クラスタがAKSクラスタと同じ管理面から監視・操作できる。接続状態・リソース・メトリクスをAzureポータルで一元確認できるため、運用担当者の認知負荷が大幅に下がる。 実務への影響 ハイブリッド環境を持つ日本企業へのインパクト 日本の大手企業や金融機関では、コンプライアンス要件やレガシーシステムとの統合の観点から「オンプレミスとAzureのハイブリッド」構成を採用するケースが多い。これまでこの構成では、Azure側とオンプレ側で別々のKubernetes管理ツールを維持する必要があった。 Fleet ManagerのGA到達により、単一の管理面から全クラスタを見渡せるようになる。運用担当者がAzureポータルを開けば、オンプレのクラスタも含めてポリシー適用状況・ワークロード配置・アラートを確認できる。 具体的な活用シナリオ 段階的なクラウド移行: オンプレの既存ワークロードをFleetに加入させながら、段階的にAKSへ移行するブループリントが描きやすくなる DR（災害対策）の強化: プライマリをAzure AKSに、DRサイトをオンプレKubernetesに置くハイブリッドDR構成をFleet Managerで一元管理できる マルチリージョンの統治: データ所在地が規制で制約されるケースで、各地域のクラスタをまたいだ一貫したポリシー適用が実現できる 筆者の見解 AzureのプラットフォームとしてのKubernetes戦略は一貫していると思う。AKS単体の改善にとどまらず、Arc経由でオンプレや他クラウドも巻き込む「管制塔」としての役割を着実に強化している。この方向性は正しいし、長期的に価値が出る投資だ。 エージェントが多様な環境で動作する時代になると、「どこで何が動いているか」を統一的に把握・制御する仕組みの重要性は一層増す。単純なコンテナオーケストレーションを超えたFleet Managerのポジショニングは、その観点からも意義が大きい。 ただし、Arc接続クラスタの環境整備（Arcエージェントの導入・維持管理・ネットワーク要件）には相応の運用コストがかかる。「接続すれば後は楽になる」という話ではなく、最初の構成設計と運用プロセスの整備に投資が必要な点は正直に伝えておきたい。ハイブリッドKubernetes管理は「やれば便利」だが「やるには準備が要る」——そのリアルを踏まえた導入計画を立ててほしい。 出典: この記事は What’s new in Azure Kubernetes Service at Microsoft Build 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Microsoft Build 2026 で Azure Logic Apps の新 SKU「Azure Logic Apps Automation」を発表した。AIエージェント・ナレッジサービス・モデルアクセスがあらかじめ組み込まれたマネージド環境を提供し、これまでよりはるかに少ない設定工数でエンタープライズグレードの自動化ワークフローを構築できるようになる。 何が変わるのか——新 SKU「Logic Apps Automation」の概要 従来の Azure Logic Apps は「Consumption（従量課金）」と「Standard」の2つの SKU を中心に提供されてきた。今回発表された Logic Apps Automation はその上位かつ特化型の選択肢として追加される形で、以下が初期状態から利用可能になる。 AIエージェント機能の組み込み: Azure AI Foundry と深く統合されており、別途エージェントランタイムを用意する必要がない ナレッジサービス（Knowledge Services）: ドキュメントやデータソースをナレッジベースとして接続し、RAG（検索拡張生成）パターンを標準のワークフローアクションとして扱える モデルアクセスの一元管理: OpenAI モデルや Azure AI 上の各種モデルへのアクセスが SKU レベルで組み込まれており、接続設定を手で組む手間が省ける マネージド環境: インフラ管理はマイクロソフト側が担う。コンテナの構成やスケーリング設定を自前で管理するコストが大幅に下がる これまで「AIエージェントを組み込んだ自動化ワークフロー」を構築しようとすると、Azure AI Foundry・Azure OpenAI・Logic Apps・Azure API Management などを個別に構成してつなぎ合わせる必要があった。Logic Apps Automation はそのグルーコードの大部分をプラットフォームに吸収する設計だ。 技術的なポイント：エージェントオーケストレーションとの関係 注目すべきは、ワークフローエンジンである Logic Apps が AIエージェントの オーケストレーション層 としての役割を明確に担うようになる点だ。 従来の RPA 的なシナリオ（ファイルが届いたらメールを送る、承認フローを回す）に加え、「判断を伴う自動化」 ——ナレッジベースを参照して回答を生成し、結果によって後続の処理を分岐させる——をノーコード/ローコードの範囲で記述できるようになる。 ...

MicrosoftがAzure API Management（APIM）のA2A（Agent-to-Agent）API管理機能をプレビュー公開した。AIエージェント同士が互いのAPIを呼び合うマルチエージェント構成において、既存のポリシーエンジン・Microsoft Entra ID・Application Insightsによるオブザーバビリティをそのまま適用できる。 A2A（Agent-to-Agent）通信とはなにか 従来のAPIは「人間のアプリケーションがバックエンドサービスを呼ぶ」構造を前提としていた。生成AI時代に入ってからは、AIエージェント自身が別のAIエージェントのAPIを呼び出す「A2A通信」が当たり前になりつつある。 オーケストレーター役のエージェントが「検索専門エージェント」「要約専門エージェント」「コード生成専門エージェント」をそれぞれAPIとして呼び出すマルチエージェント構成は、すでに多くのプロダクションシステムで見られる形だ。 問題は、こうしたエージェント間通信が「API管理の対象外」になりがちだったことにある。セキュリティポリシーが適用されない、誰がどのエージェントを呼んだか追跡できない、コストが見えない——この三重苦が現場で静かに積み重なっていた。 APIMがA2A通信を管理できるようになった 今回のプレビューにより、Azure API ManagementはA2A通信を「通常のAPIと同じ扱い」で管理できるようになる。 主な機能は以下のとおりだ： 既存のポリシーエンジンをそのまま適用: レート制限・IP制限・JWT検証・キャッシュなど、APIMに積み上げてきたポリシー資産がA2A通信にも適用される Microsoft Entra IDによるID管理: エージェント同士の認証もEntra IDで一元管理できる。Managed IdentityやService Principalを活用したNHI（Non-Human Identity）管理と自然に組み合わせられる OpenTelemetry GenAI意味規則に対応したトレース: エージェント実行のトレースをOpenTelemetry形式でApplication Insightsへ記録し、API呼び出しとエージェント実行を相関分析できる OpenTelemetry GenAI意味規則の重要性 OpenTelemetry（OTel）は分散トレーシングの業界標準だが、そのGenAI向け拡張として「GenAI意味規則（Semantic Conventions）」が整備されつつある。モデル名・プロンプトトークン数・コンプリーショントークン数・エラー種別などをOpenTelemetryのスパン属性として記録する標準仕様だ。 APIMがこの規則に対応したことで、Application Insightsダッシュボード上でエージェントの動きを可視化できるようになる。「あのAPIが遅い」と思ったら実はその裏で呼ばれているエージェントがボトルネックだった、という調査が格段にやりやすくなる。 実務への影響 マルチエージェント構成の本番運用がようやく現実的に これまで「エージェントを本番に出す」には不安要素が多かった。特に「エージェント間でどんな通信が起きているか追えない」「コストが読めない」「認証をどう設計するか」の3点が障壁だった。 APIMのA2A管理機能はこの3点を一度に解決する。APIMをエージェント間通信の管制塔として置くことで、既存のAPI管理基盤がそのままマルチエージェント時代にも使える。 NHI管理との組み合わせが鍵 エージェントをNHIとして適切に管理する仕組みと組み合わせることで、Just-In-Timeアクセス制御や最小権限原則をAI時代にも維持できる。「このエージェントは何のAPIにアクセスしてよいか」を人間が設計し、APIMのポリシーとEntra IDで強制する——これが本来あるべき姿だ。 常時アクセス権を与えるのではなく、必要なときだけ必要な権限を付与するゼロトラスト原則は、エージェントが増えれば増えるほど重要になる。 コスト管理も忘れずに Application InsightsへのOTelトレースはトークン使用量も記録できる。エージェントがエージェントを呼ぶチェーンが深くなると、トークンコストが静かに積み上がる。最新のAPIM v2 tierではAnthropicのMessages APIへのllm-emit-token-metric対応も追加されており、Claude系モデルを裏で使う構成でもコスト可視化が可能になっている。 筆者の見解 エージェントが人間の代わりにAPIを呼ぶ世界は、もう「近未来の話」ではない。APIMをAIゲートウェイとして実際に運用する中で感じてきた「エージェント間通信は野良になりがち」という課題に、MicrosoftがAPIMという既存資産で正面から答えを出してきたことは評価したい。 特にEntra IDをエージェントの認証・認可基盤として使えることの意義は大きい。これは「エージェントの管制塔としてのMicrosoft Entra ID」という長期戦略の一環として見ると筋が通っている。AIモデルの性能を競う土俵とは別に、「エージェントが安全に動作するプラットフォーム」を提供する競争ではMicrosoftのインフラ・ID管理・セキュリティの強みが生きる。この路線を正面から磨き続けてほしい——それがMicrosoftの戦い方として正しいと思っている。 ひとつ注意点を挙げるとすれば、プレビュー段階でプロダクションへの適用を検討する場合、OTelトレースのサンプリング設定とApplication Insightsへのデータ送信コストを慎重に設計すること。全トレースを垂れ流すとInsightsのコストが想定外に膨らむ。本番導入前にサンプリング率とカスタムダッシュボードの設計をセットで行うことを強くお勧めする。 出典: この記事は Preview: Govern, Secure, and Observe A2A APIs with Azure API Management の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがAzure API Centerに、AIエージェントの登録・評価機能とGitベースの同期機能を追加した。Azure API ManagementでデプロイしたA2Aエージェントが数分以内にAPI Centerへ自動登録され、API・MCPサーバーとともに統合カタログで一元管理できるようになった。 Azure API Centerに追加された3つの機能 1. エージェント登録（Agent Registration） Azure API Management（APIM）上で公開したAgent-to-Agent（A2A）プロトコル対応エージェントが、数分以内に自動的にAzure API Centerのカタログへ同期される。これまでAPIを手動で登録・管理していた運用を、AIエージェントにも同じフローで適用できるようになった。 APIだけでなく、MCP（Model Context Protocol）サーバーやエージェントを同一カタログで横断検索・管理できる点が大きな変化だ。「このタスクにはどのエージェントを使えばいいか」をカタログから探すワークフローが標準化される。 2. エージェント評価（Agent Assessment） カタログに登録されたエージェントに対して評価・スコアリングを行う機能が追加された。複数のエージェントを比較し、コンプライアンス・セキュリティポリシー・品質基準に対する適合度を把握できる。エージェントが乱立しがちな環境で「どれを信頼して使うか」の判断基準を組織として持てるようになる。 3. Gitベース同期（Git-based Synchronization） Gitリポジトリに格納されたAPI定義ファイル（OpenAPI仕様等）を、Azure API Centerに自動同期できる機能だ。コードと同じリポジトリでAPI仕様を管理し、プッシュのたびにカタログへ自動反映されるため、「ドキュメントと実装の乖離」という慢性的な問題に対処できる。CI/CDパイプラインに組み込むことで、API仕様のドリフト防止が自動化される。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エージェント管理が「属人的な把握」から「カタログベースのガバナンス」へ 現在多くの企業でAIエージェントの試験導入が進んでいるが、「どこにどんなエージェントが動いているか」の把握が担当者の頭の中に留まっている状態が多い。API Centerのエージェント登録機能は、この状態を組織的なカタログ管理に昇格させる。特に複数部門が並行してエージェントを開発・運用し始めた段階で、統制の基盤として機能する。 A2A＋MCP＋REST APIを同一ツールで管理できる実用的な価値 AIエージェント開発では、従来型のREST APIだけでなく、MCPサーバーやA2Aプロトコルなど複数のインターフェース規格が混在するケースが増えている。それぞれを別々のツールで管理するのではなく、Azure API Centerが統合ハブとなる設計は、運用コストの観点から合理的な選択肢だ。 Gitベース同期の即効性 既存のAPI開発でOpenAPI仕様をGitで管理しているチームにとって、Gitベース同期は追加コスト最小で導入できる。まずここから試すのが現実的なファーストステップといえる。 筆者の見解 Azure API Centerのこのアップデートが興味深いのは、「エージェントをAPIと同列の一級市民として扱う」という設計思想が明確になった点だ。 筆者はかねてより、「エージェントの管制塔としてのMicrosoft Entra IDとAzure基盤は長期的に正しい戦略だ」と考えてきた。今回のAPI Centerの拡張は、その基盤にエージェント管理レイヤーが積み上がった格好であり、方向性として評価できる。 Non-Human Identity（NHI）——つまりサービスプリンシパル、マネージドID、そしてAIエージェントを含む人間以外のIDの管理——は、自動化推進における最大のボトルネックのひとつだ。エージェントをカタログで可視化し評価できるようになることは、NHI管理の成熟度を上げる直接的な手段になる。 一方で、評価機能が実際にどこまで「使える判断基準」を提供できるかは、今後の充実度次第だ。評価項目が形式的なチェックリストに留まるのか、それとも実際の動作品質やセキュリティリスクを実態として把握できるレベルに達するのか——ここが肝心な部分になる。Microsoftにはその力があるのだから、表面的な機能追加に終わらせずに深化させてほしいと思う。 Azureを基盤として使いながら、その上で動かすAIやエージェントの選択肢を広げていく構成は今後も合理的だ。API Centerがその統合ポイントとして機能するなら、プラットフォームとしての価値はさらに高まる。 出典: この記事は Azure API Center now supports agent registration, agent assessment, and Git-based synchronization の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure API Management（APIM）が、Microsoft Build 2026においてJSON-RPCベースのエージェント間通信（Agent-to-Agent、A2A）APIのGA（一般提供）を発表した。REST/GraphQL/MCPと同一の管理プレーンでエージェント通信を一元管理できるようになり、マルチエージェント基盤の本格運用が現実的な選択肢になった。 A2A APIのGA ── エージェント同士が「公式の道」で通信できる時代へ これまでのAPI管理プラットフォームは、主にHTTPベースのREST/GraphQL APIを対象に設計されていた。しかし生成AIの普及により、複数のAIエージェントが互いに通信し合う「マルチエージェント構成」が現実のシステムに登場しはじめている。 今回APIMがGAとして提供するのが、JSON-RPCベースのA2A（Agent-to-Agent）APIのサポートだ。エージェント同士が構造化されたメッセージを交換するための仕組みであり、APIMの文脈でこれが重要なのは、A2A通信を既存のREST・GraphQL・MCPツールと同一の管理プレーンで扱えるという点にある。 認証・認可・レート制限・ログ収集・ポリシー適用といったAPIゲートウェイ機能が、エージェント通信に対してもそのまま機能する。「人間が呼び出すAPI」と「エージェントが呼び出すAPI」を同じ基盤で管理できることは、ガバナンスの観点から非常に重要だ。 統合モデルAPIでOpenAI・Anthropicをシームレスに切り替え 注目点のもう一つが、統合モデルAPI（Unified Model API）のマルチプロバイダー対応強化だ。OpenAI・Anthropicをはじめ複数のAIプロバイダーへのリクエストを変換・ルーティングできる機能が拡充され、バックエンドのモデルプロバイダーを変更してもアプリケーション側のコードを変えずに済む構成が可能になる。 たとえば「通常はAzure OpenAI、コスト超過時にはフォールバック先のモデルへ」といった柔軟なルーティングが、管理プレーンの設定変更だけで実現できる。特定ベンダーへの依存度を意図的にコントロールしたい組織にとって、実用的なアーキテクチャの選択肢が増えた。 MCPとの統合 ── ツール呼び出しも同一基盤で Build 2026ではMCP（Model Context Protocol）ツールのサポートも引き続き強化されている。MCPはAIエージェントが外部ツールや機能を呼び出すためのプロトコルであり、APIMがMCPエンドポイントのゲートウェイとして機能することで、ツール呼び出しにも認証・監査ログが適用できる。 REST・A2A・MCPを同一プレーンで管理できる構成は、「誰が何にどう繋がっているか」を俯瞰するうえで不可欠なインフラとなる。 実務への影響 日本のエンジニア・IT管理者が今すぐ検討すべきポイントは3つある。 1. AIゲートウェイとしてのAPIM導入・見直し 複数のAIサービスを使い分けている場合、APIMを統一ゲートウェイに置くことで、コスト可視化・レート制限・フォールバック制御が一元化できる。部署ごとにAPIキーを直接持たせているような構成は、今すぐ見直しを検討したい。 2. A2Aポリシーの事前設計 エージェント基盤を構築中・構築予定のチームは、A2A通信にどんなポリシーを適用するか（認証方式・ログ保持期間・レート制限）を今の段階から設計しておくべきだ。後付けのガバナンスは常にコストが高い。 3. Non-Human Identity（NHI）との組み合わせ エージェントが他のエージェントを呼び出す構成では、エージェント自体のIDをどう管理するかが問題になる。Microsoft Entra IDのマネージドIDやワークロードIDと組み合わせた設計を前提にしておくと、後の運用が格段に楽になる。 筆者の見解 実はこの記事を書きながら、つい先日自分自身がAPIMをAIゲートウェイとして本番運用するなかで踏み抜いたいくつかの落とし穴を思い出していた。ユーザーごとのトークン使用量の集計、プロンプトキャッシュのカウントミス、バッファレスポンス設定の罠……。APIMはよくできたプラットフォームだが、AIワークロードとの組み合わせではまだ「使いこなしのノウハウ」が必要な部分が残っている。 今回のBuild発表でA2A APIがGAになったことは、そうした泥臭い実装の土台がようやく固まってきた証拠だと受け止めている。「エージェントが呼び出すAPIも、人間が呼び出すAPIも、同じゲートウェイで管理する」というシンプルな原則が標準仕様として実装されたことの意義は大きい。 APIMの強みは、AIプロバイダーを選ばない点にある。統合モデルAPIがOpenAIやAnthropicを含む複数プロバイダーに対応したことで、Azure基盤を軸にしながらも、その上で動かすAIを状況に応じて柔軟に選ぶ運用が現実的になった。Microsoft基盤のユーザーが外部LLMを組み合わせたい場合の選択肢として、APIMはますます中心的な役割を担っていくだろう。 エージェントアーキテクチャはまだ発展途上だが、「ガバナンスを後回しにしない」ことだけは早めに決断してほしい。A2A通信が見えないところで走り出してから監査要件が出てくるのは、誰も幸せにならないパターンだ。 出典: この記事は What’s new in Azure API Management at Microsoft Build 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月開催のMicrosoft Build 2026において、Azure Database for PostgreSQLに対して接続管理・クエリ分析・セキュリティ監査にまたがる複数の新機能を発表した。今回の強化はいずれも「本番環境でPostgreSQLを安心して使い続けるために何が必要か」という問いへの直接回答であり、エンタープライズ採用を加速させる内容となっている。 PgBouncer統合で接続管理の負担を解消 今回の目玉のひとつが、PgBouncerによるサーバーサイド接続プーリングのマネージド提供だ。 PostgreSQLはその設計上、クライアント接続ごとにバックエンドプロセスをフォークする。スループット重視のWebアプリや、Lambda・Azure Functionsのようなサーバーレス関数から大量の短命な接続が押し寄せると、コネクション枯渇やメモリ逼迫が起きやすい。これを回避するためにアプリ側でプーリングライブラリを組み込んだり、別途PgBouncerをVMに立てて管理したりと、運用コストが積み上がっていた。 Azure Database for PostgreSQLにPgBouncerが統合されることで、接続プーリングの設定・監視・フェイルオーバーをマネージドサービスとして任せられるようになる。アプリ側のコード変更は最小限に抑えつつ、接続数のピーク対策が完結する点が大きい。 pg_stat_statementsでスロークエリを即座に特定 パフォーマンスチューニングの定番拡張であるpg_stat_statementsが、Azureポータルやモニタリング機能と統合される形で提供される。 これまでも手動でインストール・有効化することは可能だったが、今回はクラウドネイティブな形でダッシュボードから参照できるようになる。実行回数・平均実行時間・総CPU時間などが可視化されることで、「なんとなく重い」ではなく「どのクエリが犯人か」をデータドリブンで特定できる。 開発フェーズでは見逃されがちなN+1問題や全表スキャンも、本番データが増えた段階でじわじわ顕在化する。クエリ分析の入り口が運用コンソール内に統合されることは、DBAを専任で抱えていない中規模の開発チームにとって特に恩恵が大きい。 セキュリティ強化：プライベートエンドポイント必須化とより詳細な監査ログ セキュリティ面では2つの強化が光る。 ひとつはプライベートエンドポイント必須化オプションだ。データベースへのアクセスをVNet内のプライベートIPに限定し、パブリックインターネット経由の接続を設定レベルで強制的にブロックできるようになる。「誰かが間違えてパブリックアクセスを許可してしまった」というヒューマンエラーをポリシーで封じる仕組みで、コンプライアンス要件の厳しい金融・医療・官公庁系のワークロードで重宝する。 もうひとつは監査ログの強化だ。誰が・いつ・どのクエリを実行したかをより詳細に記録・出力できるようになる。GDPR・SOC2・ISO 27001といった国際的なコンプライアンスフレームワークへの対応や、インシデント発生時のフォレンジック調査において監査ログの粒度は直接影響してくる。 実務への影響 今回の発表を日本のITエンジニア・IT管理者の視点で整理すると、以下の点が明日から使えるアクションポイントになる。 サーバーレス・マイクロサービス構成を採用しているチームは、まずPgBouncerの接続プーリング設定を確認したい。Azure Functionsやコンテナから大量の短命接続が発生しているケースでは、PgBouncerを通すだけでレスポンスの安定性が改善するケースがある。 パフォーマンス問題を抱えているチームは、pg_stat_statementsを有効にして2〜4週間ほど本番データを収集してみると良い。「重いアプリ」と思っていたものが「1本の悪いクエリ」に起因していた、という発見は珍しくない。 セキュリティポリシーの見直しを進めている組織は、プライベートエンドポイント必須化をポリシーとして設定し、既存の接続設定の棚卸しを行うタイミングとして活用できる。「今動いているから大丈夫」は通用しない。ネットワーク層での制御とアクセスログの充実は、後回しにするほどリスクが積み上がる。 筆者の見解 AzureがPostgreSQLのマネージドサービスとして着実に機能を積み上げていることは、素直に評価したい。特にPgBouncerの統合は「本番で使おうとすると必ず直面する課題」への解答であり、地に足のついた改善だ。 プライベートエンドポイント必須化については、個人的にはもっと早く来てほしかった機能でもある。ネットワーク境界での制御はゼロトラストの補助であって中心ではないが、それでもDBサーバーへのパブリックアクセスが設定ミスで開いてしまうリスクはまだまだ現場に潜んでいる。オプションとして提供するだけでなく、新規クラスタではデフォルトでONにするくらいの思い切りがあってもいいと思う。 監査ログ強化についても同様で、「ログが取れていない」は有事の際に致命的になる。コンプライアンス対応としてのログ整備が後手に回っている組織は、このタイミングで設定を見直す契機にしてほしい。 Azureのデータプラットフォームとしての成熟度は着実に上がっている。AIワークロードが注目を集める中でも、こうした堅実なデータ基盤の強化こそが長期的な信頼につながる。派手さはないが、本番で安心して使えるプラットフォームであり続けることの価値を、MicrosoftはPostgreSQLを通じてしっかり体現しようとしている。 出典: この記事は Announcing new security, maintenance and analytics features for PostgreSQL at Microsoft Build 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。