依存を止める選択。欧州スタックでデータ主権を確実に守る実践記

🎧 音声で聴く：ジョンとリラが本記事をもとに、現場視点と戦略視点から独自の見解をディスカッションしています。記事では詳細なデータと参照リンクをまとめています。

導入

ITコンサルタンシーのCoinerellaが、米国中心のスタートアップ基盤をEU製スタックに置き換える実践記を公開した。対象はAWSからの脱却だけではない。データ主権を「設定のトグル」ではなく「アーキテクチャの姿勢」として捉え直す試みだ。

著者はInfoWorldのDavid Linthicum氏。クラウド戦略の第一人者として知られる同氏が、Coinerellaの取り組みを分析しながら、オルタナティブクラウド戦略の現実的な利点と代償を描いている。

この記事では、Coinerellaが構築したEUスタックの全体像、移行で直面した具体的な困難、そして「主権とはスペクトラムである」という核心的な主張を、日本のインフラ設計に携わる立場から読み解く。

背景と課題

クラウドにおけるデータ主権は、ハイパースケーラーのコンソールでリージョンを選び、コンプライアンスのチェックボックスを入れれば完了する――そう扱われることが少なくない。だが現実には、データレジデンシー、GDPR準拠、集中リスクの低減といった要件は、単なる設定変更では満たせない構造的な課題だ。

Coinerellaのアプローチは、プラットフォームがAWSや米国拠点のハイパースケーラーに「流されていく」ことを意図的に拒否するものだった。動機は理念だけではない。データレジデンシー、GDPR準拠、集中リスクの低減、そしてヨーロッパのインフラが運用上実用的であることの実証という、極めて実務的な判断に基づいている。

Linthicum氏が指摘するのは、リーダー層の態度の脆さだ。主権について熱く語るリーダーでも、最初の本番障害、最初のコンプライアンスレビュー、最初のインテグレーションギャップに直面すると、その姿勢が揺らぐ。Coinerellaはそこで折れずに、結果と向き合い続けている点が特筆に値する。

――主権を掲げるのは簡単だが、最初の障害で折れない組織はどれだけあるか。

技術・内容解説

Coinerellaが構築したEUスタックは、新しいパターンを発明したわけではない。標準的なモダンプラットフォームを、ヨーロッパのプロバイダーと選択的なセルフホスティングで再構成したものだ。その構成要素を整理する。

コアインフラ：Hetznerを中心とした構成

プライマリのコンピュートと基盤サービスはHetznerに移行された。仮想マシン、ロードバランシング、S3互換のオブジェクトストレージが含まれる。Linthicum氏が注目するのは、ハイパースケーラー側の語り口との乖離だ。「AWSを離れることは機能を失うこと」という主張に対し、Coinerellaは少なくとも基本機能については、性能と機能が十分であり、コスト面でも魅力的だったと報告している。

補完プロバイダー：Scalewayによるギャップ充填

Hetznerがカバーしないマネージドサービスには、Scalewayを充てた。トランザクショナルメール、コンテナレジストリ、追加のオブジェクトストレージ、オブザーバビリティツール、ドメイン登録が含まれる。複数プロバイダーの組み合わせは通常、複雑性が急増するポイントだが、Coinerellaはこの方式を意図的に採用した。単一ベンダーに全てを強いるのではなく、リージョン内で最適な選択肢を選ぶ方針だ。

エッジ：Bunny.netの活用

CDNと関連機能にはBunny.netを採用した。ストレージ、DNS、画像最適化、WAF、DDoS防御を含む。Cloudflare中心の世界から移行した際の体験は「取り組みやすかった」とされており、移行時のリスク低減に寄与した点をLinthicum氏は評価している。エッジサービスは単なる付加機能ではなく、プラットフォームの信頼性とセキュリティの中核をなすという指摘は重要だ。

AI推論とアイデンティティ

AI推論については、米国リージョンにデフォルトで依存するのではなく、Nebiusを通じてヨーロッパのGPUキャパシティを利用した。認証にはHankoを採用。パスキーなどのモダンな認証方式に対応し、ソーシャルログインにも対応するヨーロッパの認証プロバイダーだ。

セルフホスティング：Kubernetes上の内部サービス群

Kubernetes上にRancherを管理レイヤーとして、以下のサービスをセルフホスティングしている。

• Gitea（ソースコード管理）
• Plausible（アナリティクス）
• Twenty（CRM）
• Infisical（シークレット管理）
• Bugsink（エラートラッキング）

「少しだけセルフホストする」という判断が何を意味するか、インフラを運用した経験がある人間には分かるだろう。コスト削減とコントロールの獲得は、ライフサイクル全体の運用責任と引き換えだ。

構成の全体比較

機能領域	一般的な米国中心構成	CoinerellaのEUスタック	運用上の注意点
コンピュート・ストレージ	AWS EC2 / S3	Hetzner（VM、LB、S3互換ストレージ）	基本機能は遜色なし。高度なマネージドサービスは不足する場面あり
補完マネージドサービス	AWS各種マネージドサービス	Scaleway（メール、レジストリ、オブザーバビリティ等）	複数プロバイダー間の統合作業が増加
CDN・エッジ	Cloudflare	Bunny.net（CDN、DNS、WAF、DDoS防御）	Cloudflareからの移行は比較的スムーズとの報告
AI推論	米国リージョンのGPUサービス	Nebius（欧州GPUキャパシティ）	最先端モデルへのアクセスには依然として米国APIが必要な場合あり
認証	Auth0等の米国サービス	Hanko（パスキー・ソーシャルログイン対応）	エコシステムの厚みでは米国勢に劣る
ソースコード管理	GitHub	Gitea（セルフホスト）	CI/CDやマーケットプレイスの統合は自前構築が必要
セルフホスト運用負荷	低（マネージド依存）	高（Kubernetes + Rancher上で複数サービス運用）	パッチ適用、バックアップ、復旧テストを自前で管理する必要あり

最後の「運用上の注意点」列は元記事の情報を基にした独自の整理だ。マネージドサービスへの依存度が下がる分、運用負荷は確実に上がる。この欄がない比較表は、主権移行の本質を見誤らせる。

移行で直面した具体的な困難

トランザクショナルメールが最大の摩擦点の一つだった。米国エコシステムではメール配信サービスの選択肢が豊富で、統合も容易、コミュニティによる配信性やトラブルシューティングのガイダンスも厚い。欧州の代替サービスでも動作はするが、統合テンプレートやコミュニティの知見が地域間で均等に分布していないという現実がある。自社がインテグレーションチームを兼ねる場面が増える。

ソースコード管理もGitのリモート先を変えるだけの話ではなかった。GitHubを離れるということは、CI/CDのデフォルト設定、アクション、マーケットプレイス統合、そして開発者が身体に染み込ませたGitHub流の運用習慣というエコシステムごと離れることを意味する。Giteaは堅実な基盤になり得るが、支配的プラットフォーム上で「無料で」手に入る一連の自動化パイプラインを自動的に持ってくるわけではない。

コストの異常値も報告されている。一部のトップレベルドメインが欧州レジストラ経由だと大幅に高額になるケースがあり、その理由は十分に説明されていないとCoinerellaは述べている。アーキテクチャ上の致命的問題ではないが、市場構造の予想外の違いに遭遇することを示す好例だ。

――地味なサービスほど、移行の痛みが大きい。

よくある誤解

用語解説

データレジデンシー

データが物理的に保存・処理される地理的な場所に関する要件。GDPRなどの規制では、特定の種類のデータをEU域内に保持することが求められる場合がある。

FinOps

クラウドの財務管理を工学的に最適化するための実践手法。複数プロバイダーやセルフホスト環境にまたがるコスト可視化と最適配分が求められる。

オブザーバビリティ

システムの内部状態を外部から観測・理解可能にするための設計原則。メトリクス、ログ、トレースの3要素を中心に、障害の迅速な検知と原因特定を目指す。

ソブリンクラウド

特定の国や地域の法規制に準拠し、データの主権を確保するために設計されたクラウド環境。プライベートクラウドやオルタナティブクラウドと重なる概念だが、法的・地政学的な準拠が明示される点が特徴。

集中リスク

単一のプロバイダーやプラットフォームにインフラが集中することで、障害・契約変更・地政学的リスクが連鎖的に波及する危険性。

インパクト・活用事例

Coinerellaの経験は、ソブリンクラウド、プライベートクラウド、その他の「デフォルトではない」プラットフォームに向かう多くの企業が学びつつある内容と一致している。Linthicum氏が指摘する最大の教訓は、移行のコストメリットが魅力的に見えるのは、まさにより多くの作業を引き受けているからだという点だ。

インフラコストの削減は現実のものだが、その見返りとして、統合の責任増大、プラットフォームエンジニアリングの強化、そして高い運用成熟度が求められる。

「欲しいもの」と「必要なもの」の選別

ハイパースケーラーは、マネージドサービスをメニューから料理を選ぶように選択する習慣をチームに植え付けてきた。便利で早く、組織内の政治的にも通りやすいからだ。オルタナティブクラウド戦略はそこに優先順位付けを強いる。最新のマネージド機能群、最も充実したマーケットプレイス、最も広いエコシステムを「欲しい」と思っても、ビジネス成果の達成に「必要」とは限らない。

主権やプライベートクラウドを選択すると、要件を満たすより単純な技術を選ぶことになる場面が増える。華やかさや機能の豊富さは劣るかもしれない。だがこれは後退ではなく、アーキテクチャ上の規律だとLinthicum氏は述べている。

移行に不可欠な新しいプラクティス

