【AWSフルマネージド】AI Agent × RAG × MCP 構築実践ログ

1. はじめに

現在、生成AI開発のトレンドは「単なるチャットボット」から、自律的に外部ツールを使いこなす「AI Agent」へとシフトしています。特に注目されているのが、AIが外部データや機能に接続するための標準規格 「Model Context Protocol (MCP)」 と、社内データを検索して回答精度を高める 「RAG (Retrieval-Augmented Generation)」 の組み合わせです。

今回は、これらをAWSのフルマネージドサービスだけで構築してみました。具体的には、医療ガイドラインのFAQを検索し、正確に回答してくれるAIエージェントを作成します。

本記事では、実際の画面キャプチャを交えながら、構築の流れと動作の仕組みを初心者の方にもわかりやすく解説します。

2. アーキテクチャと使用ツール

今回の実践で使用した構成は以下の通りです。すべてAWS上で完結します。

  • AI Agent: Amazon Bedrock AgentCore (Agentの頭脳)

  • RAG (知識源): Amazon Bedrock Knowledge Bases + Amazon S3 Vector Bucket

  • MCP Server (ツール): AWS Lambda (AgentCore Gateway経由で接続)

  • クライアント: Python (boto3) 製コマンドラインツール

これまでのAWS社主催のワークショップで学んだ要素技術（Strands, AgentCore, RAG）を統合した実践的な構成です。

3. RAG (ナレッジベース) の構築

まずは、AIが参照するための「知識（ナレッジベース）」を作ります。今回は安価で管理が容易な構成を採用しました。

3-1. 保存先：S3 ベクトルバケット

データの保存先には、Amazon S3の新機能「ベクトルバケット」を使用しました。

従来は専用のベクトルデータベースを構築する必要がありましたが、S3だけでベクトルデータの保存・管理が可能になり、非常に手軽かつ安価になりました。

ナレッジベースの設定画面です。ベクトルデータベースとして「Amazon S3 Vectors」を選択しています。

 


【図1: Bedrockナレッジベース設定画面】

 

S3コンソール画面です。「ベクトルバケット」という新しいタイプのバケットが作成されたことがわかります。

 

 

【図2: S3ベクトルバケット画面】

3-2. データ準備：PDFのテキスト化とチャンキング

今回使用するデータは「医療情報システムの安全管理に関するガイドライン」のFAQデータです。

RAGの精度を上げるための重要な工夫として、PDFをそのまま読み込ませるのではなく、手動でテキスト化を行いました。

PDFの内容をテキストに起こしたものです。表や画像が含まれる複雑な資料の場合、自動パーサー任せにすると読み取り精度が落ちるため、このように整形してあげることでAIの回答精度が格段に上がります。

 

【図3: VS Codeでのテキスト編集画面1】

 

文末や章の区切りを意識してデータを整形しています。

 

 

【図4: VS Codeでのテキスト編集画面2 (スクロール後)】

3-3. 動作確認 (RAG単体テスト)

ナレッジベースができたら、正しく検索できるかテストします。

「糖尿病の治療ガイドラインについて教えてください」と質問してみます。

 

【図5: Bedrockコンソールでのテスト画面】

 

回答の根拠となった「ソースチャンク（参照元データ）」が表示されます。スコア付きで関連性の高い文章が取得できていることがわかります。

 

 

【図6: ソースチャンクの確認画面1】

 

複数の関連情報が正しくヒットしています。

 

 【図7: ソースチャンクの確認画面2】

 

データの追加・削除も試してみました。ファイルを更新して同期すると、即座に検索結果に反映されることが確認できました。

データの追加・削除の同期履歴です。即時反映されており、運用もスムーズに行えます。

 

 【図8: 同期履歴画面】

 

AWSのAdvanced RAGセミナー等のレポートによると、通常のRAGでは60%程度の精度でも、適切なチューニングを行うことで80-90%まで改善できるとされています。今後は「RAGUS」などの評価ツールを用いて、定量的な精度評価も実施していく予定です。

今回のチューニングとしては、文章をAIが読み込めるサイズに分割する「チャンキング」手法に、セマンティックチャンキングを採用しました。

これは、文字数で機械的に区切るのではなく、文章の意味や文脈（文末など）をAIが判断して区切る手法です。これにより、検索時に「文章が途中で切れていることで正しくヒットしない」という失敗を防げます。

その他にも、リランキング、クエリ書き換えなどの様々なチューニング手法があります。今後、RAGUSでRAGの品質評価の基盤を構築した後に、本格的なチューニングに着手しようと考えております。

4. MCP Server (Lambda) の実装

次に、このナレッジベースをAI Agentから使えるようにする「つなぎ役」として、AWS Lambdaを用意します。これをMCP (Model Context Protocol) サーバーとして機能させます。

4-1. Lambda関数の作成

PythonでLambda関数を作成し、Bedrock Knowledge Baseに問い合わせる処理（retrieve_and_generate API）を記述します。

作成したLambda関数「agentcore-medical-guidline-faq-search-tools」です。

 

 

【図9: Lambda関数概要画面】

 

RAGへ問い合わせを行う核心部分のコードです。RAGのベクトルデータベースを指定します。検索結果を元に回答を生成するためのLLMも指定します。ここで同時にGuardrailが適用できることにも注目してください。

 

 【図10: Lambdaコード画面1】

 

今回はRAGの検索結果に対してコンプライアンスチェックを行い不適切な回答がユーザに返されることを防ぐために、Guardrailの適用を行いました。Guardrailには禁止トピックと禁止ワードを指定し、問い合わせが禁止事項に抵触する場合に検索結果を返す代わりに予め指定したエラーメッセージが返信されるかをテストしました。

