Azure Arc と Azure Local の違い: Microsoft のハイブリッド インフラストラクチャ用語を整理する

By Mirko Peters · 2026-08-22

ポッドキャストへようこそ。最近のエピソードで現代のエンタープライズ IT アーキテクチャを取り上げていたので、ハイブリッド クラウド戦略について多くの時間を割いてきたことをご存じの方も多いでしょう。

Automatically translated with AI from the original post. Read the English original

ポッドキャストへようこそ。最近のエピソードで現代のエンタープライズ IT アーキテクチャを取り上げていたので、ハイブリッド クラウド戦略について多くの時間を割いてきたことをご存じの方も多いでしょう。先日、シカゴのリスナーであるマーカスさんから素晴らしいメールをいただきました。マーカスさんはこう書いていました。「当社の次世代インフラストラクチャを設計しようとしていますが、Microsoft のホワイト ペーパーを読むたびに、専門用語の多さに迷子になってしまいます。Azure Arc と Azure Local の実際の違いは何でしょうか。競合する製品なのですか。両方とも必要なのでしょうか。」

マーカスさん、あなただけではありません。Microsoft は現在、市場で最も包括的なハイブリッド エコシステムの一つを提供していますが、その広がりに比例して用語も膨大になっています。用語は改名され、略語も入れ替わるため、IT 管理者やクラウド アーキテクトは、どのツールが何をするのかを理解するのに頭を悩ませることになります。だからこそ、今回のブログ記事では、Microsoft のハイブリッド戦略を支える二つの重要な柱を分かりやすく解説したいと考えました。この記事を読み終えるころには、Azure Arc とは何か、Azure Local とは何か、両者はどこが違うのか、そして最も重要な点として、両者を組み合わせてどのようにインフラストラクチャを強化できるのかを、明確に理解していただけるはずです。

Microsoft のハイブリッド進化の概要

Azure Arc と Azure Local が今日どこに位置づけられるのかを理解するには、少しだけ時間をさかのぼる必要があります。数十年にわたり、エンタープライズ IT は二択でした。ワークロードは自社の物理サーバー上でオンプレミスのデータセンターに置くか、他社のデータセンターに置くかのどちらかでした。その後、Microsoft Azure、Amazon Web Services、Google Cloud Platform によるパブリック クラウドの革命が起こります。組織は一斉にあらゆるものをクラウドへ移行し、無限のスケーラビリティと設備投資の削減を約束されました。

しかし、現実はすぐに明らかになりました。企業は、すべてがパブリック クラウドに適しているわけではないと気づいたのです。規制要件、データ主権に関する法律、ネットワークのエッジにおける超低遅延の要求、そして容易にリファクタリングできないレガシー アプリケーションがあるため、オンプレミスのインフラストラクチャがなくなることはありませんでした。同時に、組織は Azure で慣れ親しんだ優れた管理機能、セキュリティ ツール、開発者の生産性を手放したくもありませんでした。

この認識がハイブリッド クラウドの時代を生み出しました。Microsoft は早い段階から、未来は純粋なパブリック クラウドだけではなく、エッジからデータセンター、クラウドに至るまで途切れのない連続体になると見抜いていました。長年にわたり、Microsoft はこのギャップを埋めるさまざまなツールを構築してきました。既存のハードウェアを管理することを目的としたツールもあれば、そのハードウェアを丸ごと刷新することを目的としたツールもあります。ここで、今日取り上げる二つの主題にたどり着きます。管理と制御を担う Azure Arc と、実際のハイパーコンバージド インフラストラクチャの基盤を提供する Azure Local です。

用語の整理: Azure Arc とは何か

まず Azure Arc から見ていきましょう。このセクションから一文だけ持ち帰っていただくなら、次の文にしてください。Azure Arc はインフラストラクチャ製品ではなく、コントロール プレーンです。

