1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yoshi-sa

【第5回】本番運用を支える新基盤「Amazon Bedrock AgentCore」の全貌

1
Posted at

※本記事はAIが書いて、人間が伴走しファクトチェックしています。
やや大げさな表現が含まれる場合、AIの性格だと思って生暖かい目で見ていただければ幸いです。

📅 連載構成案（全6回）

全体の流れとして、まずは「生成AIの基礎」から入り、次に「自社データとの連携（RAG）」、そして「自律的なアクション（Agents）」、最後にそれを本番運用・拡張する「基盤（AgentCore）」へと、ステップアップしていく構成にしています。今回は第2回になります。

第1回：生成AIとAmazon Bedrockの基礎 〜まずは用語を整理しよう〜

  • 概要: 生成AIのバズワードをAWSエンジニアの視点で分かりやすく翻訳し、Amazon Bedrockの立ち位置を解説します。
  • 解説する主な用語: LLM（大規模言語モデル）、プロンプト、トークン、基盤モデル（Foundation Model）
  • Bedrockの解説ポイント: 「複数メーカーのモデル（ClaudeやLlamaなど）を、1つのAPIで切り替えて使えるAWSのフルマネージドサービス」であること。
    • 【重要】 入力データがモデルの再学習に利用されないなど、AWSの強固なセキュリティ環境で生成AIを使えるメリット。

第2回：Amazon Bedrockを触ってみよう 〜コンソール体験とコスト感〜　

  • 概要: 実際にAWSマネジメントコンソールからBedrockのモデルを有効化し、プレイグラウンドで動かしてみる「手触り感」を伝える回です。
  • 解説する主な用語: ハルシネーション（もっともらしい嘘）、推論パラメータ（Temperatureなど）
  • Bedrockの解説ポイント:
    • コンソールからのモデルアクセス有効化の手順。
    • テキスト生成と画像生成の簡単なデモ。
    • 従量課金制（トークン課金）の仕組みと、コストの見積もり方の基本。

第3回：自社データをAIに教える「RAG」とKnowledge Bases

  • 概要: 「社内規程について質問したい」といったよくあるニーズに対し、モデルを再学習させずに自社データと連携させる手法を解説します。
  • 解説する主な用語: RAG（検索拡張生成）、ベクトルデータベース、エンベディング（Embedding）
  • Bedrockの解説ポイント:
    • Knowledge Bases for Amazon Bedrockの紹介。S3にPDFを置くだけで、OpenSearch Serverlessなどと連携してRAG環境がマネージドに構築できる仕組みを解説します。

第4回：AIが自律的に動く！Bedrock Agentsとは？

  • 概要: ここからが本番です。単に質問に答えるだけでなく、AI自身が考えて社内システム（API）を叩く「AIエージェント」の概念を解説します。
  • 解説する主な用語: AIエージェント、Chain of Thought（思考の連鎖）、ツール呼び出し（Function Calling）
  • Bedrock Agentsの解説ポイント:
    • ユーザーの曖昧な指示から、AIが「計画→API呼び出し（Lambdaなど）→結果の解釈」を自律的に行う仕組み。
    • Action Groups（エージェントが実行できるタスクの定義）の概念。

第5回：本番運用を支える新基盤「Amazon Bedrock AgentCore」の全貌　（今回はここ！！）

  • 概要: 開発したエージェントを「安全に」「大規模に」本番環境で運用・デプロイするための最新プラットフォーム「AgentCore」の役割を解説します。
  • 解説する主な用語: セッション分離、オブザーバビリティ（可観測性）、ガードレール
  • Bedrock AgentCoreの解説ポイント:
    • Runtime: エージェントをサーバーレスかつセキュア（分離された環境）で実行する仕組み。
    • Memory: ユーザーごとの会話の文脈や長期記憶をインフラ管理なしで保持する機能。
    • Gateway / Policy: エージェントがアクセスできるツールや外部APIを安全に管理し、意図しない動作を防ぐガバナンス機能。
    • Evaluations: エージェントの回答品質を継続的に評価・モニタリングする仕組み。

第6回：まとめ 〜AWSで作る業務特化型AIエージェントのアーキテクチャ〜

  • 概要: 連載の総まとめとして、AWSエンジニア向けに「社内向け業務支援エージェント」を構築する場合の全体アーキテクチャ図を提示します。
  • 内容:
    • ユーザー（Cognito）→ AgentCore Identity → AgentCore Runtime → Bedrock Agents → 既存の社内API（Lambda）という具体的な連携フローの紹介。
    • これから生成AIに取り組むAWSエンジニアへのネクストステップの提示。

