Amazon Bedrockのエージェント

エージェントは、依頼を複数の手順へ分解し、必要なを呼び出して処理を完了させる仕組みです。 AIF-C01では、に実際の作業を任せる構成として問われます。

なお、は、現在はAmazon Bedrock Agents Classicという名称で保守の段階にあり、新規の利用者を受け付けていません。既存の利用者は引き続き使えます。新しくエージェントを作る場合は、が勧められています。この章では、AIエージェントの役割と、エージェントを使う場面の判断を学びます。

概要

通常のは文章を返すだけですが、エージェントは外部のシステムを呼び出せます。利用者の依頼を受けたエージェントは、何をすべきか考え、必要な情報を集め、順に処理を進めます。

試験では、「複数の処理を順に実行して依頼を完了させたい」という要件で選びます。

主要技術

①構成要素

要素	役割
指示 (instruction)	エージェントの役割と守るべき方針を文章で定義します。
	手順の判断と応答の生成を担当します。
アクショングループ	呼び出せる操作の定義です。やのスキーマを指定します。
知識ベース	社内文書を参照して根拠を得ます。
の制御	各段階のプロンプトを調整できます。
	望まない話題や出力を遮ります。
メモリー	会話の文脈を保持します。

②処理の流れ ⚠️ 頻出

依頼を受け取り、達成に必要な手順を分解します。
足りない情報があれば利用者へ質問します。
アクショングループを呼び出して情報を取得または処理を実行します。
結果を確認し、必要なら次の手順へ進みます。
完了したら結果を応答します。

⚠️ 頻出: エージェントの特徴は、複数手順の分解と外部システムの呼び出しです。単一の質問応答であればエージェントは不要です。

③向く要件と向かない要件

要件	判断
予約や申請など複数システムをまたぐ処理	エージェントが向きます。
社内文書を参照した質問応答だけ	知識ベース () で足ります。
定型の手続きで流れを厳密に固定したい	のほうが制御しやすいです。
単純な文章生成	モデルの直接呼び出しで足ります。

④設計上の注意

注意点	内容
権限の最小化	エージェントが呼び出せる操作を必要最小限に絞ります。
破壊的な操作の扱い	削除や送金のような操作には人間の承認を挟みます。
誤った手順の可能性	判断は確率的です。実行前の確認手順を設けます。
監査	呼び出しの記録を残し、後から追えるようにします。
	想定外の話題や出力を遮ります。

⚠️ 頻出: エージェントに与える権限はが原則です。広い権限を与えると誤った判断で影響が広がります。

⑤現在の位置づけとAgentCoreへの移行 ⚠️ 頻出

項目	内容
状況	として保守の段階にあります。新しい機能は追加されません。
既存の利用者	作成済みのエージェントは引き続き動きます。
新しい開発	が推奨先です。
影響を受けないもの	のモデル、Knowledge Bases、Guardrailsは引き続き使えます。

Bedrock Agents Classicの機能	AgentCoreでの対応
アクショングループ	でのツールとして公開します。
知識ベースの関連付け	Gatewayや検索のツールを通して知識ベースを使います。
メモリー	の短期記憶と長期記憶を使います。
複数エージェントの協調 (監督役と専門役)	任意のフレームワークで、エージェントをツールとして呼ぶ構成などを作ります。
	Bedrockのガードレールの設定と、Gatewayでの規則の適用を使います。

⚠️ 頻出: 試験で問われるのは、特定の製品の操作よりも「AIエージェントが何をするか」「どの要件でエージェントを選ぶか」です。新規に作る前提の選択肢では、AgentCoreを選びます。

試験対策

①選択基準

問題文のキーワード	選ぶもの
複数の手順を自動で実行させたい	AIエージェント (新しく作るなら)
外部を呼んで処理を完了させたい	エージェントのツール (で既存のAPIを公開。ではアクショングループ)
社内文書を根拠に答えるだけ	知識ベース ()
定型手続きの流れを固定したい
誤操作の影響を抑えたい	と人間の承認
新しくエージェントを作り、本番で運用したい	Amazon Bedrock AgentCore

②よくある誤答

エージェントを常に最良の構成と考えること。単純な質問応答では過剰です。
エージェントが確実に正しい手順を選ぶと考えること。判断は確率的です。
エージェントに広い権限を与えて柔軟性を高めようとすること。が原則です。