Azure Arc は、Azure のコントロール プレーンを外部に拡張する魔法の杖のようなものだと考えてください。パブリック クラウドの Azure で仮想マシン、データベース、Kubernetes クラスターを管理するときに使う、まさにその管理基盤を、自社のデータセンターやエッジの拠点、さらには AWS や Google Cloud Platform といった競合クラウドにまで広げるものです。

Azure Arc の内部の仕組み

Azure Arc の中核となる仕組みは、軽量なエージェントを、リソースがどこにあっても既存のリソースにインストールすることです。フランクフルトのラックで稼働する物理 Linux サーバーでも、シカゴの社内オフィスにある VMware 仮想マシンでも、Amazon EC2 インスタンスでも、Azure Arc はそのリソースを Azure に接続します。接続されると、その外部リソースは Azure Resource Manager (ARM) に投影されます。その結果、Azure ポータルでは、非 Azure のサーバーがネイティブな Azure VM と並んで表示されるようになります。

この投影により、Azure のクラウドに実際には接続されないインフラストラクチャに対しても、クラウドネイティブな機能の大規模なスイートが利用できるようになります。

• 統合されたガバナンスとコンプライアンス: Azure Policy をオンプレミスのサーバーに適用することで、環境全体で構成が準拠した状態を維持できます。
• 高度なセキュリティ: Microsoft Defender for Cloud を拡張して、Azure 以外のサーバーや Kubernetes クラスターの脅威と脆弱性を監視できます。
• クラウドネイティブな監視: Azure Monitor は、ローカルのインフラストラクチャからログとメトリックを収集できるため、オブザーバビリティを一元的に把握できます。
• Arc 対応サービス: Azure SQL Managed Instance や Azure PostgreSQL を自社のローカルインフラストラクチャ上で実行することもできます。その管理はすべて Azure コントロール プレーンから行えます。

重要な点として、Azure Arc は基盤となるハイパーバイザーの種類を問いません。VMware、Hyper-V、物理ベアメタル環境を置き換えるものではありません。既存の環境の上に、インテリジェントな管理レイヤーをかぶせるものです。

用語の整理: Azure Local とは何か

Azure Arc を管理レイヤーとして理解したところで、インフラストラクチャ側の Azure Local に目を向けましょう。Azure Arc があらゆる場所に届くソフトウェア定義のコントロール プレーンだとすれば、Azure Local は、データセンターやエッジでワークロードをローカルに実行するためのハイパーコンバージド インフラストラクチャ (HCI) ソリューションです。

以前の名称である Azure Stack HCI でご存じの方もいるかもしれません。Microsoft は最近、この製品を Azure Local というブランドに統合・整理し、その中核的な役割とより整合するようにしました。Azure Local は、現場の自社施設にある検証済みのハードウェア アプライアンス上で動作する、最新のソフトウェア定義のコンピューティング、ストレージ、ネットワーク基盤を提供します。

Azure Local のアーキテクチャ

Azure Local は、Windows Server のテクノロジーと高度なハイパーコンバージド ソフトウェアを組み合わせ、エンタープライズグレードの仮想化とストレージ機能を提供します。仮想化には Hyper-V を、高性能なソフトウェア定義ストレージには Storage Spaces Direct を利用します。

Azure Local が本当に特徴的なのは、設計段階からAzure パブリッククラウドとの深く統合された連携機能を備えている点です。従来の仮想化基盤では、クラウドへの接続にサードパーティ製ツールが必要でしたが、Azure Local はデフォルトでクラウドに接続された状態で設計されています。自社で物理的に所有・運用するハードウェア上で、使い慣れた Windows および Linux の仮想マシンや、Azure Kubernetes Service (AKS) クラスターをローカルで実行できます。

Azure Local の主な機能は次のとおりです。

