FIXER Tech Blog - AI/Machine Learning

AWSの「AIエージェント開発入門ワークショップ」で学べたこと

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「AIエージェント開発入門ワークショップに参加してGW 旅行プランナーを作ってみた話」を再編集したものです。

はじめに

最近、AIエージェントというキーワードを耳にする機会がぐっと増えてきました。Claude Code や Cursor のようなコーディングエージェントを日々の業務で使ってはいるものの、いざ「自分で AIエージェントを作ってください」と言われるとどこから手をつけていいか分からない、という方も多いのではないでしょうか。

そんな中、AWS ソリューションアーキテクトの方を講師にお招きした AI エージェント構築ワークショップに参加する機会をいただきました。 Strands Agents というフレームワークでエージェントを作り、Amazon Bedrock AgentCore にデプロイするまでを1時間ほどで体験するハンズオンです。

この記事では、ワークショップで学んだ AIエージェントの基礎知識と、ハンズオンで実際に手を動かして気づいたことを、参加者の目線で共有します。

この記事で得られること:
・AIエージェントの定義と、エージェントを支える技術 (CoT・Tool Use・ReAct・MCP) の整理
・AWS で AIエージェントを構築するための主要サービスの位置づけ
・Strands Agents + Bedrock AgentCore でエージェントを動かすまでの実装イメージ
・ハンズオンで詰まったポイントと、その回避策

※本記事の文章は、一部生成AIを用いて作成しています。

ワークショップ概要

・形式: ハイブリッド開催
・所要時間: 約3時間 (座学 + ハンズオン)

ワークショップは、前半の座学パートでエージェントの基礎概念と AWS のサービス群を整理し、後半のハンズオンでコードを書きながらデプロイまで体験する、という構成でした。

1. AIエージェントのおさらい

そもそも AIエージェントとは

ワークショップでは、AIエージェントを次のように定義していました。

ゴールを達成する手段をAIが自律的に計画し、環境にアクションしてフィードバックを得ながらタスクを遂行するもの。

ポイントは、「会話の流れを踏まえてエージェント自身がアクションを起こす」ところです。チャットで質問に答えるだけのAIアシスタントとは違い、自分でツールを呼び出し、その結果を観察して次の行動を決めていきます。

生成AIの進化を5段階で見る

座学では、生成AIの進化を5段階で整理した図が登場しました。AIエージェントが歴史的にどの位置にいるかを俯瞰できる図です。

段階	機能	キーワード
1	テキスト入力の続きを生成する	言語モデル
2	会話形式入力の続きを (外部知識と連携し) 生成する	AIアシスタント、RAG
3	外部連携可能なデータ形式を生成し、処理を起動する	Function Calling、Code Interpreter
4	タスク完了に至る計画を生成する	Reasoning model
5	タスク完了に至る計画を実行する	AIエージェント (2025)

AIエージェントは「計画を立てるだけでなく実行までやるレイヤー」にあたる、というのが要点です。

市場の注目度

ガートナーは「2028年までにエンタープライズソフトウェアアプリの33%にエージェントAIが組み込まれ、業務上の意思決定の15%が自律化される」と予測しています (出典: Gartner, "Top Strategic Technology Trends: agentic AI – The evolution of Experience" February 2025)。

一方で、講師の方からは「2025年時点でプロダクトレベルまで実装できている事例はまだ少ない」とのコメントもあり、本格的な実装はこれからの領域です。

AIエージェントを支える技術

エージェントを「使う側」から「作る側」に立つには、裏側の技術を押さえておく必要があります。 ワークショップで紹介された4つの技術を、簡単に整理してみます。

技術	概要
Chain of Thought (CoT)	LLM（大規模言語モデル） に段階的な思考過程を出力させてから最終回答を出させる手法。複雑な多段推論で精度を上げるために使われる
Tool Use (Function Calling)	LLMが外部のツール・関数・APIを呼び出せるようにする手法。LLM の能力をツール経由で外の世界に拡張する
ReAct (Reasoning + Acting)	CoTとTool Useを組み合わせ、思考 → 行動 → 観測のループを回す手法。CoT単体に比べてハルシネーション (LLMが事実と異なる内容を生成してしまう現象)を抑えやすい
MCP (Model Context Protocol)	AIと外部のデータソース・ツールを繋ぐためのオープン規格。Anthropic が2024年11月に公開

