この記事のポイント
- Microsoft Build 2026で発表された技術を基礎から見ているよ
- 仮想化とデータ分析、データベースをテーマに見ているよ
- MXCとHorizonDBについて取り扱っているよ
はじめに
この記事ではMicrosoft Build 2026で登場したサービスまたはツールを元にバックエンド技術に関する知識に触れていきます。今回は主に仮想化とデータ分析、データベースについて触れます。
ちなみにMicrosoft Buildに関しては筆者が企画に携わっている以下のイベントでさまざま情報が共有されています。振り返りにはとてもちょうどいい内容になっていますので読んでいただけますと幸いです。※投稿もお待ちしております。
今回のMicrosoft Buildをひとことで言うと
今回のMicrosoft Build（以下、Build）はAIのための実行基盤と開発ツールを実現するということがテーマになっていたような気がします。私が注目した分野はAIも絡んでくるところで、主に仮想化とデータ分析あるいはデータベースに関するところです。
仮想化であればMXC、データ分析であればFabricやオントロジーの話、データベースであればHorizonDBです。それぞれすごい技術であることは間違いないですが、いかんせんバックエンド技術の背景がわかっていないと凄さがわからないと思いますので基本的なところからおさらいしていきましょう。
- サーバー仮想化（以下、仮想化）
- データ分析
- データベース
順番に見ていきましょう。
仮想化
今回のBuildではMicrosoft Execution Containers(MXC)、いわゆるマイクロVMを起動する仕組みが公開されました。めちゃめちゃ小さい仮想マシンを瞬時に立ち上げて演算処理を行うというものです。
とはいってもなんでマイクロVM？何がすごいの？と思う人がいると思います。ということで仮想化について基礎を見ていきましょう。
仮想化の基礎
そもそも、サーバーにおける仮想化というものは物理的な環境に対して複数あるいは単一の仮想的な環境を構築するというものです。基本としてはホストとなるホストOSがあり、ホストOSのゲストとして起動するゲストOSがあります。これをホストOS型の仮想化といいます。
※Windows上でLinux系のOSをディスクイメージから起動して使うというのもその一種です。(WSLはまた別の技術、話がややこしくなるので割愛）
※ホストOSが不要なハイパーバイザー型の仮想化というものもあります。代表例はHyper-V
ホストOS型仮想化の課題
物理的な領域をソフトウェアで切るというのがつまりは仮想化ということです。考えてみるとわかるとおり、良いことばかりではありません。
クラウド上(IaaS)でVMを起動あるいはPC上で仮想マシンを起動したことがある人であれば、なんとなくわかることでしょう。
すぐに思いつく課題としては以下のとおりです。
- 物理的領域が命、1台壊れるとN台壊れる
- ディスク・メモリ領域を共有している
- I/OやCPUを共有
- 起動までに時間がかかる
- OSに使われているカーネルがホストとゲストでそれぞれ動いていること
- ライセンスや脆弱性の問題
- ライセンスに関しては使い方を間違えると違反につながるケースあり
- 仮想サーバーはたくさん起動できる反面、管理が大変
という形で物理的なサーバーよりポータビリティが高いことは間違いないですが、ソフトウェアの世界では大きすぎるのでポータビリティは比較的に低いです。とくにホストとゲストでカーネルを2重で起動する部分は過剰です。
ということはカーネルを共有してアプリケーションと実行に必要な基盤だけを起動できれば、もっと速く起動できるのでは？ということで次にコンテナ型仮想化について説明します。
コンテナ型仮想化によって実現したことそして歴史
簡単に説明するとルームシェアリングです。同じ家に複数人が同居している状態とも言えるでしょう。
技術的にはホストOS上にコンテナランタイムがあってそのうえでアプリケーションを起動するというものです。最大のメリットとしては起動速度と構成管理があります。壊しやすくて調整しやすくて動かしやすいということです。特徴をまとめると次のとおりです。
- 仮想マシンより起動が速い
- 起動する仮想環境の構成管理が簡単にできる
- スクラップアンドビルドの手軽さ
コンテナで有名なDockerは2013年にこのコンテナ技術を広めることに貢献しましたが、実際のところ元祖コンテナとなった技術は1979年 UNIXのchrootコマンドまで遡ります。
補足：コンテナの歴史をたどる
一番最初と言われているコンテナ型仮想化技術のchrootは「アプリケーションのアクセスを指定のディレクトリに限定する」というものであり、アプリケーションが他のアプリケーションに影響を与えないというものです。
つまりはアプリケーションを隔離する技術ということになります。chrootを使うことにより複数のコンテナを起動できるようになりますが、もちろん多くのアプリケーションを起動すると管理が必要になります。サーバーを大量に管理する場合はもちろんクラスタ構成を検討する必要がありますから、同じ発想で対応するとコンテナもクラスタ構成の管理が必要になります。
ここで出てくるのはコンテナオーケストレーションです。そして、その際に登場したのがクラスタマネージャーのBorg、いわゆるKubernetesの前身と言われているツールです。それからcgroups、LXC(Linuxコンテナ)、Docker、Kubernetesと続きます。
コンテナとFaaS、サーバーレスについて
以上のようにコンテナというものはアプリケーションという単位で可搬性を高めることができます。
VMではマシンの持ち運び、コンテナではアプリケーションの持ち運びということでこれ以上にないくらい開発は楽になりますが、クラウドの台頭でさらに小さな単位として機能を持ち運ぶというものが生まれます。
いわゆる、FaaSというものです。FaaSとはつまり実行するコードだけを持ち運ぶというものです。もちろんランタイムは持ち運びません。ランタイムやサーバーに必要な構成はすべてクラウドが提供します。ここでサーバーを管理しないという概念を代表してサーバーレスというものが誕生します。
サーバーレスと言ってもサーバーないわけではありません。サーバーの管理が必要ないという意味でサーバーレスです。大きな特徴としてはScale to Zero、使わないときは稼働していないという特徴があります。
コンテナによる「アプリケーションの仮想化」、そしてFaaSによる「機能（コード）単位でのサーバーレス化」は開発と運用の効率を極限まで高めました。しかし、FaaSが提供する「Scale to Zero（不稼働時はリソース消費ゼロ）」と「リクエストに応じた超高速起動」を支える裏側では、従来の仮想化技術の限界という新たな壁に直面します。
この課題を解決するために登場したのが、マイクロVM（MicroVM）という技術です。
マイクロVMにしかない特徴（分離レベルと起動速度のトレードオフ）
FaaSのようなマルチテナント（複数のユーザーのコードが同じ物理サーバー上で動く）環境において、インフラ側には2つの絶対的な要求があります。
- 他人のコードが悪意ある挙動をしても、自社の環境やホストOSに影響を与えないこと（隔離性）
- リクエストが来てからミリ秒単位で環境を立ち上げ、Scale to Zeroを実現すること(俊敏性)
しかし、従来のVMではオーバヘッドが大きすぎること、コンテナにおいてはホストOSのカーネルを共有してしまうため隔離性が実現できていません。
つまり、カーネルが独立していてコンテナよりも高速に起動する仮想環境が重要になります。
マイクロVMは「仮想環境のいいとこ取り」
「VM並みの強固なセキュリティを持ちながら、コンテナ並みに爆速で動く極小の仮想マシン」、それがマイクロVMです。
代表的な実装としては、AWSのFirecrackerが挙げられます。AWS Lambdaの裏側では、このFirecrackerが数ミリ秒でマイクロVMを起動・破棄することで、セキュアかつ高速なScale to Zeroを実現しています。
参考:【AWS】Modern Serverless Architectures with Lambda Managed Instances
マイクロVMを用いることでアプリケーションをよりポータブルに持ち運ぶことができるようになります。
つまりMXCは何がすごいか
今回のBuildで登場したMXC(Microsoft Execution Containers)のすごいところはマイクロVMを呼び出す環境をOSSで提供したことでもありますが、根本的なところでいえば、マイクロVMをすぐに立ち上げる方法をSDKでかつマルチプラットフォームで利用できる形にしたことだと思います。
また、MXCを実際に触ってみるとわかりますが、マイクロVMの構成管理もjsonやTypeScriptで可能になっています。これはつまり、AIエージェントを作成するのに使ったプログラミング言語を使って一気通貫で構築できることを意味します。
さらにアクセス権限レベルやネットワークの分離レベルなどをコードで定義できるよう提供している点も大きなところです。
- 参考：Microsoft eXecution Container (MXC) - GitHub
- 参考：ハンズオン！夢が詰まったサンドボックスシステム、Microsoft Execution Containers（MXC）とは
ということで仮想化の話としてMXCの話は以上です。次はデータ分析について書きます。
オントロジーとセマンティック、そしてHTAP
ただのデータから価値のあるものへと進化させるために、近年のデータプラットフォームではセマンティック、オントロジー、そしてそれらを支えるHTAPという要素が急速に統合されつつあります。
セマンティックレイヤーとオントロジー
データレイクやデータウェアハウス（DWH）に格納された生データ（物理テーブル）は、そのままではビジネスユーザーやAIにとって理解が難しいものです。これを解決するのが以下の2つの概念です。
- セマンティックレイヤー
- オントロジー
セマンティックレイヤー（Semantic Layer）
セマンティックレイヤーはデータをビジネス上の言葉に翻訳する共通の抽象化レイヤーです。実体となるフィジカルなデータ層とフィジカルなデータ層に名前をつけたロジカルなデータ層の上に構築されます。
例えば、データベース上のfact_sales.amt_usdというカラムを、ビジネス側で「売上高」として統一定義します。これにより、どのBIツールやAIからアクセスしても、同じ「売上高」の定義で集計されることが保証されます。
補足：実体となるフィジカルなデータ層とフィジカルなデータ層について
Semantic Layerの下層に位置する2つのLayerに関して説明します。
- Physical Layer
- ストレージ等にデータが保存されている実体
- Logical Layer
- 物理データに名前を付け、テーブルと実体間の関係
オントロジー（Ontology）
オントロジーは「データエンティティ間の関係性やルール」を体系化したものです。Microsoft Buildでも、AIが文脈を正確に理解するためのコンテキスト基盤として強調されました。
「顧客」「製品」「契約」といった概念が、単に存在するだけにとどまりません。
「顧客は契約を所有する」「製品は特定の法規制に準拠する」といった意味的なつながり（グラフ構造）を定義します。
オントロジーによりAIは、単なるキーワードマッチングを超えて、ビジネスの文脈を理解した高度な推論やデータ分析が可能になります。
他のLayerと併せて表現すると以下のとおりです。
データ基盤を支える技術
セマンティックレイヤーやオントロジーといったものがAIに採用されるとAIの推論力はさらに向上します。しかし、セマンティックレイヤーやオントロジーを導入するデータがしっかりとデータストアに格納され、分析できる状態でなければなりません。
データを支える技術はさまざまありますが、多くはトランザクションと分析の２つに分かれます。
- OLTP（トランザクション処理）
- OLAP（分析処理）
ここでHTAP（Hybrid Transactional/Analytical Processing）鍵となります。
データを支える技術
どれだけ意味づけしても高度なオントロジー（関係性）を定義してもその基盤となるデータが「昨日の夜にバッチ処理されたもの」では、現代のリアルタイムなビジネス判断やAIエージェントの駆動には間に合いません。
HTAPは従来完全に分離されていた2つの処理(OLTP/OLAP)を同一のデータ基盤または同期された1つのシステムで同時に処理するアーキテクチャです。
なぜHTAPが重要なのか
結論から先に言うとトランザクション処理と分析を同時にこなせるからです。
従来のデータベースではOLTPとOLAPの処理それぞれに対してデータを用意するというアプローチが主要です。それはなぜか、書き込み処理と読み込み処理を単一のデータベースで実行に移すのが難しいからです。
多くのアプローチとしてはトランザクションが担保されているデータベースでレプリカを作成して分析用のリーダーエンドポイントを作成する必要があります。ただし、この場合だとデータが頻繁に挿入されるようなDBではレプリカとオリジナルで大きな差が出てしまいます。
他のアプローチではCDC、チャンジデータキャプチャで変更点を他のデータベースに伝えるというものがありますが、これでも差が出てしまうことがあります。（ものによります）
HTAPはこのトランザクション処理と分析処理の両方によってリアルタイムに分析が可能です。つまりは「今、発生した取引データ」が即座に分析可能です。
Microsoft BuildとHTAPの関係
筆者がこのHTAPをMicrosoft Buildで感じ取った瞬間はAzure HorizonDBについて説明している場面でした。Azure HorizonDBはミッションクリティカルに動くデータベースとして紹介されており、厳しいトランザクションが要求されるようなユースケースに耐えられるように設計されているようです。
ただ、公式サイト：Azure HorizonDB | Microsoft Azureを見ると次のような記述があります。
Microsoft Fabric でのミラーリング
複雑な抽出、変換、読み込み (ETL) を回避し、Microsoft Fabric にデータをほぼリアルタイムでレプリケートして、新しいビジネス インテリジェンスなどを解き放ちます。
ゼロETLミラーリングによる、ストレージ層でのレプリケーション（Near Real-time Sync）が実現できるということでつまり、HorizonDBでトランザクション(OLTP)を処理してFabricで分析(OLAP)を実行という全体で見るとHTAPのアーキテクチャになっているということです。
HorizonDBを使うことによってミッションクリティカルであってもFabricのエコシステムを接続できるということです。さらに次に説明するDiskANNによって、AI Readyな物になりHTAPにより近づきます。
データベースをさらに押し上げる技術、DiskANN
今回のBuildではAIに関することがメインに取り上げられたような印象があります。データ分析もAI ReadyでしたのでもちろんデータベースのHorizonDBにおいてもAI Readyの文脈が隠れています。
DiskANNがその代表例です。DiskANNは、Microsoft Researchが開発した最先端の近似最近傍探索（ANNS）アルゴリズムです。
HorizonDBは高性能な新しい PostgreSQL クラウド データベース サービスという説明がされています。つまりは直感的に考えるとpgvectorのHNSWインデックスでベクトル検索をしなければいけないのかなと思う人もいると思います。
HNSWではインデックスのすべてを高価なメモリ（RAM）上に展開する必要がありました。データ量が数千万、数億件とスケールするとメモリ費用が莫大になるかあるいは物理的なメモリ上限に達して破綻します。
HorizonDBがPostgreSQLの3倍のパフォーマンス、3,072 仮想コアと 128 TBまでスケーリングすることを考えるとベクトル検索する際に破綻する可能性があるということです。
そこでDiskANNをインフラ層（ストレージエンジン側）に組み込むことでインデックスの大部分を比較的安価なNVMe SSD（ディスク）に逃がしつつ、インメモリ駆動のHNSWに匹敵するミリ秒単位の超高速検索を可能にしています。
実務におけるベクトル検索（RAGなど）では単に「似ているベクトルを探す」以外にも次のようなケースがあります。
- 「ユーザーIDが一致するもの」
- 「過去3ヶ月以内のデータ」
つまりはメタデータでのフィルタリング（条件絞り込み）が同時に求められます。
DiskANNはグラフ構造を維持したまま効率的にフィルタリングを行うアルゴリズム（Filtered Search）に強みを持っています。
これをPostgreSQLにネイティブ統合することでSQLの WHERE 句によるフィルタと高次元ベクトルの近似最近傍探索（ANNS）を単一のクエリで高効率に同時実行できます。
さらに、従来のベクトル検索アーキテクチャにおいては大規模なベクトルデータを捌くために、PostgreSQLとは別に専用のベクトルデータベース（MilvusやQdrantなど）を別途立ち上げてデータを同期させるアーキテクチャが一般的でした。しかし、これにはデータの二重管理やHTAPが導入されていないDBと同様に同期遅延のリスクが伴います。
HorizonDBは従来のアーキテクチャを覆す可能性を持っています。
Azure HorizonDBのすごいところ
あれやこれや難しい話を書いてきましたが総括すると以下のとおりです。
- Fabricとの連携によってHTAPを実現
- メモリではなくディスクを検索に使うことで圧倒的高効率によるデータ処理
- ベクトル検索アーキテクチャのブレイクスルー
おおむねここまでわかるとおり、つまりはAIのためのミッションクリティカルデータベースということです。
まとめ
ということでまとめです。今回はMicrosoft Build 2026を通して仮想化とデータ分析あるいはデータベースに関することを復習しつつ、新しいSDKとサービスをチェックしました。
AIという文脈を通してこれまでの技術が再評価され、さらに進化したという印象を受けたというのが率直な感想になりそうです。ほかにもWSL ContainersやIQに関することを見ていくと面白いことが見えてきますが、思いついたらまた書こうと思います。今回は以上です。