**Azureの信頼を蝕んだ決定 – 元Azureコアエンジニアによる考察** - **機能過剰な約束** *約束された機能が遅れて提供されるか、まったく実装されないことで、ユーザーは誤解を受けたと感じました。* - **APIの安定性が一貫していない** *頻繁に破壊的変更が行われ、十分な非推奨期間が設けられないため、開発者の信頼感が揺らぎました。* - **価格設定の不透明さ** *事前告知のない調整や混乱を招く請求モデルにより、顧客は財務予測性を失いました。* - **セキュリティパッチの遅延** *重大な脆弱性が修正されるまで時間がかかり、クライアントは不必要なリスクにさらされました。* - **ドキュメント更新の遅れ** *プラットフォームのリリースに追いつかない文書は、ユーザーを信頼性の低いコミュニティ資料へと強制しました。* これら一連の決定が、Azureがかつて利用者から享受していた信頼を徐々に蝕んでしまいました。

これは、21 世紀に起こり得る最も滑稽で、最も予防可能かつ費用が高い失敗の一例を学ぶシリーズ記事の第 1 作目です。Microsoft が OpenAI（最大顧客）と米国政府からの信頼をほぼ失ってしまった出来事です。

私は 2023 年 5 月 1 日（月曜の午前中）の退屈な朝に、Azure Core に参加し、Overlake R&D チームのシニアメンバーとして入社しました。こちらは Azure Boost オフロードカードとネットワークアクセラレータを開発したチームです。私は Azure には新参者ではなく、2010 年 2 月に Windows Azure として開始されたこのクラウドサービスの最長期間稼働するプロダクションサブスクリプションを運用してきました。また Microsoft にも入社は久しぶりではありません。2013 年 1 月から Windows チームに所属し、SharePoint Online を Azure に移行した後、Core OS チームのカーネルエンジニアとして参加しました。その際にはカーネルを改善し、Docker、Azure Kubernetes、Azure Container Instances、Azure App Services、および Windows Sandbox をサポートするコンテナプラットフォームを発明・提供し、多数の特許取得に寄与しました。

さらに 2020 年〜2021 年に Overlake カードの初期設計議論にも参加し、デバッガーのシリアル接続しかない環境で Host OS ↔ アクセラレータカード通信プロトコルとネットワークスタックの提案書を作成しました。Core OS のスペシャリストとして Azure Core エンジニアが深い OS 問題を診断できるよう支援し、2023 年に再度 Azure 専門家として入社した際には、Azure が依存する技術の開発に貢献し、10 年以上にわたりプラットフォームを利用してきました。

従業員復帰者としては新入社員オリエンテーションをスキップし、12 時正午にグローバルセキュリティからバッジを受け取る予定でしたが、将来のマネージャーから「チームの月次計画会議がその朝にあるため、早めに来てほしい」と頼まれました。私は同意し、10 時前後に Studio X ビルの入口（レドモンド西キャンパスの The Commons に近い）へ到着しました。男性がドアを開け、廊下の迷路を抜けて会議室へ案内されました。

部屋はすっかり混み合っており、ライブカンファレンス通話中の人々も多かったです。開発マネージャー、リーダー、アーキテクト、プリンシパルとシニアエンジニアが、新入社員やジュニア職員と共に空間を共有していました。スクリーンには COM、WMI、パフォーマンスカウンタ、VHDX、NTFS、ETW などの馴染みのある略語と Azure 関連の新しい用語が混在した多数のボックスが矢印で結ばれたスライドが映し出されていました。

私は静かに後ろ席に座り、男性が現在のスタックを Overlake アクセラレータへ移植する大規模計画を説明しているのを見守っていました。その一連のボックス（Windows ユーザーモードとカーネルコンポーネント）がその計画にどう関係するかはすぐには分かりませんでした。数分後、私は質問しました。「これらの Windows 機能を Overlake に移植する予定ですか？」答えは「はい」または少なくとも検討中だというものでした。開発マネージャーは疑念を示し、男性は「少数のジュニア開発者に調査してもらえる」と返しました。部屋は一瞬静まり返りました。

以前勤務していた時期に Overlake カードの SoC のハードウェア仕様を見たことがあり、RAM 容量と電力予算は通常のサーバー CPU から期待できる TDP のほんの一部であることを知っていました。FPGA 上のダブルポートメモリに 4 KB しか確保できないという制約もあったため、全てが軽量かつ効率的で省電力設計でした。10 分前に参加したチームは、半分程度の Windows をファンレスで Linux 実行の小型チップ（爪先サイズ）へ移植することを真剣に検討していました。

それはまるで Elon が火星植民地化について語っているかのようでした。「極地方を核破壊し、雰囲気を育てればいい」と言うよりも、実際にはもっと難しい作業です。122 名規模の組織全体が Windows を Linux に移植して既存の VM 管理エージェントをサポートするという不可能な思考に没頭していました。その男性は Azure ノード上で動くソフトウェアの一部を監督するプリンシパルグループエンジニアリングマネージャーで、彼の上司であるパートナーエンジニアリングマネージャーも会議室にいました。二人は本当に Windows を Linux に移植して現在のソフトウェアをサポートすることを検討していたのです。

最初は自分の理解が正しいか疑問でした。実際、残りの話では計画が明確に示され、開発リーダーたちには人員投入が求められていました。この計画が成功しないことを私は即座に悟り、組織は多大な支援を必要としていると判断しました。

新しい役割での最初の一時間は、愕然と驚嘆という奇妙な感情を混ぜて残しました。スタックは 400 W の Xeon で数十個の VM しか処理できず、ハイパーバイザーが実現可能だと思っていた 1,024 個の VM 制限には到底達していませんでした。また、ノイズが大きく、顧客 VM に jitter をもたらすほどリソースを消費していました。

このスタックが小型 ARM SoC 上で収まり、多数にスケールアップするという想定は現実的ではありません。私は業界（および Microsoft）で長年経験を積んできましたが、こうした組織の非現実性を見たことは初めてでした。最初の日の課題は、新技術に追いつくことではなく、上位層まで「死走り」にあると説得することでした。

どこかで私は激しい逆境が待ち受けていると知っていました。想像できる通り、うまくいきませんでした。数日間にわたり計画を調べ、現在のシステムを学び、Core OS の旧友たちを訪ねました。この奇妙な領域で迷子になった感覚は、酔っ払いの LLM が自信満々に語るような不条理さでした。

特筆すべきは、Linux System Group のリーダー（INRIA から博士号取得した実力派）が 90 分以上も私と対面で話し、彼の組織が Mariner Linux（現在の Azure Linux）および Overlake / Azure Boost カード上で動作するトリムダウンディストリビューションを提供していることでした。彼は親切に質問に答えてくれ、173 のエージェントが Overlake へ移植候補として特定されたと教えてくれました。

さらに調査した結果、Microsoft 内で誰もが Azure ノードを管理するために最大 173 個のエージェントが必要だという理由や、それぞれが何を行い、互いにどのように相互作用し、機能セットは何か、あるいはなぜ存在するのかを説明できる者はいませんでした。Azure は VMs、ネットワーキング、ストレージを核として販売します。観測性とサービス管理を加えれば十分です。SQL、K8s、AI ワークロードなどその他すべては xPU、ネットワーク、およびストレージに基づく VM を利用し、その魔法を実現するのは Core OS とハイパーバイザーが担っています。

173 エージェントという数値がどうやって生まれたかは謎のままでしょう。しかし、そこには大きな誤解が存在しており、災害の構築方法でもあります。想像してください。この管理されていない「もの」の山が Anthropic の Claude、OpenAI API（残存部分）、SharePoint Online、政府クラウド、その他ミッション・クリティカルインフラを動かす VMs を調整しているとしたら、砂粒一つで全世界的な崩壊を招き、国家安全保障に深刻な影響を与えるだけでなく Microsoft にとってビジネス終了の危機にもなり得ることがわかります。

まだトリプル桁兆円規模の市場価値喪失、CEO への手紙、Microsoft の取締役会、Cloud + AI EVP への手紙と彼らの全く沈黙、OpenAI の quasi‑loss、米国政府との信頼破綻（防衛長官が公表したように）、無駄なエンジニアリング労力、Rust 命令、Azure Core の OpenAI ベアメタルチームでの勤務、中国や他地域からの護送セッション、2023 年に公開されたはずだった機能の遅延など、まだ多くの課題があります。

もし Azure 上で本番ワークロードを実行している、またはミッション・クリティカルシステムに依存しているなら、この物語は想像以上に重要です。Part 2 をクリックしてください。