特にMCPは、座学資料での次の例えがわかりやすかったポイントです。

従来のAPIはツールごとに異なるキーが必要だったが、MCPはUSB Type-C のように接続を統一する。

ハンズオンでもStrands AgentsからMCPサーバーをツールとして繋ぐ場面があり、規格化された接続の利点が実装中にも伝わってきました。

エージェントとワークフローの違い

座学の中で「混乱しがちなところ」として整理されていたのが、エージェントとワークフローの違いです。

種類	説明
ワークフロー	あらかじめ決められた順序に沿ってタスクを実行する。各ステップでLLMが使われることがある
エージェント	タスクの実行手順をLLMが決定し、行動の結果次第ではその手順を途中で変更することもある

「自律型かどうか」が一つの線引きですが、話し手の背景によって言葉の使い方が違う領域でもあります。会話の中で「AIエージェント」という言葉が出たときは、相手がどのイメージを指しているかを確認するのが安全そうです。

2. AWSでAIエージェントを構築するためのサービス

実装の選択肢

AWSで AIエージェントを実装する場合、大きく2つの選択肢があるとのことでした。

アプローチ	概要	特徴
マネージドサービス利用	Bedrock Agents 等を使う	エージェントへの大まかな指示とツールを実装するだけで作成可能
Agent 開発フレームワーク利用	Strands Agents / LangGraph 等の SDK を使う	プログラムで柔軟にツール定義・エージェント実装を設定可能

現状は後者のフレームワーク利用の方が、さまざまなワークロードに対応しやすいとのお話でした。今回のハンズオンも Strands Agents を使う流れです。

主要なエージェント開発フレームワーク

座学では主要なフレームワークとして、今回使う Strands Agents (AWS の OSS SDK) のほか、LangGraph、OpenAI Agents SDK、Claude Agent SDK、Google ADK、Microsoft AutoGen の6つが紹介されていました。各クラウドベンダーがそれぞれ独自のフレームワークを出している状況なので、自社の利用クラウドや、すでに契約しているLLMベンダーに合わせて選ぶのが現実的ですね。

Amazon Bedrock AgentCore

ハンズオンでデプロイ先として使う Amazon Bedrock AgentCore は、2025年10月13日に一般提供が開始されたサービスです (東京リージョンも対応済み)。

資料の中では以下のように説明されています。

あらゆるフレームワーク・モデルで構築したエージェントを、安全かつ大規模にデプロイ・運用するための基盤

特徴的なのは、AgentCore が機能ごとにコンポーネントを分けて提供しているところです。

コンポーネント	役割
Runtime	エージェントのホスティング環境 (最大8時間の長時間ワークロード対応)
Memory	セッション記憶管理 (短期: チャット履歴 / 長期: セマンティック・ユーザー嗜好・要約)
Identity	認証・認可 (ユーザー → エージェント / エージェント → ツール の両方向)
Gateway	API・Lambda・既存サービスをMCPサーバーに変換
Code Interpreter	分離されたサンドボックス環境で安全にコード実行
Browser	サーバーレスなヘッドレスブラウザ (Playwright等に対応)
Observability	エージェントの振る舞いを一元監視 (OTELログ対応)

座学資料では、「AIエージェントの中核以外の部分 (認証認可・ツール管理・実行環境・ガードレール｟有害な出力や想定外の使われ方を防ぐ仕組み｠・記憶管理・ホスティング・運用監視) は『差別化されない重労働 (Undifferentiated heavy lifting)』である」という整理が示されました。

自社サービスに AIエージェントを組み込む際、これらすべてを自前で実装するのは現実的ではありません。AgentCoreは、その重労働をコンポーネント単位で肩代わりするためのサービス群、という位置づけになります。

実際に手を動かしたハンズオンのパートは後編記事に続きます。

新屋拓海／FIXER
３度の飯並みにゲームとガンプラとアニメが好き

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER