オンライン英会話のレッスンレポート作成を生成 AI で置き換え
~レアジョブ英会話における生成 AI の実装
Author : 羽田 健太郎 (株式会社レアジョブテクノロジーズ)
Amazon Bedrock の採択理由
この機能を実現するには、2 つの課題を解決する必要がありました。「多くのトークンを処理でき、高精度に結果を出力できる」「セキュリティ・ガバナンスレベルを下げずに自社顧客に提供できる」です。
前者においては弊社のユースケースでは扱われるテキスト量も多く (1 回の処理あたり、2 ~ 4 万 token を見込んでいた）、また生成結果が間違えて誤った校正をしてしまうリスクも避けたいところだったので、多くのトークンを扱え、高性能な Claude の利用できる Amazon Bedrock は最適な選択肢でした。
後者においてはレアジョブ英会話はすでに多くの顧客がおり、個人だけでなく法人のお客様も多く利用いただいております。また企業としても ISMS の取得やセキュリティ・個人情報の取り扱いには明確なガイドラインがあり、無邪気に生成 AI のサービスを導入することができませんでした。
これに対して Amazon Bedrock によりフルマネージドな 生成 AI サービスを AWS 上の自社インフラで完結して提供できることになり、この課題が解決しました。弊社の法人のお客様には特定の 生成AI サービスの利用を明確に禁止しているところもあり、これを活用した機能を提供するにしても、それを企業ごとに利用の可否をコントロールする仕組みを作らなければいけなかったので、自社インフラで完結できる価値はコスト面だけでなく、ガバナンスや対顧客面でも大きなメリットがありました。
上記は現在のアーキテクチャの構成です。弊社のレッスンではいくつかのベンダーのインフラや Saas を組み合わせて実現されています。レッスン自体やその音声を取り扱うのは AWS ではない外部インフラになりますが、AIレッスンレポートβ を構成しているインフラは AWS で完結しています。
一部の処理は Platform という位置付けで Amazon API Gateway、AWS Lambda、Amazon DynamoDB を使ってサーバレスな構成にしています。徐々に展開率を上げていくことを前提としてスケーリングをあまり考えないでいい構成を選びました。
またこのレイヤーで AI に実行させるべきではない利用権限の管理や、汎用的な Amazon Bedrock への問い合わせ・応答などを管理しています。また今後もベータ版として提供したい機能を検証しやすくするために、既存アプリケーションは Amazon EC2 で提供していますが、こことは分離しベータ版アプリケーションを提供する部分のみ Amazon ECS で構築し、高速に検証できる状態を構築しています。
Amazon Bedrock で処理している箇所
生成 AI は優秀なので、なんでも任せたくなってしまいますが、精度やコスト面からケースにおいては全てではなく、やることは限定させる必要があります。
我々のケースでは「話したユニークな単語数」なども出力していますが、こういった処理は生成 AI にまかせるのではなく別途実装しています。また NG ワードの検知やそれが発生した時の対応なども生成 AI は使っていません。「発話文の文章校正」や「校正理由文の作成」など、ユースケースにおける本当に生成 AI が実施すべきことに集中させています。そのためプロンプトは下記のようにシンプルになっています。
Human: You are an English tutor helping students improve their conversational English.
.... （省略）
Please categorize the rewrite in to one of the following catalog,
.... （省略）
generate the feedback in the following JSON format, contains in <json_format>.
<catalog>
- original:
* keep the original sentence- grammar_fixes:
* .... （省略）
</catalog>
<json_format>
[
{{
"n": #,
"speaker": #,
"transcript": #,
"rewrite": #,
.... （省略）
}}
]
</json_format>
<transcript_json>(report_prompt_data_string)</transcript_json>
Make sure to provide a valid JSON output with the correct format.
Assistant: <json>
工程における注意や工夫
起案・要件定義 => 設計・開発 => 評価のように開発プロセスが進むことが多く、一般のプロダクト開発とあまり変わりませんが、生成 AI であるが故の各ステップでの注意や工夫がありました。
起案・要件定義においては、そもそもどの生成 AI のサービスを活用すべきか、我々のユースケースにおいてはどのモデルが必要十分なのかをプロンプトを本格的に作り込む前に検討をしていました。これによって原価としてのシステムコストの試算も大きく変わってくるので、事業・機能として実現可能かを検討しました。
弊社では aws-samples/bedrock-claude-chat を社内イントラ内で構築し、皆で触れる状態を作りました。このサンプルは直近の Amazon Bedrock の最新のモデルへの対応なども早く、最速で価値を体験できる手段の一つだと思います。 Playground はエンジニアにとってはハードルは低いのですが、事業開発のメンバーがより手軽に試せる場を作ることが重要でした。
設計・開発においては上述にもある通り、生成 AI に何をやらせるかを議論し、それ以外の部分の実装や構築方法、アーキテクチャを関係者で議論をして決めました。
評価においては、我々のケースではすでに人が実施しているケースの AI への置き換えなので実際の人が作成しているフィードバックを整理し、生成 AI に同様の質問をして遜色ないレベルでの返答ができるかの検証を実施しました。モニタリングや規約でのリスクヘッジをするとしても、このフェーズである程度の AI への期待値調整をできておくと安心でした。また入出力が見えてくると、コスト面も試算しやすくなってくるので、改めてこの時点でもコストモニタリングを検討しました。2024 年 4 月の現時点では「プロジェクト毎にコスト計算」するようなことができず、billing が model 毎の計算のため、複数のプロジェクトで同じ base model を呼び出すとコスト計算が分けられないという課題があります。この辺りは今後のアップデートに期待しています。
まとめ
この記事では Amazon Bedrock を使ったプロダクト開発における注意点や設計の事例を紹介しました。構築した内容は非常にシンプルではありますが、本格的に自社でのプロダクトへの組み込みにおいては上述のような注意点や知見が多く得られて、やはり早期に実験をしておくべきだと思いました。
まだまだ紹介したいことがたくさんあるのですが、文章だと無限に書けてしまうのでいったんここまでとさせていただき、より詳細・アップデートがあった部分については AWS Summit 2024 において登壇の機会をいただいているので、そちらでお話しさせていただければと思います。この記事を書いている間にもどんどんアップデートされている Amazon Bedrock の話を皆さんとできるのがとても楽しみです。幕張で会いましょう！
筆者プロフィール
羽田 健太郎 Kentaro Haneda（ジャンボ）
株式会社レアジョブテクノロジーズ
執行役員 CTO
2016年よりレアジョブにジョイン。アプリ事業立ち上げやレッスンシステムの内製化、新規事業の立ち上げなどを担当。現在はCTO兼PdMとして、日本とフィリピンを横断し、企画から開発、デザイン、運用までを管掌している。
AWS を無料でお試しいただけます