Azure

AIエージェントが実際のビジネスデータを扱う「本番環境」に踏み込み始めると、デモ段階では見えなかった問題が一気に顕在化する。「誰でも全部見える」状態でよかったプロトタイプが、リリース直前になって「データ境界をどう守るか」という根本的な問いを突きつけてくる。 CurityとMicrosoftがAzure SDK Blogで公開した新しいazdテンプレートは、まさにその問いに正面から答える試みだ。AIエージェントへの最小権限（Least Privilege）アクセスの実装パターンを、すぐ試せる形で提供している。 問題の本質：エージェントは「予測できない」クライアントだ 従来のクライアントアプリはAPIを決まった手順で呼ぶ。コードを読めば何をするか分かる。しかしAIエージェントは違う。自然言語を解釈して、何を呼ぶかを自分で決める。賢いが、予測不能でもある。 さらにプロンプトインジェクション——悪意あるユーザーが入力を細工してエージェントの動作を乗っ取る攻撃——のリスクも現実にある。エージェント側でいくら「正しい判断」をしようとしても、それだけでは足りない。APIレイヤーで「このトークンではここまでしか見えない」という制約を設けなければ、AIの不完全さや悪用に対して無防備のままだ。 テンプレートの核心：短命トークンと2段階のトークン交換 このテンプレートのポイントは、OAuth 2.0の短命アクセストークンによる認可だ。エージェントはAPIへの恒久的な権限を持たない。必要なときだけ、必要な範囲に絞ったトークンを取得して使う。 注目すべきは2段階のトークン交換設計だ。 第1交換: ユーザーの初期トークンのスコープを絞り込み、不透明トークン（Opaque Token）からJWT（JSON Web Token）に変換する 第2交換: エージェントのIDを付加し、MCPサーバー向けの新しいaudienceに変換する 最終的にPortfolio MCPサーバーに届くトークンには、scope: stocks/read（読み取り専用）、customer_id: 178（Entra IDの属性から取得）、region: USA（参照可能な株式の地域制限）、client_type: ai-agentが含まれる。APIはこれらのクレームを見て、「このリクエストは誰のためのものか・何が許可されているか」を判断できる。エージェントがどんな指示を受けたかは関係ない。 テンプレートの構成 インフラとしては以下が含まれる。 バックエンドエージェント: Microsoft Foundry上でC#実装（Microsoft A2A・MCP SDK使用） MCPサーバー: サンプルポートフォリオAPIを公開 認可サーバー: Curity Identity Server（ユーザー認証はMicrosoft Entra IDと連携） ゲートウェイ: 外部・内部APIゲートウェイでトークン交換と監査ログを担当 IaC: Bicepで完全自動プロビジョニング（Container Apps、Azure AI Foundry、Key Vault、Azure SQL Database等） azd up数コマンドでAzureサブスクリプション上に全体が動く状態になる。 実務への影響 日本のエンジニアが今すぐ取り組めるヒント： まずこのテンプレートをそのまま動かし、トークンの内容がどう変わるかを自分の目で確認してほしい。JWTデコーダーで中身を覗きながら「誰が・何のスコープで・どのAPIを呼べるか」の流れを追うことで、設計の全体像がつかめる。 次に、既存のAIエージェント実装を振り返ってみる価値がある。エージェントに渡しているトークンに有効期限は設定されているか？スコープは最小化されているか？ 「動いているからOK」は安全の証明にならない。特権アカウントやサービスプリンシパルに権限を無期限で与えている構成は、早急に見直すべきだ。 Microsoft Entra IDを使っている環境では、ユーザー属性（部署・地域・ロール等）をトークンのクレームとして活用するカスタムクレームの設定も検討に値する。属性ベースのアクセス制御（ABAC）は、エージェント時代のきめ細かいデータ境界を実現する重要な武器になる。 筆者の見解 AIエージェントがNon-Human Identity（NHI）として組織内で動き始める今、「誰がAPIを呼んでいるか」だけでなく「何のためにどこまで呼べるか」を制御する仕組みが不可欠になっている。 このテンプレートが示す「短命トークン＋2段階交換」のパターンは、ゼロトラストの原則をエージェントに忠実に適用したものだ。常時アクセス権を与えず、必要なときだけ必要なスコープで動かす——これはJust-In-Timeアクセスの考え方そのものであり、特権アカウント管理の世界ではすでに常識になっている。AIエージェントという新しいアクターにも、この原則を妥協なく貫く必要がある。 Microsoft Entra IDをエージェントの「管制塔」として使い、その上でサードパーティの認可サーバーと組み合わせるアーキテクチャは、Azureプラットフォームの強みを素直に活かした設計だ。この方向性は正しいと思う。 あとは、このパターンがテンプレートで終わらず、公式ドキュメントやベストプラクティスとして広く普及するかどうかが鍵だ。設計パターンをいかに「開発者が自然と選ぶ道」にするかが、セキュアなAIエージェント普及の分水嶺になる。 出典: この記事は Least privilege AI agents: A new azd template from Curity and Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年5月7日、MicrosoftはAzure AI FoundryのM365公開エージェントに深刻な脆弱性（CVE-2026-35435）が存在することを公開した。CVSSスコアは8.6（High）で、ネットワーク経由・認証不要・ユーザー操作不要での権限昇格が可能というシナリオだ。エンタープライズ環境でAIエージェントの活用を進めている組織は、今すぐ対応を開始すべき内容である。 脆弱性の技術的詳細 CVE-2026-35435の根本原因は CWE-284（不適切なアクセス制御） だ。CVSSベクターを読み解くと、この脆弱性の深刻さがよく見えてくる。 評価項目 値 意味 AV（攻撃経路） N（ネットワーク） インターネット越しに攻撃可能 AC（攻撃複雑性） L（低） 特別なスキルや環境が不要 PR（必要な権限） N（不要） 事前認証が不要 UI（ユーザー操作） N（不要） 自動化攻撃が成立する S（スコープ） C（変更あり） 影響がエージェント境界を越える C（機密性への影響） H（高） 情報漏洩リスクが高い 特に注目すべきは「スコープ変更あり（S:C）」という評価だ。これはエージェントのコンテキストを踏み台として、テナント内のより広いリソースへのアクセスが可能になることを意味する。M365のデータコネクタや業務データと連携したエージェントが侵害された場合、情報漏洩の範囲は想定をはるかに超える可能性がある。 影響を受けやすい環境 特に注意が必要なのは次のような構成だ。 公開スコープが広いエージェント: テナント外部や社内広域にアクセスを開放した公開エージェントは直接の攻撃対象になりやすい。匿名アクセスを許可している構成は特に危険だ。 機密データコネクタを接続しているエージェント: SharePoint、Exchange、Azure Storageなどと連携するエージェントは、侵害された際の影響範囲が業務データ全体に及ぶ可能性がある。 複数チームが共有するAIエージェントプラットフォーム: 共有コネクタや共有権限セットを持つ環境では、一点突破後の横移動リスクが高まる。 今すぐ取るべき対策 短期（即時対応） Microsoftのパッチ情報を継続監視する: MSRCのアドバイザリページ（CVE-2026-35435）を定期確認し、パッチが提供され次第、最優先で適用する 公開エージェントの一時制限を検討する: 広く公開されたエージェントについて、セキュリティレビュー完了まで公開スコープを絞ることを検討する エージェント操作の監査ログを確認する: 予期しない権限昇格の痕跡や、エージェントAPIへの不審なアクセスがないかをログで確認する。新規IPやサービスプリンシパルからのAPI呼び出し急増も要注意だ 中期（設計の見直し） エージェントコネクタへの最小権限適用: エージェントが本当に必要な権限だけを付与し、過剰な権限セットを排除する 条件付きアクセスの強化: エージェント管理操作に対してIP制限・デバイスコンプライアンスを組み合わせた条件付きアクセスを設定する Just-In-Timeアクセスの検討: エージェントの特権操作は常時付与ではなく、必要時だけ有効化する設計へ移行する 実務への影響 日本企業でも、Copilot StudioやAzure AI Foundryを活用してM365エージェントを構築・公開するケースが急増している。特に業務自動化の文脈でPower AutomateやAzureのデータコネクタと組み合わせた構成は多い。 こうした組織では、エージェントはもはや「ツール」ではなく「非人間アイデンティティ（NHI: Non-Human Identity）」として管理しなければならないという現実と向き合う必要がある。エージェントが持つ権限は、人間のアカウントと同様に—あるいはそれ以上に—厳密な管理が求められる時代になっている。 セキュリティ担当者はエージェントの権限棚卸しを今すぐ実施し、「そのエージェントに本当にこの権限が必要か」を一つひとつ確認してほしい。 筆者の見解 AIエージェントが業務システムの一部として定着しつつある今、こうした脆弱性は「AIの問題」ではなく「アイデンティティ管理とアクセス制御の問題」として捉え直す必要があると感じている。 ゼロトラストの本質は「信頼しない、常に確認する」だが、多くの組織ではエージェントへの権限付与がまだ人間アカウントと同じ温度感で扱われていない。「起動時にAdmin権限を持たせておけば楽」という発想は、人間のアカウントで言えば全員にグローバル管理者を付与するようなものだ。 Azure AI FoundryとCopilot Studioの基盤としての価値は揺るぎない。だからこそ、エージェント展開の際には「最小権限」「Just-In-Time」「スコープ管理」を設計の第一原則として組み込んでほしい。MicrosoftがMicrosoft Entra IDをエージェント管理の中核に据えている方向性は長期的に正しく、その仕組みを最大限に活用することが今後の鍵になると確信している。 ...

