第192回 雲勉 Amazon Bedrock AgentCoreでは守れない – クライアント側で実装する信頼性向上のためのデザインパターン

第192回 雲勉 「Amazon Bedrock AgentCoreでは守 れない – クライアント側で実装する信 頼性向上のためのデザインパターン」

0. 自己紹介 • 本田 岳士（ほんだ たけし） • エンタープライズクラウド事業部 開発第二セクション 第2開発グループ(大阪オフィス) • 自社開発２社経験してアイレット • アイレット歴 2年9ヶ月 • スパゲッティコードに対する耐性が強み • 趣味は一人旅、変なTシャツ・パーカー、猫３匹 • サーバレスアーキテクチャが好き • 2025 Japan All AWS Certifications Engineers • Google Cloud Partner All Certification Holders 2025 2

アジェンダ 0. 自己紹介 1. 概要 2. Amazon Bedrock AgentCore(以下AgentCore)とは 3. AgentCoreの信頼性 – マネージドとアプリ実装の境界 4. 使用するデザインパターンの概要 5. クライアントの実装 6. Q&A 7. まとめ 3

1. 概要 4

1．概要 ◼ 今回は、 Amazon Bedrock AgentCoreがマネージドで担保してくれる信頼性と、自分たちで実 装しなければならない信頼性の境界を整理し、その境界の外側をクラウドデザインパターンで 補っていきます。 ◼ まずAgentCoreとは何かを説明し、AgentCoreがマネージドで担保する信頼性と、自分たちで 実装すべき信頼性の境界を整理します。そのうえで、Circuit BreakerとRetry with Backoffの2 つのクラウドデザインパターンを使ってクライアント側を実装するお話です。 ◼ AgentCoreのハンズオン程度は触ったことがある方が理解は進みやすいと思いますが、 AgentCore自体の話はほとんどなく、クライアント側のデザインパターンの話に重きを置いて おります。 5

2. AgentCoreとは 6

2． AgentCoreとは AIエージェントの本番運用を支える、AWSのマネージド実行基盤 マネージドで運用負荷を削減 本番必須機能を統合提供 信頼性向上の土台を提供 7 7

2． AgentCoreとは AgentCoreの主な特徴 フレームワーク非依存 エンタープライズ機能 スケーラビリティ 8 8

3. AgentCoreの信頼性 — マネージドと アプリ実装の境界 9

3． AgentCoreの信頼性 — マネージドとアプリ実装の境界 インフラ可用性（AWS基盤） ホスティング & 自動スケール セッション管理 & メモリ永続化 Observability（Amazon CloudWatch(以下CloudWatch)) 10

3． AgentCoreの信頼性 — マネージドとアプリ実装の境界 エラーハンドリング リトライ（Backoff） フォールバック（CB） Primary Fallback 11

3． AgentCoreの信頼性 — マネージドとアプリ実装の境界 AgentCoreが担保 アプリ側で実装 可用性（AWSインフラ） エラーハンドリング ホスティング & スケール リトライ Observability フォールバック 12

4.使用するデザインパターンの概要 13

4． 使用するデザインパターンの概要 目的 適用場面 設計戦略 Failure threshold 今回の例 Primary Fallback Timeout（cooldown） Fallback policy 14

4． 使用するデザインパターンの概要 CLOSED OPEN HALF_OPEN 15

4． 使用するデザインパターンの概要 再試行フロー（要点） Invoke Backoff 1s → 2s → 4s → 8s Jitter 待ち時間にランダム性を追加 使い分け 成功 一時障害 継続的障害 16

5.クライアントの実装 17

5．クライアントの実装 Circuit Breakerが Retry Backoffを内包する形で 連携する あらかじめ2つのエージェントを デプロイしておく 18

5．クライアントの実装 指数関数的に増加 ランダムな時間を追加 19

5．クライアントの実装 OPENのまま一定時間経過したら HALF_OPENにして一度だけ プライマリエージェントで実行 リトライ付きで プライマリエージェント呼び出し リトライ失敗回数が上限を超えた らエラー処理へ フォールバック時のエージェント の呼び出し 正常終了ならCLOSED エラー処理の中で失敗のカウント とstateの更新を行い、 StateがOPENでなければ fallback処理へ 20

5．クライアントの実装 Circuit Breaker呼び出し 21

6. Q&A 22

6．Q&A Q. フォールバック用にエージェントを2つ作るのと、1つのエージェント内でモデル を切り替える場合のメリット/デメリットは？ A.エージェントを2つ作成する A.1つのエージェント内でモデルを切り替える メリット： メリット： • 片方のエージェントの障害がもう片方に影響しない • エージェントが1つなので管理がシンプル • クライアント側のARN切り替えだけで実現できる • エージェント定義の重複がない • エージェントに応じてプロンプトやツール構成を最適化できる デメリット： デメリット： • エージェント自体の障害やリージョン障害などの対処はできない • 2つのエージェントの管理が大変になる可能性 • リクエスト単位でモデルを動的に切り替えることはできない AgentCore Runtimeの料金体系は「アクティブリソース消費ベース」 →待機しているエージェントのコストは発生しない 23

6．Q&A Q. Circuit Breakerの閾値はどう決める？ A. 1. エージェントの応答時間の実測値→p99のレイテンシを基準に 2. 障害の種類→一時的なエラーは高めに、長引くエラーは短めに 3. ユーザー体験→待たせすぎるのも過度に早く切り替えるのも良くない →メトリクスを確認してチューニング 24

7. まとめ 25

7. まとめ • 今回は、AgentCore Runtimeにデプロイしたエージェントの信頼性を向上させる2つのクラウドデ ザインパターンを実装しました。 • ポイントは、AgentCoreがマネージドで担保する信頼性と、自分たちで実装すべき信頼性の境界を理解する ことです。 • マネージドに任せるべきところはAgentCoreに任せ、自分たちで補うべきところだけを実装する。 この考え方は、AgentCoreに限らず、マネージドサービスを活用するうえで共通する原則です。 • デザインパターンとは、繰り返し発生する問題に対する、検証済みの解決策に名前をつけたもの です。ゼロから障害対策を考えるのではなく、先人が検証した型を適用することで、設計判断の 質とスピードが上がります。そしてデザインパターンは組み合わせることができます。問題の性 質に応じてパターンを選び、組み合わせることで、個別に作り込むよりもシンプルで保守しやす い設計になります。 26

リファレンス • Circuit breaker pattern https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-designpatterns/circuit-breaker.html • Retry with backoff pattern https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-designpatterns/retry-backoff.html • Amazon Bedrock AgentCore Developer Guide https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrockagentcore.html 27

• https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html
• https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html
• https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html

ご清聴ありがとうございました！ 28