エンタープライズのAIプログラムが失敗するのは、たいてい悪いアイデアが原因ではありません。より多いのは、統制のないパイロット段階で行き詰まり、そのまま本番（プロダクション）に到達できないケースです。最近のVentureBeatイベントで、MassMutualおよびMass General Brighamのテクノロジーリーダーたちは、その罠をどう回避したのか、そして「統制」が「放任」を置き換えたときの成果はどのように見えるのかを説明しました。
MassMutualの結果は具体的です。開発者の生産性が30%向上し、ITヘルプデスクの解決時間は11分から1分へ、そしてカスタマーサービスの問い合わせ（電話）時間は15分から1〜2分にまで短縮されました。
「私たちはいつも、まず“なぜこの問題を重視するのか”から始めていますか？」と、イベントでMassMutualのエンタープライズ・テクノロジー＆エクスペリエンスの責任者であるSears Merritt氏は述べました。「仮に問題を解決できたとして、どうやって“解決した”と分かるのでしょうか。そして、それを実行することで紐づく価値はどれくらいあるのでしょうか？」
指標を定義し、強力なフィードバックループを構築する
175年の歴史を持ち、何百万もの保険契約者と顧客にサービスを提供しているMassMutualは、AIを事業全体に本番導入へと押し進めています。顧客サポート、IT、顧客獲得、引受、サービス、請求、その他の領域です。
Merritt氏によれば、同社のチームは科学的方法に従い、仮説から始め、ビジネスを確実に前進させる、目に見える成果につながるかどうかを検証します。アイデアが優れていても、データ不足やアクセスの制約、あるいは規制上の制約などの要因によって「ビジネス的に難しく（intractable）」なることがあります。
「私たちは、どう測定するのか、そして成功をどう定義するのかが、完全に明確になるまで、そのアイデアをこれ以上進めません。」
結局のところ、品質が何を意味するのかを定義するのは、部門やリーダーごとに委ねられます。ツールをチームやパートナーの手に渡す前に、指標を選び、最低限の品質水準を定義してください。
この出発点は、迅速なフィードバックループを生みます。「私たちの動きを遅くするのは、“私たちが達成しようとしている成果”について共有された明確さがない場所です」とMerritt氏は述べ、「それが混乱を招き、絶えず調整し直すことにつながります。『はい、うまくいっています』とビジネスパートナーが言うまでは、本番に投入しないのです。」
彼のチームは、新しいツールを評価する際に戦略的であり、「“良い”とは何か」をテストし、測定するときは「非常に厳格」です。たとえば、幻覚（ハルシネーション）率を下げるために信頼度スコアリングを行い、しきい値や評価基準を設定し、機能や出力のドリフト（変動）を監視します。
Merritt氏はまた、コミットしない方針も取っています。つまり、同社は特定のモデルの利用に自社を固定しないということです。彼が「信じられないほど不均質（incredibly heterogeneous）」だと呼ぶ技術環境があり、COBOL上で動くメインフレームと、ベスト・オブ・ブリードのモデルを組み合わせています。この柔軟性は偶然ではありません。彼のチームは、AI層と、その下にあるあらゆるものとの間に位置する共通のサービスレイヤー、マイクロサービス、APIを構築しました。より良いモデルが登場したときに差し替えるのでも、最初からやり直す必要がないようにするためです。
「今日のベスト・オブ・ブリードが、明日のベスト・オブ・ブリードとは限らないかもしれません。だからこそ、遅れを取る状態を自分たちで作りたくないのです」と、Merritt氏は説明しました。
一輪の花が咲き誇るのを放っておくのではなく、間引く
Mass General Brigham（MGB）については、最初は「撒いて祈る（spray and pray）」寄りでした。
非営利のヘルスケア・システムの約15,000人の研究者が、過去10〜15年の間、AI、ML、深層学習を活用してきたと、同じVBイベントでCTOのNallan “Sri” Sriraman氏は述べています。
しかし昨年、彼は大胆な選択をしました。チームは、統制のないAIパイロットが乱立した状態を停止したのです。最初は「一千の花が咲く（thousand flowers bloom）[アプローチ]に従いましたが、“一千の花”があったわけではありません。おそらく数十本の花が咲こうとしている状態でした」と彼は言いました。
Merritt氏のMassMutualのチームと同様に、MGBもより包括的な視点へと転換し、特定の部門の業務ワークフローに対して、なぜ特定のツールを開発しているのかを検討しました。彼らは、どの能力を望み、どの能力が必要なのか、そしてそれらにどれだけ投資が要るのかを問い直したのです。
Sriraman氏のチームはまた、主要なプラットフォーム提供元（Epic、Workday、ServiceNow、Microsoft）とも対話し、ロードマップを確認しました。ベンダーがすでに提供している（あるいは展開する計画を立てている）のに、自分たちの社内でツールを作っていることに気づいたという点で、これは「転機となる瞬間」だったと彼は指摘しました。
そしてSriraman氏は次のようにまとめました。「なぜ自分たちで作るのですか？ すでにプラットフォーム上にあるのです。ワークフローの中に組み込まれます。活用しましょう。」
とはいえ、市場はまだ黎明期で、意思決定が難しくなることもあります。 「例え話をします。6人の盲人に象を触らせて、“この象はどんな見た目か？”と言ったらどうなるでしょう？ 6つのまったく違う答えが返ってくるはずです」とSriraman氏は言いました。
それ自体は悪いことではない、と彼は続けます。状況が移ろい続ける中で、皆が発見し、試行錯誤しているだけなのです。
西部開拓時代のような無秩序な環境ではなく、Sriraman氏のチームは、Microsoft Copilotを事業全体のユーザーに配布し、より高度な製品を安全に試し、トークン利用を制御できる「小さなランディングゾーン」を用意しています。
また、業務グループ全体に「意図的にAIのチャンピオンを埋め込む」ことも始めました。「これは“一千の花を咲かせる”のとは逆で、注意深く植えて、育てる（nourishing）ような形です」とSriraman氏は述べています。
観測可能性（Observability）ももう一つの大きな考慮点です。彼は、モデルのドリフトと安全性を管理するリアルタイムのダッシュボードを挙げ、ITチームがAIを「もう少し現実的に（pragmatically）」統制できるようにすると説明します。AIシステムではヘルスモニタリングが重要だと彼は指摘しており、AIの利用に関する原則やポリシーに加えて、最小限のアクセス権限も整備されています。
臨床現場ではガードレールは絶対です。AIシステムは決定の最終判断を決して出しません。「決定を締めくくるために、必ず医師または医師助手がループの中にいます」とSriraman氏は述べました。AIが重用される領域として放射線レポートの生成を挙げつつも、放射線科医が必ず最終的にサインオフする、としています。
Sriraman氏ははっきりと言いました。「これをしてはいけません。PerplexityにPHI［保護された健康情報］を表示してはいけない。シンプルにそれだけです。」
そして重要なのは、必ず安全性の仕組みが用意されていなければならないということです。「大きな赤いボタン（kill it）、それが必要です」とSriraman氏は強調しました。「その仕組みなしに、運用環境へ何かを入れたりはしません。」
結局のところ、エージェント型AIは変革をもたらす技術である一方、エンタープライズとしてのアプローチは、劇的に変わらなくてもよいのです。「これについて新しいことは何もありません」とSriraman氏は述べました。「BPM［ビジネスプロセス管理］という“90年代〜2000年代”の言葉をAIに置き換えることはできます。同じ概念が適用されます。」
