IDCの調査結果でAIプロジェクトの成果がCIOの厳しい監視下に

IDCの調査がAIプロジェクトの失敗を巡るgoogle newsでの議論を呼び、ある見出しはプロジェクトの45%が成果を生んでいないと主張している。

ただし、基礎となる証拠はより慎重に読む必要がある。IDCに関連する調査では、平均して測定可能な成果を生み出しているAIイニシアチブは45%にとどまるとされる。この調査結果は、組織が成功をどう定義するかによっては、見出しが示す以上に大きな価値の隔たりを意味する。

この区別が重要なのは、CIOがもはや立ち上げたAIパイロットの数で評価されなくなっているからだ。取締役会はいま、測定可能なリターン、安全な導入、そして自律エージェントが本番環境に入った後も制御できるガバナンスを期待している。

これこそが見出しの背後にある本当の対立である。企業のリーダーは、より高い自律性でより多くの作業をこなすAIシステムを求めている。しかし、その同じ自律性が、コスト、意思決定、権限、障害の封じ込めをより難しくする。

したがってIDCが描いているのは、また一つの期待外れのテクノロジーサイクルではない。実験的なAIチームから、事業成果と運用リスクを説明しなければならないCIOへの責任移転を記録している。

IDCのGoogle Newsにおける主張は実際に何を示しているのか

報じられた45%という数値は、測定可能な成果を生んだイニシアチブを示すものであり、すべての企業AIプロジェクトに共通する失敗率ではない。

元のgoogle newsの見出しは、AIプロジェクトの45%が成果を出せていないと表現している。しかし、IDCに関連する補足資料では、この統計は異なる形で提示されている。

Fujitsu analysisは、IDCの2025年9月のTechnology Investment and Innovation Monitorを引用している。それによると、世界全体で平均してAIイニシアチブの45%が測定可能な成果を達成している。

Fujitsuの引用によれば、この調査は894人の回答者を対象とした。また、AIプロジェクトの4分の3超で成功を報告した組織はわずか11%だった。

これらの測定結果は、正確に45%が失敗したことを示すものではない。45%が測定可能な成果を生み出したことを示しており、残る55%は調査の測定手法では実証された結果がなかったことになる。

この隔たりには複数の状況が含まれ得る。プロジェクトが試験段階にとどまっている場合、本番環境に到達しても測定可能な価値を生んでいない場合、当初の目標を達成できなかった場合、または評価に十分なデータがない場合などだ。

これらは異なる結果である。それらを一つの失敗率にまとめれば見出しは分かりやすくなるが、企業の実績を示す像は不正確になる。

入手可能な証拠も、基盤となるAIモデルがすべての低調な結果を引き起こしたことを証明してはいない。事業部門での採用、ワークフロー設計、データ品質、運用コスト、不明確な指標は、それぞれ価値実現を妨げ得る。

この区別は、技術的な失敗と組織的な失敗を分ける。モデルが許容可能な出力を生成していても、周辺のプロジェクトが事業目標を逃すことはある。

たとえば社内アシスタントは、従業員の質問に正確に回答できるかもしれない。それでも、従業員が利用を避ける、回答が遅すぎる、あるいはサポートコストが削減額を上回るなら、商業的には失敗である。

予測モデルも、管理されたテストでは高い性能を示すことがある。しかし、管理職が推奨を無視する従来のプロセスで意思決定を続けるなら、ほとんど価値を提供しない。

IDCのより広範な調査は、この解釈を裏付けている。同社は、特に基準となる指標が一度も定義されていない場合、組織が実験と測定可能な事業成果を結び付けるのに苦労していると述べている。

だからこそ、この見出しは退けることなく吟味に値する。正確な割合は定義に依存し続けるが、根底にある価値の問題は十分に裏付けられている。

他の調査も同じ方向を示している。CIO.comの2026年調査では、AIイニシアチブが事業目標を達成または上回ったと答えた回答者はわずか19%だった。

State of the CIOの調査は、662人のITリーダーと249人のビジネスユーザーを対象とした。その結果、ユースケースの3分の1未満しか期待に応えられていないと報告した回答者は18%だった。