1. はじめに：PoC（概念実証）と本番環境の壁

こんにちは。AWSエンジニアのための生成AI入門、第5回です。

前回（第4回）までで、自社データを検索し（RAG）、APIを自律的に叩く（Agents）高度なAIエージェントの作り方を学びました。開発環境で自分がテストしている分には、「AIってすごい！便利！」と感動するはずです。

しかし、これを全社員（あるいは全顧客）に向けて本番リリースするとなると、インフラエンジニアとしては以下の課題が頭をよぎります。

  • 「Aさんの会話内容が、別のBさんの画面に混ざって出力されないか？（セッション管理）」
  • 「AIが社内システムを操作する際の認証認可はどうするのか？（アイデンティティ）」
  • 「AIが裏側でどう推論して、どのAPIを叩いたか追跡できるか？（可観測性）」

これら「本番運用の壁」を乗り越え、エージェントをエンタープライズのインフラとして安全にホスティングするためのフルマネージドプラットフォーム、それが2025年後半に登場した 「Amazon Bedrock AgentCore」 です。

2. 本番運用で必須となるAI用語（AWSエンジニア向け翻訳）

AgentCoreの機能を理解するために、まずは本番運用特有の用語をインフラ目線で翻訳してみましょう。

  • セッション分離（Session Isolation）
    • 意味: ユーザーごとの会話の文脈（コンテキスト）が他人に漏れないように完全に分離して管理すること。
    • AWSエンジニア向け翻訳: 「DynamoDBのパーティションキーによるデータ分離」。これをAI側でマネージドにやってくれないと、自前でRedisやDynamoDBを立てて会話履歴を管理する羽目になります。
  • オブザーバビリティ（可観測性 / Observability）
    • 意味: AIがどのような思考プロセスを経て、どのツールを呼び出し、どう回答したかのログを追跡できる状態。
    • AWSエンジニア向け翻訳: 「X-Rayによる分散トレーシング」や「CloudWatch Logsの詳細ログ」。これが無いと、AIは完全なブラックボックスになり、トラブルシューティングが不可能です。
  • ガードレールとポリシー（Guardrails & Policy）
    • 意味: AIへの不適切な入出力のフィルタリングと、エージェントの行動範囲の制限。
    • AWSエンジニア向け翻訳: 「AI専用のAWS WAF（Guardrails）」と「IAMのような実行認可エンジン（Policy）」。

3. Bedrock AgentCoreを構成する主要コンポーネント

AgentCoreは、エージェントを安全にスケーリングさせるための「モジュール型インフラ基盤」です。最大の驚きは、Bedrock Agentsだけでなく、LangGraphやCrewAIといったオープンソースのフレームワークで作成したエージェントもそのままデプロイできるという点です。

本番運用を支える主要なコンポーネントを見ていきましょう。

① Runtime（ランタイム）と Identity（アイデンティティ）

  • Runtime: エージェントをサーバーレスかつセキュアに実行する環境です。ユーザーごとのリクエストを完全に分離し、最大8時間の非同期ワークロードにも対応します。課金は「消費したアクティブリソース分のみ」なので、LLMの応答待ち（I/O待ち）時間のコストを削減できます。
  • Identity: エージェントがユーザーの代わりに（あるいは自律的に）AWSリソースやサードパーティのSaaSを叩くための、OAuth等と統合された安全な認証認可基盤です。

② Memory（メモリ：長期記憶と文脈の保持）

これまで、チャットボットに「文脈（直前の会話）」を覚えさせるには、アプリ側で過去の会話履歴を毎回プロンプトに含めて送信する必要がありました。
AgentCoreのMemory機能を使えば、インフラ側でユーザーごとの会話履歴を自動的に保持・管理してくれます。さらに「エピソード記憶」と呼ばれる機能により、過去の失敗やユーザーの好みをAIが学習し、次回以降の回答精度を向上させることができます。

