AWS、Superblocksをプライベートクラウドへ導入し、AmazonとGoogleのAI競争を再構築

AWSは、Superblocksを顧客のプライベートなAWS環境内で完全に稼働させる支援を通じ、AmazonとGoogleのクラウド競争で異例の一手を打った。この取り決めにより、サードパーティーのバイブコーディングプラットフォームは、エンタープライズデータ、セキュリティ制御、調達システムにより近い位置へと移る。また、AIアプリケーションはその開発に寄与したモデル企業に常に結び付いていなければならない、という前提にも疑問を投げかける。

Superblocksは2026年8月3日、Superblocks 3.0と同時にAWSとの提携を発表した。同プラットフォームでは、従業員が自然言語による指示を通じて業務アプリケーションを作成できる。この手法は一般にバイブコーディングと呼ばれる。重要な変化は、そうしたアプリケーション、プロンプト、モデル、そして関連リソースをどこで動作させられるかにある。

新しいデプロイモデルの下で、Superblocksは自社プラットフォームが顧客のAWSアカウント内で稼働し、AI推論にAmazon Bedrockを利用するとしている。AWSがインフラストラクチャの境界とモデルゲートウェイを提供し、Superblocksがアプリケーション構築とガバナンスのレイヤーを担う。

この構造は、AIコーディングツールがひしめく市場を超えて影響を及ぼす。AWSにとっては、OpenAI、Anthropic、Replit、Lovableなどの製品で作成されたアプリケーションを取り込む手段となる。Google CloudもVertex AIを通じて同じ戦略的課題に直面している。アプリケーションをホストするクラウドは、それを生成したモデルより重要になり得るのか。

答えは、企業がSuperblocksをプロトタイプから本番環境へ移行するための管理された経路として受け入れるかどうかに左右される。また、そのプライベートデプロイに関する主張が、実際のセキュリティ、運用、コンプライアンスの審査に耐えられるかにも依存する。

Superblocks 3.0、AWSの境界内へバイブコーディングを移す

中心となる変化は、もう1つのコーディングアシスタントではない。AI生成アプリケーションを、エンタープライズITが管理するインフラストラクチャへ移すためのマネージドな経路である。

SuperblocksはCloud-Premアーキテクチャを、顧客のAWSアカウント内に設ける専用のシングルテナントデプロイメントとして説明している。シングルテナントデプロイメントでは、他組織とアプリケーション環境を共有するのではなく、1社の顧客に隔離されたインスタンスを提供する。

同社によれば、このデプロイメントにはコントロールプレーン、データプレーン、そしてClark AI推論が含まれる。コントロールプレーンはアプリケーションとポリシーを管理し、データプレーンはコードを実行してプライベートな業務システムと接続する。

AIリクエストは、顧客が承認したモデルとリージョンを用いてAmazon Bedrockを経由する。アプリケーションは、顧客のプライベートデータの近くに配置されたSuperblocksのデータプレーンへ接続する。同社は、地域ごとの分離を保ちながらデータ移動を抑えられるとしている。

Cloud-Prem architectureは、既存のAWSのID管理、ネットワーク、暗号化、監査コントロールも利用する。従業員は組織のIDプロバイダーを通じて認証され、管理者は既存のアクセスポリシーを適用する。

これは、ホスト型のアプリケーションビルダーをエンタープライズデータベースへ単純に接続する方法とは異なる。Superblocksによると、完全なアプリケーション構築環境が顧客のクラウド境界内に置かれる。

従業員がアプリケーションにデータ保存を依頼した場合、Superblocksによれば、同プラットフォームはその境界内でAmazon AuroraまたはAmazon S3のリソースをプロビジョニングできる。また、アプリケーションを開発から本番環境へ移行する際には、データベースマイグレーションも実行できる。

こうした操作が重要なのは、生成コードが稼働する業務アプリケーションを構成する一要素にすぎないためだ。本番ソフトウェアには、データベース、ID、権限、ネットワーク経路、デプロイ段階、ログ、そして責任を負う所有者も必要となる。

Superblocksは、業務部門の従業員が無制限のクラウドアクセスを与えられることなく利用できる経路として、これらの要素をパッケージ化しようとしている。セキュリティチームとプラットフォームチームは、SuperblocksとAWSコンソールを通じて監督を維持する。

