Amazon Bedrock × 機械学習による新キャラクターの経済性検証の基盤設計と実装 アーキ編

はじめに

こんにちは！Chamiiです( *´艸｀)
勢いが衰えることを知らないGenAIの勉強と、特許の申請でてんやわんやしている間にこの記事が6か月も温まってしまいました(笑)
まだ仮申請の段階なので一部ぼやかして書きますがBedrock×機械学習でビジネス的な分析をすること自体に将来性を強く感じているので、いつか全量を紹介したいと思います。

話が長くなるのでアーキ編、Bedrock編、検証編の3回に分けて記事を書きます。
これは第1回 アーキ編です。

想定読者

AWS、特にBedrock周りを触ったことがある、または知識がある方及び、機械学習に一定理解のある方が基本的には対象ですが、以下に当てはまる人はぜひ読んでいただきたいです。

• チャットボットを作るだけじゃ物足りない、複数のAWSサービスを組み合わせて何か面白いことをしたい方
• LLMのハルシネーションや精度のバラつきに困っていて、定量的な数値の出力に一定の正確性を求めたい方
• LLMのコストや制約（Rate Limit）に泣かされている方

この記事から学べる事

• 定量化しにくい対象や、評価や予測をするにあたりデータが不足している対象についてLLMで定量評価、予測をするノウハウ
• Amazon Bedrock × 機械学習のビジネス的な使い方（のアーキ）
• マルチエージェントを活用した分析基盤検討（のアーキ）