両調査はサンプルと定義が異なるため、その割合を直接比較として扱うべきではない。ただし、合わせて見ると、測定可能な企業価値はいまだ一般的ではないことが示される。

責任ある結論は、拡散した主張よりも限定的だ。多くの組織はAIイニシアチブの大半から一貫したリターンを示せず、CIOはいまその理由を説明しなければならない。

数字を引き伸ばさなくても、この結論は十分に重大である。

AIの実験段階はROI責務へと移行している

中心的な変化はAIへの関心の低下ではない。明確な責任者、基準値、事業成果を定めない実験への資金提供が終わりつつあることだ。

リターンの証明が依然として難しいなかでも、企業のAI投資は続いている。この一見した矛盾は、すべてのプロジェクトへの確信ではなく、競争圧力を反映している。

取締役会は、投資を縮小すれば自社が後れを取ることを懸念している。同時に、既存の支出が収益、コスト、顧客サービス、レジリエンス、または意思決定の速度を改善していることをCIOに示すよう求めている。

これはテクノロジーリーダーに、より狭い道筋をもたらす。導入の勢いを維持しつつ、運用負担を正当化できないプロジェクトを終了しなければならない。

IDCによると、組織の42%はデジタルおよびAI投資のROIを評価することが困難、または不可能だと感じている。同社は、一貫性のない基準値と長期的な可視性の不足を主な障害として挙げている。

同社のagentic ROI frameworkは、エージェント型システムがこれらの問題をより困難にすると論じている。ワークフロー、モデル、利用パターンが変化するにつれ、その価値とコストも変わるためだ。

従来のソフトウェアは、比較的安定したビジネスケースを支えることが多い。導入前に、購入者は実装コスト、ライセンス要件、想定ユーザー数、プロセスの削減効果を見積もる。

エージェント型AIは異なる。エージェントとは、限られた人間の介入で、手順を計画し、ツールを使い、目標に向けて行動できるソフトウェアだ。

運用コストは、モデル呼び出し、コンテキストの規模、ツール利用、再試行、人間によるレビューに応じて変動する。また、事業環境やソースデータが変化すれば、その性能も変動し得る。

したがって、成功したパイロットが提供する証拠は不完全である。パイロットでは、精選されたデータ、少数のユーザーグループ、本番チームでは維持できないほど手厚い技術的監督が使われている可能性がある。

広く導入されると、同じシステムは一貫しない入力、アクセス制限、まれなケース、想定外の方法で利用する従業員に直面する。

TIAAのエグゼクティブであるSastry Durvasulaは、CIO.comのレポートでこの緊張関係を説明した。組織が運用コストを考慮すると、成功したパイロットでも実際のROIを生み出すのに苦労する可能性があると述べた。

そのコストには、トークン消費、トラフィック処理、統合の保守、評価、セキュリティレビュー、サポートが含まれる。これらは初期のデモではほとんど現れない。

新たなCIOの責務は、構築前に価値を定義することから始まる。プロジェクトには、AIなしでプロセスがどのように機能しているかを示す測定可能な基準値が必要だ。

また、成果から利益を得る事業責任者も必要になる。別部門が導入とワークフローの変更を管理している場合、技術チームだけで事業価値を認定することはできない。

CIO.comの調査では、調査対象のITリーダーの83%が部門横断的なAI体制を導入済み、または年内の導入を計画していた。しかし、正式な承認と測定は依然として成熟度が低かった。

正式なAIプロジェクト承認プロセスを持つのはわずか53%だった。さらに28%は、その後12カ月以内の導入を計画していた。

正式な指標を持つのは回答組織の47%で、34%はその整備を予定していた。この隔たりは、導入と測定可能なリターンがしばしば乖離する理由を説明する一助となる。

元のプロセスのコスト、エラー率、完了時間、顧客成果を記録していなければ、組織は改善を証明できない。

その結果、説明責任は逆転する。以前のAIプログラムでは、パイロットの数と目に見える実験が評価された。次の段階では、規律ある選定と再現可能な価値が評価される。

この変化はベンダーとの対話も変える。購入者がモデルの品質を運用上の成果に結び付けられなければ、モデル品質に関する主張の重要性は下がる。

