Azure

Microsoftは、Azure DevOpsのパイプラインが他のリポジトリやArtifacts feed、REST APIにアクセスする際の認証方式として、新しい「Azure DevOps service connection」を発表した。これまでPersonal Access Token（PAT）やビルドセッショントークンで行っていた認証を、Microsoft EntraのワークロードID（サービスプリンシパルまたはマネージドID）に置き換えられる。 PATが抱えていた課題 Azure DevOpsのパイプラインが外部リソースにアクセスする従来の主な手段はPATだった。PATは長期間有効な文字列シークレットで、発行したユーザーの権限をそのまま引き継ぐケースが多く、発行・保管・定期ローテーション・失効管理をすべて人手で行う必要があった。ビルドサービスアカウントの権限を使う運用も同様で、パイプライン単位・タスク単位の最小権限とは相性が悪い。漏洩すれば発行者の権限範囲でAzure DevOpsに広くアクセスされてしまうリスクも常につきまとっていた。 Service Connectionの仕組み 新しいService Connectionは、Entra IDのフェデレーション資格情報（Federated Credential）を使って認証する。パスワードや秘密鍵といった永続的なシークレットをどこにも保存せず、Entra ID側で発行される短命なトークンでAzure DevOpsにアクセスする点が最大の特徴だ。認証試行はすべてAzure DevOpsの監査ログに記録されるため、追跡可能性も高まる。Entra IDのアイデンティティとして認証するので、同じEntra IDテナントに参加していれば、自組織だけでなく別のAzure DevOps組織のリソースにもこの接続でアクセスできる。 設定の流れ 利用にはまず、サービスプリンシパルまたはマネージドIDをAzure DevOps組織のユーザーとして追加し、必要な権限（例：対象プロジェクトのReadersグループへの追加）を事前に割り当てておく必要がある。そのうえで新規サービス接続の作成画面から「Azure DevOps (preview)」を選び、用意したIDを指定する。利用者がMicrosoft Graphの権限を持たずフェデレーション資格情報を自動作成できない環境では、発行者（issuer）とサブジェクト（subject）の情報が画面に表示され、権限を持つ管理者が手動でEntra ID側に資格情報を追加するフォールバック手順が用意されている。 パイプラインでの使い方 設定したService Connectionは、YAMLパイプラインのresources.repositoriesで外部リポジトリをcheckoutする用途や、別組織のYAMLテンプレートをtemplateで参照する用途に使える。ランタイムパラメータでService Connection名を渡せるため、呼び出し側が接続先を切り替えられるテンプレートも組める。ほかにもNuGetAuthenticateタスクでのArtifacts feed認証や、InvokeRESTAPIタスクからAzure DevOps REST APIを直接呼び出す用途にも対応している。 実務への影響 日本のIT現場でも、複数のパイプラインで同じPATを使い回している、あるいはビルドサービスアカウントに広い権限を与えたままにしている構成は珍しくない。特に事業部や子会社ごとにAzure DevOps組織を分けている企業では、組織をまたぐリポジトリ参照やテンプレート共有のためにPATが飛び交いがちで、このService Connectionはそうした構成に直接効いてくる。 常時有効なシークレットを廃止し、フェデレーション資格情報による認証に置き換えるという方向性は、特権アクセスをJust-In-Timeで最小限に絞るゼロトラストの考え方と軌を一にしている。「今動いているから大丈夫」で放置されたPATは、担当者の異動や退職後も生き続けて監査対象から漏れやすい。既存PATの棚卸しやローテーションのタイミングは、この新方式への切り替えを検討する好機になる。 現時点ではプレビュー機能であり、対応済みのタスクはNuGetAuthenticateやInvokeRESTAPIなど一部にとどまる。全パイプラインを一度に移行するのではなく、まずは外部依存の強いテンプレート共有やArtifacts feedアクセスなど、影響範囲が明確な箇所から段階的に置き換えていく進め方が現実的だろう。 出典: この記事は You can now use the Azure DevOps Service Connection instead of a PAT or Build Session token の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年9月1日から、Microsoft Foundry（旧Azure AI Foundry）における一部のモデルデプロイメント価格を引き上げると発表した。対象はEUデータゾーンおよび米国外のリージョン指定デプロイメントで、値上げ幅は10〜50%。Provisioned Throughput（プロビジョニング済みスループット、以下PTU）は既存顧客の契約にもそのまま適用される一方、Standardデプロイは新規追加モデルのみが値上げ対象となる。リージョンを指定しない「グローバル」デプロイは価格据え置きで、引き続き最も安価な選択肢であり続ける。 Foundryのデプロイ方式とコスト構造 Microsoft Foundryのモデルデプロイには大きく3つの方式がある。①Global——特定のリージョンを指定せず、Microsoftが空いている容量に自動的にルーティングする方式で最安、②Data Zone / Regional——EUやUSなど地理的境界、あるいは単一リージョンを明示的に固定する方式で、データ主権要件を満たすために選ぶ、③PTUによる専有容量——特定のスループットとレイテンシをSLAとして確保する方式、である。今回値上げの対象になったのは②と③、つまり「場所を固定すること」に対するコストだ。 なぜ値上げなのか Microsoftが公表した理由は「特定地域における高可用性提供コストの反映」。Globalデプロイはどのデータセンターの空き容量でも処理できるため、Microsoft側は効率よくキャパシティを融通できる。これに対しEUデータゾーンのような地理的境界の保証や、特定リージョンでの冗長構成の維持は、Microsoft側にとって明確に割高な運用になる。今回の改定は、その実コストを利用者に正しく転嫁したものと理解するのが妥当だろう。 注目すべきは、PTUについては既存顧客の契約にも値上げが適用される点だ。Azureの料金改定は通常、新規デプロイのみが対象になることが多い中、これは珍しい。EUデータゾーンやリージョン固定でPTUを組んでいる既存ワークロードは、9月1日以降のコストを自分で再計算しておく必要がある。 実務への影響 日本のエンジニア・IT管理者がいま確認すべきことは3つある。 まず、社内のFoundryリソースをリストアップし、Global／Data Zone／Regionalのどれで動いているかを棚卸しする。コンプライアンス上の理由がなくGlobalで問題ないワークロードを、惰性でリージョン固定のまま運用していないかを確認したい。 次に、PTUで容量を確保している場合は9月以降の請求試算を先に出し、予算超過のアラートをAzure Cost Managementに設定しておく。値上げが既存契約に遡って適用される以上、「気づいたら請求が跳ね上がっていた」という事態は避けられる。 最後に、今回はEU・米国外が対象だが、同じロジック（特定地域の高可用性維持コスト）は将来的に東日本・西日本リージョンにも適用され得る。日本のデータ主権要件でリージョン固定を選ばざるを得ない企業ほど、この種の値上げに巻き込まれやすい構造だと理解しておくべきだ。 筆者の見解 Azureのプラットフォームとしての信頼という意味では、今回の改定は筋が通っている。地理的境界を保証するにはその分の冗長性とオペレーションコストがかかる。それを価格に正直に反映させるのは、コスト構造を偽らないという意味でむしろ健全な判断だと思う。Global据え置きで最安の選択肢を残している設計も、コンプライアンス要件のない大多数のワークロードにとっては合理的だ。 ただ、応援する立場から一つ苦言を呈するなら、PTUの既存契約にまで値上げを遡及適用するやり方は、もう少し丁寧な移行パスがあってもよかったはずだ。事前の値上げ予告と移行期間、あるいは既存契約の一定期間グランドファザリングといった配慮があれば、コスト管理に追われるIT管理者の負担はもっと小さくできた。Microsoft Entra IDを軸にAIエージェントの管制塔を担おうとしているのなら、こうした足元の請求まわりの丁寧さこそが信頼を積み上げる部分のはずだ。正面から勝負できる基盤を持っているのだから、そこはもったいない。 リージョン戦略とコストは、これから日本企業がFoundryを本格運用する上でも避けて通れないテーマになる。今のうちにデプロイ方式の棚卸しをしておいて損はない。 出典: この記事は Microsoft Foundry Model Deployment Pricing Update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月、Identity基盤「Microsoft Entra」に3つのアップデートを加えた。管理者の誤操作や悪意ある変更からテナント設定を復旧できる「Entra Backup and Recovery」、脱獄・root化端末でのMicrosoft Authenticator資格情報登録を既定でブロックする機能、そして米国政府クラウド（GCC High/DoD想定）でのSCIM 2.0 API対応である。 テナントの「誤操作」から復旧できるEntra Backup and Recovery これまでEntra IDには、条件付きアクセスポリシーの誤削除やアプリ登録の意図しない変更を「まとめて」ロールバックする標準機能がなかった。オンプレミスのActive Directoryであれば、システム状態バックアップからドメインコントローラーを復元する運用が定着していたが、クラウドのテナント設定にはそれに相当する仕組みが薄かった。Entra Backup and Recoveryは、テナント構成のスナップショットを取得し、誤操作や侵害後の不正な変更が見つかった際に特定時点へ復元できるようにする。 Authenticatorがジェイルブレイク・root化端末をブロック Microsoft Authenticatorは、脱獄（ジェイルブレイク）済みiOSやroot化されたAndroid端末での新規資格情報登録を既定でブロックするようになった。改造済み端末はOSレベルの保護機構が無効化されており、TOTPシードやプッシュ通知の承認情報がマルウェアに窃取されるリスクが高い。これまでもデバイスの状態を確認するオプションはあったが、既定で有効化されたことで、多くの組織が意識せずに一段強いガードを得ることになる。 米国政府クラウドでもSCIM 2.0 API対応 SCIM（System for Cross-domain Identity Management）2.0 APIは、SaaSアプリとEntra ID間でユーザーのプロビジョニング・デプロビジョニングを自動化する標準仕様だ。商用クラウドでは以前から利用可能だったが、米国政府クラウドでは認証・コンプライアンス要件の関係で機能提供が遅れがちだった。今回の対応により、政府機関や公共部門の契約先でも入退社に伴うアカウント管理の自動化を、商用環境と同じ水準で実現できるようになる。 実務への影響 IT管理者にとって最も影響が大きいのはAuthenticatorのデフォルト変更だろう。BYOD運用で脱獄・root化端末を黙認してきた組織では、該当端末のユーザーが突然サインイン登録できなくなる可能性がある。展開前に対象端末の棚卸しと、ヘルプデスクへの周知をしておきたい。Entra Backup and Recoveryはプレビュー段階の機能を含む可能性が高いので、まずは検証テナントで復元手順を一度実際に回し、緊急時に迷わず使えるようにしておくのが実務的だ。SCIM対応は該当する政府系案件を持つ組織以外には直接の影響は薄いが、Entra側の機能ギャップが着実に埋まっている証拠として押さえておく価値がある。 筆者の見解 今回のアップデートは派手さのないものばかりだが、Identity基盤としてのEntra IDの信頼性を底上げする、地に足のついた強化だと思う。テナント単位の復旧機能がようやく整備されたのは、正直「もっと早くあってよかった」機能ではある。ただそれは裏を返せば、Entra IDがオンプレミスAD時代の運用ノウハウをクラウドでも再現しようとしている証でもあり、応援したいポイントだ。 Authenticatorの改造端末ブロックが既定オンになったことも評価したい。ゼロトラストの基本は「常に検証する」ことであり、デバイスの健全性を前提条件に組み込む今回の変更はその方向性に合致する。エージェントが業務を代行する時代が近づくほど、認証の入口を守るAuthenticatorのような足元の機能こそが効いてくる。派手なAI機能の裏で、こうした地道な改善を積み重ねられるかどうかが、Entra IDが「エージェントの管制塔」として長期的に信頼されるプラットフォームになれるかの分かれ目になるはずだ。 出典: この記事は What’s New in Microsoft Entra: July 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年7月23日14:44 UTC（日本時間同日23:44）、Microsoft AzureのWest USリージョンで、リージョンへの出入りトラフィックが遮断される大規模な接続障害が発生した。復旧は19:41 UTC、影響時間は約4時間57分に及んだ。West USリージョン内で完結するワークロードへの影響はなかったが、リージョンをまたぐ通信を伴うサービスは軒並み機能不全に陥った。Microsoftが公開した予備インシデントレビュー（PIR）によれば、原因は定期的なデバイスメンテナンスの要求をシステムが処理する過程に潜んでいたソフトウェアのバグだった。 原因: メンテナンス要求変換ソフトウェアのバグ Azureのデータセンターでは、特定のネットワーク経路を切り離す必要のあるデバイスメンテナンスを定期的に実施している。本来この処理は、冗長化された2経路のうち少なくとも1経路が正常であることを確認する安全チェックを経て、影響を最小限に抑える設計になっている。 しかし今回、メンテナンス要求をシステムが読み取り可能な指示に変換する過程のバグにより、本来対象ではないはずの追加デバイスまでメンテナンス対象と誤認識された。その結果、データセンターとワイドエリアネットワーク（WAN）を結ぶIPルートが想定より広い範囲で削除され、West USリージョン全体の入出トラフィックが遮断される事態となった。 障害検知後、Microsoftのネットワークチームは14:45から調査を開始し、17:45にメンテナンス変更のロールバックに着手、18:26に完了。全サービスの復旧が確認されたのは19:41だった。 19サービスに連鎖、復旧後も16サービスで障害チケットが残存 影響を受けたサービスはApp Service、Application Gateway、Azure Kubernetes Service（AKS）、Azure Database for PostgreSQL、Azure Cosmos DB、Azure Firewall、ExpressRoute、Microsoft Sentinel、Power BI Embeddedなど多岐にわたり、PIRで名指しされただけでも25以上のサービス・機能に及んだ。IncidentHubの追跡によれば、Azureに依存する外部SaaS側でも連鎖的な障害が観測され、各社のステータスページでの障害認知までに数分から3時間以上のばらつきがあったという。さらに、ネットワーク自体は18:26に復旧したにもかかわらず、16サービスで障害チケットが未解決のまま残ったことも報告されている。ネットワークの物理的な復旧と、その上で動くサービス群の自己回復は別問題であることを示す事例だ。 実務への影響 今回の障害は、West USという特定リージョンの問題にとどまらず、「リージョンをまたぐ通信」に依存するあらゆるサービスに波及した点が実務上の示唆に富む。東日本・西日本リージョンを併用している国内エンタープライズでも、構造的には同じことが起こり得る。 実務上のチェックポイントは次の3点だ。 単一リージョン依存の棚卸し: 本番ワークロードがリージョン内で完結しているか、それとも他リージョンやオンプレミスとの通信（ExpressRoute、VPN Gateway、Peering）を前提にしているかを整理する。後者は今回のような障害の影響を受けやすい。 ダウンストリームの自己回復力の検証: ネットワークが復旧してもアプリケーション側が自動で再接続・再同期されるとは限らない。ヘルスチェック間隔やリトライ・バックオフの設定、手動再起動が必要な箇所を事前に洗い出しておく。 Azure Service Healthのアラート設定強化: リージョン単位の通知だけでなく、依存しているサービス単位でService Health Alertsを構成し、影響範囲の特定を早める。 筆者の見解 Azureをメイン基盤に据えている身として、こうした障害レポートは他人事ではなく毎回目を通すようにしている。今回気になったのは、原因そのものより「メンテナンス要求を変換するソフトウェアのバグ」という、自動化の境界で事故が起きた点だ。ルート削除の安全チェック自体は正しく設計されていたはずなのに、その手前の変換処理でスコープが誤って広がってしまった。安全側に倒す仕組みを作っても、その仕組みへの入力が壊れていれば意味がない。これは他のクラウド事業者にも、自分たちが社内で自動化を組むときにも当てはまる教訓だ。 Azureのプラットフォームとしての信頼性は、こうした障害が一度起きたからといって揺らぐようなものではないと考えている。ただ、応援する立場だからこそ率直に指摘しておきたいのは、復旧後も16サービスで障害チケットが残ったという事実だ。ネットワークが直ったことと、その上で動くサービス群がきちんと自己回復することは別問題であり、この差を埋める作り込みはまだ伸びしろがある。マルチリージョン構成やゾーン冗長を組んでいれば影響を免れたケースも多いはずで、日本のIT管理者にとっては「Azureが落ちたらどうするか」ではなく「自分たちの構成がどこまで単一リージョン依存になっているか」を点検する機会にしてほしい。地道な信頼の積み重ねを、これからも見ていきたい。 出典: この記事は The July 23 2026 Azure West US Outage: IP Route Removal and Downstream Impact の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

