生成 AI を活用したニュース 3 行要約を配信するシステムをマネージドに作成する　~ ニフティ株式会社による生成 AI 実装解説 ~

この記事では定期的に配信されるニュース記事に対して、生成 AI による 3 行要約を Amazon Bedrock で作成し、それを Amazon CloudFront 経由で API として配信するシステムの構成についてご紹介します。

現在は Amazon Bedrock を利用することで、最新の生成 AI モデルが利用可能かつ、コストも利用に応じた金額だけになりました。生成 AI はプロンプトエンジニアリングを活用することで、様々なタスクに適用することができ、初期の PoC からプロダクションリリースにおいても効果的に活用できます。

本記事ではほとんどの部分をマネージドサービスで構成することで、運用コストを下げながら低コストで実現した機械学習システムの一例をお見せします。

X ポスト » | Facebook シェア » | はてブ »

この Lambda 関数においては、以下の手順で要約を生成します。

1. S3 バケットからのイベントトリガーを受け取ります。イベントには、要約対象の記事データが格納されている S3 バケット名とオブジェクトキーが含まれており、どの記事データを読み出せばいいのかを渡されたイベントの内容から判別します。

2. イベントから取得したバケット名とオブジェクトキーを使用して、S3 バケットから記事データを読み込みます。記事データは JSON ファイルとして格納されており、記事のテキストが含まれています。

3. 読み込んだ記事データから記事のテキストを取り出し、generate_summary 関数に渡します。この関数は、Amazon Bedrock を使用して記事の 3 行要約を生成します。

   • generate_summary 関数ではプロンプトを用いて、最終的に JSON ファイルを生成 AI に出力させます。生成 AI が生成する JSON は有効ではない場合があるため、3 回までリトライするように制御します。

4. generate_summary 関数から返された要約を受け取ります。要約は、summary_1、summary_2、summary_3 の 3 つのキーを持つ辞書として保持します。

5. 生成された要約を、save_summary_to_s3 関数を使用して要約配信用の S3 バケットに保存します。要約は、記事 ID をファイル名に使用して JSON ファイルとして保存します。ここでは保存先の S3 バケットは、環境変数 SAVE_SUMMARY_S3_BUCKET で指定していることにしています。

以上の手順により、S3 バケットに格納された記事データから 3 行の要約を生成し、別の S3 バケットに保存する手順を自動的に行います。この AWS Lambda は、S3 イベントをトリガーとして使用しているので、新しい記事データが追加されるたびに自動的に要約が生成されます。

Claude に与えるプロンプトのテクニックとして、ニュース記事における 3 行要約では「記事の最初・中間・終わりがバランスよく含まれるようにしてください」という指示を与えることで、記事全体に言及しつつ分かりやすい要約を生成できます。この指示がない場合、記事の一部に偏った要約が生成され、読者がニュースの全体像を把握できなくなります。その結果、3 行要約の本来の目的である「素早くニュースを理解する」ことができず、要約の意味が薄れてしまいます。

また、ニュース記事要約においては「固有名詞や専門用語はそのままにして」というプロンプトは重要です。ニュース記事には固有名詞や専門用語が多く含まれていますが、特に英語表記の場合において Claude などの生成 AI は単語を翻訳して要約を生成してしまうために、要約が不自然になることがあります。「固有名詞や専門用語はそのままにして」と指示を明確に与えることで、生成された要約がより自然なものになります。

実装の初期段階においては実際に生成された要約を確認しながら、不自然な要約だと感じる点を見つけ、直接かつ具体的にプロンプトで指示を与えることで、生成 AI の出力を改善することができます。（コード内に記載しているプロンプトは簡略化されたものであり、実際のプロダクション環境のプロンプトとは異なります）

AI による要約結果を JSON として S3 に保存し、Amazon CloudFront を通して WebAPI として配信します。この構成には以下のような利点があります。

• アプリケーションサーバー不要で API として配信可能

