公開ではなく共有：テストクラウドの再定義

デバイスクラウドの進化：パブリックからプライベート、そして共有へ

管理機能を提供する責任を負うプロダクトマネージャーとして Digital.ai テストプラットフォームにおいて、私はインフラストラクチャを「可用性と制御性のバランス」という特定の視点から捉えています。私のペルソナであるクラウド管理者は、まさにゲートキーパーです。管理者はリソースを割り当て、ユーザーの権限を管理し、そして何よりも、テストチームが必要なときにリソースが利用可能であることを保証します。

長年にわたり、私たちの業界は大きく変化しました。物理ハードウェアの完全な制御から、パブリッククラウドの圧倒的な柔軟性へと移行しました。しかし、どちらの極端な方法も真の問題を解決していませんでした。今日、私たちは異なる道を切り開き、業界が長きにわたって受け入れてきた誤った二分法に挑戦します。

未来は「ロックダウン」か「すべての人に開かれた状態」かの選択ではありません。第三の状態が問われます。 共有インスタンス

私たちがどのようにしてここに至ったのか、そしてなぜこの区別がほとんどのベンダーが認めたい以上に重要なのかを説明しましょう。

フェーズ1：「ハードウェアを囲い込む」時代（社内およびオンプレミス）

私たちは皆、従来のモデルを覚えています。社内デバイスラボ。机の上をUSBケーブルが這いずり回っていた。半年ごとに交換しなければならないモバイルデバイスの膨らんだバッテリー。午後丸々かかる手動OSアップデート。他の全てが廃棄されたにもかかわらず、なぜかまだ動いていたiPhone 6。

実際に歩いてデバイスを持ち上げ、問題の原因を突き止めることができるという、実体のある操作には満足感がありました。しかし、操作の負担は計り知れないものでした。

セキュリティ意識の高いお客様、特に銀行や防衛業界のお客様向けに、オンプレミスとエアギャップのソリューションを正式に提供できるようになりました。これらの環境ではインフラストラクチャが完全に分離されているため、データは常に完全に管理下にあります。

デバイスはパブリックインターネットに一切接続しません。テストデータは建物外に持ち出されません。

なぜこれが出現したのか

金融データを扱う銀行アプリ。患者記録を管理するヘルスケアアプリ。機密情報を扱う政府アプリケーション。これらのアプリは、数時間前に他社のテストが同じデバイスに触れていたかもしれないインフラでは動作しない。

業界の答えはシンプルでした。「これらのデバイスはあなただけのものであり、あなたの環境に隔離されています。他の誰も触れることはありません。」

これは真のニーズを解決しました

• 規制対象または機密情報を扱うアプリケーションのデバイスとデータを完全に分離
• 社内のセキュリティ、ネットワーク、コンプライアンス要件に合わせたカスタム インフラストラクチャ構成
• 共有パブリックリソースに依存しない、データの保存場所と主権の保証
• パブリックインターネットにまったく接続できない環境向けのエアギャップ展開

これが引き起こした問題

しかし、これらの環境を管理する中で私が気づいたことは、セキュリティの問題は解決しましたが、新たな問題、つまり経済性が生じたということです。

• 総コストが高い組織はインフラストラクチャの維持に多大な時間、リソース、費用を費やしていました。
• 新しいデバイスへのアクセスが遅い: 顧客がiPhone 15の発売後3ヶ月もテストを待つのを見てきました。購入には経営陣の承認が必要で、調達部門は発注し、ITスタッフは設定を行い、ラボに追加しなければなりませんでした。その間、ユーザーは既に最新のiPhoneにアプリをダウンロードしていました。

オンプレミスでは、企業に必要なセキュリティが提供されましたが、デバイスのカバレッジに合わせて拡張できないコストがかかり、市場の細分化に対応できませんでした。

しかし、真に機密性の高いワークロードにおいては、この考え方は依然として有効です。エアギャップ型やオンプレミス型のソリューションは、機密データや法的に制限のあるシナリオには必要不可欠であり、今後もなくなることはありません。しかし、あらゆるテストニーズに対するデフォルトの解決策となるべきではありません。

フェーズ2: SaaSフォーク（パブリッククラウド vs. 専用クラウド）

市場がSaaSへと移行するにつれ、選択肢は2つに分かれました。どちらも、セキュリティ、カバレッジ、コストのバランスを取ろうとする現代のエンタープライズクラウド管理者のニーズに完全に応えるものではありません。

オプション1: パブリッククラウド

パブリック デバイス クラウドは、経済的に不可能になりつつあった問題、つまり開発者がユーザーが所有するすべてのデバイスを購入する余裕がないという問題に対する最初のソリューションとして登場しました。

デバイスは、プラットフォームのすべての顧客間で共有され、制限された制御で先着順に動的に割り当てられます。

