こんにちは、アジャイル事業部のみちのすけです。re:Invent 2025 に現地参加しています！

この記事は re:Invent 「From Vision to Value: Scaling Gen AI with Speed to Reduce TCO with AWS (COP215-S)」のセッションレポートです。

Tech Mahindra の Srini さんが、生成 AI の PoC を本番環境に移行させるための戦略と、実際の TCO 削減事例について紹介されていました。

概要

セッションでは、生成 AI 導入における課題と、Tech Mahindra が AWS と共に実践している本番環境移行のアプローチが語られました。特に印象的だったのは、PoC の本番化率がわずか 5%という現実と、顧客サポートの自動化による 50% のコール削減、詐欺検出の解決時間を 7 日から 24 時間以内に短縮という具体的な成果です。

こんな方におすすめ

  • 生成 AI 導入を検討しているが、PoC から本番環境への移行に課題を感じている方
  • AI プロジェクトの TCO 削減に興味がある方
  • カスタマーサポートや詐欺検出などの具体的な AI 活用事例を知りたい方
  • エージェント AI の実装を考えているエンジニアや IT マネージャー

登壇者

  • Srini さん（Tech Mahindra, Function Head – Innovation and Emerging Technologies）

生成 AI 導入の現実：わずか 5% しか本番化されていない

Srini さんはまず、生成 AI 導入における厳しい現実を共有されていました。

多くの IT 企業が生成 AI の PoC を行い、エージェントやその他の技術について話していますが、実際に本番環境に移行できているのはわずか 5% とのことです。

さらに、企業における3つの重要な統計データも紹介されていました。

  • 従業員は日常業務に必要なデータを見つけるため、あるいは誰が適切なデータを持っているかを探すために、時間の 25% を費やしている
  • 各企業はコパイロットなどを導入して従業員の生産性を高めるために、約 7% のコストを投資している
  • 最も驚くべきことに、技術への投資の 3 分の 1 が実際には使われていない（GPU、テクノロジー、ソフトウェアなどの分野で）

正直、PoCの本番化率が5%という数字には驚きました。これは多くの企業が同じ課題に直面しているということなんですね。投資の3分の1が使われていないというのも…かなり大きな無駄ですね。

企業における生成 AI の課題を示すスライド

PoC を本番環境へ：5つの重要な原則

この課題に対して、Tech Mahindra と AWS は、本番環境を想定した PoC を作成するための5つの原則を定義したとのことです。

1. PoC を本格的なプロジェクトとして扱う

通常、PoC は概念実証としてのみ見られがちです。しかし、最初から本番環境で提供可能な成果物として考えるべきとのことです。

  • データの品質を考慮する
  • レイテンシを測定する
  • 実際に違いを生み出せるか評価する

2. セキュリティとガバナンスを最初から組み込む

AI 分野で最も重要な質問は「どのようにセキュリティを提供するか？」「どのようにガバナンスを行うか？」です。

PoCの第一段階からこれらを組み込むことが重要だと強調されていました。

3. 段階的な本番展開を計画する

AI は時間とともに改善されるものです。そのため、本番環境を考えるとき、各フェーズからの学びを活かした段階的な展開を計画する必要があるとのことです。

4. エージェント AI は人間を補完するもの

大きな誤解として、「エージェント AI は人間を不要にする」というものがあります。しかし実際には、エージェントは私たちの仕事を補完するためにあるとのことです。

エージェントが大部分の作業を行い、進むにつれて必要な人間の関与を減らしていけるように計画すべきだと語られていました。

エージェント AI の位置づけについて、明確に「補完」だと説明されているのは良いですね。技術導入時の不安を軽減する重要な視点だと思います。

5. 評価とベンチマークを行う

最後に、そして最も重要なこととして、実施している内容を評価し、ベンチマークを行うことが挙げられていました。

  • PoCをベンチマークしているか？
  • どのような結果を得たいのか考えているか？

