Azure

MicrosoftがAzure上でArm64ベースの自社設計CPUチップ「Cobalt 200」を搭載したVMのプレビュー提供を開始した。同時に、AI学習向け自社設計アクセラレータ「Maia 200」がすでにMicrosoftのデータセンターで本番稼働（production）に入っていることが明らかになった。汎用コンピュート向けとAI学習向け、自社シリコンの「両輪」が出揃った形だ。 Cobalt 200とMaia 200—2つの自社チップが担う役割 Cobalt 200（汎用コンピュート向け） Cobalt 200はArm64アーキテクチャをベースにMicrosoftが独自設計したCPUチップだ。前世代のCobalt 100はAzure内部サービス向けに限定利用されていたが、Cobalt 200では外部顧客向けVMとしてプレビュー提供が始まった。 Arm64アーキテクチャの特性として、Intel/AMD系のx86 CPUと比べて電力効率が高く、スケールアウト型ワークロード——Webサーバー、API、マイクロサービス、コンテナワークロードなど——との相性が良い。コスト最適化の観点でも、同等パフォーマンスをより低い単価で実現できるケースが出てきている。 Maia 200（AI学習向け） Maia 200はAI・機械学習モデルの学習処理に特化した自社設計のアクセラレータチップだ。現時点では顧客が直接選択して使えるVMとして提供されているわけではなく、Microsoftが自社のAIサービス基盤——Azure OpenAI ServiceやMicrosoft Copilotの推論・学習基盤——を動かすためにデータセンター内部で稼働している。 今回のポイントは、Maia 200がプレビューや実証実験ではなく本番稼働（production）に移行済みであることだ。デモレベルのチップではなく、実際のサービストラフィックを支える基盤として機能している。 なぜこれが重要か—Nvidia依存という巨大リスクへの回答 AIインフラ競争において、クラウド大手が直面してきた最大の課題の一つが「Nvidia GPU依存」だ。H100やB200といったNvidia製GPUは需給がひっ迫し、調達コストも膨大。さらに、Nvidiaのロードマップに自社のAI事業が縛られるという戦略的リスクが常に付きまとう。 GoogleはTPU（Tensor Processing Unit）、AWSはTrainium/Inferentia、そしてMicrosoftはMaia——主要クラウドが独自AIチップを持つのは、まさにこのリスクヘッジであり、長期的なコスト構造の改善を狙った動きだ。 Maia 200が本番稼働に入ったということは、Microsoftの自社シリコン戦略が「研究開発フェーズ」から「実運用フェーズ」へ確実に移行したことを意味する。 実務への影響—日本のエンジニア・IT管理者が知っておくべきこと Cobalt 200 VMのプレビュー参加を検討する Linux系ワークロード——コンテナ、マイクロサービス、Webバックエンド——を抱えているエンジニアにとって、Cobalt 200 VMは試す価値がある選択肢だ。Docker multi-arch（マルチアーキテクチャ）対応のコンテナイメージを使っていれば、多くのケースでほぼシームレスに移行できる。コスト最適化の一手として検討に値する。 Arm64移行前の互換性チェックを忘れずに .NET（特に.NET 6以降）、Python、Node.js、GoはArm64対応が十分に進んでいる。一方で、古いネイティブライブラリや一部のWindows依存コンポーネントはx86エミュレーションが必要になる場合がある。本番移行前にCI/CDパイプラインでのビルドターゲット追加と動作確認を行うことを強く推奨する。 AIサービスコスト構造の長期的変化を見据える Maia 200の内部展開が進むにつれ、Azure OpenAI ServiceやAzure AI Foundryのコスト構造が中長期的に変化する可能性がある。自社シリコンの普及はクラウド事業者のマージン改善要因となるため、AIサービスの価格競争力向上につながる展開も考えられる。発注先のコスト動向として注視しておく価値はある。 筆者の見解 MicrosoftのCobalt 200・Maia 200による自社シリコン戦略は、プラットフォームとして正しい方向性だと評価している。クラウド基盤として顧客に安定したサービスを届けるには、ハードウェア層から独自に最適化できる能力が必要で、AWSやGoogleが先行していた領域だった。 Maia 200が本番稼働に入ったことは「デモができる」ではなく「本物のトラフィックで動かせる」を証明した点で意味が大きい。自社AIサービスの品質と応答速度を自社チップで支えられる体制が整いつつある。 次の関心は、Maia 200がいつ顧客向けオプションとして解放されるかだ。現状ではAzure内部のワークロードに閉じており、顧客がMaia 200の恩恵を受けるのはAzure OpenAI等のサービス経由に限られる。NvidiaのGPUを直接指定して使いたい高度な学習ワークロードを持つ顧客にとって、Maia 200を「選択できる」日が来ればプラットフォームとしての差別化はさらに強まるはずだ。 Azureがエージェント・AI基盤として長期的に信頼できる舞台であることは変わらない。その足元を支えるハードウェア投資として、今回の発表は着実な前進だ。 出典: この記事は Microsoft launches VMs based on Cobalt 200 chip in preview, Maia 200 already in production の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはBuild 2026にて、Azure Functionsのサーバーレスエージェントランタイムをパブリックプレビューとして発表した。これにより、これまでイベント駆動の関数実行基盤として知られていたAzure Functionsが、AIエージェントのホスティング・実行プラットフォームとしての役割を担うことになる。 .agent.mdという新しいプログラミングモデル 今回の最大の特徴は、エージェントの定義を .agent.md というMarkdownファイル一枚で完結させる点だ。従来のエージェントフレームワークではPythonやTypeScriptで複数ファイルにまたがってエージェントを記述するのが一般的だったが、Azure Functionsのアプローチはこれを覆す。 YAMLフロントマターでトリガー種別やメタデータを宣言し、Markdownの本文がそのままエージェントへの指示（システムプロンプト）になる。MCPサーバーの接続設定や追加ツールの定義は mcp.json と agents.config.yaml という補助ファイルに分離されており、構成管理の観点でも整理しやすい。 たとえば「毎日15時にWeb上の技術ニュースを収集してメールで要約を送る」エージェントは、以下のような .agent.md 一枚で実現できる： name: Daily Tech News Email trigger: type: timer_trigger args: schedule: “0 0 15 * * *” You are a news assistant. When triggered, fetch today’s top tech news and email a summary to $TO_EMAIL. Pythonプロジェクトとその依存関係の管理が不要になる。この簡潔さはDevOpsコストの削減に直結する。 対応トリガーとコネクタの広さ エージェントを起動できるトリガーは既存のHTTP・Timer・Service Bus・Event Hubs・SQL・Cosmos DBに加え、TeamsメッセージやOutlookメール・カレンダーイベント・SharePointアイテムへの接続バックトリガーが新たに追加された。つまり、誰かがTeamsにメッセージを投稿したことをきっかけにエージェントが動き出す、といった業務自動化シナリオが標準で実現できる。 さらに、エージェントからアクセスできるコネクタは 1,400以上。Microsoft 365・Teams・Outlook・SharePoint・Salesforce・ServiceNowなど、企業の主要SaaSが一通りカバーされている。これはPower Automateのコネクタカタログと共通の資産を活用したものだ。 コールドスタートとコスト 実務者が真っ先に気にするであろう2点について、Azure Functionsプロダクトチームは明確に回答している。 コールドスタートについては「エージェントランタイム固有の追加遅延はない。インフラがボトルネックになるのではなく、LLMの推論時間がボトルネックになる」とのことだ。Flex Consumptionプランのスケールtoゼロ特性はそのまま維持される。 コストについては「エージェント税（追加料金）は存在しない」と明言。通常のFunctions実行と同一の秒単位課金モデルが適用される。 実務への影響——日本のエンジニア・IT管理者に向けて 既存のAzure Functions運用スキルがそのまま活きる Managed Identity認証・Application Insightsによるトレース・Flex Consumptionのスケーリング設定——これらは既存のFunctions開発者がすでに知っているオペレーションモデルだ。エージェント化しても「関数が起動したらエージェントが動く」という概念モデルで理解できる。学習コストを低く抑えながらエージェント運用に踏み込めるのは、実際のシステム移行を担うエンジニアにとって大きなメリットだ。 ...

