AIパイロットをスケールさせるために失敗する理由：ガバナンス、指標、オペレーティングモデル

多くのAIパイロットは、実装の複雑性が過小評価されるため、テスト段階を超えて進みません。より明確な前進の道筋は、ステークホルダーを特定し、複雑性がどこへ移動するのかを理解し、創出される価値の指標を定義することから始まります。

AIがオペレーティングモデル、プロセス、意思決定全体に組み込まれると、より広範な変革はAI変革、またはAXと呼ばれることがあります。

なぜ多くのAIパイロットはスケールに失敗するのでしょうか？

組織はAIを試し、いくつかのユースケースをテストし、有望な結果を確認します。その後、施策はパイロット段階にとどまります：

• 運用モデルの一部になりません。
• スケールした状態で測定可能なビジネスへの影響を生み出しません。

デロイトは、回答者のうちAIの実験の40%またはそれ以上を本番環境に移行したのは25%にとどまったと報告しました。¹

マッキンゼーも同様の状況を述べています。組織の約3分の2は、いくつかのパイロットを超えてAIをスケールできていませんでした。²

私の見解では、主な理由の一つは、シニアステークホルダーが問題の複雑さを過小評価しがちなことです：

AIの施策は複雑さを取り除く解決策として提示されます。実際には、複雑さを別の場所へ移動させるだけです。

簡単な例：AI搭載チャットボット

Webサイト上のチャットボットを考えてみてください。チャットボットは顧客の質問に自動的に回答し、サポートチームの作業負荷を軽減します。多くの問い合わせは人の関与なしに処理されます。

顧客の視点から見ると、これはうまく機能します。ユーザーはすぐに回答を受け取り、サポートに連絡する必要がありません。

顧客ジャーニーから複雑さが取り除かれます。

同時に、その複雑さの一部はサポートチームおよびシステムを維持するAIチームへと移転されます。

エンドユーザーにとって何が変更されますか？

エンドユーザーにとっての主な疑問は、チャットボットが問題を解決したかどうかです。

開始時の指標は初回コンタクト解決率です。これは、サポート担当者へのエスカレーションなしに解決されるリクエストがどれくらいあるかを示します。

サポートチームにとって何が変わりますか？

サポートチームは、チャットボットでは解決できない依頼を受け取ります。場合によっては、チャットボットのエスカレーションが遅すぎることがあります。専門担当者が会話に参加する時点で、顧客はすでに問題解決を試みるために時間を費やしており、苛立っています。

場合によっては、チャットボットのエスカレーションが早すぎることもあります。十分な情報を収集する前にケースを引き継いでしまいます。サポートの専門担当者は不完全な依頼を受け取り、同じ質問を再度行う必要があります。

これは次の指標で定量化できます：

• エスカレーション率。 サポートチームに引き継がれた依頼の割合を測定します。
• 遅延エスカレーション率。 エスカレーション前に顧客が回避可能な摩擦を経験したケースを追跡します。
• 不足している文脈。 専門担当者が、より早い段階で収集できたはずの情報の提供を求める必要がある頻度を測定します。
• サポート業務負荷。 サポート依頼の件数と難易度の変化を監視します。

サポートチームへの長期的な影響

長期的には、次のような問いもあります。

• サポート担当者はどのように訓練すべきでしょうか？

チャットボットが導入される前は、ジュニア担当者は簡単な質問に回答することで学んでいました。時間の経過とともに、より難しいケースに必要な経験を身につけていきました。

定型的な依頼が自動化されると、サポートチームには複雑なケースがより高い比率で集まります。従来の訓練モデルはもはや機能しません。

組織には、専門性を構築するための新しい方法が必要です。

AIチームにとって何が変わりますか？

本番環境では、チャットボットは継続的なメンテナンスを必要とするシステムになります。

新しい顧客の質問が現れます。ナレッジベースは更新が必要になります。既存の回答は、各変更の後も正確性を保つ必要があります。安全プロトコルは見直す必要があります。

これは次の指標で定量化できます：

• 新しいユースケースを追加するまでの時間。 新しい顧客シナリオをサポートするまでに要する時間を測定します。
• 回帰テスト。 新しい変更が、以前にサポートしていたユースケースに影響を与えるかどうかを確認します。
• ナレッジベースのメンテナンス。 情報を最新の状態に保つために必要な工数を追跡します。
• 安全プロトコルのカバレッジ。 機微なトピックに明確なルールとエスカレーション経路があることを確認します。

