Azure

AIエージェントが「添付ファイルを読んで理解する」能力を得た。2026年4月29日、Microsoftは Microsoft Agent Framework v1.2.2 をリリースし、ファイル添付の自動解析機能とDurable Workflowの大幅強化を届けた。エンタープライズ現場でのエージェント活用が本格化する中、このリリースは実運用に直結する内容を多く含んでいる。 Azure AI Content Understanding：マルチモーダル解析の民主化 最大の目玉は、新アルファパッケージ agent-framework-azure-contentunderstanding だ。 これは Azure AI Content Understanding との統合を提供するコンテキストプロバイダーで、エージェントに渡されたファイル添付を自動解析し、構造化された結果をLLMのコンテキストに注入する。対応フォーマットは幅広く、ドキュメント・画像・音声・動画をカバーする。 実装面での特徴も実用的だ： マルチドキュメントセッション管理：複数ファイルにわたる解析状態を保持し、「先ほどの3つのファイルを比較して」といった会話が成立する AnalysisSection によるフィルタリング：必要な解析結果だけを取り込む粒度制御 自動登録ツール：list_documents / get_analyzed_document がフレームワーク側で自動登録される これまでは「ファイルをエージェントに渡す → エージェントが読む」という処理をアプリ側でゼロから実装する必要があったが、このパッケージによって コンテキスト注入の重労働がフレームワーク側に吸収される。開発チームが本来の業務ロジックに集中できる。 Durable Workflow：会話履歴が途切れなくなった agent-framework-foundry-hosting では、ホスト型 Durable Workflow への完全な会話履歴伝播が追加された。 具体的には Workflow.as_agent() のエンドツーエンド配線が実現し、マルチターンの WorkflowAgent 呼び出しで 共有状態が呼び出しをまたいで保持される ようになった。list[Message] 入力をDeclarativeなstart executorで受け付け、Enum 値のPowerFxシンボルシリアライズも修正されている。 エンタープライズ用途では、長時間にわたるプロセスを複数ステップに分割して実行するシナリオが多い。ワークフローの途中でコンテキストが失われるのは致命的で、これまではアプリ側での状態管理が必要だった。今回の強化により、その煩雑さが大幅に軽減される。 見逃せない破壊的変更 v1.2.2 には 破壊的変更（BREAKING CHANGE） が1件含まれている。 agent-framework-orchestrations において、オーケストレーションの終端出力が AgentResponse に標準化された。Workflow.as_agent() は最終回答のみを返すようになり、逐次承認フロー（with_request_info）と並行実行フロー（intermediate_outputs=True）が同一の出力コントラクトに揃えられた。 既存コードでオーケストレーション出力を直接パースしている実装は修正が必要になる。アップグレード前に必ず python-1.2.1...python-1.2.2 の差分を確認してほしい。 その他の修正 OpenTelemetry ストリーミング可観測性の修正：ストリーミング使用時にスパンが正しくネストされない問題を解消（#5552） file_search 引用の修正：アシスタントメッセージ履歴のラウンドトリップを壊していた問題を解消。Responses APIが input_file を拒否する現象がなくなる（#5557） 実務への影響 AIエージェント開発者・アーキテクト向け ...

