クラウドからの自立——AIが支援するのは開いた層だけ

結論——インフラも自立できる時代になった

第二部 第7章で、自由都市(Linux + Python + AI)に移住した個人がビルダーとして立つ構造を見た。設計編の本章が扱うのは、その足元 ── インフラをどこに置き、何を借り、何を預けないか ── である。

結論から言う。パブリッククラウドの価値提案の一部は、AIによって掘り崩されつつある。原因はクラウドの技術力の低下ではない。ベンダー固有の管理レイヤー(独自コンソール、独自API、独自ID基盤)が、AIの得意領域である「閉じていて仕様が安定している問題」の外側にあるためだ。

コンピュート・ストレージという標準化された部分は残る。ベンダー固有の管理・ID・運用レイヤーが、代替されやすい部分である。そしてこの非対称は、個人と小組織にとって一つの帰結を持つ ── インフラは、もう自立できる。かつて「専門家がいないからクラウドに任せる」だった判断の前提が、逆転したのだ。

AIによる底上げの非対称性——Linuxと、ベンダー固有コンソールの違い

AIは、公開知識が豊富で仕様が安定している技術ほど、開発者の実装レベルを底上げする。この原則は、第二部 第4章で見た「開いた蓄積」の運用版であり、第一部 第8章のOracle税の議論(PL/SQLとPostgreSQLの比較)と同じ構造で、インフラ運用の層にもそのまま当てはまる。

Linux(systemd、Caddy、PostgreSQL、Docker等)の運用は、何十年にもわたる公開情報が蓄積されており、コマンドや設定ファイルの文法もほぼ安定している。エラーメッセージやログの形式も標準化されているため、AIは原因を特定しやすい。

一方、クラウドベンダーの管理コンソールやCLIは、数ヶ月単位でメニュー構成やAPIバージョンが変わることが珍しくない。同じ「仮想マシンを立てる」という作業でも、コンソールのボタン配置やCLIオプションがバージョンごとに異なる。ベンダー固有の概念(Azureのリソースグループ、Entra IDのテナント等)は、汎用知識として蓄積されにくい。

何から自立するのか——ロックインの正体は管理レイヤー

クラウドベンダーのロックインは、Oracleのケースと同様、移行コストの高さに支えられてきた。ただしその内実は、コンピュート・ストレージという標準化された部分ではなく、ベンダー固有の管理・認証レイヤーに集中している。

例えばMicrosoft Azureの場合、仮想マシンやストレージそのものはLinux標準の技術で構成できるが、権限管理(RBAC)やリソース管理はEntra IDに紐づく。Entra IDは、Microsoft 365やCopilotとの深い統合を前提に設計された認証基盤であり、第一部 第12章で見た「内蔵しないと価値が出ない」という構造上の問題を抱えている。

同種の認証基盤の脆弱性は、2016年に技術者から社内で警告があったにもかかわらず対応が先送りされ、2020年のSolarWinds攻撃で実際に悪用され、2024年に米サイバーセキュリティ審査委員会(CSRB)がMicrosoftの企業文化を「セキュリティ投資を軽視している」と断定するに至った、という経緯が公表されている。

家に例えるなら、基礎(認証基盤の堅牢性)を固める前に、その上に何階建てもの構造物(Copilotの全製品統合)を積み上げた、ということだ。この認証基盤に、自分のインフラの鍵を預けるかどうか ── 自立の問いは、まずここにある。

何が残り、何を借りればいいか

コンピュート・ストレージという資源そのものは標準化されているように見えるが、その資源を取得・管理する方法(プロビジョニングAPI、管理コンソール)はベンダー固有である。AIが得意とするのは、後者ではなく、取得した後のLinux標準の技術(systemd、Docker、標準的なSQL等)を運用する部分だ。

したがって、「コンピュート資源の提供部分は残る」という見立てには修正が要る。資源そのものが標準化されていても、そこに至るまでのプロビジョニング層(仮想マシンの作成、ネットワーク設定、権限付与)がベンダー固有である限り、AIの支援は及びにくい。この層も、Entra IDのような認証レイヤーと同じ構造的弱点を抱えている。

小規模な運営における実際の選択

情報提供・コミュニティ向けアプリケーションのような小規模な運営では、この構造がより直接的に選択肢に反映される。負荷がVPS一台〜数台でまかなえる規模であれば、大規模クラウド特有の機能(オートスケール、マネージドID基盤)を前提にする理由がそもそも乏しい。

