Azure Local × IOWN APN で実現する拠点間HA構成 ソブリンAI時代に求められるState管理・運用継続性・データ主権 / Cross-site HA Architecture Powered by Azure Local × IOWN APN ~ State Management, Operational Continuity, and Data Sovereignty for the Sovereign AI Era ~

2026年6月23日のAzure Local サミット Vol.2で発表した「Azure Local × IOWN APNで実現する拠点間HA構成ソブリンAI時代に求められるState管理・運用継続性・データ主権」の講演資料です。

講演詳細についてはこちらを御覧ください https://events.nikkeibp.co.jp/event/2026/nxta260623/

Transcript

1. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. Azure Local × IOWN APN で実現する拠点間HA構成 ~ソブリンAI時代に求められるState管理・運用継続性・データ主権~ NTTドコモビジネス イノベーションセンター 鈴ヶ嶺 聡哲
2. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 2 アジェンダ 1. 生成AIからAgentic AIへ 2. Agentic AIでは 「State」 が発生する 3. Tool利用によりGPU以外の処理と業務連携が増える 4. 「State」はデータ主権の対象になる 5. ソブリンAI時代に求められるデータ主権 6. ML Systems時代の教訓 7. Agentic AI System全体像 8. Enterprise Systemとして求められる堅牢性 9. Azure Local Rack Aware ClusterによるStateful HA基盤 10.Azure Local x IOWN APNによる拠点間HA構成の拡張 11.実証例：拠点分散Stateful Agentic AI基盤の構築 12.まとめ
3. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 3 生成AIからAgentic AIへ 生成AI 単発・一往復で完結（Stateless） ユーザーが質問（プロンプト） 生成AI が回答を生成 回答を受け取る → 終了 1回のやり取りで完結し、Stateは残らない。 続きはそのつど人間が指示する。 自律化 Agentic AI 目的を与えれば、自律的に反復して業務を進める（Stateful） 1 目的を理解 2 計画・タスク分解 3 Tool実行・外部システム操作 4 結果を確認・判断（完了 / 再試行） 反復 ④で未完了なら ① へ戻り、完了まで反復する。 単発で完結する生成AIと、自律的に反復する Agentic AI の違い
4. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 4 Agentic AIでは 「State」 が発生する 1 目的理解 2 計画・分解 3 Tool実行 4 結果確認・判断 5 完了・人間確認 発生する状態 • 会話履歴 • ユーザー指示 発生する状態 • 実行計画 • サブタスク一覧 • タスク進行状況 発生する状態 • Tool呼び出し履歴 • 実行結果 • 外部API応答 • DB更新内容 • 中間結果キャッシュ 発生する状態 • エラー履歴 • リトライ状態 • 未処理タスク（キュー） 発生する状態 • 人間確認待ち • ワークフロー状態 • 監査ログ State Store 各ステップの状態を Stateful 基盤で保持・復旧する 状態が失われると、処理重複・誤実行・判断根拠の喪失につながり、業務を継続できない 堅牢な Enterprise System では、State を確実に守る必要がある。
5. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 5 Tool利用によりGPU以外の処理と業務連携が増える Agentic AI時代のCPU処理増大 https://group.softbank/media/Project/sbg/sbg/pdf/ir/presentations/2025/arm20260330_en.pdf https://arxiv.org/pdf/2511.00739 https://www.amd.com/en/blogs/2026/agentic-ai-changes-the-cpu-gpu-equation.html https://insights.trendforce.com/p/agentic-ai-cpu-gpu
6. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 6 Tool利用によりGPU以外の処理と業務連携が増える LLM Browser DB API File Workflow RPA Mail Ticket 増える処理（多くがCPU中心） • ブラウザ自動操作 / 社内システムへのログイン • API呼び出し / DB検索・更新 • ファイル読取 / PDF解析 / Excel・CSV処理 • 画像・帳票処理 / メール分類・下書き • チケット作成 / ワークフロー起動 / RPA連携 • バッチ処理 / 業務ルール判定 / 監査ログ記録 Tool実行環境が止まると、AI Agentは業務 を完了できない。 LLM/GPU基盤だけを冗長化しても、Agentic AI 全体のHAに はならない。 主にCPU処理が中心となるネットワーク・API・認証・監査 の信頼性も重要。
7. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 7 「State」はデータ主権の対象になる データに含まれ得る情報 顧客情報 社員情報 契約情報 取引情報 申請情報 医療・金融・行政データ 社内文書 業務判断履歴 Tool実行結果 API応答 監査ログ 認証・認可情報 一時的な中間データではなく、主権的に管理すべき業務データ 問われるのは「どこで・誰が」 どこに保存されるか どこで処理されるか 誰がアクセスできるか どの法域・運用主体の下で管理されるか AI Agentは社内データや業務システムに深く接続する 状態は統制すべきデータ資産
8. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 8 ソブリンAI時代に求められるデータ主権 ソブリンAIとは データとAIの処理・運用を自国／自組織の統制下に置き、外部の法域や事業者に依存せずに利用 国内で保持する 状態・業務データを国外に出さず、所在を 管理下に置く 国内で処理する 推論・Tool実行・データ処理を国内基盤で 完結させる 国内で統制する アクセス権・法域・運用主体を自組織がコ ントロール 特に要件が強い領域 行政 金融 医療 製造 重要インフラ データ主権を満たすには、ローカル／国内 のAI実行環境が必要になる。
9. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 9 では実際に、 Agentic AI System の全体像を どう考えればよいか？
10. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 10 ML Systems時代の教訓 MLはシステム全体のごく一部 • “Hidden Technical Debt in Machine Learning Systems” は、2015年にGoogleの 研究者らが発表したMLシステム設計に関する 代表的な論文 • モデルや学習コードの周辺には、データ収集、 検証、特徴量管理、設定管理、監視、リソー ス管理など多くの構成要素が存在する • MLシステムでは、通常のソフトウェア以上に 依存関係が複雑になり、技術的負債が見えに くい形で蓄積する • 特に、データ依存、パイプライン依存、設定 依存、モデル更新、フィードバックループが 運用上のリスクになる • つまり、本番MLの難しさは「モデルを作るこ と」ではなく、モデルを取り巻くシステム全 体を安定運用することにある Hidden Technical Debt in Machine Learning Systems https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf
11. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 11 Agentic AI System全体像 https://theneuralmaze.substack.com/p/hidden-technical-debt-in-agentic Agentic AIでも、LLMはシステム全体の 一部にすぎない • LLMの周辺には、Agent制御、Tool連携、 State管理、権限管理、監査、運用基盤が必要 • Agentは、計画・実行・Tool利用・結果確 認・再試行を行う • Tool連携により、DB、API、RPA、業務シス テムとの接続が増える • Stateには、会話履歴、タスク進捗、Tool結果、 承認状態、実行ログが含まれる • LLM性能だけでなく、State管理、権限管理、 監査、可用性、復旧性が重要になる • Agentic AIは、LLMアプリではなく Enterprise Systemとして設計すべき対象 • ML Systems時代と同様に、“LLMの外側”の 設計が成否を決める
12. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 12 Azure Cloud上におけるAgentic AI Systemのリファレンスアーキテクチャ https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/baseline-agentic-ai-systems-architecture/4207137
13. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 13 Enterprise Systemとしての堅牢性 1 State を堅牢に保つ 会話・タスク・Tool結果・監査ログを保 持し、障害後も復旧できる 失うと → 処理重複・誤実行・判断根拠の喪失 2 Tool 実行を止めない ブラウザ操作・API・DB更新などCPU処 理と業務連携を継続させる 止まると → 業務が完了しない（システム停止） 3 データ主権を守る 状態・実行結果を国内で保持・処理し、 自組織が統制する 守れないと → 統制の喪失・規制違反のリスク 設計原則 ①②③を満たすため、Stateful（データ、DB）は守り、Stateless（LLM）は分散する
14. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 14 Azure Local Rack Aware ClusterによるStateful HA基盤 ルーム単位のHA冗長化 • 2つの物理ラックを1つの Azure Local ク ラスターとして構成 • 各ラックをローカル可用性ゾーンとして 扱い、ノード・VM・管理機能を分散配置 • データコピーを2ラック間に均等配置し、 ラック単位の障害に備える • 片方のラックに障害が発生しても、もう 一方のラックでデータの整合性とアクセ ス性を維持 • ラック間同期レプリケーションのため、 専用ストレージネットワーク(RDMA)と 1ms以下の低遅延が必要 • ミッションクリティカルな拠点システム で、停止時間とデータ損失リスクを低減 https://learn.microsoft.com/en-us/azure/azure-local/concepts/rack-aware-cluster-overview?view=azloc-2606
15. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 15 Storage Spaces Direct が支える高可用性 高可用性を実現するストレージ基盤 • S2D は各サーバー内の NVMe / SSD を統合し、 クラスター全体の共有ストレージとして提供する • Software Storage Bus により、各ノードは他 ノードのローカルドライブを利用可能 • Rack Aware Cluster はラックを障害ドメインと して認識し、データをラック間に分散配置する • ラック単位の電源・ToR スイッチ・冷却障害発 生時も、残存ラックでサービス継続が可能 • 2+2 構成では Rack Level Nested Mirror によ り、ラック障害後も追加のノード／ドライブ障害 に耐える冗長性を提供する https://learn.microsoft.com/ja-jp/windows-server/storage/storage-spaces/storage-spaces-direct-overview
16. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 16 Azure Local Rack Aware ClusterによるStateful HA基盤 ルーム単位のHA冗長化 • 2つの物理ラックを1つの Azure Local ク ラスターとして構成 • 各ラックをローカル可用性ゾーンとして 扱い、ノード・VM・管理機能を分散配置 • データコピーを2ラック間に均等配置し、 ラック単位の障害に備える • 片方のラックに障害が発生しても、もう 一方のラックでデータの整合性とアクセ ス性を維持 • ラック間同期レプリケーションのため、 専用ストレージネットワーク(RDMA)と 1ms以下の低遅延が必要 • ミッションクリティカルな拠点システム で、停止時間とデータ損失リスクを低減 https://learn.microsoft.com/en-us/azure/azure-local/concepts/rack-aware-cluster-overview?view=azloc-2606 再掲 1ms 以下という要件は、光伝搬遅延を考慮すると、約100km圏内の拠点間接続であれば物理的に視野に入る。 IOWN APN の低遅延・大容量ネットワークを活用し、従来のラック／ルーム内HAを拠点分散HA へ拡張できる可 能性を検証する。
17. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 17 IOWN APNの特徴 IOWN APN All Photonics Network 大容量高品質 低消費電力 低遅延 通信ネットワークのすべての区間で光波長を占有することで「大容量」「低遅延」「低消費電力」を実現 2024.3.1 「APN専用線プラン powered by IOWN」の提供開始
18. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 18 IOWN APNの特徴 将来的には：サーバからPCまでデータを光で処理、無駄なエネルギーを低減 光で 処理 光で 処理 光で 処理 光で処理・送信 光で処理 これまでは：データを電気→光→電気・・・と変換、多くのエネルギーを使用 通信ビル 通信ビル 通信ビル 企業・自宅 データセンター NW機器 NW機器 NW機器 NW機器 PC 光で送信 電気で 処理 電気で 処理 電気で 処理 電気で処理 電気で処理 NW機器 サーバー 光の波長パスでユーザ拠点間を接続 現状 APN 通信ネットワークのすべての区間で光波長を占有することで「大容量」「低遅延」「低消費電力」を実現
19. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 19 障害ドメインを 「ラック」 から 「拠点」 へ広げる 従来のRack Aware Cluster ラック障害（Room） サーバ障害 拠点障害・災害 ラック障害（Room） サーバ障害 対応する仕組み サーバ障害 VM フェイルオーバー ラック障害 Rack Aware Cluster 拠点障害・災害 IOWN APN（拠点間） IOWN APNを活用した場合 障害ドメインのカバー範囲
20. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 20 Azure Local x IOWN APNによる拠点間HA構成の拡張 秋葉原 三鷹 IOWN APN HA構成を拠点分散へ拡張 構成 • Dell AX-750(L40S GPU 2枚搭載)を各拠点 に2台ずつ配備 • GPUはDDAを利用してパススルー • 2+2の冗長構成 要件 • 拠点間は約 0.6ms よって 1ms 以下の遅 延要件を満たす • 高帯域 100Gbps • 高速なストレージ通信(RDMA) 基本性能 • VMの拠点間移行時間(停止時間) ※1 415ms ※1 8vCPU, Memory 16GBのIdle VMにpingによる外部応答の停止時間を計測 IOWN APN活用により、 Azure Local Rack Aware Clusterを拠点間HA構成に拡張！！
21. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 21 秋葉原 三鷹 実証例：拠点分散Stateful Agentic AI基盤の構築 IOWN APN Stateless Stateful GPU/LLM Stateless Stateful GPU/LLM LLM Proxy LLM Proxy Virtual IP Address 通常時 負荷分散によるGPUリソースの効率的な活用 Agentic AI File/Config/DB
22. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 22 秋葉原 三鷹 実証例：拠点分散Stateful Agentic AI基盤の構築 IOWN APN Stateless Stateful GPU/LLM Stateless Stateful GPU/LLM LLM Proxy LLM Proxy Virtual IP Address 障害発生時 Agentic AI File/Config/DB Agentic AI File/Config/DB 運用継続
23. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 23 DEMO: Coding Agent 実行中の擬似障害(VM移動) DEMO
24. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 24 まとめ ① State を堅牢に保つ IOWN APN活用によるAzure Local Rack Aware Clusterの拠点間拡張 により耐障害性の向上 IOWN APN + Azure Local Rack Aware Cluster ② Tool 実行を止めない Tool 実行 VM をHA冗長化し、自動 リトライで業務プロセスを止めずに 継続する VM冗長化 ③ データ主権を守る Local LLM 実行・業務データ・ State をローカルで保持・処理し、 アクセスと法域を自組織が統制する Local LLM / Data Control 拠点A 拠点B IOWN APN