この記事をシェア
AIエージェントを自前で組むと、モデルへの指示、ツール呼び出し、会話状態、検索、権限、監査ログを一つずつ設計する必要があります。Amazon Bedrock Agentsは、これらをAWSのマネージドサービスとして組み合わせ、業務システムに接続できる形へ整理するサービスです。
本稿では、問い合わせ対応エージェントを例に、エージェント本体、Action Group、Lambda、Knowledge Base、テストコンソール、Traceの役割を確認します。IAM、コスト、ガードレール、本番適用の境界も整理します。
1. Amazon Bedrock Agentsとは何か
Bedrock Agentsは、ユーザーの依頼を受けて、基盤モデルが必要な情報を判断し、定義済みのアクションやナレッジ検索を組み合わせて回答を作る仕組みです。「質問の分類」「不足情報の確認」「検索」「外部処理の呼び出し」「結果の説明」を設計できます。
- エージェント: 基盤モデルと指示をもとに入力を処理する中心です。
- 指示: 役割、回答方針、確認条件を定義します。
- Action Group: 業務処理を呼び出す契約です。LambdaやAPIスキーマを接続します。
- Knowledge Base: S3などの業務文書を検索し、回答の根拠にします。
- セッションとTrace: 会話の流れや、検索・アクション選択を検証します。
2. 自前実装との違い
自前実装では、エージェントループ、ツール定義、リトライ、履歴、検索、監視を自社で組み合わせます。自由度が高い一方、各部品の障害処理と権限境界も自分で保守します。
| 観点 | Bedrock Agents | 自前実装 |
|---|---|---|
| 開始速度 | AWSの部品を設定して始めやすい | 設計・実装の初期負担が大きい |
| 自由度 | 提供機能の範囲で設計 | 状態管理やループまで自由 |
AWS内のデータとLambda/APIを中心に構成するなら、まずマネージドな選択肢を検討できます。複雑なマルチエージェント協調や複数クラウド横断が中心なら、自前オーケストレーターとの比較が必要です。
3. 同じモデルでもBedrock経由で使う理由
「ClaudeやGPT系のモデルを使いたいだけなら、モデル提供元のAPIを直接呼べばよいのではないか」。これは実装の初期段階で必ず出てくる疑問です。回答は、モデルの性能だけでなく、データの境界、認証、ネットワーク、監査、請求、AWSサービスとの接続をどこに集約するかで決まります。
モデル名ではなく、データ処理の境界を選ぶ
Bedrockでは、複数のモデル提供元の基盤モデルを、Amazon BedrockのAPIというAWS側の統一された入口から呼び出せます。アプリケーションはモデルごとに異なるAPI認証やレスポンス形式を直接扱うのではなく、AWS IAM、CloudTrail、VPCエンドポイント、AWSの請求・権限管理に寄せて構成できます。同じAnthropic系モデルやOpenAI系モデルを使う場合でも、重要なのはモデルのブランドではなく、社内データをどの経路でモデル推論へ渡し、誰がそのデータを管理できるかです。
直接APIを利用する方式が悪いわけではありません。モデル提供元の最新機能へ早くアクセスしたい、提供元固有のAPI機能を使いたい、AWS外のシステムから単純に呼び出したい場合には合理的です。一方で、すでに業務データがS3、DynamoDB、RDS、OpenSearch、LambdaなどAWS内にあり、IAMや監査基盤もAWSへ統一しているなら、Bedrock経由にすることで管理面の重複を減らせます。
「AWS内にとどまる」の正確な意味
Bedrockのプライバシー上の強みを説明するとき、「絶対にAWSの外へ出ない」と単純化するのは正確ではありません。AWS公式FAQは、Bedrockで処理される顧客コンテンツは利用リージョンで暗号化され、保存時もそのリージョンに保存されると説明しています。また、入力とモデル出力は第三者のモデル提供元と共有されないとしています。さらにAWSのデータ保護ドキュメントは、モデル提供元がBedrockのログや顧客のプロンプト・生成結果へアクセスできない構成を説明しています。
したがって、この記事でいう「AWS内にとどまる」とは、モデル提供元の運用環境へ顧客プロンプトを直接渡すのではなく、AWSが管理するBedrockのサービス境界で処理・保護されるという意味です。利用するリージョン、クロスリージョン推論、VPC接続、ログ保存先、バックアップ、外部連携は別途確認が必要です。特にクロスリージョン推論を選ぶ場合は、データがどのリージョンで処理される可能性があるかを要件と照合してください。
入力や出力がモデル学習に使われないこと
AWS公式FAQでは、Bedrockのユーザー入力とモデル出力はモデル提供元へ共有されないと説明されています。これは、モデル提供元の公開APIへ直接送ったデータが、その提供元のサービス条件に従うのとは異なる、Bedrockを選ぶ大きな理由です。少なくとも「自社の問い合わせ文や生成結果を、第三者モデル提供元の学習データとして自由に利用されるのではないか」という懸念を、AWSのサービス契約・データ保護の枠組みの中で管理できます。
ただし、「学習に使われない」ことと「社内から漏えいしない」ことは同じではありません。 Bedrockを使っても、アプリケーションのログ、CloudTrail、Lambdaのログ、プロンプトテンプレート、S3の中間ファイル、画面表示、利用者の誤入力から機密情報が漏れる可能性は残ります。CloudWatch LogsやS3へ保存する内容をマスキングし、ログの保持期間を短くし、IAMで閲覧者を限定する設計が必要です。
プライバシー面で得られる実務上のアドバンテージ
- データ境界: 業務データをAWS内のS3やデータベースから取得し、Bedrockへ渡す経路をAWSの権限・ネットワーク設計で管理しやすい。
- 提供元への非共有: AWS公式FAQでは、ユーザー入力とモデル出力を第三者モデル提供元と共有しないと明記されている。
- 暗号化とリージョン: 顧客コンテンツは暗号化され、利用リージョンで保存される。リージョン要件を設計に組み込みやすい。
- 監査: IAM、CloudTrail、CloudWatch、VPCエンドポイントなど、既存のAWS統制と組み合わせやすい。
- モデル選択: 一つの提供元へ固定せず、用途・品質・コスト・データ要件に応じて複数モデルを比較しやすい。
逆に、Bedrockを選べば自動的に「機密情報を安全に扱える」わけではありません。モデルへ送る前の匿名化、プロンプトインジェクション対策、Knowledge Baseのアクセス制御、生成結果の利用者権限チェック、データ保持と削除手順まで含めて初めてプライバシー要件を満たします。
4. 問い合わせ対応エージェントを設計する
「FAQを参照し、必要なら注文状況を照会する」エージェントを想定します。「注文1234の配送状況」ならAction Group、「返品条件」ならKnowledge Baseを使う流れです。
エージェントと指示
エージェントを作成し、基盤モデルとIAMロールを指定します。指示には回答範囲、本人確認が必要な操作、情報が見つからない場合の応答を明記します。注文変更のような副作用を持つ処理は、読み取り処理と分離します。
Action GroupとLambda
Action Groupは呼び出せる業務アクションの一覧です。注文番号を受け取り配送状態だけを返すLambdaを用意します。Lambda側で入力形式、認可、タイムアウト、エラー応答を検証し、エージェントに強い権限を直接持たせない構成にします。
{
"orderId": "1234",
"requestedOperation": "read_delivery_status"
}Knowledge BaseとFAQ
FAQや返品規約をS3へ配置し、Knowledge Baseのデータソースとして同期します。文書の見出し、適用日、対象商品、例外条件を明確にしてください。古い規約が残ると、検索精度以前に誤回答につながります。
5. テストコンソールとTrace
成功例だけでなく、FAQ検索、Action Group、情報不足、存在しない注文、権限外依頼、Lambdaタイムアウトを分けてテストします。期待したアクション、Lambda引数、検索根拠、秘密情報の非開示、Traceでの再現性を確認します。
6. 本番運用の勘所
IAMの最小権限
エージェント、Lambda、Knowledge Base、データソースのロールを分離し、リソースARNを絞ります。S3全体やDynamoDB全テーブルへの権限を一つのロールに集約せず、CloudTrailやCloudWatchで追跡できるようにします。
コスト
モデル推論だけでなく、Knowledge Baseの埋め込み・検索、Lambda、ログ、データ転送も関係します。正確な料金はモデル、リージョン、利用量で変わるため、公開時点のAWS料金ページで見積もります。
Guardrails
Guardrailsは有害内容や特定情報の扱いを制御する部品ですが、業務認可、注文所有者確認、Lambda入力検証の代替ではありません。出力フィルタと業務ロジックの認可を別レイヤーで設計します。
7. 向いているケース・向いていないケース
- 向いている: AWS内のFAQ、S3、Lambda、APIを組み合わせた問い合わせ対応。
- 慎重に検討: 長時間ワークフロー、厳密な決定性が必要なバッチ、複数クラウド横断。
- 別設計: 支払い、削除、契約変更など、誤操作の影響が大きい処理。
8. まとめ
Amazon Bedrock Agentsは、モデル、検索、業務アクションをAWSの管理境界に沿って組み合わせられます。一方で、Action Groupの権限、Lambdaの入力検証、Knowledge Baseの更新、Traceによる評価、コストと監査を一つのシステムとして考える必要があります。
AWS Architecture Icons（公式）
参考資料（Factチェック用）
Bedrockのデータ保護やモデル提供元とのデータ共有については、次のAWS公式資料で確認できます。サービス仕様やリージョン条件は更新されるため、記事の内容とあわせて最新版を参照してください。