8月の発表では、ChatGPT、Claude、Replit、Lovable、そして生のコードで作成されたプロトタイプを取り込むインポート機能も説明された。インポートされたアプリケーションはSuperblocks環境に入り、チームはそこで承認済みのデータやデプロイプロセスと接続できる。

これにより、この製品はアイデアが生まれる場所であることへの依存を弱められる。代わりにSuperblocksは、実験的なアプリケーションが実運用へ移行する際の管理された到着先となり得る。

同社のSuperblocks 3.0 announcementは、これを最高情報責任者および最高情報セキュリティ責任者にとっての中間的な道筋として位置付けている。従業員が構築したアプリケーションを禁止したり、通常のガバナンスの外に放置したりする必要はないという。

この位置付けはSuperblocksによるものであり、独立したセキュリティ評価によるものではない。それでも、根底にある問題は理解しやすい。生成AIコーディングツールは、多くの企業が棚卸し、レビュー、サポートできる速度を上回って、従業員によるソフトウェア作成を可能にする。

AWSデプロイメントは、こうした企業に別の選択肢を与える。既存のワークロードをすでに統制している技術的境界の中へ、従業員の実験的取り組みを取り込もうとできる。

AmazonとGoogleの競争がモデルレイヤーの上へ移行する理由

AmazonとGoogleは、他社が選好されるAIモデルを提供する場合でも、アプリケーションの下で永続的に機能する運用レイヤーになることをめぐって、ますます競争している。

初期の生成AI競争はモデル品質を中心としていた。企業はベンチマーク、コンテキスト上限、コーディング性能、応答速度を比較していた。これらの指標は依然として重要だが、頻繁に変化する。

エンタープライズアプリケーションは通常、当初のモデル優位性より長く存続する。データ接続、承認ワークフロー、IDルール、運用履歴は、モデルエンドポイントよりも置き換えが難しくなる。

顧客がBedrockをそれらのアプリケーションの下にある安定したゲートウェイとして扱う場合、AWSは利益を得る。Bedrockは、Amazonおよび外部プロバイダーのモデルを、マネージドなインターフェースとAWSのガバナンスコントロールを通じて提供する。

AWSは、model choiceツールによって、顧客はアプリケーション全体を書き換えることなくモデルを評価・置換できるとしている。この約束がすべての移行問題を解消するわけではない。モデルは依然として、プロンプト、ツール利用、出力形式、挙動、リージョンでの可用性が異なる。

それでも方向性は明確だ。AWSは、モデル選定を、各アプリケーションと1社のモデルベンダーとの恒久的な関係ではなく、AWS内で管理されるインフラストラクチャ上の意思決定にしたいと考えている。

Googleも似た立場を採っている。Vertex AI Model Gardenは、Googleのモデル、オープンモデル、選定されたサードパーティー提供物を1つのプラットフォーム内にまとめている。

Googleによれば、Model Gardenは、モデルの発見、テスト、カスタマイズ、デプロイに共通のパターンを提供する。Vertex AIはモデルアクセスを評価、提供、組織ポリシーとも接続する。

したがって、AmazonとGoogleの競争はNova対Geminiにとどまらない。両クラウドは、1つのクラウドを制御点として維持しながら複数のモデルを利用できるアプリケーションシステムを、顧客に構築してもらいたいと考えている。

Superblocksは、AWSにこの競争へ参入するための流通経路を与える。このスタートアップは従業員が理解できるアプリケーションレイヤーを提供し、AWSはエンタープライズ技術チームにとって馴染みのあるインフラストラクチャを提供する。

この役割分担は両社を支援し得る。Superblocksは、すでに機密性の高いワークロードをAWSに託している顧客へのアクセスを得る。AWSは、ストレージ、データベース、ログ、ネットワーク、セキュリティサービス、モデル推論を消費するアプリケーションを得る。

モデル提供企業が必ずしも排除されるわけではない。AWS内で稼働するアプリケーションは、Bedrockを通じて利用できるサードパーティーのモデルを依然として使用できる。ただし、商業面と運用面の中心はホスティングクラウドへ移る。

GoogleもVertex AIと独自のプライベートデプロイオプションで同じ主張をできる。同社の課題は、Geminiの性能が優れていると企業を説得することだけではない。どこで生成されたアプリケーションであっても、Google Cloudを優先される配置先にしなければならない。

MicrosoftもAzure、GitHub、モデルカタログを通じて同等の課題に直面している。しかし、AmazonとGoogleの対立は、両社が大規模なクラウドおよびAIポートフォリオを運営しているため、より広い戦略的パターンを最も明確に示している。