• 高可用性と復元力: 組み込みのクラスタリングとストレージ レプリケーションにより、ハードウェア障害が発生した場合でも、ローカルのワークロードを稼働し続けられます。
• 柔軟なフォーム ファクター: 小売店や工場に展開する堅牢なエッジ ノードから、企業のデータセンターにある大規模なマルチノード クラスターまで、Azure Local は手持ちの物理スペースに合わせて拡張できます。
• 使い慣れた仮想化: チームがすでに Hyper-V や一般的な仮想化の概念を理解していれば、Azure Local の導入における学習コストは非常に低くなります。

管理とインフラストラクチャの違い

リスナーの方から Azure Arc と Azure Local の比較を尋ねられたとき、私はまず質問の前提を正すようにしています。Azure Arc と Azure Local を比べるのは、リモコンとテレビを比べるようなものです。両者は競合する技術ではなく、IT スタックの異なるレイヤーで動作しています。

いくつかの主要な観点から、基本的な違いを見ていきましょう。

1. スタックにおけるレイヤー

Azure Arc は、完全に管理およびコントロール プレーンのレイヤーで動作します。リソースを整理、ガバナンス、保護できるクラウド サービスです。一方、Azure Local はインフラストラクチャおよびコンピューティングのレイヤーで動作します。アプリケーションが実際に実行される物理および仮想のコンピューティング リソースとストレージ リソースを提供する、オペレーティング システムおよびハイパーコンバージド基盤です。

2. ハードウェア依存性

Azure Arc は エージェント ベースの管理ツールにすぎないため、ハードウェアへの依存はほぼありません。5年前の Dell サーバーで古いバージョンの Linux を動かしていても、新しい HPE サーバーで Windows を動かしていても、さらには AWS 上でホストされている仮想マシンにも、Arc エージェントをインストールできます。一方、Azure Local では、Microsoft のハードウェア パートナーが提供する、検証済みの特定のハードウェアが必要です。サーバー ルームに余っている適当なハードウェアに単純にインストールすることはできません。パフォーマンス、信頼性、サポート性を確保するため、認定済みのクラスター ノードが必要です。

3. 主な目的

Azure Arc の目的は、統合管理です。つまり、断片化したマルチクラウドとオンプレミスの IT 資産に一貫性をもたらします。一方、Azure Local の目的は、モダナイズされたローカル インフラストラクチャです。データが生成される場所のすぐそばで、仮想化ワークロードとコンテナー ワークロードを実行できるクラウド ネイティブな HCI プラットフォームを提供します。

Azure Arc と Azure Local の使い分け

それぞれのツールの役割を整理したところで、どちらを選ぶべきかを考えてみましょう。アーキテクチャ設計のセッションでは、いつ Azure Arc を使い、いつ Azure Local をデプロイすべきでしょうか。

Azure Arc を使うケース

既に所有しているインフラストラクチャを置き換える予定がなく、そこに Azure の管理機能を取り入れたい場合は、Azure Arc をデプロイすべきです。例えば、次のようなケースです。

• 世界各地のデータセンターに、VMware やベア メタルの Linux サーバーへの大規模な投資が既に存在しており、Azure ポータルの一画面で、コンプライアンスの管理、ログの監視、ポリシーの適用を行いたい場合。
• AWS や Google Cloud 上で Kubernetes クラスターを運用しており、Azure GitOps と Azure Policy を使って、これらすべてのクラウドにまたがるデプロイを同時に管理したい場合。
• 基盤となる仮想化スタック全体を移行せずに、Azure SQL Managed Instance などの Azure データ サービスをオンプレミスで実行したい場合。

Azure Local を使うケース

老朽化したオンプレミス インフラストラクチャを刷新したい場合、または新たなエッジ コンピューティング環境を構築したい場合で、そのローカル インフラストラクチャを Azure クラウドの延長のように感じられ、動作させたい場合は、Azure Local をデプロイすべきです。

