👻

AWS Bedrockを使った大規模メールデータ要約システムの開発話

2025/11/25に公開

テーマ「2025年の最も大きなチャレンジ」

gemini banana (pro) で作成した画像。大河のようにあふれる情報から大事な情報を汲み取るイメージ。
こんにちは！この記事は、私が所属するチームが掲げる「AI武装」をテーマにしたアドベントカレンダーの一環として、日々の開発で実践しているAI活用の知見を共有するものです。
https://qiita.com/advent-calendar/2025/ca-advance-ai

 この記事の概要皆さんの現場では、「レポート作成」という業務にどれくらいの時間を費しているでしょうか？多くの現場で、データ集計や分析、そして報告資料の作成は、目には見えにくいけれど確実に時間と労力を奪っていく「見えないコスト」になっているのではないでしょうか。
今回は、そんな開発現場でよくあるレポート作成業務の課題を、生成AI、特にAWS Bedrockを活用して解決した「AI要約レポート機能」の開発秘話をご紹介します。単にAPIを叩くだけではない、大規模データを扱うためのアーキテクチャ設計や、泥臭いモデル選定の過程など、リアルな試行錯誤を共有できればと思います！

 レポート作成の「見えないコスト」という課題このプロジェクトが始まる前、私たちが開発・運用する自社開発の顧客サポートシステム（以下、社内SaaS）には、標準的なレポーティング機能が搭載されていました。しかし、この機能がユーザーと開発者の双方にとって、大きな負担となっていたのです。
ユーザー側の課題
きっかけは、2025年4⽉のユーザーアンケート結果でした。多くの顧客サポート担当者がレポート業務に課題を感じていることが明らかになったのです。その原因は、既存の機能が持つUI/UXにありました。
専門知識の壁: データを正しく分析・解釈するためには、統計学やそのドメインに関する深い知識が不可欠でした。結果として、一部の熟練したユーザーしか機能を使いこなせず、レポート作成業務が属人化していました。
工数の増大: 属人化が進むと、レポートを必要とする他のメンバーからの依頼が特定の人に集中し、その人の工数が圧迫されるという悪循環に陥っていました。
開発者側の課題
一方で、私たち開発者側も大きな課題を抱えていました。
開発のスケーラビリティ問題: レポート機能のカスタマイズや機能追加には、統計学、RDBMS、検索エンジン（OpenSearch）など、多岐にわたる専門知識が必要でした。そのため、開発がスケールしにくい構造になっていました。
個別ニーズへの対応困難: 既存の機能は、あくまで一般的なユースケースを想定したものです。特定のドメインや細かいニーズに合わせたレポートを提供するには、その都度、追加開発が必要となり、開発リソースを大きく消費していました。
これらの課題は、ユーザーと開発者の双方にとって「見えないコスト」となり、事業成長の足かせになりつつありました。この状況を打開するため、私たちは全く新しいアプローチを模索し始め、その答えが「AIによる自動化」だったのです。

 発想の転換：「レポート作成」は「文章要約」である課題解決の糸口は、まさに「時代の潮流」ともいえる生成AIの登場でした。ChatGPTやClaudeといった高性能なLLMが次々と現れ、開発者の間で「要約」や「コード生成」といったユースケースが当たり前のように語られるようになりました。
ここで、私たちは発想を転換しました。 「ユーザーが本当に知りたいのは、生のデータではなく、そのデータから導き出される分析や解釈ではないか？」 「そして、その分析や解釈を含むレポート作成は、生成AIが最も得意とする『文章要約』の一種と捉えられないか？」
このアイデアは非常にシンプルです。社内SaaSには、日々大量の問い合わせメールデータが蓄積されています。この大量のメールデータを一つの**「長文テキスト」と見立て、LLMに要約させるのです**。そうすれば、単なる数値の羅列ではなく、トレンドの分析や重要なトピックの抽出といった「解釈」を含んだ、人間が読んで理解しやすいレポートを自動生成できるはずです。
このシンプルなアイデアを、どうやって現実のサービスに落とし込んでいくか。次のセクションでは、そのための具体的なシステム設計について解説します。

 大量データを捌くためのシステムアーキテクチャアイデアを実際のサービスとして機能させるためには、堅牢な技術基盤が不可欠です。特に今回は、大量のデータを効率的かつ安定的に処理するためのアーキテクチャ設計が鍵となりました。

 非機能要件の定義まず、システムの根幹となる非機能要件を定義しました。