Microsoft Build 2026（6月2日開催）で、Azure Integration Servicesに関する6つの重要発表が行われた。Logic Apps AutomationのSaaS SKU新設、C# SDKによるコードファースト開発、API ManagementのAIゲートウェイ強化など、統合基盤全体がAIエージェントの「生産インフラ」として機能するよう大幅に再設計されている。 Azure Logic Apps Automationとは何か 最大のトピックは「Azure Logic Apps Automation」の登場だ。パブリックプレビューとして公開され、auto.azure.com からアクセスできる。 既存のLogic Apps Standardの「置き換え」ではない点に注意が必要だ。同じランタイム・同じコネクタ基盤の上に、SaaS型の体験を乗せた新しいSKUとして位置づけられている。主な特徴をまとめると： AIアシスタント内蔵: 自然言語でワークフローを説明すると、AIがアクション設定・式記述・インラインコード生成まで自動で下書き エラスティックスケール: vCPU秒単位の従量課金。アイドル時はゼロスケール。年間コミットも席単位ライセンスも不要 ガバナンス2層構造: 「プロジェクト」（セキュリティ境界）と「アプリケーション」の2層で管理。ネットワークポリシー・コネクタポリシー・承認済みAIモデルをプロジェクト単位で一括設定し、配下のアプリが継承する ガバナンス設計は企業ニーズに沿っている。「開発者のスピード」と「中央管理」を両立させる構造は、IT部門とビジネス部門の間でよく起きる綱引きを緩和する仕組みだ。 AIエージェント対応も最初から織り込まれている。エージェントループのオーケストレーション、Microsoft Foundryのホスト済みエージェントをキャンバスから直接呼び出す機能、GitHub Copilotのようなエージェントハーネスのためのマネージドサンドボックス（シェルアクセス付き）も備える。 なお、現時点ではVNet統合は未対応。VNetが必要な場合は引き続きLogic Apps Standardが正解で、VNet対応はロードマップ上の項目にとどまっている。 提供リージョン（プレビュー時点）: East Asia・Sweden Central・Australia East・North Central US・UK South・Southeast Asia・West US。Japan EastおよびJapan Westは現時点で含まれていない。 コードで書くLogic Apps：C# SDK登場 「デザイナー画面が苦手でコードで書きたい」という開発者にとって待望の発表がLogic Apps Standard SDK（NuGetパッケージ Microsoft.Azure.Workflows.Sdk）だ。 workflow .AddTrigger(WorkflowTriggers.BuiltIn.Request()) .Then(WorkflowActions.BuiltIn.ParseJson(…)) .Then(WorkflowActions.Managed.Office365.SendEmail(…)) .Then(WorkflowActions.BuiltIn.Response()); フルーエントAPIでワークフローを記述すると、既存のLogic Apps Standardランタイムが実行するJSONにコンパイルされる。新しいランタイムではないため、既存資産との互換性は維持される。 メリットとして得られるものは大きい： 型安全性とIntelliSenseによる開発体験の向上 git diff でワークフロー変更がコードレビューできる コンパイル時エラー検出でデプロイ前に問題を潰せる Condition・ForEach・Switch・Until・ScopeといったControl Flowがファーストクラスで使える CustomCode アクションでC#メソッドをインラインで書ける ソフトウェアエンジニアがLogic Appsに参入しやすくなり、GitベースのCI/CDパイプラインへの統合も自然に進む。 ...

Microsoftは2026年6月、Azure FunctionsにLogic AppsおよびPower Platformで長年使われてきた1,400以上のマネージドコネクタをファーストクラスのトリガーとして利用できるプレビュー機能を発表した。ローコードツール専用だったコネクタのエコシステムが、コードファーストな開発者にも開かれた形だ。 マネージドコネクタとは Azure Logic AppsやPower Automateには、Microsoft 365・Salesforce・Slack・ServiceNowといった外部サービスと連携するための「マネージドコネクタ」が1,400種類以上用意されている。接続先の認証情報や通信処理をMicrosoft側が管理（マネージド）してくれるため、開発者は外部サービスの細かい接続仕様を自前で実装せずに済む。これまでこのコネクタ群はローコード・ノーコードの世界での利用が中心で、コードで書くAzure Functionsからは直接活用する仕組みが存在しなかった。 何が変わったか 今回のアップデートにより、Azure Functionsのトリガーとして1,400以上のマネージドコネクタを直接バインドできるようになった。「Office 365のメールを受信したときにFunctionを起動する」「SharePointにアイテムが作成されたらFunctionを呼び出す」「SalesforceのレコードがアップデートされたらFunctionをトリガーする」といった処理が、Logic Appsを中継せずにコードだけで実現できる。 これまで必要だったLogic Apps → Azure Functionsという2段構成を、Azure Functions単体に集約できるシナリオが生まれた。 対応トリガーの例 現在プレビューで利用できる代表的なトリガーは以下の通り： Office 365メール受信 — 特定条件のメールが届いたときにFunctionを起動 Microsoft Teamsへのメッセージ投稿 — チャネルへの投稿をトリガーに処理を実行 SharePointアイテム作成 — ドキュメントライブラリへのファイル追加などをトリガーに Salesforceレコード更新 — CRMのデータ変更をAzure側でリアルタイムに処理 現状のサポート範囲と今後 現在プレビューとして提供されているのはC#（.NET 10 Isolated Worker）のみ。PythonおよびNode.jsは「近日対応予定」とされている。Azure Functionsの実務利用でPythonやNode.jsを選んでいるチームも多いため、これら言語のサポートが出揃った時点が実質的な評価開始のタイミングになるだろう。 実務への影響 アーキテクチャの設計選択肢が広がる 「ちょっとしたイベント処理はコードで書きたいが、コネクタはLogic Appsのものを使いたい」というジレンマは、Azure開発の現場でよく耳にする話だ。今回の対応により、単純なイベント起動型の処理はAzure Functionsに集約し、複数コネクタ間の複雑なフロー制御や承認ワークフローはLogic Appsに任せる、という明確な役割分担が設計しやすくなる。 コスト面の検討ポイント Logic AppsとAzure Functionsでは課金モデルが異なる。Logic Appsはコネクタの種類と実行回数に応じた従量課金が発生するケースがある。Azure Functionsでのマネージドコネクタ利用時の課金体系はプレビュー中に詳細が変わる可能性もあるため、本番移行前に必ず確認しておきたい。 M365連携の自動化がコードで書ける 日本のエンタープライズでもMicrosoft 365は標準プラットフォームとなっている。TeamsのメッセージングやSharePointのドキュメント管理、Exchange Online経由のメール処理を、C#のコードで直接イベントドリブンに書けるようになることは、Azure開発者にとって実用的な選択肢が一つ確実に増えることを意味する。 コネクタ品質のばらつきに注意 1,400以上のコネクタすべてが等しく信頼できるわけではない。Logic Appsでも一部のコネクタはサードパーティ提供であり、品質・更新頻度・エラー時の挙動にばらつきがある。Functionsで使う場合も同様で、本番運用に投入する前には接続先サービスのレート制限・認証フロー・障害時の挙動を必ずステージング環境で検証してほしい。 筆者の見解 このアップデートは地味に見えるが、実は「アーキテクチャの設計判断を変えうる」変更だと感じている。 Logic AppsとAzure Functionsは「ローコード vs コードファースト」という軸で住み分けてきたが、今回のマネージドコネクタ対応でその境界線が意図的に曖昧にされた。両者をより柔軟に組み合わせられる環境に向かっている方向性は正しいと思う。 ...

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

