QCon London 2026: マルチクラウド戦略は製品の問題である ― そのように扱え
JPモルガン・チェースのエンジニアは、QCon Londonで、マルチクラウドの複雑性はエンジニアリングだけでは解決できず、機能マッピング、需要ガバナンス、ユーザー定義による製品としてのアプローチで管理できると主張した。
キーポイント
問題認識の転換
マルチクラウドの複雑性は、単なる技術的課題ではなく、製品開発の問題として捉えるべきであると指摘している。
製品としてのアプローチ
機能マッピング、需要ガバナンス、明確なユーザー定義という製品管理の手法を適用することで、マルチクラウド環境の混沌を制御できると提案している。
実践的な解決策の提示
エンジニアリングだけに頼らない、より体系的な管理フレームワークの必要性を、具体的なカンファレンスの場で実例を交えて示した。
影響分析・編集コメントを表示
影響分析
この記事は、クラウド戦略の議論を技術実装の域から、ビジネスと製品開発の視点に引き上げる重要な視点を提供している。特にJPモルガン・チェースのような大規模で規制の厳しい業界からの実例は、他の企業のマルチクラウド導入や管理における参考となる。
編集コメント
技術的詳細よりも、戦略的アプローチの転換点を伝える記事。大企業の実践例としての価値が高いが、技術的な革新性というよりは、既知の管理手法の応用という側面が強い。
QCon London 2026において、JPモルガン・チェースのルイス・アルビナティ氏とスラブヒ・マハジャン氏は、多くの企業がマルチクラウドを誤ったアプローチで捉えていると主張しました。問題の本質は技術的なものではなく、組織的なものです。企業は、買収やシャドーIT（Shadow IT）、規制圧力、あるいはAIワークロードのためのGPU確保を追うことで、結果として複数のクラウドにまたがる運用を余儀なくされます。そして彼らは、その結果生じた混乱を、火事一つずつ消すように技術で解決しようと試みます。アルビナティ氏とマハジャン氏は、持続可能な解決策はマルチクラウドをプロジェクトではなく製品として扱うことだと論じました。
JPモルガン・チェースのマルチクラウドプラットフォームにおける需要およびポートフォリオ管理を担当するプロダクトディレクターであるアルビナティ氏は、「カオスツリー（Chaos Tree）」と呼ばれる概念で講演を開始しました。クラウド移行は当初、コスト最適化とアジリティ（Agility）の観点から推進されましたが、どちらも期待通りに機能しませんでした。企業は支出が増大し、ガバナンスされていないワークロードを運用し、FinOps、ガバナンス、SaaSコンプライアンスといったリメディエーションプログラムを次々と積み重ねる結果となりました。それぞれに独自のツールセットと人員が必要となり、最終的には16件以上のアクティブなプロジェクトが同じエンジニアリング予算を巡って競い合う状態になりました。
中核的な問題は、チームがサイロ（Silo）化して運用されている点にあります。一つのチームがGCPを担当し、別のチームがAWS、さらに別のチームがAzureを担当し、それぞれに独自のロードマップを持っています。AIの導入が進むと、Vertex AI、Bedrock、Azure OpenAIへの同時アクセスを望むチームが増え、サイロはさらに増殖します。誰一人として全体像を把握している者はいません。
彼らが提案した解決策は、製品管理の手法を借用しています。クラウドプロバイダーごとに組織するのではなく、アルビナティ氏は機能（capabilities）ごとに組織化することを推進しました：観測可能性、コスト管理、アイデンティティ、ネットワーク、デリバリーです。各機能はすべてのクラウドとビジネスラインに横断的に存在し、「AWS のロードマップはどうなっているか」という議論から「どこでも統合された観測可能性を提供できているか」へと転換させます。彼は構造化された需要ガバナンスを強調し、定期的な受入窓口（intake windows）を設定してチームに要件の提出を義務付け、計画期間中にその窓を閉じることを求めました。
JP モーガン・チェース社のログプラットフォームにおけるシニアアーキテクト兼テクニカルプロダクトマネージャーであるマハジャン氏は、具体的な例を通じて議論を実践的なレベルに引き下げました。彼女は「フランケンシュタイン型ログ」と呼ぶ状況を説明しました。これは、GCP、AWS、オンプレミスシステムからのデータをすべて AWS の S3 バケットへ流し込むことで中央集権型のログプラットフォームを運用する現実です。その結果、膨大なエグレスコストが発生し、ノイズの多いデータとなり、SRE（サイトエンジニアリング）担当者が午前 2 時のインシデント対応中に 3 つのブラウザウィンドウ間でタイムスタンプを照合して苦労することになりました。
彼らの解決策は、これをプロダクトチームのように捉えることでした。対象となるユーザーである SRE（サイトエンジニアリング）やサイバーオペレーションを特定し、過去 1 年間に実際のインシデント発生時にこれらのユーザーがどのようにデータを照会していたかを調査しました。その後、各クラウドのエッジに OpenTelemetry コレクターを展開し、ネットワーク境界を越える前にヘルスチェックや低価値のイベントをフィルタリングしました。マハジャン氏は、このアプローチによりログ量が 60% から 80% 削減され、「ノイズではなくシグナル」のみを送信できたと報告しています。また、すべての環境にわたって流れる「黄金の糸」として分散トレーシング ID を標準化し、特定までの平均時間を数時間や数日から数分に短縮しました。
マハジャン氏は聴衆に対して、実践的な教訓として「コンソールテスト」を提示しました。これは、どのプラットフォームチームでも自社のロギングインフラストラクチャに対して実行できる一連のシナリオです。もしこのテストにパスすれば、クラウドプロバイダーを統一されたエンジニアリング体験のための原材料として扱うものが構築できたことになります。もし失敗すれば、次に何を修正すべきかが明確になります。
アルビナーティ氏は、能力をサイロ化されたソリューションよりも優先し、孤立した優先順位よりも共有された発見を重視し、個別の対応ではなくゴールデンパス（標準的な成功への道筋）を採用し、設計によるガバナンスを実現し、単なるポータビリティよりもレジリエンスを重視するという原則をマニフェストとしてまとめました。彼は最後の点について率直に述べました。ポータビリティは一部の課題を解決しますが、時には答えはより優れた Kubernetes デプロイメントではなく、差別化された SLA（サービスレベルアグリーメント）に関するより良い契約を含むものであると。
著者について
Steef-Jan Wiggers
Steef-Jan Wiggers は、InfoQ のシニアクラウド編集者の一人であり、オランダの VGZ でドメインアーキテクトとして勤務しています。彼の現在の技術的専門分野は、統合プラットフォームの実装、Azure DevOps、AI、および Azure プラットフォームソリューションアーキテクチャに焦点を当てています。Steef-Jan は会議やユーザーグループでの定期的なスピーカーであり、InfoQ 向けにも執筆活動を行っています。さらに、マイクロソフトからは過去 16 年間にわたり Microsoft Azure MVP（Most Valuable Professional）として認定されています。
詳細を表示する表示しない
原文を表示
At QCon London 2026, Luis Albinati and Surabhi Mahajan from JP Morgan Chase made the case that most enterprises are approaching multi-cloud in the wrong way. The problem isn't technical, it's organisational. Companies end up running across multiple clouds by accident, through acquisitions, shadow IT, regulatory pressure, or chasing GPU availability for AI workloads. Then they try to engineer their way out of the resulting mess, one fire at a time. Albinati and Mahajan argued that the only sustainable fix is to treat multi-cloud as a product rather than a project.
Albinati, a product director responsible for demand and portfolio management across JP Morgan Chase's multi-cloud platform, opened with what he called the "chaos tree." Cloud migration was originally sold on the basis of cost optimisation and agility. Neither panned out cleanly. Companies found themselves spending more, running ungoverned workloads, and layering on remediation programmes such as FinOps, governance, and SaaS compliance, each with its own tooling and headcount, until sixteen or more active projects were competing for the same engineering budget.
The core issue is that teams operate in silos. One team owns GCP, another AWS, and another Azure, each with its own roadmap. When AI enters the picture, teams wanting access to Vertex AI, Bedrock, and Azure OpenAI simultaneously, those silos multiply. Nobody has the full picture.
Their proposed solution borrows from product management. Rather than organising around cloud providers, Albinati pushed for organising around capabilities: observability, cost management, identity, networking, and delivery. Each capability cuts horizontally across every cloud and business line, shifting conversations from "what does our AWS roadmap look like?" to "are we delivering unified observability everywhere?" He stressed structured demand governance, opening intake windows at a cadence, forcing teams to submit requirements, and closing the window to allow planning.
Mahajan, a principal architect and technical product manager for JP Morgan Chase's logging platform, brought the argument down to earth with a concrete example. She described what she called "Frankenstein logging", the reality of running a centralised logging platform that ingests data from GCP, AWS, and on-premise systems by funnelling everything into S3 buckets on AWS. The result: massive egress costs, noisy data, and SREs stuck correlating timestamps across three browser windows during a 2 AM incident.
Their fix was to think about it as a product team would. They identified their users, SREs, and cyber operations and studied how those users actually queried data during real incidents over the previous year. Then they deployed OpenTelemetry collectors at the edge in each cloud, filtering out health checks and low-value events before anything crossed a network boundary. Mahajan reported that this approach cut log volume by sixty to eighty percent, sending what she called "signals, not noise." They also standardised on distributed trace IDs as a "golden thread" that flows across all environments, which reduced the mean time to identify from hours or days to minutes.
Mahajan left the audience with a practical takeaway: a "console test", a set of scenarios that any platform team can run against their own logging infrastructure. If your platform passes, you've built something that treats the cloud providers as raw materials for a unified engineering experience. If it fails, you know what to fix next.
Albinati closed with a set of principles framed as a manifesto: capabilities over siloed solutions, shared discovery over isolated priorities, golden paths over bespoke one-offs, governance by design, and resilience over mere portability. He was blunt about that last point: portability solves some problems, but sometimes the answer involves better contracts about differentiated SLAs, not just better Kubernetes deployments.
About the Author
Steef-Jan Wiggers
Steef-Jan Wiggers is one of InfoQ's senior cloud editors and works as a Domain Architect at VGZ in the Netherlands. His current technical expertise focuses on implementing integration platforms, Azure DevOps, AI, and Azure Platform Solution Architectures. Steef-Jan is a regular speaker at conferences and user groups and writes for InfoQ. Furthermore, Microsoft has recognized him as a Microsoft Azure MVP for the past sixteen years.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み