お客さんに届けていく上で大切にしているのは“期待値コントロール”

南野充則氏(以下、南野):では、次のお題に移っていきたいと思います。次は、顧客へどう提供していくかというところですね。

生成AIの技術やプロダクトをお客さんに届けていく上で大切にしていることをまたお三方からいただければと思います。

小城久美子氏(以下、小城):私が大事にしているのは、期待値コントロールです。

お客さまの大事なデータをお預かりして、いいモデルを作って、みなさんにとっていい性能のあるモデルを提案していければなと思ってはいるんですが、私たちは、お客さんがどんなデータをお持ちなのかもあまりまだわかっていないですし、どんな業務プロセスなのかも一緒に作り上げていかなければいけないと思っていますので。

今までみたいにラッピングされたプロダクトを「どうぞ」と渡すというよりは、「一緒に作っていきましょう」というかたちでやっていくというのを今は大事にしていて、そうやって、一緒に生成AIのユースケースのある世の中を作っていきたいなと思っています。

効率化においてKPIをきちんと設計して測っていくことが大事

大友太一朗氏(以下、大友):そうですね。生成AIはなんでもできそうというような、期待値コントロールという言葉がありましたが、期待がすごく高まっている一方で、何を生成AIにやらせるのかというところ、これは、今日繰り返し言っていますが、自分たちの業務の中のどのオペレーションに生成AIを当てていくのかというところを特定するところがまず大事なのかなと思っています。

それと同時に、じゃあ、オペレーションが効率化されるというのは、何をもって測るのかというところをきちんと設計することがすごく大事な気がしていて。

「社内チャットボットを作りました」と言って、みんな使っているかなというのを、なんとなく、「MAUは何人です」、「ふーん」みたいな感じだけではなくて。

効率化したというのは、結局コスト削減にどれぐらいつながっているのか。どの業務がどれぐらい減っていて、何人がどれぐらい会議に出なくなっているんだ、みたいな話とか、KPIをきちんと設計してそれを測っていくというところがすごく大事なのかなと思っています。

「生成AIを使うことが目的になっていないか」を意識する

友松祐太(以下、友松氏):期待値コントロールという話がありましたが、もう常々痛感しているところです。

というのと同時に、やはり今、生成AIに対する検討のフェーズが、各社、本当にまばらというか、「とにかく生成AIをやっていくぞ」というフェーズもあれば、「すでに1度検証しました」というフェーズとかもあって、それに対してアプローチの仕方がぜんぜん変わってくるなというのは1つ思うところです。

やはり、生成AIを使うことが目的になってしまうことが多くて、生成AIでこれを解決しましたという時に、本質的に解きたかった問題が、実は遠回りしているケースがすごくあったりするので。

本来は業務フローを改善することで、実は近道できたとか、ここは古典的な手法を使うべきというところもあったりするので、そういうところの軸を見失わないようにというのは、お客さまに提供する上でも大事にしたいポイントだと思っています。

南野:ありがとうございます。

「できます」とは言わないことを心掛けている

南野:うまい具合に期待値コントロールするためにというところで、たぶん上司の人に説明して、「これに投資していいっすか?」という話もありますし、お客さんとやりとりしながら、「このプロダクトを作ったら、このぐらいのROIで、このぐらいの品質です」というところのやりとりをしていくと思うんですけど、その時に、心掛けているトップ3つを教えてもらいたいなと思います(笑)。

じゃあ、友松さんからお願いします。

友松:そうですね。まずは、「できます」というのは言わないということを、心掛けています。

生成AIを使うと、できそうというのは、なんとなくイメージがつくと思うんですが、そこから突き詰めていった時に、やはり実現する時に足りないポイントだったり、リスク的なポイントだったりがあるので、言葉だけ独り歩きしてしまうことがけっこうあるので。

先ほど「並走して一緒に作っていきましょう」という言葉がありましたが、きちんとそこの条件を詰めて、検証をした上で進めていくことがすごく大事かなと思っています。