非同期のバッチ処理: メールデータからトレンドを抽出するという目的上、扱うデータ量は必然的に多くなります。ユーザーがボタンを押してから30分も待たせるようなリアルタイム処理は現実的ではありません。そこで、定期実行する非同期のバッチ処理を選択しました。

マルチテナント対応とスケーラビリティ: この社内SaaSはマルチテナントアーキテクチャを採用しており、大規模なマルチテナント環境の処理を想定する必要がありました。単一のプロセスでは処理に膨大な時間がかかってしまうため、テナントごとに処理を分散・並列化できる仕組みが必須でした。

 Dispatcher-Workerパターンの採用上記の要件を満たすための解決策として、私たちは「Dispatcher-Workerパターン」を採用しました。

Dispatcher: 定期的に起動し、処理対象となる全テナントのリストを取得します。そして、その後、そのリストの要素を引数に指定して、並列で Worker を呼び出します。

Worker: Dispatcherが、テナント一つひとつに対してWorkerを起動します。各Workerは担当するテナントのデータ処理（メールデータの取得、AIによる要約、結果の保存）を並列で実行します。
この構成は非常にシンプルでありながら、テナント数が増えてもWorkerを並列実行させることでスケールさせることが可能です。
詳細な説明は省きますが、上記の図のイメージのように、１つのDispatcher コンテナがECSクラスター内で起動し、同一クラスター内で Worker コンテナを多数起動することで、複数のテナントに対応しました。
また、システムデザインは以下を参考に設計しました。
https://qiita.com/takarake/items/2ac57ebb073bd0dd941c
https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageDispatcher.html

 インフラの実装インフラの構築には AWS Copilot CLI を活用しました。Copilotには定期実行ジョブをデプロイするためのテンプレートが用意されており、ECS Fargate上で動作するDispatcherとWorkerのJobを驚くほど簡単にデプロイできました。これにより、複雑なインフラ構築に時間を費やすことなく、アプリケーションロジックの実装に集中することができました。
こうして、大量データを捌くための土台が完成しました。次はいよいよ、このシステムの心臓部であるAI処理、AWS Bedrockの実装詳細について見ていきましょう。
https://aws.github.io/copilot-cli/
!AWS Copilot CLI、めちゃくちゃ便利なんですが、もう今後は機能追加されないようです。

新しく使うマニフェストツールを探している方は、シンプルに cloudformation や terraform を採用されたほうがいいかもしれません。
とは言えば、簡単に ECS クラスターデプロイできる便利なツールなので、もうしばらくは便利に使えそう。
https://github.com/aws/copilot-cli/issues/5987

 AI処理の心臓部：AWS Bedrock実装の技術選定・設計AI機能をシステムに組み込む際、どのAPIやSDKを選択するかは、その後の開発効率やメンテナンス性に大きな影響を与えます。私たちは、今回の要件に最適な技術を慎重に比較検討しました。

 SDKの比較: boto3 vs langchainAWS Bedrockを操作するためのSDKとして、主に2つの選択肢がありました。(本当に2つか・・・？技術の進化が早すぎてなにがメインストリームかもよくわからない)

boto3 (AWS SDK for Python): AWS公式のSDKであり、BedrockのAPIを直接的かつシンプルに利用できます。AWSのファーストクラスサポートを受けられる安心感もあります。