CIOには、ワークフロー全体にわたる証拠がますます必要になる。従業員がシステムを利用しているか、出力品質が安定しているか、コストが上限内に収まっているかを測定しなければならない。

また、停止基準も必要だ。導入、品質、財務のしきい値を繰り返し下回るプロジェクトは、恒久的なインフラになる前に資金を失うべきである。

この実践はAIへの敵意を意味しない。AI支出を、他の戦略的投資と同じ規律で扱うものだ。

主な対立はAIの約束と運用現実の間にある

企業AIプロジェクトはしばしば、説得力のあるデモと、実際の業務が行われる複雑な環境との境界で失敗する。

この物語における主な対立軸は、あるAIベンダーと別のAIベンダーの争いではない。迅速なAI価値という約束と、企業運営の現実との対立である。

デモは通常、限定されたタスクを切り出す。本番システムは、権限、古い記録、矛盾するポリシー、不完全なデータ、複数の依存アプリケーションを乗り越えなければならない。

依存関係が一つ増えるごとに、別の障害経路が生まれる。モデルが妥当な回答を返しても、利用できないツール、古い記録、誤った権限によって、必要な行動を妨げられることがある。

データ品質も同様の問題をもたらす。AIシステムは情報を要約、分類、検索できるが、企業リポジトリ全体に潜むすべての矛盾を修復することはできない。

サポートエージェントは、同じ返金ポリシーの3つの版に遭遇するかもしれない。信頼できる情報源とバージョン履歴がなければ、誤ったルールを自信を持って選択する可能性がある。

ナレッジワークは、別の測定上の課題も生む。従業員が節約した時間を信頼できない出力のレビューに使うなら、文書作成が速くなっても自動的に財務価値が生まれるわけではない。

プロジェクトはプロセス全体を測定しなければならない。そこには、準備、生成、レビュー、修正、エスカレーション、そして後続のエラーが含まれる。

ここで、knowledge blendingのアプローチが有効になる場合がある。承認済みの情報源と作業コンテキストを組み合わせることで検索の隔たりを減らせるが、どの資料を信頼するかは依然としてガバナンスが決める。

ワークフローへの定着も重要である。従業員は、手順が増える、慣れないインターフェースを必要とする、またはまれなケースで機能しない新システムをしばしば回避する。

こうした行動は、支援付きのパイロットでは見えないことがある。参加者にはトレーニングとサポートが提供される一方、通常のユーザーは競合する優先事項に直面する。

したがって、導入を成功させるには、単にモデルへのアクセスを提供するだけでなく、プロセスの再設計が必要だ。チームは、どのタスクを変えるか、どの承認を残すか、例外を誰が処理するかを決めなければならない。

支援と自律性の違いは、リスクをさらに高める。文章作成アシスタントは、人がレビューするためのテキストを提案する。エージェントはチケットを作成し、記録を変更し、顧客に連絡し、または取引を開始できる。

不正確な提案はレビュー時間を要する。不正確な自律アクションは、人間が気付く前に実システムを変更し得る。

IDCの調査は、組織がすべてのタスクにエージェント型技術を適用すべきではないと論じている。明確なルールを持つ安定したプロセスには、決定論的な自動化の方が適している。

エージェント型システムがより意味を持つのは、複数の手順、変化するコンテキスト、判断、ツール間のオーケストレーションを必要とする業務だ。それでも、自律性は追加リスクを正当化できるだけの価値を生まなければならない。

このユースケースに対する規律は、IDCのAIプロジェクト失敗をめぐる議論の説明にも役立つ。一部の弱いプロジェクトは、解決すべき課題を探す技術から始まる。

チームはまずモデルやエージェントプラットフォームを選ぶ。その後、その購入を正当化できるワークフローを探す。

この順序では、業務上の重要性が限られた興味深いプロトタイプが生まれがちだ。プロジェクトが測定可能なニーズから始まっていないため、成果に責任を持つ事業部門が存在しない。

より強固な順序は、コストが高い、あるいは制約の多いワークフローから始めることだ。チームはそのベースラインを文書化し、関係する意思決定を特定し、AIが全体的な成果を改善するかを検証する。

比較には従来型ソフトウェアと業務プロセスの変更も含めるべきだ。AIは経営陣からAI施策を求められたからではなく、課題に適しているから選ばれるべきである。

