Amazon Web Services ブログ
AI ネイティブになりたかったのに、手に入れたのはお粗末な基盤だけ
本記事は 2026 年 5 月 7 日 に公開された「You Wanted to Become AI-Native, and All You Got Was a Lousy Foundation」を翻訳したものです。
実装は、本当に必要になったときに行うべきであり、いずれ必要になりそうだと予測しただけの段階で行ってはならない。
— エクストリームプログラミング (XP) の共同創始者 Ron Jeffries
最近支援したある大企業では、取締役会が最高デジタルトランスフォーメーション責任者に対し、イノベーション、成長、コスト効率を推進する AI 導入戦略の策定を求めました。彼が選んだコンサルタントは、関係者へのインタビューを実施したうえで、3.5 年にわたる 3 つのフェーズからなるプログラムを提案しました。
- フェーズ 1: デジタルの基礎を整え、未完のデジタルトランスフォーメーションが残した人材・プロセス・技術のギャップを解消する。
- フェーズ 2: ガバナンス、ツール、プラットフォーム、AI オフィスを含む AI 基盤を構築する。
- フェーズ 3: 顧客に届く可能性が最も高い AI およびエージェント型のビジネス施策を導入する。
一貫性があり、効率的な実行を重視したプログラムでした。しかし、取締役会が求めていたものではありませんでした。彼らが求めていたのは、IT 製品の実装にかかる時間が大幅に短くなった環境で、自社の革新性と競争力を高める戦略です。ところが提案されたのは、実際のビジネス価値を生み出す前に予算の大半を費やしてしまう、基礎を立て直すだけのプロジェクトでした。
コンサルタントの慎重な提案には合理性がありました。2025 年 DORA レポートは「AI は増幅器である」と述べています。AI は、成果を上げている組織の強みも、苦戦している組織の機能不全も、ともに増幅させます。ビジネス成果の目標を達成または上回るデジタル施策は半数に満たず、多くの大企業は取締役会や競合からのプレッシャーを受けながら、その未完の作業を抱えたまま AI プログラムに突入しています。
基盤が不完全だと自覚している企業が、AI によって何が増幅されるのかを不安に思うのは当然です。まず基礎を立て直すのは、責任ある選択のように感じられます。しかし、それを第一の目標や出発点にすべきではありません。
基盤優先のアプローチが必ず失敗する理由
ユースケースが定まらないうちに基盤を構築するのは、投機的な取り組みです。すべての設計判断は実際のワークロードがない状態で下され、すべてのガバナンスモデルはまだ動いていないプロセスを前提に設計されます。
Martin Fowler は、こうしたパターンに名前を付けました。ソフトウェア設計に関する代表的な著作で、彼はこれを投機的な一般化 (speculative generality) と呼びました。「いつか必要になるはず」という思い込みから、「今は必要のないもの」のためにインフラやフックを追加してしまう習慣のことです。コードレベルでは広く知られたアンチパターンですが、プログラムレベルでは、数年にわたる数百万ドル規模のコミットメントになります。
Standish Group の CHAOS レポートは、アジャイルで反復的な開発が逐次的な開発を大きく上回ることを一貫して示しています。2020 年の CHAOS レポートによれば、反復型プログラムの成功率は逐次型の 3 倍です。この差は規模が大きくなるほど顕著に広がります。2015 年の CHAOS レポートでは、大規模な反復型プログラムは、同等の逐次型プログラムに比べて成功率が 6 倍高いことがわかりました。
実際のユースケースがないまま基盤を構築するチームが、正しいものを作れることはまずありません。本物のユースケースが現れると、基盤の手直しに追われます。手直しが終わるころには、AI ツールの世界はすでに一変しています。
基盤優先の道を選んだ企業は、たいてい次の 3 つを抱え込むことになります。(1) すでに当てはまらなくなった要件向けに設計された高価なプラットフォーム、(2) 目に見える成果のないまま予算が消えていくのを眺めてきた、不満を抱えた取締役会、(3) 何年もの間、顧客にイノベーションを届けてこなかった組織です。
基盤は必要です。ただし、特定のユースケースに合わせて作る基盤だけが機能します。
基盤は後からついてくる
AI から実際のリターンを得ている組織は、特定の重要な顧客課題から着手します。そして、その課題を解決していく過程で、将来の施策を支える基盤を築いていきます。
バックログの中で、戦略的に最も重要な施策を1つ選ぶ。それを実装し、ビジネスへの実際の効果を測定します。基盤は、その施策に必要な範囲だけを進めながら構築します。そして成果を取締役会に持ち込む。進捗報告ではなく、何を変えたのか、顧客にどんな変化が起きたのかを具体的に見せるのです。
成果を1つ届ければ、チームは「この進め方で間違いない」と確信できます。そこからアプローチを反復する。次の施策では、前の施策で検証済みの基盤をそのまま使い、足りない部分だけを足していきます。
組織文化の習慣を乗り越える
このアプローチは、オペレーショナルエクセレンスで実績を積んだ組織ほど抵抗が大きくなります。基盤をさらに作り込むことと顧客に価値を届けることのトレードオフに直面したとき、チームは基盤づくりへと引き寄せられがちです。各プログラムの開始時に明確な原則を定めておくと、チームは顧客への提供に意識を向け続けられます。指針としては、認識を揃え意思決定を加速させる、記憶に残り実行に移せる原則の書き方について述べた Stephen Brozowich の記事が参考になります。
組織はそれぞれ独自の原則を策定すべきですが、次の 4 つは良い出発点になります。
- 網羅性より集中。完全な基盤を作ることが目標ではありません。適切な顧客に適切な成果を届けることが目標です。
- 要件より顧客。要件は何を求められたかを教えてくれます。顧客は何が実際に機能するかを教えてくれます。
- 効率より効果。効率は既知のシステムを最適化します。効果は、そもそも正しいものを作っているかどうかを見極めます。
- 投機よりリーン。今の施策に必要なものだけを作りましょう。施策の一つひとつが、ガバナンスが効きアーキテクチャ的に実証されたコンポーネントを、次の施策が引き継ぐ基盤へと積み上げていきます。
取締役会は、AI のための完璧な基盤を待っているわけではありません。求めているのは、顧客が体験でき、中核となるビジネス KPI を改善する成果です。
参考資料
- McKinsey. The State of AI 2025. 105 か国 1,993 組織を対象に、AI の導入状況と影響を調査した年次調査。
- Gartner. Gartner Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets. 3,100 名を超える CIO・技術担当役員と、IT 部門以外の 1,100 名を超える経営幹部を対象とした年次のグローバル調査。
- Google Cloud DORA. 2025 State of AI-Assisted Software Development. AI がソフトウェア開発における組織の強みと機能不全をどのように増幅するかを扱った調査。
- Martin Fowler. Refactoring (1999 年、第 2 版 2018 年)。
- Fortune/Knowledge at Wharton. The AI Efficiency Trap. 効率だけを追う AI 戦略が、競争優位ではなくコモディティを生み出してしまう理由を探る記事。