なぜこれが出現したのか

2010年代初頭、モバイルの断片化は爆発的に進みました。Androidは四半期ごとに数十機種の新デバイスを発売し、iOSは毎年新モデルを追加しました。大企業を除き、物理デバイス上でアプリを手動でテストすることは経済的に不可能になりました。

パブリック クラウドは、ハードウェアを購入せずに何百ものデバイスに即座にアクセスできるという画期的なソリューションを提供しました。

従量課金制。設定は不要。クリックしてテストするだけ。

スタートアップ企業や急速に発展する開発チームにとって、これは変革をもたらすものでした。

これは真のニーズを解決しました

• 物理的なデバイスラボを購入して維持する必要がなくなりました
• セットアップやインフラストラクチャの計画なしで、オンデマンドの迅速な検証が可能
• 予算が限られていても、幅広いデバイス カバレッジを経済的に利用できるようにしました

現れた限界

しかし、企業がこれらのプラットフォームを採用するにつれて、顧客との会話の中で繰り返し耳にした次のような問題が表面化しました。

• 制限付き管理: 「当社のアプリケーションは、社内環境に接続するために特定のVPNとネットワーク構成を必要とします。パブリッククラウドデバイスは、これをサポートしていない標準化されたネットワーク設定に依存しています。」
• 可用性の問題「Appleが新型iPhoneをリリースすると、需要が一気に急増します。重要なテスト期間中は、行列に並んで待つことになります。」
• コンプライアンスギャップ: 「当社のセキュリティチームがアーキテクチャを審査した結果、却下しました。マルチテナントのパブリックインフラストラクチャは、機密性の高い金融データを扱うアプリケーションには適していません。」

パブリック クラウドはモバイル テストを民主化しましたが、企業のセキュリティと制御の要件に合わせて構築されたものではありません。

オプション2: 専用クラウド

セキュリティギャップを解決するため、業界では専用（プライベート）クラウドサービスが標準化されました。デバイスが特定の顧客専用に予約されるシングルテナント環境です。

単一の顧客専用に予約されたデバイス。ラボ インフラストラクチャを管理する必要なく、完全な制御を提供します。

これは真のニーズを解決しました

• 組織専用のプライベートなシングルテナント クラウド環境へのアクセス。
• 完全な分離を通じてセキュリティと規制の要件を満たします。
• デバイスと構成を完全に制御して、テスト シナリオを最適化します。
• ラボのメンテナンス、アップグレード、IT 管理に関連する運用オーバーヘッドを削減します。
• これにより、企業は必要なセキュリティ体制を確保できましたが、オンプレミス ソリューションの経済的な問題の一部が引き継がれました。

現れた限界

• 専用デバイスのコストが継続的に発生するため、デバイスの多様性が制限され、テストの範囲が不完全になります。
• 特にリリース前のテストやデバイス固有のデバッグなどのピーク期間中にデバイス割り当てを制限すると、テストの柔軟性が低下し、リリースの遅延につながる可能性があります。

断絶：顧客が本当に必要としていたもの

その時までに、私たちには2つの極端な選択肢がありました。

• 公共: 手頃な価格でアクセスしやすく、多様なデバイスをカバーしますが、セキュリティ上の懸念があり、制御が制限されます。
• 専門性: 安全で、制御されており、準拠していますが、高価でデバイスの種類が限られています。

しかし、私が顧客と面談し、実際のテストワークフローについて尋ねたところ、彼らはどちらの極端にも当てはまらないニーズを述べました。

「当社のCI/CDパイプラインは、毎時50台のデバイスで機能テストを実行しています。これらのテストは、VPN構成のプライベートネットワーク上で実行し、迅速に実行し、テストスイート間でデバイス設定を再利用する必要があります。パブリッククラウドではこれがサポートされておらず、専用デバイスは拡張するにはコストが高すぎます。」

「実際の顧客データを用いた本番環境テストには専用デバイスを使用しています。しかし開発段階になると、チームは幅広いデバイスでバグ修正を迅速に検証するだけで済みます。専用のリソースは必要ありません。必要なのはカバレッジです。」

パターンは明らかでした。 顧客はパブリックと専用の間の何かを求めていた.

彼らに必要なもの:

• デバイスへのオンデマンドアクセスによる共有インフラストラクチャの経済性
• パブリッククラウドに匹敵する幅広いデバイスとOSのカバレッジ
• デバイスの独占所有なしでエンタープライズ グレードのセキュリティと分離を実現
• VPNおよびサイト間構成を含む完全なネットワーク制御
• 実行間のセットアップやティアダウンを中断することなく、大規模なテスト スイートを確実に実行します。

業界は問題を二者択一として捉えていました。しかし、その捉え方は間違っていました。だからこそ、私たちは何か違うものを作り始めたのです。