langchain: LLMアプリケーション開発のためのフレームワークで、より抽象化されたインターフェースを提供します。モデルの切り替え（例えばBedrockからOpenAIへ）が容易になるなど、複雑で汎用性の高いユースケースに向いています。
今回のプロジェクトでは、処理内容が「定型的な要約」と明確だったため、余計な抽象化レイヤーがなく、シンプルにAPIを扱える boto3 を採用しました。

 APIの比較: Converse API vs Invoke-Model APIboto3を使うと決めた後、次にBedrockが提供するどのAPIを利用するかが焦点となりました。
BedrockのLLMに推論させる場合、以下の2つのAPIが存在します。


項目
Converse API
Invoke-Model API


主な用途
テキスト会話・要約
テキスト・画像生成・埋め込み

インターフェース
全モデルで統一
モデルごとに異なるパラメータ

会話履歴
messages パラメータで簡単
自前で実装が必要

モデル変更
modelId 変更のみ
パラメータ構造も変更必要

このプロジェクト
最適
オーバースペック

Invoke-Model API: 各LLMモデル固有のパラメータを細かく指定できる、低レベルなAPIです。単にプロンプトを投げて結果を得たいだけの今回のケースではオーバースペックでした。例えば、Invoke-Model APIでAnthropicのClaudeを使うには、リクエストボディにanthropic_versionのようなキーを持つ固有の構造を作る必要がありますが、これはAmazonのTitanモデルで要求されるボディとは異なります。
Converse API: こうしたモデル間のパラメータの違いを吸収してくれる、より抽象化されたAPIです。Converse APIは、私たちがモデルプロバイダーごとの定型的な記述ではなく、プロンプトの中身に集中させてくれます。どのモデルを使う場合でも統一されたインターフェースでリクエストを送信できるため、コードのメンテナンス性が格段に向上します。
論より証拠ということで、実際のサンプルコードを比較すると、違いが明確になります。

 Invoke-Model API の場合titan モデルで実行する例
client = boto3.client('bedrock-runtime', region_name='ap-northeast-1')

body = json.dumps({
    "inputText": "健康になるためのチップスを教えて下さい。",
    "textGenerationConfig": {
        "maxTokenCount": 2048,
        "stopSequences": ["User:"],
        "temperature": 0,
        "topP": 0.9
    }
})

response = client.invoke_model(
    modelId='amazon.titan-text-express-v1',
    body=body,
    contentType='application/json',
    accept='application/json'
)

# レスポンスパース
response_body = json.loads(response['body'].read())
text = response_body['results'][0]['outputText']
nova モデルで実行する例
client = boto3.client('bedrock-runtime', region_name='ap-northeast-1')

body = json.dumps({
    "messages": [{
        "role": "user",
        "content": [{"text": "健康になるためのチップスを教えて下さい。\n\n"}]
    }],
    "inferenceConfig": {
        "maxTokens": 512,
        "stopSequences": [],
        "temperature": 0.7,
        "topP": 0.9
    }
})

response = client.invoke_model(
    modelId='arn:aws:bedrock:ap-northeast-1:880785016310:inference-profile/apac.amazon.nova-pro-v1:0',
    body=body,
    contentType='application/json',
    accept='application/json'
)

# レスポンスパース
response_body = json.loads(response['body'].read())
text = response_body['output']['message']['content'][0]['text']
上記のモデルごとの呼び出しを比較すると、body の内容が大きくことなることがわかります。
titan では、textGenerationConfig で　temperature を設定しているのに対し、  nova では、 inferenceConfig　で temperature を設定しています。
更に、レスポンスの構造もかなり異なり、モデルごとに異なるパラメータの組み立て、レスポンスの解析が必要になります。

 Converse API の場合claude モデルで実行する例
client = boto3.client('bedrock-runtime', region_name='ap-northeast-1')