Microsoft Foundryが静かに、しかし確実に「エンタープライズAIの司令塔」としての形を整えつつある。今回のアップデートでは、企業内知識の検索・活用を自動化するFoundry IQと、複数プラットフォームにまたがるAIエージェントを統合管理するFoundry Control Planeの2つがプレビューとして追加された。「AIを導入したいが管理が追いつかない」という多くの日本企業の悩みに直接応える内容だ。 Foundry IQ — RAGパイプラインを「組むのではなく、生やす」 RAG（Retrieval-Augmented Generation）は、生成AIに企業独自の知識を組み合わせる手法として広く普及しているが、実装は一筋縄ではいかない。SharePoint上のドキュメント、Microsoft Fabricのデータウェアハウス、社外Webサイト——これらを横断して「正しい情報を正しいタイミングで取り出す」パイプラインを作るには、相当の工数が必要だった。 Foundry IQはこの課題を正面から解決しようとしている。Managed Knowledge Systemという統合知識基盤を提供することで、データソースごとに個別のインジェスト・インデックス・検索ロジックを組む作業を大幅に自動化する。SharePoint・Microsoft Fabric・Webを接続ソースとして統一的に扱えるため、「社内文書からも答え、Webの最新情報も参照できる」エージェントが現実的な工数で実現できるようになる。 Foundry Control Plane — エージェントの「行動を見る・制御する」インフラ AIエージェントの本格展開が近づくにつれ、「どのエージェントが何をしているか把握できない」という管理上の不安が現場で高まっている。Foundry Control Planeはその解に挑む機能で、Azure上だけでなく複数のプラットフォームにまたがるエージェントを一元的にガバナンスできる仕組みを提供する。 エージェントの展開・停止・ポリシー適用・ログ収集といった運用面を集約することで、セキュリティチームやIT管理者が「AIがやっていること」を可視化・制御できるようになる。Microsoft Entra IDとの統合によってエージェントに対するアイデンティティ管理——誰が・何のエージェントを・どの権限で動かすか——が整理されれば、企業導入のハードルは一気に下がるだろう。 実務への影響 エンジニア・アーキテクト向け RAGパイプラインの構築コストが下がることで、「AIエージェントのPoCを数ヶ月で仕上げる」という目標が現実味を帯びる SharePointとFabricを両方使っている環境（大企業に多い）では、Foundry IQによる統合知識基盤の恩恵が特に大きい Foundry Control Planeは「エージェントの増殖に管理が追いつかない」問題への答え。社内展開を始める前に仕組みを先に入れる選択肢として、今から評価しておく価値がある IT管理者・セキュリティ担当向け エージェントが増えるほど非人間アイデンティティ（Non-Human Identity, NHI）の管理が必要になる。Control PlaneがEntra IDと連携する形であれば、既存のIAMポリシーをエージェントにも拡張できる可能性がある 「エージェントが何をしたか」を後から追えない構成は監査対応でも問題になる。ログと可視性の確保を最優先で考えること 筆者の見解 Foundry IQとFoundry Control Planeが示す方向性は、筆者が考える「正しいAI基盤戦略」と重なる部分が多い。 エンタープライズのAI活用における最大の課題のひとつは、知識の分散だ。「SharePointにもFabricにもWebにも情報があるが、どれを参照すべきかエージェントが判断できない」という状況は多くの組織で起きている。Foundry IQのManaged Knowledge Systemがその統合を本当に使いやすいレベルで実現できるなら、エンタープライズRAGの「工数の壁」を乗り越える転換点になりうる。 Foundry Control Planeについては、むしろ「これが早くGA（一般提供）になってほしい」という思いが強い。エージェントの展開は、管理の仕組みが整う前に走りすぎると後から痛い目を見る。Control Planeが複数プラットフォームをカバーするという設計思想も現実的だ。「Azure上だけのAIで完結する」という前提はもう通用しない。マルチプラットフォームを見据えているのは正しい。 Microsoftが「最も多くのエージェントが安全に動作するプラットフォーム」を目指すという方向性は、AIモデルそのものの優劣とは別軸の勝負だ。今回のアップデートはその道筋に確かに乗っている。プレビュー段階でどこまで実用になるか——実際に手を動かして確かめたいと思っている。 出典: この記事は Microsoft Foundry Upgrades: Foundry IQ and Foundry Control Plane Previews の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftのセキュリティプラットフォームが、2026年5月のアップデートで大きく動いた。Sentinel、Defender、Purview、Copilot for Securityの各製品で機能強化が一斉に展開され、共通テーマは「AIを前提としたセキュリティ運用の自動化」だ。セキュリティチームの人手不足が深刻な日本のIT現場にとって、見逃せない動きが続いている。 Microsoft Sentinel：操作性と拡張性の両立 今回のアップデートで特に注目したいのが、Sentinel Training Lab の登場だ。数分でハンズオン環境を構築できるこの機能は、SOCチームのオンボーディングを劇的に短縮する可能性がある。本番環境を汚さずに訓練できる場は、人材育成に悩む組織にとって実用価値が高い。 さらに、Sentinel MCP Server により、外部の大規模言語モデルとの自然言語連携が可能になった。「この不審なログは何を示しているか」「このインシデントへの推奨対応は？」といった問いを自然言語で投げかけ、AIが調査・回答してくれる仕組みだ。SOCアナリストのスキルギャップを埋める手段として、現実的な選択肢になってきた。特定のAIモデルを柔軟に組み合わせられるアーキテクチャは、Microsoftが「プラットフォームの価値をAIモデルの優劣から切り離す」方向に舵を切った証左でもある。 Data Wrangler の統合は地味だが重要だ。Sentinelのデータレイクに対するノートブック開発を効率化するこの機能により、データサイエンスの深い専門知識がなくても高度なログ分析・可視化が実施できる環境が整いつつある。 Security Copilot：「エージェント型」への本格移行 「アラートを見て人間が判断する」時代は終わりに近づいている。今回のアップデートでは、Security Copilotのエージェント化が明確に打ち出された。 フィッシングメールのトリアージ自動化は分かりやすい例だ。着信したメールを自動分類し、真の脅威を特定し、対応アクションを提案する——このフローをエージェントが自律的に実行する。SOCチームは例外処理と最終判断に集中できるようになる。 「インシデント管理の自動化はもはや贅沢品ではない」という原文の一節は正しい。AIに判断を委ねられる領域を積極的に移譲していくことが、限られた人員で組織を守るための現実解になっている。 Purview：AIガバナンスの穴を塞ぐ M365 Copilotの普及に伴い、「AIが機密情報を処理する」場面が日常的に生まれている。今回のPurview更新では、M365 CopilotのインタラクションにDLP（データ損失防止）ポリシーを全面適用できるようになった。AIとデータガバナンスを一体で設計する必要性が、いよいよ現実の課題として迫ってきた。 カスタム正規表現による平文パスワード露出の検知機能も実用性が高い。ログやメールに誤って含まれた認証情報を自動検出しポリシーに反映できる。地道だが実害を防ぐ効果は大きい。 Azure Key Vault HSM Platform Oneのリタイア告知も忘れてはならない。PurviewのBYOK（Bring Your Own Key）を利用している組織は、移行計画を今すぐ立てるべきだ。 実務への影響 日本のSOCチームやIT管理者が今すぐ検討すべきポイントを整理する。 Sentinel Training Labを即試す：本番環境なしで検証できる機会は貴重。新人育成・チーム演習に活用できる Security Copilotのエージェント機能を段階的に導入：フィッシングトリアージから始めると効果が測定しやすい M365 Copilot利用中ならPurview DLPの設定を今すぐ確認：AIとガバナンスは一体で設計する Key Vault HSMの移行期限を確認：BYOKユーザーは早急にドキュメントを確認すること 筆者の見解 Microsoftのセキュリティ製品群は、今この瞬間も確実に進化している。Sentinel・Defender・Purview・Copilot for Securityが有機的につながる「統合SecOps基盤」の完成度は、他のプラットフォームでは簡単に代替できないレベルに達しつつある。この点については、率直に評価したい。 ゼロトラスト推進の観点からも、今回の方向性は正しい。Just-In-Timeアクセス、NHI（Non-Human Identity）の適切な管理、ポリシー駆動のガバナンス——これらが自動化・AI化を通じて現実の運用に降りてきている。「常時アクセス権の付与」という旧来の設計思想から脱却できる環境が、着実に整ってきた。 ひとつ言わせてもらうなら、外部AIモデルとのMCP連携という方向性は面白い。Microsoftには「プラットフォームそのものの価値」で戦える十分な実力がある。その強みをフルに活かした設計をどこまで突き詰められるか——今後の展開を注視したい。 あとは現場がこの変化に追いつけるかだ。「今動いているから大丈夫」という感覚でいると、気づかないうちに大きく遅れをとる。セキュリティの自動化は「やれたらいいな」ではなく、今すぐ着手すべき優先課題として捉え直す時期に来ている。 出典: この記事は Azure Updates - Number 136 - May 2, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Azure Local」を大幅アップグレードし、国家・政府レベルのソブリンクラウド基盤として本格的に位置づけた。従来は16ノードまでのクラスター構成が上限だったが、新バージョン（12.2604.1003.209）では4,000ノード規模への拡張に対応。ファイバーチャネルSANとのストレージ統合、クラウド非依存のローカル制御プレーン、そして暗号鍵のローカル管理機能を一気に追加し、データ主権（データ・ソブリンティ）に厳格な要件を持つ政府機関・規制業種が現実的に選択できる基盤へと進化した。 Azure Localとは何か Azure LocalはMicrosoftが提供するオンプレミスクラウド製品で、AzureのHyper-Vハイパーバイザー、Azure Kubernetes Service（AKS）、ソフトウェア定義ストレージを組み合わせた構成が基本だ。これまでは小規模なエッジ/ハイブリッド用途を主眼に置いており、管理はAzure Arc経由——つまりMicrosoftのクラウドへの接続が前提——という制約があった。今回の大型アップグレードでその制約が大きく取り払われた。 今回の主要な変更点 ストレージのSAN対応 ファイバーチャネルSAN（Storage Area Network）との統合が可能になり、コンピュートとストレージを独立してスケールできるようになった。既存のSAN資産を持つ大規模データセンターでもAzure Localを段階導入しやすくなる。VMwareやNutanixがすでに提供してきた「コンピュートとストレージの独立スケール」に、AzureスタックもようやくエンタープライズレベルのSAN統合で並んだ形だ。 4,000ノードへのスケール対応 フォルト・ドメイン・モデリング、インフラストラクチャ・プール、マルチラック・ネットワーキングの強化により、「アーキテクチャの根本的な変更なし」で数百ノードから数千ノードへ拡張できる。ミッションクリティカルな可用性・耐障害性を維持しながらのスケールアウトが前提設計となっている点は評価に値する。 ローカル制御プレーンの追加 これが今回の変更の核心だ。新バージョンでは「Local Control Plane」が追加され、Azureへの接続なしにインフラを管理できるようになった。UIはAzureポータルと同一の操作感を維持しており、運用担当者の学習コストは最小化されている。 Local Identity with Key Vault 暗号鍵をローカルで管理する機能が追加された。エアギャップ環境（インターネット非接続環境）でも鍵管理が可能で、「クラウドプロバイダーに鍵を触らせたくない」という要件にも対応できる。 実務への影響——日本の政府・規制業種にとっての意味 日本では「政府情報システムのためのセキュリティ評価制度（ISMAP）」や金融機関への監督指針など、データの所在と管理主体に関する要件が年々厳格化されつつある。従来のAzure Localは「Azureへの接続が前提」という点で、こうした要件をクリアしにくいケースがあった。 ローカル制御プレーンの追加で「Microsoft管轄外の環境でAzure互換のインフラを動かす」という選択肢が現実的になった。エンジニアやIT管理者が明日から意識しておくべきポイントをまとめる。 既存SAN資産の活用: ファイバーチャネルSAN統合により、既存のSAN投資を活かしながらAzureスタックへの移行が可能。ストレージ刷新コストを抑えたい組織にとってメリットが大きい 段階的スケールアップ: 数百ノードから始めてアーキテクチャ変更なしに数千ノードへ拡張できる設計は、予算をフェーズ分割して調達しやすい GPU対応: 今回のリリースでGPUサポートも追加。AIワークロードをオンプレミスで実行したい政府・研究機関にとって重要な追加機能だ 鍵管理のローカル化: Key Vaultのローカル管理機能はHSM（Hardware Security Module）の補完として評価できる。鍵のライフサイクル管理を自組織でコントロールしたい場合の選択肢が広がった 筆者の見解 MicrosoftがAzure Localをソブリンクラウド対応に本格シフトさせたことは、評価に値する判断だと思う。 「データをどこに置くか」「誰が鍵を持つか」という問いは、特に日本の公共・金融・医療の現場で年々重みを増している。クラウドファーストの文脈でオンプレミスが「あきらめるもの」として扱われてきた時期があったが、実際には規制・主権・レイテンシの要件で「クラウドに置けないワークロード」は相当数存在する。そこに正面から応える製品投資として、今回のAzure Local強化は筋が通っている。 ローカル制御プレーンの追加は特に重要だ。「Azureに繋いでいる限り本当にソブリンと言えるのか？」という根本的な問いへの回答として機能する。暗号鍵のローカル管理と組み合わせることで、Microsoft側が技術的にアクセスできない構成を取れるようになる。これはゼロトラストの観点でも、「信頼は与えるものではなく、検証するもの」という原則に沿った正しいアーキテクチャだ。 競合との差分については正直に見ておきたい。VMwareとNutanixはすでにソブリンクラウド向けのスタックを実績付きで提供しており、今回Microsoftがようやくその土俵に本格参入した形だ。MicrosoftがAzure Localで差別化できるとすれば、「Azureと一貫した操作体験」と「Microsoft Entra IDによるID管理の統合」——つまり既存のMicrosoft環境との親和性だろう。その強みを実運用でどれだけ活かせるか、今後の事例が集まることで見えてくる。 方向性は正しい。Microsoftがプラットフォームとして「最も多くのエージェントと機密ワークロードが安全に動作する基盤」を作ることに本気で投資しているなら、Azure Localのこの進化はその証左のひとつだ。4,000ノード規模での実運用事例が出てくるのを、率直に楽しみにしている。 出典: この記事は Microsoft Levels Up Azure Local to Make It Fit for Large-Scale Sovereign Clouds の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzureの全新規サーバーに組み込むハードウェアセキュリティモジュール（HSM）のファームウェアとソフトウェアスタックを、OCP（Open Compute Project）を通じてオープンソース化すると発表した。「ベンダーを信じるしかない」という従来の構造から「自分たちで検証できる」構造への転換は、規制産業や政府系クラウドを利用する組織にとって見逃せない動きだ。 Azure Integrated HSMとは何か Azure Integrated HSMは、Microsoftが独自開発したHSMで、次世代V7世代のAzureサーバー全台に搭載される。既存のAzure Key VaultやAzure Managed HSMのような集中型サービスと組み合わせることで、暗号鍵の保護を「サービスレベル」から「シリコンレベル」まで引き下げる設計だ。 重要な点は、鍵が「保存されているとき」だけでなく「ワークロードが実際に実行されているとき」も保護されるという部分にある。AIエージェントが機密データを処理するユースケースが急増している今、推論処理中の鍵保護はクラウドセキュリティの新たな焦点になりつつある。 FIPS 140-3 Level 3が「デフォルト」になる意味 FIPS 140-3 Level 3は、米国政府や規制産業が採用するHSMの最高水準規格だ。要件として以下が求められる： 強力な改ざん耐性：物理アクセス試みの検知・防止 ハードウェア強制による分離：ソフトウェアからの鍵抽出を構造的に不可能にする 物理・論理両面での鍵保護：あらゆる攻撃ベクターへの対策 日本でも金融・医療・政府系システムへのクラウド採用において、同等水準の準拠が求められるケースが増えている。これをPremiumオプションや専用構成ではなく「プラットフォームのデフォルト値」として提供する意義は大きい。 オープンソース化が変えるもの 今回の発表の核心はオープンソース化にある。GitHubにファームウェアが公開されるほか、OCP SAFEによる独立した監査レポートも合わせて公開される。これにより以下が実現する： 規制産業：独立した検証が義務付けられているコンプライアンス要件への対応 ソブリンクラウド：各国政府が実装を独自に検証できる 相互運用性：プロプライエタリなプロトコルへの依存を減らし、標準ベースの統合が容易になる 3層の鍵管理アーキテクチャ 今回の発表で整理されたAzureの鍵管理は3層構造だ： レイヤー サービス 役割 集中管理層 Azure Key Vault ライフサイクル管理・ポリシー適用 集中管理層 Azure Managed HSM FIPS準拠の集中型HSM サーバー層 Azure Integrated HSM ワークロード実行中の鍵保護 また、TDISP（TLS Device Interface Security Protocol）のサポートにより、コンフィデンシャルコンピューティング環境との安全なバインディングも可能になっている。 実務への影響 コンプライアンス対応の簡素化：FIPS 140-3 Level 3がデフォルトで提供されることで、金融・医療・政府系システムの要件を追加構成なしに満たせる可能性が高まる。調達・認証プロセスの工数削減に直結する。 自前での検証が可能に：公開されたファームウェアを社内のセキュリティチームや外部監査人が精査できる。「ベンダーが言っているから信用する」から「自分たちで確認した」という根拠を得られる。 Non-Human Identity管理の強化：アプリケーションやサービス間の認証に使われる鍵をハードウェアレベルで保護できることは、NHI（非人間ID）を活用した自動化の促進にも直結する。自動化が進まない組織のボトルネックは結局「人間」だが、NHI管理の信頼基盤を固めることで、その詰まりを解消できる。 AIワークロードの信頼基盤として：AIエージェントが機密データを扱う場面が増えるほど、推論処理中の暗号保護は「あれば良い」から「なければ使えない」要件に変わっていく。今のうちに基盤を整えておく価値がある。 筆者の見解 セキュリティの話は得意な分野ではないが、今回のAzure Integrated HSMのオープンソース化は本物の動きだと評価している。 ...