AIエージェントが当たり前のように自律動作する「エージェント時代」に突入した今、インターネット上のセキュリティのあり方が根本から問い直されている。Googleは2026年4月のGoogle Cloud Nextにおいて、reCAPTCHAの次世代プラットフォームとして「Google Cloud Fraud Defense」を発表した。ボットによる自動操作対策だけにとどまらず、AIエージェントのトラフィック管理・分類・制御を一元化する、大きな方向転換だ。 AIエージェントの台頭が生んだ新たな穴 これまでWebセキュリティの主要な脅威は、悪意ある「ボット」が人間を装って攻撃してくるものだった。reCAPTCHAはまさにその文脈——人間とボットを区別するための技術として長年機能してきた。 しかし状況が変わった。EC決済、問い合わせフォーム、アカウント操作を「AIエージェント」が代行するシナリオが急増している。エージェントは「人間でもなく、従来のボットでもない」第3の存在として登場し、既存のセキュリティモデルに空白地帯を生んでいる。悪意あるエージェントによるAI駆動の合成IDフロード、大規模なアカウント乗っ取りといった脅威が現実のものとなりつつあり、「これは何者か？」を動的に判別する新しい仕組みが必要になってきた。 Google Cloud Fraud Defenseの主な機能 エージェントアクティビティの可視化 新ダッシュボードにより、サイトへのアクセスがどの種類のトラフィックか（通常ユーザー・ボット・AIエージェント）を分類・分析できる。業界標準「Web Bot Auth」や「SPIFFE」といったアイデンティティ仕様と統合し、エージェントと人間のアイデンティティをリンクして信頼度・リスクスコアを算出する設計だ。 エージェントポリシーエンジン リスクスコア・自動化の種類・エージェントのアイデンティティなど複数の条件に基づいて、特定エージェントの通過・遮断をきめ細かく制御できる。カスタマージャーニー全体の各ステージで判断を挿し込める点が、従来のシングルポイント型チェックと大きく異なる。 AI耐性チャレンジ（QRコード認証） 怪しいエージェントアクティビティを検知した際、人間の介在を要求するQRコードベースのチャレンジを発行する。既存のテキスト・画像チャレンジはAIに突破されやすくなっているため、このQRコード方式は「AIに攻撃を経済的に割に合わなくさせる」設計を意識したものだ。 既存reCAPTCHAユーザーへの影響はゼロ reCAPTCHAはFraud Defenseの「ボット対策コア」として引き続き機能し続ける。既存のreCAPTCHAユーザーは自動的にFraud Defenseの利用者に移行済みとなり、追加設定・移行作業・料金変更は一切ない。 実務への影響——日本のエンジニア・IT管理者へ 国内でもEC・金融・SaaS系サービスでreCAPTCHAを導入済みの組織は多い。今回の変更は追加作業ゼロで新機能へアクセスできるため、まずダッシュボードを確認してエージェントトラフィックの実態を把握するところから始めたい。 特に以下のシナリオでは早期対応の検討価値がある： ECサイト・予約システム: AIエージェントによる在庫先読みや大量購入リスクへの対策 APIエンドポイントを外部公開している企業: エージェントによる過剰アクセスの可視化・制御 SaaS/BtoBプラットフォーム: パートナー企業のエージェントに「信頼できる身分証明」を発行するアーキテクチャの検討 SPIFFEなどのアイデンティティ標準の採用状況を今のうちに確認しておくと、将来的なエージェント間信頼モデルの構築がスムーズになる。 筆者の見解 エージェントの台頭によってNHI（Non-Human Identity）の管理がセキュリティの核心になりつつあるというのは、ここ数年で最も重要なパラダイムシフトの一つだと感じている。 人間の代わりにAIエージェントが業務を実行する世界では、「そのエージェントは誰の指示で動いているのか」「本当に信頼できるエージェントなのか」という問いに、システム側が自動的に答えられなければならない。これはちょうど特権アクセス管理（PAM）の世界でJust-In-Time（JIT）アクセスが重要視されるのと同じ文脈だ。常時アクセス権を付与したまま放置するのではなく、エージェントの行動ごとに動的に信頼を評価・制御する——その思想がWebセキュリティ全体に波及してきた。 「エージェントを信頼する仕組みが整うまで業務自動化は進められない」という現場の声はよく聞く。NHI管理の整備こそが、結果として人間の業務ボトルネックを解消する鍵になる。業界全体として、エージェントのアイデンティティ・意図・権限を標準化する動きがさらに加速することを期待している。あらゆるプラットフォームがこの課題と正面から向き合うべき時が来た。 出典: この記事は Google Cloud fraud defense, the next evolution of reCAPTCHA の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Build 2026が6月2〜3日にサンフランシスコとオンラインで開催される。今回、事前に公開された発表プレビューページでは、AKS（Azure Kubernetes Service）、Azure Container Apps、そしてAzure AI Foundryの大型アップデートが予告されている。特に注目すべきは「エージェントAIの本番運用」というテーマだ。実験や検証の段階を超え、本番環境でAIエージェントを動かすための基盤整備がBuild 2026の核心にある。 AKS・Azure Container Apps：コンテナ運用の次フェーズへ AKSとAzure Container Appsの強化は、エージェントAIの実運用基盤として直結している。AIエージェントは単体で動くものではなく、複数のマイクロサービスやモデルが協調する分散アーキテクチャで成立する。KubernetesベースのAKSが担うスケーリングと信頼性の確保、そしてよりサーバーレスに近いContainer Appsのユーザビリティ向上は、「AIが本番で動く」ために不可欠な要素だ。 従来のコンテナ運用の課題は「作れる人と運用できる人が異なる」ことにあった。今回のアップデートでこのギャップが埋まれば、開発チームが自律的にエージェントをデプロイ・運用できる環境に近づく。 Azure AI Foundry：エージェントAI開発の司令塔 最大の注目点はAzure AI Foundryの強化だ。AI Foundryは単なる「AIモデルをデプロイする場所」ではなく、モデルの選択・評価・監視・ガバナンスまでをワンプラットフォームで管理するレイヤーとして進化を続けている。 Semantic KernelとAutoGenとの統合が深まることで、複数エージェントが協調して動作するマルチエージェントシステムを、Azure基盤の上で安全に構築できるようになる。 Semantic Kernel：Microsoftが推進するオーケストレーションSDK。C#・Python・Javaに対応し、エージェントの行動計画と実行を抽象化する AutoGen：Microsoftリサーチ発のマルチエージェントフレームワーク。複数のAIエージェントが会話しながら問題を解くアーキテクチャを実現する 実務への影響：日本のエンジニア・IT管理者に何が変わるか エージェントAI導入の「実験フェーズ」が終わる 日本企業の多くは現在「生成AIの実験」フェーズにある。Build 2026の発表は、その次のフェーズ——本番運用・ガバナンス・スケール——への移行を後押しするものになる。 特にAI Foundryの強化は、「どのモデルを使うか」「どうガバナンスするか」という組織的な意思決定を支援する。個人がバラバラにAIツールを使う状況から、組織として管理された形でAIを活用する体制へのシフトを、Azureが主導する形だ。 NHI（Non-Human Identity）管理の重要性が急増する エージェントAIが本番で動くということは、人間の代わりにシステムにアクセスするIDが急増するということだ。サービスプリンシパル、マネージドID、ワークロードIDなど、Non-Human Identityの管理はエージェントAI運用の根幹となる。 Microsoft Entra IDとの統合がここで生きてくる。エージェントが「どのリソースに」「どの範囲で」アクセスできるかを厳密に制御する仕組みは、セキュリティと業務効率の両立に直結する。NHI管理ができていない組織は、エージェントを増やすほどリスクが膨らむ構造になることを認識しておきたい。 明日から使える実践アクション Semantic Kernelの先行学習：Build前に公式ドキュメントとサンプルで基礎を固めておく。発表後に差がつく AI Foundryの評価機能を試す：モデルの選択は「使ってみた印象」ではなく、ユースケース別の評価スコアで判断する習慣を今から Entra IDのマネージドID設計を見直す：エージェント導入前に、既存のサービスプリンシパル管理の棚卸しを済ませておく 筆者の見解 Microsoft Buildは毎年「言っていたビジョンが現実になった」という確認の場でもある。エージェントAI、Semantic Kernel、AI Foundry——これらは1〜2年前から繰り返し語られてきた。今年のBuildでその完成形が見えるとすれば、それはMicrosoftが得意とする「プラットフォームとしての総合力」が発揮される瞬間になる。 個別のAIモデルの性能を競うゲームでは、Microsoftは唯一最前線のプレイヤーではない。だが筆者が注目するのは、「最も多くのエージェントが安全に動けるプラットフォームを提供する」という競争軸だ。Entra IDを中核に据えたアーキテクチャ、AI Foundryによるガバナンス基盤——この方向性は長期的に正しい。 Microsoftにはこの競争を正面から勝ちにいける力がある。Build 2026がその転換点になりうるなら、発表を正面から受け止めて実際に手を動かして評価したい。口だけのビジョン発表に終わらないことを、一利用者として期待している。 出典: この記事は Microsoft Build 2026 – Azure Announcements Preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、欧州全域にわたるAzureインフラの大規模拡張計画を正式に発表した。オーストリア、ベルギー、デンマーク（2リージョン）、ギリシャ、フィンランドへの新リージョン展開に加え、スウェーデンではフリーエアクーリングや雨水収集を採用した持続可能なデータセンター設計を採用している。クラウドとAI需要の爆発的な増大に対し、Microsoftが欧州市場への本気度を示した動きとして注目に値する。 欧州で何が起きているか 公共部門から民間企業まで、欧州全域でAzureの採用が加速している。英国のManchester City CouncilはMicrosoft 365 Copilotで行政業務を効率化し、スウェーデンのインリバー（inriver）はMicrosoft Foundryを活用して製品情報管理を革新している。この動きを受け、MicrosoftはAzureのグローバルインフラを80以上のデータセンターリージョン（34カ国）まで拡大。特に欧州では今会計年度において、以下の国・地域でキャパシティを大幅に増強している。 オーストリア ベルギー デンマーク（2リージョン展開） ギリシャ フィンランド サステナビリティへの具体的な取り組み スウェーデンのデータセンターでは、単なる拡張にとどまらない取り組みが始まっている。フリーエアクーリング（外気を直接活用した冷却方式）、雨水収集システム、再生可能ディーゼルバックアップ電源に加え、エネルギー大手バッテンフォール（Vattenfall）社との毎日の再生可能エネルギーマッチングパートナーシップを締結している。 クラウドのエネルギー消費が世界的に問題視される中、「どこに置くか」だけでなく「どう動かすか」にまで踏み込んでいる点は、エンタープライズのサステナビリティ要件にも直接応える姿勢だ。 ソブリンクラウドとデータ主権 欧州特有の規制要件に対応する「ソブリンクラウド（Sovereign Cloud）」の展開も加速している。EU Data Boundary、Microsoft Sovereign Cloudを組み合わせることで、「データがどこに保存・処理されるかを完全に制御しながら、最先端のAI機能へのアクセスは失わない」という構成を提供する。GDPRを筆頭とする欧州の厳格なデータ保護規制の文脈では、このソブリン構成の選択肢が実質的な調達条件になっている組織も少なくない。 実務への影響——日本のエンジニア・IT管理者にとっての意味 欧州向けの発表ではあるが、日本のIT現場にも示唆は多い。 データ主権の議論は日本でも他人事ではない。 改正個人情報保護法の越境移転ルール、政府情報システムのセキュリティ基準（ISMAP）など、「データをどのリージョンに置くか」は日本でもエンタープライズ案件の決め手になりつつある。Azureのリージョン拡張は、グローバルに展開する日本企業にとって選択肢の拡大を意味する。 Microsoft Foundryを活用したAI基盤設計への参考事例が増える。 欧州でinriverやSandvikがFoundryを活用している事例は、日本企業が同様のユースケースを検討する際の先行事例となる。AIワークロードをAzure上でどう構成するかの答えが、実際の企業事例から見えてくる。 サステナビリティ指標がクラウド選定の評価軸に。 ESG開示が義務化される方向で進む日本企業にとって、データセンターの電力源・冷却方式まで透明性を持つAzureの姿勢は、調達判断の根拠として活用しやすい。 筆者の見解 Azureのプラットフォームとしての信頼性は、これだけの継続投資によって証明され続けている。80以上のリージョン、各国の規制に対応したソブリン構成、サステナビリティへの具体的コミットメント——この規模でインフラを提供できるプレイヤーは世界でも限られる。 今回の発表で個人的に注目しているのは、Microsoft Foundryの言及が欧州顧客の事例に並んで登場していることだ。Azure上でどのAIモデルを活用するかという選択の幅が広がる方向性は、長期的に見て正しい戦略だと考えている。インフラの信頼性と、その上で動くAIの柔軟な選択——この組み合わせがMicrosoftの強みになっていくはずだ。 ただ、投資発表と実際のサービス品質の間にはタイムラグがある。「ここに投資している」という宣言と「実際にそこでAIワークロードが快適に動く」は別の話だ。特にAIインフラは需要が読めないため、過負荷によるパフォーマンス劣化のリスクは常に存在する。キャパシティ拡張のペースが顧客の要求に追いついているかどうか、実際の利用者視点での評価も継続して追っていきたい。 Azureが持つ「最大多数のエージェントが安全に動くプラットフォーム」という競争軸で先頭を走り続けることへの期待は変わらない。欧州でのリージョン拡張が、日本を含むアジア太平洋地域の次の展開にもつながることを楽しみにしている。 出典: この記事は Scaling cloud and AI: Microsoft Azure’s commitment to Europe’s digital future の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azureのネットワークスタックがまたひとつエンタープライズグレードへと近づいた。MicrosoftはStandard V2 NAT GatewayおよびStandard V2 パブリックIPのパブリックプレビュー開始を発表した。特に注目すべきは、Azure Kubernetes Service（AKS）のマネージドアウトバウンド手段として構成可能になったという点だ。大規模ワークロードやミッションクリティカルなサービスをKubernetes上で運用している組織にとって、見逃せないアップデートである。 Standard V2で何が変わったのか ゾーン冗長が「デフォルト有効」に これまでのStandard NAT Gatewayは、単一のアベイラビリティゾーンに紐付けられる構成が基本だった。Standard V2ではゾーン冗長（Zone-Redundant）が標準で有効となっており、ゾーン障害が発生しても自動的にフェイルオーバーし、サービス継続性が保たれる。ゾーン冗長を後付けで設定する必要がなくなるため、設計ミスによる単一障害点の作り込みリスクが大きく下がる。 スループット・処理能力の大幅向上 最大帯域幅：100 Gbps パケット処理能力：毎秒1,000万パケット（10 Mpps） ワーカーノードが数百〜数千に及ぶような大規模クラスタでも、アウトバウンド接続がボトルネックになりにくくなった。これはエンタープライズ級のバースト処理にも十分耐えられるスペックだ。 IPv4/IPv6デュアルスタック対応 Standard V2パブリックIPはIPv6にも対応しており、デュアルスタック構成でのクラスタ運用が可能になった。今後のIPv6移行を見据えたインフラ設計においても有用な選択肢となる。 AKSとの統合：マネージドアウトバウンド設定として利用可能に 今回の核心は、AKSのマネージドアウトバウンド設定としてStandard V2 NAT Gatewayが選択可能になったことだ。 これまでAKSでNAT Gatewayを使う場合、ユーザーがマニュアルでリソースを作成・紐付けする「ユーザー定義ルート（UDR）」方式か、従来のStandard NAT Gatewayを使う方式に限られていた。Standard V2が選択肢に加わることで、Azureプラットフォームとしての信頼性保証の範囲が広がり、運用負荷の軽減にもつながる。 Kubernetesクラスタのアウトバウンド設計は、セキュリティポリシーの実施やコスト最適化においても重要な位置を占める。特定IPレンジへの制限や外部サービスへの接続元IP固定が必要なケースでNAT Gatewayは欠かせないが、従来はゾーン障害時の耐障害性設計が別途必要だった。Standard V2ではその課題がプラットフォーム側で解決される。 実務への影響：日本のエンジニア・IT管理者にとっての意味 今すぐ評価を始めるべきシナリオ： 本番AKSクラスタの耐障害性強化：ゾーン冗長がデフォルト有効のため、可用性要件が高いシステムへの適用がシンプルになった。既存クラスタのアウトバウンド構成を見直す絶好のタイミングだ。 大規模マイクロサービス基盤の帯域問題解消：数百のサービスが常時外部APIに接続するような構成では、従来のNAT Gatewayがボトルネックになるケースがあった。100Gbps・10Mppsのスペックがあれば、大半のエンタープライズ構成でアウトバウンド帯域が制約要因になることはほぼ考えにくくなる。 IPv6移行のためのインフラ準備：日本国内でも政府・通信キャリアを中心にIPv6対応が進んでいる。デュアルスタック対応のStandard V2パブリックIPを今から検証しておくことで、将来的な移行コストを下げられる。 注意点： パブリックプレビュー段階のため、本番環境への即時適用は慎重に。SLAの適用範囲や既存ネットワーク構成との互換性を必ず確認した上で、検証環境から試すことを推奨する。 筆者の見解 Azureのネットワーキングレイヤーは、ここ数年で着実に「設計ミスの余地を減らす」方向へ進化している。ゾーン冗長がオプションではなくデフォルトになるのは、「知っている人だけが正しく設定できる」から「何もしなくても正しい構成になる」への転換であり、これは非常に正しい方向性だと思っている。 AKSを中心としたコンテナ基盤は、もはや「先進的な組織が試している技術」ではなく、エンタープライズのメインストリームだ。そのプラットフォームとしての信頼性を底上げするための投資として、今回のStandard V2は素直に評価できる。 ひとつ期待を込めて言わせてもらうと、こうした重要なインフラアップデートがパブリックプレビューとして提供されても、多くの日本企業では実際に試用する組織が限られているのが現状だ。「GAされてから評価する」というスタンスは理解できるが、プレビュー段階からフィードバックを出せる組織が最終的に最も恩恵を受ける。プレビュー参加はコストではなく投資として捉えてほしい。大規模クラスタ運用を担うエンジニアには、ぜひ積極的に試してみることを勧めたい。 出典: この記事は Announcing the public preview of StandardV2 NAT Gateway and StandardV2 public IPs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、Azure上で提供する旧世代VMインスタンス17シリーズについて、2026年7月1日以降の新規予約受付を停止すると発表した。そのうち13シリーズは2028年に完全廃止となる予定だ。2010年代に登場した古いIntel CPUで動作するこれらのVMは、現行世代への移行が求められる。予約期限が迫っている組織も、オンデマンドで使い続けている組織も、今すぐ移行計画を立てるべき時期に来ている。 廃止対象：2つのフェーズを押さえておく 今回の発表では、対象VMシリーズは2つのフェーズに分かれている。 フェーズ1：2026年7月1日から予約停止＋2028年完全廃止（13シリーズ） Av2、Amv2、Bv1、D、Ds、Dv2、Dsv2、F、Fs、Fsv2、G、Gs、Ls、Lsv2の各シリーズが対象。2026年7月1日以降、1年予約（Reserved VM Instances）の新規購入・更新ができなくなる。さらに2028年5月および11月に完全廃止が予定されている。 フェーズ2：2026年7月1日から予約停止、廃止時期は2028年以降（4シリーズ） Dv3、Dsv3、Ev3、Esv3の4シリーズは、1年・3年の予約が新規購入・更新できなくなるが、VMそのものは2028年を超えても稼働し続ける予定だ。 なぜ今このタイミングか：世代間の開きが大きくなりすぎた 廃止の背景にあるのは、対象VMが動作するIntel CPUの世代の古さだ。 Haswell（第4世代Xeon）：2013年リリース Skylake（第6世代Xeon）：2015年リリース Cascade Lake（第3世代Xeon Scalable）：2019年リリース Microsoftは現在、第7世代のVMを提供しており、廃止対象の第3世代VMとの間には4世代もの差がある。新しい世代のCPUはコア密度が高く、消費電力が低い。同じ物理サーバーにより多くのVMを収容できるため、Microsoftにとってのコスト効率が明確に改善する。空いたデータセンタースペースをAI向けハードウェアに転用できるという側面も透けて見える。 公式には廃止理由が明示されていないが、このような世代交代はクラウドプロバイダーが定期的に行う「ハードウェアライフサイクル管理」の一環だ。クラウドは物理インフラである以上、古いハードウェアを永久に維持することはできない。 移行の選択肢 Microsoftは移行先として主に以下を推奨している。 現行世代VM（Dv5、Ev5など）：同等の用途で性能・コスト効率が大幅に改善 Azure Savings Plan：特定のVMシリーズに縛られない柔軟な割引オプション。Reserved VM Instancesよりも移行の自由度が高い 「Retired VM Sizes Migration Guide」に詳細なマッピングが公開されているため、現在使用中のVMシリーズを確認したうえで移行先を検討すると良い。 実務への影響：「2028年はまだ先」と思わないこと 今すぐ確認すること Azure Portalで現在使用中のVM SKUを棚卸しし、廃止対象が含まれていないか確認する Reserved VM Instancesの有効期限を把握する（期限後の更新が不可になる） 既存の予約がある場合、2026年7月1日以前に必要であれば更新手続きを済ませておく 移行計画の立て方 ワークロードの移行は、サイズ変更だけで済む単純なケースから、アプリケーションの動作確認や負荷テストが必要な複雑なケースまで様々だ。2028年まで約2年あるように見えるが、数十・数百台規模の環境では計画・テスト・本番移行に相応の時間がかかる。特に稼働時間に制約がある業種（金融・医療・製造など）は、早めにプロジェクト化しておくことを強く勧める。 Azure Savings Planへの切り替えも検討価値あり Reserved VM Instancesは特定のVMシリーズにコミットするため、今後の世代交代でも同様の問題が繰り返される。Azure Savings Planはコンピューティング利用量に対するコミットメントであり、VMシリーズを問わず適用できる。長期的な柔軟性という観点では、今回の移行タイミングに合わせてSavings Planへの切り替えを検討する価値がある。 筆者の見解 クラウドを使い始めた当初、「オンプレのようなハードウェア更新サイクルから解放される」という触れ込みを信じていた方も多いだろう。しかし現実には、クラウドにも確実にライフサイクルがある。ただし、これはAzureの弱点ではない——むしろ健全な進化のサインだと筆者は捉えている。 10年以上前のCPUで動くVMを使い続けることは、ユーザー側にとってもリスクだ。パフォーマンス、セキュリティパッチの適用範囲、エネルギー効率。いずれも新世代のハードウェアに見劣りする。Microsoftが2年間のリードタイムを設けているのは、顧客が計画的に動けるだけの時間を確保しているということでもある。 「道のド真ん中を歩く」という観点で言えば、今回の移行はむしろ環境を標準化する好機だ。古いシリーズが混在した状態のまま運用し続けるより、現行世代に統一したほうが管理の複雑性が下がる。Reserved VM Instancesに縛られているなら、今後の変化に追従しやすいAzure Savings Planへの乗り換えも合わせて検討してみてほしい。 2028年の廃止を「まだ先の話」と棚上げにするのが一番危険な対応だ。今がちょうど計画を始める適切なタイミングである。 出典: この記事は Microsoft to stop taking reservations for 17 Azure VM flavours, kill 13 in 2028 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure・Microsoft 365環境を運用するエンジニアにとって、毎月恒例のDefender XDRアップデートから見逃せない機能が追加された。2026年5月版では「Blobの自動ソフトデリート（隔離）」「GitHubアーティファクト認証の強化」「Secure Boot 2023証明書の推奨事項追加」という3点が特に注目に値する。クラウドストレージのマルウェア対策からソフトウェアサプライチェーンセキュリティまで、幅広い領域をカバーする内容だ。 Defender for Cloud：悪意あるBlobを自動隔離する時代へ これまでDefender for Cloudのマルウェアスキャンは、悪意あるコンテンツを検出しても「検出の通知」にとどまるものだった。今回のアップデートで、マルウェアと判定されたAzure Blob Storageのファイルを自動ソフトデリート（論理削除＝隔離）する機能が追加された。 「ソフトデリート」という点がポイントで、完全削除ではなく一定期間隔離状態に置く。これにより、誤検知への対処や証拠保全が可能になる。ランサムウェア対策として広く使われているBlobストレージのソフトデリート機能を、セキュリティ自動化ワークフローに組み込んだかたちと言える。 特に重要なのは「検出してアラートを出す」から「検出して自動対処する」への転換点を示している点だ。従来は運用担当者がアラートを確認し、手動で対応する必要があった。この自動化により、夜間・休日のインシデント対応時間を大幅に短縮できる可能性がある。 GitHubコネクタ：アーティファクト認証でサプライチェーンを守る GitHub連携において、artifact_metadata:write 権限が新たに追加された。これにより、ビルド成果物（アーティファクト）の出所（プロベナンス）を証明するアーティファクト認証（Artifact Attestation）機能が強化される。 ソフトウェアサプライチェーン攻撃が頻発する昨今、「このバイナリは本当に信頼できるパイプラインから生成されたのか」を証明する仕組みは不可欠だ。SLSA（Supply-chain Levels for Software Artifacts）フレームワークへの対応を進める組織にとっては、直接的な恩恵がある。日本のエンタープライズ環境では「SBOM? SLSAって何？」という状態のところも少なくないが、こうした機能がプラットフォームに組み込まれていくことで、自然と全体の底上げが進むのは良い流れだ。 Secure Score：Secure Boot 2023証明書の推奨事項が追加 Microsoft Secure Scoreに、Secure Boot 2023証明書の確認に関する新しい推奨事項が追加された。2023年以降、MicrosoftはSecure Bootの証明書更新プロセスを大きく変更しており、対応が遅れている環境では将来的にブート問題が発生するリスクがある。Secure Scoreでの可視化により、管理者が「優先的に対処すべき項目」として明示されるようになった。 実務への影響 Azure Blob Storage運用担当者 自動隔離機能の有効化を検討する。誤検知ポリシーの設定と、隔離期間（保持日数）の設計を先に固めておくこと 既存の「マルウェアスキャン有効化」設定とセットで見直すタイミング DevOpsエンジニア・セキュリティチーム GitHubアクションパイプラインでアーティファクト認証を実装している場合、Defenderとの連携権限（artifact_metadata:write）の追加確認を SBOMやプロベナンス情報の収集は、もはや「意識の高い組織だけ」の話ではなくなりつつある IT管理者全般 Secure Scoreの推奨事項に新項目が加わっているため、定期レビューのタイミングで必ず確認を Secure Boot証明書の対応状況は、特にオンプレミス混在環境で見落としがちな盲点になりやすい 筆者の見解 今回のアップデートを一言で表すなら「自動化の着実な一歩前進」だ。 Blobの自動隔離は、「検出→対処」ループの自動化という、ゼロトラスト実装において論理的な帰結と言える。「なぜ今まで自動対処がなかったのか」という気持ちがないとは言えないが、それより前に進んでいることを評価したい。ゼロトラストの実装は「禁止する」より「安全に動く仕組みを育てる」ことが本質であり、今回の機能追加はその方向に正しく向いている。 GitHubのアーティファクト認証強化も方向性は正しい。ソフトウェアサプライチェーンセキュリティは、欧米ではすでに規制対応の文脈でも語られ始めており、日本企業が「うちには関係ない」と言い続けられる時間はそう長くない。プラットフォームが対応機能を積み上げてくれることで、現場が自然と引き上げられる構造は、長期的に見て健全だ。 Defender XDRは毎月こうして地味だが着実な改善を重ねている。個々の機能の派手さより、全体として使えるエコシステムを育てるアプローチに、Azureプラットフォームとしての底力を感じる。これからも、日本のIT現場が「安全に・便利に使い続けられる」仕組みを丁寧に積み上げていってほしいと思う。 出典: この記事は Monthly news - May 2026 | Microsoft Defender XDR & Security Updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIの最新チャットモデル「GPT-5.5 Instant」が、Microsoft Foundry（旧Azure AI Foundry）に正式追加された。前世代のGPT-5.3-chatと比較してトークン効率が約25〜30%向上しており、応答の簡潔さと品質を高い次元で両立させた設計となっている。エンタープライズ向けAIプラットフォームの選択肢がまた一段と充実した。 GPT-5.5 Instantとは何か 「Instant」という命名が示す通り、このモデルはレスポンスの即時性と効率性に最適化されたチャット専用モデルだ。大規模な推論タスクや長文生成よりも、会話の流れを止めない軽量なやり取りを得意とする位置づけとなっている。 注目すべきはトークン効率の改善幅だ。前世代比で25〜30%というのは、単なる性能向上の話ではない。エンタープライズ環境では月間のAPI利用コストが大きな管理項目であり、同等品質を維持しながらコストを削減できることは、現場の導入判断に直接影響する。 Microsoft Foundry上で動く意味 このモデルがMicrosoft Foundry上で提供される点は、技術的な優位性以上の意味を持つ。 Foundryは単なるモデルのホスティング基盤ではなく、Microsoft Entra IDによるアクセス管理、Azure Policyとの統合、コンプライアンス要件への対応などがセットで提供されるプラットフォームだ。GPT-5.5 Instantを選ぶことで「OpenAIの最新モデル」と「Microsoftのエンタープライズガバナンス」を同時に手に入れることができる。 日本企業の多くは情報セキュリティポリシー上、「データが日本または承認済みリージョン内に留まること」「アクセスログが取れること」「既存のID基盤と連携すること」を要件として持っている。OpenAI APIを直接叩く構成ではこれらをすべて自前で担保しなければならないが、Foundry経由であればMicrosoftのインフラが吸収してくれる。 実務への影響 チャットボット・カスタマーサポート系の刷新タイミングが来た 社内FAQ対応、問い合わせ一次受付、ヘルプデスク自動化といった用途では、「軽く・速く・コストを抑えて」動くモデルが理想だ。GPT-5.5 Instantはまさにこの要件にフィットする。現在GPT-4系を使い続けているシステムの見直しを検討する好機だ。 トークン効率の改善をコスト計画に織り込む 新モデルへの移行時は、既存のプロンプト設計をそのまま流用すると効果が出ない場合がある。「簡潔な応答に最適化された」モデルに合わせてプロンプトや出力期待値を調整することで、25〜30%の効率改善を実際のコスト削減として実現できる。 Foundryを活用した柔軟なモデル切り替え体制の整備 今後もさまざまなモデルがFoundry上に追加され続ける。「使うモデルはFoundryで管理し、アプリ側はモデル名を直書きしない」という設計を今から整備しておくと、将来のモデル更新対応が格段に楽になる。 筆者の見解 Microsoft Foundryの方向性は、改めて正しいと思う。 「最良のAIモデルを使いたいが、Microsoftのガバナンス基盤は手放したくない」——これは日本企業が直面している本音だ。その解として、FoundryがOpenAIの最新モデルをタイムリーに取り込み続けるのは、正面から向き合った答えだと評価している。 GPT-5.5 InstantのFoundry提供が示しているのは、MicrosoftがOpenAIとの連携を単なるマーケティング関係ではなく、プラットフォーム競争力の核として位置づけているということだ。最先端モデルを自社で開発するアプローチと、最良モデルを安全に使えるプラットフォームを提供するアプローチ——Microsoftが後者に力を注いでいるのは、長期的に見て決して悪い賭けではない。 ただ一点、個人的に期待することがある。Foundryのポータル体験と開発者ドキュメントの質は、まだ「素晴らしい技術を持ちながら、それが伝わり切っていない」状態だ。この技術力は本物なのだから、それを使いやすく届ける部分にもう一段の投資をしてほしい——そう思わずにはいられない。 出典: この記事は Introducing OpenAI’s newest chat model in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、Azure上で複数のデータベースサービスを利用する企業に向けた新しいコスト削減オプション「クロスサービス・クロスリージョン節約プラン」を発表した。従来のリザベーション（予約購入）モデルの制約を大きく緩和するもので、マルチDB・マルチリージョン構成が当たり前になった現代のエンタープライズ環境にとって、実質的なコスト最適化の選択肢が一段階広がる。 クロスサービス節約プランとは何か 従来のAzureリザベーションは「特定サービス × 特定リージョン」という組み合わせにしか適用できなかった。East USのAzure SQL Databaseに対して予約購入しても、後からPostgreSQLに移行したり、別リージョンに構成を変えたりすると、その割引が失われてしまうリスクがあった。 新しい節約プランでは、この制約が根本的に変わる。Azure SQL Database、Azure Database for PostgreSQL、Azure Database for MySQL、Azure Cosmos DBの4サービスを横断して1つのプランが適用されるようになり、さらにリージョンをまたいでも割引が継続する。単一サービス・単一リージョンに縛られていた従来モデルと比較すると、構成変更や移行に対する柔軟性は別次元だ。 なぜこれが日本の現場にとって重要か 日本のエンタープライズにおいて、「複数のAzureデータベースをリージョンをまたいで並行利用する」というシナリオは急速に増えている。長年SQL Serverを使ってきた企業がクラウド移行を機にPostgreSQLやMySQLへ切り替えるケース、東日本・西日本の両リージョンで冗長構成を組むケース、グローバル展開に伴ってCosmos DBを組み合わせるケースなど、実態はすでにマルチDB・マルチリージョンだ。 にもかかわらず従来のリザベーションは「1サービス・1リージョン縛り」だったため、「将来の構成変更が怖くてリザベーション購入を躊躇する」→「オンデマンド料金を払い続ける」という非合理なコスト構造に陥っている組織は少なくなかったはずだ。今回の変更は、そういった現場の痛みを正面から解消するものだと評価できる。 実務での活用ポイント 今すぐ着手できる3ステップ DB費用の棚卸し: Azure Cost ManagementでSQL・PostgreSQL・MySQL・Cosmos DBそれぞれの月次コストを確認する。複数サービスで費用が分散している場合、節約プランの恩恵を受けやすい候補だ リザベーションとの使い分けを設計する: 変動しない固定ワークロードには従来型リザベーション（割引率が高め）、マルチサービス・マルチリージョン構成には新しい節約プランという棲み分けが基本戦略になる 既存リザベーションの満了タイミングを把握する: 現在リザベーション契約中の場合は、満了に合わせて切り替えを検討する。Cost Managementの「Reservations recommendations」機能を活用すれば移行判断の根拠も得やすい コスト最適化の設計思想 どちらが得かは実際の使用パターン次第だが、「柔軟性か割引率か」というトレードオフで選べるようになった点が重要だ。FinOps（クラウド財務管理）の観点では、この選択肢の広がり自体が組織の成熟度を上げるきっかけになる。 筆者の見解 Azureのコスト最適化ツールが着実に進化していることは素直に評価したい。「統合プラットフォームで全体最適を実現する」というMicrosoftの方向性と、今回のクロスサービス設計は一貫している。使えば使うほどAzureエコシステム全体でコストが下がる仕組みはロックインと表裏一体ではあるが、マルチDB構成が現実解になった今、それを所与の条件として最大限に活用する方が建設的な判断だろう。 日本のIT部門の多くは、クラウドコスト管理の成熟度がまだ途上にある。「とりあえず移行した」だけでオンデマンド課金を払い続けている組織は珍しくない。こういった新しい節約オプションをきっかけに、自社のDBコスト構造を改めて見直す機会にしてほしい。仕組みが整いつつある今こそ、FinOpsを「知っている話」から「自組織で実践している話」に変えるタイミングだ。 出典: この記事は Microsoft Expands Azure Database Cost-Saving Options with New Cross-Service Savings Plans の内容をもとに、筆者の見解を加えて独自に執筆したものです。

