AIの利用者数も、入力されるプロンプトの数も増えています。それでも経営会議で「在庫や納期、顧客対応はどう改善しましたか」と問われると、答えに詰まるかもしれません。AIを使った実績と、事業が良くなった実績は、同じではないためです。生成AIの導入を投資として評価するには、この隔たりを埋める必要があります。

AWSでApplied AI Solutions部門を率いるシニアバイスプレジデントのコリーン・オーブリー氏は、AIのために新しい評価指標を考え出すことに懸念を示しています。同氏が重視するのは、企業が以前から追ってきた事業指標です。Amazonの経営幹部チーム「S-team」の一員でもある同氏は、20年以上にわたり販売事業者や広告主向けの製品に携わってきました。その経験を踏まえ、AIの価値も事業上の変化から判断するよう促しています。



ここで区別したいのは、利用状況を把握する指標と、投資判断を支える指標です。プロンプト数や利用率は、ツールが現場に届いているかを知る手掛かりにはなります。しかし、それだけでは問い合わせの解決率が上がったのか、採用にかかる期間が短くなったのかまでは分かりません。トークンというAIの処理単位に注目しても、その消費量から事業価値を直接読み取ることはできないでしょう。

この考え方は、技術面の評価を不要にするものではありません。回答の品質や処理コストを確認しながら、その改善が業務のどの結果につながるかを説明する必要があります。例えば、回答生成が速くなっても、確認や修正に時間がかかれば、顧客を待たせる時間は減らないかもしれません。評価の起点を事業指標に置くと、モデルの性能だけでは見えにくい工程まで、検証対象に含められます。

測るべき成果を決めるには、AIを導入する範囲も絞る必要があります。オーブリー氏がAWSのアプリケーション事業を検討した際、対照的な例になったのが、コンタクトセンター向けのAmazon Connectと、初期のAWS Supply Chainでした。両者から得られる教訓は、既存製品と同じ機能をそろえることが、必ずしも顧客の課題解決につながるわけではないという点です。

同氏によると、初期のAWS Supply Chainでは、長年の蓄積を持つERPベンダーに機能面で追いつこうとする開発が進んでいました。ERPは、会計や購買、生産などの情報を統合して管理する基幹業務システムです。その広い機能群を追いかければ、開発対象も広がります。Amazon自身のサプライチェーン運営経験があっても、製品としてどこから価値を出すかは、別の判断になります。



Amazon Connectが出発点に選んだのは、AWSのネットワーク基盤を生かした音声品質でした。Amazonの顧客サービスを運営してきた経験を背景に、顧客と課題を理解し、対象を絞って製品を育てたと説明されています。オーブリー氏はこの考え方をサプライチェーンにも適用し、Connect Decisionsとして方向を見直しました。焦点を当てたのは、多数の情報への対応に追われ、判断するころには好機を逃してしまう計画担当者です。

日本企業がこの考え方を取り入れるなら、「調達業務をAI化する」といった大きなテーマを、具体的な判断場面まで分解するとよいでしょう。例えば、例外案件の確認が滞る場面や、複数の情報を照合して対応を決める場面が候補になります。これは導入対象を選ぶための例であり、特定企業での成果を示すものではありません。対象を狭めるほど、誰の何を改善するのか、その変化を何で測るのかを、現場と経営側で共有しやすくなります。

事業指標でAIを評価する例として、AWSはWells Vehicle Electronicsの取り組みを挙げています。同社では、積極的に監視するSKUを20から2,000へ増やしながら、3カ月で在庫を7％削減したとしています。SKUは、サイズや仕様などの違いを含め、在庫を管理する際の品目単位です。監視対象の拡大と在庫の変化を併せて示すことで、業務への影響が具体的になります。

この事例の焦点は、AIへの問い合わせが何回発生したかではありません。在庫として資金が固定される状態をどう変えたかという、運転資本の問題です。運転資本は、日々の事業運営で必要になる資金を捉える考え方です。在庫水準を適切にできれば、資金の使い方を見直す余地につながります。財務部門が把握している指標と結び付くため、技術部門の内部だけで成果を説明する場合よりも、投資の議論を進めやすいでしょう。



ただし、この数字をそのまま自社の削減目標に置くのは適切ではありません。業種や需要変動、導入前の運用が異なれば、結果も変わります。今回示された情報だけでは、AI以外の要因を切り分けた効果や、詳細な測定条件までは判断できません。AWSが示した顧客事例として受け止め、自社では何を比較する必要があるかを考える材料にするのが妥当です。

実務では、導入前の基準値と、成果を確認する期間を決めておくことが出発点になります。在庫を対象にするなら、削減率に加えて欠品や納期への影響も確認したいところです。これは、在庫を減らすことだけを優先して顧客への供給を損なわないための評価設計です。目標とする指標に、守るべき品質やサービス水準を組み合わせれば、数字の改善が実際の事業改善を伴っているかを検討できます。

