はじめに
こんばんは、mirukyです。
Amazon Bedrock シリーズ第4回です。
前回（#3）では、Knowledge Bases（RAG）を使って社内データに基づくAIチャットを構築しました。
今回は、Bedrock Agentsを使って、ナレッジベース検索だけでなく外部APIやLambda関数を自律的に呼び出すAIエージェントを構築します。
Bedrock Agentsの核心は、AIが「今どのツールを使うべきか」を自律的に判断することにあります。ユーザーの質問を受けると、エージェントは「ナレッジベースを検索すべきか」「Lambda経由でAPIを呼び出すべきか」「追加の質問をすべきか」を自ら判断し、複数ステップの処理を自動で組み立てて実行します。
出典：AI エージェントを使用してアプリケーションのタスクを自動化する - Amazon Bedrock - AWS
目次
- Bedrock Agentsの仕組み
- 今回のシステム構成
- Lambda関数の作成（アクショングループの実体）
- エージェントの作成
- アクショングループの設定
- ナレッジベースの紐付け
- テストと動作確認
- 料金について
- おわりに
1. Bedrock Agentsの仕組み
1-1. エージェントの処理フロー
1-2. 主要コンポーネント
| コンポーネント | 役割 |
|---|---|
| エージェント | LLMが全体の判断・制御を担う。どのツールを使うか自律的に決定 |
| アクショングループ | エージェントが利用できるツール群。OpenAPIスキーマで定義し、Lambda関数で実装 |
| ナレッジベース | エージェントに紐付けたRAGデータソース（#3で作成済み） |
アクショングループとは
エージェントに「できること」を教えるための仕組みです。例えば「注文情報を取得する」「天気を調べる」といった具体的なアクションをOpenAPIスキーマで定義し、その実体処理をLambda関数で実装します。エージェントはユーザーの質問内容に応じて、必要なアクショングループを自動的に選択・実行します。
2. 今回のシステム構成
今回は、#3で作成したナレッジベースに加えて、注文情報を検索するLambda関数をアクショングループとして追加します。これにより、FAQへの回答と注文情報の検索を1つのエージェントで対応できるようになります。
3. Lambda関数の作成（アクショングループの実体）
3-1. Lambda関数の作成
- AWSマネジメントコンソール（東京リージョン）で Lambda を開く
- 「関数の作成」 → 「一から作成」
| 設定項目 | 値 |
|---|---|
| 関数名 | bedrock-agent-order-lookup |
| ランタイム | Python 3.14 |
| アーキテクチャ | x86_64 |
3-2. Lambda関数のコード
import json
# サンプルの注文データ（本番ではDynamoDB等から取得）
ORDERS = {
"ORD-001": {
"orderId": "ORD-001",
"customerName": "田中太郎",
"product": "ワイヤレスイヤホン",
"status": "配送中",
"estimatedDelivery": "2026年3月5日"
},
"ORD-002": {
"orderId": "ORD-002",
"customerName": "佐藤花子",
"product": "モバイルバッテリー",
"status": "出荷準備中",
"estimatedDelivery": "2026年3月7日"
}
}
def lambda_handler(event, context):
action = event.get("actionGroup", "")
api_path = event.get("apiPath", "")
http_method = event.get("httpMethod", "")
parameters = event.get("parameters", [])
if api_path == "/orders/{orderId}" and http_method == "GET":
order_id = next(
(p["value"] for p in parameters if p["name"] == "orderId"),
None
)
if order_id and order_id in ORDERS:
response_body = ORDERS[order_id]
else:
response_body = {"error": f"注文番号 {order_id} は見つかりませんでした。"}
else:
response_body = {"error": "サポートされていないAPIパスです。"}
return {
"messageVersion": "1.0",
"response": {
"actionGroup": action,
"apiPath": api_path,
"httpMethod": http_method,
"httpStatusCode": 200,
"responseBody": {
"application/json": {
"body": json.dumps(response_body, ensure_ascii=False)
}
}
}
}
レスポンス形式はBedrock Agentsの仕様に従う必要があります
messageVersion、responseの構造は固定フォーマットです。この形式に従わないと、エージェントがLambdaの応答を正しく解釈できません。
3-3. リソースベースポリシーの設定
エージェントからLambda関数を呼び出すには、Lambda側にBedrockからの呼び出しを許可するリソースベースポリシーを追加する必要があります。
エージェント作成後に設定してください
リソースベースポリシーにはエージェントのARNが必要です。セクション4でエージェントを作成した後、この手順に戻って設定してください。
- AWSマネジメントコンソールで Lambda を開く
-
bedrock-agent-order-lookup関数を開く - 「設定」 タブ → 「アクセス権限」 を選択
- 「リソースベースのポリシーステートメント」セクションで 「アクセス権限を追加」 をクリック
- ポリシーステートメントを編集で 「AWS のサービス」 を選択
- 以下を入力（アカウントIDやエージェントIDはご自身のものに変更してください）
| 設定項目 | 値 |
|---|---|
| サービス | Other |
| ステートメント ID | AllowBedrockAgentInvocation |
| プリンシパル | bedrock.amazonaws.com |
| ソース ARN | arn:aws:bedrock:ap-northeast-1:{account-id}:agent/{agent-id} |
| アクション | lambda:InvokeFunction |
7.「保存」 をクリック
なぜインラインポリシーではなくリソースベースポリシーなのか
Bedrock Agentsは bedrock.amazonaws.com というAWSサービスとしてLambdaを呼び出します。
AWSサービスからの呼び出しを許可するには、呼び出される側（Lambda関数）に
リソースベースポリシーを設定する必要があります。
エージェントのIAMロールにインラインポリシーを追加する方式では許可できません。
4. エージェントの作成
4-1. エージェント作成画面を開く
- AWSマネジメントコンソール（東京リージョン）で Amazon Bedrock を開く
- 左メニューの 「エージェント」 を選択
- 「エージェントを作成」 をクリック
4-2. 基本設定
| 設定項目 | 値 |
|---|---|
| エージェント名 | customer-support-agent |
| マルチエージェントコラボレーション | 無効 |
作成をクリックします。エージェントビルダー画面が表示されますので、下記の通り設定します。
| 設定項目 | 値 |
|---|---|
| 生成モデル | Claude 3 Haiku |
| エージェントの指示 | 以下を入力 |
あなたは親切で丁寧なカスタマーサポートのAIアシスタントです。
以下のルールに従ってください：
1. 必ず日本語で回答してください。
2. 顧客からの質問には、ナレッジベースの情報を優先して正確に回答してください。
3. 注文情報の問合せには、注文検索ツールを使用してください。
4. ナレッジベースにもツールにも回答がない場合は、正直に「お答えできません」と伝えてください。
5. 推測や創作は行わないでください。
6. 回答は簡潔かつ丁寧にしてください。
4-3. 保存
「保存」 をクリックしてエージェントを作成します。
5. アクショングループの設定
5-1. アクショングループの追加
エージェントビルダーの画面で、「アクショングループ」 セクションの 「追加」 をクリックします。下記の通り設定します。
| 設定項目 | 値 |
|---|---|
| アクショングループ名 | order-lookup |
| 説明 | 注文番号をもとに注文情報を検索します |
| アクショングループタイプ | APIスキーマで定義 |
| Lambda関数 |
bedrock-agent-order-lookup（先ほど作成した関数） |
| アクショングループスキーマ | インラインスキーマエディタで定義 |
5-2. OpenAPIスキーマの定義
アクショングループスキーマ部分にあるエディタに、以下を入力します。
openapi: "3.0.0"
info:
title: "Order Lookup API"
version: "1.0.0"
description: "注文情報を検索するAPI"
paths:
/orders/{orderId}:
get:
summary: "注文情報の取得"
description: "注文番号を指定して注文情報（商品名、ステータス、配送予定日）を取得します"
operationId: "getOrder"
parameters:
- name: orderId
in: path
required: true
description: "注文番号（例：ORD-001）"
schema:
type: string
responses:
"200":
description: "注文情報"
content:
application/json:
schema:
type: object
properties:
orderId:
type: string
customerName:
type: string
product:
type: string
status:
type: string
estimatedDelivery:
type: string
OpenAPIスキーマの重要性
OpenAPIスキーマのdescriptionフィールドは、エージェントが「このツールをいつ使うべきか」を判断する材料になります。説明が曖昧だと、エージェントがツールを正しく選択できません。何をするツールで、どんな時に使うべきかを具体的に記述することが精度向上の鍵です。
5-3. 保存と準備
- アクショングループ画面で、「作成」 をクリック
- エージェントビルダー画面に戻るので、 「保存」 をクリック
- 保存の左側にある 「準備」 をクリック（エージェントのデプロイ準備）
6. ナレッジベースの紐付け
6-1. ナレッジベースの追加
エージェントの編集画面で、「ナレッジベース」 セクションの 「追加」 をクリックします。
| 設定項目 | 値 |
|---|---|
| ナレッジベース |
company-faq-kb（#3で作成済み） |
| 説明 | 当社のFAQ情報です。営業時間、返品、送料、支払い方法などの質問に回答できます。 |
ナレッジベースの説明も精度に影響します
エージェントは、ナレッジベースの説明文をもとに「この質問にはナレッジベースを検索すべきか」を判断します。どのような情報が含まれているかを具体的に記述してください。
6-2. 保存と再準備
- 「保存」 をクリック
- 再度 「準備」 をクリック
7. テストと動作確認
7-1. 「Access denied」エラーが出る場合に備えて
テスト実行時に以下のエラーが表示される場合があります。
Access denied when calling Bedrock. Check your request permissions and retry the request.
原因：クロスリージョン推論プロファイルのモデルを選択している
エージェントの生成モデルに 「APAC Anthropic Claude 3.5 Sonnet v2」などのクロスリージョン推論プロファイル を選択すると、このエラーが発生します。2026年3月時点では、Bedrock Agentsのオーケストレーション用モデルとしてクロスリージョン推論プロファイルが正しく動作しないケースが確認されています。
解決手順
- エージェントの編集画面を開く
- 生成モデルを、東京リージョンで直接利用可能なモデルに変更する
- 「保存」 → 「準備」 をクリックしてからテストを再実行
東京リージョンで利用可能なモデルの例
| モデル | 特徴 |
|---|---|
| Anthropic Claude 3 Haiku（本記事で使用） | 高速・低コスト。エージェントの検証に最適 |
| Anthropic Claude 3 Sonnet | Haikuより高精度。バランス型 |
| Amazon Nova Pro | AWS純正モデル。日本語対応 |
「APAC」「JP」が付いたモデルに注意
モデル選択画面で「APAC Anthropic Claude...」や「JP Anthropic Claude...」と表示されるモデルはクロスリージョン推論プロファイルです。エージェントの生成モデルには、これらのプレフィックスが付いていないモデルを選択してください。
7-2. テスト画面を開く
エージェントの詳細画面で 「テストエージェント」 パネルを開きます。
7-3. テスト①：FAQ系の質問
入力: 返品はできますか？
エージェントはナレッジベースを検索し、FAQに基づいた回答を返します。
7-4. テスト②：注文情報の問合せ
入力: 注文番号ORD-001の配送状況を教えてください。
エージェントはアクショングループ（Lambda）を呼び出し、注文情報を取得して回答します。
7-5. テスト③：複合的な質問
入力: ORD-002のキャンセルはできますか？
エージェントは以下のように判断し、複数のツールを組み合わせます。
- まず注文検索（Lambda）でORD-002の状況を確認 → 「出荷準備中」
- 次にナレッジベースでキャンセルポリシーを検索
- 両方の情報を統合して回答
7-6. トレース機能でエージェントの思考過程を確認する
テスト画面でプロンプトを実行すると、回答の下に トレース（オーケストレーショントレース） が表示されます。これにより、エージェントがどのような思考の流れで回答に至ったかをステップごとに確認できます。
トレースで確認できること
| トレースステップ | 内容 |
|---|---|
| 入力解析 | ユーザーの質問をエージェントがどう解釈したか |
| ツール選択の判断 | ナレッジベース検索 or Lambda呼び出し or 直接回答のどれを選んだか |
| ナレッジベース検索結果 | 検索されたチャンクの内容と、それがどのように要約されたか |
| Lambda呼び出し結果 | アクショングループに渡されたパラメータと、返却された結果 |
| 回答生成 | 取得した情報をもとに、最終回答がどのように構成されたか |
トレース機能はデバッグの必須ツールです
エージェントが期待通りに動かない場合、トレースを確認することで原因を特定できます。
-
ツールが選択されない → OpenAPIスキーマやナレッジベースの
descriptionが曖昧な可能性 - 間違ったツールが選択される → エージェントの指示（Instructions）を見直す
- ナレッジベースの検索結果が不十分 → チャンク戦略やドキュメントの内容を見直す
テスト③のような複合的な質問では、エージェントが自ら「どのツールを、どの順序で使うか」を判断します。これがBedrock Agentsの最大の特徴であり、単純なRAGとの大きな違いです。
8. 料金について
| サービス | 料金 | 備考 |
|---|---|---|
| Bedrock Agents | トークン課金（生成モデルの利用料金） | エージェントの推論ステップごとにLLMが呼び出される |
| Lambda | リクエスト数 + 実行時間課金 | 無料利用枠あり |
| Knowledge Bases | #3と同様 | 検索 + 埋め込み + ストレージ |
エージェントは複数回LLMを呼び出します
エージェントは1回のユーザー入力に対して、判断・ツール呼び出し・回答生成で複数回のLLM推論を行います。そのため、単純なConverse API呼び出しと比べてトークン消費量が多くなります。コスト見積もりの際は余裕を持たせてください。
最新の料金は公式ページをご確認ください。
出典：Amazon Bedrock Pricing - AWS
9. おわりに
ここまでお読みいただきありがとうございます。
今回は、Bedrock Agentsを使って、ナレッジベース検索とLambda関数呼び出しを自律的に判断・実行するAIエージェントを構築しました。
次回#5では、Guardrailsを使って、生成AIの安全性を担保するガードレール設計を行います。
ではまた、お会いしましょう。
参考リンク
Amazon Bedrock Agents 公式ドキュメント
- AI エージェントを使用してアプリケーションのタスクを自動化する - Amazon Bedrock - AWS
- アクショングループを使用して、エージェントが実行するアクションを定義する - AWS
- Amazon Bedrock Pricing - AWS