組織は生産性と実際に取り込める価値も区別しなければならない。従業員が数分を節約しても、それが自動的に財務的な意味を持つわけではない。

企業が価値を取り込めるのは、その時間が成果の向上、顧客対応の短縮、能力の増加、または特定された支出の削減につながる場合に限られる。

従業員体験とレジリエンスも依然として重要になり得る。ただしリーダーは、財務目標を達成できなかった後に都合のよい説明として扱うのではなく、それらの便益をどう測定するかを定義しなければならない。

IDCがより広範な価値マッピングを提案するのはこのためだ。そのフレームワークには、従来の財務指標に加え、顧客の信頼、レジリエンス、サステナビリティ、時間軸が含まれる。

このより広いモデルが、曖昧な成功主張の言い訳になってはならない。各次元には依然として、責任者、ベースライン、測定方法、レビュー日が必要である。

したがって、運用上の現実はモデル崩壊ほど劇的ではない一方、修正はより難しい。技術、財務、セキュリティ、法務、事業チームにまたがる連携が必要になる。

モデルの更新だけで、その連携を自動的に生み出すことはできない。

エージェント型AIガバナンスはセキュリティを事業上の制約へと変える

エージェント型AIガバナンスは、自律性を安全に拡大できるかを左右する。エージェントは、不確実な出力を接続されたシステム全体の行動へと変換するためだ。

セキュリティは常に、企業の技術選定に影響を与えてきた。エージェント型システムは、モデルの不確実性と認証情報、ツール、メモリ、運用アクセスを組み合わせることで、この問題を変化させる。

従来のチャットボットは通常、情報を返す。エージェントは要求を解釈し、計画を立て、アプリケーションを呼び出し、新たな結果を受け取った後も行動を継続できる。

この能力は攻撃対象領域を拡大する。悪意あるコンテンツがエージェントの指示に影響を与える可能性があり、過剰な権限は一つの誤った判断をより大きなインシデントへと発展させ得る。

プロンプトインジェクションはその一例だ。攻撃者はモデルが読むコンテンツ内に指示を埋め込み、システムを認可されたタスクから逸脱させようとする。

エージェントがメッセージ送信、データベース変更、機密記録の取得、コード実行を行える場合、危険性は増す。誤解を招く応答は、起こり得る失敗の一つにすぎない。

IDCは、制御されない意思決定の連鎖、不透明な挙動、分断されたエスカレーションについて警告している。同社のガバナンス分析は、ガバナンスを最終的なコンプライアンスレビューではなく、運用インフラとして説明している。

同社は、2030年までにGlobal 1000企業の最大20%が訴訟、罰金、またはCIOの解任に直面する可能性があると予測している。IDCは、このリスクを、AIエージェントのガバナンス不備によって引き起こされた注目度の高い混乱と結び付けている。

これは予測であり、観測された失敗率ではない。確実な結果ではなく、潜在的な説明責任の規模を示すものだ。

IDCは、トレーサビリティ、統合ガバナンス、明確に定義された説明責任ループを推奨している。これらの統制により、チームは意思決定を再構築し、確立された境界を越える前に行動を中断できる。

トレーサビリティとは、自律的な意思決定に関わったデータ、モデル、指示、ツール呼び出し、出力を記録することを意味する。これらの記録がなければ、チームはエラーを調査することも、結果を正当化することもできない。

統合ガバナンスは、システムのライフサイクル全体を通じて、セキュリティ、データ、法務、リスク、事業の責任を結び付ける。モデルだけをレビューする委員会では、完全なワークフローを統治できない。

説明責任ループは、いつ人が行動を承認、レビュー、または停止しなければならないかを定義する。しきい値はモデルの信頼度だけでなく、起こり得る結果に基づくべきである。

低リスクの行動には、より広い自律性を与えられる。社内リマインダーの送信は、支払いの承認や顧客アカウントの変更とは異なる結果をもたらす。

アイデンティティ管理も同様に重要だ。各エージェントには、開発者や共有サービスから無制限の認証情報を借用させるのではなく、固有のアイデンティティ、権限、責任者、目的が必要である。