クラウドプロバイダーは、周辺のワークロードを所有するために、すべての勝者となるモデルを持つ必要はない。必要なのは、データベース、IDシステム、ネットワークポリシー、ログ、アプリケーションランタイム、そして調達関係である。

Superblocksとの提携が1社のスタートアップを超える意味を持つのはこのためだ。モデル提供企業間でアプリケーション環境の可搬性を高める一方、基盤となるクラウドとの関係をより価値あるものにする。

AWS、モデルの柔軟性をアプリケーションの引力へ変える

アプリケーションを個別のモデルから切り離すことで、ある形の依存を減らせる一方、他のすべてを調整するクラウドへの依存は強まる可能性がある。

SuperblocksはAIエージェントをClarkと呼んでいる。AWSデプロイメントでは、Clarkは組織の管理者が選択したモデルを使い、Bedrockを経由して推論リクエストを送信できる。

同社は、複雑なアプリケーションリクエストを小さなタスクに分割するSmart Routerについても説明している。難しい計画作業をあるモデルに、定型的なコーディング作業を別のモデルに振り分けられる。

Superblocksは、このルーティングによって最終的なアプリケーション品質を下げることなく、推論コストを最大30％削減できると主張している。この数値は同社の推計であり、多様なエンタープライズワークロードで独立して検証されたものではない。

より重要な考え方は、タスク単位でのモデルルーティングだ。アプリケーションビルダーは、計画、コード生成、テスト、修正のすべての段階を1つのモデルに任せる必要がなくなる。

このアプローチでは、モデルを交換可能なコンピューティングリソースとして扱う。アプリケーションレイヤーが各タスクに適したリソースを決定し、クラウドがアクセス、ID、容量、請求を処理する。

ただし、モデルは真に互換的ではない。あるモデルはツールスキーマに確実に従う一方、別のモデルはより優れたインターフェースコードを生成するかもしれない。さらに別のモデルは長い文書を適切に扱えても、精密な構造化出力には苦戦する可能性がある。

ルーティングシステムは、こうした違いを継続的に評価しなければならない。また、モデルが利用不能になった場合、挙動が変わった場合、必要なAWSリージョンでサポートされていない場合のフォールバックルールも必要となる。

Superblocksは、その複雑さを吸収するレイヤーとして自社を位置付けている。顧客は、プロンプトごとにモデルを選ぶのではなく、アプリケーション構築システムと対話する。

AWSにとっての利点は、ルーティングされた各リクエストをBedrock内に留められることだ。選択されたモデルが外部開発者によるものであっても、AWSはアクセス制御、推論の提供、運用監視に関与し続ける。

これにより、アプリケーションの引力が生まれる。組織がSuperblocksをAWSのID、プライベートデータベース、パッケージレジストリ、ログ、デプロイプロセスと接続すると、システム全体の移行は困難になる。

モデルは、周辺のコントロールより容易に変更できる。これが、この取引の中心にある切り離しである。

これはベンダーロックインの終わりではない。ロックインが蓄積する場所の移行である。

企業はAnthropic、OpenAI、あるいは別のモデル開発企業への全面的な依存を避けられるかもしれない。それでも、Bedrock APIs、AWSインフラストラクチャ、Superblocksのアプリケーション定義に深く依存する可能性はある。

Superblocksは自社のアプローチがベンダーロックインを排除するとしているが、この主張は慎重に扱うべきだ。データを顧客所有のAWSアカウント内に残すことは制御性を改善するものの、運用上の可搬性にはデータ所有権以上のものが必要となる。

チームは、アイデンティティルール、インフラ定義、アプリケーションロジック、デプロイメントパイプライン、監査履歴、モデルルーティングの挙動を別の場所で再構築する必要がある。その作業の難しさが、実際のポータビリティの水準を決める。

Googleは独自のアプリケーション重力圏を構築している。Vertex AIは、Model GardenをGoogle Cloudのネットワーク、データサービス、評価ツール、ポリシー制御と結び付けている。

したがってAmazon Googleの戦いは、最適な抽象化をめぐる競争になりつつある。各プロバイダーは、モデルを交換可能なものと見せる一方、自社のクラウドコントロールプレーンを不可欠なものと顧客に認識させようとしている。

