CAF（Cloud Adoption Framework：クラウド導入フレームワーク）とは、主要クラウドサービス提供事業者で採用されているクラウド導入のベストプラクティスのことです。本特集では、書籍『CAFではじめるAzureクラウド導入＆運用ガイド AI Ready実現の最適解』（日経BP）から抜粋し、著者が実際に支援した企業の実話に基づく、「AI Readyのためのクラウド導入」を進めたエピソード（数社の事例を組み合わせたフィクション）を紹介します。第2回では、経営層や現場エンジニア、セキュリティー担当者らの“認識の溝”を打開した経緯を取り上げます。
組織横断型クラウド推進チーム（CCoE）の発足はゴールではなく、いばらの道のスタート地点にすぎませんでした。多様なバックグラウンドを持つメンバーが集まった最初のキックオフ会議。そこで露呈したのは、経営層、現場エンジニア、そしてセキュリティー担当者の間にある、マリアナ海溝よりも深く暗い“認識の溝”でした。
「戦略・計画」フェーズの苦悩――ROIの壁と「8つのR」
最初の衝突は“カネ”の話から始まりました。経営層がクラウド導入に求めていたのは、徹頭徹尾「コスト削減」でした。「オンプレミスのサーバー更改費用が5億円かかる試算だ。クラウドなら、それより安くなるんだろう？3億円で済ませてくれ」――。これが彼らの期待値であり、プロジェクトの承認条件でした。
一方で、現場のエンジニアたちはまったく違う夢を見ていました。「せっかくクラウドに行くなら、コンテナ技術（Kubernetes）を使ってマイクロサービス化したい」「古臭いモノリシックなアプリをリアーキテクト（作り直し）して、開発スピードを上げたい」――。彼らにとってクラウド移行は、積年の技術的負債を返済し、モダンな開発環境を手に入れる千載一遇のチャンスだったのです。
ここに決定的な対立が生まれました。現場が望む「モダナイズ（最新化）」を突き詰めれば、初期投資と学習コストは膨らみ、経営層が期待する「コスト削減」とは真逆の結果になります。「コスト」か、「技術」か。板挟みになったCCoEは、会議のたびに紛糾する議論を前に立ち尽くしました。
その打開策は、CAF（Cloud Adoption Framework：クラウド導入フレームワーク）の「クラウド移行戦略の合理化（Rationalization）」にありました。CCoEのリーダーは、感情論で戦うのをやめ、冷徹な「数字とロジック」で戦うことにしたのです。
彼らは全システムを棚卸しし、CAFが提唱する「8つのR」に基づいて仕分けを行いました。
Quick Wins（即効性重視）：差別化につながらない社内システムや単純なWebサーバーは、そのまま移行する「Rehost（リホスト）」を選択。これにより、短期的な移行コストを抑え、経営層への手土産となる「早期のコスト削減効果」を確保する。
戦略的投資（将来性重視）：目玉となる「AI連携が必要な顧客データ基盤」や、顧客接点となる「主力ECサイト」については、コストがかかっても作り直す「Rearchitect（リアーキテクト）」を選択。ここはコスト削減領域ではなく、将来の売上増（ROIC）を狙う「投資領域」だと定義し直す。
CCoEリーダーは、経営会議のスクリーンに1枚のスライドを映し出し、こう説明しました。
「社長、すべてのシステムを高級なスポーツカー（クラウドネイティブ）にする必要はありません。荷物を運ぶだけなら軽トラック（リホスト）で十分ですし、それが経済合理性です。しかし、F1レースに勝つためのレーシングカー（AI基盤）にだけは、どうか投資してください。軽トラックでは、市場競争というレースには勝てません」
この“メリハリのある投資戦略”は、経営層にとって非常に合理的で納得感のあるものでした。CAFというフレームワークと、わかりやすい比喩が、経営と現場の共通言語として機能した最初の瞬間でした。
「準備」フェーズでの決断――統制と自由のバランス
戦略の合意が取れ、いざAzure環境の設計に入ると、次はセキュリティー部門と開発部門の間で戦争が勃発しました。
セキュリティー部門の主張は正論でした。「クラウドはインターネットにつながっていて危険だ。すべての通信を監視し、開発者が勝手にリソースを作れないよう、申請承認フローを厳格化すべきだ」――。彼らは、オンプレミス時代と同じ「境界型防御」と「Excel申請書による管理」をクラウドにも持ち込もうとしました。
これに対し、開発現場は猛反発しました。
「サーバー1台立てるのに、また3日も待たされるんですか？アジャイル開発なんて夢のまた夢だ。AWSを使っている競合他社は数分でデプロイしているのに！」
「安全性」か「スピード」か。これもまた、多くの企業が直面するトレードオフです。
ここでCCoEが導入したのが、「Azureランディングゾーン」の考え方です。特に「サブスクリプションの民主化」と「Policy as Code（ポリシーによる統制）」でした。
CCoEは、膠着した会議で次のような解決策を提示しました。
- ①箱（サブスクリプション）を配る
-
開発チームごとに専用の「サブスクリプション（リソースを入れる箱）」を払い出し、その中では自由に管理者権限（Owner）を与えました。これにより、開発者は誰の承認も待つことなく、自由にリソースを作成・削除できるようになり、待ち時間は「ゼロ」になりました。
- ②ガードレールを設置する
-
ただし、自由には責任が伴います。CCoEは人間による監視の代わりに、Azure Policyを使って、その箱に強力なシステム的「ガードレール」をかけました。
- 日本リージョン以外へのデプロイ禁止（データ主権の保護）
- 高価なGPUシリーズの無断利用禁止（コスト超過防止）
- インターネットへの直接公開（Public IP）禁止（セキュリティー事故防止）
もし開発者が、誤ってインターネットに全公開する設定を行おうとすると、Azure Policyが即座に検知し、デプロイ自体をブロックします。「申請書で止める」のではなく、「システム的に、物理的に止める」仕組みに変えたのです。
「人間がチェックするより、機械が止めてくれるなら、事故は起きようがないな」
セキュリティー担当者は、Azure Policyのデモを見て、渋々ながらも納得しました（経験上、このセキュリティー担当者の壁が最も高いのものです）。「これなら、上司のハンコを待たずに、好きなときに試行錯誤ができる」――。開発者もまた、手に入れた自由に満足しました。
この「ガードレール付きの自由」こそが、A社がAI Readyな開発スピードを生み出す源泉となりました。もしこのとき、従来のガチガチな統制を選んでいたら、後のAI導入プロジェクトは手続きの山に埋もれて頓挫していたでしょう。
こうして、戦略の合意と、自由に動けるクラウド基盤（ランディングゾーン）が整いました。しかし、“器”はできても、肝心の中身＝「データ」はまだバラバラのままでした。次回は、AIの燃料となるデータをどのように統合し、最初の成功体験（Quick Win）をつかみ取ったかを解説します。
（書籍『CAFではじめるAzureクラウド導入＆運用ガイド AI Ready実現の最適解』を基に再構成）
［日経クロステック 2026年3月17日付の記事を転載・改題］
田中健司、木幡健文（著）／日経BP／3300円（税込み）