# Claude Sonnet 4.5 での呼び出し
result = client.converse(
    modelId='claude-sonnet-4-5',
    messages=[{
        'role': 'user',
        'content': [{'text': '健康になるためのチップスを教えて下さい。'}]
    }]
)

# レスポンス取得
response_text = result['output']['message']['content'][0]['text']
print(response_text)
nova モデルで実行する例
client = boto3.client('bedrock-runtime', region_name='ap-northeast-1')

# Nova Pro での呼び出し
result = client.converse(
    modelId='amazon.nova-pro-v1:0',  # または適切なモデルID
    messages=[{
        'role': 'user',
        'content': [{'text': '健康になるためのチップスを教えて下さい。'}]
    }]
)

# レスポンス取得（全く同じパス）
response_text = result['output']['message']['content'][0]['text']
print(response_text)
Converse API を利用する場合は、モデルの切り替えがIDを変えるだけで変更ができます。このような汎用的なパラメータのお陰で、複数のモデルを簡単にテストできますし、ユーザーがモデルを選択するという機能にも対応できます。レスポンスについてもその形が統一されており、モデルごとの考慮も不要です。
結論として、私たちはシンプルさを評価し、Converse API を選択しました。
最適なAPIも決まりました。しかし、プロジェクトで最も重要な問いが残っています。それは、「一体どのLLMモデルを使うべきか？」です。

 LLM選定：コストパフォーマンスの罠と真の価値このセクションは、LLM選定を通じて色々な発見をすることができたので、最も重要なパートかもしれません。当初、私たちはコストパフォーマンスを重視したモデル選定を行いましたが、それが思わぬ落とし穴だったのです。

 初期評価私たちは、AWS Bedrockで利用可能なモデルの中から、品質とコストのバランスを考慮して2つのモデルを最終候補としました。
Amazon Nova Pro
Anthropic Claude (Claude Sonnet 4.5)
https://docs.aws.amazon.com/ja_jp/nova/latest/userguide/what-is-nova.html
両者を比較すると、コスト面では、Nova Proが圧倒的に有利でした。
※2025/10/14時点のコスト比較, 入力出力それぞれ100万トークンで換算


モデル
入力
出力
選択理由・却下理由


Nova Micro
$0.042
$0.168
コストは最安だが品質不足

Nova Lite
$0.072
$0.288
バランス型だが要件に不足

GPT-4o-mini
$0.15
$0.60
既存システムでの採用実績あり

Nova Pro
$0.96
$3.84
✅採用候補: 品質・コスト・AWS

GPT-4o
$2.50
$10.00
品質は高いがコスト高, AWSエコシステムから逸脱

Claude 3.5
$3.00
$15.00
最高品質だがコスト高

Claude 4.5
$3.30
$16.50
✅採用候補: 最新・最高品質だがコスト最高

入力トークン単価が約1/3
出力トークン単価が約1/5

 単純なテストでは Nova Pro で全く問題なしだが、、、価格はともかく性能はどうなんだろう、ということで、以下のように単純な応答のテストを実行してみました。