S3 に保存された JSON ファイルを Amazon CloudFront を通して直接 WebAPI として配信できるため、API を提供するためのアプリケーションサーバーを用意する必要がありません。これにより、インフラの構成がシンプルになり、運用コストを抑えることができます。

• 自動的なスケーリングとキャッシュ

Amazon CloudFront は CDN (Content Delivery Network) サービスであり、世界中に分散されたエッジロケーションを利用してコンテンツを配信します。アクセス数が増加しても、CloudFront が自動的にスケーリングを行うため、API の可用性を高く維持できます。またキャッシュを利用することで、同じリクエストに対してはキャッシュされた結果を返すことができるため、リクエストの処理時間を短縮できます。

• セキュリティの強化

Amazon CloudFront を用いることで DDoS 攻撃の緩和やアクセス制御、AWS WAF との統合を行うことが可能です。現在のところ今回構築した API が攻撃を受けたことはありませんが、既知の脆弱性を悪用する攻撃や同一 IP 元からのアクセス攻撃などをブロックできるため、この点においても運用コストを下げることが可能です。

Amazon Route 53 で CloudFront にルーティングを行い、CloudFront のビヘイビアによるパス設定を行うことで、フロント側では通常の API と似たような形（例えば、[api サーバーの URL]/summary/[id].json) でアクセスすることが可能になります。

ニフティニュースでは既存のシステムにおいて Amazon CloudFront を採用しており、今回は静的なリソース配信のみで完結することから、アプリケーション開発が不要となるこのような構成を採用しました。開発工数を削減できた分、インフラ構築から検証および実際の機能リリースまで 1 ヶ月で完了するという、非常にスピード感のあるリリースができたと考えています。

生成 AI を活用する場合には、生成 AI の利点と実現可能な範囲の理解が必要になります。

今回のような要約作成において、生成 AI は絶大な効果をもたらします。人の手による要約作成はどれだけ多くても 1 人 1 日 50 記事程度が限度であり、多く作成しようとするとそれだけ人手が必要になります。これが生成 AI を活用することによって、現在 1 日 2000 記事を超える記事に要約が付与されています。

しかし、生成 AI も万能ではなく、人間には違和感がある文章を出力したり、人間にはあまりない間違いをすることがあります。例えば今回のような記事要約の場合、記事内の時系列情報を混同する、対義語に変換されて出力されるといった現象が起きます。自分自身の経験として、ニュース記事の要約を作成する場合に、人間ではこのような間違いはほとんど起こりません。間違いを起こさない・人間が理解できる間違いだけをする、ということは AI にはまだ難しいため、ある程度の間違いは許容されるような用途に現在の生成 AI は向いています。ニフティニュースにおいては注釈をつけることで生成 AI の限界をユーザーに認識してもらいつつ、生成 AI を活用する道を現在も模索しています。

また、今回は生成 AI に JSON を出力してもらうことでプログラム内で扱いやすくしています。JSON を直接出力してもらうことで取り扱いがしやすくなる一方で、Claude 3 Haiku などのモデルでは有効な JSON が出力されやすい傾向にあることは確かですが、出力された JSON が有効かどうかを確認する作業は必要となる、というのが私の経験に基づく感想です。リトライ処理などを追加し、生成 AI が苦手とする作業を補うことによって、既存のアプリケーションへの適用を素早く行うことが可能になると思います。

本記事ではマネージドかつサーバーレスに機械学習システムを構成し、生成 AI プロダクトをプロダクションにリリースする一例について紹介しました。Amazon Bedrock を利用することで、AI を活用したチャレンジングな取り組みを手軽かつスピード感を持って行うことが可能になったと感じています。

さらに Amazon S3 と Amazon CloudFront を効率的に活用することで、WebAPI での静的コンテンツ配信において追加のアプリケーションサーバ開発不要で素早くプロダクションへのリリースが可能になります。AWS を効率的に活用してこれからも最高の AI アプリケーションを作っていきたいと思います。