「一緒にちょっと模索して作っていきましょう」と正直に伝えている

南野:1人1つにしましょうか。

大友:助かります(笑)。期待値コントロール……そうですね、AIに関係なくですが、できないことをできると言わないというのは、まず前提としてあります。だから、やりたいことを明確にするというのも、先ほど言ったとおりなんですが、生成AIを使う方々が何を目指すのかというイメージ、共通認識をまず持つというのがあって。

これはできるのかというところは、僕らがわかっていれば、「できます」「できません」と言えますが、わからないところは、「わかりません。だから一緒にやりましょう」と言うことが今はまだ必要だと思っていて、使いながらやっていくしかないんですという話はけっこうあるなと思っています。

「Microsoft 365 Copilot」が出た時に、Excelが英語にしか対応していなかったり、パワポで「イケてるスライド作って」と言ってたらブワーってできます、みたいなものをみなさん期待していて、「ぜんぜんできないじゃん」、「こんなアメリカンなスライド使えないよ」みたいなことをけっこう言われたんですけど。

そこの期待値のコントロールについては、僕らは、営業の中で伝えるようにはしています。

やはり、使い方は、僕らも模索している最中なので、「こんな使い方で、ここまで効率化できた」みたいなところや「一緒にちょっと模索して作っていきましょう」みたいなところは、最初にけっこう正直に伝えるようにはしています。

開発の優先順位をどうつけているのか?

南野:稟議の時って、いろいろなプロジェクトが走っているわけじゃないですか。これやろうと決めていると思うんですけど、どういう感じで決まるもんなんですか?

大友:要するに、「導入して効果が出るのか?」みたいな話ですか?

南野:たぶん、相手側よりも自社でいろいろなパーツを開発していたり、「このユースケースに、これ効きそうだ」みたいなパーツを、たぶんMSさんは作られていると思うんですけど、そのパーツごとの意思決定とか、ここを掘ってみようとか、優先順位をどうつけるんですか?

大友:プロダクト開発のほうでということですよね。おそらく、プロダクトごとにチームがきっちり分かれていて、意思決定の重心がかなり低いのがMicrosoftの特徴だと思っています。

なので、プロダクトオーナーごとに意思決定権を持たされていて、プロダクトのプリンシパルみたいなものは、そのプロダクトオーナーが作ってよいというところだと思います。

全体としてMicrosoftが目指している姿は、やはりCEOまで上がって文化形成しているので、それに沿っているかというところは、常にトラックされてはいるけど、どこを掘ってみようみたいなのは、各プロダクトオーナーやエンジニアレベルで判断をしていると思います。

南野:ありがとうございます。

まずは実現可能なユースケースを特定する

小城:稟議を取る時にどうすればいいのか、どういうことを気をつけているかのいい話をしたいなと思って、今ずっと考えていたんですけどまだ私のレベルが足りていないので、最近した失敗の話をちょっとしようと思います。

私は汎用モデルを作っているので、いわゆる、「Ask me anything」、なんでも聞けるぞ、みたいなところを狙いがちで、「こういう業界でこういうことがしたいです」みたいな感じで大きいビジョンを書いて研究サイドに持って行っては、「いや、それじゃぜんぜんわからないよ」と怒られることを繰り返しているなと思っています。

最近その中で1つ、「絶対やったほうがいいよ」と言われたのは、ユースケースをきちんと特定しようねということです。これは当たり前の基礎にして基礎なんですが、どんなお客さんのどんな反応に対してどういった反応を返すのかみたいなところ、どんなユースケースなのかというところをまずしっかり言語化しましょうというのが、1つ、共通認識として取ったなと思っています。

今までだったら、「こういうTAM(Total Addressable Market)に対してこれぐらいの数字を」みたいなところから意思決定していくことができたのですが、ちょっと今は、フィジビリ(フィジビリティ)からやらなければいけないなと思っています。