権限は最小権限の原則に従うべきだ。エージェントには、割り当てられたワークフローに必要なアクセスだけを与え、それ以上の権限を持たせない。

組織には信頼できるインベントリも必要だ。特に部門が業務アプリケーション内でエージェントを設定できる場合、セキュリティチームは存在を把握していないエージェントを保護できない。

インベントリには、責任者、接続先システム、承認済みデータ、モデルプロバイダー、評価結果、緊急時の統制を記録すべきである。

導入後は継続的な評価が必要になる。モデルの更新、プロンプトの進化、接続ツールの変更、または事業データにおける新たなパターンの出現によって、エージェントの挙動は変化し得る。

IDCは、コンテキストの変化やエッジケースの蓄積に伴い、パフォーマンスが低下し得ると指摘している。このため、エージェントは完了済みの導入ではなく、継続的に管理されるサービスとなる。

したがって、セキュリティとROIは収束する。監視、評価、アクセス制御、インシデント対応、人によるレビューはすべて運用コストを追加する。

こうした統制を除外した事業計画は、実際より有利なリターンを示す。それらを取り除いて予測値を守ろうとすれば、財務上の圧力をセキュリティ上の露出へと転嫁することになる。

これはCIOが管理すべき中心的なトレードオフである。自律性を高めれば、速度と能力は向上し得るが、保証にかかるコストも増加する。

答えは、あらゆる行動を無制限にレビューすることではない。それでは、エージェントを正当化した効率性が失われてしまう。

組織にはリスクベースの自律性が必要だ。可逆的で観測可能な行動は自動化しつつ、法的、財務的、または安全上の結果を伴う意思決定には人による承認を求めることができる。

エージェント型AIガバナンスは、停止手順も対象にしなければならない。チームには、インシデント時に認証情報を無効化し、ワークフローを停止し、メモリを隔離し、証拠を保全する能力が必要である。

こうした能力がなければ、複数のチームが責任の所在を議論している間も、エージェントは稼働し続ける可能性がある。たとえモデルが設計どおりに動作していたとしても、それは組織的な統制の失敗である。

数字だけでは依然として証明できないこと

利用可能な統計は広範な価値創出の問題を示しているが、すべてのAIプロジェクトに共通する単一の失敗率を裏付けるものではない。

Google Newsのフレーミングは、二項対立的な読み方を促す。プロジェクトは成功か失敗のどちらかであり、一つの割合が市場全体を要約する。

企業導入は、このモデルに当てはまることがほとんどない。あるプロジェクトは技術ベンチマークを満たし、導入目標を逃し、予算内に収まりながら、測定可能な収益をまったく生み出さないことがある。

別のプロジェクトは、当初のコストを上回りながらも、戦略的に重要な知識や顧客便益を生み出すことがある。成功と見なされるかどうかは、評価フレームワークに左右される。

調査の設問も結果を変える。「測定可能な成果を達成した」は、「期待に応えた」「本番環境に移行した」「財務的リターンを生み出した」とは異なる。

サンプルの選択も重要だ。技術リーダーを対象とする調査は、ビジネスユーザー、財務チーム、個別プロジェクトを対象とする研究とは異なる結果を生み出し得る。

分母も別の問題を生む。すべてのプロトタイプを数える研究もあれば、本番導入済みの案件や、シニアリーダーが認識している施策だけを含める研究もある。

時間軸も異なる。AIシステムでは、便益が現れるまでに数四半期にわたるワークフロー再設計と導入が必要になることがある。

1四半期後に失敗と宣言するのは早計かもしれない。一方で、証拠がないまま無期限に継続すれば、より多くの資本を浪費しかねない。

こうした限界はIDCの調査結果を無効にするものではない。読者がそこから責任を持って導ける結論を定めるものだ。

最も強い結論は、企業がAIの価値を測定し、再現することに苦戦しているということだ。最も弱い結論は、すべてのプロジェクトの一定割合が同じ理由で決定的に失敗したというものだ。

この違いは説明責任にも影響する。モデルが自動的に責められる場合、組織は弱い結果を招いたワークフロー、データ、ガバナンスの問題を残したままベンダーを変更する可能性がある。