AIツールを配布しても、最終的な成果物が同じ割合で増えるとは限りません。オーブリー氏が紹介したAmazonのソフトウェア開発では、AIの利用を通じて、コードを書く工程の後にある課題が見えてきました。テストの網羅性を改善すると、今度は変更を本番環境へ届けるパイプラインの問題が明らかになったといいます。

パイプラインは、コードの変更を検証し、システムへ反映する一連の仕組みです。コードを作る速度が上がっても、テストが不十分だったり、人手による作業が途中に残っていたりすれば、本番への反映はそこで滞ります。同氏の部門では、テストやパイプラインの状態を改善し、手作業を減らす取り組みを経て、2026年の本番反映のペースが2倍になったとしています。コード支援ツール単体の効果として理解すべき数字ではありません。



この事例は、AI導入後にどこへ改善費用が必要になるかを考える手掛かりになります。文章作成が速くなっても、確認者の判断待ちが長ければ公開までの時間は縮まりません。情報の分析が速くなっても、利用するデータに不整合があれば、結果の確認に時間を要するでしょう。これらは一般的な業務設計上の例ですが、一工程の効率化と、業務全体の処理時間を分けて見る必要性を示しています。

導入予算には、ツールの利用料だけでなく、後続工程を直すための人員や作業も織り込むことが望まれます。対象業務の開始から完了までを追い、作業時間と待ち時間を分けて確認すれば、次に手を入れる場所を探しやすくなります。AIの利用が増えたのに事業指標が動かない場合も、すぐにモデルを入れ替えるのではなく、改善が途中で止まっている工程を確かめる必要があります。

AIが作業の一部を担うようになると、人の役割も従来の分業だけでは捉えにくくなります。オーブリー氏は、自身のユーザー体験を設計するチームで、デザイナーに初期検証用のアルファ環境へコードを届けることまで求めていると説明しています。Amazonでは「UX tech」という新しい役割も設けられました。設計案を渡すところで責任を区切るのではなく、動くものを通じて体験を検証する方向への変化と理解できます。

同氏がチームに求めているのは、作業の担当にとどまらず、成果に責任を持つことです。ただし、組織設計や目標設定が、その変化に完全に追いついたわけではないとも認めています。AIを導入すれば、新しい役割分担が自動的に定まるわけではありません。どの成果を誰が担い、そのために何を判断できるのかを、組織として整理する必要があります。



日本企業でも、成果を重視する方針を、単なる目標の上乗せにしないことが大切です。例えば、顧客対応の解決率を担当者の目標にするなら、必要な情報へのアクセスや、例外案件を上位者へ引き継ぐ経路も整える必要があるでしょう。本人が動かせない条件を残したまま結果だけを求めると、改善につながりにくくなります。これはAWSの制度を示すものではなく、成果中心の役割設計を自社で実施する際の検討事項です。

評価する仕事の範囲も見直したいところです。AIが生成した内容の確認、誤りの修正、業務ルールの整理などは、最終的な品質を支える作業になります。従来の処理件数だけでは、その貢献を捉え切れないかもしれません。事業部門と人事部門が、期待する成果、必要な権限、品質を担保する責任を同時に話し合えば、現場も新しい働き方を具体的に理解しやすくなります。

AIが適切な答えを出しても、日々の仕事に組み込めなければ成果は続きません。オーブリー氏は、Connect製品群の設計思想を「humorphism」と呼び、AIを人の働き方に合わせることを重視しています。利用者が命令を入力するだけの操作から、状況の手掛かりを捉え、判断を記憶し、仕事を先へ進める体験を目指していると説明しています。これらは同氏が語る設計上の方向性であり、すべての製品で同じ機能が提供されているという意味ではありません。

同氏が懸念するのは、社内の試作から実運用に移るまでの隔たりです。デモでは担当者が操作を案内できても、現場では利用者自身が入力し、結果を確かめ、必要な修正を行います。その過程が煩雑なら、AIの性能が高くても利用は定着しにくいでしょう。製品評価では、モデルの能力に加え、設定、テスト、分析、日常の操作まで確認する必要があります。



導入段階の違いにも注意が必要です。オーブリー氏によると、電子部品などを手掛けるTE Connectivityでは、Connect Decisionsの利用が計画担当者2,000人に広がっています。一方、Connect Talentは2026年9月に一般提供が始まり、初期顧客で導入が進んでいる段階としています。同じ製品群でも利用実績の蓄積は一様ではないため、製品名だけで成熟度を判断することはできません。

自社での次の一歩は、拡大前の判断条件を一枚にまとめることです。改善したい事業指標を一つ選び、導入前の値、評価期間、守るべき品質、成果の責任者を記載します。そのうえで、実際の担当者が通常の業務を通して使えるかを確かめ、後続工程の修正費用も含めて判断するとよいでしょう。利用回数が増えても狙った指標が動かなければ、対象範囲や運用を見直す段階です。次の実証実験を始める前に、いま進めている案件について、この判断条件を現場と財務部門で合意するところから着手できます。