ベンダー依存と出口戦略

文書基準: 2026年8月

なぜ出口戦略が必要か

単一ベンダーへの統合を深めるほど、価格交渉力が低下し、ベンダーのポリシー変更（値上げ、サービス終了、地域からの撤退）に対して脆弱になります。EU DORAなど一部の管轄では、金融業界にExit Planの文書化を義務付けています。2025年11月、ESAs（EBA、EIOPA、ESMA）はDORAに基づき最初のCTPP（Critical ICT Third-Party Provider）指定リストを公開し、CTPPに指定されたベンダーを利用する金融機関はより厳格なExit準備を証明する必要があります。国別の義務は韓国 · 米国 · EU · 日本 · シンガポールガイドを参照してください。

重要な誤解:

AWS Prescriptive Guidanceも同様の立場を示しています——「依存の防止は、技術的な決定よりも組織の人材・プロセスに大きく依存する」。

依存の4つの側面

側面	説明	例
データ依存	データ形式、ストレージ、イグレスコスト	S3専用フォーマット、Cosmos DB専用API、ペタバイト級データのイグレス
API依存	特定ベンダーのSDK/APIに合わせたコード	Lambdaイベントオブジェクト、Azure Durable Functionsの状態管理
アーキテクチャ依存	ベンダー固有のサービスに基づく設計	Step Functionsワークフロー、Cosmos DB専用機能
運用依存	チームのスキルとツールチェーンの偏り	CloudFormationのみを使うチーム、Azure DevOpsパイプライン
AI/ML依存	ファインチューニングモデル、エンベディング、ベクトルDBのベンダー依存	エクスポート不可のベンダー固有ファインチューニングモデル、特定エンベディングモデルに紐づくベクトルインデックス、プラットフォーム依存のプロンプト/RAGパイプライン

依存レベルとトレードオフ

サービスごとに依存の程度は異なります。一般的に下位レイヤー（IaaS）ほど低く、上位レイヤー（マネージドサービス）ほど高くなります。

レベル	依存度	移植性	管理負担	代表例
IaaS（VM）	低い	高い	高い	EC2、Azure VM、Compute Engine
コンテナ（Kubernetes）	非常に低い	非常に高い	中程度	EKS/AKS/GKE/OKE
オープンソースマネージド	中程度	中程度	低い	PostgreSQL/Valkey/Kafkaマネージド
クラウドネイティブPaaS	高い	低い	非常に低い	Aurora、Cosmos DB、BigQuery
サーバーレス（FaaS）	非常に高い	非常に低い	非常に低い	Lambda、Azure Functions、Cloud Run

選択は「管理負担の軽減 vs. 移植性の確保」のトレードオフです。ほとんどの組織は一点に集中せず、ワークロードの特性に応じて複数の地点を併用します。

ポータビリティのための設計原則

1. 標準オープンソースを優先

可能な箇所では業界標準のオープンソースインターフェースを選択します。

カテゴリ	移植性が高い選択	移植性が低い選択
コンテナオーケストレーション	Kubernetes (EKS/AKS/GKE/OKE)	ECS、Service Fabric
リレーショナルDB	PostgreSQL/MySQL互換（Aurora PostgreSQL、Cloud SQL）	Cosmos DB独自API、DynamoDB
キャッシュ	Valkey/Redis互換（ElastiCache、Cache for Redis）	ベンダー独自キャッシュ
メッセージキュー	Kafka互換（MSK、Event Hubs for Kafka）	SQS、Service Bus
コンテナイメージ	OCI標準イメージ（ECR、ACR、Artifact Registry）	ベンダー専用デプロイフォーマット
認証	OIDC/SAML	ベンダー専用SDK認証

2. IaCでインフラを定義

IaCはポータビリティの基盤です。Terraformはマルチクラウド定義を単一のツールで管理でき、移植性が最も高くなります。

ツール	マルチクラウド対応	移植性
Terraform / OpenTofu	主要ベンダー＋サードパーティ	非常に高い
Pulumi	主要ベンダー	高い
Crossplane	Kubernetesベースの抽象化	高い
AWS CloudFormation	AWS専用	低い
Azure Bicep / ARM	Azure専用	低い
Google Cloud Deployment Manager	Google Cloud専用	低い
OCI Resource Manager	OCI専用（Terraformベース）	中程度

3. 抽象化レイヤー

ベンダー依存のコードがアプリケーションのビジネスロジックに広がらないよう隔離します。

graph LR
    A[ビジネスロジック] --> B[抽象化インターフェース]
    B --> C1[AWS実装]
    B --> C2[Azure実装]
    B --> C3[Google Cloud実装]

代表的な抽象化ライブラリ/フレームワーク:

ストレージ: Go Cloud Development Kit、Apache Libcloud
メッセージ: CloudEvents (CNCF)
AI: LangChain、LlamaIndex（LLM抽象化）
Kubernetes: Knative Serving、Dapr

4. データポータビリティ

標準フォーマット — Parquet、Avro、JSON、CSV
定期バックアップを中立的な場所に保存 — 別リージョン/ベンダー/オンプレミス
イグレスコストの認識 — ペタバイト級のデータはイグレスコストが数万〜数十万ドル（USD）に達する場合があります。なお、Google Cloudは2024年1月からベンダー切り替え時のイグレス無料化を開始し、2025年9月にはEU/UKのマルチクラウド環境向けにData Transfer Essentialsを提供してイグレスコストを免除している（EU Data Act対応）
オフライン転送の活用 — ストレージマイグレーションを参照

Exit実行計画

金融業界/規制産業で求められるExit Planの一般的な構成要素:

1. 資産インベントリ

ワークロード、データ、依存サービスの一覧
各項目の依存レベル（高/中/低）
移行の優先順位と難易度

2. トリガーシナリオ

どのような状況でExitを実行するか:

ベンダーによる一方的な値上げ（契約上の上限を超過）
コアサービスの終了告知
規制変更によるベンダー利用制限
ベンダーのセキュリティインシデント/信頼喪失
M&Aによる戦略変更

3. 移行手順

ターゲット環境の準備（別ベンダーまたはオンプレミス）
データ移行の順序（マイグレーションウェーブ、アプリケーションマイグレーションを参照）
デュアルラン期間（2つの環境の並行運用）
レガシー終了基準

4. コスト見積もり

データイグレス
マイグレーションツール/人員
運用停止コスト
新環境の構築

5. 定期検証

年1回のExit Planレビュー
主要アーキテクチャ変更時の影響分析
競合ベンダーとのPoCによる実際の移行可能性の確認

よくある間違い

依存の排除を目標にマネージドサービスをすべて放棄する — 移植性のためにすべてをKubernetes上で直接運用し、運用負担とコストがかえって増加する
Exit Planを文書化するだけで検証しない — 年1回の競合ベンダーPoCや実際の移行テストを行わず、計画が現実と乖離する
イグレスコストを事前に見積もらない — ペタバイト級データのイグレスコストが数万〜数十万ドル（USD）に達し得ることを見落とす

チェックリスト

ワークロードごとの依存レベル（高/中/低）をインベントリとして管理しているか
Exitトリガーシナリオ（値上げ、サービス終了、規制変更）を定義したか
年1回Exit Planをレビューし、主要アーキテクチャ変更時に影響分析を実施しているか

参考資料

AWS

Azure

Google Cloud

OCI

Oracle Cloud Hosting and Delivery Policies

標準および規制

CNCF Cloud Native Trail Map
EU DORA (Digital Operational Resilience Act)
ESAs CTPP指定および監督フレームワーク — 2025年11月に最初のCTPP指定リストを公開
Martin Fowler — Strangler Fig Application