本特集では、「AI Readyのためのクラウド導入」を提唱します。AIを動かすための土台づくりを体系的に実践するための指針を示します。その中核にあるのが、「Cloud Adoption Framework（CAF：クラウド導入フレームワーク）」です。CAFは海外を中心に数万件以上のクラウド導入プロジェクトで実際に使われ、成功事例・失敗事例から学んだ“実証済みのガイダンス”であることが大きな特徴です。CAFはMicrosoft、AWS、Google、Oracleなどのクラウドサービス提供事業者で採用されているクラウド導入のベストプラクティスです。書籍『CAFではじめるAzureクラウド導入＆運用ガイド AI Ready実現の最適解』（日経BP）から抜粋し、著者が実際に支援した企業の実話に基づくエピソード（数社の事例を組み合わせたフィクション）を紹介します。その第1回。
「我が社も来期から全社的に生成AIを活用し、業務効率を飛躍的に向上させる。IT部門は、そのための基盤を早急に用意してほしい」
ある月曜日の経営会議。CEOが放ったこの鶴の一声から、すべては始まりました。会議室のプロジェクターには「AIによるDX（デジタルトランスフォーメーション）革命」という華々しいスライドが映し出されていましたが、その場に同席していたIT部門長の背中には、冷や汗が流れていました。なぜなら、彼は知っていたからです。経営層が見ている“美しい未来”と、現場のエンジニアが日々格闘している“泥臭い現実”の間には、グランドキャニオンのような深い断絶があることを……。
これは、著者が実際に支援したある企業（以下、A社）の実話に基づくエピソードです。本特集では、A社の実話とほか数社の事例を組み合わせたフィクションを、理解を深めるためのケーススタディーとして紹介します。
創業30年を超える伝統企業であるA社は、対外的には「DX先進企業」としてクラウド移行を積極的にPRしていました。しかし、その蓋を開けてみると、実態は「AI Ready」とは程遠い、まさに「混沌（カオス）」と呼ぶにふさわしい状態でした。プロジェクト発足前夜、私たちが直面したのは、Cloud Adoption Framework（CAF）が警告する典型的なアンチパターンの博覧会だったのです。
「なんちゃってクラウド」の代償――リホストの罠（わな）
A社は3年前に「クラウドファースト」を宣言し、オンプレミスのサーバー群をパブリッククラウド（AzureおよびAWS）へと移行していました。しかし、その手法は戦略なき「リホスト（Lift＆Shift）」でした。つまり、オンプレミスの設計思想や運用ルールはそのままに、単に仮想マシン（IaaS）という“場所”だけをクラウドに移したものだったのです。
その結果、何が起きていたか。第一に、「コストの肥大化」です。クラウドの最大の利点である「オートスケーリング（自動伸縮）」や「PaaS（Platform as a Service）」を活用しない設計のため、アクセスが少ない夜間や休日であっても、最大スペックのサーバーが24時間365日課金され続けていました。
第二に、「シャドーITの横行」です。IT部門の承認スピードが遅すぎるため、各事業部がクレジットカードで勝手にSaaSやクラウド環境を契約していました。経理部門には毎月、謎のクラウド利用料の請求書が届き、「これは誰が使っているのか？」という犯人探しに膨大な工数が割かれていました。
経営層は「クラウドにすれば安くなり、速くなるはずだ」と信じていました。しかし現実は、オンプレミス時代よりもコストが増加し、管理不能なブラックボックスがクラウド上に増殖していたのです。
AIを拒絶する「データのサイロ化」と「Excelバケツリレー」
CEOの号令を受け、企画部門は勇み足で「AIによる売上予測」や「顧客対応自動化」のPoC（概念実証）に着手しました。しかし、開始からわずか2週間で、プロジェクトは暗礁に乗り上げました。「データがつながらない」のです。
- 営業部：顧客データはSaaS型のCRM（顧客管理システム）にある。
- 製造部：工場の稼働データは、工場内の閉じたオンプレミスサーバーにある。
- 経理部：売上データは、老朽化したERP（基幹業務システム）の中に塩漬けになっている。
それぞれのデータは連携されておらず、「各担当者がCSVで吐き出し、メールで送り合い、Excelで手加工して統合する」という、いわば“デジタル時代のバケツリレー”でかろうじてつながっていました。AIに学習させるためのデータセットを用意するだけで数週間を要し、苦労して集めたデータも、部署ごとに定義（カラム名や単位、更新頻度）がバラバラ。これでは、どんなに高性能なLLM（大規模言語モデル）を導入しても、まともな答えが返ってくるはずがありません。
「データレイヤー」の欠如が、AIプロジェクトの出ばなを完全に挫いていました。
「あの人に聞かないとわからない」――属人化の限界
そして最も深刻かつ致命的だったのが、「運用の極度な属人化」です。A社の複雑怪奇なクラウド基盤全体を把握しているのは、初期構築を担当したエースエンジニアのB氏と、協力会社の特定の担当者だけでした。ドキュメントは数年前から更新されておらず、セキュリティーグループの設定やネットワーク構成の変更手順は、すべてB氏の頭の中にしかありません。
「AI用のGPUサーバーを立てたい」「外部データ連携のためにネットワークポートを開放したい」――。こうしたDX推進のための要望が出るたびに、すべての作業依頼がB氏に集中します。しかし、B氏は既存システムのトラブル対応や日々の運用業務で手いっぱいです。その結果、AIプロジェクトのインフラ手配は「数カ月待ち」というボトルネックが発生していました。
もしB氏が明日、病気で倒れたり退職したりしたらどうなるか。A社のIT基盤は瞬時にコントロールを失い、二度と変更できなくなる……。そんな「事業継続リスク」と隣り合わせの状態だったのです。
CCoEという「解」への気づき
「このままでは、AI導入どころか、会社のシステム基盤そのものが崩壊する」
この危機感を共有したのは、IT部門長と、経営企画部の若手リーダーでした。彼らは現場の惨状を目の当たりにし、重要な事実に気づきました。これは「新しいAIツールを買ってくれば解決する問題」ではない。「必要なのは高性能なツールではなく、バラバラになったデータ・組織・ルールをつなぎ直し、交通整理を行うための“機能”と“横断組織”である」と。
そこで彼らが起案したのが、「Cloud Center of Excellence（CCoE）」の立ち上げです。しかし、設立への道のりは平たんではありませんでした。
「これ以上、会議を増やすつもりか？」「ITインフラの話なら、情シスだけで勝手にやってくれ」――。事業部からは冷ややかな反応が返ってきました。経営層からは「そのCCoEとやらを作れば、いくらもうかるんだ？」という、ROI（投資対効果）への厳しい問いが投げかけられました。
それでも、発起人たちは諦めませんでした。
「AIを動かすためには、今の“縦割り”と“属人化”を解消しなければなりません。これはITの問題ではなく、経営の死活問題なのです」
彼らは粘り強く経営層への説得を続けました。その結果、IT部門（インフラ・アプリ）、セキュリティ部門、経営企画、そして事業部の代表者数名からなる、A社初の「組織横断型クラウド推進チーム（CCoE）」が発足しました。それは半ば強引なスタートでしたが、メンバーの目には確固たる意志が宿っていました。
彼らが最初に武器として手に取ったのが、Microsoftが提供する「Cloud Adoption Framework （CAF）」でした。カオス状態のA社を、CAFという羅針盤を使ってどう立て直し、AI Readyな企業へと変革させていくのか――。その泥臭くもリアルな闘いの記録を次回で紹介します。
（書籍『CAFではじめるAzureクラウド導入＆運用ガイド AI Ready実現の最適解』を基に再構成）
［日経クロステック 2026年3月16日付の記事を転載・改題］
田中健司、木幡健文（著）／日経BP／3300円（税込み）