MicrosoftはAzure FunctionsにおけるGoの第一級言語サポートをパブリックプレビューとして公開した。Flex Consumptionプランで利用可能になり、Goエンジニアが慣れ親しんだ標準パッケージをそのままサーバーレス関数の記述に使えるようになった。 Goが「第一級市民」になるとは何か これまでAzure FunctionsでGoを動かすには、カスタムハンドラーという迂回路を使う必要があった。独自プロセスとしてGoバイナリを起動し、Functions Workerとのやり取りを自分で実装する形だ。便利とは言えない。 今回のアップデートで、この制約が取り払われた。HTTPハンドラーは標準のhttp.HandlerFuncをそのまま使って記述できる。 func HttpHandler(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, “Hello from Azure Functions!”) } Goを書いたことがある人ならすぐに理解できる、いつも通りの書き方だ。非HTTPトリガー（タイマー、メッセージキュー等）もcontext.Contextと型付きペイロードで処理でき、Goらしい型安全なコードが書ける。 サポートされるトリガー一覧 パブリックプレビュー時点で以下のトリガーが利用可能だ。 トリガー種別 用途の例 HTTP REST APIエンドポイント、Webhookの受信 Timer 定期バッチ処理 Service Bus 非同期メッセージ処理 Event Hubs ストリームデータの取り込み Event Grid イベント駆動アーキテクチャ Cosmos DB データ変更の検知・連鎖処理 Blob Storage ファイルアップロード後の処理 実務でよく使うトリガーは一通り揃っている。プロトタイプから本格的なプロダクション用途まで対応できる水準だ。 なぜこれが重要か——Goとサーバーレスの相性 Goはコンパイル後のバイナリが小さく、起動が速い。サーバーレス関数において最大の課題の一つがコールドスタートの遅延であることを考えると、この組み合わせは理にかなっている。 AzureのFlex ConsumptionプランはコールドスタートとスケーリングをAzureがマネージドで制御するプランだ。ここにGoの軽量さが加わることで、従来のC#やNodeよりも低レイテンシなサーバーレス関数を実現できる可能性がある。 また、GoはクラウドネイティブなOSS（KubernetesやTerraform等）の実装言語として事実上の標準に近い地位にある。こうしたエコシステムに慣れた開発者がAzureに参入しやすくなるという意味もある。 日本のIT現場への影響 Goチームを抱える組織にとっては、バックエンドコードをAzure FunctionsにそのままデプロイできるためCI/CDパイプラインの統一が容易になる。言語ごとに別のデプロイ方法を使い分けるコストが下がる。 マイクロサービス移行中のチームにとっては、既存のGoサービスの一部をFunctions化してFlex Consumptionの従量課金メリットを得るという選択肢が現実的になった。 スタートアップや少人数チームでは、GoのシンプルさとAzure Functionsのインフラ管理不要という特性を組み合わせることで、少ない人手で高い可用性を実現しやすくなる。 実務での第一歩としては、まずHTTPトリガーの関数から始めるのが無難だ。Goの標準ライブラリだけで動くシンプルなAPIエンドポイントをFlex Consumptionに乗せ、コールドスタート時間と実行コストを計測してから適用範囲を広げていくアプローチを推奨する。 筆者の見解 Goサポートのアナウンスは、Azure Functionsのエコシステムとして正しい方向の一手だと思う。 これまで「AzureでGoを使いたければApp ServiceかAKSを選べ」という暗黙のメッセージがあった。それが変わる。Goを書く開発者にとってAzureの選択肢が広がるのは歓迎すべきことで、Azureのプラットフォームとしての懐の深さにもつながる。 標準パッケージをそのまま使えるという設計方針も評価できる。独自フレームワークや特殊なSDKを覚えさせるのではなく、「Go開発者がGoを書けばいい」という姿勢は、道のド真ん中を歩くアプローチとして正しい。 一方で、プレビュー段階での成熟度については慎重に見ていく必要がある。Flex Consumptionプランは比較的新しく、本番導入にあたってはSLAや運用ノウハウの蓄積状況を自分たちで確認することが重要だ。 Azureはインフラプラットフォームとしての信頼性は揺るがない。あとはこういった地道な言語サポートの拡充が、実際に開発者体験の改善として積み重なっていくかどうか。Goチームを抱えている組織は、まずFlex Consumptionプランのプレビューで試してみる価値は十分にある。 出典: この記事は Announcing Go support in Azure Functions (Preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は Azure SQL Database の長期保存（LTR）バックアップに対する WORM（Write Once, Read Many）不変保護機能を一般提供（GA）として公開した。グローバル管理者を含む最高権限のアカウントでもバックアップの変更・削除が一切できなくなる仕組みで、金融・医療・公共機関など規制要件の厳しい業種向けにデータ保護を大幅に強化する。 Azure SQL LTR バックアップ不変保護とは Azure SQL Database には標準の PITR（Point-in-Time Restore）とは別に、数ヶ月〜最大 10 年単位でバックアップを保持する LTR（Long-Term Retention）機能がある。今回 GA になったのは、この LTR バックアップに対する immutability（不変性）保護だ。 主な特性は以下の通り： WORM 保護: バックアップが作成されると、設定された保持期間中は一切の変更・削除が不可能 管理者も例外なし: サブスクリプション所有者・グローバル管理者を含むいかなるアカウントもバックアップを変更できない Microsoft Entra ID 認証との統合: Entra ID ログインを利用する SQL Database インスタンスではセキュリティ体制がさらに強化 コンプライアンス監査対応: SOC 2、ISO 27001、PCI DSS、HIPAA 等の監査証跡として機能する変更不可能なバックアップを証明できる 技術的な実装の背景 従来の Azure SQL バックアップは、技術的には管理者権限で削除・変更が可能な状態だった。これは「内部脅威（インサイダー脅威）」や「管理者アカウントの乗っ取り」シナリオでデータが失われるリスクを意味していた。 今回の機能は Azure Blob Storage 側の Immutable Storage ポリシーを活用し、バックアップデータを WORM 状態にロックする。一度コミットされた immutability ポリシーは Azure インフラレベルで保護されるため、アプリケーション層や IAM 層の操作では迂回できない構造になっている。 ...

Microsoftは2026年6月のProduct Terms更新で3ヶ月連続となるAIライセンス条件の大幅改定を実施した。Copilot StudioのCustomer Copyright Commitment（CCC）適用指定の削除、Agent 365の前提ライセンス要件の明文化、Azure Local向けAzure Hybrid Benefitの適用縮小など、企業の調達・コンプライアンス担当者に直結する変更が複数含まれている。 3ヶ月連続の改定——何が動いているのか 直近の動きを振り返ると、3月はAzure Arcの簡素化、4月はハイリスクAIコンテンツへのガードレール強化、5月はAIエージェントへのマルチプレクシング規定拡大とRPA出力のAIトレーニング禁止、そして6月は「Azure AI Services」という包括定義の新設だ。Azure Foundry経由でデプロイされるすべてのモデル（サードパーティ含む）にEnterprise AI Services行動規範が適用される形になった。 個別のモデルプロバイダー条件は外部ドキュメントページに集約された。これは管理の一元化という観点では合理的だが、追跡すべきドキュメントが増えることも意味する。 最重要変更①：Copilot StudioのCCC指定が告知なし削除 Customer Copyright Commitment（CCC）とは、AI生成コンテンツが第三者の著作権を侵害した場合の法的リスクをMicrosoftが顧客に代わって負う知的財産補償制度だ。「MicrosoftのAIが作ったものはMicrosoftが守る」という企業向けの大きな売り文句でもあった。 6月更新前、Power Platform Service Specific TermsにはCopilot Studioが「Covered Product（対象製品）」として明記されていた。これが今回の更新でひっそりと削除された。変更説明には一切記載がない。 重要な補足として、CCC自体の保護が消えたわけではない。CCCのRequired Mitigationsページ（最終更新：2026年3月20日）にはCopilot Studioが引き続き掲載されており、保護は継続している。ただしProduct Terms本文から消えたということは、CCCドキュメントページを個別に監視していなければ変更を見落とすリスクがある。さらに、外部モデルをCopilot Studioに接続した場合、そのモデルの出力はAzure OpenAI経由でなければCCC対象外になる点も忘れてはならない。 最重要変更②：Agent 365のライセンス前提条件が明文化 Agent 365の利用には以下のいずれかが必要と初めて明示された。 Microsoft 365 E5 F5 Defender and Purview Business Premium 裏を返せば、Microsoft 365 E3、Business Basic、Business Standardでは利用できない。E3のみでAgent 365活用を検討していた組織には追加投資が求められる。段階的なエージェント活用計画を描いていた場合、ライセンス計画の見直しが必要だ。 その他の注目変更点 Azure Hybrid Benefit for Azure Localの適用縮小：従来は比較的広く適用できたが、ハイパーコンバージドインフラ（HCI）構成に限定された。Azure Localを使ったオンプレミスコスト最適化を計画している組織はアーキテクチャ要件を再確認すること。 SPUR（サービスプロバイダー利用規約）へのAIトレーニング禁止拡大：5月のRPAトレーニング禁止がSPLA（サービスプロバイダーライセンス契約）ホスティング会社向けに拡大。Office Suites、Project、Visio経由で処理したデータをAIモデルのトレーニングに使うことが禁止された。 非公表変更：Customer LockboxがCompliance Services一覧から削除され、「Microsoft Discovery」という未告知サービスがLimited Accessレジスターに追加された。前者は何らかの移行が背景にある可能性があり、後者はまだ詳細不明だ。 ...