③ Gateway（ゲートウェイ）と Policy（ポリシー）

  • Gateway: APIやLambda関数をエージェント用のツールに変換する入り口です。最近ではAI界隈のデファクトスタンダードである 「MCP（Model Context Protocol）サーバー」 への接続もネイティブサポートされています。
  • Policy: エージェントが意図しないツール操作（例：「全件削除」など）をしないよう、リアルタイムで行動を監視・ブロックします。自然言語で「〜の操作は禁止」と書くだけで、裏側でAWSのオープンソース認可言語である 「Cedar」 に変換され、堅牢なガバナンスを効かせることができます。

④ Observability（可観測性）と Evaluations（評価）

OpenTelemetry（OTEL）と互換性があり、CloudWatchとシームレスに連携します。本番環境でのAIの思考プロセスをすべてトレース可能なほか、Evaluations機能によって「オンライン（本番稼働中）の回答品質」を自動でスコアリングし、劣化を早期検知します。

4. ユースケースと「セッション分離」の実装イメージ

【ユースケース：全社員向けヘルプデスクエージェント】
社員Aが「私の昨日の経費申請、どうなってる？」と聞いた時、AIはAさんの過去の会話履歴とIDだけを参照し、Bさんの情報を絶対に引き出さない仕組みが必要です。

インフラエンジニアがアプリ側に提供するAPIエンドポイントでは、AgentCoreに 「一意のSession ID」 を渡す設計にするだけで、複雑な状態管理をAWSに丸投げできます。

import boto3
import uuid

# Bedrock Agent Runtimeクライアントの初期化
bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

agent_id = 'YOUR_AGENT_ID'
agent_alias_id = 'YOUR_AGENT_ALIAS_ID'

# Cognitoのユーザーサブジェクト（sub）などをベースに、セッションIDを生成
# 【重要】これによりユーザーごとのMemory（会話履歴）とRuntime環境が完全に分離される
user_session_id = str(uuid.uuid5(uuid.NAMESPACE_DNS, 'user-A-id'))

response = bedrock_agent_runtime.invoke_agent(
    agentId=agent_id,
    agentAliasId=agent_alias_id,
    sessionId=user_session_id, # ← ここが本番運用で最も重要！
    inputText='さっきの件だけど、やっぱり来週に変更しておいて。' 
    # ↑「さっきの件」という文脈を、AgentCoreのMemoryが自動で補完してくれる
)

# レスポンスの処理（Traceを有効にすれば、Observability機能で思考プロセスも取得可能）
for event in response.get('completion'):
    if 'chunk' in event:
        print(event['chunk']['bytes'].decode())
    elif 'trace' in event:
        print("【AIの思考トレースログ】", event['trace'])

5. 本番運用における「セキュリティ」と「コスト」

  • 多層防御（Defense in Depth）によるセキュリティ:
    フロントエンドからの悪意あるプロンプトはGuardrailsで弾き、エージェントがツール（Lambda等）を実行しようとする瞬間は**AgentCore Policy（Cedar）**で権限をチェックします。この多層防御アーキテクチャこそが、エンタープライズ導入におけるセキュリティ部門の強力な説得材料になります。
  • MemoryとTraceのコスト管理:
    Bedrockの利用料は「トークン課金」が基本ですが、本番環境でMemory（長期記憶）を有効にすると、ユーザーごとの過去の文脈を毎回の推論に含めるため、入力トークン数が雪だるま式に増えていく傾向があります。
    また、詳細な推論ログ（Trace）をすべてCloudWatchに吐き出すとログの保存コストもかかります。「保存する会話履歴は過去10ターンまで」「Traceのサンプリングレートを絞る」など、コストと可観測性のトレードオフを設計するのがアーキテクトの腕の見せ所です。

6. 第5回のまとめと次回予告

今回は、エージェントを本番運用するための最強のモジュール基盤「Amazon Bedrock AgentCore」について解説しました。
AIモデル自体の賢さも重要ですが、それを 「フレームワークに依存せず、安全に・分離して・監視できる状態」 でホスティングするAWSのマネージドサービスこそが、エンタープライズ領域でBedrockが選ばれる最大の理由です。

さて、全6回でお送りしてきたこの連載も次回が最終回です。
次回（第6回）は、 「まとめ 〜AWSで作る業務特化型AIエージェントの全体アーキテクチャ〜」 と題して、これまで学んだRAG、Agents、AgentCore、そして既存のAWSリソース（Cognito, S3, Lambdaなど）をすべて組み合わせた「完成予想図」を描きます。あなたの会社で明日から使える構成図をお持ち帰りください！

1
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?