Microsoft Entra IDの条件付きアクセスを運用しているすべての管理者にとって、見逃せない変更が2026年5月13日に施行される。「すべてのリソース（All resources）」を対象としたポリシーにおいて、リソース除外設定の扱いが変わり、これまで除外設定によって事実上回避されていたサインインもポリシー評価の対象になる。既存構成によっては予期せぬアクセスブロックが発生しうるため、施行前の早急な棚卸しが求められる。 条件付きアクセスの「リソース除外」とは 条件付きアクセスポリシーは、「誰が・どのアプリに・どの条件でアクセスするか」を制御する仕組みだ。ポリシーのスコープとして「すべてのクラウドアプリ」を指定しつつ、特定アプリだけを除外リストに入れることで、例外的なアクセスパスを設けることができる。 たとえば「すべてのリソースに多要素認証（MFA）を要求する」というポリシーを定義しながら、特定のレガシーアプリやサービスアカウント向けアプリを除外リストに追加するケースが多い。これは現実的な運用上の妥協点として広く使われてきた手法だ。 何が変わるのか 今回の変更の核心は「ポリシー強制適用の一貫性向上」にある。 これまでの動作では、「すべてのリソース」を対象とするポリシーに除外リソースが設定されている場合、該当リソースへのサインインがポリシー評価から実質的に外れるケースが存在した。ポリシー設計者の意図と異なる動作を引き起こす可能性があり、セキュリティギャップになり得た。 5月13日以降は、このギャップが解消される。「すべてのリソース」を対象とするポリシーは、リソース除外の有無にかかわらず、より一貫した形で評価・強制適用される。 事前に確認すべきポイント 1. 「すべてのリソース」対象ポリシーの棚卸し Entraポータルの「条件付きアクセス」→「ポリシー」で、スコープが「すべてのリソース」になっているポリシーを全件確認する。リソース除外が設定されているものは特に注意が必要だ。 2. 除外の意図を再確認する 除外設定が「技術的に仕方なく入れた回避策」なのか、「意図的な例外ルール」なのかを明確にしておく。前者の場合、変更後に予期せぬブロックが発生する可能性がある。 3. 「What If」ツールで影響をシミュレーション Entraの「What If」ツールやサインインログを活用して、変更後にどのサインインが影響を受けるかを事前に確認する。本番環境で突然ブロックが発生する前に、テストテナントや評価環境での検証も推奨する。 4. 5月13日以前に修正を完了させる ポリシーを意図した動作に修正するか、個別アプリへの専用ポリシーを作成して対応する。施行当日の対応では間に合わないケースもある。 日本のIT環境への影響 日本の大規模企業では、条件付きアクセスを「とりあえず設定した」状態のまま、除外リストを膨らませて運用しているケースが少なくない。特に、オンプレミスからEntraへ移行した時期に「既存システムが動かなくなると困る」という理由で除外を積み上げてきた環境は要注意だ。 今回の変更は、そうした「なんとなく動いていた」構成が明示的に問題として浮き上がるきっかけになる。影響を受けるポリシーを早期に特定し、ゼロトラストの観点でポリシー全体を見直す好機と捉えたい。 筆者の見解 ゼロトラストの本質は「すべてのアクセスを継続的に検証する」ことにある。その観点からすれば、今回の変更はMicrosoftが当然の挙動を当然に動くようにした、正しい方向性の修正だ。 ただ、「当たり前のことが今まで当たり前でなかった」という事実は率直に受け止めるべきだろう。リソース除外によるポリシー回避という設計上のあいまいさが長年存在していた点は、Entraの実力を考えればもったいなかったと感じる。Microsoft Entra IDはゼロトラストの中心的な基盤として十分な実力を持っている。その実力を全開にするには、こういった細部の一貫性こそが重要だ。 企業に対しては、「変更で壊れたから直す」という対応に留まらず、これを機にポリシー設計全体を見直してほしい。「常時アクセス権の付与」や「積み上がった除外設定」は、ゼロトラストの皮をかぶった旧来の境界防御に過ぎない。ポリシーを「管理画面上のスイッチ」ではなく「アクセス制御の設計図」として捉え直す——今回の変更は、その再設計への良い入り口になる。 出典: この記事は Conditional Access: Policy Enforcement Change for Resource Exclusions (May 13) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AKS（Azure Kubernetes Service）で、CiliumベースのAzure CNIとAdvanced Container Networking Services（ACNS）を使用するクラスターに、WireGuardによるノード間ポッドトラフィック暗号化が正式対応した。アプリケーション側の変更もサイドカーコンテナの追加も一切不要という「透過的暗号化」の実現は、Kubernetesセキュリティの現場にとって地味ながら重要な前進だ。 WireGuardとは何か——なぜKubernetesで注目されるのか WireGuardは2015年に登場したモダンなVPNプロトコルで、OpenVPNやIPSecと比較してコードベースが極めてシンプル（約4000行）かつパフォーマンスが高い。Linux 5.6以降ではカーネル標準機能として統合されており、近年のクラウドネイティブ環境で急速に採用が広がっている。 Kubernetesの文脈では「VPN」というよりも「ノード間通信の暗号化レイヤー」として捉えるのが正確だ。複数ノードに分散したポッド間の通信は、デフォルトでは平文のまま物理・仮想ネットワーク上を流れる。クラウド上ではネットワーク自体が暗号化されていることが多いが、「ネットワーク層は信頼しない」というゼロトラストの観点からは、独立した暗号化レイヤーを持つことが望ましい。 透過的暗号化の実装——CiliumとeBPFの組み合わせ 今回の機能が注目に値するのは、その透過性にある。従来、Kubernetes上でポッド間通信を暗号化しようとすると、主に以下の選択肢があった。 サービスメッシュ（Istio/Linkerd等）のサイドカープロキシ: ポッドごとにEnvoy等のプロキシを注入してmTLSを終端する アプリケーション組み込みのTLS: 各アプリが独自にTLS実装を持つ サイドカーアプローチは強力だが、CPU・メモリのオーバーヘッド、証明書管理の複雑さ、デバッグ難易度の上昇というコストが伴う。 CiliumはeBPF（Extended Berkeley Packet Filter）をLinuxカーネルレベルで活用するCNI（Container Network Interface）だ。eBPFによってネットワークパケットをカーネル空間で処理するため、ユーザー空間のプロキシを挟まずに透過的な暗号化が実現できる。WireGuardのカーネル統合と組み合わせることで、アプリケーション・ワークロードに一切の変更なく、ノード間の全ポッドトラフィックを保護できるようになった。 実務への影響 既存クラスターへの後付けが可能 新規クラスターだけでなく、既存クラスターへの後付け有効化にも対応しているのは実運用において重要だ。多くの企業のKubernetes環境はすでに本番稼働中であり、「次の再構築時に」という先送りが難しいケースも多い。段階的なセキュリティ強化を計画している組織にとって、ダウンタイムなしに暗号化を追加できる点は大きなメリットだ。 サービスメッシュの複雑性を避けたい場合の選択肢 ノード間通信の暗号化が必要だが、Istioのような重量級サービスメッシュを導入するリソースがない——そういったケースに、このアプローチは明確な答えを提供する。ただし、WireGuardによる透過的暗号化と、mTLSによるワークロードID認証は異なるレイヤーの話だ。「通信経路の暗号化」と「ワークロードの認証・認可」は別問題として整理しておきたい。 設定の前提条件 Azure CNI Powered by Ciliumが有効なAKSクラスター Advanced Container Networking Services（ACNS）の有効化 Ciliumの encryption.type: wireguard オプションで機能を有効化 既存クラスターの場合は az aks update コマンドで追加できるため、IaCのコード変更も最小限に抑えられる。 筆者の見解 ゼロトラストの文脈で言えば、今回の対応は「ネットワーク経路への暗黙の信頼を排除する」方向に一歩踏み出したものだ。クラスター内部であっても通信は暗号化する、という原則をインフラレベルで実装できるようになったことの意義は小さくない。 特に評価したいのが「アプリケーション変更なし・サイドカーなし」という設計思想だ。セキュリティ機能はこうあるべきで、使う側に余計な負担をかけずに安全が確保されるのが理想形だ。IaC（Terraform/Bicep）で数行の変更で暗号化が有効になるなら、「コストとメリットが見合わない」という言い訳は通用しなくなる。 AKSとCiliumの組み合わせがこの水準まで来たことは、Azureのネットワーキング投資が着実に積み上がっている証拠として素直に評価したい。こうした「インフラレイヤーで透過的に安全を担保する」仕組みが充実してきたことで、アプリケーション開発者はセキュリティの実装を意識せずに済む環境が整いつつある。日本のクラウドネイティブシフトを加速させる、実質的な武器の一つになるはずだ。 出典: この記事は AKS: WireGuard in-transit encryption now available for Azure CNI powered by Cilium の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure AI Foundryでリアルタイム音声AIがついに「本番品質」に到達した。2026年2月、OpenAIのgpt-realtime-1.5とgpt-audio-1.5がAzure AI Foundry Direct Modelsとして正式GA（一般提供）に移行した。前世代から引き継いだ低遅延特性を維持しつつ、現場導入を阻んでいた三つの課題——命令追従精度・多言語対応・ツール呼び出し——に正面から取り組んだアップデートだ。 何が変わったか：三点の重点強化 ① 命令追従精度の向上 音声AIはテキストAIよりもプロンプトが伝わりにくい。話し言葉の曖昧さや言い淀みを超えて指示を正確に実行できるかは、業務適用の第一関門だ。コールセンターや社内ヘルプデスクの自動応答では、ユーザーが崩れた言葉で問い合わせることも多い。この精度向上は直接、自動化の完成度に直結する。 ② 多言語対応の強化 前世代でも「多言語対応」を謳ってはいたが、日本語やインド系言語での精度は英語に比べて見劣りする場面があった。「英語なら動く、日本語は怪しい」では国内導入は進まない。今回の改善は、日本語音声業務への採用を現実的な選択肢に引き上げる。ASRモデル（gpt-4o-mini-transcribe）の改良も同時に進んでおり、日本語の文字起こし精度も着実に向上している。 ③ ツール呼び出し（Function Calling）の改善 音声入力を受け取りながらリアルタイムでAPIを叩いてデータ取得・処理を行う、いわゆる「音声エージェント」の実現に不可欠な機能だ。これが安定して動くようになると、「しゃべるだけで社内システムを操作できる」インターフェースの開発が一気に現実味を帯びる。 接続方式の柔軟性：SIP対応がゲームチェンジャー WebRTC・WebSocket・SIPの三方式に対応している点も重要だ。2025年10月に追加されたSIP対応は特に大きい。既存の電話インフラ（IP-PBX、コールセンターCTIシステム等）との統合が、新規のシステム置き換えなしに実現できる。電話番号はそのままに、受話後の処理だけをAIに置き換えるというアプローチが可能になる。 実務への影響 日本企業が今すぐ検討すべきシナリオを整理する。 ユースケース ポイント コールセンター一次対応の自動化 SIP対応でCTI連携が容易。既存番号を活かしたまま投入可能 社内ヘルプデスク音声ボット Teams Phoneとの統合でユーザーが内線感覚で問い合わせ可能 音声インターフェース付きエージェント Function Calling改善でリアルタイムデータ取得が安定動作 会議・商談リアルタイム文字起こし 話者分離対応のgpt-4o-transcribe-diarizeと組み合わせると威力倍増 エンジニア向け実装ヒント： Chat Completion APIと同じ感覚で呼べる設計のため、テキストAI開発の経験があれば移行コストは低い Azure AI Foundryポータルで即座に試せる。まず動かして感覚を掴むのが最速 用途によってはSpeech-to-Textのみの軽量構成（gpt-4o-mini-transcribe）も有効。フル音声応答が不要なシナリオでコストを最適化できる 筆者の見解 音声AIの「本番品質」への到達は、テキストAIよりも数年遅れていた。命令追従が不安定、日本語が怪しい、Function Callingが動かない——そのどれか一つが欠けると業務導入は止まる。今回のGA発表は、その三つの穴を塞いできたという意味で素直に評価したい。 Azure AI Foundryを通じてこれらのモデルが使えるという点も、IT管理者の視点では重要だ。AzureのセキュリティポリシーやMicrosoft Entra IDによるアクセス制御をそのまま活用しながら最新の音声AIを本番投入できる。「AIを使いたいが、セキュリティ統制が追いつかない」という悩みを抱える日本の大企業にとって、Azure AI Foundry経由というのは最も「道の真ん中」にある選択肢だ。 コールセンターや音声窓口の自動化は、もはや「近未来の話」ではない。SIP対応で既存インフラへの統合ハードルが下がり、多言語対応が改善され、Function Callingが安定した——今期の検討テーブルに載せるべき条件が揃ってきた。 音声AIの精度競争はまだ続く。だが「試す価値がある」から「本番投入できる」への閾値を越えた今、動き出すタイミングを逃す理由はなくなりつつある。 出典: この記事は GPT RealTime 1.5 and GPT Audio 1.5 now Generally Available on Azure AI Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIエージェントが「前回の会話を覚えている」——この一見シンプルな能力が、エンタープライズAI活用の成否を左右する時代が来た。Microsoft Foundry Agent Serviceが提供する「Memory（プレビュー）」機能が、2026年6月1日以降に有償化されることが正式に発表された。セッションをまたいでユーザーの好みや文脈を自動的に抽出・保持・再活用するフルマネージドのメモリ基盤だ。GAを目前に控えた今、エンタープライズでの本格導入を検討するタイミングが来ている。 短期メモリと長期メモリ、何が違うのか AIエージェントのメモリには大きく2種類ある。 短期メモリ（Short-term memory） は現在のセッション内の会話履歴を保持するもので、多くのエージェントフレームワークが既に実装している。「先ほど言ったように」という発言の文脈をエージェントが理解できるのはこの仕組みのおかげだ。 長期メモリ（Long-term memory） はセッションや端末をまたいで知識を保持する。「このユーザーは乳製品アレルギーがある」「月次レポートは英語で欲しいと言っていた」——こうした情報をセッションが終わっても保持し続けるのが長期メモリの本質だ。 Foundry Agent ServiceのMemory機能はこの長期メモリに特化している。 3フェーズで動く自動メモリ処理 Memory機能は以下の3フェーズで自律的に動作する： 抽出（Extraction）: 会話からユーザーの好み・事実・文脈を自動抽出して保存 統合（Consolidation）: LLMが類似・重複メモリをマージし、矛盾する情報（新しいアレルギー情報など）を解決して最新状態を維持 検索（Retrieval）: 必要なタイミングで最も関連性の高いメモリを検索して会話に反映 この処理はすべてマネージドで提供される。開発者はベクターDBの運用やメモリ整合性管理に頭を悩ませる必要がない点は、実務上かなり大きなメリットだ。 価格体系——プレビュー中に使い倒せ プレビュー期間（〜2026年6月1日）は無料。6月以降の価格は以下の通り： 種類 価格 短期メモリ $0.25 / 1,000イベント 長期メモリ $0.25 / 1,000メモリ / 月 月単位で積み上がる長期メモリのコストは、ユーザー規模が大きい場合に予想外の金額になりやすい。プレビュー期間中に実際の利用量を計測し、本番導入後のコスト試算を済ませておくことを強くすすめる。 実務での活用ポイント 今すぐ検討すべき3つのシナリオ 1. 社内ヘルプデスクエージェント ユーザーごとの環境・権限・過去の問い合わせ内容を記憶することで、「また最初から説明する」コストを削減できる。問い合わせのたびに同じ情報を入力し直す無駄は思った以上に大きい。 2. カスタマーサポート自動化 顧客ごとの契約内容・過去トラブルの経緯を長期保持し、担当者が変わっても文脈が引き継がれる体験を実現できる。 内部業務エージェント（承認フロー・レポート生成等） 担当者の好みや判断パターンを学習させることで、エージェントの精度が時間とともに向上する。定型的なやり取りをメモリに蓄積すれば、都度の指示が不要になる部分が増えていく。 設計上の注意点 Foundry IQのナレッジベース（組織共有のドキュメント）とMemory（個人ユーザー文脈）は用途が根本から異なる。設計段階で「これはOrg-wideの知識か？User-specificな文脈か？」を明確に分離することが、コスト最適化と精度維持の両面で効いてくる。 また、メモリ内容はユーザーのプライバシーデータにもなりうる。Microsoft Entra IDと組み合わせてメモリストアへのアクセス制御を適切に設計することは必須だ。エージェントが誰のメモリにアクセスできるか、という認可設計を最初から組み込んでほしい。 筆者の見解 この機能がGAに近づいたことは、エンタープライズ向けAIエージェント基盤としてのFoundryが着実に成熟している証だと思う。 エージェントが「記憶を持つ」ことは、単なる利便性の向上ではない。これは自動化の質が根本から変わることを意味する。従来のRPA的な自動化は「決まった手順を繰り返す」ものだった。Memoryを持つエージェントは「経験を積みながら継続する」自動化になる。ユーザーが何度も同じ好みを伝えなくていい世界は、業務効率の観点からも意義が大きい。 Non-Human Identity（NHI）の管理と組み合わせて考えると、このメモリ機能はさらに重要な意味を持つ。エージェントがユーザーコンテキストを正確に保持・活用できれば、人間の介入が必要なシーンをさらに減らし、承認フローや判断処理のより大部分をエージェントに委ねられるようになる。業務効率のボトルネックは常に「人間の関与」にある。その関与を減らす仕組みが、プラットフォームレベルで整ってきている。 Foundryは「どのAIモデルを動かすか」という選択と、「エージェントの記憶・認証・オーケストレーションをどう管理するか」という基盤の両方を提供している。この方向性は長期的に正しい。基盤をしっかり固めて、その上で動かすモデルや能力を選べる構成は、技術の進化が速い今の時代に柔軟性が高い。プレビュー期間のうちに実際に手を動かして、自社の業務フローにどう組み込むか検証しておく価値は十分にある。 出典: この記事は Memory in Microsoft Foundry Agent Service (preview) — Pricing and GA timeline announced の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIエージェントを「書くこと」は難しくなくなった。難しいのは「安全に、本番で、企業規模で動かすこと」だ。Microsoftは今回、この課題に正面から向き合った答えを出してきた。Azure AI Foundryのホステッドエージェント（Hosted Agents）がパブリックプレビューとして提供開始。すべてのエージェントセッションを独立したVM隔離環境で動作させ、エンタープライズ規模での本番運用を実現する基盤だ。 なぜ既存のコンピューティングではエージェントが動かないのか コンテナ、Webアプリ、サーバーレス関数——これらはいずれも「複数ユーザーが同一インスタンスを共有する」前提で設計されたアーキテクチャだ。Webサービスやシンプルなバックエンドなら問題ない。しかしAIエージェントは根本的に違う。 エージェントはファイルシステムへの読み書き、コードの実行、認証情報・中間状態の長期保持を行う。顧客AとBが同一エージェントコンテナに乗っかり、そのコンテナが共有ファイルシステムに書き込んでいる——これはパフォーマンス問題ではなく、セキュリティ上の根本的な欠陥だ。 今回のホステッドエージェントはこの問題を「プロセス分離」や「コードサンドボックス」の小手先ではなく、ハイパーバイザーレベルの本格的なVM分離で解決している。 主要機能の解説 セッション単位のVM分離 すべてのエージェントセッションが専用VMサンドボックスで動作する。コンテナ分離より重い代わりに、分離の強度と証明可能性が段違いだ。マルチテナント環境での「隔離されている」という証明が、コンプライアンス審査で決定的な意味を持つ。 スケール・トゥ・ゼロとファイルシステム永続化 アイドル時はコストゼロ。そして再起動後もファイル・ディスク状態・セッション識別子がそのまま保持される。エージェントは「続き」から作業を再開できる。これは従来のサーバーレスでは実現困難だったパターンだ。 統合アイデンティティ管理 エージェントごとの専用IDと、OBO（On-Behalf-Of）トークンによるユーザー別ID委任をサポート。「このエージェントが、この権限で、何をしたか」というトレーサビリティの基盤になる。 BYO VNet・バージョン管理・プロトコル互換性 アウトバウンドトラフィックを自社VNet経由でルーティング可能。ウェイテッドロールアウト（段階リリース）やOpenResponses/Activity Protocolの自動マッピング、AG-UIサポートまでビルトインで提供する。 日本のIT現場への影響 AIエージェントを本番運用しようとして「どう安全に動かすか」の審査で止まっているケースは、日本企業に多い。特に金融・医療・官公庁など規制の厳しいセクターでは、マルチテナント環境での隔離の証明と、エージェント行動の監査ログが承認の前提条件だ。 既存エージェントへの適用が容易: アプリケーションコードの変更なしに適用可能とされており、導入の摩擦が低い。 Non-Human Identity（NHI）管理との接続: エージェントが人間の代わりに業務を実行する時代、エージェント自身の「ID・権限・行動ログ」の管理は自動化推進の前提条件になる。セッション単位ID管理はそのピースの一つだ。NHI管理ができなければ、業務自動化は人間のボトルネックを解消できない。 コスト構造の透明化: スケール・トゥ・ゼロにより、動作時間のみの課金になる。PoC段階で「本番移行後のコストが読めない」という問題が軽減される。 筆者の見解 「エージェント時代のゼロトラストを本気で設計しはじめた」——今回の発表を一言で表すなら、そういうことだと思う。 Microsoftが狙っているのは「最も賢いAIを作る競争」ではなく、「最も多くのエージェントが安全に動作するプラットフォームを提供する競争」だ。今回のホステッドエージェントは、その戦略が着実に具体化されていることを示している。Microsoft Entraをエージェントの管制塔として機能させ、Foundryをその実行基盤として整備していく絵が見えてきた。この方向性は長期的に正しい。 ただし、現実的な目線でも見ておきたい。ハイパーバイザー分離はコンテナより重い。大量セッションの同時起動シナリオでのコストとレイテンシがどうなるかは、パブリックプレビュー期間中に実際に検証してみる価値がある。Microsoftの技術力があれば正面から解決できるはず——そこに期待したいし、そのための検証データを早く出してほしいところだ。 Foudnry Agent Serviceを使っている方は、まずプレビューで既存エージェントに適用してみることをお勧めする。コード変更不要で試せるなら、やらない理由はない。 出典: この記事は Introducing the new hosted agents in Foundry Agent Service: secure, scalable compute built for agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月下旬、Azure Databricksに複数の重要な変更が一斉に展開される。なかでも注目すべきは、コンプライアンスセキュリティプロファイルが有効なワークスペースへのScoped PAT（スコープ付き個人アクセストークン）のデフォルト有効化と、New SQL Editorのデフォルト化だ。地味に見えて実運用への影響は大きく、インフラ担当者は今から準備しておく必要がある。 New SQL Editorがデフォルトに 2026年5月下旬をもって、Databricksの新しいSQL Editorが全ワークスペースで標準UIになる。これまでは手動で切り替える必要があったが、5月以降は新規・既存を問わず自動的にNew SQL Editorが適用される。 インターフェースの操作感が変わるため、日々使っているデータエンジニアやアナリストへの事前周知が欠かせない。特に大規模なチームで共有ダッシュボードや保存済みクエリを多用している場合、切り替え後のUI差異による混乱を防ぐためのウォークスルーを社内で実施しておくと安心だ。 Scoped PATとは何か——「最小権限」を自動化に組み込む 従来のPAT（Personal Access Token）は、作成者が持つワークスペース全体の権限をそのまま引き継ぐ仕組みだった。PATが漏洩したり誤用されたりすると、そのユーザーが持つすべての操作権限が侵害される。 Scoped PATはこの問題を解消する。トークン生成時に1つ以上のAPIスコープ（操作範囲）を明示的に指定することで、そのPATが実行できる操作を特定のAPI呼び出しに限定できる。「ジョブ実行のみ許可」「クラスター一覧の取得のみ」といった粒度で制御可能だ。 これはゼロトラストの観点から非常に正しいアプローチだ。APIキーやトークンといったNon-Human Identity（NHI：非人間アイデンティティ）は、日々の自動化・CI/CDパイプライン・スクリプトで大量に使われているが、その権限管理は往々にして雑になりがちだ。「とりあえず全権限で」「後で絞る」は永遠に後で絞られない。Scoped PATによってデフォルトが最小権限側に引き寄せられるのは、セキュリティ成熟度を底上げする変化だ。 見落としがちな「孤立権限」の罠 今回のリリースで特に注意が必要なのが、ワークスペース・オブジェクト権限の継承変更だ。今後は、ワークスペースから削除済みのグループに残存している権限（「孤立権限」）が、意図せず有効化される可能性がある。 具体例を挙げると、「Contractors」グループがワークスペースから除外されていても、そのグループがフォルダへの編集権限を保持したままの場合、グループメンバーが突然そのフォルダにアクセスできるようになる。DatabricksはOrphaned Permission Analysis Notebookを提供しているため、リリース前に必ず実行して孤立権限を洗い出すべきだ。 Terraform・SCIM自動化ユーザーへの破壊的変更 もうひとつ見逃せないのが、ワークスペース・システムグループ（users・admins）のエンタイトルメント固定化だ。これまでは自動化スクリプトやTerraformでusersグループのエンタイトルメントを操作できたが、今後はこれが不可能になる。 既存のエンタイトルメントはクローングループに自動移行されるとのことだが、Terraform・Workspace SCIM API・カスタムスクリプトでシステムグループを管理している場合はコードの修正が必須。移行前に自動化ワークフローを棚卸しておくことを強く推奨する。 Power BI → ADBC移行も並行して進める 2026年7月には、Power BIのすべての接続がODBCからADBC（Arrow Database Connectivity）へ移行する。2025年10月からパブリックプレビューとなっており、2026年2月以降の新規接続はすでにADBCがデフォルトになっているが、既存の接続はODBCのままだ。本番移行前に、ステージング環境でADBC接続の動作検証を済ませておこう。 実務への影響 データエンジニア: New SQL Editorへの切り替えをチームへ事前周知。保存済みクエリ・ワークフローの動作確認を。 セキュリティ担当者: Scoped PATのスコープ設計を今から検討。既存PATの棚卸しと最小権限への見直しを。 インフラ/プラットフォームチーム: 孤立権限の棚卸し（Notebookを活用）とTerraform/SCIMスクリプトの修正を5月リリース前に完了させる。 BIチーム: Power BIのADBC移行を7月本番前にステージングで検証。 筆者の見解 Scoped PATの話は、表面上は「PATのスコープが切れるようになった」という地味な機能追加に見える。しかし本質はもっと深いところにある。 自動化やAIエージェントが日常的に動く現代の環境では、人間のアカウントよりもNHI（サービスアカウント、APIキー、トークン類）の方が圧倒的に多い。そしてこれらNHIの権限管理が甘いままでは、いくら認証を強化しても意味がない。Just-In-Time（JIT）アクセスや最小権限の原則は、人間のアカウントだけでなくNHIにも適用されなければならない。Scoped PATはその方向性への一歩だ。 一方で、孤立権限の問題が示すように、権限管理を長年放置していると「変更を加えるたびに想定外のアクセスが発生する」状態になる。これはセキュリティの問題というよりガバナンスの問題だ。「今動いているから大丈夫」という姿勢は、自動化投資の足を引っ張る最大の障壁になる。 今回のAzure Databricksのアップデートは、地味ながらも「ちゃんとやろうとしている」という意志が感じられる変更群だ。インフラチームがこの機会に権限管理の棚卸しをするきっかけにしてほしい。 出典: この記事は Azure Databricks: SQL editor becomes default + scoped PAT GA in May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIエージェントが業務の至るところに展開される時代が本格到来しつつある中、Microsoftが2026年4月30日、AIエージェントに特化したセキュリティ機能群を一斉公開した。Agent 365 Runtime Protection、Defender for CloudのAI Security Posture Management（AI-SPM）、GitHub Advanced Securityの強化、Microsoft PurviewのAI Data Security Investigationsと、守備範囲はインフラからコード、コンプライアンスまで広範にわたる。EU AI Actの本格施行が2026年8月に迫る中、このタイミングの発表は偶然ではない。 AIエージェントのリアルタイム監視——Agent 365 Runtime Protection 現在パブリックプレビュー中のAgent 365 Runtime Protectionは、Copilotプラットフォーム上で動作するAIエージェントの挙動をリアルタイムで監視する仕組みだ。従来の静的ルールではなく、行動ベースラインと異常検知エンジンを組み合わせることで、未知の攻撃パターンにも対応できる点が大きな特徴である。 エージェントが認可外のデータアクセスや予期せぬAPIコールを試みた場合、アクセス権を自動で剥奪し、Microsoft Entra IDと連携して最小権限ポリシーを動的に適用する。医療分野でのアーリーアダプター事例では、スケジューリングエージェントが患者データを外部メールに転送しようとした操作をリアルタイムでブロックしたという。HIPAAコンプライアンス違反になりかねなかった事案を未然に防いだこのケースは、エンタープライズ展開における実用価値を端的に示している。一般提供（GA）は2026年Q3の見込みだ。 セキュアスコアでAIワークロードを可視化——Defender for Cloud AI-SPM Defender for CloudにAI Security Posture Management（AI-SPM）が加わった。Azure OpenAI、Copilot Studio、カスタムエージェントフレームワークといった全AIワークロードを一元ダッシュボードで把握し、セキュアスコアとして評価する。 過剰なモデルエンドポイント権限やコンテンツフィルターの欠如などのミスコンフィグレーションを検出し、プロンプトインジェクションやモデル盗用の脅威検知結果はMicrosoft Sentinelにアラートとして流れる。クラウドだけでなくAzure Arc経由でハイブリッド環境もカバーしている点は、オンプレミスとの共存が続く日本の大企業にとって見逃せないポイントだ。 AIが書いたコードのリスクを洗う——GitHub Advanced Security AI生成コードの脆弱性は従来の静的解析ツールが見落としやすい。今回のCodeQL強化では、安全でないデシリアライズ、幻覚による存在しないライブラリの呼び出し、ロジック上の欠陥など、AI特有の脆弱性パターンを検出するクエリパックが追加された。 さらに注目すべきは、AIエージェントが開発ワークフロー中に動的生成したAPIキーやトークンを検出できるようになったシークレットスキャンの強化だ。従来の静的スキャンでは拾えなかったこのリスクへの対応は、AI活用が進む現場では即座に価値を発揮する。 Agent Actions Auditにより、Copilot Chatエージェントがプルリクエストで提案した全コード変更と、その変更を引き起こしたプロンプトのコンテキストが記録される。センシティブなモジュールに触れるエージェント生成コードには手動承認ポリシーを設定できるため、CI/CDパイプラインの整合性を保ちながらAI活用を進められる。 データライフサイクルを可視化——Purview AI Data Security Investigations Microsoft PurviewのAI Data Security Investigationsは、M365・Azure・サードパーティAIサービスのログを横断的に相関分析し、AI操作のデータライフサイクルを視覚的なタイムラインで再構築する。マーケティングエージェントが顧客データベースにアクセスし、個人情報を要約して外部モデルに共有した一連の流れを事後に追えるようになる、といったユースケースが想定されている。 AI-sensitive information typesの導入により、AIシステムが生成・入力したデータの自動分類も可能になり、保持ラベルやデータ損失防止（DLP）ポリシーの適用精度が高まる。 実務への影響——日本のエンジニア・IT管理者に向けて 今すぐ始められることを整理する。 AI-SPMのセキュアスコアをベースラインに: 既存のAzure AIワークロードを棚卸しし、AI-SPMダッシュボードでスコア化するだけで優先対応箇所が明確になる。現状把握から始めるのが最短ルートだ。 GitHubのAgent Actions Auditを開発ポリシーに組み込む: AI生成コードに対する特別なレビュープロセスを設けるかどうか、まずポリシーを定義することから着手するとよい。 Purviewで証跡自動化の検討を: EU AI Act対応が必要な組織はもちろん、将来の国内規制に備える観点でも、今のうちにPurviewのタイムライン機能を使って知見を蓄えておく価値がある。 NHI（Non-Human Identity）管理の整備: AIエージェントはNHIの典型だ。エージェントが増えるほど、各エージェントに付与されたIDと権限の管理が複雑化する。今回のEntra ID連携・最小権限の動的適用はこの問題への直接的な答えであり、業務自動化推進のボトルネック解消にも直結する。 筆者の見解 今回の発表を一言で表すなら、「エージェント時代のゼロトラストを本気で設計しはじめた」ということだと思う。エージェントは人間と同じように——いやそれ以上の速度で——大量のデータにアクセスし、外部サービスと通信し、コードを書く。そのひとつひとつにIDがあり、権限があり、監査ログが必要になる。ここを疎かにした状態でエージェントをばらまくのは、かつての「サービスアカウントのパスワードを何年も変えていません」という状況と構造的に何も変わらない。 ...

