レッスン8：クラウド移行と次の選択——マルチクラウド・ハイブリッド・修了後

このレッスンで学ぶこと

クラウド移行の 7R を理解し、自社の業務システムに当てはめられる
ハイブリッドクラウド・マルチクラウドの理想と現実を整理できる
ベンダーロックインに関する建設的な議論ができる
2026 年 6 月時点の論点（AI エージェント実行環境、SBOM、PQC）を概観する
本コース修了後の学習方向を把握する

前のレッスンでは、クラウドのセキュリティ（責任共有モデル、IAM、KMS、ログ）を整理しました。最終回のこのレッスンでは、視点をふたたび広げて「クラウドへの移行」「複数クラウドの組み合わせ」「2026 年以降の論点」を扱います。同時に、本コース修了後にどの方向に学びを進めるかを案内します。本コースは「初級」として概念中心に整理してきましたが、最後に「現場でこの先何を考えるか」の道しるべをお渡しします。

クラウド移行の 7R

オンプレからクラウドへの移行戦略は、伝統的に「6R」と呼ばれてきました。AWS が 2016 年に提唱したフレームワークで、業界で広く使われています。近年は Relocate（再配置）を加えた「7R」が一般的になっています。

7R の一覧

略号	英語	意味
Retain	Retain	そのままオンプレで残す
Retire	Retire	廃止する
Rehost	Rehost（Lift and Shift）	そのまま仮想マシンに乗せ替える
Replatform	Replatform（Lift, Tinker, and Shift）	小さな修正を加えて乗せ替える
Repurchase	Repurchase	既存システムを廃止して SaaS に置き換える
Refactor	Refactor／Re-architect	クラウドネイティブに再設計する
Relocate	Relocate	VMware など特定の仕組みごと別のクラウドへ移す

各 R の使い分け

Retain（残す）：規制・要件で乗せられない、または当面コスト効果が薄いシステム
Retire（廃止）：使われていないシステム。移行前に廃止候補を見つけるのが重要
Rehost（リフト＆シフト）：そのまま仮想マシンに乗せる。スピード優先で移行コストが低い
Replatform（リフト・ティンカー＆シフト）：例：自社運用 DB をマネージド DB に置き換える
Repurchase（買い替え）：例：自社開発の人事システムを Workday に置き換える
Refactor（再設計）：マイクロサービス・コンテナ・サーバーレスで作り直す。最も高コスト・高効果
Relocate（再配置）：VMware Cloud on AWS のように、特定の仕組みごと別環境へ持って行く

どの R を選ぶか

ROI（投資対効果）が見えやすい順：Retire ＞ Repurchase ＞ Rehost ＞ Replatform ＞ Refactor
スピードが要る場合：Rehost で先に乗せて、徐々に Replatform / Refactor へ
完全なクラウドネイティブを目指す：Refactor が必要だが、コストとリスクが大きい

「すべて Refactor が理想」というのは、実務では非現実的です。組織の体力に応じて、業務システムごとに R を選び分けるのが現実的です。

💡 ポイント 「100 のシステムを 1 年で全部 Refactor したい」は、ほぼ確実に失敗します。実際の大規模移行プロジェクトは、3〜5 年かけて「Retire→Rehost→徐々に Replatform → 一部 Refactor」という流れで進めるのが普通です。

ハイブリッドクラウドとマルチクラウド

クラウドを語る上で、ハイブリッドとマルチの 2 つの言葉は混同されがちです。

定義の整理

ハイブリッドクラウド（hybrid cloud）：オンプレミス／プライベートクラウドと、パブリッククラウドを組み合わせる
マルチクラウド（multi-cloud）：複数のパブリッククラウド（AWS と Azure、Azure と Google Cloud など）を組み合わせる
ハイブリッド＋マルチクラウド：オンプレ＋複数パブリックを組み合わせる

採用される理由

規制対応：機密データはオンプレ、その他はクラウド
冗長性：単一クラウドの障害リスクを下げたい
業務領域別の最適化：データ分析は Google Cloud、エンタープライズは Azure、と使い分け
ベンダーロックイン回避：1 社に依存しすぎないようにする
M&A の結果：合併・買収で別のクラウドを使うシステムが入ってくる