Microsoft Entraが2026年6月、FIDO2パスキーの組織展開を支援する「Registration Campaigns」機能を一般提供開始した。管理者はサインイン時にパスキー登録を促すキャンペーンを設定できるようになり、フィッシング耐性認証の普及に向けた現実的な移行パスが整備された。あわせてLinux向けフィッシング耐性MFAのGA、App Deactivation機能の追加など、ゼロトラスト戦略の土台を固める複数のアップデートが加わった。 パスキー普及の「最後の1マイル」を埋めるRegistration Campaigns FIDO2パスキーが優れた認証方式であることは広く知られているが、実際の組織展開で最大の壁となるのが「既存ユーザーへの登録誘導」だ。Registration CampaignsはサインインフローのUI内で自然な形でパスキー登録を促せる設計で、強制することなく段階的な普及を後押しできる。 Windows HelloのデバイスバウンドパスキーはMicrosoft Entra参加・登録済みデバイスでなくても利用可能で、生体認証やPINによるフィッシング耐性サインインが実現する。ただしWindowsのインタラクティブコンソールサインインはサポート対象外のため、既存の展開シナリオとの整合性確認は必要になる。 Linux向けフィッシング耐性MFAが一般提供開始 Microsoftのidentity brokerを通じたLinuxデスクトップ向けフィッシング耐性MFAが一般提供（GA）になった。対応ディストリビューションはUbuntu 24.04/26.04およびRHEL 8/9/10で、WindowsとmacOSに続きLinuxも同水準のフィッシング耐性MFAを利用できる環境が整った。 クラウドネイティブな開発環境でLinuxを使うエンジニアが多い日本のエンタープライズ企業にとっては待望のアップデートだ。CI/CDパイプラインやクラウドシェル環境でのMFA強化に直結する。 ガバナンス強化：孤立アカウント検出とApp Deactivation ガバナンス面でも実用的な機能が複数追加された。 孤立アカウントの自動検出（Discovery Reports） 接続済みアプリケーション内のすべてのアカウント（孤立アカウント含む）を可視化するレポート機能。アクセス権のギャップ特定やアプリケーションオンボーディング支援に活用できる。Microsoft Entra ID GovernanceまたはEntra Suiteが必要。 App Deactivation アプリケーションを削除せずに無効化できる機能。セキュリティ調査中の不審アプリ停止や、設定データを保持したまま一時停止したいケースに対応する。無効化されたアプリは新規アクセストークン取得もサインインも不可になる一方、設定・権限・メタデータは保持される。後からの再有効化も可能で、完全削除と異なり「証跡を残しつつ止める」用途に向いている。 テナント間セキュリティグループ同期 複数のEntraテナントをまたいでセキュリティグループとメンバーシップを同期できる。M&Aや企業グループ内IT統合のシナリオで有効な手段が増えた。 Azure AD B2C移行支援：500万オブジェクト以上の大規模移行に対応 High Scale Compatibility（HSC）モードにより、500万オブジェクト以上を持つ大規模なAzure AD B2Cテナントが、ユーザーの再登録やパスワードリセットなしにMicrosoft Entra External IDへ移行できる。B2CポリシーアナライザーでGA移行準備を評価した上で、アカウントチームと連携して進めることが推奨されている。 パブリックプレビュー：ドメインレスSAML連携と秘密度ラベル パブリックプレビューに入った機能のうち特に注目したいのが2つだ。 ドメインレスSAML連携 外部ユーザーがメールドメインのマッチングなしに、自社IdP（アイデンティティプロバイダー）の認証情報でサインインできるようになる。従来の制約が緩和され、パートナー企業やサプライヤーとのフェデレーション設計が柔軟になる。 EntraセキュリティグループへのMicrosoft Purview秘密度ラベル M365のラベルポリシーをEntraセキュリティグループにも適用可能になる。ゲストアクセス制御を含むグループ設定のガバナンスをMicrosoft Purviewと統合して管理できる。 実務への影響 パスキー展開を検討している管理者へ Registration Campaignsは強制ではなく「促す」設計のため、ユーザー体験を損なわずに移行を進められる。まずパイロットグループにキャンペーンを設定して登録率を測定し、全展開の可否を判断するアプローチが現実的だ。 Linux環境のセキュリティ担当者へ 対応ディストリビューション（Ubuntu 24.04/26.04、RHEL 8/9/10）を確認し、identity brokerの導入を優先検討すべきだ。開発環境全体でフィッシング耐性MFAを適用できるかどうかは、ゼロトラスト戦略の実効性に直結する。 マルチテナント管理者へ テナント間グループ同期を活用する場合、どのテナントをマスターとして管理するかのガバナンスポリシーを先に決めておくことが重要だ。技術的な機能が整備されても、運用ルールが曖昧なままでは混乱が生じやすい。 筆者の見解 今回のEntraアップデート群を見ると、Microsoftがアイデンティティ基盤に着実にリソースを投じていることが伝わってくる。特にRegistration Campaignsによるパスキー誘導は、「理想の認証方式を現場に浸透させる」という現実的な課題に正面から向き合った実装で、評価できる。 ゼロトラスト戦略においてアイデンティティが土台であることは言うまでもない。生成AIエージェントが組織内で動き始める中、Non-Human Identities（NHI）の管理と人間のアカウント管理を統合的に扱えるプラットフォームの重要性はさらに高まっている。EntraがそのコントロールプレーンとしてAgent IdentityのSponsorship管理まで備え始めているのは、長期的に見て正しい方向性だと思う。 一方で、毎月これだけ多くの機能が追加され続けると、現場のIT管理者が「何から手を付けるべきか」を見失うリスクも出てくる。機能の充実と、それを実際に使いこなすためのドキュメントや移行支援の充実は、必ずしも同じペースでは進まない。Microsoftには機能を増やすことと同じくらいのエネルギーを、その伴走支援に向けてほしいと、長年利用してきた立場から率直に思う。 Linux向けMFAのGA、App Deactivation、テナント間グループ同期——いずれも地味に見えて、実際の現場では「あれ、これできないんだっけ」と困るポイントを埋める機能だ。そういった堅実な積み上げがEntraへの信頼を支えている。 ...

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