Azureのインフラ自動化ツールが「実戦仕様」に本格シフト Azure Developer CLI（azd）の2026年4月リリースは、バージョン1.23.14から1.24.2まで、わずか1ヶ月で5本のリリースを重ねた。数だけ見れば「ちょこちょこ更新」に聞こえるが、中身は違う。開発者が現場で感じていた「Bashしか書けないフック」「AIクォート不足で途中死亡」といった実痛点をまとめて刺してきた。技術的な完成度よりも使い勝手の改善に舵を切ったアップデートとして評価したい。 主要アップデートを読み解く 🪝 多言語フックサポート——チームの言語でazdを書ける 今回最大の目玉は、azure.yamlのフックにPython・JavaScript・TypeScript・.NETが加わったこと。これまでBashとPowerShellしか選択肢がなく、「フロントエンドチームがNode.jsしか書けないのにShellスクリプトを強要される」「Pythonチームが無理やりBashを覚える」といった摩擦があった。 各言語には自動的な依存関係管理も付属する： Python：requirements.txtまたはpyproject.tomlを検出 → 自動で仮想環境を構築して依存を解決 JavaScript/TypeScript：package.jsonがあればnpm installを自動実行。TypeScriptはnpx tsxでコンパイル不要 .NET：.csファイルを指定するとdotnet runで実行。.NET 10以降は単一ファイルスクリプトにも対応 「言語の壁」は地味に生産性を削ぐ。特にPolyglotな開発チームでは、「フックのためだけにBashを覚えさせる」コストが馬鹿にならない。この改善はそういう現場への直接的な答えだ。 🤖 AIモデルクォータの事前チェック azd provision実行時に、BicepスナップショットからAzure Cognitive Servicesのモデルデプロイを検出し、プロビジョニング前にクォータ不足を警告する機能が追加された。 これが地味に助かる。AIワークロードをAzureにデプロイした経験のある人なら分かるはずだが、「プロビジョニングを走らせて途中でクォータ不足エラー→半端な状態でリソースが残る→手動クリーンアップ」というフローは何度経験してもストレスがたまる。フェイルファストで事前に止めてくれるようになったのは大きい。 🔌 エクステンションフレームワークの成熟 カスタムプロビジョニングプロバイダーにより、Bicep以外のインフラバックエンドをエクステンションとして差し込めるようになった。Terraform派や独自IaCを使っている組織にとっては、azdのワークフロー統一を諦めなくて済む選択肢が広がる。 Key Vaultシークレットリゾルバー（@Microsoft.KeyVault(...)参照を自動解決）も実用的な追加だ。エクステンションに渡す環境変数の中にシークレットがあっても、平文を経由させずに済む。 🔒 セキュリティ改善 Windows MSIのコード署名検証 エクステンションコマンドでの環境変数リーク修正 セキュリティ系の修正は地味だが、エンタープライズ環境での採用を進めるうえで外せない要素。特に環境変数のリークはCI/CDパイプラインでのシークレット漏洩リスクに直結するため、すぐにazdのバージョンアップを適用することを強くすすめる。 azd updateのパブリックプレビュー昇格 azd updateが単一コマンドでazdそのものをアップデートできる機能として、すべてのプラットフォームでパブリックプレビューに。「ツールのアップデート方法がプラットフォームごとに違って混乱する」問題を一本化する取り組みで、これは地味ながら運用担当者には嬉しい。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと 1. 既存の自動化パイプラインにはまずセキュリティパッチを エクステンションコマンドの環境変数リーク修正が含まれている。CI/CDでazdを使っている環境は、secrets/環境変数の扱いを見直しつつバージョンアップを。azd update（パブリックプレビュー）を使えば一発で済む。 2. フロントエンド・フルスタックチームへのazd普及障壁が下がった Bash/PowerShellを書ける人材がいない、あるいはフロントエンドチームにもインフラデプロイを担当させたいケースで、今回の多言語フックは有効な武器になる。package.jsonがあればNode.jsの依存も自動管理されるため、学習コストは最低限で済む。 3. AIワークロードのデプロイ品質が上がる AIモデルのクォータ事前検証は、Azure OpenAIやAzure AI Foundryを使ったソリューションをデプロイしている現場全員に関係する。「本番環境でいきなりプロビジョニングが止まる」リスクを下げるためにも、クォータ確認フローとしてazdを標準化する価値がある。 4. --no-promptの標準化でCI/CDエージェントとの相性が向上 人間の入力を前提にしたCLI動作はAIエージェントや自動化パイプラインの天敵だ。--no-promptの挙動が標準化されたことで、azdをエージェントワークフローの一部として組み込みやすくなった。 筆者の見解 azdはもともと「Azureへのデプロイを標準化する」ツールとして生まれたが、近年はAIワークロードの急拡大を追いかけながら急ピッチで進化している。今回のアップデートを見ると、その方向性が「デベロッパーフレンドリーな実用ツール」として整合性を持ちはじめているように感じる。 多言語フックは「できたら嬉しい」機能ではなく、「これがないと採用を諦めていた」チームがいたはずの機能だ。こういう実際の摩擦点を拾って潰す改善は、正直評価したい。 一方で、今回触れられなかったazd＋AI Foundryの連携という文脈は引き続き注目している。Azureのインフラ自動化とAIエージェントのオーケストレーションが統合的に進化していくとすれば、azdはその入口として戦略的に重要なポジションを担うことになる。Microsoft Entra IDを認証基盤に据えつつ、エージェント的なワークロードをazdで展開管理していくアーキテクチャは、エンタープライズのAI導入として「道のド真ん中」の選択肢になりうる。 5リリースを1ヶ月に詰め込むスピードには、良い意味での切迫感を感じる。これを継続できるなら、azdは2026年中にインフラ自動化の現場で「標準選択肢」として定着する可能性が十分ある。今のうちに触れておいて損はない。 出典: この記事は Azure Developer CLI (azd) – April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月、Azure AI Foundry Agent Serviceに実務的な開発者視点で見ると非常に重要なアップデートが入った。Python SDKまたはREST APIを使って、コンテナ化されたエージェントコードを直接デプロイできるようになったのだ。一見地味に映るかもしれないが、これは「お試しフェーズ」から「本格的なエージェント開発基盤」へのギアチェンジを意味する変更である。 これまでの制約と今回の変化 Azure AI Foundry Agent Serviceはこれまで、Azure Portalのウィザードやクイックスタートテンプレートに沿って構築するスタイルが主流だった。手軽に試せる反面、プロダクション環境では「クイックスタート前提の構造的制約」が足かせになるケースがあった。 今回のアップデートでは、自前のコンテナ化されたエージェントコードを以下の方法で直接デプロイできるようになった。 Python SDK（azure-ai-foundry）：エージェントをプログラマティックに定義・管理 REST API：HTTP経由でコンテナ化エージェントをデプロイ・操作 変更前 変更後 クイックスタートウィザード依存 Python SDK / REST API で直接デプロイ Portal中心の操作 CI/CDパイプラインへの統合が容易 テンプレートの制約あり 独自コンテナをそのまま持ち込める 実務への影響 GitOps・DevOpsとの自然な統合 エージェントのデプロイが「git push → CI → REST API call」という流れに乗せられるようになった。インフラのコード化（IaC）の延長線上にある発想であり、エージェントのバージョン管理・ロールバック・本番昇格のフローをチームの既存ワークフローに組み込みやすくなる。 既存スキルセットでの参入 「エージェント専用の新しい学習コスト」を最小化できる。Python SDKやREST APIという多くのエンジニアが既に持つスキルでエージェント開発に入れるのは、普及の観点で大きい。Azure OpenAI ServiceやAzure AI Servicesをすでに使いこなしているチームは特にスムーズに移行できるだろう。 セキュリティ・ガバナンスとの統合 Microsoft Entra IDやAzure RBAC、Azure Policyとの連携がコンテナ単位で適用できるようになる。エージェントが「特別扱いの何か」ではなく「通常のAzureリソース」として管理される設計は、エンタープライズガバナンスの文脈で非常に重要な意味を持つ。Non-Human Identity（NHI）の管理が整備されてこそ、エージェントへの権限委譲が安全かつ監査可能なかたちで実現できる。 筆者の見解 Azureのプラットフォームとしての設計思想が、ここでも着実に体現されている。コンテナ直接デプロイへの対応は「エージェント開発を一部のパワーユーザーだけのものにしない」という方向性と一致しており、エンタープライズ現場への普及を後押しするだろう。 個人的に注目しているのは、エージェントをAzureの通常リソースとして扱うという設計思想だ。業務効率のボトルネックはいつも「人間の関与が必要な部分」にある。NHIをきちんと管理できる基盤があってこそ、エージェントへの権限委譲が現実的になり、自動化が実際に動き始める。Microsoft Foundry経由でエージェント基盤を整備する道筋は、長期的に正しい方向だと考えている。 クイックスタートの「お試し感」を超えて、プロダクショングレードの基盤として成熟してきた今こそ、日本のIT現場でも真剣に設計に向き合う時期が来ている。「まずPoC」で止まっているチームには、今回のアップデートを機に本格移行を検討するきっかけにしてほしい。 出典: この記事は Microsoft Foundry Hosted Agent Update: What Changed for Azure OpenAI Teams in April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがFY2026（2025年7月〜2026年6月）第3四半期の決算を発表し、売上高は前年同期比18%増の829億ドルを記録した。なかでも注目すべきはAzureの成長率で、前年同期比40%増とアナリスト予想（37〜38%）を大きく上回る結果となった。 数字が語る「Azure一強」の構図 インテリジェントクラウド部門の売上は346.8億ドルで、前年比30%増という力強い伸びを記録した。この部門にはAzureのほかSQL Server、Windows Server、GitHubなどが含まれるが、成長の主役がAzureであることは疑いようがない。 一方でMore Personal Computing部門（Windows・Xbox・デバイス等）は苦戦が続き、特にXboxとデバイス販売の縮小が目立つ。全社18%成長の中でクラウド部門だけが突出した伸びを示すという、極めて明快な「クラウド軸への集中」が数字から読み取れる。 Azure 40%成長の牽引役：AIワークロードの本格化 Azure成長の背景には、AIワークロードの急拡大がある。「とりあえずクラウドへのリフト&シフト」という時代から、生成AIや機械学習ワークロードを前提とした「AIネイティブなクラウド活用」へのシフトが進んでおり、その受け皿としてのAzureの存在感が一気に高まっている。 Azure OpenAI ServiceやAzure AI Foundryが大手企業のAI本番導入の基盤として機能し始めており、「AIのプラットフォームとしてのAzure」という地位が着実に確立されつつある局面だ。 実務への影響：日本のIT担当者が今考えるべきこと クラウド戦略の棚卸しタイミング Azure 40%成長という数字は「Microsoftが儲かっている」という話に留まらない。世界中の企業がAzureにAIワークロードを移し始めているという事実の反映だ。日本企業もこの流れに乗り遅れないよう、クラウド活用戦略の見直しを行う好機と捉えるべきだ。 Azure AI Foundryによるガバナンス確保 Azure AI Foundryは、自社のAzure環境内で複数のAIモデルを安全に利用できる基盤を提供する。パブリックなSaaSとは異なり、データのガバナンスを自社でコントロールできる点は日本の大企業にとって重要な選択基準となる。Microsoft Entra IDとの統合によるアクセス管理は、ゼロトラスト推進の文脈でも強みだ。 デバイス戦略の再点検 XboxやSurface等のデバイス販売が振るわない状況は、Microsoftがハードウェアへのリソース配分を絞りソフトウェア・クラウドに集中する方向性を示唆している。Surfaceへの依存度が高い組織は、中長期的な端末調達戦略の見直しも視野に入れておく価値がある。 筆者の見解 Azureが40%成長したことは、率直に言って「実力通り」の結果だと感じる。Azure基盤の堅牢さ、Microsoft Entra IDによるアイデンティティ管理の完成度、グローバルなコンプライアンス対応——これらは本物の競争力であり、その価値が今まさに数字として結実している。 注目したいのは、「最も賢いAIを作る競争」と「最も多くのエージェントが安全に動くプラットフォームを提供する競争」は別物だという点だ。後者においてMicrosoftには圧倒的な強みがあり、今回の決算はまさにその強みが数字になって現れた結果だと解釈している。 一方でデバイス事業については、もったいないという気持ちがある。SurfaceはWindowsの理想形を体現する役割を担えるはずで、「AI時代のWindowsデバイス」というコンセプトをより前面に打ち出す形で存在感を取り戻せる余地は十分あるはずだ。その実力はあると信じているだけに、低迷が続く現状を惜しく思う。 今後のAzure成長持続性を左右するのは、「AIワークロードがどれだけ企業の本番稼働に広がるか」だ。PoC（概念実証）どまりの案件が実際のビジネスプロセスへ組み込まれていく段階への移行——そこが真の勝負どころだろう。日本企業がその変革をどこで・どのように進めるか、Azureプラットフォームの真価が問われるのはこれからだ。 出典: この記事は Microsoft Q3 2026 Earnings: Cloud & Azure Drive 18% Growth as Xbox & Devices Decline の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのCEO サティア・ナデラ氏が2026年4月、シドニーで開催した自社イベントで、オーストラリアへの大規模投資計画を発表した。総額はA$250億（約2.7兆円）、2029年末までに完了予定という同社史上最大の対オーストラリア投資だ。AzureのAIスーパーコンピューティング基盤とクラウドインフラを大幅に拡充するとともに、AI安全性・人材育成・サイバーセキュリティへの取り組みも同時に発表された。 何に投資するのか 今回の投資の核心は、AzureのAIスーパーコンピューティング基盤の拡充だ。大規模なGPUクラスターを含むデータセンター容量を増強し、オーストラリアおよびアジア太平洋地域の企業・公共機関がローカルでAI推論やモデルトレーニングを実行できる環境を整備する。 注目すべきは、単なるハードウェア増強にとどまらない点だ。AI安全性イニシアチブ・人材育成プログラム・サイバーセキュリティ強化がセットで発表されている。インフラと人材・ガバナンスを同時展開するのは、近年のMicrosoftが得意とするアプローチであり、この構造が企業・政府からの信頼獲得に直結している。 アジア太平洋戦略における位置づけ オーストラリアはAI規制の枠組みが比較的整備されつつあり、米国クラウド企業にとってはアジア太平洋地域の「橋頭堡」になりつつある。データ主権（データが国内に留まることを法的に要求するルール）への要求が世界的に高まる中、オーストラリア現地のAIインフラを持つことは、政府・金融・医療などの規制産業への展開において決定的な優位性をもたらす。 この文脈で見ると、今回の投資はオーストラリア単体の話ではなく、アジア太平洋全体の覇権を見据えた長期的な布石と解釈できる。 実務への影響——日本のIT担当者が今知るべきこと ① オーストラリアとのビジネスに関わる組織へ 金融機関・グローバル企業がAzure上でオーストラリア規制に準拠したAIワークロードを実行しやすくなる。コンプライアンス対応のリードタイムが短縮される可能性があり、現地子会社を持つ日本企業にとっては直接的なメリットになりうる。 ② Azure AIサービスの容量問題が中長期的に緩和 GPU不足によるサービス制限はここ数年、Azure利用者を悩ませてきた。今回のような大規模インフラ増強は、Azure OpenAI Serviceや各種AI APIのリージョン拡張・可用性向上につながる。日本リージョンへの波及効果も期待していい。 ③ データ主権・コンプライアンス設計の参照事例として オーストラリアで構築されるアーキテクチャ——Azure Policyによるリージョン固定のデータ配置制御や、規制産業向けのガバナンス設計——は、日本の金融・医療・公共機関のDX推進にそのまま応用できるユースケースが多い。ホワイトペーパーやケーススタディを積極的に参照する価値がある。 筆者の見解 2兆円超の投資額を「すごい」で終わらせてはもったいない。重要なのは「なぜオーストラリアか」という問いへの答えにある。データ主権、AI規制への対応、政府・公共セクターへの展開——これらの条件が揃う市場に大量の資本と人材をぶつける戦略は、Azureのプラットフォームとしての本質的な強みと完全に一致している。 筆者が長年感じてきた「Azureは、AIそのものより、AIを安全に動かすプラットフォームとして際立って強い」という直感が、今回の発表でさらに裏付けられた気がする。最も賢いモデルを自前で作る競争は熾烈だが、最も多くのエージェントと企業データが安全に動作できる基盤を提供する競争では、Microsoftの優位は当面続くだろう。 ひとつ正直に言うと、Azureの個別サービスをすべて追いかける時代は、もう終わりつつある。大切なのはこの巨大なプラットフォームの上で、自分のビジネスに必要なAIをどう設計・運用するかという力だ。その意味で、今回のような大規模インフラ投資は「選択肢と安心感が広がった」と前向きに受け取っていい。あとは私たちがそれをどう使いこなすかだ。 出典: この記事は Microsoft Commits $18 Billion to Build Australian AI Capacity の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure Data Factory（ADF）と Azure Synapse Analytics を長年運用してきた組織にとって、Microsoft Fabric への移行は「いつかやらないといけない」案件だったはずだ。そこに Microsoft が公式の移行アシスタントをパブリックプレビューとして公開した。計画的な移行を支援する「アセスメントファースト」のアプローチが特徴で、日本の現場でも注目すべきアップデートだ。 移行アシスタントの概要 今回プレビュー公開された移行アシスタントは、ADF および Azure Synapse Analytics のパイプラインを Microsoft Fabric Data Factory へ移行するための公式ツールだ。以下の 3 つの機能を柱としている。 アセスメント機能 移行前に、既存パイプラインの互換性スコア・サポート済みアクティビティの比率・移行準備状況を事前評価できる。いきなり移行を開始して「対応していないアクティビティがあった」という事態を防ぐための仕組みだ。リスクの見える化から始められるのは実運用を考えると大きなポイントになる。 Linked Services の自動変換 ADF の Linked Services を Fabric の「接続（Connections）」形式へ自動変換する機能も含まれる。接続先の定義が大量にある環境では手動での書き換えは現実的でないため、この自動変換は実用上かなり価値がある。 Synapse Spark 成果物の自動移行 Synapse Analytics で作成した Spark ノートブックや Spark Job 定義を、Fabric Data Engineering へ自動移行する機能もプレビュー提供が開始された。ETL だけでなく分析処理を含む Synapse 環境をまるごと Fabric に乗せ換える道筋が、ようやく整ってきた形だ。 なぜ今 Fabric への移行が重要か Microsoft Fabric は、Azure Data Factory・Synapse Analytics・Power BI・Data Lake などのサービスを統合した SaaS 型データプラットフォームだ。個別サービスとして散在していたデータ基盤を一つのガバナンス傘下に収め、ライセンスも Fabric 容量ベースで統合できる。 ...