理想と現実のギャップ

「マルチクラウドにすればリスク分散できる」と聞こえはよい一方で、現実の運用は思った以上に大変です。

認証基盤を 2 つ管理する必要がある
ネットワーク接続を冗長に持つコスト
各クラウドの異なる用語・サービス体系を習得した人材
監視・運用ツールを統一するコストと、独自ツールに合わせるコスト
各社のサポート契約を別々に維持
ベスト・オブ・ブリードを実現できる人材の少なさ

実例として、37signals（Basecamp や HEY を運営）は 2022 年に「Leaving the Cloud」を表明し、2023〜2024 年に多くのワークロードをクラウドからオンプレに戻しました。一方、Atlassian は AWS への集約を継続しています。「マルチクラウドが正解」「シングルクラウドが正解」と一律に語ることはできません。

⚠️ 注意 「マルチクラウドにすればロックインがなくなる」は、現実には不完全な命題です。各クラウドの独自サービスを使えば、結局その先で別のロックインが発生します。「ロックイン」と「運用効率」のトレードオフを意識する必要があります。

ベンダーロックインの建設的な議論

ベンダーロックイン（vendor lock-in）は、特定のクラウド事業者の独自サービスに深く依存して、移行が難しくなる状態を指します。クラウド業界で長く議論されてきたテーマです。

過度な恐れの問題

「ロックインが怖いから AWS の独自サービスは使わない」と決めると、クラウドの利点（マネージド DB、マネージド AI 、サーバーレス）の多くを使えなくなります。結果として、すべてを仮想マシン上に自前構築することになり、運用コストとセキュリティ負担が増えます。

過度な楽観の問題

「ロックインは気にしない」「Refactor で全部 AWS 専用サービスに乗せ替える」と判断すると、5 年後に事業環境が変わって他クラウドに移したくなったときに、莫大な再開発コストが発生します。

バランスの取り方

移行コストと得られる価値を、サービスごとに天秤にかける
抽象化層（abstraction layer）を入れる：特定クラウド固有の API を直接呼ばず、自社の薄いラッパーを通す
標準的なオープン技術（Kubernetes、PostgreSQL、Linux など）を中核に据える
「全部移せる状態」ではなく「重要なものだけは移せる状態」を保つ

「完全な移行可能性」を追うコストは大きすぎます。「中核業務はオープン技術で実装し、便利な周辺サービスはクラウド独自を使う」という妥協が、多くの組織で現実解になっています。

2026 年 6 月時点：AI エージェント実行環境としてのクラウド

2024〜2025 年にかけて、AI エージェント（自律的に判断して行動する AI システム）の業務利用が広がってきました。クラウドはその実行環境としての役割を強めています。

クラウドが AI エージェントに提供するもの

マネージド推論サービス（AWS Bedrock、Azure OpenAI Service、Google Vertex AI など）
ベクトルデータベース（pgvector、Pinecone のクラウド版など）
関数実行環境（サーバーレスでエージェントのアクション実行）
認証・認可（エージェントが扱える範囲を IAM で制御）
ログと監査（エージェントの行動を追跡）

設計上の論点

「エージェントが暴走したときに止められるか」（権限制限・ガードレール）
「コスト上限が設定できるか」（推論コスト・API 呼び出しコストの予算管理）
「監査ログが取れるか」（説明責任）
「機密情報を扱う際の責任分界」（責任共有モデルの新しい論点）

本コースは「クラウド入門」として概要にとどめますが、AI エージェント時代のクラウド設計は今後 5 年の中心テーマです。

📝 補足 AI エージェント自体の設計（観察・思考・行動・記憶・道具、ReAct、Function Calling、MCP など）は、別の専門書・コースを参照してください。本コースは「クラウドという土台」の側からの視点のみ扱います。

SBOM とサプライチェーン

2020 年代のセキュリティ論点として、サプライチェーン攻撃（supply chain attack）への対応が無視できなくなりました。

SolarWinds 事件（2020 年）