すべての問題が組織の準備不足のせいにされるなら、ベンダーは信頼性の低い製品に対する責任を回避できる。どちらの見方も精査に値する。

モデルの品質は依然として重要だ。ハルシネーション、一貫性のない推論、レイテンシー、限られたコンテキスト、ツール利用時のエラーは、アプリケーションを本番環境に不適なものにし得る。

ベンダー設計も重要である。購入者には、使いやすい監査ログ、権限制御、モデル変更の通知、評価ツール、予測可能なサービス挙動が必要だ。

組織は適切なユースケースを選択し、アクセスを安全に設定する責任を負う。ベンダーは能力と制約を正確に説明する責任を負う。

したがって、IDCのAIプロジェクト失敗をめぐる議論は、一人の都合のよい犯人ではなく、より良い問いを生み出すべきである。

プロジェクトはどのベースラインを改善するつもりだったのか。どの事業責任者が目標を受け入れたのか。承認前にセキュリティと運用コストは含まれていたのか。

パイロット支援が終了した後も、従業員はシステムを利用したのか。まれなケースや変化するデータにおいても、出力品質は許容範囲にとどまったのか。

エラー発生後、チームはエージェントの行動を再構築できたのか。無関係なシステムを停止させずに、ワークフローを直ちに止められたのか。

これらの問いは、議論のある見出しを運用レビューへと変える。また、パイロットが予定どおり開始されたかどうかよりも、答えるのが難しい。

独立した比較も、慎重さの必要性を裏付ける。Gartnerは、高成熟度の組織の45%がAIプロジェクトを少なくとも3年間運用し続けたと報告した。

同社のAI成熟度調査は、継続性を成熟した実践と結び付けたが、継続性だけで事業価値が証明されるわけではない。

プロジェクトは戦略的または政治的な理由で運用を継続することがある。また、能力を別のプラットフォームへ移行することに成功した後で終了することもある。

単一の指標で成果全体を捉えることはできない。組織には、技術パフォーマンス、導入状況、財務的影響、リスク、戦略的価値を分けたポートフォリオの視点が必要だ。

そのポートフォリオには、成功しなかったプロジェクトも含めるべきである。中止されたパイロットを隠すことは、誤解を招く見方を生み、チームが繰り返される原因を認識する妨げになる。

また、健全な中止と制御不能な失敗も区別すべきだ。弱いプロジェクトを早期に終了させることは、低いパフォーマンスではなく、規律あるガバナンスを示す場合がある。

あるCIO.comの情報源は、開始したプロジェクトのおよそ3分の1を中止することを健全だと説明した。この組織は、ステージゲート型の資金提供と成果チェックポイントを用いて、弱い取り組みが恒久的なリソースを消費するのを防いだ。

このアプローチは失敗の捉え方を変える。危険なプロジェクトは、必ずしも停止するプロジェクトではない。誰も意思決定の責任を負わないために、証拠がないまま継続するプロジェクトである場合がある。

CIOが次に注視すべき3つのシグナル

次の試金石は、組織がパイロット件数を、成果報告、統制された自律性、そして従業員が実際のワークフロー内でAIを利用している証拠に置き換えるかどうかだ。

最初のシグナルは、正式なAI価値プレイブックの導入である。IDCは、アジア太平洋地域の500社のCIOの60%が、2027年までにその作成を任されると予測している。

価値創出のプレイブックは、ユースケースの選定、ベースライン、コストモデル、責任所在、レビューの基準値を標準化する。これによりリーダーは、一貫した根拠に基づいてプロジェクトを比較できる。

組織が測定可能な成果を欠くプロジェクトを打ち切り始めれば、この兆候はIDCの主張を補強することになる。正式な測定が広がってもポートフォリオの成果が改善しなければ、その主張は弱まる。

重要な指標は、公開されたプレイブックの数ではない。責任者、ベースライン、完全な運用コスト、定期的な成果レビューが明確に設定された本番イニシアチブの割合である。

取締役会は、組織が間接的な便益をどのように報告しているかにも注目すべきだ。顧客の信頼、レジリエンス、意思決定の迅速化はいずれも重要になり得るが、それぞれに観測可能な測定方法が必要となる。

