Google Cloud AI調査、既存ソフトウェアが近代化を停滞させていると判明
Google Cloudは11月9日、調査対象となった意思決定者の49%が、オンプレミスのソフトウェアを技術施策の遅延または縮小と結び付けていることを示す調査結果を発表した。こうした施策にはAIも含まれるが、この結果はAIプロジェクトのみを切り分けたものではない。Google Cloud AI調査は、既存業務の維持と新たな能力の構築が競合するという、企業にとって身近な対立を具体的な数字で示している。
Hypothesis Groupと実施されたこの調査では、米国のエンタープライズIT部門および事業部門の意思決定者1,250人を対象とした。Googleはこの結果を、より幅広いアーキテクチャの選択肢と、既存プロバイダーへの依存低減を訴える根拠としている。その中心的な懸念は理解できる。連続したアクションを通じてタスクを遂行できるソフトウェアであるAIエージェントは、アクセスするシステムの制約を引き継ぐためだ。
Microsoftは有用な比較対象となる。同社の調査は、インフラの置き換えを中心的な解決策と捉えるのではなく、従業員による導入と並んで組織の準備状況を重視している。両者に共通する緊張関係は、AIへのアクセスを拡大することと、業務プロセスをAIに対応可能な状態にすることの間にある。技術リーダーにとっては、議論の焦点が統合、運用責任、そして新たな支出が本当に希少なエンジニアリング能力を解放するのかどうかへ移ることを意味する。
Google Cloud AI調査が実際に測定したもの
この調査は、特定の近代化戦略が制約を解消することを実証するものではなく、意思決定者が報告した制約を測定している。
Google Cloudのリスク・コンプライアンス責任者であるJeanette Manfraは、レガシーソフトウェア調査の発表でこの結果を紹介した。付随するレポートの日付は2026年10月であり、調査手法によればフィールドワークは8月に実施された。したがって、この公開は11月時点の導入状況をリアルタイムで測定したものではなく、以前に収集された経験についての最近の報告を提供するものだ。
解釈を左右する重要な定義がある。この調査では、ローカルでホストまたはオンプレミスで運用されるエンタープライズソフトウェアを、クラウドでホスト・管理されるソフトウェアと対比し、レガシーと分類している。この定義は、デプロイメントおよび管理の形態に関するものだ。読者は、対象となるすべてのシステムが時代遅れ、サポート対象外、あるいはAIに技術的に不適切であると想定すべきではない。
この区別が重要なのは、設置場所と状態が異なる問いに答えるからである。ローカルで運用されるアプリケーションでも、明確なインターフェースと規律ある保守を備えていることはある。クラウドアプリケーションでも、分かりにくいレコード、一貫性のない権限、密結合した業務ルールを抱えている可能性がある。いずれの観察も回答者の経験と矛盾しないが、どちらも買い手が導くべき結論を限定する。
報告された49%も、遅延、スコープ縮小、中断、キャンセルという複数の結果をまとめている。これらは異なる程度の混乱を表す。一時的なスケジュール調整は、プロジェクトを断念することと同じ事業上の影響を持たない。同様に、他の技術施策も含まれているため、この結果をAIキャンセル率とみなすことはできない。
ただし、この留保によって意味のある発見が損なわれるわけではない。回答者は、既存のソフトウェア環境を計画的な変化への障壁と関連付けている。エンタープライズの買い手にとって、これは評価中のAI製品と並行して周辺環境にも注意を向けるべき証拠となる。
ただし、調査回答だけでは責任の連鎖全体を確立することはできない。停滞した施策には、アプリケーションの制約、調達上の制限、専門知識の不足、競合する優先順位、不明確なビジネスケースなどが関与している可能性がある。同一プロジェクトの中で複数の原因が共存することもある。
したがって、Google Cloud AI調査は、認識されている組織的摩擦の診断として最も有用である。これはリーダーに、自社の依存関係を調査する理由を与える。しかし、どのアプリケーションを置き換えるべきか、どのプロバイダーを選ぶべきか、あるいは特定の導入に先立って移行すべきかを示すものではない。
この違いは、有用な調査シグナルと過度に広範な購買結論を分ける。次の問いは、誰がその摩擦を解消しなければならないのか、そして彼らが本来ならどのような業務をしているのかである。
保守の負担はAIを提供すると期待されるチームに及ぶ
直接的な負担は、運用継続と新たなAI提供の両方に責任を持つチームにかかる。
経営層がAIの期限を設定したからといって、エンジニアリング組織は既存の業務負荷を任意のものとして扱うことはできない。セキュリティ修正、アクセス変更、インシデント対応、アプリケーションサポートは、引き続き必要である。追加の目標を割り当てても、それを達成するのに必要な能力が自動的に生まれるわけではない。
これは、人員数だけでは見えにくい予算上の問題を生む。チームが十分な人員を抱えているように見えても、専門家がその固有の知識を必要とするシステムに拘束されている可能性がある。重要な制約は、総従業員数ではなく、提供期間中に利用可能な専門知識であることが多い。
たとえば、従業員のアカウント問題解決を支援する社内サービスエージェントを考えてみよう。もっともらしい回答を生成することは、任務の一部に過ぎない。周囲のプロセスでは、従業員を特定し、許可されたアクセスを確立し、最新情報を取得し、例外を責任者に振り分ける必要がある。
エージェントがアカウントを変更できる場合、組織には承認ルールとそのアクションの記録も必要となる。効果的なデモでは、この運用作業の大部分を避けられる。だが本番サービスは、後から誰かがすべての異常ケースを手作業で修正することに依存できない。
こうした要求は、開発チームとセキュリティチームが異なる方向から圧力を受ける理由を説明する。事業リーダーは目に見える進捗を求める。運用チームは可用性を維持しなければならない。セキュリティ審査担当者はアクセスを承認するために十分な証拠を必要とする。明確な優先順位がなければ、統合作業はこれらのグループの間で誰にも所有されない依存関係になり得る。
保守は順序付けにも影響する。アプリケーションの置き換えは、最終的にはサポート負担を減らすかもしれないが、その効果が現れる前に相当な作業を要する。移行期間中、チームは置き換え先を学びながら既存プロセスを支援する必要があるかもしれない。そのため、近代化の提案には一時的な業務負荷の説明が必要となる。
ここで、エンジニアを解放するという広範な約束は検証に値する。問うべきなのは、どの反復的な業務がなくなり、誰が現在それを担い、いつその人たちが利用可能になるのかである。責任をプロバイダーに移すことは役立つ場合があるが、残る統合・監督作業にも依然として所有者が必要だ。
調達チームも関連する課題に直面する。製品を導入する利便性と、それを運用するための労力を区別しなければならない。馴染みのある契約は購買を簡素化できても、データアクセスの問題を解決するとは限らない。馴染みのないプロバイダーは魅力的な機能を提供する一方で、別の一連の運用責任を追加する可能性がある。
ナレッジワーカーにとって、その結果は利用可能性のばらつきとして現れる。アシスタントは文書を問題なく要約できても、重要な判断に必要な記録を利用できないことがある。その結果、目に見えるAIインターフェースは、その背後のワークフローよりも速く進展する。
したがって、この圧力は技術的であると同時に組織的でもある。リーダーシップは、どの依存関係に投資する価値があるのか、どの提案プロジェクトを待たせるべきかを決めなければならない。そうしなければ、新しいパイロットは、前任の施策を遅らせた条件を変えないまま、同じ人材を奪い合うことになる。
エージェントを追加しても、その下にある作業はなくならない
アクションには提案よりも明確な境界が必要であるため、自動化は信頼できる業務インターフェースの重要性を高める。
Googleの主張は、ソフトウェアの配置場所だけに当てはめるよりも、特定のワークフローに適用したときの方が説得力を持つ。助言を生成するシステムは、実行を人に委ねられる。行動を認可されたシステムは、組織が明示したルールに直面しなければならない。
例として、購買依頼を考えてみよう。従業員はエージェントに対し、承認済みのサプライヤーを使って発注を準備するよう依頼するかもしれない。言語処理のタスクは簡単に説明できる。業務上のタスクには、権限の確認、正しい勘定の選択、購買ポリシーの適用、在庫のない品目への対応が含まれる。
各段階では、流暢なテキストだけでは独立して解決できない問いが生じる。どの記録が正本なのか。依頼者には権限があるのか。提案された購入はポリシーの範囲内か。注文は成功したが確認が失敗した場合、何が起こるのか。
これらの問いは、回答を生成することと取引を完了することの違いを浮き彫りにする。組織は、部分的な完了を含め、自社システム内で何が起きたのかを把握する必要がある。自信に満ちた会話型の応答は、その証拠の代わりにはならない。
既存アプリケーションには、従業員が文書ではなく経験を通じて理解しているルールが組み込まれている場合がある。エージェントの導入は、その暗黙知を露呈させることがある。統合の問題に見えるものが、実際にはポリシー、例外、責任に関する未解決の判断を含んでいるかもしれない。
アプリケーションを置き換えても、こうした判断が必ず解決するわけではない。表現するためのより良い場所を作れる可能性はあるが、意図された振る舞いは依然として誰かが決めなければならない。だからこそ、近代化の提案は、基盤ソフトウェアの古さに頼るのではなく、改善する業務上の境界を特定すべきである。
Google自身のカスタマーサービス導入に関する説明は、具体例を提供している。2025年4月、同社はWendy’s FreshAIがドライブスルーの注文を処理し、24州へ展開していると説明した。これらは企業が報告した導入上の主張であり、一般的なエージェントの信頼性を独立して証明するものではない。
それでもこの例は、定義されたタスクの価値を示している。食品の注文には認識可能な入力、メニュー上の制約、そして店舗運営へ到達しなければならない取引がある。その有用性は、会話品質だけでなく、実際のサービスプロセスとの接続に依存する。
社内のエンタープライズワークフローにも、境界が見えにくい場合であっても、同程度の明確さが必要である。契約の調査、更新の準備、アクセス問題の解決といった依頼には、合意された到達点が必要だ。そうでなければ、下流の従業員が実質的な作業をなお完了しているにもかかわらず、エージェントがテキストを生成した時点でチームが成功を宣言することになり得る。
これにより、統合は説明責任の問題となる。誰かが、推奨から承認済みのアクションへの移行と、アクションから検証済みの結果への移行を担わなければならない。この所有権がなければ、自動化は労力を再配分しても、業務プロセスを大きく変えないままに終わる可能性がある。
最も強力な近代化のケースは、こうした移行を特定し、それが改善されることを実証する。その証拠は、未解決の引き継ぎが減り、確実な完了が得られ、問題が発生した場合にも管理可能な復旧ができることを示すべきである。
GoogleとMicrosoftは準備態勢への異なる道筋を重視する
両ベンダーは重点の置き方こそ異なるが、いずれも有用なAI導入において組織的な準備を中心的要素としている。
Googleの立場では、アーキテクチャの自由度が重要な役割を占める。Microsoftの組織におけるAI準備態勢に関する調査は、マネジメント、業務設計、評価をより重視している。同社の2026年5月のレポートは、10市場でAIを利用する2万人の従業員を対象とした調査に基づいている。
Microsoftは、組織的な条件が、回答者がAIから得ていると報告する価値と強く関連していると述べている。その方法論では、統計的関連と因果関係を明確に区別している。この慎重さはGoogleの説明と比較する際に重要であり、いずれの調査も、導入を成功させるための普遍的な処方箋を確立しているわけではない。
この比較は、異なる商業的立場も反映している。Googleには、購入者に既存のエンタープライズ関係を見直すよう促すインセンティブがある。Microsoftには、既存の職場環境をAIにとって生産的な場にするインセンティブがある。こうしたインセンティブは、どちらの企業の調査結果も自動的に無効化することなく、その強調点を説明する助けになる。
購入者にとって、この選択には実務上のトレードオフが伴う。確立済みの環境を拡張すれば、使い慣れた管理を維持し、移行作業の一部を減らせる可能性がある。代替手段を導入すれば、交渉上の選択肢を増やしたり、特定のワークフロー要件を満たしたりできる。どちらの道を選んでも、組織が統合の評価を省けば期待を裏切る可能性がある。
したがってGoogle Cloud AI調査は、既存ベンダーを自動的に退けるのではなく、依存関係を精査する契機となるべきだ。コンポーネントの変更が許容できない混乱を招く場合、不可欠な情報を失う場合、または企業が独立して業務を遂行できなくなる場合、依存は重大な意味を持つ。
この懸念は、既存プロバイダーと同じように新規プロバイダーにも当てはまる。企業は、よく知る制約を、あまり知らない制約に置き換えることがある。契約が異なるからといって、それ自体でより大きな自由が確立されるわけではない。
意味のある選択には、運用上の証拠が必要だ。購入者は、記録が製品の外でも利用可能か、権限を再構築できるか、完了済みの作業を引き続き検証できるかを理解する必要がある。こうした問いは、メニューで選べるモデル名の数よりも多くを明らかにする。
AIモデルを選ぶことと、ワークフロープラットフォームを置き換えることにも違いがある。モデルは情報を生成または解釈する。プラットフォームは、指示、接続、記録、承認履歴を保持できる。前者の変更は比較的限定的で済むかもしれないが、後者の変更はプロセス全体に影響する。
このため、調達に関する議論はより厳格になる。購入者は、継続する義務や退出条件を含め、業務上の取り決め全体を評価すべきだ。便利なデモンストレーションから得られる知見は、重要な接続が切断された場合や事業部門がプロセスを変更した場合に何が起きるかについては限られている。
ナレッジマネジメントは、より小規模な類似例を示す。検索可能なナレッジベースは、人々が文脈の中で関連資料を取得できるときに役立つ。エンタープライズ自動化には、取得した情報が組織的な影響を伴う行動に影響し得るため、さらに多くの要件が加わる。
したがってGoogleとMicrosoftの最も重要な比較は、それぞれが提案する環境が実際の業務をどのように支えるかにある。ブランドの好みは、競合するアプローチ間で同じプロセス、権限、受け入れ基準を検証することの弱い代替手段にすぎない。
この調査は、重要な因果関係とセキュリティに関する問いを残している
報告された保守上の摩擦は調査の根拠となるが、クラウド移行がすべてのワークロードでより良い成果をもたらすことを確立するものではない。
付随するエンタープライズ準備度レポートは、定性インタビューで補完された20分間のオンライン調査について説明している。米国の意思決定者を対象としたサンプルは、明確に定義された視点を提供する。読者は、他地域の企業や、購買およびテクノロジー部門のリーダー以外の従業員について論じる際、この範囲を踏まえるべきだ。
レポートによれば、回答者の78%はテクノロジー保守がAIからリソースを逸らしていると考え、48%は自社のスタックが大規模導入の準備を整えているとみなしている。これらは能力と準備度に関する評価である。移行後に回復したエンジニアリング時間を直接測定したものではない。
回答者は不満を正確に表現できても、最善の解決策を特定しているとは限らない。サポート要求に苦しむチームは、置き換え、より良い設定、追加の専門知識、またはより限定的なAIの適用範囲から恩恵を得られる可能性がある。どの対応を選ぶかには、影響を受ける環境からの証拠が必要となる。
商業的スポンサーシップも同じ理由で注目に値する。Googleは、同社が提案する方向性に沿ったサービスを販売している。適切な対応は、定義を検討し代替案を比較する一方、精査に耐える有用な知見を保持することだ。
調査における導入形態に基づく定義は、特に重要である。ローカル管理ソフトウェアをレガシーとして扱うことで、クラウドとの比較が当初から中心に置かれる。購入者には、保守性、セキュリティ、統合の品質、事業適合性について、なお別途の評価が必要だ。
セキュリティは、単純な移行の物語にもう一つの限界をもたらす。マネージドサービスは、インフラ保守を担当する主体を変えることができる。しかし、エージェントがどの情報にアクセスできるか、どの行動にレビューが必要かを決める必要性までは取り除かない。
Gartnerのエージェントガバナンス・フレームワークは、この違いを扱っている。アナリストのShiva Varmaは、画一的な統制は単純なエージェントを過度に制限する一方、より自律的なエージェントには制限が不十分になり得ると論じる。このフレームワークは、観察、助言、承認を要する行動を区別する。
この視点は、自律性を高めることが常に進歩を意味するという前提を複雑にする。推奨事項の作成に限定されたエージェントが、重要なワークフローに適している場合もある。承認を求めることは、その価値が行動と潜在的な影響に左右される設計判断である。
したがって慎重なエンタープライズ購入者は、インフラの改善と認可の改善を区別すべきだ。より良いホスティングは、可用性と保守性を支えられる。より良い認可は、システムに許可される行動を定義する。どちらにも注意を払う価値があり、一方が他方の代わりになるべきではない。
Google Cloud AI調査は、これらの投資間のバランスを解決しない。リーダーが検討できる、認識された制約を特定している。分析上の誤りは、このシグナルを、一つのアーキテクチャ、ベンダー、または自律性の水準が本質的に望ましいという証拠に変換することだ。
導入後には、さらに測定上の問題がある。従業員は作業開始に費やす時間を減らす一方、不確かな結果を確認する時間を増やすかもしれない。生産性に関する主張は、サポートや復旧と併せて、そのレビュー作業を考慮する必要がある。そうしなければ、見かけ上の自動化が、別のチームに移された作業を隠す可能性がある。
完了したワークフロー、切り替えの証拠、復旧を注視する
次に有用となる証拠は、モダナイゼーションの意思決定を、購入者が検証できる運用結果と結び付けるものだ。
今後数か月で最初に注視すべきシグナルは、完了したワークフローについての顧客報告である。有用な開示は、デモンストレーションと反復的な利用を区別し、何を成功した完了と数えるのかを説明する。また、人間の介入が引き続き必要な箇所も明らかにすべきだ。
モダナイゼーションが特定可能な制約を取り除き、再現可能な運用改善を生むなら、この証拠はGoogleの主張を強める。基盤環境を置き換えたにもかかわらず、プロジェクトがなお広範な手動修復を要するなら、広範な移行の主張は弱まるだろう。
プロセスが許容できないエラーを生む場合、完了だけでは不十分である。購入者には、正確性と例外を解決するために必要な労力に関する証拠が必要だ。迅速に完了しながら下流での紛争を生むワークフローは、問題を解決したのではなく移動させたにすぎない。
二つ目のシグナルは、実証された切り替えである。顧客が、稼働中のプロセスがコンポーネント変更を経ても維持されることを示す場合、コネクターやモデル選択に関する製品発表はより詳しく検討する価値がある。権限、評価基準、利用可能な記録が維持されれば、柔軟性の意味ある証拠となる。
広範な再構築を要する切り替えは、異なる実態を示す。名目上の選択肢が、大きな運用上の依存と並存していることを示唆する。この違いは、購入者が確立済みの職場プラットフォームと代替のエージェント環境を比較する際に重要となる。
三つ目のシグナルは、制御された障害下での復旧である。顧客の説明や技術評価では、アクセス権が失効した場合、接続先アプリケーションが利用不能になった場合、または行動が部分的にしか完了しなかった場合に何が起きるかを説明すべきだ。復旧の証拠は、好条件のデモンストレーションを超えたシステムの振る舞いを明らかにする。
明確な責任分担は、信頼を強める。一つのチームが、最後に検証された状態を特定し、どの行動が起きたかを判断し、作業をどのように再開するかを決められるべきだ。こうした答えを毎回非公式な調査で探さなければならないなら、運用負荷は未解決のままである。
これらのシグナルは、インフラ上の制約とプロセス上の制約を分ける助けにもなる。接続の失敗は技術的な依存関係を示す可能性がある。未解決の承認紛争はガバナンスを示す。どちらも提供を阻害し得るが、必要となる対応は異なる。
Google Cloud AI調査は、エンタープライズのリーダーに対し、エンジニアリング能力がどこに費やされているのかを検討する理由を与える。その知見が最も価値を持つのは、特定のサービス、その依存関係、それを有用な状態に保つ責任者に関する問いへと翻訳されたときである。
AI投資を計画する読者は、アシスタントの応答の先にある業務を追うべきだ。どの事業成果が実現しなければならないのか、どの記録が完了を証明するのか、誰が例外を処理するのかを問う。移行の労力と継続的なレビューを含め、同じ成果に照らして提案を比較する。既存プラットフォームと代替案を評価する際には、受け入れ基準を一貫させる。保守削減に関する主張には、なくなるタスクと維持される責任を明示するよう求める。そのうえで、通常業務および制御された障害の際にもその変化が持続することを示す顧客の証拠を探す。現在、あなたのチームが価値ある業務を完了することを妨げている依存関係は何であり、提案された投資がそれを実際に取り除くことを示す証拠は何だろうか。
