ChatGPTを駆使して実現したAIアシスタント機能の開発ストーリー
プロダクト開発部のバックエンド開発グループでエンジニアをしているゆうまです。
このたび、2023年4月24日に弊社のサービスにAIアシスタント機能(β)をリリースしました。今回は、その開発プロセスにおいて検討した内容や設計についてご紹介いたします。
AIアシスタント機能とは
AIアシスタント機能は、ChatGPTを活用した出品者の支援をする機能です。
サービス内容の特徴を1~5個と、出品者の経歴を入れると「サービス内容」の原稿をChatGPTを用いてAIが提案する機能です。
AIアシスタント機能の導入
コストはかけたくない
今回の機能リリースにあたり、重要な要素としてスピードとサーバーコストが挙げられます。この要件を満たす設計として、最初に思いついたのがLambdaでした。Lambdaであれば、サーバーの構築が必要なく、Serverless Frameworkの設定ファイルを書くだけで済むため、費用も安く抑えられます。
しかし、フロントエンドからAPI Gatewayを通してLambdaの処理を実行する場合、API Gatewayのタイムアウト時間の制限が問題となります。最大で29秒しかないため、ChatGPTからのレスポンス時間がそれ以上かかる場合には、処理が失敗する恐れがあります。
この問題に対して、AWS Step Functionsを使用してLambdaを非同期に呼び出すことを検討しました。この方法であれば、API Gatewayのタイムアウトの制約を回避することができます。
しかしながら、そもそもレスポンスの時間が長いという問題もあります。レスポンスが1分以上かかる場合、ユーザーは待機する必要があり、それによる離脱リスクも考えられます。そこで、ストリーミング形式のレスポンスを採用することで、ユーザーがレスポンスの進捗状況を確認できるようにしました。これにより、ユーザーのストレスを軽減することができます。
ストリーミング形式の検討
AIアシスタント機能のストリーミング形式の実現方法について調べる中で、2023年4月7日に発表されたAWS Lambda レスポンスストリーミングを活用できないかと考えました。しかしながら、API Gatewayが未対応であるため、このアプローチは採用できないことが分かりました。
そこで、ストリーミング形式を採用するためには、サーバーの建設が必要であると判断しました。しかしながら、インフラの構築には時間的、費用的な制約があり、この課題に取り組むためには再度工数の見直しが必要になりました。
NuxtのserverMiddlewareの採用
悩んでいた中、フロントエンドエンジニアから「NuxtのserverMiddlewareを利用するのはどうだろう」という提案を受け、検討しました。フロントエンドから直接OpenAIのAPIを呼び出すことはAPIキーの流出リスクがあるため危険ですが、serverMiddlewareを利用すればAPIキーの流出リスクがなくなるため、安全面でも問題ありません。また、新規でサーバーを立ち上げる必要もないため、インフラエンジニアの工数も必要ありません。これにより、API Gatewayのタイムアウトの制約やストリーミング形式に関する問題も回避できます。フロントエンドからOpenAIのAPIを叩くことができるため、実装も簡単でスムーズに行えるので、最終的にserverMiddlewareを採用しました。
バリデーションについて
OpenAIのAPIは利用回数に応じて課金されるため、無駄にAPIを多く叩くと費用がかかってしまいます。そのため、1日に叩けるAPIの回数を制限することにしましたが、制限をかけるためにはAPIを何回叩いたかを保存する必要があります。フロントエンドだけで処理する場合はCookieで保存できますが、ユーザーがCookieを削除することもあるため、Redisを利用することにしました。ただし、現在はフロントエンドからRedisにアクセスする手段がないため、バリデーションはココナラが普段使用しているサーバーサイドのアプリケーションを介して行うようにしました。
まとめ
どのようなアーキテクチャになったのかを図でまとめます。
このような構成にすることにより、インフラ構成の工数とコストを削減することができ、かつスピーディーに実装できるようになりました。
さいごに
私たちココナラでは、一緒にサービスを盛り上げていく仲間を募集しています。
私が所属するバックエンド開発グループ以外にも、部署ごとに環境の改善などに取り組んでいます。もし興味をお持ちいただけましたら、カジュアル面談にお越しください。
また、募集求人については以下のリンクからご確認いただけます。
Discussion