Superblocksは、技術職ではない従業員もアプリケーションパイプラインに取り込むため、この競争におけるAWSを強化する。作成者が増えればアプリケーションも増え、各アプリケーションは追加のAWSサービスを利用できる。

その拡大に価値があるのは、企業がそれを統制できる場合に限られる。そうでなければ、開発の高速化はサポートされない社内ソフトウェアの集積を拡大するだけだ。

ガバナンスが製品だが、なお証明が必要

Superblocksが売り込んでいるのは無制限のコード生成ではなく、統制された本番アクセスであり、その約束にははるかに高い水準の証拠が求められる。

同社によると、すべてのコード変更は本番環境に入る前に、専門のセキュリティエージェントと決定論的スキャナーを通過する。決定論的スキャナーは固定ルールを適用し、ハードコードされた認証情報や安全でないデータフローなど、既知の弱点を検出する。

報道によれば、セキュリティエージェントは認証、認可、API、ビジネスロジックを含む、より広範なアプリケーションコンテキストを検査する。管理者は、組織固有の要件に対応するポリシーエージェントも定義できる。

Superblocksによると、本番環境向けの制御にはプライベートパッケージレジストリとソフトウェア部品表が含まれる。ソフトウェア部品表は、アプリケーションに含まれるコンポーネントと依存関係を記録する。

同プラットフォームは、公開後の新たな脆弱性についても、デプロイ済みの依存関係を継続的にスキャンするとされる。関連する脆弱性が見つかった場合、アプリケーション所有者に警告できる。

これらは有用な制御だが、その存在だけで有効性が証明されるわけではない。セキュリティエージェントは微妙な認可上の問題を見逃したり、安全でない生成ロジックを承認したり、管理者が無視するほど多くの誤検知アラートを出したりする可能性がある。

生成されたアプリケーションは、所有権に関する問題ももたらす。元の従業員が役割を変えた場合、APIが変更された場合、あるいはモデル生成ワークフローが誤った事業判断を生んだ場合に、誰がアプリケーションを保守するかを決めなければならない。

クラウド隔離ではこれらの問題には答えられない。コードとプロンプトをAWSアカウント内に保持することで特定の露出経路は減らせるが、生成されたロジックが正しいことにはならない。

既存のIAMポリシーにも過剰な権限が含まれている可能性がある。完全にプライベートクラウド内で動作するアプリケーションであっても、機密データを誤った従業員に公開したり、重要な記録を変更したりする恐れがある。

プロンプトとデータは顧客の安全なAWS環境内に残るというSuperblocksの主張にも、同じ慎重さが必要だ。購入者は、どのメタデータ、診断情報、サポート記録、管理イベントがその環境外へ出るのかを検証しなければならない。

同社のアーキテクチャでは、リージョナルデータプレーンからの通信はアウトバウンド専用にできるとされる。それでも組織は、そのアウトバウンド経路、サポートの仕組み、暗号化の取り決め、Superblocksの管理権限を調査する必要がある。

Cloud-Premもマネージドサービスである。Superblocksがアップグレード、セキュリティパッチ、信頼性、サポートを担い、顧客はクラウドレベルのポリシーとデプロイ境界を管理する。

この分担は運用作業を減らせる可能性があるが、共有責任も生む。購入者は、各コンポーネントにどちらの当事者がアクセスできるのか、インシデント発生時に何が起きるのかを正確に把握する必要がある。

プライベートデプロイメントはアップグレードを複雑にする可能性もある。Superblocksは、ネットワーク制限、リージョン要件、承認プロセスが異なる多数の顧客環境をサポートしなければならない。

同社はアップグレードを計画・実行するとしている。エンタープライズ顧客は、それでも変更後にアプリケーションの挙動、モデルルーティング、ポリシー、統合が維持されるかをテストすべきだ。

もう一つの不確実性は導入だ。ビジネスユーザーは、レビューや昇格ステージを伴う承認済みプラットフォームよりも、消費者向けコーディングツールの即時的な自由を好むかもしれない。

Superblocksは既存のプロトタイプをインポートすることで、この問題への対処を試みている。これにより従業員は使い慣れたツールで始め、アプリケーションが本番データを必要とする段階で統制環境に入ることができる。

この橋渡しは戦略的に理にかなっているが、限界もある。インポートされたコードには、サポートされないパッケージ、不明確なライセンス、脆弱な前提、Superblocksにきれいに対応しない構造が持ち込まれる可能性がある。