日本の大企業には、いまもOracleデータベースが基幹システムの中枢として根を張っている。そこへMicrosoftが動いた。Azure Logic Apps StandardにOracleデータベースの組み込みコネクタ（Built-in Connector）がパブリックプレビューとして追加されたのだ。これはエンタープライズ統合の現場にとって、地味に見えて実は大きな一手である。 これまでの課題と今回の変化 これまでLogic AppsからOracleデータベースに接続するには、外部コネクタ（マネージドコネクタ）を使う方法が主流だった。外部コネクタはAzure上のマネージドサービスとして動作するため、オンプレミスのOracleに接続する場合はオンプレミスデータゲートウェイの構築・維持管理が別途必要になる。ゲートウェイサーバーの可用性管理、証明書更新、バージョン管理――これらが「地味に重い運用負担」として現場エンジニアにのしかかってきた。 今回のパブリックプレビューで追加されたBuilt-in Connectorは、Logic Apps Standardのシングルテナント実行環境（Azure Functions Extensibility）にインプロセスで組み込まれる形態だ。これにより： オンプレミスデータゲートウェイが不要になるケースが増える ネットワーク設定やVNet統合がよりシンプルになる レイテンシが低減し、接続の信頼性が向上する Logic Apps Standardのローカル開発・テスト環境（VS Code + Azure Functions Core Tools）でも直接動作確認が可能になる 組み込みコネクタとマネージドコネクタの違い Logic Appsにはコネクタが2種類ある。マネージドコネクタはAzureが管理するSaaS型で、外部APIへの接続に向いている。一方、Built-in Connectorはワークフローランタイムと同一プロセスで動くため、セキュリティ上の分離が強く、パフォーマンスも有利だ。SQLやService Bus、Storage QueueなどはすでにBuilt-inとして提供されており、今回Oracleがその仲間入りをした格好になる。 実務での活用ポイント 1. 既存のOracleデータゲートウェイ構成を見直すタイミング 現在オンプレミスデータゲートウェイを使ってOracleに接続しているLogic Appsフローがあれば、パブリックプレビュー期間中に移行検証を開始するのが得策だ。GAになる前に自社の接続要件（認証方式、VNet構成、TLSバージョン）を整理しておくと移行がスムーズになる。 2. ハイブリッドアーキテクチャの再設計に使える Azure Logic Apps StandardはApp Service Environment（ASE）やVNet統合と組み合わせることで、プライベートネットワーク内のOracleへの安全なアクセスが実現できる。ゼロトラストの観点からも、ゲートウェイという「経路上の中継点」を減らせることはセキュリティアーキテクチャの単純化につながる。 3. 基幹系データとクラウドサービスの橋渡し Oracleに蓄積された受発注データ・在庫データを、Azure OpenAI ServiceやPower BIにリアルタイムで連携するパイプラインが、より低コストで構築できるようになる。「AIに食わせるデータをどう引っ張るか」という問いに対して、Logic Appsが現実的な選択肢として浮上してくる。 筆者の見解 エンタープライズ統合の世界では「最後の1マイル」が一番しんどい。どんなにクラウドネイティブな構成を描いても、現実には20年モノのOracleが基幹業務を支えているケースが日本では山ほどある。そこへのネイティブ接続がLogic Apps Standardに加わったことは、現場レベルで見れば地味だが確実に効いてくる話だ。 Microsoftの統合プラットフォーム戦略は、Azure Logic Apps・Azure Integration Services・API Management・Service Busといったコンポーネントを組み合わせて「全体最適」を実現するアーキテクチャを指向している。個別コネクタの拡充は、その戦略の着実な実装だ。部分最適のツールを乱立させるのではなく、一つのプラットフォームで幅広いシナリオをカバーできるようにする――この方向性は正しいと思う。 ひとつ期待したいのは、ドキュメントとサンプルの充実だ。Built-in Connectorの設定パラメータや認証オプション、特にOracleのWallet認証やKerberos連携まわりは、日本の大規模エンタープライズ環境では必須となるケースが多い。パブリックプレビューの段階からコミュニティへの情報開示を積極的に行い、GAに向けたフィードバックループを回してほしい。それができる力が、このプラットフォームにはある。 出典: この記事は Oracle Database built-in connector for Azure Logic Apps Standard now in public preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure Kubernetes Service（AKS）のLinuxノードに、深刻な特権昇格（Local Privilege Escalation）脆弱性が報告された（CVE-2026-31431、通称「Copy Fail」）。非ルートの一般コンテナからホストノードのrootへ到達できるという性質は、コンテナ分離モデルの根幹を揺るがすインパクトがある。AKSを本番運用している組織は今すぐ対応状況を確認してほしい。 Linuxカーネルのalgif_aead何が問題か Linuxカーネルのalgif_aeadモジュール（AEAD: 認証付き暗号）に存在する脆弱性で、CVSSスコアは7.8（HIGH）。このモジュール自体はAKSのLinuxノードにデフォルトでロードされないが、カーネルのモジュール自動ロード機能（request_module）により、AF_ALGソケットを作成するだけで動的にロードされてしまうのが問題だ。 AF_ALGソケットの作成に特別な権限は不要なため、特権なし・root不要・ホストアクセスなしの一般コンテナからでも悪用可能となる。つまり「マルチテナントクラスター上の悪意あるPod」が隣接ノードへ侵害を広げるシナリオが現実的に存在する。 影響を受けるノードイメージは以下の通り： Ubuntu 20.04 FIPS Ubuntu 22.04 Ubuntu 24.04 Azure Linux 3.0 Azure Linux 2.0（Mariner）およびWindowsノードは非影響。 対処法：ノードイメージのバージョンで手順が変わる Microsoftは2026年5月1日に緩和策を展開済みだ。modprobeルール（install algif_aead /bin/false）でモジュールの自動ロードをブロックする方法で、ノードイメージバージョン202604.13.0および202604.24.0に含まれている。 重要なのは、この修正はノードイメージアップグレードを通じて適用されるという点だ。既存ノードへのインプレースパッチではない。 ノードの状況 対処方法 202604.24.0より古いバージョン ノードイメージアップグレードで緩和策が自動適用 すでに202604.24.0のノード 新しいイメージが存在しないため、DaemonSetを手動適用する ノードプールのアップグレードコマンドは以下： 出典: この記事は CVE-2026-26118: SSRF vulnerability in Azure Model Context Protocol (MCP) Server の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Foundryに、OpenAIの最新画像生成モデル「GPT-image-2」が正式統合（GA）された。従来のDALL-Eシリーズに代わる次世代モデルとして、エンタープライズ向けの高品質な画像生成を可能にする。「新しいモデルが一つ増えた」という話にとどまらず、Foundryのプラットフォーム戦略が一段と本格化した出来事として注目したい。 GPT-image-2とは何が違うのか GPT-image-2はOpenAIが開発した最新の画像生成モデルで、従来のDALL-Eシリーズから大幅に進化している。主な特徴は以下の通りだ。 高精度なテキスト解釈: プロンプトの意図をより正確に反映した画像を生成でき、複雑な指示への追従性が向上 業務水準の品質: UIコンポーネントのモック、マーケティング素材、プレゼン資料の挿絵など、実務で使えるレベルの出力が期待できる Foundry管理環境内でのホスティング: データは組織のガバナンス・セキュリティポリシーの管理下に置かれ、コンプライアンス要件を維持したまま利用可能 特にFoundry経由での提供という点が重要で、企業のセキュリティ要件を満たした形でモデルを利用できる。 なぜMicrosoft Foundry経由なのか GPT-image-2を単体でAPI利用することも技術的には可能だが、Microsoft Foundry経由には大きなメリットがある。 既存ワークフローとの統合が最大の利点だ。Azure OpenAI Service、Azure AI Search、Copilot Studioといったエコシステムと接続し、エージェントの一部として画像生成を組み込める。「商品説明文を受け取って自動的に画像を生成し、ECサイトに掲載するエージェント」といったシナリオが、追加の認証やインフラ構築なしに実現できる。 コンプライアンスとガバナンスの観点からも、Foundry上での利用はエンタープライズに適している。Microsoft Entra IDによる認証・認可、Azure Policyによるガバナンス、監査ログの記録など、企業のIT部門が求めるコントロールがすでに組み込まれている。外部のAI APIを個別に契約・管理するコストや煩雑さを考えると、この統合管理の価値は相当大きい。 実務への影響——日本のエンジニア・IT管理者にとっての意味 画像生成AIは「クリエイター向けのツール」という認識がまだ根強い。しかし現実には、技術ドキュメントのアイキャッチ、社内報のバナー、サービスデスク向けマニュアルの挿絵、ECサイトの商品画像最適化など、「業務で使える画像生成」の需要は静かに広がっている。 GPT-image-2がFoundryに統合されたことで、「AIモデルを活用したいが、ガバナンスも維持したい」というエンタープライズの要件が一つのプラットフォームで満たせるようになる。特にMicrosoft製品を中心に環境を構築している日本企業にとって、新たな自動化基盤の選択肢として真剣に検討する価値がある。 明日から動けるヒントを3つ挙げる。 PoCはFoundryのプレイグラウンドから: まずFoundry上のモデルカタログでGPT-image-2を試し、自社ユースケースに合う品質かを検証する。プロンプト設計はDALL-Eとは異なるため、移行時は必ず出力品質を再評価すること エージェント組み込みの設計を先に描く: 単体で画像を生成するより、テキスト処理→画像生成→ストレージ保存→通知といった一連のワークフローとして設計した方が業務インパクトは大きい コスト試算を早めに: 画像生成はテキスト生成より単価が高い。月間生成枚数の見積もりと予算確保を先行させておくと、本格展開がスムーズになる 筆者の見解 この動きを見て、MicrosoftのFoundry戦略は着実に正しい方向へ進んでいると感じる。自社モデルだけにこだわらず、「業界の最良モデルをFoundry上で動かせる」という設計思想は、長期的に見て非常に強い競争優位になりうる。エンタープライズが本当に求めているのは「最強のモデル」ではなく、「管理・監査・セキュリティが保証された環境で、使い物になるモデルを使えること」だからだ。 Microsoftはモデル開発の競争では難しい戦いが続いているが、「最も多くのエージェントが安全に動作するプラットフォームを提供する競争」では依然として有利な立場にある。GPT-image-2のFoundry統合は、まさにその強みを活かした一手だ。 日本のIT組織においては、個別のAIサービスを乱立させるより、Foundryのような統合プラットフォームに集約していく方が、長期的な管理コストを抑えられる。「AIが進化するほど、どのモデルを使うかより、どのプラットフォームで安全に使うかが問われる時代になっている」——その意味で、今回の統合は地味に見えて、実はエンタープライズAI基盤を考える上での重要な一ピースだと捉えている。 出典: この記事は Introducing OpenAI’s GPT-image-2 in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年、企業のAI活用は「試験運用」から「本番稼働」へと本格的に移行しつつある。その転換点において、MicrosoftがIDC MarketScape: Worldwide API Management 2026 Vendor AssessmentでLeaderポジションを獲得した。この評価は単なる表彰ではなく、従来のAPI管理にとどまらずAIモデル・ツール・エージェントまでを統一プラットフォームで統制するという戦略が業界標準として認知されつつあることを意味している。 10年の実績が生んだ信頼基盤 Azure API Management（APIM）は10年以上にわたりグローバル規模でAPIガバナンスの中枢を担ってきた。38,000社以上の顧客、約300万のAPI、月間3兆回を超えるAPIリクエストという稼働規模は、エンタープライズ用途で試されてきた実績の重みそのものだ。こうした基盤の上に、AI専用のゲートウェイ機能が追加されており、すでに2,000社以上の企業がAI運用の管理・可視化に活用している。 APIとAIを同じガバナンス層で扱う意義 従来のAPI管理は「システム間の接続」が主眼だった。しかしAIが本番環境に入り込んだ今、課題の構造が変わった。複数のAIモデルが複数のチャンネルから呼び出され、コスト管理・レート制限・ポリシー適用・ログ取得が複雑に絡み合う。APIMのAIゲートウェイ機能はこれに対する正攻法だ。モデルへのアクセス制御、使用量の監視、コスト管理、セキュリティポリシーの強制適用を既存のAPIインフラと同じ管理層で扱える。 Heineken社の事例はその効果を端的に示している。5か月で世界規模のAPIプラットフォームを構築し、月間5,000万コール処理・稼働開始以来100%アップタイム・API呼び出しコストを最大75%削減という成果だ。Banco Bradesco社も金融サービス全体のAI・APIを集中管理し、セキュリティポリシーの一貫適用と可視性確保を実現している。 日本のIT現場にとっての実務的意味 日本の多くの企業はいま「どうやって安全に、コストを管理しながらAIを組織全体に展開するか」という段階に差し掛かっている。マルチベンダー・マルチモデル構成を選択する企業にとって、各プロバイダーのAPIをバラバラに管理するアプローチは統制不能になる。ポリシーが散在し、コストが見えず、ログが断片化する。APIMのような統合ゲートウェイを挟むことで、アプリケーション側はモデルの差異を意識せずに済み、ガバナンス・可視性・コスト制御を一か所に集約できる。 実務での活用ポイント LLMトラフィックの計測を最初から設計に組み込む: コスト管理の観点から、APIレベルでのトークン使用量の記録は後付けではなく初期設計に含める。プロバイダーごとの応答フォーマットの差異を前提に計測ロジックを設計しないと、後から痛い目を見る レート制限とフォールバックをポリシーで定義する: モデルごとのクォータをAPIMのポリシーで強制適用し、特定モデルの過負荷・障害時の自動フォールバックをインフラ側に持たせる AIトラフィックも既存の監視スタックへ統合する: オブザーバビリティを分断しない。AIトラフィックを既存のダッシュボードに統合することでインシデント対応が格段に早くなる OpenAI標準前提の設定を疑う: 標準ポリシーでは捕捉できない使用量データが存在する場合がある。マルチモデル環境では各プロバイダーのレスポンス仕様を事前に調査しておく 筆者の見解 Microsoftのこの方向性は間違っていない、と断言できる。AIが本番運用に入った瞬間から「どのモデルに何を頼んでいるか」「コストはどうなっているか」「ポリシーに違反していないか」を問われる。個別のSDKにそれぞれのガバナンスを持ち込もうとすれば必ずバラバラになる。統合ガバナンス層としてのAPIMは、この問題への現実的な解だ。 ただ、実際にLLMガバナンスをAPIMで一元化しようとすると、OpenAI標準を前提に設計されたポリシーでは捕捉しきれないケースに直面することがある。マルチモデル運用を進める組織ほど、この問題は早めに顕在化する。プロバイダーごとのストリーミング応答の差異まで考慮した計測実装が必要になる場面があり、「標準ポリシーで全部いける」という楽観は禁物だ。 APIMが「AI管理の標準インフラ」になっていくシナリオは十分に現実的で、Microsoftにはそれを実現する力がある。だからこそ、OpenAI以外のプロバイダーへの対応をより丁寧に作り込んでいくことを期待したい。IDCのLeader認定は出発点であり、真価が問われるのはこれからだ。 出典: この記事は Microsoft named a Leader in the IDC MarketScape: Worldwide API Management 2026 Vendor Assessment の内容をもとに、筆者の見解を加えて独自に執筆したものです。