2020 年に発覚した SolarWinds 事件は、サプライチェーン攻撃の代表例です。SolarWinds 社のソフトウェアアップデートに攻撃者がマルウェアを仕込み、それを使った世界中の組織（米国政府機関も含む）に侵入しました。「信頼している取引先のソフトウェアが入り口になる」というパターンが、業界全体に警鐘を鳴らしました。

SBOM（Software Bill of Materials）

SBOM は、ソフトウェアの「部品表」のことです。自社で使うソフトウェアがどんな OSS（オープンソースソフトウェア）を含み、どのバージョンか、ライセンスは何か、を一覧化します。

米国大統領令 EO 14028（2021 年）が SBOM の整備を政府調達に求めた
業界標準フォーマット：CycloneDX、SPDX
脆弱性が見つかったとき、影響範囲をすぐ特定できる
取引先選定で SBOM 提出が求められるケースが増えている

クラウドサービスを使う組織も、SBOM を整備して取引先・規制当局に提示する必要が出てきました。

PQC（耐量子計算機暗号）

もう 1 つの 2026 年時点の論点が、PQC（Post-Quantum Cryptography：耐量子計算機暗号）です。

量子コンピュータの脅威

現在の主要な暗号方式（RSA、ECC など）は、量子コンピュータが十分に発達すれば理論上は破られる可能性があります。実用的な量子コンピュータの登場は 10〜20 年先と見られていますが、いま盗まれた暗号化データを将来復号する「Harvest Now, Decrypt Later」攻撃の懸念から、現時点から PQC への移行が始まっています。

NIST の標準化

NIST は 2024 年 8 月に最初の 3 つの PQC 標準（FIPS 203／204／205）を確定しました。クラウド事業者も順次対応を進めており、TLS の鍵交換アルゴリズムで PQC 対応が始まっています。

業務システムの開発者・経営層が「明日から PQC 対応を急ぐ」必要はありません。一方で、長期保管する暗号化データ（医療記録、契約書、政府記録など）を扱う組織は、移行計画を持つことが推奨されます。

📝 補足 PQC の技術的な詳細（格子暗号、符号ベース、多変数多項式、ハッシュベースなど）は、別の専門書を参照してください。本コースは「2026 年時点で意識しておく論点」として概要のみ触れます。

「クラウドネイティブ」という言葉

最後に、本コース全体で控えめに扱ってきた「クラウドネイティブ（cloud native）」という言葉について整理します。

定義の整理

CNCF（Cloud Native Computing Foundation）の定義によれば、クラウドネイティブとは、

スケーラブルなアプリケーションを構築・実行することを可能にする技術
コンテナ、サービスメッシュ、マイクロサービス、不変インフラ、宣言的 API などが典型

つまり「クラウド上で動くシステム全般」を指すのではなく、「クラウドの特徴を活かす設計」を指す言葉です。

濫用への注意

「クラウドネイティブ」は、業界マーケティングで濫用されがちです。「うちは何でもクラウドネイティブ」と言う組織が、実態としては仮想マシン 5 台で動いている、ということも珍しくありません。

本コースでは、クラウドネイティブを「目指すべき唯一の理想」とは扱いませんでした。Refactor によるクラウドネイティブ化は、組織の体力と業務要件次第で判断するもので、すべての業務が向くわけではありません。

本コース修了後の学習方向

本コースは「初級・全社員必修」として、クラウドの土台を概念中心に整理しました。ここから先の学びは、目的によって方向が変わります。

1. 業務での意思決定者として深めたい場合

各クラウドの公式ホワイトペーパー（無料公開、深い）
FinOps Foundation の Practitioner 認定資料
業界紙・カンファレンスレポート（AWS re:Invent、Microsoft Ignite、Google Cloud Next）
Gartner Magic Quadrant、Forrester Wave などの調査レポート

2. 設計者・運用者として技術深度を深めたい場合

公式の認定資格対策（AWS Solutions Architect、Azure Solutions Architect、Google Cloud Architect）
動かして学ぶ：無料枠で実際にリソースを立てて触る
Kubernetes、Terraform（IaC）、Linux などの周辺技術
各クラウドの公式チュートリアル