Microsoftは2026年6月のMicrosoft Build 2026において、Azure HorizonDBのパブリックプレビューを発表した。AIエージェントワークロードを念頭に一から再設計されたPostgreSQL互換のフルマネージドデータベースサービスで、エンタープライズ向けの信頼性とAIネイティブ機能を一体化している。 Azure HorizonDBとは何か Azure HorizonDBは、単なるPostgreSQLのホスティングサービスではない。LLMエージェントが大量のデータにリアルタイムでアクセスするAIネイティブな用途を主軸に設計されたデータベース基盤だ。 Microsoftによれば、自己管理のPostgreSQLと比較してトランザクション性能と検索速度が最大3倍向上している。スケール面でも以下の数値が示されている。 最大 128TBのデータベースをサポート 最大 15台のリードレプリカによるスケールアウト 可用性ゾーン間でのサブミリ秒コミットレイテンシー PostgreSQL互換を完全に維持しており、既存のORM・ドライバー・pgvectorを使ったコードの大部分をそのまま移行できる点は実務上のアドバンテージになる。 AIネイティブ機能の核心：DiskANNベクター検索 Azure HorizonDBが既存サービスと一線を画す最大の特徴は、DiskANN（球面量子化対応）をデータベースエンジンに直接統合した点だ。 DiskANNはMicrosoft Research発の近似最近傍探索アルゴリズムで、ベクターを正規化・圧縮して球面距離（角度距離）で比較する。この球面量子化により、大規模ベクターインデックスをメモリに載せきれない場合でも低ストレージコストで高速な類似検索を実現できる。pgvectorのようなメモリ依存型の実装と比べて、大規模運用でのコスト効率が高い。 さらに、インDB AIモデル管理機能により、エンベディング生成などのAI処理をデータベース内で完結させる構成も視野に入る。データの移動を最小化し、レイテンシーと複雑性を下げる設計思想だ。 エンタープライズセキュリティ：Entra IDとの統合 セキュリティ面では、Microsoft Entra IDとのネイティブ統合を標準装備する。データベースへのアクセス認証・認可を組織のIDインフラに一元化でき、プライベートエンドポイントによるネットワーク分離、保存中・転送中の暗号化も含まれる。 これはAIエージェントがデータベースに自律的にアクセスする構成——いわゆるNon-Human Identity（NHI）の管理においても重要だ。エージェントごとにEntra IDのサービスプリンシパルやマネージドIDを割り当て、最小権限でアクセス制御できる基盤が整っている。 実務への影響 RAG・AIエージェント基盤の有力候補 RAG（Retrieval-Augmented Generation）構成では、埋め込みベクターを格納・検索するデータベースの選定が性能のボトルネックになりやすい。Azure Database for PostgreSQLでpgvectorを運用しているチームが、ベクター検索性能の壁にぶつかっている場合、Azure HorizonDBは現実的な移行先の選択肢になる。 PostgreSQL互換を維持しているため、アプリケーションコードの改修コストは低く抑えられる。 既存Azureインフラとの親和性 Entra ID統合・プライベートエンドポイント・Azure Monitor連携など、すでにAzureを基盤としている組織であれば追加設定のコストが小さい。Azure Kubernetes ServiceやAzure Container Appsと組み合わせたマイクロサービス構成での採用が現実的なシナリオだ。 VS Code向けのPostgreSQLツール拡充も同時発表されており、開発者ループ全体をAzureエコシステム内で完結させやすくなっている。 筆者の見解 Azure HorizonDBは、Azureのデータベースサービス群の中で久々に「コンセプトが一本通っている」と感じる製品だ。「AIエージェントが使うデータベース」という軸を最初から据えた設計は、後付けでベクター検索を追加してきたサービスとは本質的に異なる。 DiskANNの採用は技術的に正しい判断だと思う。Microsoft Researchが長年培ってきた研究成果を自社プラットフォームに組み込む——これをきちんとやれるのはMicrosoftの強みであり、こういうところで真価を発揮してほしい。 Entra ID統合も地味に効いてくる。AIエージェントがデータに自律的にアクセスする時代においては、NHIの認証・認可管理は必ず課題になる。Entra IDを中心に一元管理できる設計を最初から持っているのは、エンタープライズ採用の現場でかなり助かるはずだ。 もっとも、現時点ではパブリックプレビューだ。価格体系・GAのタイムライン・マルチリージョン対応の詳細はまだ不明な部分が多い。PostgreSQL互換をうたう以上、オープンエコシステムの維持とのバランスも長期的に注視する必要がある。 AIエージェント基盤を本気で検討しているチームは、パブリックプレビューの段階から触れておく価値は十分にある。GAを待ってから評価し始めると、競合との差が開く可能性があることも頭に入れておきたい。 出典: この記事は Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月12日、Microsoft Build 2026の流れを受けてAzureの大規模アップデートを発表した。コンピュート・ストレージ・データベース・AI・セキュリティ・開発ツールと幅広い領域で多数の機能がGA（一般提供）に到達しており、運用チームは今すぐ対応が必要なアクションアイテムも複数存在する。 Azure Cobalt 200 VM：エージェントAI時代のコンピュート基盤 今回のアップデートで最も注目すべきは Azure Cobalt 200 VM の登場だ。従来比50%のパフォーマンス向上を実現し、エージェント型AIワークロードへの最適化が施されている。 AIエージェントが複数タスクを並列処理しながら継続的に推論を行う「エージェント型ワークロード」は、従来の単発API呼び出しとは根本的に異なる負荷特性を持つ。Cobalt 200はこうした新しい計算パターンに対応するために設計されており、長期的なAIインフラの主力になると見ている。 コンピュート面ではほかにも以下がGA到達している： NCv6（GPUコンピュートシリーズ最新世代） Premium SSD v2 の非ゾーンVM対応 また、GuestRDMAとLinux NVMeのAzure Site Recovery（ASR）サポートがプレビュー入りした。ハイパフォーマンスコンピューティング環境の災害対策を検討しているチームには見逃せない動きだ。 ストレージ：Azure FilesのGAと注意すべき課金変更 Azure Files が正式GAとなった。エンタープライズ向けフルマネージドファイル共有として安定フェーズに入ったと評価できる。 ただし、同時に 課金ポリシーの変更 が発表されており注意が必要だ： cool・cold・archiveティアの 最小請求オブジェクトサイズ が明確化（2026年7月1日より適用） GPv1アカウントおよびレガシーBlobアカウント の新規作成が2026年6月1日より制限開始（すでに適用済み） GPv1アカウントをまだ利用しているケースは、マイグレーション計画を早急に立てる必要がある。「今動いているから大丈夫」は通用しない。 データベース：PostgreSQLとAzure SQLの強化 データベース領域では複数の重要なGA到達がある。 PostgreSQL では、メンテナンスコントロール機能と開発者向け PostgreSQL Hub がGA。Azure SQL では Microsoft Entra IDログイン のサポートと イミュータブル（不変）バックアップ保護 が追加された。EntraログインサポートによってAzure SQLがID管理の一元化エコシステムに深く組み込まれ、イミュータブルバックアップはランサムウェア対策の観点で実質必須の機能だ。 Cosmos DB ではパーティション単位の自動フェイルオーバー、チェンジフィードの強化、AIアプリ向けベクターデータ同期用の埋め込み機能が追加された。なお、Cosmos DB Synapse Linkは2029年3月31日に廃止 が決定しているため、利用中の組織はマイグレーション計画のスケジューリングを始めてほしい。 AI・開発者ツール：Fable 5がFoundryに統合 AI・開発者ツール領域では見逃せない動きがある。 Anthropic Fable 5がAzure AI Foundryに統合 され、Copilotとのインテグレーションも確認されている。Microsoft Azure AI Foundryを通じて外部の最先端モデルを活用できるエコシステムが着実に広がっている。 ...

