はじめに
こんにちは！Chamiiです( *´艸｀)
今回は第2回 Bedrock編ということで、Amazon Bedrock × 機械学習による新キャラクターの経済性検証の基盤設計と実装 アーキ編に引き続き、Amazon Bedrock × 機械学習による新キャラクターの経済性検証についてご紹介したいと思います。
なお、この記事に出てくるイラストはすべて筆者の手描きです。（イラストが趣味です）
また、この新キャラクターの分析の部分が特許申請中のためぼかして説明します。
想定読者
AWS、特にBedrock周りを触ったことがある、または知識がある方及び、機械学習に一定理解のある方が基本的には対象ですが、以下に当てはまる人はぜひ読んでいただきたいです。
- チャットボットを作るだけじゃ物足りない、複数のAWSサービスを組み合わせて何か面白いことをしたい方
- LLMのハルシネーションや精度のバラつきに困っていて、定量的な数値の出力に一定の正確性を求めたい方
- LLMのコストや制約（Rate Limit）に泣かされている方
この記事から学べる事
- マルチエージェントの設計思想
- エージェントにおけるメモリ戦略
- プロンプトの工夫
背景
背景は第1回 アーキ編の背景の通りなのでこちらをご参照ください。
全体アーキテクチャ
今回はBedrock編なので、下図赤枠部分がメインの話になります。
ここまでが振り返りで、この下からで本題に入ります。
推論のフローとBedrockの関係
■今回構築した推論フロー
① Input
IP設計書及び、その設計書をもとに描いた画像をインプットとする
キャラについて、要素分解を筆者なりに実施した結果、以下3つに要素分解できると考えて設計書を構築
-
IP設計書
このキャラ(IP)について、上図の3要素を設定する。例：
-
IP画像
IP設計書をもとに描いた画像例：
② IPの要素抽出
①のインプットをもとに見た目及び性格、世界観について要素を抽出する。（ここで出力されたものがキャラクターの特徴量のインプットとなる）。見た目の評価については画像が入力可能なClaude 3 Haikuを利用しました。
なお、IPの要素抽出についてはそのキャラの外見について、逆生成ができるほど解像度が高くなるように、また世界観については感情・見た人への効果（役割）・ストーリーが明確に言語化されるようにプロンプトチューニングを実施しています。
このIPの要素抽出は定型処理のため、AIエージェントは利用していません。また、必ずJSONファイルで出力されるようにルールベースのプロンプトを記載しています。
IP要素抽出のプロンプト
# IP要素抽出のプロンプト
あなたはトップレベルのIPデザイナー兼アートディレクターです。
入力された画像をもとに、IPの本質を分解・言語化してください。
# 目的
このIPを「別ポーズ・別シーンでも同一キャラクターとして再現できる状態」まで定義すること
# 出力形式（厳守）
以下の形式を守り、JSON形式で出力しなさい。
## ① 外見要素（再現性のための分解）
以下の観点で具体的かつ構造的に記述してください
- シルエット（最重要）
- 頭身（例：1頭身、2頭身など）
- 輪郭（丸い、楕円、角張りなど）
- 特徴的な形（例：耳が長い、頭が大きいなど）
- 顔の構造
- 目（形、位置、サイズ、特徴）
- 口（形、開閉、表現）
- 鼻（有無・形状）
- パーツ構成
- 手足（長さ、太さ、関節表現）
- 体の構造（胴体の有無、一体型など）
- 色・質感
- メインカラー
- サブカラー
- 質感（マット、ふわふわ、光沢など）
- 固有特徴（最重要）
- このキャラを一意に識別する要素を3つ以上
---
## ② 世界観・キャラクター性
- 感情トーン（例：健気、いたずらっ子、無気力など）
- 性格・役割（例：癒し系、ツッコミ役など）
- 行動パターン（どういう動きをするか）
- 想定シーン（どんな場面で使われるか）
- ターゲット（誰に刺さるか）
---
## ③ 性格
- 基本性格（例：優しい、わがまま、臆病、ポジティブ）
- 対人スタンス（例：依存型、独立型、世話焼き、無関心）
- 欲求・動機（例：構ってほしい、認められたい、楽したい）
- 弱点・欠点（例：すぐ拗ねる、飽きっぽい、面倒くさがり）
---
## ④ 抽象化（超重要）
このキャラクターの本質を以下で表現してください：
- 一言コンセプト（20文字以内）
- コアバリュー（なぜ人に受けるのか）
- NG条件（これを変えると別キャラになる要素）
---
# 制約
- 抽象論は禁止（必ず具体化する）
- 見たままではなく「再現可能な粒度」で記載する
- デザイナーがそのまま使えるレベルで記載する
# 出力形式:
以下に示す情報を必ずJSON形式で出力してください。
# JSON形式のポイント:
1. JSONは必ず UTF-8エンコード対応の標準フォーマット で記載してください。
2. 最上位構造は必ず リスト（[ ]） とし、その中に1つ以上のオブジェクト（{{ }}) を含めてください。
3. すべてのキーと値は ダブルクォーテーションを使用してください。
4. 不要な文章や説明文は削除し、純粋なデータのみをJSON形式で返してください
5. 回答には絶対に「json」や余計なテキストを含めないでください。
6. フォーマットエラーが発生しないよう、厳密に構文を守ってください。
③ RAG
新キャラクターの特徴をもとに関連情報を取得することを目的として、Amazon Bedrock Knowledge Basesを利用してRAG機能を実装。第1回で記載した通り、データ取り込み・chunking・embedding・retrieval・orchestrationまで含めてマネージドでRAGの機能を提供してくれるサービスです。構造データだけでなく、非構造データも扱えるのが便利なところですし、何よりフルスクラッチで作る必要がないところが便利だと思います。また、一定プロンプトをチューニングをしきらなくても性能が出るところは純粋に凄いなと思います。一方で、フルマネージドであるがゆえに内部パラメータ（chunking戦略・reranking制御）が限定的にしか制御できないため、Knowledge Basesを利用したRAGの機能で性能が出ない場合はフルスクラッチでの実装が必要になる想定です。ここの性能検証もいつかやりたいと思っていますが今回は置いておきます。
なお、Knowledge Basesの内部処理はこんな感じになっているのではないかと予想しています。
Input
↓
Chunking (チャンキング戦略で詳細を指定)
↓
Embedding (埋め込みモデルでモデルを指定)
↓
ベクトルストア作成
↓
Retrieve
↓
クエリ結果出力
筆者の感想の範囲にとどまりますが、Knowledge Basesは複雑すぎる非構造化データや大きな構造データがインプットの場合性能が落ちる傾向にあると感じているので、そのようなデータが多い場合はフルスクラッチによる実装と比較する必要があると考えています。
今回はどういうキャラが売れやすい（市場規模が大きくなりやすい）のかを論じている論文をいくつかダウンロードしてインプットしました。
■インプットしたデータ
- IP Research That Is Currently Exploding in Popularity - Taking Chiikawa as an Example
- Research on the Success Elements of Animation IP: Creativity, Marketing, and Globalization
- Research on the Success Elements of Animation IP: Creativity, Marketing, and Globalization
④ IPを評価（特徴量を抽出）、⑤学習済みモデルに入力について
④ IPを評価（特徴量を抽出）、⑤学習済みモデルに入力について、特許の関係で詳細は記載できないが以下のようなフローのモデルを構築。
④ IPを評価（特徴量を抽出）
個人的には、生成AIを特徴量生成器として利用することが面白いポイントかなと理解しています
②IPの要素抽出及び③RAGの出力をインプットにIPを評価。今回は見た目、性格、世界観、名前で計10項目（10次元）で評価を実施し、データを生成
ここでは10項目について0-1のスコアで定量的に評価しています。
このとき、「0-1で回答してください」、というシンプルなプロンプトだと0.7-0.9に偏る傾向があるため、出力値が特定レンジに偏らないよう分布を分散させるよう指示し、0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0を選ぶ確率を回答させ、加重平均を算出することを工夫しました。
⑤ 学習済みモデルに入力
トレーニング済みモデルに④ IPを評価の結果をインプットし、出力を取得する。
イメージは下図の通りで、特徴量をインプットすると、何円の市場規模があるか出力する。
インプットデータサンプル
| カテゴリ | 項目名 | 値 | 意味 | ビジネス影響 |
|---|---|---|---|---|
| コンテンツ力 | IP新規性スコア | 0.7 | IPの独自性・新しさ | 話題性・初速に影響 |
| コンテンツ力 | ファンダム拡張性 | 0.8 | ファンが広がるポテンシャル | LTV・継続収益に影響 |
| コンテンツ力 | ファンダム深度 | 0.75 | ファンの熱量・ロイヤリティ | リピート・課金に影響 |
| マネタイズ | グッズ売上比率 | 0.4 | 売上に占める物販割合 | 利益率・収益構造に影響 |
| マネタイズ | 収益多様性 | 0.6 | 収益源の分散度（広告/課金/物販） | リスク分散・安定性 |
| 投資 | マーケ予算（MUSD） | 0.3 | マーケティング投資額 | 認知・初期売上に影響 |
| 展開戦略 | メディアミックス数 | 2 | 展開チャネル数 | スケール・拡張性 |
| 供給力 | キャラクター数 | 5 | 登場キャラ数 | 商品展開・推し分散 |
| 市場 | ジャンル成長率 | 0.1 | 市場の成長性 | 外部環境として影響 |
| マーケ効率 | CPM（USD） | 8 | 広告単価 | 獲得効率・ROI |
出力データサンプル
70.0
※単位は億円
⑥ 推論結果からマルチエージェントで根拠を分析
今回は、単一エージェントではなくマルチエージェント構成を採用し、推論結果に対する根拠分析を実施しています。
その理由は以下の2点に集約されます。
- エージェント間の視点の分離による分析精度の向上
- 思考過程の構造化による再現性の担保
なぜ単一エージェントでは不十分か
単一エージェントによる推論は、一見シンプルで高速ですが、以下の構造的な課題があると考えています。
- 観点が単一化し、評価軸が暗黙的になる
- 思考プロセスがブラックボックス化する
- 出力の再現性が低くなりやすい
特にキャラクターの市場性評価のように、「魅力」「拡散性」「収益性」といった複数軸が絡む問題においては、単一の推論ではバイアスが乗りやすく、評価の一貫性が担保されない可能性があります。
今回は以下の5体の専門家エージェント(IP市場性検討エージェント構成)を作成して分析を実施。これらのエージェントはすべてBedrock Agentsで作成しており、実体化しています。また、IP Content Analyst、Fandom Growth Strategist、Monetization Plannerの3体のエージェント群はStrandsで実装しており、論点を並列に分析します。今回は深層学習に加えて専門家エージェントの思考回路をメモリに格納していくことにより、将来的に専門家エージェントと対話することを想定したいと考えました。よって、以下のメモリ戦略のうちEpisodic memory strategyを利用し、オーケストレーターエージェントにノウハウを蓄積しています。また、批評家エージェントを加えることにより議論の収束を防ぎ、新しい観点での議論を実現します。
AgentCoreのメモリ戦略の一覧
| メモリ戦略 | 特徴（システム的性質） |
|---|---|
| Semantic | 構造化された「事実」を抽出・永続化する。冗長な会話から意味を正規化し、再利用しやすい形で保持 |
| User preference | ユーザーの嗜好を継続的に蓄積し、安定したパーソナライズが可能 |
| Summary | セッション内の情報を圧縮し、トークン効率を最適化する。逐次的に更新される要約状態を保持 |
| Episodic | 文脈の中から「重要イベント」を選択的に抽出し、ストーリーとして保持 |
IP市場性検討エージェント構成
| エージェント名 | 役割 |
|---|---|
| Orchestrator | 全体統括。各専門エージェントの分析結果を統合し、最終的な市場性判断（Go / No-Go / 条件付きGo）を行う |
| IP Content Analyst | IPの魅力（新規性・キャラクター性・世界観）を評価し、ユーザーに刺さるポテンシャルを分析する |
| Fandom Growth Strategist | ファンダムの拡張性（SNS拡散・UGC・コミュニティ形成）を評価し、バズ・長期成長の可能性を分析する |
| Monetization Planner | 収益構造（グッズ、広告、課金、ライセンス）を設計・評価し、収益最大化の戦略を提示する |
| Critic | 全分析に対して批判的視点でレビューし、過大評価・リスク・前提の甘さを指摘する |
Agent as Toolsパターンの理由
各専門エージェントは独立した意思決定主体ではなく、「ツール」としてオーケストレーターから呼び出される設計としています。
これにより、
- 制御フローの明確化
- レイテンシの最適化
- 不要な推論ループの抑制
が実現可能になる。
メモリ戦略がEpisodic memory strategyの理由
Episodic memory strategy を利用する理由は、これは単なる事実（Semantic）ではなく、
- どのような観点で評価したか
- どのような議論が行われたか
- どの判断に至ったか
といった「思考の流れ」をイベントとして蓄積するためです。
これにより、分析プロセスのトレーサビリティ確保であったり、ナレッジの再利用が可能になる想定です。
メモリの識別子の設計
AgentCoreのメモリについてはactor_id と session_idがキーになる。それぞれ以下のように定義。
なお、ユーザーをグループごとに管理する可能性がある場合はactor_idをteam_id-user_id等ハイフンで結合することを想定しています。
- actor_id : user_id
- session_id : chat-yyyymmdd-0n
躓きポイント
① Strandsのセッション管理が単一エージェント中心の設計となっている話
正直ここは、かなりハマりました。
最初はシンプルに「複数エージェントが同じセッションで会話するなら、メモリもそのまま共有すればいい」という感覚で実装していました。
ただ実際に動かしてみると、ログには warning が大量に出続け、挙動もどこか不安定で、「一応動くけど信用できない」状態になりました。この時点では原因が分からず、「メモリの設計が悪いのか？」「プロンプトか？」「AgentCore側か？」と切り分けにかなり時間を使いました。
後から分かったのは、Strands Agents SDK のセッション管理自体がそもそもマルチエージェントでの共有を前提にしていない設計だったという点です。つまり、1つのセッションに対して複数エージェントが同じメモリ戦略をそのまま適用すると、コンテキストの注入や状態管理が競合してしまい、warningや不整合が発生しやすい構造になっていました。
この前提に気づいてからは設計を見直し、上図のように メモリは司会者（オーケストレーター）エージェントのみに持たせる 形に変更しています。各エージェントはステートレスに振る舞わせ、会話の履歴や文脈はすべて司会者が集約して管理する構成にすることで、ログの安定性も上がり、挙動も明確になり、ようやく「安心して使える状態」になりました。
#次回予告
今回の記事ではBedrockに注目して解説しましたが、次回はこれらの結果と考察を共有予定です。
ぜひ次回もお付き合いください<(_ _)>