マイクロソフトは、オンプレミス向けクラウド基盤「Azure Local」を大幅に拡張し、政府機関や規制産業が求める「数千ノード規模のソブリンプライベートクラウド」として本格展開を開始した。データ主権（Digital Sovereignty）の確保が世界的な制度的要件になりつつある中、このアーキテクチャ進化は見逃せない。 16ノードの制約を超えた大規模スケールへ Azure Localは、AzureのクラウドOSをオンプレミス環境で動かすプラットフォームだ。今回の発表で最も重要なのはスケールの上限が事実上撤廃に近い形で拡張された点だ。従来の小規模構成の制約が取り払われ、単一のソブリン境界内で「数千ノード」規模のクラスターを構築できるようになった。 さらに、コンピュートとストレージを独立して展開できる分離型アーキテクチャが新たに導入された。ストレージノードだけを横に拡張したい、GPUクラスターだけを増強したい、という柔軟な構成が可能になり、大規模なAI推論や分析処理をオンプレミスで動かす組織にとってインフラ設計の自由度が大きく広がる。 ソブリンクラウドとは——日本のIT現場での意味 「ソブリンクラウド」とは、データとその処理を特定の地理的・法的管轄内に閉じ込めることを保証するクラウド基盤のことだ。EUのGDPRや各国データローカライゼーション規制の強化を受け、政府・金融・医療・通信など規制業種を中心に需要が急拡大している。 日本においても、マイナンバー関連データ、医療記録、防衛関連システムのように「国内データセンター内で完全に管理しなければならない」ワークロードは多い。Azure Localは切断環境（Disconnected Operations）でも、ポリシー適用・RBAC・監査設定をローカルで維持できる。インターネット接続が保証できない工場、基地、政府施設でも、Azureと同一の運用モデルを維持できるのは実務上の大きなアドバンテージだ。 AT&Tが選んだ理由——「一貫性」こそが核心 世界最大級の通信事業者であるAT&Tが、ミッションクリティカルなインフラの基盤としてAzure Localを採用している。「Azureの運用モデルの一貫性を、自社のインフラ上で実現できることが重要」というコメントは的を射ている。クラウドと同一のオペレーションモデルをオンプレミスで再現できる——この「ハイブリッドの透明性」こそが、複雑な運用環境を持つ大企業が採用を決める核心にある。 Forrester Wave™ ソブリンクラウドプラットフォーム Q2 2026でリーダー評価を獲得したことも、マイクロソフトのこの領域への本気度を裏付けている。 日本のエンジニア・IT管理者への実務ポイント これまで「Azureを使いたいが、データを外部に出せない」という制約で導入をためらっていた組織にとって、今回の拡張は具体的な選択肢として浮上する。 明日から使える視点を整理する： 既存のAzureスキルがそのまま生きる：Azure PortalやAzure Arc経由の管理はパブリッククラウドと同一の操作体験。運用担当者の学習コストが最小化される オンプレでのAI推論が現実的な選択肢に：高性能GPUノードを組み込んだ構成が可能になり、LLMの社内推論やリアルタイム画像解析を完全にオンプレ環境で稼働させられる ゼロトラスト設計との相性：Just-In-Timeアクセス管理やAzure Arcによるポリシー統制をオンプレ環境に展開することで、特権アカウント管理を含むゼロトラスト型の統制アーキテクチャが実現できる 切断環境での安定運用：工場や政府施設など、インターネット接続が断続的または皆無の環境でも、ローカルでポリシー適用と監査ログを維持できる 筆者の見解 ソブリンクラウドは「クラウド移行を断念した組織の妥協案」ではなく、「データ主権という本質的要件に対するアーキテクチャ的回答」だと見ている。この文脈でAzure Localの今回の進化を評価すると、マイクロソフトが長年積み上げてきたプラットフォーム設計の強みが最も発揮されるフィールドに打ち込んできた、という印象だ。 日本の行政機関やエンタープライズにとって、「国産クラウド」という名目で実態は凡庸なシステムに高いコストを払い続けているケースは少なくない。Azureの運用モデルをそのままオンプレで実現できるこのアーキテクチャは、そうした環境からの移行先として説得力がある。 一点、注文をつけるとすれば、日本市場向けの具体的な実績と性能ベンチマークをもっと積極的に出してほしい。AT&Tの事例は力強いが、日本の意思決定者が判断材料にできる国内導入事例や具体的なコストモデルの整備がまだ薄い。技術的なポテンシャルは十分にあるのだから、それを日本のユーザーが検証できる形で透明性を持って開示することが、次のステップとして重要だと思う。 出典: この記事は Microsoft Sovereign Private Cloud scales to thousands of nodes with Azure Local の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PostgreSQLの接続管理問題は、システム規模が大きくなるほど深刻になる。Azure Database for PostgreSQL Flexible Serverに組み込まれている接続プーラー PgBouncer が 1.25.1 に更新され、一般提供（GA）となった。高並列接続環境でのパフォーマンス向上と安定性の改善が主なポイントだ。 PostgreSQLの「接続爆発」問題とは PostgreSQLは1接続ごとにプロセスを生成する設計になっている。シンプルで堅牢なアーキテクチャだが、同時接続数が増えるとメモリ消費とコンテキストスイッチのコストが急増するという特性がある。 Webアプリケーションやマイクロサービス環境では、アプリケーションサーバーが数十〜数百のワーカープロセスを持ち、それぞれがデータベース接続を確立しようとする。単純計算で100ワーカー × 10サービスインスタンス = 1,000接続が同時に張られることもある。これがPostgreSQLのmax_connectionsに近づくと、クエリのレイテンシ悪化や接続エラーが頻発し始める。 コネクションプーラーはこの問題を解決するミドルウェアだ。アプリとデータベースの間に立ち、アプリ側から多数の接続を受け付けながら、データベース側へは実際に必要な数だけの接続を維持する。 PgBouncer 1.25.1 の主な改善点 PgBouncer 1.25.1の核心は、高並列接続環境でのパフォーマンスと安定性の向上とコネクションプーリングのオーバーヘッド削減にある。 接続処理の効率化: 大量の短命な接続が頻繁に発生するワークロード（バッチ処理、APIゲートウェイ経由のアクセスなど）での応答性が向上 高負荷時の安定性: エッジケースで発生していた問題が修正され、長時間稼働での信頼性が向上 GAステータス移行: プレビューから正式提供に移行し、SLAの対象となる Azure Database for PostgreSQL Flexible ServerではPgBouncerは組み込み機能として提供されており、別途インフラを用意する必要がない。Flexible Serverの設定画面から有効化するだけで利用できる点は大きな利点だ。 実務への影響 有効化の判断基準 すべてのシステムがPgBouncerを必要とするわけではない。以下の条件に当てはまる場合は導入を検討すべきだ： max_connectionsに近い値で接続数が推移している 接続確立のレイテンシがクエリ実行時間の無視できない割合を占めている コンテナやサーバーレス関数からPostgreSQLに接続している マイクロサービスで多数のサービスインスタンスが同一DBに接続している モード選択の注意点 PgBouncerを有効化する際に特に重要なのがトランザクションモードとセッションモードの選択だ。 モード 特徴 向いているケース セッションモード 接続をセッション全体で保持 pg_tempテーブルやSETを多用する場合 トランザクションモード トランザクション単位で接続を共有 短命なクエリが大量発生する場合 ステートメントモード ステートメント単位 限定的なユースケース トランザクションモードは最もプーリング効率が高いが、LISTEN/NOTIFY、PREPARE/EXECUTE、SETコマンドなど一部の機能が制限される。既存アプリをそのまま移行する際は互換性の確認が必須だ。 推奨設定アプローチ pool_sizeとmax_client_connの設定は環境によって異なるが、初期値としてPostgreSQL側のmax_connectionsの70〜80%をプールサイズの上限として設定し、Azure Monitorの接続数メトリクスを確認しながら調整するアプローチが安全だ。 筆者の見解 コネクションプーリングは「地味だが効果抜群」な最適化の典型例だ。アプリケーション側のコード変更なしに、インフラ層の設定変更だけでスループットが大きく改善するケースが多い。 Azure Database for PostgreSQL Flexible ServerがこれをGAの組み込み機能として提供している点は素直に評価できる。自前でPgBouncerをサイドカーやプロキシとして運用するには、バージョン管理・監視・フェイルオーバー設計など相当な運用コストがかかる。マネージドサービスとして提供されることで、「動かす仕組みを構築する」ことから「どう設計して使うか」に集中できるようになる。 日本のエンタープライズ環境では、「PostgreSQLを本番で使う」という判断自体がいまだ社内承認のハードルになっているケースも少なくない。しかしフルマネージドでSLA付きのサービスがGAとなり、接続管理という運用上の大きな課題も組み込みで解決できるようになった今、レガシーなRDBMSに縛られ続ける合理的な理由はどんどん薄くなっている。 ...