aws --profile cxplus-dev bedrock-runtime converse \
--model-id MODEL_ID \
--messages '[{"role":"user","content":[{"text":"健康になるためのチップスを教えて下さい"}]}]' \
--inference-config '{"maxTokens":2048,"stopSequences":["User:"],"temperature":0,"topP":0.9}' \
--additional-model-request-fields '{}' \
--region ap-northeast-1 > invoke-model-output.txt
その結果、以下のような出力が得られました。

 Nova Pro の場合  健康になるためのチップスを以下にまとめます。これらの習慣を日常生活に取り入れることで、全体的な健康状態を改善することができます。

  ### 食事に関するチップス

  1. バランスの取れた食事：野菜、果物、全粒穀物、タンパク質（魚、鶏肉、豆類など）をバランスよく摂取しましょう。
  2. 水分補給：1日あたり少なくとも2リットルの水を飲むように心がけましょう。
  3. 糖分と塩分の制限：加工食品、砂糖入り飲料、塩分の多い食品の摂取を減らしましょう。
  4. 健康的な脂肪：オリーブオイル、アボカド、ナッツ、種子などの不飽和脂肪を摂取しましょう。

  ### 運動に関するチップス

  1. 定期的な運動：週に少なくとも150分の中強度有酸素運動（ウォーキング、サイクリングなど）を行いましょう。
  2. 筋力トレーニング：週に2回以上、筋力トレーニングを取り入れましょう。
  3. ストレッチ：柔軟性を保つために、定期的にストレッチを行いましょう。

  ### メンタルヘルスに関するチップス

  1. ストレス管理：ヨガ、瞑想、深呼吸などのリラックス技法を練習しましょう。
  2. 十分な睡眠：大人は7-9時間の質の高い睡眠をとるようにしましょう。
  3. 社会的つながり：友人や家族との時間を大切にし、孤立を避けましょう。

  ### その他のチップス

  1. 禁煙：タバコを吸う習慣がある場合は、禁煙を検討しましょう。
  2. アルコールの適度な摂取：アルコールを飲む場合は、適度な量に留めましょう。
  3. 定期的な健康チェック：定期的に健康診断を受け、自分の健康状態を把握しましょう。

  これらのチップスを徐々に取り入れることで、より健康的なライフスタイルを築くことができます。
指示していないが、気を利かしてMarkdown形式で出力してくれている 👍
チップスをポテチではなく、Tips で理解できている 👍
上記の単純な出力を見て、ChatGPT や Gemini がめちゃくちゃ進化している昨今、なにもすごさを感じ無いかもしれませんが、先程コスト比較したモデルの中では、このような簡単な問いかけにすらまともに回答できないモデルも結構ありました。その点で、Nova Pro も性能的に悪くないかもという評価に至りました。

 Claude Sonnet 4.5 の場合  健康になるための実践的なヒント 💪

  ## 🥗 食生活

  • バランスの良い食事：野菜、果物、全粒穀物、タンパク質をバランスよく
  • 水分補給：1日1.5〜2リットルの水を飲む
  • 加工食品を控える：塩分・糖分・添加物の摂りすぎに注意
  • 腹八分目：食べ過ぎない習慣をつける

  ## 🏃 運動習慣

  • 毎日30分の運動：ウォーキング、ジョギング、サイクリングなど
  • 筋トレ：週2〜3回、基礎代謝アップに効果的
  • ストレッチ：柔軟性を保ち、怪我予防にも

  ## 😴 睡眠

  • 7〜8時間の睡眠を確保
  • 規則正しい就寝時間を守る
  • 寝る前のスマホ・PC使用を控える

  ## 🧘 ストレス管理

  • 深呼吸や瞑想を取り入れる
  • 趣味の時間を持つ
  • 人との交流を大切にする

  ## 🏥 予防

  • 定期的な健康診断
  • 歯科検診も忘れずに
  • 手洗い・うがいの習慣

  小さなことから始めて、継続することが大切です！
Claude の方は更に、絵文字もつけてくれて、ホスピタリティにあふれています 👍

 現実世界での試練： 出力結果の比較しかし、実際に数千件のメールデータ、しかもノイズを含んだ現実世界のデータを処理させると、両モデルの性能差は歴然となりました。
※実際のレポートデータはお見せできないので特徴を箇条書きで比較するだけになりますがご了承ください。

 Nova Proが生成したレポートの評価:まずは、Nova Pro のレポートです。
良い点
大量のメールデータをまとめてLLMに読ませただけで、ある程度件数も把握できている点はすごいなと思いました。
悪い点
分析は「件数が増えた、減った」といった単純な定量的な分析に終始している。
トピック抽出も「スレッド I D : xxx で対応が⻑期化しています」のように抽象的すぎる。
実際にそのレポートを読んで、「結局なにが問題・課題なんだ？」思ってしまうぐらい、薄いレポートという印象でした。

 Claude Sonnet 4.5が生成したレポートの評価:良い点