「まず実現可能なユースケースとしてここを目指しましょう。その結果としてこういうTAMにいきますね」みたいなところの考え方をするようになって、今までとはちょっと順番が変わってきたなと思っています。

南野:ありがとうございます。

人が限界だったところにチャレンジすることで市場を作っていける

南野:ちょっと時間がだんだんオーバーしてきているんですけれども、最後に1問、お願いしたいことがあります。

最後の質問になるんですけど、今のLLMのプロダクトを作っていく中で、今だとどういう切り口のユースケースだと勝ちパターンにはまるんじゃないかなと、現状、自分たちの仮説の中で思っていることがなにかあれば、ぜひ、1つずつお願いします。

小城:勝ちパターンになるものは、難しいなと思うんですけれども(笑)、まず思っているところとしては、目の前の業務を効率化できるというところで、1つ目の勝ちパターンがあるなと思っています。

ただ、そのあとのユースケースのほうが、大きな「勝ち」としては必要になってくるんじゃないかな、と思っていて。

例えば、よくあるユースケースで言うと、パーソナライズがあると思います。今までは、人間が1人しかいなくて、うまく説明できる人が1人しかいませんでした。ただ、これからは、生成AIがそれを代替できるなら、今日聞いていただいている方の数だけ、すごくうまく説明できる人を作ることができて、各々、説明というのをコンテンツとして作っていくことができるようになることもあり得るんじゃないかな、と思っています。

というところで、今まで人が限界だったところにチャレンジしていくような勝ちパターンを見つけていくと、大きなTAMに対して市場を作っていけるんじゃないかな、と思っています。

南野:ありがとうございます。

「自然言語で行われている会話から新しい知見を引き出す」が勝ちパターンになる

大友:もうちょっと具体的なユースケースの話で言うと、例えば社内だったり、顧客と会社とそのお客さまとの間でのコミュニケーションというところ、自然言語で行われている大量の会話みたいなものが、今まではデータとして積もっていっていなかったんですよね。

それを溜めていって、そこから知見を引き出すみたいなところは、今まで、人間の頭だとやりきれなかった部分だと思うんですけど、生成AIを活用することで、新しい知見をそこから引き出すことができるようになってきているのかなと思っています。

例えば、コールセンターとかカスタマーサポートみたいなところで、どんな問い合わせがどんな感情でされていて、どう解決されているのかみたいな話もそうですし、あとは、社員同士のコミュニケーションとかですね。

ほかにも、会議の中で何が話されているかとか、それはどういうプロセスでどんな力学が働いて意思決定されているのかみたいなところって、まだ、あまりひもとかれていない領域なんじゃないかなと思っています。

そこの部分って、生成AIがすごく得意とする領域だと思っているので、やはり人と人のコミュニケーションが発生しているけれど、今まであまりひもとかれて知見が吸い出されていないような領域を見つけるのは、勝ちパターンの1つになっていくんじゃないかなと今思っています。

南野:ありがとうございます。

LLM×いろいろな技術で新しい価値を作っていく

友松:ものすごく難しいんですけれども、今私たちがやっていて思うところをお話しすると、ボイスボットっていう事業があって、これはものすごくいろいろな技術が組み合わさったものになっています。音声とか言語とか、ヒューマン・コンピューター・インタラクションとか、いろいろな技術が組み合わさっていて、そこにLLMが入ってくると思うんですけれども。

技術の組み合わせをして新しい価値を作っていくというところと、それを使った時に、本質的にどういう新しいユーザー体験を作れるかというところ。ここを開発していくところが、ある意味参入障壁でもあるし、技術の強みを活かせるところだったりもするので、そこが1つ、勝ちパターンになるんじゃないかなと、AI Shiftで進めているところになっています。

南野:ありがとうございます。そうですね、ここまででパネルディスカッションはいったん終了していきたいと思います。みなさん、すごく貴重なお話をありがとうございました。

(会場拍手)