これらは PoC を作成する際に考慮すべき重要なポイントとのことです。

課題を克服するための5つのアプローチ

Tech Mahindra の戦略：4つの観点で AI を提供

Tech Mahindra は、AI 提供のための戦略を策定したとのことです。

企業が AI を求めてくる際、通常は4つの主要な観点を持っているそうです。

  • 生産性の向上
  • トランスフォーメーション
  • イノベーション
  • ガバナンス

この戦略を実現するために、Tech Mahindra は Tech Mahindra Orion という製品を開発したとのことです。

Tech Mahindra Orion とは

Orion は、NVIDIA をインフラプレイヤーとして、以下の機能を提供するプラットフォームとのことです。

  • ファインチューニング用のモデルへのアクセス
  • RAG（Retrieval-Augmented Generation）リポジトリの作成支援
  • タスクを自動化するエージェントの起動支援

これにより、スピード、相互運用性、セキュリティとガバナンスが実現されるそうです。

Orion は AWS 上でホストされており、Tech Mahindra は AWS の Bedrock でエージェントを開発し、多くの AWS 認定資格保有者を抱え、AWS とコア領域で共同研究を行っているとのことです。

詳細はブース 1284 で確認できるとのことでした。

TechM Orion の機能アーキテクチャ

Tech Mahindra と AWS のパートナーシップ

事例1：エンジニアリングサービス企業のカスタマーサポート自動化

最初の事例は、1950年以来存在する米国のエンジニアリングサービス企業についてです。

課題

この企業は、カスタマーサポートに従事する 75 人のエージェントを抱えていました。

これらのエージェントは多数の電話に対応していましたが、その結果として以下の問題が発生していたとのことです。

  • カスタマーセンターへのアクセスを試みる人々のための長い待ち行列
  • 生産性への悪影響

ソリューション

Tech Mahindra と AWS は、生成 AI ベースのチャットボットを作成する共同ソリューションを提供したとのことです。

技術的には以下のような構成で実装されたそうです。

Amazon Lex で自然言語理解

Amazon Lex は、自然言語理解（Natural Language Understanding）を使用するツールとのことです。

顧客がクエリを入力すると、そのクエリの背後にある意図を理解し、情報を AWS Lambda に渡します。

AWS Lambda でオーケストレーション

AWS Lambda は、存在する情報全体をオーケストレーションします。

  • リポジトリ
  • 在庫情報
  • 価格設定

これらの情報を取得して Claude Sonnet に渡します。

Claude Sonnet で応答生成

AWS Bedrock には、AWS と Anthropic の複数のモデルがあるとのことです。

Claude Sonnet は Anthropic のモデルの1つで、複雑なユースケースの解決に使用されるそうです。

このモデルが Lambda からの情報を受け取り、人間が理解できる形で Lex に渡し、その情報がエンドユーザーに届くという流れとのことです。

成果

この実装により、以下の成果が得られたとのことです。

  • 受信していたコールの 50% を自動化
  • 顧客に生産性をもたらした
  • 同じ 75 人のエージェントが、実際の販売により多くの時間を費やせるようになった
  • 50,000 ドルの収益を生み出した

自動化によって既存の人員がより価値の高い業務に集中できるようになったのは、理想的な結果ですね。コスト削減だけでなく、収益向上にもつながっているのは素晴らしいと思います。

Case Study #1: カスタマーサポート自動化の事例

事例2：フィリピンのBFSI企業における詐欺検出の高速化

2番目の事例は、フィリピンの企業についてです。モバイルと送金を主に行う BFSI（Banking, Financial Services, and Insurance）企業とのことです。

企業の背景と市場

この企業は過去数年間好調で、2024年には以下を達成したとのことです。

  • 9,400万人の消費者
  • 500万ドルの時価総額

フィリピンは送金に大きく注力している国で、送金分野は 2030年まで年間 30.3% で成長している市場とのことです。

