AWS Startup ブログ

開発期間を2ヶ月短縮。運用工数もほぼゼロに。クウゼン社の Amazon OpenSearch Service 活用

株式会社クウゼンは「テクノロジーで、対話の可能性を広げる仕組みを創る」というミッションを掲げ、ノーコード AI チャットボット「KUZEN(クウゼン)」を軸に事業を展開するスタートアップ企業です。

同社は AWS を用いてインフラ環境を構築しています。そして「KUZEN」内の Q&A 機能を実現するうえで、OpenSearch クラスターのデプロイ、オペレーション、スケーリングを容易にするマネージドサービスの Amazon OpenSearch Service を活用しているのです。

今回はアマゾン ウェブ サービス ジャパン スタートアップ事業本部 スタートアップアカウントマネージャーの井上 遼とシニア スタートアップ ML ソリューションアーキテクトの針原 佳貴が、株式会社クウゼン 共同創業者 CTO の白倉 弘太 氏とインフラエンジニアの西守 啓一郎 氏にお話を伺いました。

「KUZEN」を使えばチャットボットを簡単に導入できる

井上:クウゼン社の事業概要についてご説明ください。

白倉:クウゼンは 5 年前に創業した会社で、ユーザーの投稿に対して自動応答するチャットボットを簡単に作れるサービスを提供することから事業をスタートしました。直近の 1 年くらいはコミュニケーションツールの LINE をインターフェースにすることに注力しており、チャットを通じた商品の紹介や顧客へのマーケティング施策などを実現できるように、機能を拡充しています。

株式会社クウゼン 共同創業者 CTO 白倉 弘太 氏

井上:世の中にチャットボットを提供する会社は多数あります。他社のツールと比べて、御社のツールはどのような点が優れているのでしょうか。

白倉:他社のチャットボットの大多数は、カスタマーサポートが担っていた問い合わせ対応の自動化のように、コスト削減を主な目的として利用されることが多いです。私たちの提供するノーコード AI チャットボット「KUZEN」も、もちろんそうした機能を提供していますが、弊社のツールはより複雑な要件に対応できることが強みです。

たとえば Salesforce などの CRM ツールとのデータ連携をしたり、在庫管理ツールにある購入履歴などの情報をもとにメッセージを出し分けたりといったことが実現できます。そして、顧客企業が「KUZEN」の使い方やビジネス活用で困らないように、弊社のカスタマーサクセスがお客さまと伴走しながら支援するのが、弊社の事業の大きな特徴です。

Amazon OpenSearch Service により開発・運用の負担を軽減

井上:今回のインタビューでは、Amazon OpenSearch Service の利用事例にフォーカスしたいです。何の機能に使用されているかをお話しください。

白倉:「KUZEN」のチャットボットにある応答機能のひとつに、Q&A 機能があります。これは、あらかじめ質問とその答えのデータをデータベースに登録しておき、ユーザーがボットに対して質問した際に、登録されているデータのなかからユーザーの質問と同意のものを見つけ出し、その回答をボットがユーザーに返答する機能です。

この機能を実現するには、形態素解析や同義語の取り扱いなど各種の自然言語処理を実装する必要がありました。もともとはリレーショナルデータベースにデータを格納して自前で処理を実装する案もありましたが、それではかなりの工数がかかります。できればマネージドサービスを活用して、開発・運用ともに最小限の工数に抑えたいと思っていました。そんな折に、Amazon OpenSearch Service の存在を知って導入を決めたのです。

Q&A 機能を実現するうえでは、Amazon OpenSearch Service による検索結果をそのままユーザーに返しているわけではなく、工夫をしています。返却された検索結果の一覧のうち、重要度の高いものだけをユーザーに返すフィルタリングの処理を入れています。

針原:Amazon OpenSearch Service を使ったことで、どのくらい開発・運用の工数が削減できましたか?

白倉:工数のかかる箇所として、大きく分けて AWS 上で Amazon OpenSearch Service を設定する作業と、アプリケーション側から Amazon OpenSearch Service を利用するためのソースコードの実装があります。後者については Q&A 機能全体の実装として 2 カ月ほどで完了しました。Amazon OpenSearch Service を使わずに実装していたら、もっと時間がかかったはずです。おそらく、概算で 4 カ月くらいはかかったと思います。

前者のインフラ設定作業は非常にスムーズに進み、Terraform での実装を含めてもかなり短期間で行うことができました。Elasticsearch を Amazon EC2 などにインストールして使うよりも、ずっと早く簡単にできたと思います。さらに言えば、真の意味でのインフラ側の恩恵は、その後の運用面にあります。マネージドサービスは、私たちが低レイヤーの部分を管理しなくていい点が素晴らしく、運用負担の軽減につながっています。

針原:Amazon OpenSearch Service を使用して検索結果を返している部分は、どれくらいのパフォーマンスでどれほどの数のレスポンスを返却していますか?

白倉:10 requests/second くらいで通常リクエストを受けており、レスポンスはほぼ全て 2ms 以内に返しています。もし仮に Amazon OpenSearch Service を使わないでリレーショナルデータベースなどに頼った場合は、同じパフォーマンスを出すのにより高いコストを払う必要があったはずです。