KubeCon Europe 2026でMicrosoftが打ち出したメッセージは明快だった。「Kubernetesはもはやコンテナオーケストレーションツールではない。AIインフラの基盤OSだ」——この宣言は、エンタープライズAI運用の設計思想を根底から変える可能性を持っている。 KubernetesがAI基盤の「コントロールプレーン」になる Microsoftが描くビジョンは、Kubernetesを企業内のあらゆるAI関連ワークロードの管理基盤として位置付けるものだ。Webアプリのコンテナを管理していた同じ kubectl コマンドが、数百台のGPUにまたがる分散学習ジョブをオーケストレーションする——この統合こそが今回の発表の核心である。 従来、AIインフラは「専用の管理システム」として独立して運用されることが多かった。それがKubernetesへの一元化を進めることで、運用チームの学習コストを抑えつつ、既存のCI/CDパイプラインやポリシー管理をそのままAIワークロードに適用できるようになる。 DRAがGPUスケジューリングを変える 三本柱の一つ目がDynamic Resource Allocation（DRA）だ。KubernetesがCPUやメモリをスケジューリングするのと同じ精度で、GPUリソースを割り当てられるようになる仕組みである。 具体的には以下の機能がKubernetes APIを通じて直接利用可能になる。 フラクショナルGPU共有: 1枚のGPUを複数のワークロードで分割利用 タイムスライシング: GPU利用時間を時間割で管理 マルチインスタンスGPUパーティショニング（MIG）: NVIDIAのMIG機能をK8sレイヤーで統制 これまでGPU管理は専用ツールに頼るか、手動設定が必要なケースが多かった。DRAの成熟によって、GPUリソースがCPU/メモリと同様に「Kubernetesが面倒を見る」世界が近づく。 AI Runway：モデルを本番に届ける「最後の1マイル」を短縮 二本目の柱がAI Runwayプラットフォームだ。多くの組織がモデルのトレーニングには成功しているが、それを本番環境に展開することに苦労している。AI Runwayはその「最後の1マイル」問題に正面から取り組む。 VS Codeなどの開発環境と本番Kubernetesクラスターをつなぐ標準化パイプラインを提供し、モデルの特性とリソース要件に基づいてKubernetesマニフェストを自動生成する。モデル検証から本番デプロイまでの時間を「数日から数時間へ」と短縮できることをMicrosoftは示した。 カナリアデプロイやロールバック手順もKubernetesネイティブな仕組みで自動処理されるため、MLOpsの運用負荷を大幅に削減できる。 Cilium統合でAIのネットワーク要件に応える 三本目がCiliumの深いAKS統合だ。AIの分散学習では、ノード間を流れるデータ量が従来のマイクロサービスとは桁違いに大きい。勾配（gradient）のやり取りだけでテラバイト規模のトラフィックが発生する。 CiliumのeBPFベースアーキテクチャはカーネルレベルでこのトラフィックを最適化し、Microsoftの発表によれば分散学習ジョブのネットワークレイテンシを標準Kubernetesネットワーキングと比較して40%削減したという。eBPFはLinuxカーネルのコードを変更せずにカーネル動作を拡張できる技術であり、パフォーマンスと可観測性の両立が可能だ。 実務への影響——日本の現場にとって何が変わるか この発表が日本のエンジニアやインフラ管理者に示す実務的なインパクトは大きく三点ある。 1. GPU管理の標準化が加速する DRAの成熟により、GPUクラスターの管理をKubernetesに集約できる。AIプロジェクトごとに別々のツールや専門家を抱える必要が減り、既存のKubernetes運用チームがGPUワークロードを担える素地が整う。 2. AKS採用組織はCI/CD刷新の好機 AI RunwayはAKSとの統合が前提だ。すでにAzure/AKSを本番で使っている組織は、MLOpsパイプラインをKubernetesネイティブに刷新する絶好のタイミングが来ている。既存のポリシー・RBAC・監査ログがそのままAIワークロードに適用できる点は、ガバナンス上の大きなメリットだ。 3. ただし専門知識の壁は依然として高い DRA、Cilium、AI Runway——どれも強力だが、設定・運用には高度なKubernetes知識が必要だ。「とりあえずAKSを使っている」レベルの組織がそのまま恩恵を受けられるほど簡単ではない。マネージドサービスの成熟と、社内人材のスキルアップを並行して進める計画が必要になる。 筆者の見解 Microsoftが「KubernetesをAI基盤のOSにする」と宣言したことは、アーキテクチャの方向性として筋が通っている。部分最適のツールをバラバラに積み重ねるより、統合されたコントロールプレーンで全体を管理するほうが、長期的には運用コストもリスクも下がる。これはプラットフォームとしてのAzure・Entra ID・AKSに対する信頼が揺るがない理由と同じだ。 DRAによるGPU管理の標準化とCiliumによるネットワーク性能の底上げは、特に評価できる。GPUクラスターの管理が「Kubernetesを知れば何とかなる」世界になることは、日本の現場にとって人材調達の観点からも重要な前進だ。 一方で、AI Runwayの「数日から数時間へ」という効果を実際に得るには、モデル管理・バージョン管理・監視の仕組みが整備されていることが前提になる。ツールを導入すれば自動的に解決する話ではない。MLOpsの文化と基盤を先に作ることが順序として正しい。 Kubernetesを中核に据えたプラットフォーム統合の方向性は歓迎する。ただし「すごい発表があった」で終わらせず、自分たちのKubernetes運用の現在地を棚卸しして、どのコンポーネントから実装するかの優先順位を今すぐ考え始めることが、実務者として取るべき行動だろう。 出典: この記事は Microsoft Declares Kubernetes the AI Infrastructure OS at KubeCon 2026 with DRA, AI Runway & Cilium Integration の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ運用の現場では長らく「コストか網羅性か」のトレードオフが悩みの種だった。ログを長期保存しようとすれば費用が膨らみ、コストを抑えれば必要なときにデータがない。Microsoft Sentinel Data Lakeはそのジレンマを正面から解決しようとする試みだ。2026年4月1日より、Microsoft FabricおよびAzure Data Lake Storage（ADLS）・Azure Databricksとのフェデレーション機能が一般提供となり、最大12年分のセキュリティデータを単一の統合基盤でクエリ・分析できる環境が整った。 Sentinel Data Lakeとは何か Microsoft Sentinel Data Lakeは、クラウドネイティブなセキュリティ専用データレイクである。従来のSIEMが抱えていた「大量データの長期保存コスト」と「複雑なクエリ性能」という二重苦を、ストレージとコンピュートの分離、そしてオープンフォーマット（Parquet）の採用によって解消している。 アーキテクチャの要点は以下の3点だ。 シングルコピー設計: データの重複を排除し、ストレージコストを最小化 2層ストレージ構造: リアルタイム分析向けの「Analyticsティア」と、長期保存向けの「Data Lakeティア」（最大12年）を用途で使い分ける マルチエンジン対応: KQLによるクエリに加え、JupyterノートブックとPythonライブラリを使った機械学習・異常検知・フォレンジック分析まで一気通貫で実施できる フェデレーション対応の意味 今回の一般提供で特に注目したいのが、Microsoft FabricおよびADLS・Azure Databricksとのフェデレーション対応だ。セキュリティデータは往々にして複数のシステムに分散している。既存のDatabricksパイプラインやADLSに蓄積された業務ログを、Sentinelの分析エンジンから直接参照できるようになったことで、「セキュリティのためだけにデータを移す」二重管理が不要になる。 サポートされるデータソースも幅広く、Microsoft Defender XDRファミリー全体・Microsoft Entra ID・Microsoft 365・Microsoft Resource Graph・Endpoint Detectionに加え、サードパーティのセキュリティソースや脅威インテリジェンスフィードも統合できる。 日本のIT現場への影響 日本のエンタープライズにとって、特に響くポイントは「12年分のデータ保持」と「コスト最適化」の組み合わせだろう。 金融・医療・行政などの規制業種では、ログ保全期間の要件が年々厳格化している。従来は専用のアーカイブストレージとSIEMを別々に維持しなければならず、インシデント発生時に過去ログを掘り起こす作業は「職人技」と化していた。Sentinel Data Lakeによって、KQLという標準クエリ言語で過去12年のデータをシームレスに検索できるのは、SOC（Security Operations Center）の運用負荷を大きく下げる可能性がある。 また、ストレージとコンピュートの分離は、「平時は安いストレージに置いておき、インシデント調査時だけ高性能な分析エンジンを使う」という費用対効果の高いアーキテクチャを可能にする。SIEMライセンス費用が課題になっている組織には、コスト構造の見直しを検討する価値がある。 実務での活用ポイント 既存ADLSとの段階的統合: いきなり全データを移行するのではなく、フェデレーション機能を使って既存ADLSをSentinelから参照する形で試験的に始めるのが現実的 KQL + Jupyterの使い分け: リアルタイムのアラート・ハンティングはKQL、過去データの傾向分析・機械学習モデルの実行はJupyterと役割を明確に分ける Non-Human Identity（NHI）ログの長期保持: サービスプリンシパルやマネージドIDのアクティビティログを長期保存することで、侵害の初期侵入点遡及が容易になる 筆者の見解 Azureのプラットフォームとしての底力は、こういうところに出る。Parquetという業界標準フォーマット、Fabricとのネイティブ連携、KQLとPythonの両方をサポートするマルチエンジン設計——どれも「ベンダーロックインで囲い込む」ではなく「開放性で選ばれる」方向を向いている。この姿勢は正しい。 個人的には、セキュリティデータの長期分析基盤とAI・機械学習の組み合わせに最も期待している。異常検知や攻撃パターンの発見は、深い文脈と長い時系列データがあってこそ精度が上がる。12年分のデータを機械学習にかけられる環境が標準で用意されるのは、SOCのあり方を変えるインパクトを持ちうる。 一方で、「設計は素晴らしいが運用は別の話」という現実も直視すべきだ。フェデレーション設定やデータコネクタの管理、クエリのチューニングには相応の習熟が必要で、マネージドとはいえゼロ負荷ではない。導入する際は、SentinelのLog Analytics設計を最初からきちんと整理しておかないと、12年後に「なんのデータが何のためにあるのか誰もわからない」状態になりかねない。「アーキテクチャの道のド真ん中」を選び、後から後悔しない設計を最初に固める。その一点だけは省力化しないことを強くお勧めしたい。 出典: この記事は Microsoft Sentinel Data Lake: Fabric and ADLS Federation Now Available の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Foundryに、DeepSeek V4 FlashおよびV4 Proが追加された。単なるモデルラインナップの拡充ではない。「Microsoftプラットフォームの上で、最良のAIモデルを選ぶ自由」というアーキテクチャが着実に形になってきた出来事として受け止めるべきだ。 DeepSeek V4 Flash / V4 Pro とは何者か DeepSeek V4 Flash は、低レイテンシ・低コストの推論に特化したモデルだ。Microsoftの発表によれば、GPT-5.5と比較して約1/7のコストで動作する。リアルタイム応答が求められるチャットボットや、大量バッチ処理が必要なドキュメント分析など、「スピードとコストのバランスが最優先」な場面に向いている。 DeepSeek V4 Pro は、1.6兆パラメータ（アクティブパラメータは49B）のMixture-of-Experts（MoE）アーキテクチャを採用した高度推論モデルだ。全パラメータを常時使用するわけでなく、推論ごとに必要なエキスパートのみを活性化する設計により、パラメータ規模の割に効率的な処理が可能となっている。複雑なコード生成、長文の論理推論、技術ドキュメントの高度な解析といった重い処理を担当させる想定だ。 両モデルに共通する仕様として特筆すべきは、コンテキスト長100万トークン対応とマルチモーダル対応だ。長大な契約書や技術仕様書、大規模なコードベース全体を一度に与えて推論させる使い方が現実的になる。 なぜこれが重要か この発表が意味するのは、「高品質なAI推論を使いたければMicrosoftプラットフォームを離れるしかない」という状況が変わりつつあるということだ。 これまで、コストを重視する企業が最前線のモデルを使おうとすると、各モデルのAPIを個別調達し、請求管理・セキュリティポリシー・アクセス制御をバラバラに設計する必要があった。Microsoft Entra IDによる認証統合、Azure Policy によるガバナンス、Azure Monitor によるログ集約——こうしたプラットフォームの恩恵を受けながら複数モデルを使い分けるインフラが、Foundryによって整いつつある。 Azure API Management（APIM）との組み合わせで、モデルごとのトークン使用量を一元監視・ルーティング制御できる体制を構築すれば、コスト管理とガバナンスを両立したマルチモデル運用が初めて現実的な選択肢となる。 実務での活用ポイント コスト最適化のためのモデルルーティング設計が最初の実践課題になるだろう。すべてのリクエストを最高性能のモデルに流す必要はない。問い合わせの分類・要約・定型応答はFlash、複雑なコード生成や長文推論はProというように、用途ごとにモデルを使い分けるルーティング層を設計することで、全体コストを大幅に圧縮できる。 100万トークンコンテキストの活用は、日本の大企業や官公庁で蓄積されてきた大量の内部ドキュメントを活かす上で特に有効だ。これまで「チャンク分割してベクトル検索」という複雑な前処理が必要だったユースケースの一部が、コンテキストに全文を放り込む単純なアプローチに置き換えられる可能性がある。RAGアーキテクチャの設計を見直す機会として捉えるといい。 セキュリティ境界を維持したまま使えることも見逃せない。Foundry経由での利用は、Azureのデータレジデンシーポリシーや仮想ネットワーク統合の恩恵を受けられる。直接APIを叩く場合と比べ、エンタープライズ要件への対応が容易になる。 筆者の見解 MicrosoftがFoundryのモデルカタログを積極的に拡充していることは、長期的に正しい戦略の実行だと思う。「最も賢いAIを自社だけで作る競争」ではなく「最も多くの優れたAIが安全に動作するプラットフォームを提供する競争」に舵を切る姿勢が、この発表にも表れている。 今回の追加モデルは、価格と性能の両面でエンタープライズ向けに十分実用的な選択肢だ。GPT-5.5比1/7というコスト差は、大規模に展開するシステムでは月次のインフラコストを数百万円単位で変えうる。コスト圧力のある日本の現場で、この差は意思決定を変えるに十分なインパクトだろう。 一方で、正直に言えば「Foundryが今後も継続的に最良のモデルを揃え続けられるか」は注視し続ける必要がある。プラットフォームの価値はモデルの質と鮮度に直結するからだ。今回のDeepSeek追加は良い一手だが、これを継続的なコミットメントとして示し続けてほしい。Microsoftには、そのポジションを維持するだけのプラットフォーム力がある。正面から勝負できる舞台を自ら整えているのだから、あとはモデルの充実で応えていくことを期待したい。 Azure基盤を使い続けながら、最適なAIモデルを業務ごとに選ぶ——その選択肢が着実に広がっている。今がインフラ設計の見直しどころだ。 出典: この記事は Introducing DeepSeek V4 Flash and V4 Pro in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントを本格的に業務展開しようとして、「ツールの配線地獄」に陥った経験はないだろうか。Microsoft FoundryにToolboxesが登場し、このボトルネックを正面から解消する仕組みがパブリックプレビューとして公開された。 ツール統合の「複雑さ」が組織規模の展開を阻んでいた Microsoftが公式ブログで示した例がわかりやすい。「新入社員のオンボーディングを自動化するエージェント」を作るとしよう。Entra IDアカウントの作成、GitHubリポジトリへのアクセス付与、クラウドリソースのプロビジョニング、Azure DevOpsへのタスク登録、Teamsへのウェルカムメッセージ送信——これだけで5種類のツール、5種類の認証モデル、5チームの管轄が絡んでくる。 この「1エージェント×多ツール」の問題を組織全体に拡大すると、同じツール実装が各チームに散在し、クレデンシャルが重複し、ガバナンスが機能しなくなる。問題はモデルの能力ではない。ツール統合そのものがボトルネックになっているのだ。 Toolboxesとは何か：4つの柱 Foundry Toolboxesは「一度定義したツールセットを、あらゆるエージェントが単一エンドポイントから利用できる」仕組みだ。4つの柱で構成される。 Discover（近日公開） ツールカタログを検索・発見する機能。長大なカタログを手動で探す必要がなくなり、承認済みツールを再発見して再利用できる。 Build（本日より利用可能） ツールを「Toolbox」という名前付きの再利用可能バンドルにまとめる機能。現在対応しているツールは以下の通り。 ビルトインツール: Web Search、Code Interpreter、File Search、Azure AI Search プロトコル: MCP（Model Context Protocol）、A2A（Agent-to-Agent）、OpenAPI 認証はOAuthアイデンティティパススルーとMicrosoft Entraマネージドアイデンティティによって一元管理される。個々の開発者がクレデンシャルを管理する必要がなくなる。 Consume（本日より利用可能） ToolboxをMCP互換の単一エンドポイントとして公開する機能。エージェントは一度接続するだけで、Toolbox内のすべてのツールを動的に発見・呼び出せる。フレームワークやランタイムは問わない。AutoGenでもSemantic Kernelでも、MCP対応であればそのまま使える。 Govern（近日公開） すべてのツール呼び出しに対する集中認証と可観測性。開発者がガバナンスロジックを各エージェントに組み込む必要がなくなり、セキュリティチームと基盤チームが一貫したコントロールを得られる。 実務への影響：日本のエンジニア・IT管理者にとっての意味 今すぐ試せること Foundryポータルからツールboxを作成し、既存のMCPサーバーをバンドルして動作確認する Entraマネージドアイデンティティを使って認証を一元化し、クレデンシャル管理のコストを下げる MCP対応の任意のエージェントランタイムから接続し、既存エージェントとの統合を検証する ガバナンス観点での注目点 日本の大企業でよく見られる「シャドーIT的なエージェント乱立」を制御する手段として有効だ。誰がどのツールを使っているか、セキュリティ設定は統一されているか——こうした問いに答えるための基盤が整いつつある。Govern機能がGAになれば、監査ログや利用状況の可視化も期待できる。 NHI（Non-Human Identity）管理との接続 Toolboxesの認証機能はEntraのマネージドアイデンティティと統合されている。これは「人間の関与なしに安全にツールを呼び出せる」NHI管理の実践そのものだ。業務自動化の真のボトルネックは技術ではなく、認証・認可の煩雑さにある。この問題を正面から解決しようとしている姿勢は、現実の課題に真摯に向き合ったものと言える。 筆者の見解 AIエージェントの普及における最大の障害は、モデルの性能ではなくインフラ側の「配線コスト」だという見立ては正しい。Toolboxesはその問題に正直に向き合っている。 Microsoftが持つ強みは、Entra ID・Teams・Azure基盤という「エンタープライズを縦断するプラットフォーム」だ。個別のAI機能で競争するより、「多数のエージェントが安全に動作するための管制塔」としての役割——これはMicrosoftが最も得意とする領域であり、Toolboxesはその方向性を正しく具体化している。 一点気になるのは、GovernとDiscoverがまだ「近日公開」のステータスであることだ。ガバナンスが完備されていない状態でエージェントが乱立するリスクは現実にある。パブリックプレビューで実際に触りながら検証を進めつつ、GA（一般提供）のタイミングを見極めてから本番展開の計画を立てるのが現実的な進め方だろう。 MCP（Model Context Protocol）という共通プロトコルが、今後のエージェントエコシステムの事実上の標準になりつつある。FoundryがMCPを前面に打ち出してきたことは、この流れに乗る意思表示として明確だ。エンタープライズAIの「インフラ層」として確固たる地位を築けるか——Toolboxesはそのための重要な一手になりうる。正面から勝負できる力がMicrosoftにはある。あとはスピードと完成度だ。 出典: この記事は Introducing Toolboxes in Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月29日に発表したFY2026第3四半期（2026年3月期）決算は、市場予測を軒並み上回る内容だった。Azureの前年比40%成長（固定為替ベース39%）はアナリスト予測を超え、AI事業の年換算収益が370億ドルを突破したことは、クラウド・AI投資が着実に収益化されていることを示している。822億ドルという四半期売上の規模だけでも圧倒的だが、今回の決算が本当に示しているのは「数字の大きさ」ではなく「エコシステムの深度」だ。 決算のポイントをおさえる 主要指標を整理すると： 総収益：822億ドル（前年比+18%） Intelligent Cloud部門：347億ドル（+30%） うち Azure：前年比 +40%（固定為替+39%） AI事業年換算収益：370億ドル（前年比+123%） Copilot座席数：2,000万席 クラウドRPO（残存履行義務）：6,270億ドル（前年比+99%） 特に注目すべきは「残存履行義務」が6,270億ドルという数字だ。これはすでに契約済みだがまだ売上計上されていない金額であり、1年で実質倍増している。世界中の大企業・公共機関がAzureの長期利用に本格的にコミットしている実態が、この数字に如実に現れている。 AI事業「年換算370億ドル」が意味するもの Satya Nadella CEOが強調した「AI事業の年換算収益が前年比123%成長」という数字は、単なる投資フェーズを脱したことを示す。ただしこの「AI収益」は、Azure AI基盤のAPI利用料、Copilot for M365の追加ライセンス、GitHub Copilotなど複数の製品・サービスが混在している点は押さえておきたい。 とりわけ、Azure上で外部AIモデルのAPI利用が増加していることが成長ドライバーの一つになりつつある。言い換えれば「Microsoftのプラットフォームの上でさまざまなAIが動く」という構造が収益として現れ始めているのだ。これはMicrosoftが選んだポジショニングが正しかったことの証左でもある。 エージェント時代の「管制塔」としてのAzure Nadella CEOが今回の決算で使ったキーワードに注目したい。「agentic computing era（エージェント・コンピューティング時代）」という表現を積極的に使い始めている。 Microsoftの戦略を読み解くと、「最も賢いAIを自社で作る競争」よりも「最も多くのエージェントが安全に動作できるプラットフォームを提供する競争」に軸足を移しているのが見えてくる。Microsoft Entra IDをエージェントの認証・認可基盤として機能させ、Azure上でさまざまなAIモデルを選択的に利用できるエコシステムを構築するアプローチは、企業が求める「ガバナンスを保ちながらAIを活用したい」というニーズに正面から応えるものだ。 実務への影響 IT管理者・調達担当者へ 「Azure投資を継続する」という判断の根拠が固まった四半期だ。RPOの倍増は、Azureが長期的な企業インフラとして世界レベルで選ばれている証拠。自組織のクラウド戦略を見直す際、Azureを軸に置く意思決定は引き続き合理的だ。 エンジニア・アーキテクトへ Azure AI Foundryを中心にしたAI基盤への移行を検討するタイミングが来ている。モデルの選択肢が増えるほど「どのモデルをどのユースケースに使うか」というアーキテクチャ判断の重要性が増す。あわせて、Microsoft Entra IDと連携したNon-Human Identity（NHI）管理——AIエージェントのIDを人間と同様に認証・認可する仕組み——は、エージェント活用の実務上の前提条件として早期に習得しておきたい。自動化・エージェント化のボトルネックは結局「人間の承認フロー」にあり、NHI管理の整備なしに業務効率の抜本的改善は難しい。 Copilot for M365を評価中の組織へ 座席数2,000万席は市場への普及を示すが、「導入した＝活用している」は別問題だ。Microsoft 365管理センターのCopilotダッシュボードで自組織の利用状況を定期的に確認し、アクティブ率が低い部署へのオンボーディング強化が今期投資を無駄にしないための最優先アクションだ。 筆者の見解 今回の決算は文句なしに好業績だ。RPOの倍増はプラットフォームとしてのAzureへの信頼が揺るぎないことを示しており、長期投資の観点では非常に健全な数字だと思う。 その一方で、Copilotについては「2,000万席」という数字を素直に喜びつつも、「座席があること」と「生産性が実際に変わること」の間にある溝をどう埋めるかが次の勝負どころだと感じている。Microsoftにはその溝を埋め切るだけの技術力もリソースもある。Copilotが「本当に使われるツール」として評価が確立する日を、率直に楽しみに待っている。 エージェント時代の管制塔争いはこれからが本番だ。インフラとID管理で圧倒的な優位に立つMicrosoftがこのポジションを活かしきれるか——FY2026通期と来期の数字に引き続き注目していきたい。 出典: この記事は Microsoft Q3 FY2026 Earnings: Azure Revenue Grew 40% の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Sentinelのデータ収集基盤が、2026年4月にかけて大きな転換点を迎えた。コードレスコネクタ基盤の刷新（CCFへの改称とCCF Pushのプレビュー開始）、Defender Advanced HuntingテーブルへのLake専用インジェストのGA、そしてMicrosoft Fabricを活用したデータフェデレーション機能のプレビューが相次いで発表された。SOC（セキュリティオペレーションセンター）の運用コストと複雑性を同時に下げる施策として、日本のセキュリティ担当者も注目すべきアップデートだ。 Codeless Connector Framework（CCF）の刷新 これまで「Codeless Connector Platform（CCP）」と呼ばれていたSentinelのカスタムコネクタ基盤が、「Codeless Connector Framework（CCF）」に改称された。単なる名称変更ではなく、アーキテクチャの成熟とロードマップの整理を示すリブランディングだ。 今回のハイライトは「CCF Push」のパブリックプレビュー開始だ。従来のPull型コネクタ（Sentinelがデータソースに取りに行く）に加え、Push型（データソース側からSentinelに送り込む）をカスタムコードなしで実装できるようになった。これにより、独自のログ基盤やSaaSサービスからのイベントをSentinelに集約するハードルが大幅に下がる。 従来、独自コネクタを作るにはAzure Functionsなどのカスタム実装が必要だった。CCFはJSON設定ファイルだけで接続定義を完結させる設計であり、セキュリティエンジニアがインフラ管理の負担なくデータソースを追加できる点が最大の価値だ。Visual Studio Code向けのコネクタビルダーエージェント（プレビュー）も加わり、開発体験の底上げも図られている。 Lake専用インジェストのGA — 高コスト構成を見直す好機 Microsoft Defender Advanced HuntingテーブルへのLake専用インジェスト（Lake-only Ingestion）が一般提供（GA）を迎えた。 Sentinelのインジェストモデルには「分析ログ」「基本ログ」「補助ログ」という階層があるが、Lake専用インジェストはデータをAnalyticsテーブルとしてではなく、ストレージレイヤーにのみ保持する。これにより、常時クエリが不要なデータ（長期保存・コンプライアンス目的等）のインジェストコストを大幅に削減できる。 特にDefender Advanced Huntingのテーブルは大量のイベントを生成するため、全量をAnalyticsとして取り込むとコストが膨らみやすい。「重要なアラートはリアルタイム分析、ハンティング用データは低コストで長期保存」という使い分けが現実的になった。 【要注意】7月1日までにオートメーションルールを更新せよ 見逃してほしくない重要な変更がある。2026年7月1日より、Sentinelアナリティクスルールのアラートにおけるアカウントエンティティの「Account Name」フィールドの仕様が変更される。 現在、UPNが user@domain.com の場合、Account Nameには user が入ることも user@domain.com が入ることもある（挙動が不安定だった）。変更後は常に user（UPNプレフィックスのみ）が入り、ドメイン部分は別フィールド（UPNSuffix）として提供される。 既存のLogic AppsプレイブックやオートメーションルールでAccount Nameに対して Equals user@domain.com のような完全一致チェックをしている場合、この変更後に動作しなくなる可能性がある。Contains や Starts with オペレーションへの書き換えを推奨する。7月1日は想像より近い。早めに棚卸しを。 データフェデレーション（プレビュー）— データを動かさずに分析する Microsoft Fabricをバックエンドとして活用する「Sentinelデータフェデレーション」もプレビューに入った。Azure Data Lake StorageやAzure Databricksに存在するデータを、Sentinelにコピーすることなくそのまま分析できる仕組みだ。KQLやノートブック、カスタムグラフなど、SentinelのUXから透過的に利用できる。 データ移動はコストとガバナンスの問題を生む。既存のDatabricksやADLSにセキュリティ関連データを持っている組織にとって、フェデレーションアプローチは現実的な選択肢になりうる。 実務への影響 SOC担当者・セキュリティエンジニアへ: CCF Pushプレビューを試す価値がある。社内の独自ログ基盤や、既存コネクタがないSaaSからのイベント収集をAzure Functions不要で実装できる可能性がある Lake専用インジェストのGAにより「全量をAnalyticsで取り込む」構成を見直す好機。特にDefender系テーブルはボリュームが大きいため、コスト試算を行うことを推奨する 7月1日のUPN変更はすぐ確認。Logic AppsのPlaybookでAccountNameを参照している箇所は全数チェックを IT管理者・CISOへ: ...