新車のサブスクリプションサービス「KINTO」のシステム開発をはじめとして、トヨタグループの様々なプロジェクトに取り組むKINTOテクノロジーズ様。実証実験として取り組んでいる車内で自然な会話ができるAIサービスをテーマとし、2024年7月に弊社開催のAzure Light-upに参加いただきました。今回はOsaka Tech Labオフィス (大阪) に伺い、その取り組みについてお話を伺いました。
KINTO ONE開発部 プロデュースG Senior Project Manager 出口悟 様
プラットフォーム開発部 Cloud Infrastructure G Senior Cloud Engineer 井木則夫 様
KINTO ONE開発部 新車サブスク開発G Front-end Engineer 楢林祐輝 様
業務システム開発部 業務システムG Engineer 上山晃平 様
今回Azure Light-upの題材になったのは、GPT-4oを使って車内で気軽な雑談、自然な会話ができるAIをつくるプロジェクトでしたね。この取り組みについて、始まりのきっかけを改めてご説明いただけますでしょうか。
井木: KINTOテクノロジーズのOsaka Tech Labのメンバーは普段それぞれ異なる案件に参画しています。集まって何かをすることがあまりないので、「Osaka Tech Labメンバーで何かやりたいよね」という話が出ていたんです。たまたま会話サービスを作っている別プロジェクトのニーズから、LLMを活用して自然な雑談ができるものをPoCで作りたいというアイディアが出て、そこでAzure Light-upの話を聞いて「どこまでできるかは未知数だけどやってみよう」となり、スタートしました。
珍しい機会ですね。プロダクトについても概要をお聞かせいただけますか。
出口: 目指したものは、「自然な会話ができるAI」というふわっとしたイメージでした。AIとの会話には特有のレスポンスの特徴があり、例えば安心感を与えるだとか、空気を読むといったファジーな会話の要件を実現するのは非常に難しい課題です。今回はその難易度の高い部分にフォーカスを当てて取り組むことにしました。メメンバーそれぞれが別の仕事を抱えているため、開発期間はAzure Light-upの2日間とその後の15時間に限定し、集中して取り組みました。全員がAzureを使った開発は未経験という状況のなか、今回これだけ限られた期間で会話ができるサービスの完成まで辿り着けたのはとても良い体験となりました。
Azure Light-upではディスカッションをしながらプロンプトを作成し、その後AzureのPaaS/Serverlessサービスを使って開発を進めました。開催後も社内で調整を重ねてPoC版を完成されており、その過程では実際に車内での検証も行われたとのことでした。
出口: Azure Light-upの後、実際に車を走らせながら調整をしました。楢林さんが後部座席にPCを持ち込んで、私が運転しながら会話を試しました。「今のセリフいまいちだな」とか「こういうシーンあるよね」という気づきを得て、その場でプロンプトを直してさらにレスポンスを評価してみたり。そういった検証を繰り返して、自然な会話ができるようになるまで調整しました。
楢林: これは個人的にも結構良い体験でした。こういうことができるんだと実感できましたね。車内ではプロンプトの書き換えを何度か行いましたが、Cosmos DB上のデータをAzureポータルから簡単に編集できたので助かりました。
車内で検証しながら開発というのは、なかなかない体験ですよね。求められていないものを作ってしまって結局使われないというケースは本当によくあるので、こういった検証は大事ですね。
出口: そうですね。自然な会話を実現するには「ここでこういうこと言わないよな」「なんか違和感あるな」という気づきや感覚が重要なので、開発メンバーがその場で同時に共感しながら、随時プロンプトを何度も修正しながらの検証は本当に効果的でした。
私たちとしても、この段階で車内での検証という発想がなかったのでお聞きして感激しました。思えばLLMを使った開発はプログラミング観点での難しさがあまりないことが多いので、改善を素早く回しやすいはずなんですが、なかなかそこまで踏み出せないケースの方が多いですよね。会社として開発環境の制限が少ないことも大きいかもしれませんね。
出口: たしかに我々は開発を内製の部隊でやっており、ここOsaka Tech Labでもフロントからバックエンド、インフラまで一通り開発ができるメンバーが揃っています。この体制のおかげで、実装・評価・改修を高速で回すことができ、迅速に動けるという大きなメリットがあります。特に、プロジェクトの進行をスピードアップさせる上で、この内製開発の強みが非常に効果的であると感じています。
AIを使った開発ではプログラミングの知識だけでなくビジネスの知識や文章構成の能力も必要になることが多いので、外注開発ではやりとりが多くなりがちです。また今回、アプリケーションやデータベースにパブリックネットワークからアクセスできたのが検証のやりやすさに貢献したと思います。Azureの仮想ネットワークは各リソースに後から設定できるので、PoCの間はパブリックにしておき運用に入る前にVNETに切り替えるというパターンが実現しやすいですね。
今回作成したプロダクトのデモを見せていただきながら、取り組みを振り返っていただきました。現在のPoC版では、音声入力はスマホのマイク、出力はユカイ工学社のBOCCO emoを使って、実際の対話に近い検証をされています。
近隣のお店のおすすめを尋ねるとフレンドリーな口調でカジュアルに答えてくれる
返答がとても簡潔でいいですね。車内で音声質問ができるようなサービスは他にも使ったことがありますが、固い口調で長々と説明されると逆に疲れてしまうことがあります。
出口: テキストベースでずっと検証をしていたときは応答の長さについて全然気にならなかったのですが、実際に車に乗せてテストしてみたらかなり長く感じたんですよね。Azure Light-up中にも応答のトークン数を制限することで短い返答を促す工夫をしましたが、それだけでなく会話自体をショートにするためのシステムプロンプトもいくつか入れています。
返答の長さにはたまに揺らぎがあっても、それはそれで親近感を感じられて良さそうです。
出口: そうですよね。ずっと長い話をされるとしんどいですが、たまにあると運転しながらちょっと面白くなっちゃうとか。Azure Light-upで試したこととして、プロンプトを少し変えるだけでAIのキャラクターや口調がガラッと変わったのが結構感動しましたね。
具体的に口調を指示するだけでなく、キャラクターの属性や性格などの設定をプロンプトで渡すことでうまくいったのを覚えています。
出口: はい、それ以外にもFew shotで会話の例を渡すというのも試しました。あれも1往復の会話だけでなく、3〜4往復くらいの例を書くと結構うまくいくように思いました。他にも、ある程度会話が続いたら話を締めにいくみたいな指示をプロンプトに入れています。こういうことがキャラクターの調整に効くんだなというのを掴めたので、すごく勉強になりました。
最近LLMプロンプトのノウハウがたくさん公開されていて、たとえば間違った情報を回答させないための工夫などはよく見かけますが、こういった口調の調整のようなキャラクター設定に関するナレッジはまだまだ少ないです。今回は業務シーンでの利用時とはうってかわって、創作だとか趣味の領域に近い考え方でプロンプトを作成するお手伝いをできたのがよかったのではないかと思います。
楢林: あの後、色々と改良を加えてみました。ロボットと連携しただけでなく、位置情報を取得してその地域のおすすめスポットを教えてくれるようにしました。やってみて一つ面白かったのが、位置情報として緯度経度をそのままLLMに渡しても理解してくれなかったことです。緯度経度から住所を取得して渡すとちゃんと判断できるなど勉強になりました。
出口: 現状、音声入力時に不要な音を少し拾ってしまうことがあるので、別付けのマイクにしなきゃなというのを検討しています。あとは応答にタイムラグを感じるので、他の音声出力デバイスも試してみたいですね。
Azure OpenAI Service側でのパフォーマンス改善も見込めます。最近プロンプトキャッシュの機能が追加されましたが、今回のようなケースだとシステムプロンプトの内容が固定できるのでキャッシュがかなり効き、コスト削減もできそうです。応答速度でいえば最近GPT-4o Realtime APIのプレビュー版がリリースされました。こちらは返答はかなり速いですが、少し用途が違うかもしれませんね。
Azure AI Studio上でGPT-4o Realtime APIを試行中
出口: すごい。これも組み込みを試してみたいです。
いま試したのは男性の声ですが、他にもサンプル音声が用意されていて面白いですよね。ただ、Realtime APIのモデルの返答は逆に人間っぽすぎて違和感を感じることもあるかもしれません。またこれまでのモデルと違って繋ぎっぱなしの通信なので、料金が高くなりがちなところも注意が必要です。
上山: 今後、ユーザーごとのパーソナライズもしていきたいなと考えています。現状では会話履歴を100件くらい取って入れているだけなので、そこを要約したりとか、キーワードを抽出してニュースに当て込んだりとか。どのようにしてユーザーの好みを発話に反映させるかが課題です。
人間の脳と同じように、短期記憶と長期記憶にざっくり分けて管理するというのも一つの手かと思います。詳細な会話履歴が毎回必要というわけではないですし、トークン数の上限もあるので、重要なキーワードだけを含めるのは効果的だと思います。抽出のタイミングなども含めて、考えることはいくつかありそうですね。
普段はAWSをお使いとのことですが、今回Azureを使ってみていかがでしたでしょうか。
井木: ポータルを使って簡単に設定ができるのがよかったです。たとえば今回Cosmos DBを使いましたが、誰にもやり方を聞いていないのに感覚でリソースを作ることができて、すぐに触れました。デフォルトで最低限の設定がされているのでやりやすく感じました。ただ、他のクラウドと比較するとAzureはまだまだコミュニティ活動が活発でないので、情報収集が少し難しいと感じました。
Azureは昔から難しいチューニングをしなくても性能面で70~80点は取れるような印象がありますね。もちろん今回ご紹介したAzure FunctionsやCosmos DBに関しては80点以上の設定をすることもできます。コミュニティについては、Azureの利用事例はかなり多いもののなかなか発信に至らないケースが多いようで、私たちもより盛り上げていきたいと思っています。KINTOテクノロジーズさんのような内製開発プロジェクトの事例も、もっと広めていきたいですね。
改めて、今回のAzure Light-upはいかがでしたでしょうか。
出口: これまで参加してきたハンズオンとは違って、要件の整理やディスカッション、何を達成したいかにフォーカスする時間を大きく割いていただいたのが驚きでした。Day1の午前の時間で、自然な会話をするためにはどういう情報が必要だとか、提供したいユーザー体験を全員で話して共有できたのがとても良かったです。結果、その後再度大きな議論をすることなく進めることができ、特に実装が進んだDay2では、コミュニケーションが非常に円滑に進み、チーム全体の連携が強化されていることを実感しました。
まずは手を動かしてみようとなって、開発環境の構築から始まるようなプログラムが多いですよね。我々もお客様の状況によって進行をダイナミックに変えていますが、今回はお話をお聞きする中でプロンプトを練ることが最重要だと思い、ディスカッションに時間を使うことにしました。技術的には何か面白かったところなどありましたでしょうか。
楢林: Azure Light-upの2日間である程度土台がしっかり固まっていたので、その後の開発も「これ設計間違ってるんじゃないか」みたいな不安を感じることなく進められました。15時間という短い期間ではあったのですが、とにかくこのまま進めていけば大丈夫だろうと思えたので、本当に良い基盤を作っていただけたなと感じました。最終的にはプロンプトの調整をすることが多かったんですが、シンプルな設計だったので取り扱いもスムーズでした。
出口: 例えばデータベース設計一つとってもいろんな選択肢や検討ポイントがありますが、2日間という縛りがあったからこそ悩まずに思い切ってCosmos DBを選択できたのも良かったですね。
普段からAzure Light-upでは全体を繋ぐことを重視していて、個別の設計は手を動かす前にあまり深掘りしすぎないようにしています。ビジネス上の目的が達成できるかどうかの検証なので、一部時間がなくてできませんでしたというのは避けたいと考えていますし、しっかり動かしてみないと適切な技術がわからないことが非常に多いですからね。
楢林: Azure Light-upの後も、スコープの見極めがうまくできたと思います。実際にニュースの情報を発話させるという案があったのですが、外部から情報を取得するには考えることが多いということで今回はスコープから外しました。逆に、位置情報についてはちゃんと取得して現在地にもとづいた会話ができるところまで完成させようと決めたんです。
今回は、タイムボックス型の開発で取捨選択を強制させられることが逆にメリットになったということですね。私たちも普段からコーディングの細かい部分、たとえば変数の名前とかDIをどうするかとか、こだわって考え始めると数日かかるようなことは、後でクリーンアップすると割り切ってとにかく前に進めるようにしています。
出口: はい。特にプロンプト調整部分では、そのアプローチがプロジェクト進行のスピードを大幅に向上させることができると実感しました。
やりたいことの確証をまず得たいですよね。今回これだけスピーディーに進められたのは環境のおかげでもあります。少し前、たとえばGPT-4が出てすぐの頃は、なかなか応答が返ってこないのでひとまずGPT-3.5で試すようなこともしていて、プロンプトの検証だけで大きな手間がかかる状況でした。ビジネス側・開発側のメンバーが揃った場で何度も反復検証できるというのが、みなさんにわざわざ会場までご足労いただきオフラインで開催できたことの大きなメリットだと思います。