ID:77304さん

speakerdeckの解説と一部重複いたしますが、各種勉強会で登壇した際の資料を公開しております。 # 【プロジェクト概要】 ## 目的・背景 2017年末から日本にもGoogleアシスタントの「OKグーグル」が上陸し、その後Amazon EchoのAlexaが日本対応しました。 当時、音声認識によるシステム・サービスはかなり少なく、強い可能性を考え、当時の正社員を辞めて個人事業主として取り組みました。 いくつかの音声アプリケーションを作成していましたが、ふと、 **ユーザーが「Alexa、◯◯をして」と音声認識サービスを利用したとして、そのサービスが良かったのか悪かったのか、レビューを取るシステムが当時存在しない** ことに気づき、簡単な音声認識サービスを利用後に、ユーザーにレビューをもとめるAlexaスキルを開発し、AWSJ（Amazon Web Services Japan)のAlexa担当の方々と協議を繰り返し、納得してもらいリリースしました。 例えばAmazon Kindeで電子書籍を最後のページまで読んだ際に、レビューを求められますが、それですらレビューを実施する人は稀です。そのため、私は音声操作のみのAmazon EchoやGoogle Homeなら、使用した結果のレビューも音声でやるべきなのではないかということで、*** ためしにAmazon Alexaにて作ったところ、Amazonの公式ページでは評価数がせいぜい2件などでしたが音声レビューは2週間で118件という50倍以上の成果を得ました。 *** 本件を勉強会で登壇していたところ、スタートアップ企業のS社の社長に魅入られ、S社にCTOとして業務委託契約ではありつつも音声レビューシステムを本プロジェクト化し、音声認識サービスのプラットフォームとすべく開始されました。 本システムではAmazon AlexaとAWSの様々なサービスを組み合わせて、Alexaにユーザーが話しかけるアプリである「スキル」について、事前に同意いただいた開発者にAPIを公開し、この **音声レビュー・ログデータ収集・分析システム** にて、音声サービスにおいて音声でユーザーから星いくつかの評価を得たのか、ユーザーから何かしらのフィードバックはないかをテキスト化して保存しました。スキル開発者が多いほど、他のスキル開発者と成果物の比較ができる形式になっており、スキル開発者およびどのスキルなのかは登録者本人のみ実名・全員匿名の切り替えができるように構築いたしました。 ## 規模感、チーム構成、担当した役割 ### 規模感 4人 結果、資金繰りがショートしたため、金銭的な規模感なら開発費とその他で数百万円 ### チーム構成 技術面すべて私、資金調達にS社社長、スタートアップ企業経験者アドバイザー1人、大学生1人 ### 私が担当した役割 CTOとして ** 技術面をすべて担い ** 、マニュアル、営業、登壇などの拡販も行いました。 ### 使用技術や開発環境等 #### 使用技術 [AWS構成図](https://speakerdeck.com/surumegohan/patent-application-system-materials?slide=55) * Alexa Skill * AWS Lambda * AWS API Gateway * Amazon CloudWatch * Amazon DynamoDB * Amazon Kinesis Firehose * Amazon S3 * Amazon RedShift * Amazon QuickSight 検証した技術 * Amazon Athena * Amazon EC2 * AWS Glue * Amazon Aurora #### 開発環境 * Let's Note * Windows 10 * デュアルモニタ * **AWS Startup Loft Tokyo** # 取り組んだ課題 ## どんな課題だったのか そもそも当時の私はAWSについて、Alexaスキル作成と専門のRDB系以外の知識がほぼ皆無であり、ほぼゼロから書籍と手を動かしての検証から入りました。 AWSの各種サービスにおいて、不明点はAWS Startup Loft TokyoのスタートアップSAの方々のアドバイスを頂きながらある程度動作するモノは構築できましたが、特にデータ分析箇所で苦労しました。 苦労した理由として特に3つが挙げられます。 * ダッシュボードはどれを選ぶか * 短期的に見ればS3からAthenaのデータ分析が費用面では負担が少ないが、中長期的にみればRedshiftを選ぶべきか技術選定とコスト面 * 後に特許申請をすることになりますが、その対応 ### 1.ダッシュボードの選定 システムの目的の1つに、** 自分以外の音声認識サービス作成者との比較 ** があるため、わかりやすくいBIツールの導入が不可欠でした。しかしながら、EC2を立ち上げて、そこにRedashを乗せるような運用は費用対効果がとても悪く、操作性も難ありでした。 ダッシュボードの想定利用者は音声認識サービス開発者というITエンジニアはもちろんですが、中長期的にみて経営層などの非ITエンジニアでも容易に扱える必要があり、対応に苦難しました。 ### 2.認証手続き 日本中・世界中から本システムを利用する未来を想定し、かつ、** 音声認識サービス実施時の利用となると、1秒の遅延が発生してもエンドユーザーの人間は不快感を得ることにつながるため、Amazon Alexaのスキル（アプリ）を提供している開発者ではなく、音声認識サービスを直に使っている真のユーザーへの負担を最小限に抑えることが必要 ** でした。 そのため、本システムへの認証やデータ保存などをエンドユーザーに意識させない処理が求められました。 ### 3.データ分析に用いる技術 音声データをテキスト化して、その後分析に用いるとして、データクレンジングや分析アプローチの方法に苦労しました。 最終的には全世界の音声認識サービスのプラットフォームを目指したため、それに耐えられるAWSのサービスの選定と設計は、AWS初心者だった私にとって頭を悩ませました。 また、当時AWS Glueは完全にβ版であり、そもそも不具合が頻発していたため、その対応にも追われることになりました。 新しい技術を選択するか、安定した技術を選択するか、別のアプローチはないかと、AWSJのスタートアップSAの方々に都度相談しつつ 進ませて頂きました。 最終的にはRedshiftを導入しましたが、当時から高価であり、S3からAthenaの方が良かったのですが、どちらでも対応できるような疎結合な形に収める方針としました。 ### 4.特許申請 本システムは、我々のアドバイザーの見解から、特許がとれるのではないかとなり、弁理士と相談した結果、出願・取得することになりましたが、自分が構築したシステムとはいえ、特許申請用の文章は独特であり、大学の修士論文より厳しく、差し戻しも受けました。 ただ、結果的に特許取得ができたので良い経験になりました。 [J-GLOBAL:音声レビュー・ログデータ収集・分析システム](https://jglobal.jst.go.jp/detail?JGLOBAL_ID=202203003466898551) ## 技術的なアプローチや工夫した点 ### 1.ダッシュボードの選定への対応 RedashやPentahoなど世の中にBIツールはいくつかありますが、 * AWSと接続ができるか * ユーザー数が不特定であり、長期的に耐えうるか * 非ITエンジニアでも利用できる画面を提供できるか という課題があり、AWSJ（Amazon Web Services Japan）の方々とも話し合いましたが結論はでなかったのですが、世の中の「データ分析セミナー」について調べたところ、たまたまAWSJで1週間後程度にAmazon QuickSightのハンズオンセミナーがあることを知り、受講。今回のシステムに導入できることを確認し、セミナー講師担当だった方と、我々S社の社長を含めた会議をセッティングしていただき、導入する手筈となりました。 なぜ、AWSJの方々がAmazon QuickSightの提案ができなかったというと、そもそも ** ダッシュボートは社内でのデータ分析を行い、社内で部門長などに提示するもの ** という事例が多く、 ** ダッシュボートを他社に公開して分析してもらう ** というアプローチについて前例が極めて稀だったためです。 Amazon QuickSightはAWSのサービスに直にクエリを投げて分析ができ、ユーザー単位の料金であるため、本システムに非常にマッチしておりました。 ここに気がつけたことで、今回のシステムが将来的なプラットフォームになりうる可能性があり、特許につなげることができました。 ### 2.認証とデータ挿入のロジックのLambdaを非同期で別々に構築する ここからは [システム構成概要](https://speakerdeck.com/surumegohan/patent-application-system-materials?slide=55) を必要に応じてご確認いただけると助かります。 結果的に、過去にコミットが生じるRDBであるPostgreSQL・OracleDBやHadoopを運用した際に **「やってはいけない」** と言われていた手法をあえて取ることにしました。 RDBを用いるシステム開発では、RDBにデータの書き込み・更新ができたかどうか確実に判断するロジックが必須という考えを持っていました。RDBへのアクセスを行うアーキテクチャでは、サードパーティでも例えばJavaならばRDBへのアクセス結果をreturnで返り値で返すことが当然と考えていました。少なくともデータストアにデータが書き込みできたかどうかは確認するべきだと今でも考えます。 しかしながら、それをあえて無視することにしました。 なぜなら、データストアに本当に保存できたかどうかはエンドユーザーには無関係であり、開発当時の2018年秋以降において、JSON形式のテキスト文字列を受け取るだけで、システムに致命的な負荷がAWSにはかからないだろうと考えました。 実際、後述の仕組みで実装しましたが、JMeterをもちいてとにかくリクエストを送る負荷テストを行いましたが、AWSのシステムが優秀だったためか、少なくともβ版公開時以上の想定規模で本システムにアクセスをしても取りこぼしが発生していないことはAmazon Cloud Watch等で確認がとれました。 まずはAmazon API Gatewayで、Amazon Alexaから音声データと本システム利用のための認証情報をテキスト化したJSONを、受取り、本件のシステムのユーザーなのかを判別します。 本来、その直後に何かしらのデータストアにJSONを整形して保存する予定でしたが、あえて事前にAmazon DynamoDBに、本システムのユーザー名とパスワードなどの認証情報を格納しておき、Amazon API GatewayにでJSONを受けた直後はAmazon DynamoDBに、認証用JSONの中身が通過したら、システムを利用してつながった結果だけHTTPのステータスコード「202 Accepted」のように「200 OK」を本システムを呼び出したAmazon Alexaスキルに返答しました。 同様に、異常の場合はHTTPステータスコードの4xx,5xxになるべく沿うように実装しました。 実際の音声認識サービスでも例えば「今日の天気は？」とユーザーが話しかけた際には何かしら外部の天気予報APIと連携しているはずなので、この程度の【とにかくシステムに正常にアクセスできた】だけを即時Amazon API Gateway、AWS Lambda、高速処理とスケーラブル性に優れたAmazon DynamoDBへのSELECT文1回の実施だけを行い、本システムの開発者の音声認識サービスに返答しました。 この最低限の認証を実施中に非同期にて、別途新しいAWS Lamndaを非同期で呼び出し、音声認識サービスの開発者から流れてきたJSONの中身の確認と整形を行い、データの保存はユーザーの意志と離れて別途行うという仕組みをとりました。 ### 3.データ分析の技術選定 将来的に日本・世界中から、Amazon AlexaやGoogle Homeなどのデータが常に流れてくることを想定しながらも、スモールスタートができるデータ分析の技術選定というコストの狭間が問題でした。 膨大なデータが流れていくることで、RDBにデータを挿入・更新していくことは、長年の経験から無謀であり、 * まずは大量にながれてくる音声認識サービスの会話内容等のテキストをどのように受け止めるか * データをシステム上にどのように保存するか * 保存先はデータ分析に扱えるのか は大きな課題でした。 #### 大量に流れてくるテキストの受取り 音声認識サービスを用いたJSONのテキストデータが24時間365日流れてくることを想定しましたが、それを直に何かしらのデータストアに保存することはさすがに無謀だと感じ、AWSの様々なサービスを確認したところ、Amazon Kinesis Firehoseというサービスを知りました。当時のFirehoseは流れてくるデータを一旦受け取ったあとに * 一定量データが溜まったらデータストアに格納する * 一定時間経過したらその時点のデータをデータストアに格納する という機能を持っており、今回のシステムに大変向いていました。これでも取りこぼしが出た場合は、当時はさらにAmazon Kinesis streamなどを挟む予定でしたが、結果的にFirehoseのみで解決しました。 β版として公開する際には、 * 本システムを利用していただける開発者の方々に、なるべく早くログデータのダッシュボードに反映させたい * 少なくとも60秒程度はデータストアにデータを挿入するコミットの時間を要する と考えていたため、** Firehoseの設定を60秒間、音声認識サービスのユーザーから流れてくるJSONデータを貯めてからデータストアに保存する **というロジックとしました。 懸念としてはFirehoseに60秒という指定をしても、保有しきれるデータ量が溢れるとデータストアに保存するという仕様がありましたが、それも踏まえたデータストアを選択することにしました。 #### データストアの選定 AWSにおいて、データ分析を想定したデータストアとして、 * Amazon S3 bucket * Amazon Redshift がFirehoseからデータストアに直に保存できるサービスでした。 当時、データレイクの考え方があり、ひとまずAmazon S3にデータを格納してから利用するというロジックが多かったですが、本システムの目標は音声認識サービスのユーザーが、音声認識サービス開発者のスキル（アプリ）をどのように利用したのか * 会話の回数 * 話しかけた内容 * 利用した音声認識サービスへの星いくつであるかのレビュー * 日本中での利用頻度 などを他の音声認識サービスの開発者と比較しながら履歴の閲覧、分析を行うことでした。 そのため、場合によりデータストアへのアクセスが多くなる、分析に特化したデータストアでないと将来的にデータ量が増えた際に動作が重くなるなどの課題がありました。 これにはAWSJのスタートアップSAの方々もどちらを勧めるべきか人によって異なりました。 * Amazon S3 bucket に Amazon Athenaの利用で裏でSQLを実行する * 分析用と割り切っているのでAmazon RedShiftを利用し、チューニングしていく の2択が多く、AWS Glueはα版、β版が不具合だらけした。 2025年1月現在ならばAmazon Athenaはかなり使いやすく、安価であるためAmazon Athenaを選びますが、当時は将来的なデータ分析を本格的に実行するならば、あとからAmazon Redshiftを本システムに格納することは困難であることが予想されたため、 * 受け取ったJSONを生データとしてAmazon Kinesis Firehoseに渡し、Amazon S3へ保存 * 受け取ったJSONをAWS Lambda内でCSV形式にしてからAmazon Kinesis Firehoseへ流し、Amazon S3に格納した後に、PostgreSQLと同様のCOPY文にて流れてきたJSON1つ1つではなく、一気にAmazon Redshiftへ格納する という構成としました。 Redshiftの利用にはそれなりに費用がかかりましたが、 * 導入するには、長期間のシステムメンテナンスが不可欠であるため、初期段階のうちが最も適切であること * もし不要だと判断、将来的にAmazon Athenaの汎用性やコストが下がるなら、Amazon Redshiftを抜くことは比較的安易であること * Amazon Redshift が将来的に安価、分析用サービスと連携されやすい未来がありうる（実際に2025年1月現在、Amazon Redshift ゼロ ETL 統合、Amazon Q、Amazon Bedrockなど様々なデータ分析用サービスが展開されました） をS社長に説明し、Amazon Redshiftを導入することとしました。 ### 4.特許出願対応にUML 今回のシステムは、東京都目黒区のAmazon Web Services JapanにてAWS Loft Tokyo（当時の名称）コワーキングスペースが開放された2日目から通いつづけ、AWSそのものをほとんど触ったことがなかった私がとにかく注力した結果、約1ヶ月でα版を作成できたため、当時音声認識サービスはそれなりに注目度があったため早めに動く必要があり、特許出願にも動きました。 特許出願の文章は弁理士の方と意思疎通をしながら作成していく作業となります。 また、当然特許庁の方に少しでもわかりやすい文面を提出する必要があります。 クラウドや構成図の説明も重要ですが、特許となると【新規性】が特に問われるため、どの点が新しいのか、市場価値があるのかを説明する際に、UMLを用いて、中でも * ユースケース図 * シーケンス図 * アクティビティ図 を用いるため「astah*」というツールを使いました。 SIerで長年勤めていた際の設計書で重宝していたので用いることにしましたが、諸雑務を手伝ってくれていた当時の大学生がいたため、UMLの説明と本システムの表現について教え、その大学生にUMLの各種の図を作成してもらい、レビューしていきました。 新卒の後輩の指導の経験があったので、大学生にUMLの書き方を教えることができたのも1つの成果だと考えています。 # 取り組みの成果 本取り組みの成果は大変多くの学びがありました。 1. AWSについてほとんど無知だった状態から、何がなんでも作ってやるという姿勢と、AWSJの方々（特にスタートアップSAとデータベーススペシャリスト）から入社スカウトがくるほどの技術力 1. この経験からAWS認定を4つ、一発合格取得 1. Amazon Alexaの公式がAlexaスキルに音声レビューを導入（※　ライセンス料などが取れそうでしたが技術発展のためにそのままにしています） 1. スマートスピーカーの勉強会を4つ運営していましたが、かなりの知名度が得られ、AWSJ以外のいくつかの企業からスカウトがきました 1. 0→1のシステム開発に携わった経験は、この後のITエンジニア経歴に活かされています 1. AWSJの当時の代表取締役社長だった長崎様からの招待でAWS Summit Tokyo 2019、AWS Startup TokyoというAWS公式の場で登壇させていただきました 1. 様々な企業や投資家に出資のお願いや売り込みに走り、「ビジネスになるのか？」という会社員ITエンジニアでは得にくい視点を痛感しました 1. 技術書典という技術同人誌イベントに本件を寄稿することになり、技術本の執筆を経験することができ、今ではテクニカルライターとしての業務も行っています 以上