先に本稿の結論を示しておく。Google Cloudが2026年7月8日(米国時間)に公表した年次調査レポート「State of Infrastructure in the Agentic AI Era(エージェント型AI時代のインフラの現状)」で、回答組織の83%が「本番水準のエージェント型AIを支えるには、インフラストラクチャのアップグレードが必要だ」と答えた。この数字が経営者に教えてくれるのは、AI活用が止まる場所についての、直感に反する事実だ。多くの会社は「良いモデルを選べばうまくいく」と考えてPoC(概念実証)を始める。しかし本番で詰まるのは、モデルの賢さではない。データがどこにどんな形であるか、誰に何をさせてよいか、何が起きたかを追えるか、いくらかかっているかを把握できるか——つまりデータ基盤・権限・ログ・コスト管理というインフラの側だ。世界のITリーダー1,402人の8割強が「今の足場では本番に耐えない」と認めたのだから、専任情シスのいない中堅・中小企業でこの足場が整っている可能性は、残念ながらさらに低い。
ただし、この83%という数字は正確に扱う必要がある。これは「AIプロジェクトの83%が失敗する」という数字ではないし、「AI導入全般にインフラ刷新が要る」という意味でもない。設問はあくまで**「本番運用グレードのエージェント型AI(自律的に多段階のタスクを実行するAI)を支えるために」**という限定つきであり、回答者は世界のIT部門の上級リーダー1,400人超だ。本稿ではまずこの調査を正確に読み解き、そのうえで「なぜPoCは動くのに本番で止まるのか」という構造を、規模の小さい会社の実情に翻訳する。最後に、PoC本番化の前に自社で確認できるインフラ準備度チェックリストと、ベンダー見積もりから「インフラ整備費」が抜け落ちているときの見抜き方まで踏み込む。ここが本稿でいちばん実用的な部分だ。
なお当サイトでは同日、IPA「DX動向2026」の効率化91.6%・売上向上3.9%という成果の断層を扱った。あちらはDXの成果の質(何のためにやるか)がテーマだが、本稿が扱うのは技術的ボトルネック(なぜ本番に載らないか)であり、引用する統計も論点も別物だ。両方を併せて読むと、「目的の設計」と「足場の整備」という、AI投資でつまずく2大要因が揃って見えるはずだ。
誰がこの記事を読むべきか
- 生成AIのPoCや部門トライアルまでは進んだが、「全社展開」「基幹業務への組み込み」の話になると急に費用感も工期も膨らみ、前に進めなくなっている経営者・役員
- 来期予算でAI投資の枠を組もうとしているが、「モデル利用料」以外に何を積むべきか分からない決裁者
- ベンダーから受け取ったAI開発の見積もりに「環境構築一式」としか書かれておらず、その中身を検証できずにいる発注担当者
- 「AIエージェント」という言葉を提案書で見かける機会が増えたが、従来の生成AI導入と何が違い、何が追加で必要になるのかを判断材料として知りたい人
- 過去に「デモでは動いたのに、自社データにつないだ途端に精度も速度も落ちた」経験があり、その原因を構造として理解したい人
逆に、まだ最初のPoCにも着手していない段階の会社は、本稿のチェックリストを「将来の検収基準」として頭に入れておく使い方が適している。最初の一歩から完璧なインフラを求める必要はない——この点は後述のFAQで詳しく述べる。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
事実整理：Google Cloud調査は何を示したのか
一次情報を確認する。レポートは2026年で2回目となる年次調査で、英語版ブログは2026年7月8日、日本語版ブログは7月15日に公開された。調査対象は世界のITリーダー1,402人(レポート公式ページに明記)。国別・企業規模別の内訳はブログ公表分には明記されておらず、詳細は本体レポート(登録制)に委ねられている。ブログで公表された主要な数字は以下のとおりだ。
横にスクロールして確認できます
| 数字 | 設問・文脈(公表文言ベース) |
|---|---|
| 83% | 本番運用に対応できるエージェント型AIを支えるには、インフラストラクチャのアップグレードが必要だと回答 |
| 62% | データの外向き転送料金・ストレージの肥大化・遊休状態の専用ハードウェアによる多額の「推論税(inference tax)」に直面 |
| 81% | 運用の複雑さを、AIの大規模展開に伴う「隠れたコスト」として指摘 |
| 79% | 推論を大規模展開するうえでの最大の課題として、セキュリティ・ガバナンス・MLOpsを挙げた |
| 78% | 生成AIソリューションを主要クラウドパートナーから直接調達(2025年比で30ポイント増) |
| 52% | ハイブリッドマルチクラウド構成を採用 |
| 48% | 厳格なデータ所在地(データレジデンシー)管理に対応できるインフラを優先 |
| 91% | ハードウェア選定時に消費電力を考慮(うち61%は主要・重要な判断要因と位置づけ) |
読み方の注意を3点添えておく。第一に、**83%の主語は「エージェント型AIを本番水準で動かしたい組織」**だ。エージェント型AIとは、指示に対して一回答を返すだけでなく、複数のシステムを横断して自律的に多段階のタスク(調べる→判断する→実行する)を進めるAIを指す。単発の文章生成やチャットの社内利用だけなら、ここまでのインフラ要求は発生しない。第二に、回答者は上級ITリーダーであり、回答母集団はそもそも専任のIT組織を持つ規模の企業に偏っていると考えるべきだ。第三に、これはクラウドベンダー自身による調査であり、「インフラ投資が必要だ」という結論はGoogle Cloudの事業と利害が一致する。数字自体を疑う必要はないが、処方箋(=クラウド増強)の部分は割り引いて読み、自社に必要な範囲を自分の頭で決める必要がある。
この3点を踏まえてなお、この調査には引用する価値がある。インフラ投資を売りたい側の調査であっても、「モデルではなくインフラが詰まる」という診断の部分は、当社が受託開発の現場で見てきた構造と一致するからだ。次章でその構造を分解する。
なぜモデルではなくインフラで詰まるのか：PoCと本番の4つの断絶
PoCが順調だった会社ほど、本番化の壁に驚く。理由は単純で、PoCは本番で問題になる要素を最初から全部取り除いた環境で行われるからだ。断絶は4つの領域で起きる。
断絶1：データ基盤——「用意された綺麗なデータ」と「散らばった生データ」。 PoCでは、担当者が手作業で選んだ数百件のサンプルデータをAIに読ませる。文字化けもなく、形式も揃い、機密も除外済みだ。ところが本番では、AIがつなぐ先は現実のデータになる。顧客情報は販売管理と営業の個人Excelに二重に存在し、商品コードは事業部ごとに体系が違い、必要な文書はファイルサーバーの深い階層にPDFスキャンで眠っている。エージェント型AIは自分でデータを取りに行って判断するからこそ、参照先のデータが汚れていれば、間違った判断を自動で量産する。調査で62%が挙げた「推論税」——転送料金やストレージ肥大化による想定外のコスト——も、データの置き場所と流れを設計しないままAIを走らせた結果として発生しやすい。
断絶2：権限——「個人のアカウント」と「組織のアクセス制御」。 PoCは推進担当者の個人アカウントで動く。その人が見てよい情報だけを扱うので、権限の問題は表面化しない。本番で全社の業務に組み込んだ瞬間、話が変わる。AIが人事情報も原価も顧客の与信情報も読める状態で全社員の質問に答えるなら、それはアクセス権限の全社的な破壊にほかならない。「経理部員の質問には原価を答えてよいが、営業部員には答えてはならない」を実現するには、社内の権限体系がデータ側に整備されていることが前提になる。多くの中堅・中小企業では、この権限体系そのものが暗黙知(「あのフォルダは触らない空気」)でしか存在しない。調査で79%がセキュリティ・ガバナンス・MLOpsを最大の課題に挙げたのは、大企業ですらこの整備が済んでいないことの表れだ。
断絶3：ログと監視——「失敗しても笑い話」と「説明責任」。 PoCでAIが変な回答をしても、その場で笑って修正すれば済む。本番は違う。AIエージェントが受発注や顧客対応の一部を担うなら、「いつ・誰の指示で・何を参照して・何を実行したか」を後から追跡できなければ、トラブル時に原因究明も顧客への説明もできない。取引先から「この回答はどういう根拠か」と問われて「AIがやったので分かりません」は通らない。ログの記録・保存・検索の仕組みは、モデルには含まれていない。インフラとして別途作るものだ。そしてこれは、監査や取引先のセキュリティチェックシートで今後確実に問われる項目になる。
断絶4：コスト管理——「月数万円の実験」と「従量課金の青天井」。 PoCの費用は定額のAPI利用料か少額の従量課金で、気にする必要がなかった。本番のエージェント型AIは、1つのタスクのために内部で何度も推論を繰り返す。利用者が増え、自動実行が増えれば、コストは利用量に比例して伸びる——しかもどの業務のどの処理にいくらかかっているかを計測する仕組みがなければ、請求書が来るまで分からない。調査で81%が「運用の複雑さ」を隠れたコストと呼んだ背景には、この可視化されない従量課金の膨張があると当社は見ている。コストの計測・上限設定・アラートは、これもモデルの機能ではなくインフラ側の整備項目だ。
まとめると、PoCと本番の間にあるのは技術の谷ではなく、「例外を排除した実験環境」と「例外だらけの現実」の谷であり、その谷を埋める材料がデータ基盤・権限・ログ・コスト管理の4つだ。世界のITリーダーの83%が「今のままでは支えられない」と答えた対象は、まさにこの4領域である。そして規模の小さい会社では、この4領域は「古くなっている」のではなく「そもそも存在しない」ことが多い。だからこそ、PoCの成功を見て「あとは展開するだけ」と判断するのは危険で、展開の前に足場の現在地を確かめる工程が要る。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
経営者のための判断軸：4領域をどの順番で、どこまでやるか
インフラ整備と聞くと「全部やるには数千万円かかるのでは」と身構える経営者は多い。だが4領域は同時に完璧にする必要はなく、導入するAIの自律度に応じて要求水準が変わる。判断軸として次の考え方を勧める。
軸1：AIの自律度で要求水準を決める。 人間が最終確認してから使う「下書き生成型」(要約・文書作成・翻訳)なら、権限とログの要求は低く、データ基盤も対象業務の分だけで足りる。人間の確認なしに実行まで進む「エージェント型」(自動発注・自動回答・自動処理)に近づくほど、4領域すべての水準を引き上げる必要がある。逆に言えば、インフラ整備の予算が確保できないなら、AIの自律度を下げた設計にするのが正しい経営判断であり、それは恥ずかしい選択ではない。83%の統計は「エージェント型をやるなら足場から」という条件文として読むべきで、「足場がないならAIをやるな」ではない。
軸2：データ基盤は「AIのため」ではなく「経営のため」に順序を決める。 4領域のうち最も投資額が大きくなりがちなのがデータ基盤だが、これはAI専用の投資ではない。売上・原価・顧客・在庫のデータが整理されて一箇所に集まる状態は、AIがあってもなくても経営判断の質を上げる。したがって優先順位は「AIに食わせたいデータ」からではなく「経営判断に使いたいデータ」から決めるのが合理的だ。整備の設計と進め方はデータ活用基盤構築で当社が示している考え方を参照してほしい。AIはその基盤の上に載る利用者の一人にすぎない。
軸3：権限とログは「最初の本番業務」の範囲だけ精密にやる。 全社の権限体系を一気に整備しようとすると、それ自体が年単位のプロジェクトになって頓挫する。現実的なのは、最初に本番化する1業務について「このAIが読んでよいデータの一覧」「実行してよい操作の一覧」「記録すべきログの項目」を文書で確定させ、業務を広げるたびにこの文書を拡張していく方式だ。小さく精密に始めて広げる方が、大きく曖昧に始めるより速い。
軸4：コスト管理は導入初日から数字を取る。 4領域で唯一、後回しにする理由がないのがコスト計測だ。利用量と費用の記録は導入初日から取れるし、取っていなければ「この業務のAI化は割に合っているか」という投資判断が永遠にできない。月次で「業務別のAI費用」が一枚で見える状態を、本番化の必須条件にすることを勧める。
PoC本番化前のインフラ準備度チェックリスト
発注や全社展開の意思決定の前に、以下を自社で確認してほしい。技術者でなくても答えられる設問にしてある。「いいえ」が多い領域が、見積もりに整備費として現れるべき領域だ。
データ基盤の準備度
- 本番でAIに参照させたいデータが「どのシステム・どのファイルに・どんな形式で」あるか、一覧にできる
- そのデータの中に、AIに読ませてはならない情報(個人情報・取引先機密・人事情報)が混ざっていないか、混ざっているなら分離する方法を答えられる
- 同じ意味のデータが複数箇所で食い違っている場合(顧客名の表記揺れ、コード体系の不一致)、どちらを正とするかのルールがある
権限の準備度
- 「誰がどの情報を見てよいか」が、担当者の頭の中ではなく文書やシステム設定として存在する
- AIに実行させる操作(登録・送信・発注など)について、金額や影響範囲の上限と、人間の承認が要る条件を決めてある
- 退職者・異動者のアカウントとアクセス権が、現在すでに適切に棚卸しされている(ここが崩れている会社は、AI以前の宿題がある)
ログ・監視の準備度
- AIの入出力と実行操作を記録し、後から検索できる仕組みを本番構成に含めることが、要件として明文化されている
- AIの回答・動作の品質を「誰が・どの頻度で・何を基準に」点検するか、運用の担当が決まっている
- 誤作動やおかしな回答を発見したとき、利用を止める手順と連絡先が決まっている
コスト管理の準備度
- 本番運用時の月額費用の見積もりに、モデル利用料だけでなく、データ転送・ストレージ・周辺システムの保守が含まれている
- 利用量が想定を超えたときに気づける仕組み(上限設定・アラート)が構成に入っている
- 「この業務のAI化にいくらかかり、何がどれだけ改善したか」を四半期ごとに突き合わせる場を設定してある
全問「はい」である必要はない。重要なのは、「いいえ」の項目を把握しないままベンダーと本番化の契約をしないことだ。「いいえ」の項目は、見積もりのどこかに整備作業として計上されているか、自社側の宿題として役割分担表に載っているか、どちらかでなければならない。どちらにも載っていない「いいえ」は、プロジェクト中盤で追加費用か品質問題として必ず表面化する。
見積もりから「インフラ整備費」が抜けているときの見抜き方
本稿でいちばん実務的な話をする。AI開発の見積もりで最も危険なのは、金額が高いことではなく、本番運用に必須の項目が静かに抜けていることだ。抜けたまま契約すると、結末は3パターンしかない。(1)開発中盤に「データ整備が別途必要と判明しました」と追加見積もりが来る、(2)納品物は動くが、権限もログもない「本番に置かれたPoC」が出来上がり、監査や事故で使用停止になる、(3)ベンダーの環境に全部を依存する構成になり、解約も乗り換えもできなくなる。どれも契約前の検算で防げる。
見積書を受け取ったら、次の観点で行を探してほしい。
- データ整備・連携の行があるか。「既存システムとのAPI連携」「データクレンジング」「マスタ統合」に類する行が見当たらず、開発費が「AI機能実装一式」に丸められている場合、ベンダーは「データは綺麗な状態で提供される前提」で見積もっている可能性が高い。前提条件の欄に「貴社にてデータをご用意いただく想定です」と小さく書かれていないか確認すること。そこが実質的な追加費用の火種になる。
- 権限設計・アクセス制御の行があるか。「認証はシングルサインオンに対応」だけでは足りない。誰がログインできるか(認証)と、ログインした人が何を見てよいか(認可)は別物で、後者の設計工数が入っているかを確認する。
- ログ・監視の行があるか。「動くこと」と「動きを追えること」は別の成果物だ。ログの記録範囲・保存期間・閲覧方法が提案書のどこかに書かれていなければ、質問して回答を書面でもらう。
- 運用フェーズの費用が示されているか。 初期開発費だけ提示され、月額のモデル利用料・保守・コスト監視の運用が「別途協議」になっている見積もりは、投資判断の材料として不完全だ。3年総額で比較しなければ、初期費の安い提案が総額で最も高くつくことを見抜けない。
そのうえで、ベンダーに次の質問を投げてみるとよい。「この見積もりの範囲を納品いただいた場合、当社側で別途整備が必要なものを、すべて挙げてください」。誠実なベンダーはデータの用意・権限ルールの決定・運用担当の確保など、発注者側の宿題を具体的に列挙してくる。「特にございません、すべて含まれております」と即答する相手の方を、むしろ警戒すべきだ。本稿で見たとおり、世界のITリーダーの83%が足場の整備を必要と答える領域で、追加の宿題が何もない本番化は考えにくい。発注前にこうした整理を自社主導で行う進め方は、DX・システム開発で示している当社の標準的な進行にも組み込んでいる。
FAQ
Q1. 83%という数字は、うちのような中小企業にもそのまま当てはまりますか。
A. そのままは当てはまりません。調査の回答者は世界の上級ITリーダー1,402人で、専任のIT組織を持つ規模の企業に偏っているとみられ(国別・規模別の内訳は非公表)、設問も「本番水準のエージェント型AI」という限定つきです。ただし方向としては、規模が小さい会社ほど事情は厳しくなります。大企業は「古いインフラを刷新する」課題ですが、中小企業では権限体系やログの仕組みが「そもそも存在しない」ケースが多いからです。83%を自社の確率として読むのではなく、「本番化の壁はモデルではなくインフラ側に出る」という構造の裏付けとして読んでください。
Q2. エージェント型AIと、いま使っている生成AI(ChatGPTなど)は何が違うのですか。
A. 一往復の質問応答や文章生成で完結するのが従来の使い方で、人間が結果を確認してから使います。エージェント型は、目的を与えると自分で情報を取得し、判断し、複数の手順を実行まで進めます。人間の確認を挟まずにシステムを操作する場面が増えるため、参照データの正しさ・操作権限の制御・行動記録の3つが従来型よりはるかに重要になります。本文の4領域の要求水準が上がるのは、この自律性が理由です。
Q3. インフラ刷新とは、クラウドへの全面移行や基幹システムの入れ替えが必要という意味ですか。
A. 必ずしもそうではありません。本稿の文脈でのインフラは、サーバーの話に限らず「データの置き方・権限・記録・費用の見える化」という運用の足場全体を指します。既存システムを残したまま、AIが参照する範囲のデータ整備と権限・ログの設計だけを行う構成は十分に成立します。「AIを入れるならまずクラウド全面移行を」という提案を受けたら、その範囲が本当に最初の業務に必要かを切り分けて検証すべきです。
Q4. インフラが整うまでPoCも始めない方がよいのでしょうか。
A. いいえ、それは逆に失敗パターンです。完璧な基盤を先に作ろうとすると、使い道が決まっていない基盤に大金を投じることになり、頓挫の典型例になります。順序としては、小さなPoCで「どの業務で効くか」を確かめ、本番化の対象が決まった段階で、その業務に必要な範囲のインフラを整備する——この往復が現実的です。本稿のチェックリストは「PoCを始める条件」ではなく「本番化を決裁する条件」として使ってください。
Q5. 「推論税」とは何ですか。自社でも発生しますか。
A. 調査レポートの用語で、AIの推論(実行)そのものの料金ではなく、その周辺で発生する付随コスト——データをクラウド外へ転送する料金、増え続けるストレージ費用、使われていない専用ハードウェアの維持費など——を税金にたとえたものです。62%のリーダーが多額の推論税に直面していると回答しました。中小企業でも、従量課金のAPI費用やログ・データの保存費用が「気づいたら膨らんでいた」という形で同種の問題は起きます。対策は高度な技術ではなく、業務別に費用を計測し上限とアラートを設定するという、本文の軸4で述べた基本の徹底です。
GXOに相談すべきタイミング
次の状況に心当たりがあれば、契約や全社展開の前に第三者の視点を入れる価値がある。
- PoCは成功と評価しているが、本番化の見積もりが想定の数倍になり、その金額の妥当性を自社で検証できないとき
- 受け取った提案書に「環境構築一式」「AI基盤構築」といった粒度の粗い行があり、本稿で挙げた整備項目が含まれているのか判別できないとき
- 本稿のチェックリストで「いいえ」が多かったが、どの項目から・どの範囲で整備すべきか、優先順位を決める判断材料が社内にないとき
- エージェント型AIの提案を受けており、自社の権限・ログの現状でそれを受け止められるのか、導入前に評価したいとき
こうした場面でGXOが提供しているのが、開発契約とは切り離した第三者評価としてのAI導入可否アセスメントだ。対象業務の絞り込み、足場4領域の現状評価、受け取った見積もり・提案の妥当性検証を、30分の壁打ちと要件整理シートという軽い形式で行う。使いどきはPoCの次を決める直前か、本番化契約に印を押す直前——つまり、判断を誤ると最も高くつく局面だ。なお、AI以前にデジタル化やデータ整備の段階でつまずいている感触があるなら、先に無料のDX成熟度診断で足元を測る方が話が早い。
まとめ：83%は脅しではなく、見積もりの検算表である
Google Cloudの調査が示した83%という数字は、「AIは難しいからやめておけ」という警告ではない。世界のITリーダーたちが、エージェント型AIの本番運用を目前にして「勝負はモデルではなくインフラで決まる」と認めた、というのがこの統計の中身だ。そしてこの認識は、これからAI投資の予算を組む中堅・中小企業の経営者にとって、そのまま使える検算表になる。ベンダーの提案がモデルの性能とデモの見栄えだけを語り、データ基盤・権限・ログ・コスト管理に触れていないなら、その提案は本番までの距離の半分しか見積もっていない。逆に、この4領域の宿題を具体的に指摘してくる相手は、本番化の現実を知っている可能性が高い。PoCの成功に続く次の決裁では、「どのモデルか」ではなく「足場は何が足りないか」から議論を始めてほしい。それだけで、本番に行けないPoCを量産する側から抜け出せる。
参考資料
- Google Cloud「State of AI infrastructure report overview」(英語版公式ブログ、2026年7月8日)
- Google Cloud「レポート: 83%の組織がエージェント型AIに対応するためにインフラストラクチャのアップグレードを必要としている」(日本語版公式ブログ、2026年7月15日)
- Google Cloud「2026 State of infrastructure in the agentic AI era」(レポート本体・登録制)
- Ledge.ai「AIエージェント本番運用、83%がインフラ更新必要 Google Cloudが世界のITリーダー1,402人を調査」(報道)
