新米エンジニアが「Amazon Bedrockで何ができるの？」を試してみた ～メール自動処理で学ぶ、バックエンドでのAI活用術～

私は新米エンジニアとして、AWSをメインで扱うチームで日々奮闘しています。
普段、ChatGPTと人生について語り合うほどAI好きな私ですが、ふと「AWSのAIをもっと業務に活かせないだろうか…」と思い立ち、AWSのAIサービスであるAmazon Bedrockの検証にチャレンジしてみました。

本記事では「問い合わせメールの確認」を題材に、Amazon Bedrockをバックエンドに組み込んだシステム構築について検証を通じて紹介します。不定形なテキストをAIに判断させるこのアーキテクチャを通じて、皆様の自社の業務課題を解決するヒントになれば幸いです。

Amazon Bedrockは、AWSが提供するフルマネージド型の生成AIサービスです。
Anthropic社のClaude、Meta社のLlama、Amazon独自のTitanなどをはじめとする複数の基盤モデルを、サーバーのインフラ管理を意識することなく、API経由で自社のシステムへ簡単に組み込めるのが最大の特徴です。

近年、お客様から「AWSの生成AIサービスとしてAmazon Bedrockの名前をよく聞くが、具体的な活用方法が分からない」というご相談をよくいただきます。生成AIと聞くと「ChatGPT」「Gemini」といった対話型のイメージが先行しがちで、その他の活用方法がイメージできない方も多いと思います。

しかし、「対話」以外にも、日々発生する情報の「判断」「分類」「抽出」といった定型作業にも生成AIは大いに活用でき、もっと業務を効率化することができます。

Amazon Bedrockは、アプリケーションやシステムに組み込むことで、業務効率化に活かすことができます。今回はその一例として、イメージしやすい「問い合わせメールの自動分類」を題材に、具体的な実装手順を見ていきます。その前に、なぜこのタスクにAmazon Bedrockが適しているのかを、3つのポイントで説明します。

たとえば、サポート宛に届く「ログインできない」というメール。

• A社「ログインできないんだけど、どうすればいい？」
• B社「至急！ログインできなくて業務が止まっています。即座に対応してください」

従来のルールベースのキーワードマッチでは、どちらも「ログイン」というカテゴリに振り分けられますが、後者が持つ「緊急性」や「温度感」までは判定することが困難でした。それ以外にも、サポート宛には多種多様な問い合わせメールが来て、緊急度の判別には人手による確認が必要なケースが多いという現実がありました。

このように「不定形テキストの意図や文脈を汲み取る」作業は、生成AIの得意分野の1つです。急ぎで回答を求められるチャットボットとは異なる「非同期処理」では、即時性の制約が比較的小さいため、AIを活用した柔軟な判定ロジックを組み込みやすくなります。

AWSには、Amazon Bedrock以外のAIサービスに「Amazon Comprehend」という自然言語処理サービスがあります。一見「Amazon Comprehend」の方がメール処理に特化したサービスに見えますが、独自の業務要件に合わせてAmazon Comprehendの『カスタム分類機能』を用いる場合は、事前に数百〜数千件の「学習データ」を用意し、モデルをトレーニングする必要があります。

一方、Amazon Bedrockは「学習データがゼロ」の状態でも、プロンプトで指示を与えるだけで即座に高精度な分類を開始できます。
「まずは1件のメールから試したい」「運用しながら分類項目を柔軟に変更したい」といったスモールスタートのフェーズにおいては、プロンプト一つで挙動を変えられるAmazon Bedrockが最適な選択肢となります。

AIの強みは「理解」だけではありません。人間が書いた「バラバラな文章」を、コンピューターが処理しやすい「構造化されたデータ（JSON形式）」に変換できる点も非常に重要です。

この「構造化」ができるおかげで、AIが判断した結果をそのままプログラムで処理可能になります。「特定のチャットサービスへ通知する」「APIを介して台帳へ自動追記する」といった、システム間の連携が極めてスムーズになります。

以下が、本システムの挙動と構成図になります。

1. ①メールの受信

   テスト用メールファイルをAmazon S3バケットへ配置します。

2. ②イベント発火

   Amazon S3の「オブジェクト作成」をトリガーに、AWS Lambdaが自動起動します。

3. ③データ取得

   AWS LambdaがAmazon S3から該当のメールファイルを取り出し、中身を読み取ります。

4. ④AI解析リクエスト

   AWS LambdaがAmazon Bedrockに対し、解析用プロンプトとメール内容を渡します。

5. ⑤AI要約

   AIがメール文脈を読み取り、指定されたJSON形式に要約・分類します。

6. ⑥チャット通知

   解析結果をGoogle ChatのWebhookを利用して特定のスペースへ送信します。

以下が、AWS Lambda関数内に記述したAmazon Bedrockへの入力値（プロンプト）になります。
※本検証では、Amazon Bedrockの基盤モデルとして「Claude 3 Haiku」を採用しています。

今回の検証では、AIの「文脈理解」という真価を発揮するために、一度見ただけでは内容が読み取れない文章をテストメールとして用意しました。

お客様の佐藤様は「あ、今日はお忙しければ、お返事は週明けでも大丈夫ですよ。」とおっしゃっていますが、土日にセキュリティリスクに晒し続けるのはあまりにも危険です。AIは潜在的な危険性に気づいて、緊急要件であることを通知できるのでしょうか。

今回の検証を通じて、最も驚いたのは「実装の工数」と「出力の質」のバランスです。

