本記事の目次 (→シリーズの特集ページ)
機械学習でチャットによる問い合わせに回答
――バージョン2はどのようなアーキテクチャにしたんですか?
小林:まず、ばらばらに立ち上げられていた個別サービスからロジックを取り出して、1つのRailsアプリケーションに統合しました。顧客データを格納するデータベースも同様です。そうして、OK SKYサービス全体を1つのRailsアプリケーションとして構築し直しました。
また、このタイミングでOK SKYを稼働させるクラウドを、AWSからHerokuに切り替えました。OK SKYを提供する場合には、RailsアプリケーションのインスタンスをHeroku上で立ち上げます。ユーザーが解約したときには、そのインスタンスを破棄するだけで、顧客データやログデータも含め、削除すべきデータが消去されます。これで課題を解決できました。
存外に嬉しかったのは、インスタンスの立ち上げとセットアップが簡単になったことですね。環境変数やアドオンの組み合わせなど設定しておけば、あとは「Deploy to Heroku」ボタンをクリックするだけでセットアップまで完了し、すぐにユーザーへ提供できるんです。
――アーキテクチャ図のcommunication moduleの中に「テキスト解析」とあります。システムがお客様とチャットでやり取りするのですから、この部分はサービスの品質を左右するところだと思います。どのような実装になっているのですか?
小林:詳しくはまだ言えないのですが、やり取りする言葉はIBM Watsonを使って生成しています。お客様の入力を理解し、それに対して適切な次の質問を返します。お客様への聞き方にも重要なポイントがあります。例えば、自由形式ではなく、「……していいですか?」と尋ねて「イエス」か「ノー」かで回答してもらえるようにしています。イエスかノーかを正しく聞いていけば、問い合わせたいことはおおよそ分かるんです。
また、質問は誘導型になっています。例えば「夏に着るワンピースを探しています」という問い合わせに対しては、「ワンピースですね?」「お仕事用のワンピースでしょうか?」という具合です。
――なるほど。今話題の機械学習の実用例というわけですね! ただ、お客さんの回答をうまく誘導するための台本?っていうんでしょうか、それを作るのがまず難しそうですけど。
小林:弊社はチャットセンターを持っているので、チャットの構成、やり取りの構成自体は簡単に作れるんですよ。
OK SKYでは、チャットセンターで人間が生み出したデータをGoogle BigQueryの中に全部入れて、類似性のルームを生成し、それでいったん分類をしたあとに、人間の手でそれぞれで上手くまとめるという方法で作りました。チャットセンターには400万メッセージぐらいあり、約30万のルームができました。
なぜAWSからHerokuへ切り替えたのか
――うーん、もうSFの世界のようです……。ところでなぜ、AWSからHerokuにクラウドを変更したのですか? AWSでも同様の実装はできたと思うのですが。
小林:コストですね、一番の理由は。バージョン1まではミニマム構成でもインフラコストとして120万円くらいかかっていた。しかし、ネットワークのトランザクションも含めて、利用できるリソース範囲の0.1%も使ってない。何かあったときのために、たとえ1台で運用していてもDBを挟んでおくとか、本来1台ならそれはいらないはずなのに、こうした余剰リソースがどうしても発生する。さらに、ミニマム構成では1つでも使用するAWSのサービスを外すと、OK SKYが提供するサービスに影響が出てしまう。にっちもさっちもいかない状態でしたね。
そんなときにHerokuさんとご縁ができて、じゃあ乗り換えませんかっていうので、それで決断しました。あと、Herokuではアドオンも含めて、立ち上げたインスタンスに対して一括で課金される点もコストに無駄がなく魅力でした。
――バージョン2への移行はクラウドやアーキテクチャの変更など、とても大きなものです。移行の際に困った点などはありませんでしたか?
小林:結構悩んだポイントはあって、1つはバージョン1とシステム連携していたユーザーさんへの対応です。在庫連携とか、商品マスターや顧客マスター連携などを行っているユーザーさんがいらっしゃったんです。それも、インフラの調査などを事前に行うようなビッグクライアントでした。
いただいた要望には、「ファイル連携だったら、HULFT(ファイル転送ミドルウェア)を使ってやってほしい」「サーバ自体は残してやってほしい」といったものがありました。また、クラウドを切り替えるとIPアドレスが変わるわけで、APIで連携しているユーザーさんではご対応いただけないケースもありました。
――結局、どうされたんです?
小林:システム連携はあきらめました。代わりに、商品や在庫のデータを表示するWebサイトをクローリングして収集する方式としました。それで、お客様から問い合わせがあったときに参照する商品や在庫のデータベースを構築する。将来的にはそのやり方がいいかなって思いました。HTMLになったものから情報吸い出すのであれば、同じしくみで全部できますから、効率的というか汎用的というか。
――荒っぽいですが、高額なインテグレーション費用をかけて連携する仕組みを構築するより、たしかにコスパに優れている気がします(笑)
Force.comは「無料」で試せます!
簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。