Azure

クラウド一辺倒に見えたMicrosoftのインフラ戦略に、静かだが重要な変化が起きている。Azure Localが「分解型デプロイ（Disaggregated Deployments）」と呼ばれる新アーキテクチャを採用し、これまで現実的ではなかった数千ノード規模のオンプレミス主権インフラが手の届くところに来た。AI推論やアナリティクスワークロードをパブリッククラウドに出したくない——そういう要件を持つ組織にとって、これは見逃せないアップデートだ。 「分解型デプロイ」で何が変わったか 従来のAzure Stack HCI（現Azure Local）は、コンピュートとストレージを同一ノードに搭載するハイパーコンバージドインフラ（HCI）モデルが基本だった。スケールアップするには全ノードを一律に追加する必要があり、コンピュート過剰・ストレージ過剰の片方に無駄が出やすい構造だった。 今回の分解型デプロイはこの制約を取り払う。コンピュートノードとストレージノードを独立してスケールできる設計になり、ワークロードの実態に合わせたリソース投入が可能になった。GPU集約型のAI推論では「コンピュートを増やし、ストレージは据え置き」、大量データ処理では「ストレージを増やし、コンピュートは最小限」という選択肢が現実になる。 フォルトドメインモデルの強化とインフラプール 大規模化に伴う可用性設計も進化している。強化されたフォルトドメインモデルにより、ラック単位・電源系統単位での障害分離が明示的に制御できるようになった。これは単なる機能追加ではなく、エンタープライズ本番環境で数千ノードを運用する際に不可欠な前提条件だ。 インフラプール機能は、異なるスペックのノードを論理的なリソースプールとして統合管理する仕組みで、世代の異なるハードウェアを混在させながら運用するという現実的な課題に応える。「常に最新ハードウェアに統一」など大企業では難しい。この機能は地道だが実務上の価値が高い。 マルチラックネットワーキングで「数百→数千ノード」へ スケールの鍵を握るのがマルチラックネットワーキングだ。従来のAzure Localはシングルラックまたは少数ラック構成が前提で、事実上16ノード前後が現実的な上限だった。今回の拡張により、ラック間通信の帯域とレイテンシが最適化され、アーキテクチャを変えずに数千ノード構成まで水平展開できる。 「アーキテクチャ変更なしでスケール」というのは、実際の運用現場では非常に重要なメッセージだ。スケールアウトのたびに設計し直す手間は、運用チームにとって大きな負担であり、変更リスクでもある。 実務への影響——日本のエンジニア・IT管理者にとっての意味 データ主権要件の強い組織に刺さる 金融機関、医療機関、官公庁、防衛関連——日本にはパブリッククラウドへのデータ持ち出しに法的・規制的制約がある組織が少なくない。これまでこうした組織がAI推論基盤を構築しようとすると、NVIDIAのDGXクラスタをオンプレに建てるか、プライベートクラウドを自力構築するかという選択肢しかなかった。Azure Localがその隙間に入ってくる。 AI推論をオンプレで完結させるための具体的なヒント GPU搭載コンピュートノードと高容量ストレージノードを分離設計し、モデルのロード・推論・ログ保存のワークロード特性に合わせてスケーリング戦略を立てる フォルトドメインの設定は「電源系統ごと」「ラックごと」を最初から明示的に設計する。後付けでの変更は想定外の影響が出やすい インフラプールを使った世代混在運用では、古いノードをストレージ専用に降格させることで資産の延命と新規投資の抑制を両立できる Azure Arcとの統合を忘れずに。管理プレーンをAzure側に置きながらデータプレーンはオンプレというハイブリッド構成が、運用の現実解になる 規模感の参考値 数千ノード規模というのは、データセンター1棟丸ごとに近いスケールだ。中小企業の話ではない。ただし「数百ノードから始めて段階的に拡張できる」点は、大手製造業や通信キャリアが段階投資しやすいモデルになっている。 筆者の見解 Azure Localのこの方向性は、Microsoftが「プラットフォームの多様性」に対して誠実に向き合っている証拠だと思う。「全部クラウドへ」という力学だけで動いているわけではなく、オンプレミスを必要とする顧客の現実を直視したアーキテクチャ拡張だ。これは評価したい。 個人的に注目しているのは、AI推論ワークロードとの組み合わせだ。LLMの推論はGPUを大量に消費するが、そのGPUをパブリッククラウドでオンデマンドに使うと、大規模・継続的な処理では驚くほどのコストになる。「一定以上の推論量を持つ組織はオンプレGPUクラスタのほうが経済合理性がある」という議論は以前からあったが、その選択肢がAzure管理プレーンと統合された形で提供されるのは意味が大きい。Microsoftのエコシステムを離れる必要がない。 一方で、日本市場での普及に向けてはいくつか乗り越えるべき壁がある。導入・設計できるSIerが限られること、初期投資の大きさ、そして何より「クラウドかオンプレか」という二項対立で議論が止まりがちな日本のIT意思決定文化だ。技術の準備が整っても、組織の判断が追いつかないシナリオは珍しくない。 Microsoftにはこれだけのインフラ技術力がある。その力を、日本のエンタープライズが安心して手の届く形で届けるエコシステムの整備——そこにもう一段の力を入れてほしい、と応援する立場から率直に思う。 出典: この記事は Azure Local expands to sovereign-scale infrastructure with disaggregated deployments の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、2027年までにAIインフラを現在の2倍に拡張する計画を正式に表明した。FY2026第3四半期だけで1GWものデータセンター容量を新規追加し、Azureを基軸とした生成AI需要への対応を本格化させている。この動きは単なるインフラ投資の話ではなく、OpenAIとの関係再定義とAzureの自立強化という、より大きな戦略転換の文脈で読む必要がある。 1GW追加という数字が意味するもの Microsoft Azureはすでにグローバルで80以上のリージョン、500超のデータセンター、190以上のPoP（ネットワーク拠点）、80万キロメートルを超える専用光ファイバーを擁する。この規模感は「クラウドサービス」というくくりをはるかに超えており、電力・ネットワーク・土地・冷却設備という物理レイヤーそのものが、AIの差別化要因になっている時代を反映している。 1GW追加というのは、大規模データセンター数十棟分に相当するスケールだ。重要なのは「需要が先か、インフラが先か」という問いへのMicrosoftの答えが、明確に「インフラが先」——需要を見越して先手を打つ姿勢であることだ。これはクラウドプロバイダーとしての成熟度を示すと同時に、AI競争での「遅れを取り戻す」という意志の表れでもある。 OpenAI独占の終焉と「Azureのオープン化」 Microsoftが長年築いてきたOpenAIとの独占的パートナーシップが、この1年で大きく変容しつつある。かつてはOpenAIモデルへの独占ライセンスをAzureへの大規模投資と引き換えに獲得していたが、その独占権は失効しつつある。OpenAI自身もNvidiaやAMD、Cerebrasと直接契約して独自のAIインフラ構築を進め始めた。 一見するとMicrosoftにとって不利な展開に見えるが、むしろAzureが「OpenAIのクラウド」から「マルチモデルが動作するオープンなAIプラットフォーム」へと脱皮する機会が生まれたと読むべきだろう。Azureでは今後、多様なモデルが共存し、企業が自社データで独自モデルを訓練・推論実行できる環境が整っていく。 実務への影響 日本のIT部門・エンジニアが今この動きから読み取るべきポイントは3つある。 ① Azure上でのモデル選択の自由度が広がる Azureはすでに複数のモデルをホストできる「Azure AI Foundry」を展開している。OpenAIモデルに縛られず、用途に応じて最適なモデルを選べる環境が整いつつある。エンタープライズのガバナンスを維持しながらAIを活用したい企業にとって、Azureはより現実的な選択肢になる。Microsoft Entra IDを軸とした認証・認可基盤の上でAIエージェントを安全に動かすアーキテクチャは、長期的に最も再現性が高い構成だ。 ② GPUアクセスの安定性が増す GPUが依然として入手困難な中、Azureのリソースを通じてAI推論・学習環境にアクセスするモデルは引き続き有効だ。インフラ倍増は、現在発生しているキャパシティ制限の緩和に直接寄与する。特に日本企業には「自社でGPUを買って管理する」よりも「Azureのマネージドサービスで動かす」ほうが、運用コスト・セキュリティ・スケーラビリティの観点から合理的な選択であることが多い。 ③ Copilot・AI製品の体験向上が期待できる インフラ強化の恩恵は、最終的にエンドユーザーの体験にも反映される。Copilotの応答速度やAzure OpenAI Serviceのキャパシティ改善という形で、日常業務での利用体験が向上していくはずだ。現時点でCopilotの応答品質に不満を感じているユーザーにとっても、インフラの充実は朗報だ。 筆者の見解 今回のインフラ倍増宣言は、数字の大きさよりも「戦略の転換点」として記憶されるべき発表だと思っている。 Microsoftは長らくOpenAIという看板を借りる形でGenAI競争を戦ってきた。それ自体は合理的な判断だったが、今後OpenAIとの独占が緩み、AzureがマルチモデルのプラットフォームとしてMaiaなど自社AIチップも含めた垂直統合に向かうとするなら、これは「本当のAzure時代の幕開け」になりうる。 Azureというプラットフォームの底力は疑っていない。80リージョン・80万kmのファイバー・500超のデータセンター——この物理基盤は一朝一夕には作れない本物の競争優位だ。これだけの資産を持っているのだから、AIモデルそのものの競争でも正面から勝負できる力は十分にある。もったいないと思う場面があるとすれば、むしろそのポテンシャルをまだ全開にできていないところだろう。 今後注目したいのは、MicrosoftがフロンティアモデルをAzureから提供する日が来るかどうかだ。Maiaチップを軸にした自社モデル開発への再参入は、現実的な未来として十分考えられる。それが実現したとき、Azureは「他社モデルを借りて動くプラットフォーム」から「自前のAIと最高のプラットフォームが一体化した強み」へと進化する。 日本のIT現場では、AIへの移行が「どのモデルを使うか」ではなく「どのプラットフォームで安全・効率的に動かすか」という問いに変わりつつある。その答えとしてAzureを選ぶ合理性は、今後もゆるぎないと考えている。インフラへの巨額投資は、その選択肢をより確かなものにする動きだ。 出典: この記事は Microsoft Committed To Doubling AI Infrastructure In Two Years の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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との共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

DockerでAzure SDKが断続的にタイムアウトする。原因はAzureじゃなかった🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 続きをみる note.com で続きを読む →

日本の大企業には、いまも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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。続きをみる note.com で続きを読む →