MicrosoftはAzure Policyに、Kubernetesネイティブの検証エンジンであるCEL（Common Expression Language）とVAP（Validating Admission Policy）を使ったポリシー評価機能を追加した。Azure Kubernetes Service（AKS）を含むKubernetesクラスタ向けのポリシー適用を、外部のWebhook呼び出しに頼らずAPIサーバー内部だけで完結できるようになる。 Admission Webhookの限界 これまでKubernetes上でガバナンスポリシーを強制する主流の方法は、OPA Gatekeeperなどが採用する「Admission Webhook」方式だった。APIサーバーはPodやDeploymentの作成・更新リクエストを受け取るたびに、外部のポリシーエンジンへHTTP経由で問い合わせ、許可・拒否を判定してもらう。この方式は柔軟な反面、次の課題を抱えていた。 レイテンシ: リクエストのたびにネットワーク越しの往復が発生する 可用性リスク: Webhookサービス自体が単一障害点になりうる。ダウン時にfail-openにすればポリシーが素通りし、fail-closedにすればクラスタ操作全体が止まる 運用の複雑さ: Webhookサーバーの可用性・スケーリング・証明書管理をクラスタ運用者が別途面倒を見る必要がある CEL/VAPが変えること CELはGoogleが開発した軽量な式言語で、Kubernetes APIサーバーに組み込まれている。これを使ってポリシーを記述する仕組みがValidating Admission Policy（VAP）で、Kubernetes 1.30でGA（安定版）となった。VAPを使えば、ポリシー評価ロジックそのものをAPIサーバー内部のCELエンジンが処理するため、外部Webhookへの呼び出しが不要になる。 今回のアップデートで、Azure PolicyはこのVAP/CELをネイティブにサポートした。Azure Policyの管理画面・コンプライアンスダッシュボード・Azure Policy定義言語といった使い慣れたガバナンスの枠組みはそのままに、内部的な評価エンジンとしてCEL/VAPを選べるようになる。既存のRegoベース（OPA Gatekeeper）ポリシーとの併用も可能なため、既存のポリシー資産を捨てずに段階的に移行できる点も実務上重要だ。 実務への影響 AKSクラスタを運用する日本のエンジニア・IT管理者にとって、この変更は次のような意味を持つ。 移行は急ぐ必要はないが、新規ポリシーはCEL/VAPを優先検討する価値がある。外部Webhookが不要になる分、ポリシー評価の遅延とWebhookサーバーの障害点を同時に減らせる Gatekeeperを使い続けている環境でも共存できる。既存のConstraintTemplateをすべて書き換える必要はなく、新規ポリシーや高頻度で評価されるポリシーからCEL/VAPへ切り替えるといった段階的な移行がしやすい 監査ログとコンプライアンスレポートはAzure Policy側に統一される。評価エンジンが変わってもガバナンスの可視化はAzure Policyのダッシュボードに集約できるため、マルチクラスタ運用でも管理の一貫性を保ちやすい 筆者の見解 AzureのKubernetesガバナンスは、これまで「Azure Policyの管理面」と「Gatekeeperの評価エンジン（Rego）」という異なる技術を組み合わせて成立していた部分が大きかった。Regoは表現力が高い一方で学習コストが高く、外部Webhookという構成そのものが運用上の弱点になりやすかった。今回、KubernetesのGA機能であるCEL/VAPをAzure Policyがネイティブに取り込んだのは、部分最適な構成を積み上げるのではなく、Kubernetes標準の仕組みに正面から乗ることを選んだという意味で、素直に評価できる判断だ。「道のド真ん中を歩く」設計を評価する立場からすると、こういう地味だが土台を締め直すアップデートこそ長期的に効いてくる。 ただし、既存のGatekeeper環境を抱える企業にとっては、Rego資産の扱いや移行の順序をどう設計するかという新たな判断が増えることも事実だ。ここでMicrosoftに期待したいのは、単に「両方使えます」で終わらせず、どのポリシーから移行すべきかの指針や自動変換ツールまで踏み込んで用意すること。AKSのガバナンス基盤としての信頼は揺るがないからこそ、移行の実務までカバーしてくれれば、AKSを選ぶ理由がまた一つ増える。 出典: この記事は Introducing Kubernetes-Native Policy Validation with CEL and VAP in Azure Policy の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Azure Logic Appsの統合アカウント機能を裏側で支える約6万本のAzure Functionsアプリケーションを、廃止予定のv1/v2ランタイムから最新のv4分離ワーカーモデルへ、顧客に気づかれることなく移行させた。かかった期間は2年、鍵になったのは「シャドウトラフィック」と呼ばれる検証手法だ。 6万本のFunctionsが支える「見えない基盤」 Logic Appsの統合アカウントは、EDI（電子データ交換）やAS2、X12、XML検証といったB2B連携処理を担う機能で、日本企業でも金融・製造業のシステム間連携で使われている。この処理エンジンの実体はAzure Functionsであり、顧客ごとに個別のFunctionsアプリが動いている。その数が約6万本という規模になる。 問題は、Functionsのv1/v2ランタイムがサポート終了に向かう一方で、6万本すべてを一斉に止めて入れ替えるわけにはいかないことだ。原文タイトルの「飛行中に飛行機のエンジンを交換する」という比喩どおり、サービスを止めずにランタイムそのものを差し替える必要があった。 「シャドウトラフィック」という検証手法 Microsoftが採ったのは、実際に流れてくる本番トラフィックを複製し、旧ランタイム（v1/v2）と新ランタイム（v4分離ワーカー）の両方に並行して流し込むというアプローチだ。旧ランタイムの応答を正としてユーザーに返しつつ、裏では新ランタイムにも同じリクエストを処理させ、両者の出力を突き合わせて差分を検出する。挙動が完全に一致することを確認できたアプリから順に、実際のトラフィックの向き先を新ランタイムへ切り替えていく。カナリアリリースやブルーグリーンデプロイの発想を、6万本という規模とサービス個別の複雑な業務ロジックに合わせて徹底した形と言える。 実務への影響 この手法自体は目新しい発明ではないが、「新旧の挙動が一致することを、推測ではなく実トラフィックで機械的に証明してから切り替える」という規律を、これだけの規模で最後までやり切った点に価値がある。日本企業がAzure Functionsのv1/v2ランタイム廃止に直面している場合、まず自社アプリの現行ランタイムを確認し、移行の猶予期間内に計画的に対応すべきだ。急ぐ必要はないが、放置は禁物である。 また、ランタイムのメジャーバージョン更新やAPI契約変更、データベースエンジンの入れ替えなど、自社システムで「止められないが変えなければならない」場面に直面するエンジニアにとって、シャドウトラフィックによる並行検証は再現性の高い王道パターンとして参考になる。フィーチャーフラグや段階的ロールアウトと組み合わせれば、大規模な基盤更新でも顧客影響をほぼゼロに抑えられることを、Microsoft自身が6万本規模で実証した意義は大きい。 筆者の見解 派手なAI関連の発表が続く裏で、Azureの中核インフラがこれだけ地道な規律を持って更新されているという事実は、素直に評価したい。奇をてらわず、実トラフィックでの検証を積み重ねてから切り替えるという「道のド真ん中」を歩くやり方は、まさにエンタープライズ基盤に求められる姿勢だ。 禁止や強制切り替えではなく、顧客が気づかないうちに安全な状態へ移行させる設計思想も好ましい。ユーザーに我慢や作業を強いず、気づいたら最新かつ安全な状態になっている——これは業務システムの運用で本来目指すべき理想形であり、Azure基盤チームの仕事としては十分に信頼できる水準だと感じる。派手さはないが、こういう仕事の積み重ねこそがAzureというプラットフォームへの信頼を支えている。 出典: この記事は Changing the Engine While the Plane Is Flying: Migrating 60,000 Apps Under Live Load の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftとDatabricksが、2017年から続く戦略的パートナーシップを2030年代まで延長すると発表した。Databricksは中核業務基盤としてAzure Databricksへの依存をさらに深め、次世代Arm基盤「Azure Cobalt」への移行も進める。一方Microsoftは、Databricksが開発した自然言語データ分析エージェント「Genie」を自社製品群に統合していく方針だ。 何が延長されたのか 両社の提携は今回が初めてではない。Azure Databricksはすでに数年前からAzureの一等地サービスとして提供されており、今回の発表はその関係を「延長・深化」させるものだ。ポイントは2つある。1つは、DatabricksがAzure基盤への技術的コミットメントを強めること。具体的には、MicrosoftがAzure上で展開する独自Arm CPU「Azure Cobalt」への移行を進め、コストと電力効率の両面でメリットを引き出す計画だ。もう1つは、DatabricksのAIコワーカー「Genie」をMicrosoft製品ラインへ組み込むこと。GenieはSQLを書けない業務担当者でも自然言語でデータレイクハウスに問い合わせできるエージェントで、これがMicrosoft側のエコシステムに接続されることになる。 なぜこれが重要か 企業のデータ基盤とAIエージェントは、もはや別々に語れない領域になっている。DatabricksはSnowflakeと並ぶレイクハウスの代表格であり、すでに多くの日本企業がAzure Databricksを分析基盤として採用している。今回の提携延長は、その基盤の上で「誰が使うAIか」の選択肢が広がったことを意味する。Microsoftは自社でGenie相当のものをゼロから作るのではなく、実績のあるパートナーの技術をAzureという土俵に呼び込む道を選んだ。これはCopilotのような自社製品一本足打法とは異なる、プラットフォーマーとしての現実的な戦略だ。 実務での活用ポイント すでにAzure Databricksを使っている組織であれば、この提携延長はロードマップの安全性を裏付ける材料になる。Azure Cobalt移行が選択可能になった際は、コスト・電力効率の観点でワークロードごとに移行を検討する価値がある。Genie統合が具体化した段階では、業務部門への自然言語データアクセスをどこまで開放するかが論点になるはずだ。ここではMicrosoft Entra IDによる条件付きアクセスや権限管理を先に設計し、「誰が」「どのデータに」自然言語で問い合わせできるかをガバナンスの土台として整えてから展開するのが筋が良い。 筆者の見解 Azureというプラットフォームへの信頼は、この手のニュースを見るたびに再確認できる。Microsoft Entra IDやAzureの基盤としての立ち位置は、AI時代においてもぶれていない。正直なところ、WindowsやAzure、M365を隅々まで追いかける意味自体は薄れてきていると感じる。それよりも重要なのは、Azureという土台の上でどのAIをどう選んで動かすかだ。その意味で、DatabricksのGenieをMicrosoft自身の製品に取り込むという今回の判断は、正面から勝負できる力があるからこそできる、地に足のついた一手だと思う。最も賢いAIを自前で作る競争では他社に後れを取る場面があっても、最も多くのエージェントが安全に、ガバナンスの効いた形で動くプラットフォームを提供する競争では、Microsoftには十分な勝ち筋がある。今回の提携延長は、その勝ち筋を実直に伸ばす一歩として素直に評価したい。 出典: この記事は Databricks and Microsoft expand partnership to help enterprises bring business context to enterprise AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Azure Monitor配下のAI運用支援機能「Azure Copilot Observability Agent」を正式提供開始(GA)したと発表した。同時に、アラート発生を常時バックグラウンドで監視し、トリアージ・関連アラートの相関分析・詳細調査までを自動で行う新機能「Autonomous Operations(自律運用)」をプレビュー公開している。 Copilot Observability Agentとは何か Azure MonitorのCopilot機能はこれまで、自然言語での質問に応じてKQL(Kusto Query Language)クエリを生成したり、ログやメトリクスの傾向を要約したりする「聞かれたら答える」チャット型のアシスタントだった。今回GAとなったObservability Agentは、この対話型の枠を超え、運用担当者が明示的に質問しなくても、監視対象のアラートやテレメトリを継続的に観察する「常駐型」のエージェントへと役割を広げた。 Autonomous Operationsが変える運用フロー プレビュー公開されたAutonomous Operationsは、アラートが発火した瞬間からバックグラウンドで動き出す。重要度のトリアージ、関連する複数アラートの相関付け、過去の類似インシデントとの突き合わせ、ログ・メトリクス・トレースを横断した原因調査までを、運用担当者が気づく前に済ませておく。いわゆるAIOps(AI for IT Operations)の実装であり、SRE・運用担当者が最初に見る画面は「生のアラート」ではなく「一次調査済みのサマリー」に変わっていく。 実務への影響 日本の大規模Azure環境を運用するIT管理者・SREにとって最大の恩恵は、アラート疲れ(Alert Fatigue)の軽減だ。深夜のオンコールで大量のアラートを一つずつ手作業で相関付ける負担が減り、一次トリアージ済みの情報から対応を始められる。 導入にあたっては、このエージェント自体を一つの「非人間アイデンティティ(NHI)」として扱う視点が欠かせない。Azure Monitorやログへの参照権限を最小権限で設計し、書き込み・変更を伴う操作へは段階的にしか権限を広げない。現時点では「調査まで」に留まっている設計は堅実であり、まずは非本番環境や参照専用モードで挙動を確認してから本番に展開するのが安全な進め方だ。既存のServiceNowやPagerDutyなどのITSM連携がどこまで効くかも、導入前に確認しておきたいポイントになる。 筆者の見解 Azureのプラットフォームとしての信頼は、この手のAIOps機能が増えても揺らがない。むしろ今回の話で注目すべきは、Observability Agentの調査能力そのものより、それが誰の権限で、どこまでの範囲で動くのかという「エージェントのガバナンス」の設計だと感じている。 生成AIの進化スピードを考えると、個々のAI機能がどれだけ賢いかを追いかけ続けることにはあまり意味がない。それよりも重要なのは、大量に増えていくAIエージェントを、Microsoft Entra IDのような管制塔の下で安全に権限管理し、監査ログを残せる仕組みがあるかどうかだ。マイクロソフトは最先端のAIモデルを作る競争では必ずしも先頭を走っていないが、多数のエージェントを安全に稼働させるプラットフォームを提供する競争では強みを持っている。今回のAutonomous Operationsが「調査までは自律、実行は人間の承認」という現実的な線引きから始めているのは好印象で、この段階を丁寧に踏んでから権限を広げていってほしい。 出典: この記事は Azure Copilot Observability Agent is generally available, with autonomous operations in preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoft Corp.は2026年7月20日、AMD(Advanced Micro Devices)が開発するAI特化ラック参照設計「Helios」をAzureのインフラに採用すると発表した。同時に、AMDの次世代GPU「Instinct MI455X」を72基搭載したHeliosラックを基盤とする新インスタンス「ND MI455X v7」シリーズをはじめ、計3つの新しいAzure仮想マシンファミリーを発表している。 Heliosとは何か HeliosはAMDが製造パートナー向けに提供する参照設計（ブループリント）で、1ラックあたり72基のMI455 GPUを搭載する。MI455は432GBのHBM4メモリと19.6Tbpsのメモリ帯域幅を持ち、新しいコアアーキテクチャ「CDNA 5」を採用する。 特徴的なのは、GPUだけでなくPensando製DPU（データ処理ユニット）とEPYC CPUを組み合わせている点だ。ストレージ制御やネットワーク暗号化といったインフラ管理タスクをDPUに任せることで、CPUリソースを顧客アプリケーション側に多く割り当てられる設計になっている。CPUには次世代の「Venice」シリーズを採用し、TSMCの2nmプロセスとチップレットを積層する「SoIC」技術を使う。ラック全体は液冷方式を採用し、オープンソースのネットワークプロトコル「UALoE」でチップ間通信を行う。AMDのリサ・スーCEOは「AMDとMicrosoftは何年もかけて高性能インフラを共同構築してきた。今日、その提携をAMDのAIソリューション全体に拡張する」とコメントしている。 3つの新Azureインスタンス Heliosを基盤とする「ND MI455X v7」は、AIエージェントや検索など推論ワークロード向けに最適化されている。もう一つの「HDv2」はGPUではなくCPU中心の処理、たとえばAIエージェント向けデータセットの前処理に最適化されており、EPYC Vulcanコアを最大500基、メモリ4TB、フラッシュストレージ32TBまで搭載できる。3つ目の「HXv2」は、半導体設計（EDA: Electronic Design Automation）向け既存シリーズの改良版で、科学シミュレーションなどより幅広い用途に対応する。5GHz超で動作するEPYCVulcanコアを176基搭載し、コアあたりキャッシュは従来比50%増、800Gb InfiniBandによりMPIベースの大規模シミュレーションにも対応するという。あわせて、仮想化処理をCPUから専用チップにオフロードする「Azure Boost」についてもAMDと共同最適化を進める。Heliosラックの出荷は今年後半に開始される予定だ。 実務への影響 日本のIT現場にとって直接効いてくるのは、AIエージェントや検索基盤をAzure上で運用する際の「GPU調達の選択肢が増える」という点だ。NVIDIA一辺倒だった大規模GPU需要にAMD系インスタンスが加わることで、需給ひっ迫時の確保のしやすさやコスト競争が働く可能性がある。推論ワークロードを設計する際は、ND MI455X v7が使えるようになった段階でベンチマークを取り、既存のNVIDIA系インスタンスと比較検討する価値がある。 また、AIエージェント向けにデータ前処理基盤を持つチームはHDv2のような大容量メモリ・フラッシュ構成のCPUインスタンスを、製造業や半導体設計に関わるエンジニアはHXv2のHPC/EDA向け強化を、それぞれ選定肢として押さえておきたい。いずれも一般提供の時期や地域展開はAzureの発表を継続的に確認する必要がある。 筆者の見解 Azureというプラットフォームの基盤としての信頼は、今回の件でむしろ裏付けられたと感じる。MetaやOpenAI、Oracleに続いてMicrosoftもAMDの主要クラウド顧客に加わった形だが、これは目新しい賭けというより、王道の手堅い判断だ。GPU供給を単一ベンダーに依存させず、実績のあるハードウェアの選択肢を顧客に用意する——これはAzureが本来強みを発揮すべき層であり、派手さよりも堅実さが評価されるべき動きだと思う。 個人的には、AIの世界で「どのAIモデルを使うか」を細かく追いかける意味が薄れてきている中で、その土台となるインフラの多様性・信頼性こそがクラウドベンダーの実力を測る指標になると考えている。AMDという有力な選択肢を正面から取り込めるだけの基盤を持っていることは、Azureの地力の証明でもある。あとはND MI455X v7が実際にどれだけの性能とコスト競争力を日本のユーザーに届けられるか、一般提供のタイミングで注視したい。 出典: この記事は Microsoft will use AMD’s AI-optimized Helios racks in Azure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはAI開発基盤「Microsoft Foundry」に新機能「AI Gateway Control Plane」を追加した。App Service上で動くAIエージェントを、Azure API Management（APIM）を裏側の実行基盤としながらFoundryの管理画面から一元的に登録・可視化できるようにするものだ。Foundry以外で動く外部エージェントも同じ管制塔に取り込める点がポイントで、App Service専用のAI基盤を個別に構築・運用する負担を軽減する狙いがある。 AI Gateway Control Planeの正体 API ManagementはこれまでもAzureにおけるAIゲートウェイの定番パターンだった。トークン単位のレート制限、セマンティックキャッシュ、コンテンツセーフティ、バックエンドの負荷分散など、LLM呼び出しを本番運用するうえで必要なガバナンス機能を一手に引き受けてきた実績がある。今回の変更は、この実績あるAPIMの機能を「Foundryの管理画面の裏側」に組み込み、開発者が個別にAPIMインスタンスをプロビジョニングし、ポリシーをゼロから設定する手間をなくした点にある。App Serviceで動くエージェントは、Foundry側の管理画面からエンドポイントを登録するだけで、レート制御や可観測性の恩恵を受けられるようになる。 App Serviceにとっての実質的な変化 これまでApp Service上でAIエージェントを動かす場合、ゲートウェイ機能が欲しければAPIMインスタンスを別途構築し、App Serviceとは別のライフサイクルで運用する必要があった。Control Planeの導入により、Foundry側がその管理レイヤーを肩代わりする形になり、社内で稼働する複数のエージェント（Foundry上で作ったものも、社内の別チームが独自に構築した外部エージェントも）を同じ場所で棚卸しできるようになる。これは「エージェントが増えすぎて誰が何を動かしているか把握できない」という、AIエージェント運用が本格化した組織が必ず直面する課題への回答だ。 実務への影響 日本のIT管理者にとって重要なのは、この機能がガバナンスと可視性の話であるという点だ。エージェントが部門ごとに乱立し始めると、コスト管理、セキュリティレビュー、監査対応のいずれも後手に回る。App Service上で既にAIエージェントを運用しているなら、独自に組んだAPIMポリシーをFoundry Control Plane側に寄せられないか棚卸しする価値がある。現時点ではプレビュー機能の可能性が高いため、リージョン提供状況や既存APIM構成との共存パターンを事前に確認してから移行を検討したい。エージェントの数が今後さらに増えることを前提に、早い段階で登録・可視化の仕組みを整えておく方が、後から棚卸しするより圧倒的に楽になる。 筆者の見解 今回の話は「AIエージェントを禁止するのではなく、安全に使える仕組みを提供する」という発想がそのまま形になった好例だと思う。エージェントの野良運用を止めようとして利用を制限すればするほど、現場は見えないところで独自にエージェントを動かし始める。それよりも、公式に提供された登録・可視化の仕組みが一番便利だと現場が感じる状態を作る方が、結果的にガバナンスは効く。APIMという実績あるコンポーネントを裏側に据え、Foundryという管制塔から個別インフラの面倒を減らすという設計思想は、まさに王道を行く堅実な選択だ。 Azureプラットフォームとしての信頼性や、Microsoft Entra IDを中心とした認証・認可の枠組みは今後も揺るがないと見ている。エージェントの数が指数関数的に増える時代において、「最も賢いAIを作る」競争と「最も多くのエージェントが安全に動作する基盤を提供する」競争は別物であり、後者でMicrosoftが積み上げてきたAPIMやEntra IDの資産は確実に効いてくる。App Serviceのような既存ワークロードにこの管制塔機能を波及させ続けることこそ、Microsoftが正面から勝負できる領域だと思う。 出典: この記事は Microsoft Foundry Now Has an AI Gateway Control Plane — What Changes for App Service の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、オンプレミス環境で完結するAI推論基盤「Foundry Local on Azure Local」の機能を強化し、複数ノードで構成するKubernetesクラスタ上での推論スケーリングと、高速推論ランタイム「vLLM」への対応を追加したと発表した。GPUリソースを自動的に最適化するチューニングプランナーや、複数レプリカ間でリクエストを振り分けるルーティング機能も新たに加わり、金融・医療・官公庁など機密データを外部に出せない業種向けの「ソブリンAI」基盤としての完成度を高めている。 Foundry LocalとAzure Localとは何か Azure Localは、旧Azure Stack HCIの後継にあたるオンプレミス向けハイパーコンバージド基盤で、Azure Arcを通じてクラウドと同じ管理体験をデータセンター内で実現する製品だ。Foundry Localは、その上でAzure AI Foundryと同等のモデルカタログ・推論APIをインターネット接続なしで動かせるようにしたコンポーネントで、小規模言語モデル（SLM）やオープンウェイトモデルをオンプレミスのGPUサーバー上で運用できる。 今回の機能強化のポイント マルチノードKubernetesクラスタでの推論スケーリング: 従来は1台のGPUサーバーの能力に縛られていた推論処理を、複数ノードに分散して負荷に応じて拡張できるようになった vLLMランタイム対応: PagedAttentionなどの技術で高スループットを実現するOSSの推論エンジンvLLMを、Foundry Local上で選択できるようになった GPU向け自動チューニングプランナー: 搭載GPUとモデルの組み合わせに応じて、バッチサイズやメモリ配分などのパラメータを自動的に最適化する マルチレプリカ向けリクエストルーティング: 複数のモデルレプリカにリクエストを適切に振り分け、可用性とスループットを両立させる いずれも、単体サーバーでの検証段階から、本番運用に耐えるスケールアウト構成への橋渡しとなる機能群だ。 なぜ「ソブリンAI」が必要なのか 生成AIの業務活用が進むほど、金融業界のガイドラインや医療情報の外部持ち出し制限、防衛・自治体の機密情報保護など、データを国内・自社ネットワーク境界の外に出せない要件との衝突が表面化している。Foundry Local on Azure Localは、推論処理そのものをオンプレミスで完結させることで、この種の規制要件と生成AI活用の両立を狙った基盤だ。 実務への影響 日本のIT管理者にとって重要なのは、この強化がAzure ArcやMicrosoft Entra IDによる一元管理を維持したまま、オンプレミスでのAI推論をスケールできる点だ。クラウドとオンプレミスで別々の管理体系を持つ必要がなく、ガバナンスの一貫性を保てる。 PoC段階では単一ノードで十分でも、本番投入後にユーザー数やモデルサイズが増えるケースは多い。マルチノード構成への移行はネットワーク設計やGPUキャパシティプランニングを後から作り直すコストが大きいため、要件定義の段階からスケールアウトを見込んだ設計を検討しておくことを勧める。また、vLLM対応により、Llama・Phi・Mistralといったオープンウェイトモデルをオンプレミスで効率よく動かす選択肢が広がる点も、コスト最適化を検討する材料になる。 筆者の見解 Azureというプラットフォームへの信頼は、この手の機能強化を見るたびに揺らがないと感じる。Foundry Local on Azure Localは、AIモデルそのものの優劣を競う土俵ではなく、「どのAIを、どこまで安全に、どこで動かすか」を統制する基盤としての価値を積み上げる動きだ。Entra IDやArcによる一元管理を保ったまま、オンプレミスでもクラウドと同じ運用体験を提供できる点は、地に足の着いた正攻法だと思う。 一方で、こうした細かい機能を逐一追いかける意味は正直薄れてきているとも感じる。マルチノード対応やvLLM対応といった個々の機能よりも、「オンプレミスでも安全にAIを回せる基盤がある」という大枠を押さえておき、あとは実際に手を動かして試す方が学びが早い。 この基盤の価値をさらに引き出せるかどうかは、今後どこまでモデル選択の自由度を広げられるかにかかっている。オープンウェイトモデルへの対応だけで終わらせるのはもったいない。プラットフォームとしての力があるのだから、そこにもう一段踏み込んでこそ、ソブリンAI要件を抱える企業から正面から選ばれる基盤になるはずだ。 出典: この記事は Build, deploy, and govern sovereign AI with Foundry Local on Azure Local の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月17日、Tech Communityブログで「From AI Adoption to AI Governance」と題する記事を公開し、Azure API Management（APIM）をMicrosoft Foundry（旧Azure AI Foundry）の前段に配置してAIモデル利用を一元的に統制する構成を解説した。社内でAI活用が広がるほど「誰が」「どのモデルを」「どれだけ」使っているかが見えなくなる、という課題に対する具体的な処方箋である。 APIMを「AIゲートウェイ」として使う発想 これまで多くの現場では、開発者やチームがMicrosoft Foundryのモデルエンドポイントに直接APIキーで接続していた。この状態が広がると、利用状況の可視化ができない、チームごとのコスト配分ができない、キーが漏洩しても検知できない、といった統制不能な状況に陥る。 APIMをFoundryの手前にリバースプロキシとして挟むことで、次のようなポリシーを一箇所に集約できる。 トークン単位でのレート制限・クォータ管理（従来のリクエスト数制限では不十分なLLM特有の課金構造に対応） 複数モデルデプロイやリージョン間でのロードバランシング セマンティックキャッシュによる重複リクエストのコスト削減 Application Insightsへの一元的なログ集約とトークン消費の可視化 Microsoft Entra IDのマネージドID・アプリ登録を軸にした認証統合（APIキーの個別配布からの脱却） 記事ではあわせて、こうしたGenAIゲートウェイポリシーの利用にはAPIMのv2ティア（Standard v2 / Premium v2）が前提になる点、およびApp Service上でエージェントをホストする構成に関する仕様変更にも触れており、既存構成からの移行を検討する際の注意点として押さえておきたい。 実務への影響 日本のエンタープライズでも、部門ごとにFoundryやAzure OpenAIのエンドポイントを個別契約し、気づけばAPIキーが乱立している、というケースは珍しくない。この状態では月次のAI利用コストが読めず、セキュリティ部門もどの部署が何を呼んでいるか把握できない。 明日から着手できる対策は、まずAPIMをAI利用の唯一の入口として位置づけ、アプリケーション側からFoundryへの直接呼び出しを禁止することだ。APIMとFoundry間の認証はAPIキーではなくマネージドIDに統一し、サブスクリプションキーとEntra IDのアプリ登録を紐付ければ、チーム単位のコスト按分や監査ログの追跡が一気に楽になる。IT管理者はこの構成を「AI版の踏み台サーバー」として説明すると社内の理解を得やすいだろう。 筆者の見解 AzureとMicrosoft Entra IDの基盤としての信頼性は揺るがない、というのが筆者の一貫した立場だ。今回の構成はまさにその強みを体現している。APIMとEntra IDでAIモデルへのアクセスを統制するというのは、結局のところ「人間ではなくサービスプリンシパルやマネージドIDといった非人間アイデンティティ(NHI)をどう管理するか」という話であり、これはゼロトラストの延長線上にある本質的な課題だ。常時発行されたAPIキーがそこら中に転がっている状態こそが最大のリスクであり、APIMを唯一の入口にする発想は正しい方向だと思う。 Microsoft Foundry経由であれば、Azureという基盤を手放すことなく、そのときどきで最良のAIモデルを選んで動かせる。最先端モデルの開発競争でMicrosoftが常に先頭を走っているとは言えないが、多数のエージェントを安全に運用できるプラットフォームを提供する競争では十分に勝負できる力を持っている。今回のようなガバナンス機能の地道な積み上げこそが、その強みを実際の現場価値に変えていく道だろう。正面から勝負できるはずのプラットフォームなので、この路線を継続してほしい。 出典: この記事は From AI Adoption to AI Governance - Using APIM as the Gateway for Azure AI Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