セキュリティチームには、アプリケーションのインベントリが完全であり続けることを示す証拠も必要だ。従業員がインポートも開示もしないプロトタイプは、統制されたプラットフォームでは管理できない。

したがって、Superblocksの主張が最も強い形で成立するには、技術的なデプロイメントだけでなく行動変容が必要になる。従業員は承認済みの経路を受け入れ、ITはその経路を非公式な代替手段より速くしなければならない。

圧力はコーディングプラットフォームとエンタープライズITに及ぶ

当面の敗者は、アプリケーションを別の場所で作り直すことなく、迅速なプロトタイプから統制された本番環境へ移行できないプラットフォームだ。

消費者向けのコーディングツールは、動作するプロトタイプを作るために必要な労力を低下させた。これらは、多くの場合、迅速な視覚的フィードバックと簡単なデプロイを望む個人の作成者に最適化されている。

エンタープライズの本番環境には異なる要件がある。アプリケーションには、顧客記録、財務システム、社内API、規制対象データへの統制されたアクセスが必要だ。

また、監査ログ、環境分離、インシデント手順、明確な所有権も必要となる。視覚的に説得力のあるプロトタイプが、これらの条件を自動的に満たすわけではない。

Superblocksは、こうした段階間のギャップを狙っている。アイデア出しの段階で従業員がChatGPT、Claude、Replit、Lovableを使うことを阻止する必要はない。本番環境への移行を担う必要がある。

この位置付けは、他のバイブコーディングプラットフォームに対し、同等のガバナンスとプライベートデプロイメントの選択肢を追加する圧力となる。そうしなければ、最終的な運用段階を扱うプラットフォームへの供給元になるリスクがある。

この圧力は、既存の社内ツールベンダーにも及ぶ。これらの製品はすでに権限、データ接続、デプロイメントに対応しているが、AI生成によって、誰が構築できるか、アプリケーションがどれほど速く増えるかが変わる。

こうしたベンダーは、そもそもエンタープライズを引き付けた制御を弱めることなく、従来型ではない作成者を支援しなければならない。また、顧客が単一のAIサプライヤーへの依存を避けるなか、信頼できるモデルの柔軟性も必要になる。

クラウドプロバイダーも別の判断に直面している。自らアプリケーション生成環境を構築するか、マーケットプレイスや販売チャネルを通じて独立製品を流通させるかだ。

AWSは、Bedrockと開発者サービスを拡充し続けながら、Superblocksとの提携という道を選んでいる。このアプローチによりAWSは、すべてのインターフェースを自ら所有せずに、専門的なアプリケーション体験を支援できる。

GoogleはVertex AI、自社のアプリケーション開発製品、外部パートナーを通じて対抗できる。MicrosoftはAzure AIサービスをGitHubや自社のビジネスソフトウェア基盤と組み合わせられる。

より深い圧力はエンタープライズITにかかる。従業員は、これらのツールが承認済みカタログに掲載されているかどうかにかかわらず、すでにコーディングエージェントやブラウザベースのアプリケーションビルダーにアクセスできる。

すべてのツールを禁止すれば、開発を公式な監督のさらに外側へ押し出す可能性がある。あらゆる実験を承認すれば、セキュリティチームとプラットフォームチームが維持できないレビュー負荷が生まれる。

Superblocksは、その答えとして自動化されたポリシー適用を提案している。説明どおりにセキュリティエージェントとデプロイメント制御が機能すれば、ITは生成されたすべての行を手作業で検査する代わりに、ルールと例外をレビューできる。

この提案には実際の運用上の証拠が必要だ。チームは、本番環境に到達するアプリケーションの数、ポリシーが安全でない変更を阻止する頻度、例外解決にかかる時間を測定すべきである。

放棄されたアプリケーションも追跡すべきだ。作成の高速化は、重複したワークフローや、責任を負う保守担当者のいないツールを含むソフトウェアの乱雑化を生みかねない。

検索可能なエンジニアリングナレッジベースは、設計判断、運用手順書、アプリケーションのコンテキストをチームが保持する助けになる。技術的な制御に取って代わるものではないが、従業員が作成したソフトウェアをめぐる知識の喪失を減らすことはできる。

最も重要な指標は、生成されたアプリケーションの数ではない。安全で有用に保守され、置き換えたプロセスより低コストであり続けるアプリケーションの数だ。