• 従来の SAN と仮想化スタックの サポート期限 が迫っており、Azure のバックアップ、災害復旧、監視とネイティブに統合される、最新のソフトウェア定義ハイパーコンバージド インフラストラクチャに置き換えたい場合。
• 病院、小売店舗、製造工場などのエッジ拠点で、低遅延のコンピューティングとストレージが必要であり、データをローカルで処理しなければならないものの、それらのワークロードは Azure クラウドから一元管理したい場合。
• オンプレミスで Azure Kubernetes Service (AKS) を、完全なサポートと既存のクラウド デプロイ パイプラインへのシームレスな統合を伴って実行したい場合。

ハイブリッド戦略における両者の連携

ここからが本当に面白いところです。Azure Arc と Azure Local は別個の製品ですが、Microsoft は両者が連携することで、より優れた価値を発揮するように設計しています。実は、Azure Local クラスターは、既定で自動的に Azure Arc が有効化されます!

データセンターに Azure Local クラスターをデプロイすると、基盤となるインフラストラクチャはローカルで管理されますが、そのコントロール プレーンは Azure Arc と完全に統合されます。つまり、Azure Local インフラストラクチャを管理するために、個別のエージェントをインストールしたり、複雑なトンネルを構成したりする必要はありません。初期化された時点から、Azure サブスクリプションにネイティブに表示されます。

この相乗効果が実際にどのように機能するのか、現実のハイブリッド シナリオで見てみましょう。大規模なグローバル物流企業を想像してください。

1. エッジ: 同社は世界中に数百の物流センターを運営しています。各センターには、小規模な 2 ノードの Azure Local アプライアンスをデプロイし、配送ラベルの処理、ローカル データベース インスタンスの実行、倉庫自動化システムの管理を、超低遅延で行っています。
2. エンタープライズ全体: 同社には、VMware と物理サーバーが混在するレガシー データセンターや、AWS でホストされているワークロードもあります。これらすべての環境に Azure Arc エージェントをインストールし、セキュリティ ベースラインの適用とコンプライアンスの追跡を行っています。
3. 統合管理: Azure ポータルを使うと、中央の IT チームは、Azure Local 上で動作するエッジの fulfillment センターの状態を、AWS 上のインスタンスやレガシー サーバー (Azure Arc で管理) と並べて確認できます。Azure Policy を使えば、暗号化の標準がどこでも満たされていることを確認でき、Azure Monitor を使えば、パフォーマンス メトリックをグローバルに追跡できます。

このアーキテクチャでは、Azure Local がエッジで回復性と高性能を備えた基盤を提供し、Azure Arc が、ハイブリッド環境全体を一つにまとめる包括的なガバナンスと制御プレーンを提供します。

まとめ: ハイブリッド クラウドへの取り組みをシンプルにする

Microsoft のハイブリッド クラウド エコシステムは、一見すると複雑に感じられるかもしれません。しかし、用語を具体的なアーキテクチャ レイヤーに対応づけると、全体がすっきり見えてきます。覚えておくべき黄金律は次のとおりです。Azure Arc はすべての場所にあるすべてのものを管理する制御プレーンであり、Azure Local はローカルおよびエッジのワークロード向けの最新のハイパーコンバージド インフラストラクチャです。

来年に向けてエンタープライズ アーキテクチャを計画する際は、これらのテクノロジーを二者択一として捉えないでください。むしろ、それらがどのように補完し合うかに目を向けてください。既存の多様な IT 資産を統合して管理するには Azure Arc を使い、クラウド ネイティブの俊敏性を取り入れてオンプレミスやエッジのインフラストラクチャを近代化する必要がある場合は Azure Local を活用してください。

この詳細解説が、Microsoft のハイブリッド用語に関する混乱の解消に役立てば幸いです。いつものように、皆さんのご意見をぜひお聞かせください。マルチクラウド環境で Azure Arc を現在お使いですか。エッジの拠点に Azure Local を導入済みですか。ご意見はコメント欄にお寄せいただくか、次回のリスナー メールバッグ エピソードのためにメールでお送りください。それでは次回まで、未来に向けたアーキテクチャの設計を続けていきましょう。