返金、財務、アカウントアクセス、または注文変更に関する質問は、ケースをさらに複雑にします……チャットボットは質問に直接回答すべきでしょうか？一般的な案内を提供すべきでしょうか？専門担当者に引き継ぐべきでしょうか？

誰かがこれらのルールを定義し、テストし、ビジネスの文脈が変化したときに更新する必要があります。

AI施策のために本当に指標が必要なのでしょうか？

妥当な疑問は、このような測定の取り組みが本当に必要なのかという点です。私の答えは「はい！」です。議論そのものが価値を生みます。議論はチームに対して、より具体的になることを促します。

• 成功したチャットボットとは、具体的に何を意味するのでしょうか？
• どのようなエスカレーションが許容されるのでしょうか？
• AIチームはどれだけの保守作業に対応できるのでしょうか？
• サポート担当者をどのようにトレーニングするのでしょうか？

KPIの正確な値が入手できない場合であっても、これらの問いは実装の品質を向上させます。

マッキンゼーは、生成AIの導入およびスケーリングに関する12の実践事項を分析しました。各実践事項はEBITへの影響と正の相関を示しました。研究に含まれた実践事項の中では、生成AIソリューションに対して明確に定義されたKPIを追跡することが、収益に最も強い影響を与えました。³

各AIパイロットに関連する指標を継続的に追跡するには、規律が求められます。BSC Designerプラットフォームは、パフォーマンス測定の一貫性を確保し、KPIを必要なビジネス文脈に整合させることで、このプロセスを大幅に容易にできます。

複雑性指標から始めてください

各AIプロジェクトには、それぞれ固有の指標セットが必要です。それでも、ほぼすべての導入でレビューする価値のある共通領域がいくつかあります。最初は複雑性です。

複雑性を定量化するのは困難です。組織が時間、労力、予算を費やしている領域に注目してください。繰り返しのコミュニケーション、手作業によるレビュー、遅延した意思決定、例外を探してください。

適切な候補は次のとおりです：

• 例外処理時間。 AIシステムが処理できないケースを解決するために必要な労力を測定します。
• 繰り返しのコミュニケーション。 文脈の欠落や不明確な回答によって生じる追加のやり取りを追跡します。
• 手作業によるレビュー。 人による検証を必要とするケースの量を測定します。
• 保守の労力。 システムの更新とテストに必要なリソースを追跡します。
• 管理コスト。 安全性およびコンプライアンスのリスクを管理するために必要な労力を監視します。

これらの指標は、自動化後に複雑性がどこへ移動したかを示します。

信頼を実証的に測定してください

2つ目の領域は信頼です。ステークホルダーは、AIの出力が信頼できるかどうかを問うでしょう。この問いは、最終結果が入力データ、モデル、ナレッジベース、統制、そしてエスカレーションプロセスに依存する場合に難しくなります。

信頼は実証的に測定できます。チームは既知のデータでシステムをテストし、典型的な故障モードを特定し、異なる形で破綻するさまざまなシステムを組み合わせた場合に何が起こるかを確認できます。

パイロットから実装へ移行します

AIのパイロットから本格的な実装へ移行するには、ステークホルダー、複雑性、信頼の観点から既存のAI施策をレビューしてください。

構造化されたワークショップは、チームがいくつかの実務的な質問に答えるのに役立ちます。

• ステークホルダー。 AI施策の影響を受けるのは誰ですか？
• 期待される値。 各ステークホルダーはどのような改善を体験すべきですか？
• 移転された複雑性。 新しい作業負荷はどこに発生しますか？
• 能力。 どのようなシステム、リソース、スキルが必要ですか？
• リスク。 実装中に何がうまくいかなくなる可能性がありますか？
• 指標。 チームは進捗と成果をどのようにモニタリングしますか？

戦略実行キャンバスは、この議論の出発点として使用できます。これは、ステークホルダーのニーズを目標、能力、リスク、前提、指標と結び付けるのに役立ちます。

Alexis Savkín

Alexis Savkinは、戦略アーキテクトであり、バランスト・スコアカードを中核とする戦略実行ソフトウェア・プラットフォームであるBSC Designerの創設者です。彼は、組織が戦略を測定可能な戦略的目標、KPI、および施策へと落とし込むことを支援しています。Alexisは、Strategy Execution Canvasの考案者であり、戦略とパフォーマンス測定に関する100本以上の記事の著者であり、また定期的な講演者でもあります。