前置きが長くなりました！では早速中身に行きましょうε≡≡ﾍ( ´Д`)ﾉ

背景

言わずもがな勢いがすごいAI agentとMulti-Agent

最近よくAIエージェントという言葉を耳にするようになりました。私自身IT関連の部署に身を置いていることもあり、毎日更新されるAI系テクノロジーのサービス、ノウハウに追いつくので精一杯です。改めて、このAIエージェントがいつから流行ったのかを調査すると、2024年後半からグッと注目度が上がっています。ちょうどGPT-4系やClaude-3系がリリースされたあたりで、生成AIの印象が「面白い」から「使える」に変わった時期ではないかと記憶しています。年々注目度を高めているAI関連技術はやはり追っていかねばと思わされるデータですね。一方で、意外とトレンドがまだ来ていないのがマルチエージェントです。私個人としては、マルチエージェントもとても面白いので早く波がくればいいのに、と思っています。

なぜBedrock × 機械学習をやろうと思ったのか

私は大学時代ロボットマニピュレーション×深層学習の研究をしていたんですが、データを取るのにそれはそれは苦労しました。センサに毎回入ってしまうノイズ、思う通りに動いてくれないロボット、欲しいと思ったタイミングでなぜか売り切れる材料、、、散々な研究生活でした(笑)
社会人になって毎日AIと対話することが仕事になった昨今、生成AIがあったらデータとるのに苦労しないのにな、、と思いついたのがきっかけで今回の検証をやろうと思いました。

新キャラクターの評価の難しさ

新キャラクターの経済性とはすなわち、このキャラを作った時に最終的にいくらの規模の市場規模が取れるか、ということです。キャラ関連コンテンツを販売したり、ライセンスを提供する直接マネタイズ型、SNSやプラットフォームから知名度を上げてグッズ販売を行う間接マネタイズ型などマネタイズ方式は色々ありますが、今回検証したいのは年間いくらの利益を生み出せるか、です。
**既存キャラであれば例年のデータを扱った推定が一定可能ですが、新キャラはそうもいきません。**前例が基本的になく、キャラ（IP）関連データがそもそも不足しているケースが多いこと、また市場そのものが未形成であるうえ、トレンドにも左右されます。よって、新キャラをリリースする際は基本的に仮説の連鎖になることが多い印象です。どのようなターゲットにアプローチするのか、そのターゲットの購買率はどれくらいか、他キャラの傾向を参考にどれくらいでグッズ化までたどり着きそうか、などなど要素をフェルミ推定チックに考えていくわけです。このやり方は投資判断として説明責任が弱く、また属人化した暗黙知で推定、評価されるので再現性もないわけです。

解決したい課題

よって、解決したい課題は以下です。
①. アイデア評価の属人性

• キャラクターのIPの市場性の評価が属人化されており、言語化されているケースが少ない
• 人によって評価が変わる（再現性がない）
• 組織として知見が蓄積されない

②.試算した経済性と現実の乖離

• 感覚や暗黙知で試算された経済性は現実との乖離が発生するリスクがある

③.意思決定のしにくさ、投資判断の不透明性

• なぜこの新キャラがGOなのか説明しにくい
• コンセプト検証に時間もコストもかかる

上記を解決するために簡単な模式図にすると以下のようなことをAWSで実現します。

仮説：機械学習はパターン抽出が得意なことを生かし、既存キャラの特徴量と経済性の非線形パターンを学習できれば、新キャラの特徴量に対して経済性の推定値を出力可能である

全体アーキテクチャ

全体アーキテクチャは下図です。
アーキテクチャは①フロントレイヤ、②推論・生成レイヤ、③データレイヤで構成しています

アーキテクチャ概要

①フロントレイヤ

ユーザーがキャラ(IP)の画像や設定を入力する想定のUIにしています。
Cognitoによる認証はプロユースを想定して設定しています。

• Next.js UI
• Cognito（認証）

②推論・生成レイヤ

実行、推論基盤部分で今回の検証のコアになるところです。

• Lambda（オーケストレーション）
• Bedrock（LLM / AIエージェント / RAG）
• SageMaker Endpoint（数理モデル）

③データレイヤ

学習データやナレッジ、実行ログ等を管理します。

• S3（Raw / Feature / RAG）
• Glue（ETL）

技術選定の根拠

Bedrockを使う理由

外部API(OpenAPIなど)を呼び出す、OSSで構築する、など生成AIを使いたいだけなら何でもいいわけですが、今回は（検証も兼ねて）Amazon Bedrockを利用しました。

理由①：マルチモデル戦略が容易に実現可能

Bedrockで使えるモデルはNova系やAnthropic系を始めかなり増えてきましたね。その分Bedrockから呼び出せば、Claude / Nova / 他モデルを統一APIで利用可能なのでユースケースごとに最適なモデルを選ぶことができます。同じClaudeでもHaikuとSonnetでは性能も（コストやレイテンシも）違うわけなので、ユースケースやそのLLMに求める回答の質をどこまで求めるか、で利用するモデルは戦略を立てないといけないわけです。

私のよく使うモデル

軽い処理 → Haiku / Nova Lite
重い推論 → Sonnet
超重要 → Opus

今回は以下のように使い分けました。

参考までに全部Sonnetに寄せた場合と適宜モデルを変更した場合のコストを簡単に比較します。（すべてus-west-2で算出）
参考：Amazon Bedrockの料金

パターンA: すべて Sonnet に寄せた場合

特徴抽出: Sonnet 3
最終推論: Sonnet 3
補助要約: Sonnet 3とすると

特徴抽出: 3,000入力トークン/1,000 * 0.006 + 800入力トークン/1,000 * 0.03 = $0.042
最終推論: 6,000入力トークン/1,000 * 0.006 + 1,500入力トークン/1,000 * 0.03 = $0.081
補助要約: 2,000入力トークン/1,000 * 0.006 + 400入力トークン/1,000 * 0.03 = $0.024

パターンB: 補助処理を Nova Lite に逃がす場合

特徴抽出: Sonnet 3
最終推論: Sonnet 3
補助要約: Nova Lite とすると

特徴抽出: 3,000入力トークン/1,000 * 0.006 + 800入力トークン/1,000 * 0.03 = $0.042
最終推論: 6,000入力トークン/1,000 * 0.006 + 1,500入力トークン/1,000 * 0.03 = $0.081
補助要約: 2,000/1,000 * 0.00006 + 400/1,000 * 0.00024 = $0.000216

つまり、軽量タスクを Sonnet に投げるか Nova Lite に投げるかで二桁以上差が出ることがわかると思います。これを何も考えずにやるとコストが膨大になりますので、ちゃんとモデルは選択する必要があるわけですね。

理由②：業務要件への適合

このキャラは商用利用想定のため、生成AIへの学習に使われたり、事前に流出することは避ける必要があります。これを容易に実現できるのがBedrockの強みと考えています。

①. インプットデータの非学習の保証
Amazon Bedrock の公式では、明確に以下が記載されています。学習データにされないこと、これが生成AIを使うときに必ずチェックする必要があるポイントです。

“Amazon Bedrock does not use your prompts or responses to train AWS models.”

②. インターネットを経由しない
BedrockはVPC Endpoint経由でアクセスしています。また、データ等もすべてS3に格納しており、Web検索等も実施していないため、このアーキはインターネット非経由で実現しています。インターネットを介する場合も工夫をすればよいことではありますが、基本的にインターネットに出ない、を原則にしたいところです。

理由③：RAG / Agent / Guardrails の統合

Bedrock GuardrailsおよびKnowledge BasesがGAされるまで、Embedding、Re-rankingやHybrid SearchなどRAGの機能や出力の制御（不適切なものを落とすネガティブプロンプト制御）をフルスクラッチで書いていたわけですが横展開しにくいうえに運用もハードな状態になっていました。この2つの機能がリリースされたことにより、シンプルな構成で比較的簡単にAgent周りを作れるようになりました。

①. RAG（Knowledge Bases）
S3やRDS、外部データなどをインプットして、Embeddingモデルを決めて実行すればマネージドでRAGの機能を提供してくれるサービスです。構造データだけでなく、非構造データも扱えるのが便利なところですし、何よりフルスクラッチで作る必要がないので、コード量が少ないし標準化できるという点でも開発工数は大幅に小さくなりました。Embeddingの時に選ぶモードによっては相性の悪いデータ、良いデータがあり、それは必ずしも下図のData parsedの定義通りではないのですが、その話は別記事でご紹介できればと思います。今回の検証では全てデフォルトパーサーで実施しています。

②. Guardrails
LLMの生成はハルシネーションが発生したり、暴力的な表現や差別的な表現など不適切な表現が往々にして発生します。特に小説や画像など創作においてLLMを野放しにすると信じられないデザインが出てくることもしばしば。よって、以下のようにInputとOutputの間にGuardrailsをいれ、ゲートとして機能させています。

User Input
↓
[Guardrails(入力チェック)]
↓
LLM
↓
[Guardrails(出力チェック)]
↓
Output

今回は特に以下のコンテンツフィルタ(block)を設定しました。

• 暴力的な表現
• 性的な表現
• 社会的、倫理的にNGな表現

Step Functions を使わなかった理由

今回は処理が単純（フローがシンプル）だったのであえてLambdaのみで実装しました。また、まだ検証レベルなのでできるだけコストを抑えたかった、という気持ちもあります。
このアプリがプロユース化されるときにはもっと前処理、推論が複雑になるので、別の回でBedrock AgentCoreを利用した場合はどうなるか？を検討したいと思っています。

躓きポイント

筆者が躓いたポイントは以下の通りです。特に1つ目は大事！

①コスト最適化が“できていなかった”話

モデル選択自体はそれなりにうまくいっていたんですが、完全に盲点だったのが「トークン量の管理」でした。

最初はこんな感じで考えていました
「軽い処理はHaiku、重い処理はSonnetでいい感じに分けたし大丈夫でしょ」

・・・結論全然大丈夫じゃなかったです。

請求を見てびっくりしたんですが、想定の3倍くらいのコストが出ていました。
原因をちゃんと分解してみると以下の事象が発生していることがわかりました。

• コンテキストを毎回フルで渡していた
• RAGの結果をそのまま全部突っ込んでいた
• 中間処理でも無駄に長いプロンプトを使っていた
• 出力も必要以上に冗長だった

つまり「モデルではなく“入力の長さ”でコストが爆発していた」ということです。
意外と見落としがちなんですが、入力トークンと出力トークン、この両方で課金されるので、「どのモデルを使うか」より「トークンをどれだけ渡すか」の方が効く場面が普通にあるんですよね。

このときの学びはかなりシンプルで

• 本当に必要な情報だけ渡す（RAGも絞る）
• 中間ステップは“短く・雑に”する
• 出力は構造化して冗長な文章を減らす

ことが大事なんだと気付きました。
ここをサボると、本当に平気でコストが倍々ゲームになりますのでお気をつけて。。。

②非同期設計を後回しにして詰んだ話

最初にこのシステムを組んだとき、正直に言うと全部同期で作りました。
理由は単純で、「その方が実装が楽だったから」です。早く動くものを作りたかったんです。
ですが、

• 特徴量抽出(LLM)
• RAG
• 補助処理(LLM)
• 推論

これを全部直列でやるので出力が全部出るまでに時間がとてもかかりました。
なのでこの事象を受けて、

①. 特徴量抽出をバッチ化して非同期処理にする
②. 重い推論を非同期実行にして、UIなどはポーリングさせる

その結果UXはかなり改善されました。
結局作り直しに時間がかかったので、「非同期は“後から足すもの”じゃなくて“最初に決めるもの”」だなと痛感しました。なので最初にちゃんと決めるべきは

• どこまでを同期で返すか
• どこからを非同期に逃がすか
• ユーザーにどう見せるか（UX）

なんだと思います。

次回予告

今回の記事ではアーキテクチャ全体と技術選定について解説しましたが、次回はBedrock編でエージェントの設計思想やメモリ・セッション戦略などAIエージェントについて詳細を解説予定です！
良かったら次の記事も読んでいただけると嬉しいです<(_ _)>