2025年のMSライセンス価格改定を契機に締結した50億円・5年間のAzureコミットメント。
これは単なるコスト防御ではなく、AWSで実証したクラウド活用能力をAzureへ拡張し、
マルチクラウドを真の経営変革基盤として完成させる転換期である。
AWS（守り）・Azure（攻め）・GCP（マーケティング）の役割を固定化し、グループ全体で一貫性あるクラウド運用を実現する。
データ統合・AI活用・市民開発・グローバル接続の5つの実行軸で競争優位性を創出。単独施策ではなく一体的なプラットフォームとして推進する。
CCoE体制・Microsoftとの戦略的協働・TCS運用エコシステムを構築し、再現性ある実行フレームワークを確立する。
直接的な契機（MSライセンス価格改定）と構造的な変化（クラウドの経営基盤化）が重なった、サントリーにとって唯一無二のタイミングである。
この変化はサントリーにとって追い風でも向かい風でもなく、対応できるかどうかで競争力の差が生まれる環境変化である。
| 変化軸 | 📉 これまで | 📈 これから |
|---|---|---|
| クラウドの役割 | ITインフラの効率化手段 | 経営スピードと変革力を左右する経営基盤 |
| 競争優位の源泉 | クラウドはAWSでほぼ1択 | 事業価値に応じてクラウドを使い分ける設計力・統制力 |
| AI活用の水準 | 業務効率化のPoC段階 | 意思決定の高度化・業務プロセスそのものの再設計 |
| データの位置づけ | 各BUごとに分散配置 | グローバル横断の戦略的資産として意思決定に活用 |
| セキュリティ・ガバナンス | AWSのみ中央統制 | マルチクラウドを前提とした横断的・自動化された統制 |
3つのクラウドは明確な成熟度の差があり、AWSは完成した基盤・Azureは戦略的に重要だが未完成・GCPは補完的活用に留まる。
現状分析が示すのは、個別クラウドの技術的課題ではなく、より深いところにある3つの構造問題である。これらを解決しない限り、いかなる戦略も実行力を持たない。
マルチクラウドを「経営前提」と捉える戦略思想は時代の潮流と合っているが、それを動かすための意思決定単位・投資構造・設計思想が同じレイヤーで整備されていない。AWSの成功体験を前提とした期待が先行する一方で、AWSが経た「初期標準設計・運用体制構築・パートナー形成」という条件がAzureには与えられていない。
Azureはデータ統合・AI活用・市民開発・グローバル横断基盤の中核に位置づけられるべきだが、使い方・責任・コストが明確な「社内向けサービス」として完成していない。「技術的には存在するが、使うには都度確認が必要なもの」に留まっており、この状態ではデータ・AI活用を全社規模でスケールさせることは難しい。
設計・判断・運営の責任が分散し、横断視点で統制・推進する組織単位が不明確。Azure活用は個人の調整力や現場努力に依存しており、再現性もスケールも持たない。Microsoftを「戦略パートナー」と位置づけながら、共同ガバナンス・役割分担が十分に設計されていない。受け手側の権限設計・体制・覚悟が整わない限り、戦略パートナーシップは形式に留まる。
「どのクラウドが優れているか」ではなく、「どのクラウドが、どの価値を最も合理的に実現できるか」で役割を明確に定義する。役割を固定化することで、グループ全体の一貫性あるマルチクラウド運用を実現する。
AzureをAWSの「第2のクラウド」として単純に位置づけるのではなく、グローバル・横断・End-to-Endで設計できる整合性に着目し、AWSとは補完関係にある戦略基盤として明確に位置づける。
Windows ServerやSQL Serverのライセンスを、AWSと比較して安価に利用可能。既存のMicrosoft投資との相乗効果を最大化し、クラウド移行における総保有コスト（TCO）を削減する。
データレイクを全社で同じクラウドに配置し、Power PlatformとAzure間を同一リージョン内で連携させることで、クラウド間通信に伴うEgressコストを最小化させる。
セキュアな参照：Microsoft Graphコネクタにより、Entra IDの権限を維持したまま、Azure上のデータをCopilotの回答に安全に活用可能。M365との深い統合により、情報活用と情報統制を同時に実現できる。
認証の統合：Entra IDにより、アプリからDBまで一貫した認証基盤で管理可能。
安全なRAG構築：Azure AI SearchとPrivate Linkを併用し、インターネットを経由しない閉域網内でのデータ検索・生成AI連携を実現。
Azure上のデータに付与された機密設定を、Copilotが生成した回答にも自動適用。データの取り扱いルールをエンドツーエンドで維持し、情報ガバナンスを生成AIの活用領域まで一貫して適用できる。
5つの軸は相互に連動させることで初めて最大の価値を発揮する。単独施策の積み上げではなく、一体的なプラットフォームとして設計・推進することが肝要である。
「One Suntory」の視点で、Suntory Japan・SBF・SGSに分断されたデータを統合し、グローバル横断で「同じ数字を見て判断できる」経営データ基盤を確立する。経営層・事業責任者がスピーディに意思決定できるデータレイクを構築する。
Copilot（業務フロント）とAzure OpenAI（業務システム統合型AI）を全社標準AIとして位置づける。人に依存していた業務判断・資料作成・分析を組織の能力として内製化し、AIを一過性の実験から持続的な生産性向上基盤へ進化させる。
Power Platformを全社標準の業務デジタル化基盤とし、IT主導の大規模開発と現場主導の即応的改善を明確に役割分担する。業務システムと現場アプリをセキュアに接続、また上述のAI基盤も活用することで、「現場が自律的に改善し続ける組織」への転換を実現する。
インフラ・CI/CD・セキュリティ・監視を共通プラットフォームとして標準化し、各事業・各国で「同じやり方で高速にクラウド基盤を提供、安定して動かせる」土台を整備する。開発者がセルフサービスで利用できるIDP（内部開発プラットフォーム）を構築し、グループ全体で再現性のあるITデリバリー能力を確立する（Platform Engineering）。
Azure Virtual WANを中核としたネットワーク基盤により、オンプレ中心の資産から脱却し、Azure・AWS・GCP・オンプレを一元的に接続・統制する。MPLSからSD-WANへの移行によりコスト最適化と運用生産性向上を両立しつつ、現行グローバルバックボーンの廃止を図る。
| 領域 | 📉 現状（As-Is） | 🎯 目指す姿（To-Be） |
|---|---|---|
| 技術標準 | SI2・SGSで別々の標準、属人的な更新 | 統合Azure標準、AI支援による半自動更新 |
| データ基盤 | 3社で分断、横断参照困難 | 仮想統合データレイク、グローバル横断参照可能 |
| AI活用 | 個別PoC、散在・未定着 | Copilot / Azure OpenAI 標準化、業務組み込み |
| 開発基盤 | 手動・属人化、スピード不足 | セルフサービスポータル・IaC自動化による高速開発 |
| ネットワーク | MPLS中心、複雑なグローバル接続 | SD-WAN / Virtual WAN 一本化、コスト最適化 |
| 運用 | 手動対応・TCS/個人依存 | AIOps活用による自動・半自動インシデント対応 |
| 組織・推進 | 個人の調整力依存、横断統制なし | CCoE体制によるガバナンス、MS戦略パートナーシップ機能 |
Azureコミットメント期間（5年間）を3フェーズに分け、段階的に成熟度を高める。フェーズの考え方は「基盤を整える → スケールさせる → 変革を実現する」である。
構造課題③への対応として、横断戦略を実現するガバナンスモデルを確立する。「止める統制」ではなく「使わせる統制」——標準・ガードレール・運用モデルをあらかじめ整備し、現場のスピードを阻害しない体制を構築する。
AWSで確立した運用エコシステム以上のものをAzureに構築することを目指す
| 役割 | 責任内容 | 担当者 / 所属 |
|---|---|---|
| ITプロジェクトリーダー | スコープ・マイルストーン・成果のエンドツーエンド管理責任 | Tom (SHD) |
| エグゼクティブスポンサー | 戦略方針の決定および主要意思決定のサポート | Lusman (SHD), Ian (SGS) |
| エンタープライズアーキテクチャリード | ターゲットアーキテクチャおよび標準化アプローチの定義 | Rohan (SHD), Joshua (SBF), TCSアーキテクトチーム(TBD) |
| エンジニアリングリード | Azureサービスの実装・構築の実行 | Rohan (SHD), Son (SHD), TCSエンジニアリングチーム(TBD) |
| セキュリティ・ガバナンスチーム | コンプライアンス・セキュリティポリシー遵守の確保 | Turner (SHD), Vincent (SBFI) |
| VMO（ベンダー管理オフィス） | MSコミットメント達成状況管理・契約/商務調整 | Janice (SHD) |
| Azureオペレーションチーム | 運用準備・ランブック作成・BAUへの移行対応 | Rohan (SHD), Son (SHD), TCSオペレーションチーム(TBD) |
| 各ビジネスユニット代表 | 要件提供・設計検証・導入支援 | M Cruz (SBFE), Ram (SBFI), Mitsu (SBFA), TBD (SBFO), Larry (PBV) 等 |
戦略の進捗と成果を定量・定性の両面から継続的に計測・可視化する。
| KPI | 目標値 | 計測時期 |
|---|---|---|
| Azureコミットメント達成率 | 5年累計50億円（計画通りの消化） | 毎年度末 |
| Azure標準化カバレッジ | 主要マネージドサービスの標準化率 95%以上 | Phase 1末（2027年3月） |
| Azure技術者数 | Azure solutions architect associate相当の技術者の数 60名以上 | Phase 1末（2027年3月） |
| データ統合カバレッジ | 3社主要業務データのデータレイク統合率 | Phase 2末（2029年3月） |
| SD-WAN移行率 | MPLSからSD-WANへの移行完了割合 | Phase 3末（2031年3月） |
Azure基盤の構築・運用にあたって発生する費用の概要。BU固有の要件に基づく個別サービス費用は別途。
| コスト種別 | 項目 | コスト / 条件 | 備考 |
|---|---|---|---|
| 初期費用（Capex） | 各BUのSI2 Azure環境 初期構築費用 | 未定（TBD） | 新設のTCS Azureチームが実装を担当予定 |
| 初期費用（Capex） | Azureへの専用接続 初期設定費用 | 未定（TBD） | 各BUが利用する通信キャリアのサービス料金に依存 |
| 月次費用（Opex） | 各BU Azureサブスクリプション 基本インフラ月次費用 | 月額 USD 2,600 | Azureファウンデーションインフラのネットワーク・セキュリティ関連費用 |
| 月次費用（Opex） | TCS Azureオペレーションチーム費用 | 未定（TBD） | AWSと異なりFTベースのモデルで料金が算定されるため、サントリーグローバル全体へのコスト配賦方法は現時点で未決定 |
主要リスクを発生可能性・影響度で評価し、具体的な対応方針を定義する。