環境構築からコードの実装、デバッグを含めても1時間足らずでこのバックエンドを完成させることができました。
「生成AIを使ったシステム」と聞くと特別な専門知識が必要に思えるかもしれませんが、アーキテクチャの大部分はAmazon S3やAWS LambdaといったAWSの基本サービスの連携です。普段からAWSを触っているエンジニアであれば、既存の知識の延長線上でAmazon BedrockのAPIを呼び出すだけで、高度な判断を伴うAIシステムが完成してしまう手軽さに驚くはずです。

また、プロンプトが「複雑な条件分岐（If文）の代わりになる」というのも非常に面白い体験でした。
通常であれば「この単語が含まれていたらA」と泥臭く正規表現やロジックを記述する部分を、Amazon Bedrockへの自然言語による指示（プロンプト）に任せることができます。これにより、AWS Lambda側のコード記述量を大幅に減らし、シンプルに実装することができました。

今回の検証では、あえて「世間話の中に重大なインシデントが紛れ込み、かつ文末で顧客が遠慮している」という意地悪なメールとしました。すると初期のプロンプトでは、AIは「他社の機密データが見えている」という事実を認識していながらも、文末の「お返事は週明けでも大丈夫ですよ」という顧客の遠慮（ノイズ）を真正面から受け止めてしまい、優先度を「中」と誤判定してしまったのです。

「本来、AIの判断精度を向上させるためには、モデルの再学習（ファインチューニング）や高度なパラメータ調整といった、データサイエンティストのような専門知識が求められる場面がありました。しかし、Amazon Bedrockでは、プロンプト設計やAPI経由での利用を通じて、生成AIを業務に取り入れやすいのが特長です。

実際、プロンプトに「顧客が文末で遠慮していても、リスクがあれば無視して緊急と判定せよ」という絶対的な優先順位を追加するだけで、即座にAIはノイズを切り捨てて「緊急」を見抜く番人へと進化しました。

「ソースコードを一行も書き換えず、専門的な学習プロセスも踏まず、ただ日本語の指示を変えるだけでシステムの挙動を劇的に修正できる」。この試行錯誤の圧倒的なスピード感こそ、Amazon Bedrockを実務に採用する最大の強みだと感じました。

今回一番の収穫は、AIを単なる「要約ツール」ではなく、「非定型データを、システムが扱える『構造化データ（JSON）』に変換する翻訳機」として捉えた時の可能性です。

人間が書くメールは自由すぎて、本来はプログラムで扱うのが最も難しいデータです。
しかし、Amazon Bedrockを介して「カテゴリ」や「優先度」を綺麗なJSON形式で抽出できるようになると、話は一気に変わります。

• 「AIが判断した結果」を、そのまま業務システムへ受け渡す
• 「特定の条件（緊急度：高）」の時だけ、別の自動化システムを起動させる

このように、LLMが「人間の言葉」と「システムの論理」を繋ぐハブになることで、これまで「人間にしか判断できない」と諦めていた多くの業務を自動化できる手応えを感じました。

今回ご紹介した「イベント発生 → AWS Lambdaで取得 → Amazon Bedrockで処理」という非同期連携のアーキテクチャは、一つの「型」として非常に高い汎用性を持っています。

入力元（トリガー）となるイベントと、Amazon Bedrockに渡すプロンプトの指示内容を変えるだけで、さまざまな業務課題に応用することが可能です。本セクションでは、弊社内で実際に活用している事例をご紹介します。

AWS環境のセキュリティ監視では、Amazon GuardDuty、AWS Config、IAM Access Analyzer など複数のサービスを利用しますが、従来は「通知が各管理アカウントからバラバラに届く」「専門的な内容で調査に時間がかかる」「どの環境（本番・開発）のアラートか判別しにくい」といった課題がありました。

各サービスから届くアラートをイベントとして集約し、発生の都度、Amazon Bedrockへ内容を投入。単なる翻訳ではなく、「発生時刻」「対象サービス」「環境名/ID」「リージョン」といったメタデータを整理した上で、Amazon Bedrockに以下の2点を生成させています。

• Amazon Bedrockによるアドバイス:「なぜこのアラートが出たのか」の分かりやすい解説
• 推奨される調査方針/対策:具体的な作業手順の提案

専門知識が必要なアラートが、即座に「意味」と「ネクストアクション」を伴う通知に変換されます。通知元がチャットスペースに集約されたことで、メールに埋もれて対応漏れが発生するリスクも激減しました。

本記事では、Amazon Bedrockをバックエンドに組み込んだ「非同期な自動化」の検証を通じて、以下3点のメリットを実感することができました。

• 1.「行間を読む」文脈理解力：文脈を深く汲み取った、柔軟な分類が可能。
• 2.「学習いらず」の即戦力：大量のデータ準備が不要で、すぐに実務に投入できる。
• 3.「システムへ繋ぐ」構造化能力：不定形のデータを指定したフォーマットに変換し、後続のシステムへ橋渡しできる。

今回の検証を通じて、「日本語のプロンプトが、そのまま複雑な条件分岐（If文）の代わりになる」という開発体験には、私自身も大きな可能性を感じました。たとえ初期の回答精度が低くても、コードを書き換えずに日本語で即座にチューニングできるスピード感は、まさにAmazon Bedrockならではの強みです。

「生成AIをチャットの相手としてではなく、システムの『パーツ』として組み込む」

この視点を持つだけで、これまで人間にしかできなかった「ルールベースでは限界がある業務判断」を自動化の領域へと広げることができます。

生成AIの導入に、最初から100%の完璧さを求める必要はありません。まずはスモールスタートで導入し、あなたの身近な業務を「ちょっとだけ」アップデートしてみませんか？