AzureのマネージドPostgreSQLサービス「Azure Database for PostgreSQL Flexible Server」において、Premium SSD v2が一般提供（GA）に到達しました。対応リージョンは48に広がり、これまでとは根本的に異なるストレージ設計が正式に利用可能となっています。 Premium SSD v2が変えること これまでのAzureストレージでは、IOPSを増やすためにはディスクサイズを拡張するか、より上位のSKUへ移行するしかありませんでした。Premium SSD v2はこの制約を取り払い、ストレージ容量・IOPS・スループットを互いに独立してスケールできる設計になっています。 主な仕様は以下の通りです。 項目 最大値 IOPS 80,000 IOPS スループット 1,200 MiB/s ストレージ容量 64 TiB 従来のPremium SSDでは、1 TiBのディスクで得られるIOPSはおよそ5,000程度でした。それ以上が必要なら容量を増やすかUltra Diskへ移行するしかなく、「容量は十分なのにIOPSのためだけに費用を払う」という非効率な状況が生まれがちでした。Premium SSD v2では、1 TiBのままで20,000 IOPSを設定するといった組み合わせが可能になります。 どんなワークロードに有効か Microsoftが特に推奨しているのは次のケースです。 OLTP（オンライントランザクション処理）：小さなトランザクションが大量に並列発生するシステム。ECサイトの注文処理、金融系のリアルタイム処理など SaaSアプリケーション：多数のテナントが同時アクセスするマルチテナント構成 高並列ワークロード：多数のコネクションが同時に読み書きを行うシステム 逆に、バッチ処理中心や読み取り比率が非常に高いシステムでは、従来のPremium SSDでも十分な場合があります。ワークロードの特性をまず把握することが先決です。 実務への影響 コスト設計の見直し機会 日本のシステムでよく見られるのが「念のため大きめのディスクを確保する」という設計です。これはコスト過剰を生みやすいパターンでした。Premium SSD v2では容量とIOPSを切り離せるため、実際の要件に合わせた細かい最適化が可能になります。 移行は段階的に 既存のFlexible Serverインスタンスであれば、ダウンタイムを最小限に抑えた移行手順が用意されています。まず開発・ステージング環境で試し、pg_stat_bgwriterやpg_stat_ioなどでI/Oパターンを計測してから本番移行を検討するのが現実的です。 監視設計も合わせて見直す IOPSをプロビジョニングで制御できるということは、上限設定のミスが性能問題に直結するリスクも意味します。Azure Monitorでdisk_iops_consumed_percentageなどのメトリクスをきちんと監視し、閾値アラートを設定しておくことを強くお勧めします。良い武器も使い方を誤ると逆効果になります。 筆者の見解 Azureのデータベースサービスは、派手さはないものの着実に進化を続けています。Premium SSD v2のGAは地味な発表に見えますが、PostgreSQLで大規模な業務システムを動かしているエンジニアにとっては「ようやく来た」と感じる機能のひとつでしょう。 特に評価したいのは「容量と性能の分離」というコンセプトです。クラウドの強みは柔軟なスケールにあるはずなのに、ストレージだけが「容量を増やさないとIOPSが増やせない」という制約で縛られていたのは、長年の設計上の課題でした。この解決は、エンジニアが本来やりたかった「要件に応じた最適化」を現実的な選択肢にするという意味で、本質的な改善です。 一方で、こうした細かいパラメータを適切に設定・監視するには相応の知識が必要です。「とりあえずv2に変えれば速くなる」というわけではなく、ワークロードの特性をきちんと把握した上で使わないとコストが無駄になります。プラットフォームが進化すればするほど、使う側の設計力も問われる——そのことは忘れないようにしたいところです。 Azureのデータサービスが持つポテンシャルは本物です。あとは、こういった良い機能をユーザーが迷わず使いこなせるよう、ドキュメントやベストプラクティスの充実に引き続き力を入れてほしいところ。良いものを作っても届かなければもったいない——そこへの期待は変わりません。 出典: この記事は Premium SSD v2 Is Now Generally Available for Azure Database for PostgreSQL の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...