2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェント初心者が、Amazon Bedrock AgentCoreを触って疑問に感じた他AWSサービスとの違い

Posted at

はじめに

私はプロジェクト都合上AIを触ることがなく、正直「AIはまだそんなに普及していないから大丈夫」と思っていました。
しかしAWS Re:Inventに行き、CEO基調講演やその他のセッションを取っていく中で、AIに関する知識をつけていないことに危機感を感じ、勉強を始めました。
これから学ぶ方のために、個人的に疑問を感じた箇所をここにまとめていこうと思います。

※かなり初歩的な疑問です。

Amazon Bedrock AgentCoreとは

Amazon Bedrock AgentCore は、AIエージェント(自律的に判断・行動するAIアプリケーション)を 安全かつ本番環境レベルで 構築・デプロイ・運用 するための AWS のマネージドプラットフォーム です。
インフラ管理の負担を抽象化し、スケーラビリティ、セキュリティ、Identity/Access 管理、記憶(コンテキスト・メモリ)、実行環境、ツール連携、モニタリングなど一連の機能をまとまって提供します。

Amazon Bedrock AgentCoreの必要性は下記にあります。

  • エージェント開発の複雑性

Generative AI の普及により、単なる LLM 呼び出しではなく 長時間実行・複雑タスク・外部ツールとの連携・本番運用 が求められるようになってきました。従来は開発者が自前でサーバー、ランタイム、認証・認可、ログ、拡張性を組み合わせる必要があり、時間もコストも掛かります。

  • 本番信頼性の要件

企業ユースでは スケーラブル/セキュア/監査可能 な基盤が不可欠。AgentCore はこうした要件を満たすための フルマネージド基盤 として位置付けられています。

疑問①: Step Functionsとの違いは何か

AIエージェントを触っていて最初に思ったのは「特定の条件に基づいて順番通りに手順をこなしてる」ということです。
Step FunctionsというAWSマネージドサービスも条件に基づいて処理を順番にこなすため利用されると思っています。単純なステップであればAI Agentに頼らずとも良いのでは?と思いました。

Step Functions = “ルールベースのオーケストレーション”

  • 状態遷移(状態機械)が 設計時に確定
  • 条件分岐も 明示したルール(Choice)で決まる
  • 並列(Parallel)、Map、リトライなど 制御が厳密
  • 強み:監査・再現性・テスト容易性(「この入力なら必ずこの分岐」)

AgentCore = “推論ベースのオーケストレーション”

  • LLMが「次に何をするか」を動的に選ぶ(ツール選択・順序・回数)
  • そのために Runtime / Memory / Gateway / Identity / Observability など、エージェント運用に必要な要素がパッケージ化されている

Step FunctionはあくまでYesかNoかをシステムが判断できるレベルの単純なフローの場合に利用できて、曖昧な指示に対しても自分で判断してほしい場合はAI Agentに軍配が上がるということで理解をしました。
ただ、個人的には「ワークフローを何でもかんでもAIエージェント化するのではなく、適切な用途に基づいて利用サービスを分けること」が大事だと感じました。

疑問②: AIエージェントアプリをECSやFargateにデプロイするのではなく、AgentCoreにデプロイするメリットは何か

私はプロジェクトでEKSを触っていたことから、AIエージェントも同じようにコンテナ上で動かすようなイメージをしていました。
しかし「AgentCore Runtime上にデプロイする」という言葉をみて、「あれ、コンテナやサーバレス上にデプロイはしないのか?」と疑問に思いました。

ECSやFargateにデプロイするのと、AgentCore Runtimeにデプロイすることの違いは一言で言うと「運用の責任範囲」にあります。

ECS/Fargate にデプロイする場合:

  • 実行基盤、スケール、セッション管理、認証・認可、ツールの公開、メモリ永続化、可観測性、ガードレール、監査を自分で管理しなくてはいけない
  • 普通のWebアプリとしてエージェントAPIをホストするイメージ

AgentCore にデプロイする場合:

  • AWSがエージェントに特化した Runtime / Identity / Memory / Gateway / Observability(+Browser/Code Interpreter等のBuilt-in tools) を提供し、組み合わせて本番運用しやすくする

AIエージェントにはアプリケーションをデプロイする以外にも上記のような非機能観点やツールの増幅に耐えうる設計にする必要があり、それを実現するためにAgentCoreが必要なんだという理解をしました。

まとめ

本記事では、Amazon Bedrock AgentCore を理解するうえで混乱しやすい2点に絞って整理しました。

① Step Functions との違い
Step Functions は ルールベースのワークフローであり、
状態遷移・分岐・実行順序は 設計時点で確定 します。

一方、AgentCore は 推論ベースのオーケストレーションを前提としており、
LLM が状況に応じて「次に何をするか」「どのツールを使うか」を動的に判断します。

  • 処理内容が明確・決定論的 → Step Functions
  • 指示が曖昧・判断を委ねたい → AgentCore

という住み分けで理解するのが自然だと感じました。

② ECS / Fargate にデプロイする場合との違い

ECS や Fargate に AI エージェントをデプロイすること自体は可能ですが、その場合は

  • Identity / 認証・認可
  • セッション・メモリ管理
  • ツール公開・ガードレール
  • 監査・可観測性

といった エージェント特有の運用責務をすべて自前で設計・実装する必要があります。

AgentCore はこれらを 「AIエージェント前提の Runtime としてまとめて提供」 することで、
エージェントを アプリケーションではなくプロダクトとして運用 しやすくしている点が本質的な違いだと理解しました。

2
0
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
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?