定量的な分析はもちろんのこと、その内容を明確な表形式で分かりやすく整理してくれる。
さらに、「温度感⾼そうなトピック」として課題を特定している。
「以下のメールがその典型例です」といった形で、根拠となるメール本文を直接引用してくれる。
悪い点
ほぼない？
ときどき、ハルシネーションが発生する(Nova Proも同様)
上記の通り、実際に生成されたレポートをは、今何が一番重要な問題なのかをすぐに理解することができる内容になっていました。なおかつLLMのハルシネーションはほとんどなく、根拠となる実際のメールを引用してくれたりして、読み手にとって実際に業務改善につなげる洞察が得られるレポートになっていました。
あえて弱点を上げるとすると、文章を読んで理解する必要があるので、グラフが並べられたレポートのダッシュボードのようなもので、定量的な状況が一目ではわからない点があります。しかし、それは従来からある Opensearch や SQL による集計とグラフ描画ライブラリなどで対応すればいいので、さらにその先の分析として生成されたレポートは十分に機能していると思いました。

 最終決断： Claude Sonnet 4.5 を採用モデルの利用料金的には、Nova Pro がコスパが良さそうに思えていましたが、実際に利用してみたら、ユーザーに「価値」を提供できるのは、Claude Sonnet 4.5 だろうと思い、Claude Sonnet 4.5 を採用しました。
価値を提供できなければ、コストを頑張って節約したところであまり意味はないと思うので、使われる機能に仕上げるためには妥当な判断かと思いました。

 巨大データとの格闘：コンテキストウィンドウ対策LLMを選定し、いざ実装を進めようとしたとき、私たちは生成AIアプリケーション開発における共通の壁にぶつかりました。それが「コンテキストウィンドウの制約」です。

 コンテキストウィンドウとは？
https://platform.claude.com/docs/en/build-with-claude/context-windows
上記は、Claude のドキュメントからの引用ですが、コンテキストウィンドウとはLLMが一度に処理できる情報の量（トークン数）の上限のことです。数千件、数万件にも及ぶメールデータを一度にLLMへ入力することはできません。上限を超えるとエラーになってしまいます。1通あたりのメールの文量にもよりますが、Sonnet 4.5 の場合、だいたい3,000件~4,000件のメールで頭打ちでした。レポート対象によっては、数万件あり、実際にシステムで処理するとコンテキストが足りない旨のエラーがBedrockから返されることがありました。
この課題を解決するために「階層的要約戦略」を考案しました。

 階層的要約戦略

AIに処理の流れの全体像を説明する画像を生成させました。若干異次元の漢字が入っていますが、ご容赦を。
なにが階層なのかというと、メールデータ全体を、週ごとの要約と、月ごとの要約に分けて処理するというところが階層的になっています。上記のイメージでなんとなく理解頂けるといいのですが・・・簡単な説明を以下に記述します。

 ステップ1：週次要約フェーズまず、1ヶ月分のメールデータを1週間ごとに分割します。そして、1週間分のデータの中でも、さらにLLMが処理できるサイズに分割して処理を行います。
動的バッチ処理: 1週間分のメールデータを1件ずつバッファに溜めていきます。このとき、tiktoken ライブラリを使ってプログラム的にトークン数を見積もり、合計がコンテキストウィンドウ上限の80%に達した時点で、それを1つのバッチとしてLLMに投入し、要約させます。
文脈の維持: ここが重要な工夫です。2回目のバッチ処理を行う際には、前回のバッチで生成された要約結果を、新しいメールデータと一緒に入力します。 これを繰り返すことで、前のバッチの文脈を引き継ぎながら、週全体の情報を統合した「週次レポート」を生成します。

 ステップ2：月次要約フェーズ1ヶ月分（通常4〜5つ）の週次レポートがすべて生成されたら、次のフェーズに移ります。
