株式会社朝日新聞社での文字起こしシステムにおけるサーバーレスの活用 – 処理時間を短縮し業務貢献しながらクラウド費用も削減した話

新聞業界では昨今の市場環境の変化、対応すべき媒体数の増加などもあり業務効率化が急務になっております。本稿では、株式会社朝日新聞社メディア事業本部メディア研究開発センターの編集業務の効率化の取り組みと、改善活動の中で生まれたシステムの課題をサーバーレスを活用して改善した話について紹介させていただきます。

編集業務の現状と課題、解決策

株式会社朝日新聞社は 140 年以上の歴史を持つ国内有数のメディア企業であり、紙媒体からデジタルメディアまで幅広い媒体で情報を提供しています。2021 年 4 月には、新聞社ならではの豊富なデータを活用した先端技術の研究・開発を推進することをミッションとして掲げた、メディア研究開発センターが設立されました。このセンターでは、主に人工知能を活用した業務課題の解決や新しいサービスの創造に取り組んでいます。一方で、昨今の新聞社を取り巻く環境は大きく変化し、記者の負荷増が課題となっています。以下の図は記事が公開されるまでのフローを簡潔にまとめたもので、記者が様々な業務を担っていることがわかります。

編集業務の効率化のため既存フローの分析を実施したところ、上記の図の書き起こしのステップでは１時間の音声ファイルを書き起こすのに平均して 2.5 時間かかっていることがわかりました。そのため朝日新聞社では書き起こし作業に着目し、編集業務の効率化を目指した文字起こしシステムの開発に着手しました。

リリース当初の文字起こしシステムアーキテクチャ概要

リリース当初の文字起こしシステムのアーキテクチャは以下の通りです。

※ 図1 : リリース当初のアーキテクチャ概要

文字起こしシステムは、音声ファイルがアップロードされた際、

音声ファイルの前処理
音声ファイルの分割
音声認識
句読点の自動付与
フィラー発生や相槌の検出
自動要約
キーワード抽出
結果をユーザーに返却

というフローで処理しています。中でも、 2 から 5 は上図の AWS Fargate によって行っていましたが、ユーザーインタビューでは処理速度が遅いという意見がありました。

処理速度が遅くなる原因は以下の 3 つが挙げられました。

自社開発でない音声認識モデルを活用していたため、モデルの最適化や高速化などをすることができなかった。
分割した音声ファイルの音声認識を Fargate の 1 つのタスク内で並列処理させていたため、より大きな vCPU を割り当ててスケールアップする以外で並列数を増加させてスケールアウトさせることができなかった。
最大 1GB の音声ファイルがアップロードされ、1 ファイル毎の音声認識が完了するのを待ってから句読点、フィラー発生や相槌の検出処理をおこなっていたため、多量の待ちが発生していた。

そのため処理速度の向上のためにアーキテクチャを見直すことにしました。また、ユーザーインタビューでは処理速度以外にも音声認識性能向上を求める声も多くあり、音声認識モデルの構築についても着手しました。

サーバーレスを活用した文字起こしシステムのアーキテクチャ概要

システムのアーキテクチャを見直すにあたって、 AWS のソリューションアーキテクトとの相談を経て、コストと実装の容易さの観点から AWS Step Functions と AWS Lambda を活用して処理を並列化し、処理速度の向上に取り組みました。サーバーレスを利用したアーキテクチャは以下の通りです。

※ 図2 : サーバーレスを活用したアーキテクチャ概要

初期のアーキテクチャとの主な変更点は音声認識パイプラインを Step Functions と Lambda に置き換えている点にあります。ファイルがアップロードされたタイミングで Amazon EC2 が音声認識のステートマシンを呼び出し、処理が完了するまでポーリングしています。現状の構成は極力活用し、音声認識パイプラインのみ改善を加え、改修箇所を少なくしつつ並列度を高め 1 ファイルにかかる処理時間を短縮することができました。

音声認識パイプラインの改善

まず、音声認識パイプラインを改善するために、自社で構築した音声認識モデルに切り替えました。自社で構築した音声認識モデルは 10 億以上のパラメータで構成されており、認識性能が向上したほか、 GPU なしでも高速に動作するよう、推論部分は C++ で実装しています。 Lambda は現在 GPU に対応しておりませんが、 GPU なしでも動作するようにしたことにより Lambda での推論が可能になりました。また、 Python バインディング ( 注釈 : C++ で書かれたコードを Python で利用できるようにする )という形で API を構築しました。これにより C++ のスキルセットを持たない開発者でも Python という慣れ親しんだ言語を使い新たに C++ を学ぶ必要なく、エンドポイント構築にのみ集中することができるようになるほか、Lambda の実装・保守・運用時のハードルも低減しました。なお、 Lambda はコンテナ形式でデプロイしており、約 1.5GB の機械学習モデルをイメージに組み込んでいます。

次に Step Functions と Lambda で構成された音声認識パイプラインの詳細について紹介します。アーキテクチャは以下の通りです。

※ 図3 : 図2でのStep Functions 内の詳細アーキテクチャ

最初に、親のステートマシンを使用してアップロードされたファイルを 30 秒単位で分割します。分割ファイルを Amazon S3 にアップロードし、それぞれの分割ファイルに対して、Step Functions の Distributed Map を活用して複数の子ステートマシンが並列で音声認識、句読点付与、フィラー発生や相槌の検出処理を進めていきます。Step Functions の Distributed Map を活用することによって容易に並列処理を実装でき、処理の高速化を実現できました。このシステムの並列度は分割したファイルに依存し、アップロードされたファイルのサイズに応じて変わり予測ができないため、最大 10000 並列の同時実行数をサポートする Distributed Mapを利用しています。また、各 Lambda 関数については Lambda Powertools を活用してロギングや入力値のバリデーションを行っています。 Lambda Powertools の利用により、自前実装することなくそれらの処理を実装することができました。

改善の結果

上記のアーキテクチャへの移行により、文字起こしの処理時間が劇的に短縮されました。以前は 1 時間の音声ファイルの処理には約 30 分かかっていましたが、それが 4 〜 5 分にまで短縮されました。さらに、システムの推論コストも約 40% 削減され、クラウド利用費用の面でも大きなメリットが生まれました。リリース後、業務ユーザーからは「月の残業が 20 時間減りました」といったようなポジティブな意見が多く寄せられ、高い信頼と満足度を得ることができました。

まとめ

本記事では朝日新聞社における文字起こしサービスの開発と、アーキテクチャをサーバーレスを利用して改善したエピソードを紹介させていただきました。社内の記者へのヒアリングを通して課題をみつけ、プロトタイプを実装したのち、ユーザーの増加に合わせて改善を重ねるという進め方は、他のメディア企業の皆様にも参考になる事例かと思います。また並列処理は自前で実装しようとすると骨の折れる作業になりますが、サーバーレスを活用することによって並列度が高い処理を比較的容易に実装できるということを紹介いただきました。データ処理やファイル処理をサーバーレスで並列化することは様々なバッチ型処理に適用できるアイデアですのでご参考にしていただければと思います。今後は CI/CD パイプラインの整備や、 GPU の活用も視野に入れて Step Functions と Amazon SageMaker を利用したワークフローの構築を予定しているとのことです。

本ブログは、株式会社朝日新聞社メディア事業本部メディア研究開発センター山野氏、嘉田氏とソリューションアーキテクトの紙谷が共同で執筆いたしました。

Amazon Web Services ブログ