• 短期的・イベント時の負荷変動に対応する必要がある場合は、国内クラウド(さくらのクラウド等)で十分に対応できる
• 恒常的な負荷であれば、ローカル(自宅・事務所内のマシン)でも運用でき、外部のクラウド破綻リスクからも独立できる
• いずれの場合も、認証はOIDC等の標準プロトコルに基づく自己ホスト型のID基盤(PocketBase、Keycloak等)で完結させることができ、ベンダー固有のID基盤への依存を避けられる

これが「自立」の実装である。全部を自前にすることではない。鍵(認証)と管理を手元に置き、借りるものは標準の形で借りる ── 窓は借りても、金庫は自分の側に置く。組織のスイート全体でこれをやり切る手順は、別シリーズ「AIネイティブな仕事の作法 ソフトウェア開発編」の自立編が扱っている。

クラウドファーストは「遺産の付け替え」だった

なぜクラウド、とりわけAzureはここまで成長できたのか。ゼロから新しい市場を作ったのではない。既存の資産を土台にしたのだ。

• Windows Server、SQL Server、Active Directoryを使っていた既存の企業顧客が、そのままクラウド版(Azure VM、Azure SQL、Entra ID)に移行した
• 何十年もかけて築いた企業内IT担当者との関係、調達契約、ライセンス体系がそのまま使えた
• 既存のロックインを「オンプレミス課金」から「クラウド課金」に付け替えただけで、顧客の意思決定コストがほぼゼロだった

つまりクラウドファーストの実態は、新規事業ではなく既存資産の高収益な作り替えである。

対照実験もある。モバイルファーストは、遺産がなかったから負けた。Windows Phoneには企業向けの蓄積された遺産(アプリ資産、開発者コミュニティ、ユーザーの慣れ)が何もなく、Apple/Googleが既に持つネットワーク効果とゼロから戦う必要があった。遺産の付け替えができない領域では、Microsoftの本質的な強み(既存顧客のロックイン)が全く機能しなかった。

三社の性格の違い——借りるなら、何をどう借りるか

同じ「クラウド」でも、AWS・Google Cloud・Azureでは、この構造的リスクへの晒され方が異なる。

AWSは、外部の事業者・AI開発企業に広く使われる基盤としての性格が強い。2025年通年の売上は1,287億ドル(前年比+19%)と三社中最大で、Bedrockには複数のAIラボのモデルが載っている。既存のAWSエコシステム(IAM、VPC等)に深く入っている組織にとって、AI導入の抵抗が少ない。自社開発のAIチップ(Trainium)も外部提供を前提に育てている。顧客基盤が広く分散しているため、特定のロックイン構造への依存度は相対的に薄い。

Googleは、自社利用の比重が大きい。Google Cloud単体の売上(2025年通年で約590億ドル、年末時点の年間換算では700億ドル超)は成長しているが、Alphabet全体のAI・データセンター投資規模(2025年実績910億ドル、2026年計画は1,800億〜1,900億ドルへ倍増、2027年はさらに大幅増の見通し)と比べると、検索・YouTube・Gemini自体の内部利用が投資の相当部分を占めていると考えられる。外部クラウド事業として顧客に依存する比率は、AWSほど高くない。

Azureは、深い統合による企業ロックインへの依存度が三社の中で最も高い。売上は FY2025(2025年6月期)に初めて開示され、750億ドル超(前年比+34%)。Entra ID・Microsoft 365・Copilotとの統合を前面に押し出す戦略を取っており、独自の管理・ID基盤への依存を顧客に強いる度合いが強い。これが、AIによる「閉じていて仕様が安定した問題」の代替圧力に最も直接さらされる理由である。

自立の観点から言えば、借りてよいのは「標準的な資源を標準的な形で渡す」性格の部分であり、預けてはいけないのは「深い統合」を前提とする部分である。

まとめ——没落するのは閉じた層、自立するのは開いた層の上

クラウドという概念そのものが終わるのではない。標準化された技術(Linux、コンテナ、標準的なSQL、標準プロトコルに基づく認証)を、標準的な形で提供する部分は残り続ける。掘り崩されるのは、資源の提供方法そのものがベンダー固有であるために、AIの支援を受けにくい部分である。これは認証・管理レイヤーに限らず、コンピュート資源のプロビジョニング自体にも及ぶ。この囲い込みは、AIが「閉じていて仕様が安定した問題」を解決する速度に対して脆弱であり、Oracle DBのPL/SQLロックインと同じ構造的リスクを抱えている。