4-2. Agentからの呼び出しに対応させる

AgentがこのLambdaを適切な「ツール」として認識・実行できるように、リクエストパラメータからツール名を判定するロジックを以下のように追加します。

 

【図11: Lambdaコード画面2 (ツール名判定処理)】

 

AgentCore Gateway経由で渡される情報から、どのツール（機能）を実行すべきかを判断する処理を追記しています。

4-3. スキーマ定義

MCP ServerとしてAgentから呼び出されるためには、「このツールはどんな機能で、どんな入力を必要とするか」をMCP Clientに教えるためのスキーマ（説明書）を定義します。

 

【図12: AgentCoreスキーマ定義画面】

 

「検索内容(text)」を受け取って「医療ガイドラインFAQ検索」を行うツールである、という定義をJSON形式で記述しています。先ほどのlambdaで実装したソースコードのインタフェース情報を記述したものです。現状ではこの内容をソースコードとは独立して別途、手動で記述して登録しました。 今後は、Web APIにおけるSwagger (OpenAPI) のように、ソースコードとスキーマを同期を取って自動生成したりするのがスタンダードになると予想されます。

5. Agentの動作検証と可視化

ここが最も面白い部分です。構築したAgentが、実際にどのように考えて動いているのかをAWSの管理画面（CloudWatch / GenAI Observability）で見てみましょう。AWSではObservabilityというキーワードで呼ばれる運用で非常に重要となる分野です。

5-1. 思考の軌跡 (Trajectory)

ユーザーが「糖尿病の治療ガイドラインについて教えてください」と質問した時の、Agentの思考ログです。

左から右へ、処理の流れが可視化されています。問い合わせに応じて、Agentが自律的に適切なツールを選択し動いている様子がわかります。

 

【図13: CloudWatch Trajectory画面】

5-2. ツール呼び出しとパラメータ生成

以下は、MCP ClientであるAgentプログラムがRAG検索機能を持つMCP Serverのツールを呼び出した瞬間のログです。

 

【図14: ツール呼び出し詳細画面】

 

MCP Serverのスキーマ情報に合わせて、text パラメータに「糖尿病の治療ガイドラインについて検索いたします。」という検索クエリを、MCP ClientのAgent自身が考えて生成し、入力していることが確認できます。

5-3. 試行錯誤のプロセス

MCP Serverとして実装されたRAG検索ツールから返ってきた検索結果です。

 

【図15: RAGからの返答画面】

一度の検索で終わらず、得られた情報を元に「これで十分か？」「もっと調べることはないか？」とAgentが自律的に判断し、必要に応じて複数回問い合わせを行っています。

 

【図16: Agentの再考画面1】

 

【図17: Agentの再考画面2】

 

 【図18: Agentの再考画面3】

 

5-4. 最終回答の生成

調査が完了し、ユーザーへの最終回答を生成しています。策定機関や治療目標（HbA1c 7.0%未満など）といった具体的な根拠を引用して回答を作成しています。

 

 【図19: 最終回答ログ画面】

 

今後は、回答品質の評価のためにRAGUSなどのツールを利用して、定量的に評価したいと考えております。

6. クライアントアプリからの利用

最後に、このAgentをPythonのコマンドラインツールから利用してみます。

 

【図20: ターミナルでの実行画面】

 

You: 糖尿病の治療ガイドラインについて教えてください

Bot: (RAGで検索した結果を元に回答)

ターミナル上で、先ほどのAgentが期待通りに動作していることが確認できました。Webアプリ化も可能ですが、エンジニアの実務用ツールとしては、このようにエディタやターミナルで完結するCUIツールも非常に便利です。

このチャットbotは、ブラウザ上のChatGPTで簡易に作成しました。今回はテンポラリな検証環境上に構築されたvscodeサーバーをエディタとして使用したこともあってGitHub CopilotやAmazon Qなどの拡張機能は導入しませんでした。本格的な開発の際にはこれらの開発支援ツールを導入する方が良いと思います。

7. まとめ

AWSのフルマネージドサービス（Bedrock, S3, Lambda）を組み合わせることで、以下の特徴を持つ高度なAI Agentを構築できました。

  • 高精度: 手動テキスト化とセマンティックチャンキングによるRAG品質の向上

  • 低コスト: S3 Vector Bucketによる安価な運用

  • 透明性: CloudWatchによる思考プロセスの完全な可視化

  • コンプライアンス: Guardrailの適用による禁止トピックや禁止ワードの適用

特に、Agentがどのようにツールを使い、どう考えて答えを出したのかが「見える」こと(AWSではObservabilityというキーワードがよく使われますので覚えておくと良いでしょう。)（XAI: 説明可能なAI）は、実運用において非常に重要です。ぜひ皆さんも試してみてください。

8. 参考文献・リンク

RAGデータソース

本ハンズオンのRAG構築には、厚生労働省が公開している以下のガイドラインおよびQ&Aを利用しました。

  • 医療情報システムの安全管理に関するガイドライン 第6.0版（令和5年5月）

  • 医療情報システムの安全管理に関するガイドライン第6.0版 Q&A（令和７年５月）

実装の参考にしたAWSワークショップ

実装にあたり、以下のAWS公式ワークショップを参考にしました。

  • 実践力を鍛えるBootcamp - クラウドネイティブ編 -

  • Amazon Bedrock AgentCore ワークショップ

 

注意事項

本記事に掲載しているスクリーンショットは、検証目的で構築した一時的な環境を使用したものです。表示されているリソースやユーザは全て検証時点のものであり、現在は当該環境を削除済みです。したがって、表示されているリソースやユーザは現在は存在しておりません。

 

以上