課題：アカウント乗っ取り（ATO）

しかし、この顧客は障害に直面しました。

金融の世界では、アカウント乗っ取り（Account Takeover, ATO）というものがあります。これは、他人があなたの詳細情報を偽装してアカウントを乗っ取り、悪意のある行為を始めるというものです。

アカウントに何か問題が発生したことに気付くと、すぐにカスタマーサポートに連絡します。

この顧客でも同じことが起こっていましたが、カスタマーサポートチームは通常、解決に 7 日かかっていたとのことです。

金融ビジネスで7日かかっているということは、信頼性の損失について語っているに等しいと指摘されていました。

ソリューション：Fraud Sentinel

企業は Tech Mahindra にアプローチし、Fraud Sentinel と呼ばれるプラットフォームを作成したとのことです。

2つのことを実施したそうです。

1. AWS Step Functions で詐欺検出プロセスを自動化

AWS の製品である AWS Step Functions を使用して、詐欺検出プロセス全体を自動化したとのことです。

通常、手動で行われていたことが、プロセスフローを通じて行われるようになり、詐欺検出がはるかに簡単になったそうです。

2. 生成 AI ベースのチャットボット

生成 AI ベースのチャットボットを作成し、詐欺アナリストが通常のビジネス言語を使用してチャットボットや専門家と対話できるようにしたとのことです。

成果

これを実施することで、以下の成果が得られたとのことです。

  • ATOケースの解決時間を 7日から24時間未満に短縮
  • 解決時間だけでなく、SLAも1日に短縮
  • 信頼性を失っていた企業が、顧客満足度指数（CSAT）を 10% 向上
  • フィリピンでその分野のリーダーであり続け、拡大中

7日から24時間未満への短縮は…かなりインパクトがありますね。金融業界での信頼性回復という点で、非常に重要な改善だと思います。

Case Study #2: 詐欺検出システムの事例

ビジネスアウトカムにフォーカスする

Srini さんは、ビジネスにフォーカスする際に何を見るべきかについても語られていました。

技術よりもビジネス成果

通常、技術者が顧客に会うとき、最新の技術について話したり、それがどのように役立つかを説明したりすることに満足しがちです。

しかし、フォーカスすべきは顧客が求めているビジネス成果であり、それをどう解決できるかだと強調されていました。

通常の自動化ソリューションで顧客のニーズを満たせるなら、大規模言語モデルやRAGリポジトリを使うというアイデアを提供するよりも、それを選ぶべきとのことです。

この視点は当たり前のようで、実際にやるのは難しいですよね。技術者はつい新しい技術を使いたくなってしまいますが、顧客のビジネス成果を最優先に考えるという姿勢は見習いたいと思います。

コストに焦点を当てる

2つ目のポイントは、コストにフォーカスしているかという点です。

ソリューションを検討する時点から、コスト経済性を考慮しているかが重要とのことです。

例えば、トークンのコストが高い GPT-4 やその他のモデルを使用する傾向がありますが、それを考慮に入れているでしょうか？ 良い悪いを言っているのではなく、経済性を計算する際にそれを考慮しているかが問題だと語られていました。

PoCを適切に本番グレードに計画する

3つ目は、先ほど話されたP0Cを適切に本番グレードに計画しているかという点です。

測定する

最後に、そして最も重要なこととして、実施しているすべての作業を測定することが挙げられていました。

  • 実施しようとしている PoC を測定する
  • 実施しようとしているプロジェクトを測定する
  • どのように構築し、何を得たいのか

これが最も重要なフォーカスポイントだとのことです。

実装のアプローチ

Srini さんは、通常の実装アプローチについても説明されていました。

顧客との議論では、まず問題が何であり、その問題が実際に顧客にどのように影響しているかを理解しようとするとのことです。

最初の事例

