Summary
- Delos Cloud は、もはや単なる覚書や政策構想ではない。同社の発表によると、ギュータースロー広域圏の第1運用センターは2025年9月に稼働開始し、ライプツィヒ広域圏の第2運用センターは2026年1月に稼働開始、セキュリティ運用センターは既に準備完了、そしてデータセンターは本番サービス提供に向けた最終準備段階にあった。
- 商業的な提供内容は、Microsoft Azure テクノロジーを基盤とし、Delos Cloud が Arvato Systems の要員によって運用する、ドイツ公共部門向けクラウドである。Delos は、インフラを所有し、プラットフォームを運営し、製品のライセンスを提供するとしている。一方、Microsoft は技術を提供し、Arvato はドイツでの運用を支援する。
- 公開ルーティングの証拠は実在する。AS198678 の RIPE RDAPは Delos Cloud GmbH を指名し、RIPEstat のアナウンスプレフィックスデータは4つの IPv4 プレフィックスと1つの IPv6 アグリゲートを示し、RIPEstat ルーティングステータスは広範なコレクター可視性を示している。依存関係も明確である。RIPEstat ネイバーデータは、別の Delos Cloud システムである AS212185 を、AS198678 の単一の公開ネイバーとして観測している。
- したがって、レジリエンスのテストは、Delos Cloud が信頼できる公開フットプリントを持つかどうかではない。実際に持っている。テストは、重要な公共部門ワークロードが依存する前に、顧客がホステッドサービスの背後にある施設の電力、冷却、キャリア多様性、保守慣行、在庫、サポートエスカレーションを検証できるかどうかである。
公開証拠は、本格的な運用調査を裏付けるに至っている
Delos Cloud GmbH は、公式企業ページ、SAP のリリース、パートナーページ、顧客パイロット資料、インターネットレジストリデータを通じて可視化されている。同社の概要ページは、ドイツのセキュリティ要件に適合し、連邦、州、地方自治体の IT プロバイダーを支援することを目的とした、ドイツのデジタル公共サービス向けソブリンプラットフォームとして位置づけている。製品ページでは、提供内容は Microsoft サービスを中核とし、Delos Cloud がソブリンとして提供するものであり、従量制およびユーザーベースのサービスを含む一方で、サードパーティソフトウェア、オープンソースソフトウェア、顧客開発アプリケーションにも余地を残していると述べている。
これは、企業の存在を問うだけの「薄い足跡」仮説が示唆するよりも、強力な公的立場である。より適切な下方修正は異なる。Delos Cloud は、実在する高度な構築物として扱うに十分な証拠を有している。しかし、部外者がすべてのデータセンター、トランジット、保守、移行依存関係を本番実証済みと評価できるだけの、物理的かつ運用上の詳細をまだ公開していない。公共部門向けクラウドにおいては、ブランドの認知度よりも、この区別の方が重要である。ソブリンオファーも依然としてホステッドキャパシティのオファーである。それは、設備が故障した際に使用可能なサービスへと、建物、ラック、ルーター、スタッフ、契約を変換しなければならない。
タイムラインは重要である。2025年9月の SAP リリースは、Delos Cloud が第1運用センターをギュータースロー広域圏で稼働開始したと述べている。同リリースによれば、60名以上の人員が常駐し、Arvato Systems の運用スタッフが Delos Cloud サービスを運営し、同センターがプラットフォーム運用、セキュリティ、認証において主要な役割を担うとしている。また、ライプツィヒ広域圏の第2運用センターが完成間近であり、フランクフルト広域圏の第3運用センターが間もなく着工され、同広域圏のセキュリティ運用センターは準備完了であるとも述べている。
2026年1月の SAP リリースは、状況をさらに進展させた。同リリースは、ライプツィヒ広域圏の第2運用センターが稼働開始し、本番運用のための運用センターインフラが完了し、2つの完成した運用センターが、プラットフォームに障害や危機シナリオに対する地理冗長的な運用保護を提供すると述べている。同じリリースでは、関連するセキュリティ運用センターが準備完了であり、Delos Cloud のデータセンターが本番運用に向けた最終準備段階にあることも伝えている。また、ライプツィヒセンターは80のワークプレースを提供し、厳格なセキュリティ対策の下で24時間365日の運用を行うとしている。
公開されている顧客証拠も、一般的な関心の域を超えた。Delos Cloud の顧客ページには、パイロット顧客や、連邦および州レベルの公共利用事例における具体例が挙げられており、連邦雇用機関、ノルトライン＝ヴェストファーレン州の金融・テクノロジープロジェクト、バーデン＝ヴュルテンベルク州の文化施設などが含まれている。2026年5月の SAP リリースは、シュトゥットガルト州立劇場が Delos Cloud プラットフォーム上で Microsoft Office 365および一部の Azure サービスのパイロットを開始し、バーデン州立劇場カールスルーエも参加し、SVA がコンサルティングおよび実装パートナーを務めると述べている。2026年6月の SAP リリースは、Delos Cloud がパートナープログラムの開始にあたり、15社と戦略的パートナーシップを締結したと伝えている。
これらを総合すると、これらの情報源は懐疑的な却下ではなく、本格的なインフラ分析を正当化する。もはや問われるのは、Delos Cloud が公的記録に登場するかどうかではない。問われるのは、実証された立ち上げインフラと、顧客が依然として精査する必要がある部分との境界線がどこにあるかである。すなわち、物理的なデータホール、キャリアルート、サポートエスカレーション、復旧パス、セキュリティ認証、そして Microsoft テクノロジーベースへの商業的依存である。
ドイツがサービスエリアだが、サイトマップは依然として限定的
Delos Cloud のサービスエリアに関する約束は、異例なほど明確である。同社の資料は、このプラットフォームがドイツの公共部門向けであり、データ処理と運用はドイツ国内に留まると繰り返し述べている。2025年2月の価格設定リリースは、このプラットフォームがドイツの公共顧客向けであること、機密性の高い行政データはドイツ国内のデータセンターおよび運用サイトでのみ処理されること、Delos Cloud GmbH とプラットフォームがドイツの管轄下にあることを述べている。D-Trust 証明書リリースも、暗号化および認証通信のためのドイツ TLS 証明書について説明しながら、同じローカリティの点を強調している。
このローカリティは商業的に価値がある。同時に、それは完全なサイトマップではない。公開リリースでは、ギュータースロー広域圏とライプツィヒ広域圏の運用センター、およびフランクフルト広域圏のセキュリティ運用センターが特定されている。データホールの住所、ユーティリティ供給設計、ラック数、電力密度、建物所有者、メットミールーム、燃料手配、キャリア引き込み口などは公開されていない。2026年1月には Delos Cloud のデータセンターが最終準備段階にあると述べているが、ここで確認した公開リリースではそれらのデータセンターの名称は明らかにされていない。
この境界は明確に保つべきである。運用センターは、人々が監視、操作、セキュリティ確保、対応を行う場所である。データセンターは、コンピューティング、ストレージ、ネットワーク機器が電力を消費し、熱を排出し、キャリアに接続する場所である。この2つは関連しているが、互換性はない。2サイトの運用体制は、コンピューティングプラットフォームに別の物理的な依存関係があっても、スタッフと指揮のレジリエンスを向上させることができる。逆に、運用デスク、アクセス制御、キャリアエスカレーション、変更承認が利用できない場合、2つのデータホールがあっても顧客にとっては障害となり得る。Delos Cloud の公開資料は、運用センターレイヤーに関しては最も強力であり、データホールレイヤーに関しては弱い。
同じ注意は地理冗長性にも当てはまる。2026年1月のリリースは、2つの完成した運用センターが、地理冗長性を通じて障害や危機シナリオに対する運用を確保すると述べている。これは運用レイヤーに関する重要な主張である。しかし、それだけでは、すべての顧客ワークロードが2つの独立したデータホール間で同期レプリケーションされていること、すべての管理システムがアクティブ／アクティブ制御を備えていること、すべての顧客サービスがテスト済みのリージョンフェイルオーバーを備えていること、すべてのストレージサービスが特定のリカバリポイントを満たせること、などを証明するものではない。これらの詳細は顧客向け文書に存在するかもしれないが、すべてが公開されているわけではない。
調達においては、適切なサイトに関する質問はしたがって具体的である。どのリージョン、可用性設計、データセンターペアが、注文されるサービスをサポートするのか？どの機能がギュータースロー、ライプツィヒ、フランクフルトから制御され、どの機能がデータホール内で実行されるのか？運用センターが吸収できる障害はどれで、どの障害がデータセンタースタッフ、キャリアエンジニア、予備ハードウェア、Microsoft テクノロジーサポートを必要とするのか？公開資料は、その精査の入り口を開くが、それを閉じるものではない。
オペレーターの境界が中核的な主権の主張である
Delos Cloud の主権に関する論拠は、役割の分離に基づいている。2025年2月の価格設定リリースは、Delos Cloud が Microsoft Azure のハイパースケールテクノロジーを使用するが、それらのサービスをドイツの行政にソブリンとして提供すると述べている。Delos Cloud GmbH がインフラ所有者としてプラットフォーム運用と製品ライセンスを引き受ける。Microsoft はテクノロジーサプライヤーとして貢献する。2024年10月の SAP 契約リリースおよび同じ契約に関する Bertelsmann のレポートでは、Delos Cloud、Microsoft、Arvato Systems 間の最終契約について説明し、Arvato Systems がドイツでのプラットフォーム運用を支援すると述べている。
この構造は重要である。なぜなら、公共部門のバイヤーは単に仮想マシンや Office コラボレーションを購入しているだけではないからだ。法的かつ運用上のコントロールの割り当てを購入しているのである。Delos Cloud は、ドイツの企業によって運用され、ドイツの管轄下にあり、ドイツのセキュリティクリアランスを受けた要員によって、ドイツ国内でデータ処理が行われる環境で、Microsoft テクノロジーを提供すると述べている。これは、グローバルリージョンの通常のパブリッククラウドサービスを購入し、ドイツの請求ラッパーを追加するのとは異なる提案である。
この境界は依存関係も生み出す。Microsoft がテクノロジーサプライヤーであるならば、Delos Cloud は依然として Microsoft のソフトウェア開発、セキュリティアップデート、製品進化、ライセンス権に依存する。Arvato Systems のスタッフが運用センターでサービスを運用するならば、Delos Cloud は Arvato の採用、トレーニング、クリアランス、シフトカバレッジ、施設手順に依存する。SAP が親会社および投資家であるならば、Delos Cloud は SAP のスケールから恩恵を受けるが、同時に資金調達、契約、公共の信頼を整合させ続けなければならない戦略プログラムの内部に位置することになる。主権はいくつかのリスクを低減するが、注意深く設計された連鎖の中に他のリスクを集中させる。
Bleu および Microsoft との2025年11月のレジリエンス発表は、その連鎖を浮き彫りにしている。SAP リリースは、Delos Cloud と Bleu が広範な危機・緊急シナリオに向けた国境を越えた技術的・運用上の協力に合意し、一方で Delos Cloud と Microsoft は、外部の制限によって特定の顧客に対する Microsoft クラウドサービスが影響を受けた場合に、欧州での事業継続を支援することを目的とした別個の契約を締結したと述べている。これは、Delos Cloud が地政学的なサービス継続リスクについて考慮していることを示すため有用である。また、オペレーターの境界を単一の壁として扱うことができない理由も示している。いくつかの緊急時の救済策は、法的権利、ソフトウェアアクセス、Delos のキャパシティ、運用スタッフ、顧客の移行能力を同時に必要とするからである。
支持可能な結論はバランスの取れたものである。Delos Cloud は、明示された役割分離を伴う公的な主権設計を有している。その設計は意味がある。それはまた、物理的施設、アップデートパス、スタッフ手順、緊急時移行の取り決めが負荷の下で機能するという証明の代わりにはならない。顧客はその設計を拒否する必要はない。顧客はそれを障害に対してテストする必要がある。
Delos Cloud が販売するのは単一の単純なクラウド製品ではない
Delos Cloud の製品カタログは、インフラ、プラットフォーム、コラボレーションサービスにわたる。ポートフォリオページには、Azure Foundational Services、Azure Mainstream Services、Office 365、SAP サービス、サードパーティソリューション、オープンソースソフトウェア、顧客開発アプリケーションが記載されている。コンピューティング、ストレージ、ネットワーキング、データベース、コンテナサービス、監視、セキュリティ関連項目がポートフォリオ全体に含まれている。ロードマップページは、サービスのセットを、ソブリン公共部門向けクラウドへの段階的な道筋として位置づけている。
この幅広さはキャパシティにとって重要である。仮想マシンは CPU、メモリ、ストレージ、ネットワークポート、ホストスケジューリングキャパシティ、管理プレーンキャパシティ、およびサポート時間を消費する。マネージドデータベースはストレージ、メモリ、バックアップキャパシティ、および運用ケアを消費する。コラボレーションテナントは ID、メール、ストレージ、ポリシー、およびサポートキャパシティを消費する。バックアップやサイトリカバリサービスは、二次ストレージ、ネットワークスループット、リストア手順、およびテスト時間を消費する。Kubernetes サービスはコントロールプレーンキャパシティ、ワーカーノード、イメージ、ロギング、およびセキュリティメンテナンスを消費する。購入者は1つのクラウドカタログを見るが、オペレーターは多数のキャパシティプールを運用しなければならない。
2025年2月の価格設定リリースは、経済的な枠組みを付け加える。それによると、Delos Cloud はドイツの公共顧客向けのソブリン Microsoft サービスを、現行の Microsoft ドイツ定価の15%増しで価格設定し、その価格は Delos Cloud が提供する Azure Foundational Services、Azure Mainstream Services、Microsoft Office 365を含む Microsoft インフラおよびプラットフォームサービスに適用される。この追加料金は主権の可視的な価格であるが、キャパシティ保証ではない。15%の上乗せがドイツでの運用、セキュリティ要件、分離されたインフラ、および管理の取り決めに対して支払われるのは、プラットフォームが十分な需要に達し、かつ基盤の設備が使用可能な予備を考慮して計画されている場合に限られる。
使用可能な予備は隠れた分母である。Delos Cloud は運用センターと製品ポートフォリオを発表できるが、本番移行を評価する顧客は、より公開が難しいキャパシティの数値を必要とする。すなわち、委託された IT 負荷、販売済み負荷、予備負荷、サービス別のホストクラスター、ストレージ予備、ネットワークのオーバーサブスクリプション、バックアップキャパシティ、サポート要員、パッチ適用枠、リストアパフォーマンスなどである。インストールされたサーバーは、使用可能なクラウドキャパシティとは同じではない。ハードウェアが搭載されていても、テスト済みの自動化、予備ストレージ、承認されたメンテナンスパス、キャリア多様性がないラックは、重要なワークロードを安全に担うことはできない。パイロットテナントを開始できるリージョンが、大規模な部門移行に向けて自動的に準備が整っているわけではない。
これが、プラットフォームのオープンでベンダーニュートラルな主張が重要である理由である。パートナープログラムと製品ページは、サードパーティが Delos Cloud にソリューションを持ち込めることを示している。これはエコシステムの深みを改善する可能性があるが、同時に多様性も追加する。Delos インフラ上にパートナーが構築したアプリケーションは、Office 365サービスとは異なるサポート、ライセンス、パッチ、リストア条件を持つ場合がある。オープンソースコンポーネントは、Microsoft 提供のコンポーネントとは異なるメンテナンス責任を持つ場合がある。顧客開発のアプリケーションは、Delos が部分的にしか提供しないランディングゾーン、監視、バックアップ、シークレット処理、ネットワークセグメンテーションを必要とするかもしれない。クラウドカタログはキャパシティ計画の出発点であり、終点ではない。
ルーティング証拠は到達可能性を証明するが、物理経路全体を証明するわけではない
Delos Cloud のネットワーク証拠は、多くの初期段階のソブリンクラウドプロジェクトより強力である。AS198678 の RIPE RDAPは、この自律システムをdeloscloudとして識別し、2023年5月1日登録、登録者は Delos Cloud GmbH であるとしている。RIPEstat の AS 概要は、この AS が2026年7月12日にアナウンスされたと報告した。アナウンスプレフィックスビューは、2026年6月28日から7月12日の期間に、123.2.0.0/15、142.221.0.0/16、161.37.0.0/16、168.86.0.0/17、2a07:3040::/32の5つの可視プレフィックスを示した。
これらのプレフィックスの規模は些細ではない。RIPEstat ルーティングステータスは、294,912個の IPv4 アドレスを含む4つの IPv4 プレフィックスと、65,536 /48に相当する1つの IPv6 アグリゲートを報告した。また、クエリ時点において、サンプリングされた326の IPv4 ピア中326、322の IPv6 ピア中322がルートを観測しているとも報告した。Delos の IPv4 レンジに関するRIPE RDAP IP レコードは、可視割り当てのアドレス保持者として Delos Cloud GmbH を特定している。AS198678 と123.2.0.0/15に対するRIPEstat RPKI バリデーションは有効なオリジンステータスを返し、対応するIPv6 バリデーションも AS198678 と2a07:3040::/32に対して有効を返した。
これらの事実は、1つの重要な主張を裏付ける。すなわち、Delos Cloud は自社名義で稼働中の公開インターネットルーティングを有している。しかし、クラウドバイヤーが関心を持つすべての主張を裏付けるものではない。RIPEstat ネイバービューは、AS198678 の公開ネイバーを1つ観測した：AS212185 である。AS212185 の RIPE RDAPは、その AS をdeloscloudconnectとして識別し、2025年6月26日に Delos Cloud GmbH に登録された。AS212185 のRIPEstat アナウンスプレフィックスデータは2つの IPv4 /23と2つの IPv6 /48を示し、一方で AS212185 のRIPEstat ネイバーデータは AS2914、AS3356、AS198678 を観測した。
このパターンは、内部オリジン AS が Delos 接続 AS の背後にあり、それが大規模なアップストリームを通じてグローバルトランジットに到達しているように見える。それは完全に意図的でレジリエントであるかもしれない。また、公開 BGP ビューでは見えない物理的な依存関係を隠しているかもしれない。AS212185 は多様なファイバー引き込み口を受けているか？AS2914 と AS3356 は別々のメットミールーム、管路、光システムを通じて接続されているか？どちらかが故障した場合に、もう一方がフル本番負荷を担えるか？管理プレーンと顧客プレーンは分離されているか？PeeringDB で可視化されていないインターネットエクスチェンジピアリングはあるか？公開ルーティングはこれらの質問に答えることができない。コレクターが観測する経路形状を示すことしかできない。
公開 PeeringDB エントリが存在しないことも、限定的な証拠である。AS198678 の PeeringDBへのクエリはネットワークレコードを返さない。PeeringDB は任意であり、存在しないからといって Delos Cloud が施設、プライベート相互接続、またはアップストリーム契約を欠いていることを意味しない。しかし、公共機関が PeeringDB を使用して施設の存在、エクスチェンジポート、トラフィックポリシー、またはピアリング連絡先詳細を検証できないことを意味する。公共部門ネットワークへの信頼できる接続に依存するソブリンクラウドにとって、欠落した公開相互接続プロファイルは、直接の顧客証拠の必要性を高める。
したがって、ネットワークのグレードは弱いというよりも中程度である。ルートは稼働中であり、RPKI で有効であり、広範に可視化されている。公開ルートグラフは、ネットワークエッジがレジリエントであると証明するのに十分な物理的多様性を明らかにしていない。顧客は、影響度の高いワークロードを Delos Cloud に依存する前に、ルートオリジン設計、アップストリームキャリアリスト、物理的引き込み口の多様性、DDoS 処理、プライベート公共部門接続、経路漏洩保護、フェイルオーバーテスト結果、メンテナンス通知ルールを尋ねるべきである。
電力と冷却は、なおも地味な証明ポイントである
ソブリンクラウドも依然として、ソフトウェアがその上に重ねられた電力設備および冷却設備である。Delos の公開リリースは、データがドイツのデータセンターで処理され、それらのデータセンターが2026年1月に本番運用の最終準備段階にあったと述べている。しかし、ユーティリティ容量、変圧器トポロジー、UPS 設計、発電機定格、燃料稼働時間、冷却トポロジー、水害リスク、防火区画、ラック密度制限などを開示していない。この省略はセキュリティ上および商業上の理由から理解できるが、購買担当者に、省略できない疑問を残す。
BSI C5 カタログページおよびC5:2026カタログ PDFは、このレベルの証拠がクラウド保証にとって標準的である理由を示している。クラウドセキュリティには、物理的セキュリティ、運用、インシデント対応、事業継続、可搬性、サービスレベル、サプライチェーン管理が含まれる。Delos Cloud 自身の資料も、BSI 要件に準拠し、機密性の高い公共部門データの処理をサポートすることを目指していると述べている。その主張は、最終的には立ち上げ声明だけでなく、認証とテスト証拠によって裏付けられるべきである。
電力について、顧客はサービス境界を知る必要がある。顧客ワークロードは物理的に独立した2つのデータホールに配置されているか？ユーティリティフィードは変電所からラックまで独立しているか？委託された IT 負荷は、単に設置されたものと比較してどの程度か？非常用発電機は IT 負荷と冷却を同時にまかなえるか？長時間の停電中の燃料補給時はどうなるか？どのシステムが同時メンテナンス可能で、どのメンテナンス状態が冗長性を低下させるか？A/B ラックフィードも、上流の1つの配電盤や1つの UPS トレインに集約されている場合には、大した意味を持たない。
冷却について、顧客は熱除去マップを必要とする。プラットフォームは、吸気温度が上昇し、コンポーネントがスロットリングし、ホストが負荷を削減する間も電力を供給され続けることができる。冷却設備は販売負荷に対して十分な予備を持っているか？チラー、ポンプ、制御系、給水、熱交換器は独立した電力でバックアップされているか？顧客ワークロードを移動することなく冷却メンテナンスを実施できるか？冷却ユニット、コントローラー、センサーネットワークに障害が発生した場合のインシデントパスは？これらは学術的な懸念ではない。短時間の設備故障がサービスインシデントになるかどうかを決定づける。
火災と水害リスクに関して、顧客は建物固有の緩和策を必要とする。ドイツ国内というロケーションは管轄と人員配置に有利だが、床面高さ、漏洩検知、ガス消火、煙区画、燃料貯蔵、隣接テナントリスク、緊急アクセスを明らかにするものではない。公式のセキュリティ評価がそれらの事実をカバーしているかもしれない。公開リリースはそれらを公開していない。適切な秘密保持の下で事実がバイヤーから見えるようになるまでは、安全な公的見解は、データセンターのロケーションはドイツ国内であり、データホールのレジリエンスは公的にスコア可能ではない、というものである。
修理ウィンドウこそ、誰が実際にサービスを運用しているかが顧客に分かる場である
メンテナンスウィンドウは、設計を現実に変える。サービスには2つのサイト、2つのキャリア、重複したコンポーネントがあるかもしれないが、修理手順が安全でない手作業を要求したり、スペアパーツが不足していたり、スタッフがサイトにたどり着けなかったり、変更がロールバックパスなしで適用されたりすれば、やはり失敗し得る。この点に関する Delos Cloud の最も強力な公開証拠は、その運用センターの構築である。すなわち、完成した2つの運用拠点、Arvato Systems からのセキュリティクリアランスを受けたドイツ人スタッフ、セキュリティ運用センター、そして成長するパートナーエコシステムである。
これは肯定的である。しかし同時に、次の一連の疑問も生じさせる。どのチームがデータホールのラックを開けられるのか？どのチームが故障したストレージシェルフを交換できるのか？どのチームがルーター変更を承認できるのか？どのチームが Microsoft テクノロジーのアップデートを遅延または拒否できるのか？どのチームがメンテナンスウィンドウを顧客に通知するのか？どのチームがインシデントを宣言するのか？三者構成の設計では、顧客体験は機器数と同じくらい、契約と権限マップに依存する。
Arvato Systems の Delos Cloud ページは、Arvato を行政向けソブリンクラウドのパートナーとして位置づけており、2025年9月と2026年1月の Delos リリースも、運用センター内の Arvato Systems 運用スタッフを特定している。Bertelsmann のレポートは、Arvato Systems がプラットフォームを運用し、複数のドイツ拠点が長期的な運用に関与する、と付け加えている。これは Arvato に修理連鎖における重要な役割を与える。しかし、正確なエスカレーションラダー、リモートハンズの応答時間、スペア在庫ポリシー、チケット目標などは開示されていない。
修理ウィンドウはまた、公共部門の変更管理とも相互作用する。通常のハイパースケールクラウドは、グローバルリージョン全体に継続的に変更を展開するかもしれない。ソブリン公共部門クラウドは、より厳格な通知、承認、文書化、職務分離を必要とするかもしれない。これは制御を改善し得るが、うまく設計されていなければ修正を遅らせる可能性がある。顧客は、標準的なメンテナンスリードタイム、緊急変更ルール、顧客承認ポイント、ロールバック手順、そして計画メンテナンスが代表的な規模でサービス損失なく完了したという証拠を求めるべきである。
サポートカバレッジも同じように重要である。運用センターのリリースは24時間365日の運用を約束している。しかし、24時間365日の運用が、自動的にすべてのサービスに24時間365日の専門サポートがあること、すべてのパートナーアプリケーションが夜間に修理できること、すべての顧客が同じ重大度パスを持つことを意味するわけではない。Delos Cloud のパートナープログラムは、パートナーをサービス、販売、構築の役割に分けている。これは、1つのインシデントパスにおいて、顧客が Delos Cloud、サービスパートナー、ソフトウェアベンダー、内部の公共部門 IT プロバイダーを抱える可能性があることを意味する。修理ウィンドウでは、誰が誰に連絡するのか、誰が時間を管理するのか、誰が修正を実行できるのかを明示しなければならない。
顧客移行は、単発のオンボーディングタスクではなく、依存関係である
Delos Cloud が存在するのは、公共部門の顧客が、ローカリティ、管轄、運用管理を放棄することなく、最新のクラウドサービスを望むからである。その移行の約束は中心的である。それはまた、レジリエンスを過大評価しやすい領域の1つでもある。ソブリンクラウドにワークロードを移行しても、自動的に移植可能、復元可能、あるいは基盤となるテクノロジーベースから独立したものになるわけではない。
Delos の顧客ページは、パイロットを、大規模採用前に技術的、契約的、組織的な取り決めをテストする方法として説明している。シュトゥットガルト州立劇場のリリースは、パイロットが Office 365機能と選択された Azure サービスを実条件下でテストし、セキュリティ、効率性、公共文化事業への統合に注意を払うと述べている。これはパイロットの良い使い方である。仮定ではなく経験的に移行を扱っている。
顧客にとって、現実的な移行の質問は具体的である。ID はどのように統合されるか？テナントポリシーはどのように設定されるか？どの Office 365データがエクスポートおよびリストア可能か？どの Azure サービスがローンチ時に含まれ、どのサービスが後から登場するか？仮想マシンをイメージとして移動できるか、それとも再構築のみか？データベース、バックアップ、ログ、暗号化キー、監視データはどのようにエクスポートされるか？公共部門組織が通常の Microsoft サービスで開始し、後に Delos Cloud に移行する場合、あるいは Delos Cloud で開始し、他の場所への緊急移行が必要になった場合、何が起こるのか？ワークロードがマネージドサービスを多用するほど、移行は製品固有のエクスポートパスに依存するようになる。
ドイツ行政クラウド戦略資料およびFITKO DVC ガイダンスは、孤立した1つのプラットフォームではなく、より広範な連邦クラウドエコシステムを指し示している。この文脈は重要である。Delos Cloud は1つの大きなコンポーネントかもしれないが、公的機関は相互運用性、調達の明確性、そして、ある依存関係を単に国内の別の依存関係で置き換えることを避ける方法も必要としている。データのローカリティは1つの問題を解決する。データのポータビリティは別の問題を解決する。
2025年11月の Microsoft 継続性契約は、移行をさらに明確にしている。それによると、外的な制限により Microsoft が特定の顧客にサービスを提供できなくなった場合、それらの顧客はワークロードを Delos Cloud に移行するオプションを持ち得るとしている。これは戦略的な緊急時対応策である。その実用的な価値は、キャパシティ、法的権利、ソフトウェアアクセス、互換性のあるサービスバージョン、顧客の準備状況、帯域幅、テスト演習に依存する。一度もリハーサルされたことのない緊急移行は、単なる期待であり、復旧能力ではない。
したがって、購買担当者は移行成果物を稼働中の運用証拠として扱うべきである。必要な証拠には、ランディングゾーンパターン、ID 統合ガイド、エクスポート手順、サービスごとの制限、バックアップおよびリストアテスト、ロールバック基準、コスト影響、顧客受け入れテストが含まれる。目的は、すべてのワークロードをクラウド非依存にすることではない。目的は、依存関係が意図的なものである場所、一時的なものである場所、そして危険になり始める場所を正確に知ることである。
主要な障害経路は特殊なものではなく、ありふれたものである
Delos Cloud の戦略的な状況設定は、リスクを地政学的に感じさせるかもしれないが、ほとんどのサービス障害は依然としてありふれたインフラから始まるだろう。
第一の経路は、ラックまたはホストの故障である。サーバー、ストレージシェルフ、トップオブラックスイッチ、または電力分配ユニットが故障する。予備ハードウェアが現地にあり、自動化が機能していれば、顧客への影響はほとんど見られないかもしれない。しかし、故障が小規模なサービス群、未成熟なリージョン、または予備が限られた管理システムに当たった場合、顧客はプロビジョニングエラー、パフォーマンス低下、リストア失敗を経験するかもしれない。Delos Cloud の公開資料は、クラスターサイズ、予備比率、リストア時間を公開していない。
第二の経路は、アップストリームまたはキャリアの障害である。公開 BGP は、AS198678 が AS212185 の背後にあり、AS212185 が大規模なトランジットプロバイダーに隣接していることを示している。設計は良好なプライベート多様性を有しているかもしれないが、公開ルートグラフはそれを証明しない。キャリアのメンテナンスイベント、ファイバー切断、光プラットフォーム障害、経路漏洩などが、コンピュートが健全であっても、顧客ワークロードや管理パスを孤立させる可能性がある。顧客は、AS 番号だけでなく、物理的な経路多様性を知る必要がある。
第三の経路は、ソフトウェアアップデートおよびプロバイダー契約の障害である。Delos Cloud は、ドイツでの運用と管理を維持しつつ、Microsoft テクノロジーに依存している。セキュリティアップデート、機能変更、ライセンス、緊急時の権利はすべて、その境界を安全に越えなければならない。アップデートの流れが少なすぎると、セキュリティと互換性のリスクが生じる。仲介されないアップデートの流れが多すぎると、主権の論拠が弱まる。公開リリースは契約の存在を示しているが、顧客は運用ルールと証拠を必要としている。
第四の経路は、サポートとスタッフの飽和である。2つの運用センターはスタッフとサイトのリスクを低減するが、広範なインシデントは依然としてサービスデスク、パートナーチーム、エスカレーションキューを過負荷状態にし得る。公共部門の顧客は、インシデント分類、重大度目標、コミュニケーションテンプレート、時間外権限、および演習からの証拠を求めるだろう。主要な認証、メール、ネットワーク、ストレージインシデントは、単一の仮想マシンの停止よりもはるかに多くの人に影響を及ぼす。
第五の経路は、請求、調達、利用資格の不一致である。Delos Cloud の公開提供は、ドイツ国内の適格な公共顧客に限定されており、パートナーおよび公共部門 IT プロバイダーを通じて提供される。サービスが技術的に準備ができていても、契約、利用資格、予算、調達カタログ、パートナーの可用性、またはセキュリティ承認によってブロックされる可能性がある。ホストされたキャパシティは、顧客が適用される公共部門ルールの範囲内で、それを注文、構成、接続、サポートできる場合にのみ使用可能となる。
第六の経路は、データポータビリティの障害である。顧客が ID、メール、ストレージ、データベース、スナップショット、ログを十分に速くエクスポートできなければ、サービス停止がロックインインシデントとなる。Delos Cloud の DVC との整合性やパートナーエコシステムはそのリスクを低減しうるが、証明には、標準規格の文言だけでなく、テスト済みの出口が必要である。
これらの経路のいずれも、Delos Cloud を却下する理由にはならない。それらは、あらゆる本格的なクラウドプラットフォームが退屈なものにしなければならない経路である。退屈とは、文書化され、テストされ、リハーサルされ、測定され、契約上所有されていることを意味する。
ホスティングの経済性が、どの程度のレジリエンスを予備として保持できるかを決定する
2025年2月の価格声明は、購買提案と同時に経済的問題を明らかにするため有用である。Delos Cloud は、ソブリン Microsoft サービスを、適格な公共顧客向けに現行の Microsoft ドイツ定価の15%増しで価格設定すると述べている。これは、しばしば戦略的な言葉でのみ説明される製品カテゴリーとしては、比較的明確な数字である。これにより顧客は厳しい質問を投げかけることができる。すなわち、そのマージンは何をカバーしなければならないのか？
答えは、ソフトウェアライセンスよりも広範である。その追加料金は、ドイツのデータセンターインフラ、ドイツの運用センターの人員、セキュリティクリアランスを受けた要員、コンプライアンス作業、個別の証明書手配、パートナー調整、顧客オンボーディング、インシデント対応、サポートカバレッジ、そして成長や障害を吸収するための十分な未使用キャパシティを支えなければならない。これらのコストの一部は、最初の大口顧客が到来する前に固定されている。一部は使用量に応じて変動する。一部は、普段はアイドル状態かもしれない予備ホスト、予備ストレージ、代替ネットワークパス、上級エンジニアが可用でなければならない停電時にのみ可視化される。
ここで、設置容量と使用可能容量が分離する。プラットフォームはドイツのデータホールにハードウェアを設置しているかもしれないが、予備、メンテナンス余裕、災害復旧割り当て、管理プレーンのニーズ、バックアップ領域、成長バッファなどを差し引くと、販売可能部分はより少なくなる。プラットフォームが設置上限に近いところで販売すると、メンテナンスはよりリスクが高くなる。大きな予備を維持するならば、経済的にはそれらを賄うのに十分な顧客需要が必要となる。顧客はクラウド料金を見る。オペレーターは、セキュリティとローカリティの制約の下で、在庫問題を管理する。
公共部門の調達は、この課題を増幅させ得る。顧客は、フレームワーク契約、パイロット承認、予算サイクルの後に波状に到来するかもしれない。立ち上がりが遅ければ、高価なインフラが十分に活用されないままになる可能性がある。急激な立ち上がりは、サービステーム、クォータ計画、パートナーキャパシティにストレスを与える可能性がある。一部の顧客は、セキュリティチェックを完了する間、保守的な制限を必要とするかもしれないし、他の顧客はパイロット成功後に大規模な移行を望むかもしれない。Delos Cloud のパートナーエコシステムはその作業を吸収するのに役立つが、それはパートナーの準備状況、Delos のクォータ、顧客ガバナンスが同時に揃った場合に限られる。
バイヤーにとって、経済的なデューデリジェンスは実践的である。どのサービスが一般提供中で、どれが容量制限があり、どれが予約を必要とし、どれがリージョンやテナントクォータを持ち、どれがサービスクラスによってサポート条件が変わるのかを尋ねること。売り切れゾーン、希少なストレージ層、大規模な Office 移行、突然のバックアップ拡張、別環境からの緊急移行を Delos がどのように処理するかを尋ねること。ソブリンクラウドが良い価値となり得るのは、その価格が単にローカリティと法的管理だけでなく、通常のインフラストレスを乗り切るのに十分な予備を購入する場合のみである。
システム障害時に影響を受けるのは誰か
直接の顧客は、ドイツの公共機関とその IT プロバイダーである。実際のユーザーは、公務員、劇場スタッフ、財務チーム、職業安定所職員、地方自治体管理者、ケースワーカー、セキュリティチーム、公共デジタルサービスに依存する市民などである。影響を受ける具体的な人口は、どのサービスが障害を起こすかによる。Office コラボレーションの停止はスタッフのコミュニケーションに影響を与え得る。仮想ネットワークの停止はアプリケーションを隔離し得る。データベースやストレージのインシデントはケース処理を停止させ得る。ID インシデントは、一度に多数のサービスへのアクセスをブロックし得る。
責任の連鎖は層状になっている。リリースによれば、Delos Cloud は公開プラットフォームオペレーターであり、インフラ所有者である。Microsoft がテクノロジーベースを供給する。Arvato Systems がドイツでの運用を支援する。サービスパートナーは、顧客環境の設計、実装、移行を行うかもしれない。ビルドパートナーは、プラットフォーム上でアプリケーションロジックを実行するかもしれない。公共部門 IT プロバイダーは、最終サービスの契約、統合、サポートを行うかもしれない。利用できないサービスを経験した市民はそれらの層を見ることはないが、インシデント対応はそれらを通過するだろう。
これが、この記事のタイトルが重要である理由である。Delos Cloud はホステッドキャパシティを販売している。ホステッドキャパシティは、法的なラッパーがソブリンであり、ソフトウェアベースが馴染み深い場合でも、ラック、トランジット、修理ウィンドウに依存する。故障したストレージシェルフは管轄によって解決されない。キャリアの切断は政策声明によって解決されない。移行のボトルネックは価格表によって解決されない。主権は管理の主張であり、信頼性は運用の実績である。
Delos Cloud にとっての最も強力な公開事例は、それが契約から施設、パイロット、パートナー、ルートへと段階的に前進してきたことである。最も強力な公開注意事項は、最終的な本番証拠は必然的に公開発表よりも具体的でなければならないということである。データホールは最新の認証を必要とする。トランジット設計は多様性の証明を必要とする。修理連鎖は権限の証明を必要とする。顧客の出口パスはリハーサルを必要とする。それらがバイヤーに利用可能になれば、Delos Cloud は戦略的な約束としてではなく、本番プラットフォームとして評価され得る。
残された疑問を解決するもの
Delos Cloud に求められる証拠は、機密性の高いフロアプランや顧客名の要求ではない。それは、重要なホステッドキャパシティのための通常の保証パッケージである。
第一に、適切な秘密保持の下で、データセンターの運用境界を公開または提供すること。施設運営者、ドイツ国内のロケーションリージョン、データホールの範囲、ユーティリティおよび発電機のクラス、冷却のレジリエンス、物理的セキュリティ対策、火災および水害の保護、現在の認証または証明の範囲などである。目的は正確なラック列を明らかにすることではなく、どのシステム境界が評価されたかを示すことである。
第二に、サービスごとのキャパシティ証拠を提供すること。顧客は、現在技術的に利用可能なもの、パイロット中のもの、計画中のもの、Microsoft のリリースケイデンスに依存するもの、そして移行の波に対して十分な予備容量を持つものを知る必要がある。Delos のロードマップとポートフォリオは有用だが、本番ワークロードには、現在の可用性、クォータ、制限、メンテナンス状態、サポートコミットメントが必要である。
第三に、適切なレベルでネットワーク設計を開示すること。公開 BGP はすでに AS198678 と AS212185 を示している。しかし顧客はさらに、アップストリームの多様性、物理的な引き込み口の多様性、プライベート公共部門接続、ルーティングセキュリティ、DDoS 対応、経路フェイルオーバーテスト、メンテナンス手順を必要としている。PeeringDB の不在はそれ自体が欠陥ではないが、欠けている公開相互接続ビューは、顧客に対する直接の証拠によって置き換えられるべきである。
第四に、修理を証明すること。つまり、電力切替テスト、冷却フェイルオーバー、キャリアフェイルオーバー、セキュリティインシデント対応、バックアップリストア、ID 復旧、ストレージリカバリ、パッチのロールバック、顧客コミュニケーションに関する最近の証拠である。メンテナンスウィンドウは、作業がいつ行われるかだけでなく、作業中にどのような冗長性が維持されるかを示すべきである。
第五に、ポータビリティを証明すること。顧客は、テナントデータ、仮想マシン、データベース、ログ、鍵、バックアップ、アプリケーション依存関係について、テスト済みのパスを必要としている。DVC の文脈は相互運用性を戦略的目標としているが、Delos Cloud は依然として、特定の顧客がどのように参入し、拡張し、一時停止し、復旧し、または退出できるかを示さなければならない。
それらの証拠があれば、Delos Cloud の評価は「高度だが、物理的および運用レイヤーでの証明が依然として必要」というものよりも強固になり得る。それらがなければ、責任ある結論は控えめなものとなる。Delos Cloud GmbH は、公開された運用マイルストーン、顧客パイロット、パートナースケール、明確な主権設計、そして稼働中のネットワークリソースを有している。検証されるべきは、企業の存在ではない。検証されるべきは、クラウドサービスの通常の機構が故障した際に、その名前で販売されるキャパシティの信頼性である。