そして、このように実現した Q&A 機能によってお客さまのビジネス的な成果もかなり出ています。たとえば日本最大級の不動産・住宅情報サイト「LIFULL HOME’S」を運営する株式会社LIFULL では、「KUZEN」を導入して経理や労務に関する社員からの質問への対応をチャットボットにした結果、対応時間を 1 年間で 2,199 時間以上も削減できたそうです。

井上:かなりの成果ですね。Amazon OpenSearch Service をご利用いただいて良かったです。

アマゾン ウェブ サービス ジャパン スタートアップ事業本部 スタートアップアカウントマネージャー 井上 遼

AWS 側でプロトタイプ作成も支援

針原:Amazon OpenSearch Service 以外の部分ではどのような AWS のサービスを利用されていますか。

西守:Q&A 機能関連の部分をピックアップすると、白倉がお話ししたフィルタリング処理の部分は Ruby on Rails のアプリケーションを Amazon ECS on AWS Fargate でホスティングしています。また、永続的なデータベースとしては Amazon Aurora を、一時的なキャッシュを格納する先として Amazon ElastiCache を使っています。

また、Q&A での会話履歴やユーザー情報などは、Amazon S3 に格納してから AWS Glue による変換処理をかけ、Amazon Athena によってクエリで情報取得できるようにしています。

白倉:ダッシュボード機能と呼ばれる、お客さまが利用する統計情報のページを Amazon Athena と Amazon QuickSight によって実現しています。

Q&A 機能関連箇所のアーキテクチャ

針原:ダッシュボード機能の開発には、私たち AWS のメンバーもご協力させていただきましたよね。AWS には、プロトタイピングエンジニアという職種があります。これは、お客さまに対してベストプラクティスに基づいたソリューションを提案するだけでなく、一緒にプロトタイプを開発することを通じてお客さまのプロジェクトを成功に導く役割です。

当初、まだ白倉さんが Amazon QuickSight でどういったダッシュボードを構築可能かイメージが湧いていなかったため、プロトタイピングエンジニアのメンバーたちがお手伝いさせていただきました。

白倉:AWS の 2 人についてもらって、2 週間ほどペアプログラミングをしてもらいました。かなり助かりましたね。私たちが想定する機能のシンプルなプロトタイプ版を作ってもらえたことで、調査や実装などにかかる工数をかなり削減できました。

株式会社クウゼン インフラエンジニア 西守 啓一郎 氏

さらなるスケールに耐えられるアーキテクチャを

井上:今後はどのようなサービス展開を予定されていますか。

白倉:今のビジネスモデルが比較的うまくいっているので、その事業を引き続き成長させていきます。また、数年以内に第 2 のサービスをリリースすることも視野に入れているので、それに向けてインフラ拡張も実施していきます。

インフラに関しての今後の改善点としては、エンタープライズのお客さまも増えているため、突発的にサービスのトラフィックが増加するような事態に備える必要があります。Web サーバーに用いている AWS Fargate は比較的容易にスケールアップできるので、課題はリレーショナルデータベース側だと考えています。

針原:リレーショナルデータベースをアクセス増に耐えられるようにしていくには、さまざまなパターンが考えられます。Read-intensive であれば Aurora レプリカを増やして対応する方法、Write-intensive なユースケースだとスケールアップさせたり、トラフィックに変動がある場合は Amazon Aurora Serverless を導入するなど選択肢が複数ありますので、ぜひアーキテクチャについてディスカッションできるとうれしいです。

私たちがよくお客さまにご提案しているのは、取得しているデータベースに関する各種のメトリクスを定量的に確認することです。どのような種類のクエリがどれくらいの頻度で発行されているのか、クエリチューニングなどで改善できる余地があるのか。データベースの負荷の確認やボトルネックとなる SQL の特定には Performance Insights をご活用いただけると思いますし、データベース周りに強いソリューションアーキテクトも居るのでぜひ積極的にご相談いただければと思います。

アマゾン ウェブ サービス ジャパン スタートアップ事業本部 シニア スタートアップ ML ソリューションアーキテクト 針原 佳貴

西守:白倉がお話ししたスケーリングの部分は私も同意で、それに加えてアプリケーションのデプロイサイクルを高速化したいと考えています。インフラエンジニアとして、それを実現するための仕組みを整備していきます。

井上:今後はどのようなタイプのエンジニアに参画してほしいですか。

白倉:私がいつも思っているのは、自立できるエンジニアであってほしいということです。技術や事業に関心を持って、その熱量をベースに自ら動ける人だと良いですね。

西守:ポジティブ人がいいですね。「何事も 1 回やってみよう」とか「困難なことが起きたときこそ前向きになろう」といったマインドの人と一緒に働きたいです。

井上:今回は貴重なお話をありがとうございました。


導入支援・お見積り・資料請求等に関するご質問、ご相談に日本担当チームがお答えします。平日 10:00〜17:00 はチャットでもお問い合わせいただけます。お問い合わせはこちら