最終統合: 生成された4〜5つの週次レポートをすべてインプットとして、再度LLMに投入します。
月次レポート完成: LLMは、週ごとのトレンドや出来事を統合し、月全体の傾向を分析した最終的な「月次レポート」を生成します。
すべてのメールを一度にLLMにわたすことはできませんが、週次要約にまとめて、それを5個くらいの量だったら、十分に現代のLLMならさばけるコンテキスト量になりました。
この階層的なアプローチによって、私たちはコンテキストウィンドウというLLMの制約を回避しつつ、膨大なデータから質の高いインサイトを抽出できるレポートの生成ができました。

 プロジェクトから得られた3つの学び今回の開発経験は、私たちに多くの実践的な教訓をもたらしました。今後のAI機能開発における指針ともなる、3つの重要な学びを共有します。

 学び1: モデル選定はコストだけでなく「ユーザー価値」で判断する。Nova ProとClaude Sonnet 4.5を比較してそれを実感しました。初期コストの安さに惹かれて安易な選択をしていたら、ユーザーにとって価値のない機能になっていたでしょう。表面的なスペックやコストだけでなく、実際に本番に近い形で動かしたうえでの性能を評価するのが大事ですね。

 学び2: シンプルさを優先する。Converse API を選んだ理由がここにあります。 Invoke-Model API のような多機能で複雑な選択肢もありましたが、私たちの「定型的な要約処理」という要件には、最もシンプルでメンテナンス性の高い技術が最適でした。常に「この要件を満たす最もシンプルな方法は何か？」と自問することが、持続可能なシステム開発につながります。

 学び3: 流行に流されず、本質を見極める。開発当時、 RAG（Retrieval-Augmented Generation） や AIエージェント といった技術が大きな注目を集めていました。私たちもBedrock Knowledge Base (RAG)などを検討しましたが、流行に飛びつくのではなく、自分たちの課題の本質を見極めました。今回の課題は、未知の情報に対するQ&Aではなく、「指定された期間の既知のメールデータを要約する」という確定的で定型的な処理です。そのため、ベクトル検索などの複雑な仕組みは不要だと判断し、シンプルな実装で目的を達成することができました。

 まとめこのプロジェクトを通じて、AIを活用することで、専門知識を必要とし、属人化していたレポート作成業務を自動化できることがわかりました。これは、ユーザーの工数を削減し、誰でもデータに基づいたインサイトを得られる環境を実現したという点で、大きな可能性があると考えています。
今回の開発で改めて実感したのは、生成AIの活用は、単にAPIを叩くだけでは完結しないということです。大量のデータをどう前処理するか、LLMの制約をどうアーキテクチャで回避するか、そしてどの技術・モデルが本当に価値を生むのか。AIがとてつもない速度で進化していますが、もうしばらくは、こういった泥臭い地道な検証とシステム設計のノウハウみたいなのが必要になっていくんだろうなと思いました。
AWS Bedrock を使いたい人、LLMを使ったシステム・アプリケーション実装を考えている人の参考になれば幸いです！

 🌺 沖縄から「21世紀を代表する会社」を創る仲間を募集シーエー・アドバンスは、「沖縄のインターネット産業の未来を創る」をビジョンに掲げ、サイバーエージェントグループの一員として、ABEMAやAmebaを支える社内システムを開発しています。 勤務地は沖縄・那覇市 おもろまち。 Next.js 、React、Ruby on Rails、AWS などモダンな技術で、東京・ベトナムのエンジニアと協業。若手が裁量権を持って挑戦できる環境です。
失敗を恐れず挑戦できる文化。一緒にアドバンス(進歩)しませんか?
https://hrmos.co/pages/ca-adv-group/jobs?category=1580771415836098560

AWS Bedrockを使った大規模メールデータ要約システムの開発話