3. セキュリティ・ガバナンスを深めたい場合

情報セキュリティの基礎（CIA トライアド、認証、暗号化、フィッシング対策など）
CIS Benchmarks（クラウドセキュリティ設定の標準）
ISO 27001／27017／27018 などの認証
NIST SP 800-53、SP 800-207（ゼロトラスト）などのフレームワーク

4. 経営層・財務として把握したい場合

FinOps の概要書籍
TCO（総保有コスト）計算の基本
クラウド契約の交渉（エンタープライズ契約、コミットメント割引）
ベンダーマネジメントの基礎

講師の現場メモ：「3 年後に振り返って判断するもの」

私（山下）が独立後、ある中堅 SaaS の CTO に呼ばれて、3 年前に決めたマルチクラウド戦略の見直し相談を受けました。

3 年前、その SaaS は「リスク分散」と「ベスト・オブ・ブリード」の二つの理由で、AWS と Google Cloud の併用を決めていました。当時の CTO（前任者）の判断は、業界の流行に合致した妥当なものでした。

ところが 3 年経って、現場で起きていたのは、

エンジニア採用が困難（AWS 経験者と GCP 経験者を別々に確保する必要）
監視ツールを 2 種類運用するコスト
認証基盤の整合性確保に専任 1 人
マイナーな障害が頻発（クラウド間の通信遅延）
売上規模に比して、運用人員が他社の 1.5 倍

私と新しい CTO で、5 週間かけて「AWS 1 本に集約する」シナリオを試算しました。移行コストは 1.5 億円、運用コスト削減は年 4,000 万円、つまり 4 年で回収できる試算でした。「リスク分散」を捨てる判断は怖かったものの、現実の運用コストと比較すれば、集約がベターでした。

経営層に提案し、半年かけて GCP のワークロードを AWS に移行しました。1 年後、運用人員を 30% 削減できました。

このときに痛感したのは、「3 年前の最適解は、いまの最適解とは限らない」ということです。クラウド戦略は、3 年に一度は棚卸ししないと、現場と乖離します。本コースで何度も「要件で選ぶ」「半年で変わる前提」を強調してきたのは、そういう棚卸しの語彙を皆さんに持ち帰っていただきたいからです。

最後に 1 つ、本コースを通じてお伝えしたいメッセージがあります。

クラウドは魔法でも、危険物でもありません。電気や水道のような社会インフラに、ますます近づいていきます。インフラの中身を全員が知る必要はありませんが、「契約の発想」「責任分界」「コスト構造」「セキュリティ設計」の語彙を持つことで、業務判断の精度が変わります。本コースが、皆さんが自分の現場で「クラウドはこういう道具だから、うちはこう使う」と腹落ちして語れるための土台になれば、これに勝る喜びはありません。

ここまでおつきあいいただき、ありがとうございました。

まとめ

このレッスンでは、以下のことを学びました。

クラウド移行の 7R：Retain、Retire、Rehost、Replatform、Repurchase、Refactor、Relocate
組織の体力に応じて、業務システムごとに R を選び分けるのが現実的
ハイブリッドクラウド：オンプレ＋パブリック、マルチクラウド：複数パブリック
ハイブリッド・マルチクラウドは複雑さとコスト増を伴う。理想形ではなく選択肢の 1 つ
ベンダーロックインは過度な恐れも過度な楽観も避け、抽象化層やオープン技術でバランスを取る
2026 年 6 月時点の論点：AI エージェント実行環境、SBOM（CycloneDX／SPDX、EO 14028）、PQC（NIST FIPS 203／204／205）
「クラウドネイティブ」は CNCF の定義（コンテナ、マイクロサービス、宣言的 API など）。「クラウド上で動く全般」ではなく「特徴を活かす設計」を指す
修了後の学習方向：業務意思決定者、設計者・運用者、セキュリティ・ガバナンス、経営層・財務の 4 つの方向で異なる
クラウドは魔法でも危険物でもなく、社会インフラに近づいていく道具

本コース全 8 レッスンを通して学んだ語彙を、現場でぜひ使ってみてください。

確認クイズ

このレッスンの理解度をチェックしましょう。