フェーズ3：プライベートクラウドでの共有デバイス - 第三の道

これはどこですか？ Digital.ai テスト ここ数年、私たちはイノベーションに注力してきました。それは、単に他社と違うことをしようとしているからではなく、お客様の真のニーズに耳を傾け、真のニーズを解決しようとしてきたからです。

これが意味すること

先着順で動的に割り当てられるデバイスですが、パブリックデバイスに比べて制御性と柔軟性に優れています。大規模なテストスイートの実行、特定の設定（専用デバイスと同じVPN設定の使用など）が必要な環境、そして業務を中断せずに使用する場合に適しています。

プライベート環境のセキュリティ体制を維持しながら、共有利用の経済性も実現します。

なぜこれが出現したのか

このモデルを可能にし、また必要にしたのは、次の 3 つの力の融合です。

1. クラウドセキュリティ技術が成熟

プライベートクラウドアーキテクチャは、マルチテナントインフラストラクチャ内で真の分離を実現できるレベルまで進化しました。基盤となるクラウドインフラストラクチャは共有されているにもかかわらず、お客様のデバイス、ネットワーク構成、データは他のお客様とは完全に分離されています。

このレベルの分離は 2015 年には確実に達成できませんでした。しかし現在では、エンタープライズ クラウド アーキテクチャの標準となっています。

2. コスト圧力の高まり

チームは、より経済的な利用効率で、これまでと同じセキュリティ保証を求めていました。「セキュリティ上必要だから」という従来の答えでは、もはや満足のいくものではありませんでした。

3. 多様化する検査ニーズ

今日のチームには 1 種類のテストだけではなく、それぞれ異なる要件を持つ複数のワークロードがあります。

• 実際の顧客データを使用した高セキュリティの運用テスト（専用リソースが必要）
• 合成データを使用した大規模な CI/CD 機能テスト（排他性よりも規模とカバレッジを優先）
• 数百のデバイスと OS の組み合わせにわたる広範な互換性テスト (専用デバイスだけでは経済的に実行可能ではありません)
• バグ修正の日々の開発検証（高速アクセスと多様性が必要、可用性は保証されない）

パブリックか専用かを問わず、万能のインフラストラクチャは、今日のテストの実際のやり方を反映していません。

テスト戦略にとってこれが何を意味するか

現在、デバイスクラウドの選択肢を検討しているのであれば、「パブリック vs. プライベート」という枠組みを完全に否定すべきです。これは時代遅れであり、現代のテストの実際の仕組みを反映していません。

チームの実際の働き方に基づいて意思決定を行いましょう。その答えを見つけるために、以下の質問をよく考えてみてください。

1. 実際の作業負荷要件は何ですか?

• すべてのワークロードが機密データや規制対象データを処理しますか、それとも一部のみを処理しますか?
• デバイスの可用性を常に保証する必要がありますか、それとも定義されたウィンドウのみで保証する必要がありますか?
• テストは永続的なデバイス構成に依存していますか、それとも実行ごとにクリーンな環境が必要ですか?

ほとんどのチームは、実際にこれを計画すると、混合していることに気づきます。

2. セキュリティ要件ごとにワークロードを分離できますか?

• 高セキュリティ → 専用 SaaS またはオンプレミス（本番データ、規制対象または制限されたアプリケーション）
• 中程度のセキュリティ → プライベートインスタンス内の共有デバイス（機能テスト、CI/CD、互換性）
• 低セキュリティ → プライベートインスタンス内のパブリックまたは共有デバイス（初期開発、非機密検証）

重要なポイント: すべてのテスト ワークロードに最高のセキュリティ レベルが必要なわけではない。

結論：革命ではなく進化

パブリックからプライベート、そして共有へと進化を遂げたのは、ベンダーによるイノベーションそのものによるものではありません。業界が無視できない顧客ニーズと市場の力によって推進されたのです。

プライベート SaaS 環境内での共有デバイスが登場したのは、組織が無視できない経済性、テストに欠かせないデバイスの多様性、犠牲にできないセキュリティのバランスを取る必要があったためです。

At Digital.ai テストを通して、デバイスクラウドインフラストラクチャの未来は、単一の導入モデルを選択することではないことがわかりました。クラウド管理者が実際に管理できる、安全でコンプライアンスに準拠した環境内で、さまざまなワークロードを適切な階層に適応させるのに十分な柔軟性を備えたアーキテクチャを構築することが重要なのです。

本当の質問は決して「公的なものか私的なものか？」ではありませんでした。

本当の問題は、「データを公開したり予算を超過したりすることなく、テスト チームに必要なカバレッジを提供するにはどうすればよいでしょうか?」です。

それが「公開ではなく共有」の意味です。そして、それこそが私たちが築き上げている未来なのです。