EY のグローバル CIO である Joe Depa 氏が、AI 活用における「信頼（trust）」について語ったインタビューが公開されました。話の中心は理念ではなく実務です。自社で高性能モデルが低価値な作業に使われていたことに気づき、モデル選択を見直した結果、トークン消費を60%削減しながら価値を上げたという具体的な話が出てきます。私が注目したのは削減率そのものではなく、測る対象を「利用率」から「成果」へ切り替えた判断のほうです。
要点 (出典の事実のみ)
- EY Global CIO の Joe Depa 氏は、AI で成果を出す企業と「pilot purgatory（PoCの煉獄）」に留まる企業を分けるのは trust だと述べている。要素は3つで、信頼できるデータ（自社固有かつ適切に統治されたデータは競争上の堀になる）、信頼できるプロセスと技術（データを実際の業務・意思決定・成果に接続する）、従業員のスキル投資（信頼しなければ使わず、使わなければ勘所が育たない）。
- EY 自身の反省として、生成AIの初期は「利用されているか」を勢いの指標として見ていたが、モデルとユースケースが成熟した現在は事業成果の測定へ focus を移したと説明している。
- その過程で高性能モデルが低価値な作業に使われていることを発見。高価値ユースケースに対するモデル選択の最適化・チームの訓練・利用のガバナンスにより、トークン消費を60%削減しつつ価値を向上させた。これを AI Value Realization Office（ガバナンス・トレーニング・価値測定を担う組織）として制度化している。
- ガバナンスについては「ブレーキだと思われがちだが逆で、アクセルを踏む自信を与えるもの」と述べる。EY の Responsible AI Pulse 調査では、責任あるAIで先行する企業の5社に4社近くがイノベーションの向上を、半数超が収益成長を報告したという。
- AIエージェントが行動を起こすようになると、ガバナンスは文書のままではいられず、システム自体に組み込む必要がある（アクセス制御、挙動の監視、バイアスの確認、逸脱時のセーフガード）とも述べている。
- 「innovation theatre（イノベーション劇場）」の兆候は活動量と成果を混同すること。規律ある企業は、すべてのPoCに担当者・投資仮説・成功指標・意思決定ポイント（拡大するか、作り直すか、止めるか）を置いている。
「利用率で測る期間」には終わりを決めておく
一番実務的だと感じたのは、EY が自社の測り方の変遷を率直に語っている点です。生成AIの導入初期に「まず使ってもらう」ことを重視し、利用率を勢いの指標として見るのは、私は正しい判断だと思います。誰も触っていないツールは改善のしようがないからです。
問題は、その期間をいつ終えるかを決めていないと、利用率のまま何年も走ってしまうことです。利用率は上がり続けますし、報告もしやすい。しかし利用率が高いことと事業が良くなったことは別で、両者を混同したまま予算が続く状態が、Depa 氏の言う innovation theatre です。
前回、Airbnb が予約1件あたりのサポートコストで効果を開示した件について、効果は「単位あたり」で測るべきだと書きました。EY の話はその前段にあたります。何で測るかの前に、いつ測り方を切り替えるかを決める。 導入前にこれを合意しておくと、「使われているのに成果が見えない」という膠着を避けられます。
トークン60%削減は、節約の話ではない
「トークン消費60%削減」という数字は、安いモデルに乗り換えた結果に見えます。しかし Depa 氏の説明を読むと、実際にやったのは高価値ユースケースに対するモデル選択の最適化です。つまり、低価値な作業に高性能モデルを当てていたのをやめた。削減は結果であって目的ではありません。
これはモノタロウが「AIに任せない範囲」を先に決めた設計と同じ構造です。どちらも「AIをどこに使うか」ではなく「どの処理に、どの強さのモデルを当てるか」を設計の対象にしています。全部を最高性能のモデルに通す構成は、作るのは簡単ですが、運用に入ると費用が効いてきます。
そして重要なのは、EY がこれを個人の工夫ではなく組織（AI Value Realization Office）として制度化した点です。モデル選択のルールは、誰かが気をつけるだけでは維持されません。
開発会社の事業判断にどう効くか
三つ挙げます。
一つ目。測り方の切り替え時期を、契約時に決めておく。 「導入後3か月は利用率で見る、その後は業務指標に切り替える」と最初に握っておくと、成果が出ないときに「使われていないから」なのか「使われているが効いていない」のかを切り分けられます。これは提案書に1行入れるだけで済み、後から揉める確率を大きく下げます。
二つ目。モデル選択のルールを納品物に含める。 「この処理は軽量モデル、この処理は高性能モデル」という対応づけと、その判断基準を文書として残す。運用コストは使われるほど増えるため、ここを設計しないまま公開すると、数か月後に必ず費用の議論になります。私が先日更新したAI開発会社の選び方でも、推論コストを見積もりに含めているかを確認観点として挙げました。発注側がこれを聞くようになる前に、提供側から出せるかどうかの差です。
三つ目。エージェント案件では、ガバナンスが実装スコープに入る。 Depa 氏の「ガバナンスは文書のままではいられない」という指摘は、そのまま要件定義の話です。アクセス制御、監査ログ、挙動の監視、逸脱時のエスカレーション。これらはドキュメントではなくコードで実現するものであり、工数が発生します。監視基盤自体が人間スケールの前提のままだと破綻するという論点とも重なります。従来「非機能要件」として後回しにされてきた領域が、エージェント案件では主要な開発対象になる。ここは受託開発会社にとって仕事が増える方向の変化です。
誤読しやすい点
「ガバナンスを整えれば成果が出る」と読むのは順序が逆です。 Depa 氏が言っているのは、ガバナンスがあると安心して試せるから試行回数が増えるという因果です。実際、引用されている調査も「責任あるAIで先行する企業がイノベーションと収益成長を報告した」という相関であり、ガバナンス単体が成果を生むという証明ではありません。ルールだけ先に作って試行が止まれば、本末転倒になります。
もう一つ、60%という数字を自社に当てはめられるとは限りません。 EY はグローバル規模で大量のAI利用があり、その中に「低価値な作業に高性能モデル」という無駄が積み上がっていたからこその削減幅です。使い始めたばかりの企業に同じ余地はありません。持ち帰るべきは削減率ではなく、モデル選択を設計対象として扱う考え方のほうだと考えています。
なお、EY の AI 全社展開そのものについてはEYとマイクロソフトのAI全社展開施策で別途扱っています。あわせて読むと、実証段階を抜ける企業が何を組織として持っているかが見えてきます。
出典: 'Move fast, but do it with trust built in': EY CIO tells us why the rapid pace of AI means trust is now a critical business imperative (TechRadar Pro)