Microsoftは、Azure Container Appsの新リソースタイプ「Sandboxes」を発表した。AIエージェントが外部コードやツールを安全に実行するためのエフェメラルなセキュアコンピュート環境で、GitHub Copilot Cloud SandboxesおよびAzure AI Foundry Hosted Agentsの基盤インフラとしてすでに採用されている。 Azure Container Apps Sandboxesとは AIエージェントが実際に役立つ仕事をするには、コードを書くだけでなく「実行する」必要がある。問題は、外部から渡されたコードや動的に生成されたスクリプトの実行が、本質的にセキュリティリスクを伴う点だ。 Azure Container Apps Sandboxesは、このリスクに正面から向き合うために設計されたリソースタイプだ。一言で言えば「使い捨てのセキュアな実行箱」——エージェントがコードを走らせるたびに新しい隔離環境を起動し、タスクが終われば破棄する。 3つの技術的特徴 1. サブ秒起動 従来のコンテナは、起動に数秒〜数十秒かかることが多い。AIエージェントがコードを実行するたびにこれだけ待たされていたら、対話的な開発体験は成立しない。Sandboxesはサブ秒（1秒未満）での起動を実現し、エージェントとのやりとりを自然なテンポで維持できる。 2. スナップショットベースの一時停止・再開 実行状態をスナップショットとして保存し、必要なときに即座に再開できる。長時間の計算タスクや、人間の確認を挟む対話型エージェントフローでも、状態を失わずに作業を継続できる。これはステートレスが前提だった従来のサーバーレスモデルとは一線を画す設計だ。 3. マイクロVM単位の分離 最も重要な特徴がここだ。各Sandboxはマイクロレベルの仮想マシン境界で分離されている。たとえ悪意あるコード（または単純なバグ）が実行されても、影響はそのマイクロVMの内側に封じ込められる。プロセス分離レベルのコンテナと比べて、格段に強固なセキュリティ境界を提供する。 このアプローチはFirecrackerやgVisorなど、クラウドサンドボックスの先駆的技術から影響を受けており、「高速 + 安全」という相反する要件を両立させる設計パターンとして業界に定着しつつある。 GitHub CopilotとAzure AI Foundryへの統合 Sandboxesが単なる新機能発表にとどまらない理由は、すでに主要製品の基盤インフラとして採用されている点にある。 GitHub Copilot Cloud Sandboxes: CopilotのコーディングエージェントがPR作成やコード修正を行う際、コードの実行・テストはSandboxes上で行われる。開発者のローカル環境や本番環境に一切干渉しない。 Azure AI Foundry Hosted Agents: Foundry上でホストされるAIエージェントが外部ツールやAPIを呼び出す際の実行環境としても活用される。エージェントが自律的に動作する際のセキュリティ基盤を担う。 MicrosoftはSandboxesをAIエージェント時代のインフラ基盤として位置づけており、上位製品がこれを透過的に活用する構造を整えている。 実務への影響——日本のエンジニアへの示唆 自社エージェント開発に活用できる GitHub CopilotやFoundryだけでなく、自社でAIエージェントを開発している組織も、Azure Container Apps Sandboxesを直接利用できる。ユーザーが送信したコードを安全に実行するコードインタープリター機能、動的に生成されたスクリプトのテスト実行、マルチエージェントシステムにおける隔離されたツール実行——これらのユースケースで自前のサンドボックス環境を構築する手間が大幅に削減できる。 セキュリティ設計の発想が変わる 従来、「AIが生成したコードを実行する」という要件には「それは危険なので禁止」という結論が出がちだった。Sandboxesは「禁止ではなく、安全に実行できる仕組みを提供する」という設計思想の転換を技術的に支える。セキュリティを担保しながらAIエージェントの能力を最大限に引き出すアーキテクチャが、Azureのマネージドサービスとして利用可能になった。 Foundryとのセット活用を検討する 現在Azure AI Foundryを評価中・運用中の組織は、エージェントのツール実行部分にSandboxesを組み合わせることで、セキュリティアーキテクチャを強化できる。特に外部APIの呼び出しや動的コード実行を含むワークフローでは、設計の早い段階から組み込むことを推奨する。 筆者の見解 AIエージェントが「コードを読む」から「コードを実行する」フェーズに移行したとき、インフラ側にも相応の進化が必要になる。Sandboxesはその変化に対するMicrosoftの明確な回答だ。 特に評価したいのは、GitHub CopilotとFoundryという自社の主力製品での実績ある採用だ。「発表だけで使われていない」ではなく、自社製品のバックエンドに実際に使っている——これは技術的な成熟度を示す根拠として重要だ。マイクロVM分離という設計の選択も堅実で、「コンテナだから大丈夫」という楽観論より、エンタープライズ採用において信頼を得やすいアプローチだと思う。 一方で、サブ秒起動やスナップショット再開が実際の業務ワークロードでどれだけのスケールに耐えられるか、コストモデルがどうなるかは、現時点ではまだ見極めが必要な部分だ。Microsoftのインフラ基盤の地力は申し分ない。あとは実際に使い込んだときの運用知見をいかに早く積み上げられるかが鍵になる。 Non-Human Identity（NHI）の管理と業務自動化の観点からも、「安全なコード実行環境」の重要性はエージェント普及とともに増す一方だ。Sandboxesはその需要に対して一歩先に手を打った取り組みとして、Azure基盤を採用する組織には注目する価値がある。 出典: この記事は Introducing Azure Container Apps Sandboxes: Secure Infrastructure for Agentic Workloads の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはFabricの2026年6月機能アップデートを公開し、プライベートネットワーク環境でAzure SQL Database・SAP・SQL Server 2016〜2022・SharePointへのミラーリングが利用可能になったと発表した。データエージェントの可観測性強化とOneLakeのストレージライフサイクル管理の簡素化も含まれており、エンタープライズ向けの実用性が一段と高まった内容だ。 プライベートネットワーク対応がゲームチェンジャーになる理由 Fabricのミラーリング機能は、既存のデータソースをリアルタイムに近い形でOneLakeに複製するアーキテクチャだ。これまでパブリックエンドポイント経由のみという制約があったが、今回のアップデートでその壁が取り除かれた。 今月から対応したソースは以下の通りだ： Azure SQL Database（プライベートエンドポイント経由） SAP（オンプレミスデータゲートウェイ経由） SQL Server 2016〜2022（オンプレミスデータゲートウェイ経由） SharePoint（プライベートネットワーク内） 日本の大企業・金融機関・医療機関の多くは「インターネット非経由が原則」という情報セキュリティポリシーを持つ。これまではそのポリシーがFabric活用範囲を事実上狭めていた。今回の対応により、クローズドな企業ネットワーク内でもFabricのデータ統合能力をフルに活かせる環境が整った。 データエージェントの可観測性強化 今月のアップデートには、データエージェント（Data Agent）の可観測性（Observability）と信頼性向上も含まれている。エージェントの実行ログとトレーシング情報の可視化が強化され、エラー発生時の原因追跡が容易になった。 AIエージェントを業務プロセスに組み込もうとしている企業にとって、「動いているはずなのに結果がおかしい」「なぜ失敗したかわからない」という状況はアジャイルな改善を阻害する最大の壁だ。可観測性の強化は地味に見えて、実運用における信頼のクリティカルパスを埋める重要な改善といえる。 OneLakeのストレージライフサイクル管理の簡素化 OneLakeのストレージライフサイクル管理機能が簡素化された。データの「ホット→クール→コールド」層間の移動ルールをシンプルな設定で管理できるようになり、長期保管データのコスト最適化が扱いやすくなった。 大量の分析データを保有する企業では「とりあえず全部ホットストレージ」という選択をしがちだが、アクセス頻度の低いデータをコールド層に自動移動させるだけでストレージコストを大幅に削減できる。今回の簡素化により、アーキテクトだけでなくデータエンジニアレベルでこの設定を扱えるようになる。 実務への影響 閉域網環境でのFabric採用検討を再開すべきタイミング 「ネットワーク要件が合わない」「セキュリティ審査を通過できない」という理由でFabricの導入を諦めた、または保留にしている日本企業は少なくないはずだ。今回のプライベートネットワーク対応を機に、要件整理を再度行う価値がある。 特に以下のシナリオでは検討の優先度を上げるべきだ： オンプレSQL Serverのレガシーデータをリアルタイム分析したい：SQL Server 2016〜2022というバージョン範囲はまさに「現役で動いているオンプレDB」のど真ん中。ゲートウェイ経由でミラーリングできるなら、大規模なデータ移行プロジェクトなしに分析基盤を構築できる。 SAP連携がボトルネックになっている製造業・大手流通：SAP×プライベートネットワーク対応は直撃の改善だ。SAPのデータをFabric/OneLakeに流せるなら、BIレポートの集計ラグを大幅に縮小できる。 SharePointデータを含む社内情報の横断分析：Teams/SharePointのコンテンツをOneLakeに統合してAIで検索・分析するシナリオが、閉域網でも現実的になる。 アーキテクト向けアクションアイテム オンプレミスデータゲートウェイの設計を早めに固める（SQL Server・SAP経由のミラーリングに必須） Azure Private Linkの構成を先にレビューしておく（Azure SQL DB向け） ストレージライフサイクルポリシーの初期設定を設計フェーズで決めておく（後付けより設計段階での決定が効果的） 筆者の見解 Fabricのプライベートネットワーク対応は、日本市場の現実に対するMicrosoftの真摯な応答だと評価したい。 日本の大企業が「閉域網原則」を持つのは、単なる保守性ではなく業法・規制・実際の脅威環境を踏まえた判断だ。その現実に対して「パブリックエンドポイントで繋いでください」という立場を取り続けることは、Fabricの普及を自ら妨げていた側面がある。今回の対応でその壁が一つ取り除かれたことは素直に歓迎したい。 Fabricが目指す「あらゆるデータをOneLakeに集約して、その上でAI・BIを動かす」というビジョンは正しい方向性だ。部分最適を積み重ねて後から高コストに気づくのではなく、統合プラットフォームで全体最適を図るという思想は、今の日本企業に最も必要なアーキテクチャ哲学でもある。 データエージェントの可観測性強化も同様だ。AIエージェントを業務に組み込むなら、ブラックボックスのまま動かすわけにはいかない。ログ・トレーシング・信頼性という基盤を固めてから機能を広げる——これは正攻法だ。 毎月着実にアップデートを重ね、エンタープライズの現実的な要件に応えていく継続的な改善姿勢こそが、Fabricの長期的な競争力になってきている。「今月何が変わったか」を追うことが実務上の意思決定に直結する、数少ないプラットフォームの一つとして、Fabricは着実にその地位を固めつつある。 出典: この記事は Fabric June 2026 Feature Summary の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoft Build 2026でMicrosoftは、Azure API ManagementにOpenAI・Anthropic・Google Vertex AIを単一エンドポイントで束ねる「Unified Model API」を公開プレビューとして発表し、LLMプロバイダーの切り替えをコード変更ゼロで実現できる仕組みを提供した。 Unified Model APIとは何か 複数のAIプロバイダーを並用しようとすると、従来はそれぞれ異なるSDK・認証方式・リクエストスキーマへの対応が必要だった。アプリ層にアダプターコードを書くか、LiteLLM・OpenRouterのような外部ゲートウェイを導入するかのどちらかで、コスト・管理負荷・ガバナンスの逸脱という問題が常につきまとっていた。 Unified Model APIはこの問題を「APIマネジメント層での変換」として解決する。クライアントアプリは既存のOpenAI Chat Completions形式でリクエストを送るだけでよく、裏側でAzure API ManagementがAzure OpenAI・Anthropic・Google Vertex AIのいずれかに振り分ける。クライアントコードは何も変えなくていい。 モデルエイリアスによる抽象化 実務で特に重要なのが「モデルエイリアス」の仕組みだ。アプリ開発者は anthropic.claude-opus-4-8@20260514 のようなプロバイダー固有のモデルIDを直接指定する必要がなく、claude-sonnet や gpt のような簡易名で呼べばよい。エイリアスとバックエンドの紐付けはプラットフォームチームがAPI Management上で管理する。 「今期はAzure OpenAIのGPT-5.5を使い、来期はClaude Sonnetに切り替える」という意思決定が、アプリのコードには一切影響しない。エイリアスの参照先をAPI Management側で変えるだけだ。これはプラットフォームチームとアプリ開発チームの責務分離として非常に明快なモデルだ。 A2A APIとコンテンツ安全ポリシーの拡充 Build 2026では同時に、Agent-to-Agent（A2A）APIガバナンスが一般提供（GA）に達したことも発表された。A2Aは、あるエージェントが別のエージェントのAPIを呼び出してサブタスクを委譲するパターンを定義したプロトコルで、Google主導で策定されAzure・OpenAI・Anthropicが対応する。 さらに、これまでLLM呼び出しにのみ適用されていたコンテンツ安全ポリシーが、MCPツール呼び出しの引数やA2Aペイロードにも拡大された。マルチエージェントシステム全体でガバナンスの穴がなくなりつつある。 現時点のプロバイダー対応状況 プロバイダー Unified Model API 可観測性 コンテンツ安全 Azure OpenAI GA GA GA Anthropic プレビュー プレビュー プレビュー Google Vertex AI プレビュー プレビュー プレビュー 実務への影響 Azureを基盤に使っている日本のエンタープライズにとって、この機能は具体的なメリットをもたらす。 コスト最適化が容易になる: タスクの内容によって安価なモデルと高性能なモデルを使い分けるマルチモデル戦略が、アプリコードを変えずにポリシー設定だけで実現できる。RAGの埋め込み生成には安価なモデル、複雑な推論タスクには上位モデルという使い分けもAPI Management側の設定変更で完結する。 既存の運用・監査フローを崩さない: Azure API Management経由で一元化されているため、既存の可観測性・ログ・コンプライアンスの仕組みをそのまま流用できる。外部ゲートウェイを追加すると生じるセキュリティ審査や内部承認プロセスを回避できる点は、大企業では特に大きな意味を持つ。 ...

