ビジネスニュースをパーソナライズ化・分析し、情報収集を効率化するアーキテクチャの仕組み

情報収集と企業分析の効率化を目指す、ストックマーク株式会社

司会者：では、続きまして、ストックマーク株式会社のチーフエンジニアである谷本さんに壇上にお越しいただきたいと思います。谷本さんよろしくお願いします。

谷本龍一氏（以下、谷本）：ストックマーク株式会社でチーフエンジニアをやっております、谷本と申します。よろしくお願いします。

まず最初に弊社の説明をさせてください。我々は2016年設立のAIスタートアップです。主に、テキスト解析とテキストマイニングをベースとしたクラウドソリューションの開発・運用をさせていただいております。

世の中には膨大な数のメディアがあって、そこから日々膨大なニュースが我々に配信されてくると思うんですね。ビジネスの現場においては、情報収集が非効率になってしまったり、未知なる脅威に遭遇したり、あるいは最終的には意思決定が遅れる。そういった問題があります。

我々が解きたい課題としては、人工知能を用いたソリューションで既存のビジネスプロセスを変換して、その問題解決をしていく。そういうものを目指しています。

実際にどういうサービスを作っているかですが、企業に我々のサービスを導入していただくと、その企業の業界に関連するニュースをまるごと持ってきて、それをさらに個人でパーソナライズして配信することで、情報収集の効率化を達成します。

それだけではなくて、その企業の競合となる他企業やマーケットの情報なども分析して出すことができます。我々は「100分の1の時間で、100倍の情報量を扱って、企業分析をしよう」ということをスローガンに掲げています。

システムのアーキテクチャについて説明します。

まずこの左上のメディアサイトのところから、AWS LambdaとAmazon SQSを使ってクローリング、そして記事の分析・保存をしていきます。

そうして集まったニュースに対して、次は、AWS Batch上で管理されたCPUコンテナと、あと一部Amazon EC2上で管理されたGPUコンテナを用いて機械学習処理を行い、最終的に記事をAmazon Elasticsearch Serviceに保存しています。記事以外の情報はAmazon DynamoDBに保存しています。

そして、集まった情報に対して、オンラインアプリケーションでは、ユーザーが自分の興味がある業界であったり、興味のある企業に対して検索したデータの検索結果を、さらに個人でレコメンデーションして最終的に返すといったかたちになっています。

網羅性を担保し、パフォーマンスを上げられることが利点

谷本：我々がこのアーキテクチャを採用している理由ですが、1つは網羅性を担保する。これが一番大きな理由の1つです。

そのために、我々はAWS LambdaとAmazon SQSを使ってサーバレスな記事の収集・分析というものを構築したので、スケーラブルな構成にし、かつ、今後高速な追加開発なども行える。そういうものを担保できるようになっています。

さらに2つ目としては、実際に集まった大量のデータを、どうやってユーザーが使えるビジネスニュースとして提供できるか。それを達成することが目的になります。

そのために、我々はCPUとGPUのコンテナを用いて、弊社内にある累計数千万記事を独自AIエンジンで分析をしています。CPUコンテナですと、要約の生成や業界の分析。あとGPUコンテナだと、類似企業の抽出のようなことを行っています。

さらに、オンラインアプリケーションのところでは、Amazon DynamoDBとAmazon Elasticsearch Serviceを併用することで、ユーザーと記事のマッチングをリアルタイムで行って、レコメンデーションを達成しています。

我々は、このサービスがWell Architectedな理由として、2つ挙げられると思います。1つは信頼性です。我々のサービスを作っていく中で感じたことは、オープンデータやニュースの収集・分析というのは、データは当然増え続けますし、それに伴う特殊ケースがどんどん増えていく。それとの格闘の連続だということがわかりました。

実は、最初はこの情報を収集するところは、Amazon EC2のインスタンスは1台だったんです。

それが今、クローリングと記事分析は別のAmazon SQSで分離している。

さらに分かれていって、最終的にはプロダクトの成長に合わせて、段階的にマイクロサービス化を達成して、それによって信頼性を獲得していくというところがあります。

2つ目の理由としては、パフォーマンスが挙げられると思います。先ほど申し上げたように、オンラインで数十万記事の分析結果をなるべく早く、ユーザーを待機させないスピードで提供する必要があります。

そこで我々は、このAmazon Elasticsearch Serviceのところと、それからAmazon Elastic Beanstalk管理下のEC2インスタンスのところで、それぞれインスタンスタイプの最適化を行いました。その結果、現在利用されているような高速な検索およびレコメンデーションを達成できているということが言えます。

サービスのリリースから約2年で累計1,000社以上が利用

谷本：最後に、我々のアーキテクチャによるビジネスへの貢献というところですが、我々のこのサービスは2017年の4月から、導入、リリースを開始して、今まで累計1,000社以上でご利用いただいています。

以上です。ありがとうございます。

司会者：ありがとうございました。

（会場拍手）

谷本さん、お疲れさまです。それでは質問をよろしくお願いします。

竹内秀行氏（以下、竹内）：Amazon SQSとAWS Lambdaで多段構成にしているじゃないですか。あそこの部分って、例えばLambdaでプログラムのミスによって障害が起きたときに、その障害の原因を追うために、なにか工夫していることはありますか？

谷本：工夫は、Amazon CloudWatchで監視しているのと、一応環境ごとに完全に別のパイプラインを用意していて、プロダクション環境のものが1つ死ぬと、 最近のステージング環境のものでまったく同じものを提供して使えるようにはしています。

竹内：そうではなくて、中間データはまったく保存していないんですか？　そこはちょっと不安だなと思ったんですけれども。

谷本：中間データは一応SQSには溜めている……というところまでです。

竹内：わかりました。はい。

司会者：では、以上となります。谷本さんどうもありがとうございました。

谷本：ありがとうございました。

（会場拍手）