プロダクトに生成AI技術をどう取り込むか？ーAlexa Cookpadを例に
こんにちは、デザイナーの橋本 (@hashcc) です。
4ヶ月ほど前にAmazon Alexa版クックパッドアプリ向けにGPT-3を使ってAIレシピ要約機能を実験的に導入していました。今回はこの機能の構想からリリースまでのプロセスを書いてみようかと思います。
作る前にざっくり作り方がわかる機能を作った
Amazon Alexa版クックパッドアプリは、音声やタッチで料理をガイドするアプリです。レシピ検索や作り方画面を音声やタッチで操作できるので、「濡れた手でスマホを触りたくない」といった悩みを減らし、快適に料理ができるようにするものです。
今回はOpenAI社のGPT-3を使って、このアプリの作り方画面に、作り方の端的な説明を入れてみました。これによって調理前に作り方のイメージをつけて、作り方を1から10まで見ることが不要になることで、より手早く調理にかかれるようにしました。
開発の流れや試行錯誤ポイントについて書きながら、GPTという武器をどう使うかな〜と悩んでる人のなにかのヒントになればいいかなと思ってます。
そもそもは調理を楽しみにすることにフォーカスしたアプリ
Alexa版クックパッドアプリがどういうものかはちらっと書きましたが、補足としてこのアプリが力点を置いているのは「調理」です。アプリの目的も「毎日の調理を楽しくする」ことにあります。
なぜそこに至ったか別記事に譲りますが、そこに力点を置いてから、例えばこんな風に調理を楽にする機能をいろいろと導入していました。
初期の要約機能の開発と背景
そうして「調理を楽しくする」ことに集中して開発していた結果、実はGPTによるレシピ要約機能を入れる前にも、要約機能が必要そうだねとなって、機能開発を行っていました。
端緒となったのはユーザーインタビューです。調理の現場を知りたいなと思って、アプリ利用者さんにユーザーインタビューを行ったことがあるのですが、何人かはレシピ作り方画面を開いたときに1から10まで手順を見ていたのです。
「Alexa、次の手順・・」
「Alexa、次の手順・・」
「Alexa、次の手順・・」
とAlexaに話しかけながら作り方を頭に入れてる様子は、どう考えても面倒そうです・・
よって、レシピの作り方を短くまとめて、最初に伝えるのはどうかと考えて試してみることにしました（要約入りレシピをプロトタイプして再度テストしてみたら、いい結果が出たのもありました）
ただ、結論を言うと、これは50-60点くらいの出来までしか詰められませんでした。
例えば肉じゃがは「じゃがいもなどを食べやすく切り、鍋に肉や野菜を入れて炒め、煮詰める料理」と言えますが、日本語の複雑さやレシピの書かれ方の多様性もあって、「切って、炒めて、煮詰める料理」とまでしか解析できなかったのです（食材と工程の係り受け関係がわからないケースも多いため）
GPTを利用した要約機能の開発
機能リリースから2年、ChatGPTが話題になりだした2022年末に、これはあの頃考えていた要約がもっといい感じにできるんじゃないかと考えて、同僚とプロトタイプしながら、どういう形で導入すると良いのか一緒に考えていました。
それと並行して、東大松尾研の資料や関連する論文を解説している記事なども見つつ、どういう原理だから何が得意・苦手なのかを理解し、直感を補足しながら進めていました。
ちなみに、レシピ要約とは別にアイデア発想など他のアイデアも考えていて、社内ブログにいろいろ投下したりしていたのですが、初手としてこの武器を情報圧縮（要約）に使うほうが利便性をわかりやすく感じられそうと考えていました。
開発はとてもスムーズ
開発・・といってもプロンプトを考えて出力して評価するくらいなので、難しいポイントはあまりなかったです。
それに、先の要約機能開発で評価用レシピを決めていたり、良い要約の基準を作っていたりしたので、そのプロセスもスムーズでした。
プロンプトに要求を詰め込みすぎると、かえってアウトプットがバグりがちなので、いい感じに要求を圧縮した抽象度のプロンプトを考えるのがコツでしょうか？ いわゆる深津式プロンプトによる出力空間の絞り込み方も参考にしながら、プロンプトを考えていました。
あとは、アウトプットが要件を満たしていなかったら（要約なのにやたら長い文が出てくるなど）再度要約処理させるみたいなことも試しつつ、クオリティの担保を狙ったりしました。
この辺はOpenAI側が出している資料でも解説されていますね。
要約例
プロダクトに適用してみよう
チーム内でプロダクトに適用してみて数字を見たいという合意はあったものの、実際に出してみるにあたって考えるポイントはいくつかありました。
パフォーマンスなど既存の当たり前品質を損なうことはないか？
データを第三者（OpenAI）に送信することに問題はないか？
作者さんやレシピを探している人に迷惑がかかることはあるか？
どうやって評価するか？
パフォーマンスなど既存の当たり前品質を損なうことはないか？
例えば、レシピ要約を追加するのに追加で3秒間APIレスポンス待ちの時間が発生しますとなると、それは厳しいでしょう。
かといって、ボタンを押すると要約内容を生成するというのも「調理時の手間を減らしたい」という目的からすると、あまり良くは見えません。
となると、静的にデータを生成しておいて埋め込むという形になります。
とはいえクックパッドには386万のレシピがあります。当時1レシピあたり0.3円程度の生成コストだったので、全レシピだと1回の生成で130万円ほどかかってしまい、これはトライにしては高額すぎます。
ただ、アクセス分布を出してみるとアクセス上位2000レシピで全体の13%のアクセスをカバーできることがわかりました。PVを考慮すると評価には十分そうということで、このレシピ数でGoしてみることにしました
（結果的にOpenAI APIの無料範囲内でできてしまいました）
データを第三者（OpenAI）に送信することに問題はないか？
プライバシー的な観点から非公開データを第三者に送る場合は、適切な情報管理になるように対応が必要になりますが、今回は公開レシピデータなのでこれは問題なかったです。
作者さんやレシピを探している人に迷惑がかかることはあるか？
ChatGPTも嘘をつくことがありますから、オリジナルとは全く異なる要約が生成されるリスクも少ないながらもありました。そのリスクは以下のように解決してみました。
レシピ作者さんが意図とは異なる作り方を紹介しているように見える
→ 作者さんではなく、AIが生成したことがわかるようにする
ユーザーが低品質な内容を継続的に見ることで、利用意欲を失ってしまう
→ こちら側で事前に内容をチェックした上で、ユーザーが任意で要約機能を無効にできるようにする
どうやって評価するか？
要約がある事自体の満足は先のユーザーインタビューで見えていたので、利用品質が問題ないかという点で、要約部分を閉じたり無効にしたりしている人の比率を当初のKPIにしていました（ただ、この時点でも要約有無でのリテンションの変化を見て両方の視点から評価したほうがよかったですね）
出してみると不満がある人はかなり少なかったので、そのまま継続して出すようにしています。
おわりに
最初の社内ブログで構想を練ってからプロダクトをリリースするまで3週間程度ですから、生成AIはうまく使えば、デザイナー自身でとんでもない速度でサービスの価値を増幅させる武器になりうると感じました。
今回書いたように、新しい武器の特性を素早くキャッチして、プロダクトで実現したい課題とかけあわせながら、うまく価値を形にしていくプロセスは楽しいし、大事な部分だと思います。
今後、生成AIもおそらく画像入出力に対応するなど、できることがどんどん広がっていくと思いますが、このダイナミズムを楽しみながら、新しい価値を作れるように、開発していきましょう。