Microsoftは、科学・工学分野のR&Dワークフローに自律AIエージェントチームを展開するAzureベースのプラットフォーム「Microsoft Discovery」を正式提供（GA）開始した。同時に発表された次世代トポロジカル量子チップ「Majorana 2」は前世代比で信頼性が1,000倍向上しており、その実現にDiscoveryのエージェント機能が大きく貢献している。 Microsoft Discoveryとは何か Microsoft Discoveryは、組織が専門化されたAIエージェントのチームをデプロイできるプラットフォームだ。各エージェントは大規模な知識ベースを推論し、仮説を生成し、実験を最適化し、結果を検証し、継続的なループで学習する。 アーキテクチャの核心は以下の4要素で構成される： Discovery Engine：マルチエージェントの研究ワークフロー全体を統合管理 Azure HPC連携：計算負荷の高いシミュレーションを処理 信頼スコアリングと引用機能：エージェントの出力を追跡可能・レビュー可能にする エンタープライズセキュリティ・ガバナンス：知的財産の保護と規制準拠を担保 Microsoftが設計上の4要件として掲げているのは、ワークフローの再現性、出力のレビュー可能性、独自知識のガバナンス、既存R&D組織への適合性だ。「ブラックボックスではなく説明可能なエージェント」という姿勢は、企業での実採用に向けた現実的な解答といえる。 Majorana 2——AIエージェントが実現した量子チップの飛躍 今回の最大のハイライトは、Discoveryの実績として同時発表されたMajorana 2だ。量子チームはDiscoveryのエージェントを活用して以下を実現した： 製造ワークフローの管理自動化 測定作業の自動化 材料スタックの最適化 キュービット製造における未発見の欠陥の特定 約20年分の異なるフォーマットの実験データにわたるパターン相関分析 技術面では、アルミニウムから鉛の超伝導体への転換により、宇宙線由来のノイズからキュービットを遮蔽することに成功。平均量子ビット寿命20秒（最長1分）を達成した。他のアプローチで典型的なマイクロ秒単位の寿命と比べると、桁違いの改善だ。演算時間は1マイクロ秒、量子ビットサイズは0.1ミリメートルの100分の1という高集積度を実現している。 Microsoftはこれにより、スケーラブルな量子コンピュータの実現を2029年と見込んでおり、当初計画から半分のタイムラインに前倒しとなる。 個人研究者・小規模チームへの間口も開放 エンタープライズ向けのAzure GAと並行して、無料のデスクトップアプリがEarly Previewで公開された。GitHub Copilotアカウントがあればローカル実行が可能で、大学研究者や小規模チームも敷居低くDiscoveryを試せる。 早期顧客には、エネルギー貯蔵・バイオシステム工学でセルフドライブ型科学ワークフローを構築するPacific Northwest National Laboratory（PNNL）や、半導体向け次世代流体の開発を進めるSyensqoなどが含まれる。 日本のIT現場への影響 日本の製造業・素材産業・医薬品分野の企業にとって、Microsoft Discoveryは今後注目すべきプラットフォームだ。 R&Dチームへの示唆： 既存のAzure環境を持つ企業は、追加インフラなしにアクセスできる 「20年分のデータを横断分析」というユースケースは、製造業の品質管理や失敗事例の学習に直結する GitHub Copilotの法人契約があれば、まずデスクトップアプリで小規模実験が可能 IT管理者・アーキテクトへの示唆： エージェントの出力に信頼スコアと引用が付くことで、コンプライアンス対応がしやすくなる Azure HPC連携は既存のAzureガバナンスポリシーが適用されるため、セキュリティチームの負担が比較的小さい Non-Human Identity（NHI）管理の観点から、エージェントに対してもMicrosoft Entra IDの条件付きアクセスをどう適用するかを早期に設計しておく価値がある 筆者の見解 Microsoft Discoveryの正式提供が持つ意味は、単に「もう一つのAIサービスが増えた」ではない。これはMicrosoftが「最も賢いAIを作る競争」ではなく、「最も多くのエージェントが安全かつ追跡可能に動作するプラットフォームを提供する競争」に軸足を置いていることの表れだ。 Majorana 2の開発でAIエージェントが「20年分の実験データを横断的に相関分析し、未発見の欠陥を特定した」という事実は、単なる業務効率化の話ではない。「AIが研究の主要なプレイヤーになった」という現実を示している。 エージェントの管制塔としてのAzure基盤——Entra IDによる認証・認可、HPC連携、ガバナンスコントロール——という構成は、長期的に見て筋が通っている。信頼スコアリングと引用機能を標準装備にしている点も評価できる。「エージェントが何をしたか説明できない」という問題は企業導入の最大の障壁の一つであり、ここに正面から答えを出していることは意味が大きい。 日本の製造業・研究機関にとって、自社の10年・20年分の実験データや製造ログがAIエージェントによって体系的に活用される日は、想像より近いかもしれない。Azure上でのエージェント基盤構築を今から設計し始めるのが、現実的な次の一手だろう。 出典: この記事は Microsoft Discovery Reaches GA on Azure, Powering the Agentic AI behind Majorana 2 Quantum Chip の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAKS（Azure Kubernetes Service）の2026年5月29日付リリースノートを公開し、AKS AutomaticのマネージドシステムノードプールがGA（一般提供）に昇格した。LocalDNSが新クラスターでデフォルト必須となるなど運用自動化が前進した一方、Flatcar Container Linuxの廃止期限が目前に迫っており、既存利用者には早急な移行対応が求められる。 マネージドシステムノードプール GA化の何が変わるか AKS AutomaticにおけるマネージドシステムノードプールがGAとなり、システムコンポーネント（kube-system 等）が動作するノードプールをAzureが完全管理する形が標準化された。 セキュリティ観点での変更点は大きい。GAとともに以下の制限が自動適用される： 新クラスターでは顧客提供のSSHキーをブロック（既存クラスターは保持するが追加不可） 複数レイヤーのセキュリティ制限が自動的に有効化 ノードへの直接アクセス経路が制限される 重要な注意点：マネージドシステムノードプールを持たない既存のAKS Automaticクラスターは、インプレースアップグレードで対応できない。クラスターを再作成してワークロードを移行する必要があるため、移行計画の立案が必須だ。 LocalDNS が新クラスターで必須化 新規作成するAKS Automaticクラスター、および既存クラスターへ追加する新ノードプールでは、LocalDNSモードが Required にデフォルト設定される。 LocalDNSはノードローカルのDNSキャッシュを利用して名前解決を行う。kube-dnsやCoreDNSのPodへの依存を削減し、クラスター内DNS応答速度と信頼性が向上する。マイクロサービス環境でDNS解決がボトルネックになるケースへの現実的な対処だ。 既存ノードプールへの変更はなく、新クラスター・新ノードプール追加時から有効となる。 Microsoft Defender for Containers にマルウェアスキャンが追加 Microsoft Defender for Containersにマルウェアスキャン機能が追加された。コンテナイメージや実行中ワークロードへの悪意あるコード混入を検知する。 サプライチェーン攻撃がKubernetes環境でも現実的な脅威となっている今、コンテナレイヤーでのスキャンは多層防御の重要な一手だ。Defender for Containersを既に有効化している環境では、ポリシーへの組み込みを検討したい。 廃止タイムライン：今すぐ対応が必要なもの ノードOS / 機能 廃止開始 完全削除 移行先 Flatcar Container Linux 2026年6月8日 2026年9月8日 Azure Container Linux for AKS Windows Server Annual Channel 2026年5月15日 2027年5月15日 LTSC（Long Term Servicing Channel） Windows Server 2019 2026年3月1日 2027年4月1日 Windows Server 2022以降 ...