この記事の概要

レポート作成の「見えないコスト」という課題

発想の転換：「レポート作成」は「文章要約」である

大量データを捌くためのシステムアーキテクチャ

非機能要件の定義

Dispatcher-Workerパターンの採用

インフラの実装

AI処理の心臓部：AWS Bedrock実装の技術選定・設計

SDKの比較: boto3 vs langchain

APIの比較: Converse API vs Invoke-Model API

Invoke-Model API の場合

Converse API の場合

LLM選定：コストパフォーマンスの罠と真の価値

初期評価

単純なテストでは Nova Pro で全く問題なしだが、、、

Nova Pro の場合

Claude Sonnet 4.5 の場合

現実世界での試練：出力結果の比較

Nova Proが生成したレポートの評価:

Claude Sonnet 4.5が生成したレポートの評価:

最終決断： Claude Sonnet 4.5 を採用

巨大データとの格闘：コンテキストウィンドウ対策

コンテキストウィンドウとは？

階層的要約戦略

ステップ1：週次要約フェーズ

ステップ2：月次要約フェーズ

プロジェクトから得られた3つの学び

学び1: モデル選定はコストだけでなく「ユーザー価値」で判断する。

学び2: シンプルさを優先する。

学び3: 流行に流されず、本質を見極める。

まとめ

🌺 沖縄から「21世紀を代表する会社」を創る仲間を募集

Discussion

項目	Converse API	Invoke-Model API
主な用途	テキスト会話・要約	テキスト・画像生成・埋め込み
インターフェース	全モデルで統一	モデルごとに異なるパラメータ
会話履歴	messages パラメータで簡単	自前で実装が必要
モデル変更	modelId 変更のみ	パラメータ構造も変更必要
このプロジェクト	最適	オーバースペック

モデル	入力	出力	選択理由・却下理由
Nova Micro	$0.042	$0.168	コストは最安だが品質不足
Nova Lite	$0.072	$0.288	バランス型だが要件に不足
GPT-4o-mini	$0.15	$0.60	既存システムでの採用実績あり
Nova Pro	$0.96	$3.84	✅採用候補: 品質・コスト・AWS
GPT-4o	$2.50	$10.00	品質は高いがコスト高, AWSエコシステムから逸脱
Claude 3.5	$3.00	$15.00	最高品質だがコスト高
Claude 4.5	$3.30	$16.50	✅採用候補: 最新・最高品質だがコスト最高

この記事の概要

レポート作成の「見えないコスト」という課題

発想の転換：「レポート作成」は「文章要約」である

大量データを捌くためのシステムアーキテクチャ

非機能要件の定義

Dispatcher-Workerパターンの採用

インフラの実装

AI処理の心臓部：AWS Bedrock実装の技術選定・設計

SDKの比較: boto3 vs langchain

APIの比較: Converse API vs Invoke-Model API

Invoke-Model API の場合

Converse API の場合

LLM選定：コストパフォーマンスの罠と真の価値

初期評価

単純なテストでは Nova Pro で全く問題なしだが、、、

Nova Pro の場合

Claude Sonnet 4.5 の場合

現実世界での試練： 出力結果の比較

Nova Proが生成したレポートの評価:

Claude Sonnet 4.5が生成したレポートの評価:

最終決断： Claude Sonnet 4.5 を採用

巨大データとの格闘：コンテキストウィンドウ対策

コンテキストウィンドウとは？

階層的要約戦略

ステップ1：週次要約フェーズ

ステップ2：月次要約フェーズ

プロジェクトから得られた3つの学び

学び1: モデル選定はコストだけでなく「ユーザー価値」で判断する。

学び2: シンプルさを優先する。

学び3: 流行に流されず、本質を見極める。

まとめ

🌺 沖縄から「21世紀を代表する会社」を創る仲間を募集

Discussion

現実世界での試練：出力結果の比較