FinOpsは、異種プロバイダー群、セルフホスト基盤、ハイパースケーラーに任せられなくなったキャパシティ計画を横断するエンジニアリング規律になる。オブザーバビリティは、プロバイダー境界をまたぎ、エンドツーエンドで所有するコンポーネントを含むプラットフォームを構築する以上、設計段階からの最重要要件となる。

一貫したメトリクス、ログ、トレース、SLO、インシデント対応手順が、プロバイダーごとにツールやAPIが異なる環境下でも機能する必要がある。自前でやる範囲が広がる以上、パッチ適用、セキュリティ、バックアップ、復旧テスト、運用手順書の整備をより明示的に行う必要がある。

排除できない依存関係

Coinerellaは「米国依存を全て排除した」という純粋主義の物語ではない。構造的に排除できない依存関係が存在することを正直に認めている。

• ユーザー獲得にGoogleの広告エコシステムが必要な場合がある
• モバイル配信はAppleの開発者プログラムを経由せざるを得ない
• ソーシャルログインはGoogleとAppleのインフラに依存しており、除去するとコンバージョン率に影響し得る
• 特定の最先端AIモデルを使いたければ、米国のAPIを利用せざるを得ない場合がある

正直なところ、この「排除できないものは隔離し、トレードオフに誠実であれ」という姿勢こそが、この事例の最大の価値だと考えている。主権を全か無かで語る議論は現実の設計判断に役立たない。コアデータと運用上の依存関係がどこに置かれるかについての、段階的な選択の連続として捉える方が実用的だ。

――主権は二値ではない。スペクトラムだ。

アクションガイド

Coinerellaの事例から得られる知見を、読者の立場別に整理する。

インフラ・プラットフォームエンジニア向け

意思決定者・アーキテクト向け

• 主権を「製品機能」ではなく「戦略的姿勢と工学的コミットメント」として位置づける。これが組織内の期待値管理の出発点になる
• 「欲しいもの」と「必要なもの」を分離する判断基準を事前に設定する。ハイパースケーラーのマネージドサービスのうち、ビジネス成果の達成に本当に必要なものを絞り込む
• 最初の本番障害やコンプライアンスレビューで姿勢が揺らがないよう、移行の意思決定根拠と許容するトレードオフを文書化しておく

個人的には、日本のSIer案件においてこの種のオルタナティブクラウド移行が検討される場合、最大のボトルネックはセルフホスティングの運用体制構築よりも、複数プロバイダーの契約・請求・サポート窓口の一本化が難しいという商習慣の問題だと見ている。技術的な実現可能性よりも、調達プロセスと運用体制の組織的な設計が先に立ちはだかる場面が多い。

未来展望とリスク

Linthicum氏の整理は明快だ。主権対応が「難しすぎてできない」のではなく、「予測可能な形で難しい」のだ。Coinerellaの事例は、その旅が苦労に見合う価値があることを示しているが、容易ではないという枠組みこそが、企業のリーダー層に必要なものだとしている。

主権をプロダクトの機能として期待すれば失望する。戦略的姿勢として、実際の工学的コミットメントを伴うものとして扱えば、コントロール、コスト、ローカリティの利点を、必要な作業量に驚かされることなく得られる。

ただし、この種の移行が今後広がるかどうかは、ヨーロッパのプロバイダー側のエコシステム成熟度にも依存する。トランザクショナルメールやCI/CDといった領域でコミュニティの厚みが増さなければ、移行のハードルは高いままだ。また、地政学的な情勢変化がデータ主権の要件を急に厳格化させるリスクもあり、その場合はCoinerellaのような先行事例が参照ケースとして重要性を増すだろう。

――「予測可能な困難」は、準備さえあれば管理可能だ。

まとめ

Coinerellaの取り組みが示しているのは、クラウド主権は設定画面のトグルスイッチではなく、アーキテクチャの姿勢と運用モデルの全面的な再設計であるという事実だ。Hetzner、Scaleway、Bunny.net、Nebius、Hankoといったヨーロッパのプロバイダー群を組み合わせ、Kubernetes上でGitea、Plausible、Twenty、Infisical、Bugsinkをセルフホスティングする構成は、コスト面で魅力的だが、統合とライフサイクル管理の負荷を自ら引き受けることを意味する。

メール配信やソースコード管理といった「地味な」サービスでの摩擦、ドメイン登録コストの説明のつかない価格差、そしてGoogleやAppleのインフラへの構造的依存など、移行の現実は「きれいな実験室」とは程遠い。それでも、排除できるものは排除し、できないものは隔離し、トレードオフに誠実であるという姿勢は、主権を語るすべての組織が参照すべき基準だ。

FinOps、オブザーバビリティ、運用手順書の整備といった新しいプラクティスを最初から織り込めるかどうかが、この種の移行の成否を分ける。主権は意思決定の連続であり、その覚悟と準備がなければ成立しない。

参照リンク・情報源

• InfoWorld：Sovereignty isn’t a toggle feature（David Linthicum、2026年2月27日）
• Coinerella：Made in EU – it was harder than I thought