2026年7月14日、Microsoftは「SQL Server 2016」の延長サポートを終了した。以後は新たなセキュリティ更新プログラムが提供されず、脆弱性が見つかっても放置されたままの状態になる。この節目に合わせて、Microsoft社内のカスタマーエンジニアが自社ブログで、ESU(拡張セキュリティ更新プログラム)・Azure SQLへの移行・新バージョンへのアップグレードという3つの選択肢を整理して解説した。 何が終わったのか — SQL Server 2016のライフサイクル SQL Server 2016は2016年にリリースされ、5年間のメインストリームサポート(2021年7月終了)を経て、延長サポート期間に入っていた。延長サポート期間中は無償のセキュリティ更新のみが提供され、新機能や非セキュリティ系の修正は行われない。そして今回、その延長サポートも尽きた。つまり今後SQL Server 2016に新たな脆弱性が発見されても、Microsoftから修正プログラムが配布されることはない。 用意された3つの延命・移行策 ①ESU(拡張セキュリティ更新プログラム) Software Assurance付きのライセンスを持つ組織向けに、最大3年間、有償でセキュリティ更新の提供を継続する制度。オンプレミス環境で「今すぐには移行できない」システムのための猶予措置と位置づけられる。重要なのは、SQL ServerをAzure VMやAzure Arc対応サーバーとしてAzure上で稼働させれば、ESUが追加コストなしで提供される点だ。Azureへ寄せるだけで実質的にセキュリティ更新の心配から解放される。 ②Azure SQLへの移行 Azure SQL Managed Instance(オンプレミスのSQL Serverとほぼ互換性を保ったPaaS)、Azure SQL Database(フルマネージドだがアプリ側の見直しが必要)、あるいはAzure VM上のSQL Server(リフト&シフト)という3系統がある。パッチ適用・バックアップ・高可用性構成といった運用負荷をAzure側に肩代わりさせられるのが最大の利点だ。 ③SQL Server 2022への新規アップグレード オンプレミス運用を継続する場合は、現行のSQL Server 2022(またはそれ以降)への移行が王道。パフォーマンス向上やAzureとの連携機能強化が図られている。 実務への影響 日本のIT現場では、基幹システムや業務パッケージがSQL Server 2016に紐づいたまま塩漬けになっているケースが少なくない。ベンダーサポートが切れた業務パッケージや、改修コストが見合わない古い社内システムが典型例だ。まず着手すべきは「棚卸し」——社内にどれだけのSQL Server 2016インスタンスが存在するかを把握することから始まる。Azure Migrateのようなツールでインベントリを取得し、システムごとに「ESUで延命」「Azure SQLへ移行」「アップグレード」のどれを選ぶかを仕分けるロードマップ作りが急務だ。特にAzure Arcでオンプレミスサーバーを登録すれば、ハードウェアはそのままで無償ESUの対象にできる場合があり、コストを抑えた延命策として検討する価値がある。 筆者の見解 今回の話は目新しい技術の話ではなく、地味な「サポートライフサイクル」の話だが、実はここにMicrosoftの設計のうまさが表れていると感じる。ESUという延命策を用意しつつ、Azureに寄せれば無償になるという仕組みは、「移行しないと詰む」という脅しではなく「移行すれば一番得をする」という自然な誘導になっている。禁止や強制ではなく、公式ルートが一番便利だと思わせる仕組みこそが正しいやり方だと筆者は考えている。 一方で、現場でよく見かけるのが「今動いているから大丈夫」という判断だ。これは過去にActive DirectoryのSID重複問題などで痛い目を見た教訓と同じで、パッチが提供されない状態で「動いている」ことと「安全である」ことはまったく別の話だ。延長サポートが切れた瞬間から、たとえ障害が起きなくても、そのサーバーは静かにリスクを蓄積し続ける。 Azureというプラットフォーム自体への信頼は今も揺るがない。レガシー資産の延命と移行の両方に現実的な道を用意できるのは、長年エンタープライズを支えてきたMicrosoftの底力だろう。派手さはなくても、こういう地味な「王道」の仕組みをきちんと維持し続けてほしいし、この分野では今後も正面から安心して頼れる存在であってほしいと思う。 出典: この記事は SQL Server 2016 Reaches End of Support: A Customer Engineer’s Perspective on What’s Next の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Azure Storageの「レガシー（Legacy）Blob Storageアカウント」を2026年10月に完全廃止する。対象アカウントを期限までに汎用v2（General-purpose v2、以下GPv2）へ移行しない場合、Microsoftが自動的に移行を実施し、結果として課金体系が変わる可能性がある。日本語での言及がまだ少ない話題だけに、該当アカウントを持つ企業は今のうちに確認しておきたい。 レガシーBlob StorageとGPv2、何が違うのか 従来のレガシーBlob Storageアカウントは、アクセス層（Hot/Cool/Archive）の設定が「アカウント単位」でしかできなかった。これに対しGPv2は、Blobごとの個別階層設定に加えて、ライフサイクル管理による自動階層移行、不変（Immutable）Blobストレージ、Event Grid連携、そしてBlob以外のTable・Queue・Filesサービスへの対応まで含む、Azure Storageの標準構成だ。料金体系も一貫しており、Microsoftとしてはプラットフォームを単純化し、全顧客に最新機能と統一された課金モデルを提供する狙いがある。 廃止までのタイムラインと「自動移行」の重み 2025年9月: 廃止方針を発表 2026年9月: レガシーBlob Storageアカウントの新規作成を停止 2026年10月: 完全廃止。残存するレガシーアカウントはGPv2へ自動移行され、以降アクセスがブロックされる 注意すべきは、Microsoftの公式文書が「移行しないという選択は、Microsoftが代わりに移行することへの同意とみなす」と明記している点だ。つまり何もしなければ、自分の与り知らぬところで移行が実行され、気づいたときには課金額が変わっている、という展開になりかねない。 実務への影響 日本のエンジニア・IT管理者が今すぐ取るべき行動は明確だ。まずAzure Resource GraphやAzureポータル、CLIを使って自社のレガシーBlob Storageアカウントを棚卸しする。幸い、大半のBlobオンリーのワークロードはGPv2移行にあたってコード変更が不要だ。ただし、階層を意識しない古いコストロジックやハードコードされた料金前提が残っていないかは要チェックとなる。移行前にはAzure料金計算ツールで新しい課金モデル（Blobごとの階層別課金・トランザクション課金）を試算しておくと安心だ。また、多数のアカウントを抱える組織では、deployIfNotExistsのAzure Policyを使えば対象アカウントの検知から非破壊的なアップグレードまで自動化できる。手動で個別対応するより、ポリシーベースで横展開する方が現実的だろう。 筆者の見解 Azureのプラットフォームとしての信頼は、今も揺るがないと筆者は考えている。ストレージ層のような地味な基盤コンポーネントを、派手なAI発表の裏で地道にモダナイズし続ける姿勢は、実は最も評価すべき部分だ。ただ、今回のような重要な廃止告知について日本語での発信がまだ薄いのは正直もったいない。せっかく価値のある移行パスを用意しているのだから、日本の顧客によりわかりやすく届ける努力があってもいいはずだ。 もう一つ、これは筆者が一貫して主張していることだが、「今動いているから大丈夫」という発想はクラウド運用において通用しない。今回のレガシーBlob Storageのように、明示的に手を打たなければ気づかぬうちに構成や課金体系が変わるケースは、Azureに限らず今後も起こり得る。定期的な構成の棚卸しを「やらされ仕事」として片付けるのではなく、標準的な運用プロセスに組み込んでおくことが、こうした変更に振り回されないための最善策だ。 出典: この記事は Legacy Blob Storage account retirement overview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月、Azure Blob StorageのSFTP（SSH File Transfer Protocol）アクセスにおいて、Microsoft Entra IDによる認証を一般提供（GA）として公開した。これまでBlob StorageのSFTP機能を使うには、ストレージアカウントごとにローカルSFTPユーザーを作成し、パスワードを個別管理する必要があった。今回のGAにより、Entra ID認証でMFA・条件付きアクセス・RBAC/ABACとの統合が可能になる。プレビュー期間中に指摘されていたABAC（属性ベースアクセス制御）の権限判定の不整合も解消され、コピーやリネームといったサブ操作への対応も加わった。 SFTPという「枯れたプロトコル」にEntra IDが統合される意味 Azure Blob StorageはネイティブでSFTPプロトコルをサポートしており、レガシーシステムやパートナー企業とのファイル連携で今も広く使われている。従来この機能を利用するには、ストレージアカウントごとにローカルSFTPユーザーを作成し、パスワードやSSH鍵を個別に管理しなければならなかった。ユーザー数が増えるほどローテーション作業や退職者アカウントの削除漏れが積み上がる、典型的な「野良アカウント」問題を抱えやすい仕組みだった。 今回のGAでは、このSFTP認証にMicrosoft Entra IDを利用できるようになった。SFTPクライアント（人間のユーザーでもサービスでも）がEntra IDで認証し、Azure RBAC（ロールベースアクセス制御）やABAC（属性ベースアクセス制御）によってコンテナ単位・パス単位でアクセス権を制御できる。MFAや条件付きアクセスポリシー（デバイス準拠、接続元IP制限、リスクベース制御など）もそのまま適用される。ローカルSFTPユーザー方式と共存できるため、既存環境から段階的に移行することも可能だ。 GA版での品質改善 プレビュー期間中はABACの権限判定に不整合があり、特定の条件下で意図しないアクセスが許可・拒否されるケースが報告されていた。GA版ではこの判定ロジックが修正され、コピーやリネームなどのサブ操作についても正しく権限チェックが行われるようになった。派手さはないが、本番採用の可否を左右する重要な品質向上だ。 実務への影響 日本の製造業・金融業では、パートナー企業とのファイル交換にいまだSFTPを使っているケースが多い。EDI連携やバッチ処理系のシステムでは、SFTPが唯一の外部インターフェースということも珍しくない。こうした環境では、ローカルSFTPユーザーの棚卸しとパスワードローテーションが、地味だが重いIT運用負荷になっている。 実務での活用ポイントは次の通りだ。 既存のローカルSFTPユーザーを洗い出し、Entra ID認証への移行計画を立てる（両方式は共存可能なので段階移行できる） 条件付きアクセスポリシーで接続元IPやデバイス準拠を要求し、ネットワーク層だけに頼らない認証層での制御を強化する RBAC/ABACでコンテナ・パス単位の最小権限アクセスを設計する サービス間連携であればマネージドIDやサービスプリンシパルを使い、そもそもパスワードという資格情報自体をなくす方向を検討する 筆者の見解 SFTPのような枯れたプロトコルは、クラウド移行後も「動いているから触らない」扱いになりがちで、結果としてID管理の穴になりやすい領域だ。今回の変更は華やかさこそないが、そこに正面からEntra IDを統合してきた点は評価したい。 ローカルSFTPユーザーのパスワード管理は、Non-Human Identities（NHI）管理が抜け落ちる典型的な現場だ。人間のアカウントはEntra IDで一元管理していても、サービス用・連携用のアカウントだけ別管理になっているケースは多く、結局そこがボトルネックになって自動化が進まない、という状況をよく見かける。今回のGAでSFTP接続もEntra IDの管制下に置けるようになったことは、ネットワーク層・認証層・認可層の3層防御という観点でも意味が大きい。 欲を言えば、常時有効な資格情報ではなく、Just-In-Timeでの一時的なアクセス権付与ともっと自然に組み合わせられる設計にしてほしいところだ。特権的なファイル転送経路ほど「常時アクセス可能」がリスクになる。とはいえ、地味な機能を一つずつID基盤に統合していくのはMicrosoftらしい堅実な仕事であり、AIをめぐる派手な競争の裏でこうした足元を固める動きこそ、Azureというプラットフォームへの信頼を支えている。目立たないニュースだが、実務で長く効いてくるのはこういうアップデートだ。 出典: この記事は Enterprise Identity Meets Secure File Transfer: Entra ID Public Preview on Azure Blob Storage SFTP の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Foundry（旧Azure AI Foundry）のモデルカタログに、Moonshot AI製のコーディング特化モデル「Kimi K2.7 Code」がパブリックプレビューとして追加された。中国のAI研究機関Moonshot AIが開発したKimiシリーズの最新版で、長時間にわたる複雑なコーディングタスクをこなすことに特化したモデルだ。 Kimi K2.7 Codeの技術的な特徴 前バージョンのK2.6と比較して、Kimi K2.7 Codeは「思考トークン」（モデルが回答を生成する前に内部で使う推論用トークン）の使用量を約30%削減しながら、複数ステップにまたがる長期のコーディングタスクの成功率を高めているという。 コンテキストウィンドウは256Kトークンに達し、これは大規模なコードベース全体や複数ファイルにまたがる仕様書を一度に読み込ませるのに十分な容量だ。またマルチステップのツール呼び出し（ファイル編集、テスト実行、ビルドコマンドの実行などを連続して行う「エージェント的」な動作）にも対応しており、コーディングエージェントの裏側モデルとして使うことを想定している。 Microsoft Foundryは、Azure OpenAIのモデル群に加えて、Meta Llama・Mistral・DeepSeek・xAI Grokなど自社製以外のモデルも一つのカタログで横断的に扱えるプラットフォームだ。今回のKimi K2.7 Code追加も、その「モデルの選択肢を増やす」路線の一環と言える。 実務への影響 日本のエンジニアやIT管理者にとって重要なのは、「新しいモデルが一つ増えた」という以上に、そのモデルをどこで、どう安全に使うかという点だ。 Foundry経由でKimi K2.7 Codeを使う最大のメリットは、Microsoft Entra IDによるアクセス制御や監査ログ、データ処理リージョンの指定といったガバナンス機能をそのまま適用できることにある。Moonshot AIは中国のAI企業であり、モデル単体を個人契約のAPIキーで直接呼び出すと、データの取り扱いやコンプライアンス上の説明責任があいまいになりがちだ。Foundryのカタログ経由であれば、企業のセキュリティポリシーの枠内でモデルを評価・利用できる。 長時間コーディングタスクでの思考トークン削減は、そのままAPIコストの削減に直結する。エージェント型のコーディング支援を業務で使っているチームは、既存のワークフローの中でKimi K2.7 Codeをベンチマークし、コスト対効果を検証する価値がある。256Kの大きなコンテキストウィンドウは、モノレポや大規模プロジェクトでの活用にも向いている。 筆者の見解 今回の件で興味深いのは、モデル単体の性能競争ではなく、Microsoft Foundryという「基盤」の戦略の方だ。マイクロソフトは最先端のAIモデルを自社だけで作り切る競争では必ずしも先頭を走っていない。しかし、Entra IDによるガバナンスの下で多種多様なモデルを安全に選べる場を用意する競争では、むしろ有利な立場にいる。 エンジニアが「このタスクにはこのモデルが速い・安い」と気づいたとき、会社のセキュリティポリシーの外側でこっそりAPIキーを契約して使ってしまう、いわゆるシャドーAIが一番のリスクだ。禁止で対処しようとすると必ず抜け道が生まれる。今回のようにFoundryのカタログへ正式に追加し、IT管理者が許可した範囲で使える状態を作ることこそが、現実的な解決策だと考える。 正直なところ、Windows・Azure・M365のアップデートを一つひとつ逐一追いかける意味は薄れてきている。大事なのは個別モデルのスペック表を追い回すことではなく、Foundryという土台を活かして「使えるAIを選べる自由」をどう業務に落とし込むかだ。マイクロソフトには、Entra IDを軸にした管制塔としての役割を今後も伸ばしてほしい。基盤を作る力は間違いなくあるのだから、そこを正面から伸ばしていくべきだと思う。 出典: この記事は Introducing Kimi K2.7 Code in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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