カスタマーサービス担当者が、販売やクロスセルを行うべきなのに、クエリ処理に忙殺されており、その処理により多くの時間がかかっていたため、企業はビジネスを失っていました。

2番目の事例

顧客はビジネスを獲得していましたが、信頼性を失っており、成長する送金市場において長期的に影響を与える可能性がありました。

ソリューション設計

ビジネス成果に焦点を当て、その後、検討段階に戻って考えるとのことです。

  • AI を使用するのか？
  • 生成 AI を使用するのか？
  • RAG リポジトリを使用するのか？
  • どのようなソリューションを試したいのか？

全体的なフォーカスは、どのようにビジネス成果を導き出すかにあるべきだと語られていました。

大規模言語モデルは万能薬ではない

Srini さんは、エージェントと同様に、大規模言語モデルも万能薬ではないと指摘されていました。

Tech Mahindra は Enders という12億パラメータのモデルを作成し、GPT などとベンチマークを行ったとのことです。

独立機関により、トークン化の比率が他のモデルよりもはるかに優れていることが判明したそうです。

これは、大規模言語モデルをパラメータ数だけで判断するのではなく、どのようにファインチューニングされ、どのように学習されたかに基づいて判断しているという事実を示しているとのことです。

コスト、ビジネス成果を見て、PoC を本番グレードに移行しようとする、これが両方の顧客との取り組みで学んだことだと締めくくられていました。

パラメータ数が多ければ良いというわけではないんですね。ファインチューニングの質が重要というのは、モデル選定の際に参考になると思います。

その他の取り組み：メタバースと量子コンピューティング

セッションの最後に、Srini さんは AI 以外の取り組みについても触れられていました。

メタバースとイマーシブ体験

イマーシブ体験と AI を組み合わせて、多くのビジネスプロセスをシミュレートすることに取り組んでいるとのことです。

例として、以下が挙げられていました。

  • 鉱山会社向けのデジタルツイン
  • 電話会社向けの光ファイバー敷設のデジタルツイン
  • 金融プロセスの解決方法のデジタルツイン

これらは、AI とイマーシブ体験（メタバースと呼ばれるもの）の組み合わせで実現しようとしているとのことです。

量子コンピューティング

AWS と協力して、量子コンピューティングを実践に導入することにも取り組んでいるそうです。

  • 詐欺検出などのケースを解決するために量子コンピューティングを使用
  • 量子を使用したルート最適化

これは AWS の製品である Amazon Braket を使用して取り組んでいるとのことです。

量子コンピューティングまで実践に導入しようとしているのは先進的ですね。特に詐欺検出やルート最適化など、実用的な用途に焦点を当てているのが興味深いです。

まとめ

セッションを通じて、生成 AI のPoCを本番環境に移行させるための実践的なアプローチを学ぶことができました。

特に重要だと感じたポイントは以下の3点です。

  1. 現実を直視する：PoCの本番化率が5%という厳しい現実を認識し、最初から本番環境を意識した設計を行う
  2. ビジネス成果にフォーカスする：技術先行ではなく、顧客のビジネス課題を解決することを第一に考える
  3. 測定とベンチマークを怠らない：実施している内容を常に評価し、期待する成果を得られているか確認する

2つの具体的な事例では、カスタマーサポートの50%自動化や、詐欺検出の解決時間を7日から24時間未満に短縮するなど、明確な成果が示されていました。これらは単なる技術デモではなく、実際のビジネス価値を生み出している点が印象的でした。

また、エージェント AI は人間を置き換えるのではなく補完するものだという考え方や、大規模言語モデルがパラメータ数だけで判断されるべきでないという指摘も、AI 導入を検討する際の重要な視点だと思います。

Tech Mahindra と AWS の事例から、生成 AI プロジェクトを成功させるには、技術的な優秀さだけでなく、ビジネス理解、コスト意識、段階的なアプローチが不可欠であることが分かりました。

Vision to Value: 4つのフレームワーク

参考リンク