2つ目の兆候は、強制力のあるエージェント制御の導入である。ポリシーだけでは、ビジネスシステム全体で継続的に行動するソフトウェアを統制できない。

CIOは、専用のアイデンティティ、限定された権限、完全なアクションログ、人間へのエスカレーションルール、テスト済みの停止手順を備えるエージェントがどれだけあるかを追跡すべきだ。

セキュリティチームは、重大度と根本原因別にインシデントも報告すべきである。インシデント件数の増加は、安全性の悪化を示す場合もあれば、これまで見えなかった活動への可視性が向上したことを反映する場合もある。

より意味のある傾向は、エージェントの利用が拡大する中で重大インシデントが減少するかどうかだ。組織はインシデント率を、エージェントのアクション数、接続システム数、リスクレベルと照らして比較すべきである。

IDCのアジア太平洋地域に関する見通しは、不十分なエージェント制御が法的リスクや経営幹部の説明責任を含む深刻な結果を招くと予測している。自律的な導入が技術的監督を上回る速度で拡大すれば、この予測の信頼性は高まる。

組織が、リスクベースの制御が利用拡大に合わせてスケールすることを示せば、その予測の信頼性は低下する。根拠には、監査結果、封じ込め時間、権限違反、人間による介入の成功例を含めるべきだ。

3つ目の兆候は、ワークフローの成果に結び付いた本番導入である。パイロット段階での精度や従業員の熱意は、日常業務での継続的な利用の代わりにはならない。

CIOは、アクティブ利用、完了率、例外の発生頻度、レビュー時間、生成された成果物のうち有用な結果に至る割合を監視すべきである。

また、導入支援が縮小した後に何が起きるかも測定すべきだ。開発者からの継続的な介入に依存するシステムは、再現可能な本番運用には到達していない。

事業部門は、AIがサイクルタイムを短縮し、能力を拡張し、エラーを減らし、顧客成果を改善しているかを報告する必要がある。財務チームは、主張される削減効果を検証すべきだ。

利用が拡大しているにもかかわらず測定可能な価値が弱いままであれば、この兆候はgoogle newsの論調を補強することになる。導入だけではROIの問題を解決できないことを示すからだ。

完全なセキュリティコストと運用コストを含めた後でも、成熟したプログラムが複数のワークフローで再現可能な成果を示せば、その論調は弱まる。

これら3つの兆候はつながっている。より良い価値モデルはより強いユースケースを選び、より強い制御は安全な自律性を可能にし、持続的なワークフロー導入は測定可能な証拠を生み出す。

いずれか1つが欠けると、結果は脆弱になる。制御のない収益性の高いシステムは、隠れたリスクを抱える。ユーザーのいない安全なシステムは、価値を生まない。

ベースライン測定のない人気システムは、印象的な活動量を生み出しても、リターンは不確実なままである。

CIOは、またしても大まかな割合でこの議論に答えようとする圧力に抵抗すべきだ。集計された見出しよりも、自らのポートフォリオの方が有用な証拠を提供する。

まずは重要なワークフローを少数選び、現在のパフォーマンスを記録することから始められる。各プロジェクトには、ビジネス責任者、技術責任者、リスク分類、レビュー予定を設定すべきである。

チームは、初期開発を超えたコストを算出すべきだ。これには、モデル利用、統合の保守、監視、評価、セキュリティ、サポート、人間によるレビューが含まれる。

自律性を付与する前に、許容できない結果を定義すべきである。こうした境界には、データ漏えい、財務上の上限、顧客への影響、禁止されたツール操作を含められる。

最後に、取りやめたプロジェクトを含め、社内の結果を公開すべきだ。透明な報告により、弱いプロジェクトが熱意だけで存続することは難しくなる。

したがって、論争となっている45%という主張は、普遍的なスコアカードとしてではなく、警告として有用である。これは、不正確な測定がいかに容易に断定的なAI見出しへと変わるかを示している。

より良い対応は、google newsの1つの割合をめぐって議論することではない。各AIシステムが、すべてのコストとリスクを計上した後にも価値を生み出しているという証拠を求めることだ。

あなたの組織では、どのプロジェクトがそのテストを生き残り、どのプロジェクトが成功の定義すらされていないために資金提供を受け続けているだろうか。