Superblocksがその成果を示せれば、AWSはビジネス主導の開発を通じてクラウド消費を拡大する、再現可能な経路を得る。示せなければ、この提携は実証済みの運用モデルを伴わない、魅力的なデプロイメントの物語にとどまる。

Amazon Googleクラウド競争の次の展開

この提携がエンタープライズアプリケーション開発を変えるのか、それとも限定的なプライベートクラウドの選択肢にとどまるのかは、3つの兆候で分かる。

最初の兆候は本番導入だ。AWSとSuperblocksは、デモや孤立したパイロットの評価だけでなく、Cloud-Premアーキテクチャ上で意味のあるアプリケーションを運用する顧客を必要としている。

有用な証拠には、アプリケーション数、アクティブな作成者、本番利用、インシデント率、プロトタイプをサービス化するまでの所要時間が含まれる。顧客事例は、測定された成果とSuperblocksが提示した推計を区別すべきだ。

規制産業での導入は中心的な論点を強化する。こうした組織には、データ所在地、監査可能性、モデルアクセスの制御を求める最も明確な理由がある。

デプロイメントが遅ければ、この論点は弱まる。それは、Superblocksが支援したい従業員にとって、プライベートクラウドの導入とガバナンスが過度の摩擦を生むことを示唆するからだ。

2つ目の兆候は、直接的な競争対応である。Google、Microsoft、既存の社内ツールベンダー、その他のバイブコーディングプラットフォームには、現在、自らのプロトタイプから本番までの経路を強化する理由がある。

意味のある対応は、モデルの選択肢、顧客管理のインフラ、ポリシー適用、アプリケーションライフサイクル管理を組み合わせることになる。別のコードジェネレーターを追加するだけでは、同じ問題には対処できない。

Googleは、すでに幅広いモデルカタログとプライベートデプロイメント機能を提供しているため、特に重要だ。Googleがこれらの資産を同様に利用しやすいビジネスアプリケーション層と結び付ければ、Amazon Googleの競争は先鋭化する。

そのような動きは、モデルがクラウド管理下のアプリケーションシステム内のコンポーネントになりつつあるという考えを強化する。反応が鈍ければ、競合各社がSuperblocksをより狭い社内ツール製品と見なしていることを示すだろう。

3つ目の兆候は、モデル切り替えの成功を示す証拠だ。SuperblocksとAWSは、アプリケーションを一つのプロバイダーに結び付けずに、承認済みモデル間でタスクをルーティングできると主張している。

顧客は、実際のモデルアップグレードや置き換えの際にこの主張をテストすべきだ。出力品質、アプリケーション障害、レイテンシー、ポリシーの挙動、各変更に必要なエンジニアリング作業を測定する必要がある。

容易な切り替えはAWSの立場を強化する。それは、BedrockとSuperblocksが長寿命のアプリケーションを短いモデルサイクルから分離できることを示す。

頻繁な障害や大規模なプロンプト書き換えは、分離の論拠を弱める。それらは、共通のクラウドインターフェースの背後にあっても、モデル固有の挙動がアプリケーションロジックに埋め込まれたままであることを明らかにする。

購入者は、その結果として生じる依存関係マップも検討すべきだ。モデルの置き換えは容易になる一方、AWSやSuperblocksの置き換えは難しくなる可能性がある。

そのトレードオフが自動的に不利になるわけではない。企業は一貫したセキュリティ、サポート、調達を得る代わりに、インフラへの依存を受け入れることが多い。

ただし、この判断は明示的に行うべきだ。プライベートクラウドへの導入は、配置場所とアクセスに対する制御をもたらすが、プラットフォーム間のポータビリティを保証するものではない。

AWSとSuperblocksの提携が重要なのは、AIソフトウェアの持続的な価値を、モデルそのものより上位に位置付けているからだ。アプリケーション、そのデータ接続、そしてガバナンスは、最初にコードを生成したモデルがどれであれ、それより長く存続し得る。

AmazonとGoogleの競争は、まさにその方向へ進んでいる。クラウドプロバイダーは、モデルが説明責任を果たすビジネスシステムへと変わる環境を掌握したいと考えている。

開発者と企業の購買担当者にとって、次のステップは実践的だ。インポートしたアプリケーションを1つ、実際のセキュリティポリシーに照らしてテストし、その後でモデルを置き換える。その結果によって、このアーキテクチャが真に柔軟性を生み出すのか、それとも依存先を別のレイヤーへ移すだけなのかが明らかになる。