Microsoftは、AIエージェント向け統合プラットフォーム「Microsoft Foundry」を正式提供（GA）開始し、Build 2026においてFireworks AIとの連携強化を発表した。「最も賢いモデル」を作る競争ではなく、「最も信頼できるプラットフォーム」を構築することで、エンタープライズAI市場の主導権を握ろうという大きな戦略転換だ。 Microsoft Foundryとは何か Microsoft Foundryは、Azure上でAIエージェントを構築・管理・監視するための統合基盤だ。単一のAzureエンドポイントから複数のAIモデル（オープンモデルを含む）にアクセスでき、モデルの選定・切り替え・コスト管理をひとまとめに行える。 今回のGAに合わせて特に注目されるのが、Fireworks AIとの統合だ。Fireworks AIは高性能な推論特化インフラを提供するスタートアップで、Foundryとの連携によりエンタープライズグレードのSLA（サービス品質保証）とSOC 2コンプライアンス対応のオープンモデル推論が、単一のAzureエンドポイントから利用できるようになった。 「能力競争」ではなく「信頼性競争」 Microsoftのこの戦略を端的に示すのが、「AIの能力よりも、AIを安全・確実・低コストで運用できる仕組みこそが企業採用の決め手になる」という読みだ。 現在のAI市場はGPT-4o、Claude、Geminiなど各社が最高性能を競い合う状況にある。しかしMicrosoftは、大企業が実際にAIを本番導入する際の課題は「どのモデルが賢いか」ではなく、次の3点だと見切っている。 コンプライアンスと監査対応 — 金融・医療・官公庁では、SOC 2やISO 27001、GDPRへの対応が必須条件 コスト可視化と管理 — 開発・検証環境のAIコストが予算超過するリスクへの対応 ガバナンスとアクセス制御 — 誰が何のエージェントを何に使ったかを追跡・制御する仕組み Foundryはこの3つを一元的に解決するプラットフォームとして設計されている。 Fireworks AI統合が実務にもたらすもの Fireworks AIの推論インフラは、LlamaやMixtralなどオープンソースLLMを商用グレードで動かすことに特化している。今回のFoundry統合により、以下が実現する。 Azure環境を離れることなく、最新のオープンモデルを本番グレードのSLAで利用できる コスト効率の高いオープンモデルと高性能なクローズドモデルを、同一のAPIで柔軟に切り替えられる セキュリティ監査・ログ記録もAzure標準のツールチェーンで完結する 「AIモデルの選択肢を広げながら、運用基盤はAzureに統一できる」という実践的なメリットは、特にマルチモデル戦略を検討している組織に刺さる提案だ。 日本のIT現場への影響 日本の金融・製造・公共セクターでは、クラウドやAIの採用においてコンプライアンス要件が非常に厳しい。「オープンモデルを使いたいがSOC 2対応ができないためプライベートモデルに限定せざるを得ない」という状況は、IT部門からよく聞く話だ。 Microsoft Foundryの正式提供により、この制約が一部緩和される可能性がある。Fireworks AI経由のオープンモデル推論がAzureのコンプライアンス傘下に入ることで、IT部門が経営層や法務部門へ説明しやすくなる。 また、Azure OpenAI Serviceで管理基盤を標準化している組織にとっては、追加の学習コストなしに利用可能モデルの幅を広げられる点も評価ポイントになるだろう。エージェント管理においてMicrosoft Entra IDを中心に据えている構成とも親和性が高い。 筆者の見解 Microsoftのこの戦略には、一定の説得力がある。「最強のモデルを作る競争」では厳しい場面があっても、「エンタープライズが安心してエージェントを大量に動かせるプラットフォーム」という土俵なら、長年の実績と信頼を武器に戦える。 Foundry経由で他社AIモデルを統一基盤で使えるようにした判断は賢明だと思う。「Azureを使いながら最適なモデルを選べる自由度」を提供することで、プラットフォームの価値を高め、Azure離れを防ぐ有力な手段になりうる。エージェントの管制塔としてMicrosoft Entra IDが機能し、実行モデルは状況に応じて最適なものを選ぶ——この構成は、筆者が実務で推奨しているアーキテクチャと合致している。 一方、「信頼性で勝負」という戦略が「能力競争から降りた」と受け取られるリスクも否定できない。プラットフォームとしての強みは本物であり、Microsoftが勝てる土俵だ。そこに加えて、Copilotをはじめとした自社AIサービスの品質も地道に磨き続けてほしい。強固なプラットフォームと優れた自社モデルが揃ったとき、Microsoftの本当の強みが発揮される。その日が来ることを楽しみにしている。 出典: この記事は With Foundry, Microsoft bets the enterprise AI battle is about reliability, not capability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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