はじめに
AI Builders Day とは
セッションが始まるまで
【キーノート1】まだ間に合う！Agentic AI on AWSの現在地をやさしく一挙おさらい
AI エージェントの設計で注意するべきポイント6選
AgentCore BrowserとClaude Codeスキルを活用した『初手AI』を実現する業務自動化AIエージェント基盤
最後に

はじめに

こんにちは、新人アプリケーションエンジニアの福井です！
業務では日々 Java × SpringBoot を用いてバックエンドからフロントエンドまで幅広く開発に携わっています。
今回、12/20(土)に池袋サンシャインシティで開催された、JAWS-UG 主催の AI Builders Day 2025に参加してきたため、聴講レポートとして共有します。

AI Builders Day とは

2025年はAIエージェント元年。
AWSで生成AIアプリを作る日本の「ビルダー」たちを盛り上げる、国内最大規模の開発者向けオフラインイベントです。現地では既にAIエージェント構築に業務で取り組む開発者は然り、これからエージェント開発に挑戦する人まで幅広い層が参加していました。参考までに、下記が本イベント参加者の年代比率と初参加率になります。

引用：https://x.com/minorun365/status/2002397745102139857?s=46‬

最終的に、人数としては600人を超え、当日枠を200枠拡張するほど大盛況のイベントでした。

セッションが始まるまで

今回会場の雰囲気を早く知りたかったこともあり、早めに会場入りしました。
会場についてからは、まず企業ブースに行きました。企業ブースでは、早速 AI エージェントに関する書籍や自社での実績について紹介されていました。

各社のブースを見て回っていると、、
JAWS-UG が主催している初心者支部において、参加したことがない支部を compass 上でメンバー追加すると、AWS BuilderCards の拡張版がもらえるブースがありました！もちろん、ゲット..！
前回 JAWS FESTA に参加した際にスタンダード版は入手していたため、これで遊べる幅が広がりました！(まだしたことがない..)

そうこうしているうちに来場者数が増え、オープニングとキーノートが始まりました。
本記事では、気になったセッション3つを取り上げたいと思います。

【キーノート1】まだ間に合う！Agentic AI on AWSの現在地をやさしく一挙おさらい

speakerdeck.com

登壇者（敬称略）：みのるん（KDDIアジャイル開発センター株式会社）

こちらのキーノート1では、「AIエージェント利用元年」から「AIエージェント構築元年」への移り変わる中、まず生成AIの大きな潮流について俯瞰的に整理されました。 ChatGPTの登場以降、私たちはAIを“使う側”としてその恩恵を享受してきましたが、いまや関心は「どう使うか」から「どう作り、どう組み込むか」へと確実にシフトしています。セッション冒頭では、LLMの登場によって企業システムがどのように変わり、なぜAIエージェントという形に進化してきたのかが、技術の積み重ねとして丁寧に語られました。 RAG(検索拡張生成)、Amazon Bedrock Knowledge Bases、Amazon S3 Vectors、OSSフレームワークなどなど、個別の技術を点ではなく線で捉えることで、「今なぜAIエージェントが求められているのか」を自然と腹落ちさせることができました。

AIエージェントを単に「便利そう」で終わらせずに、「これから私たちはAIとどう向き合えばいいのか」考えるきっかけを与えてくれる、全体像の見えたキーノートだったと感じました。学びの多いセッションでした。

AI エージェントの設計で注意するべきポイント6選

speakerdeck.com

登壇者（敬称略）：福地開(ふくち)

本セッションでは、AIエージェント構築における実体験に基づいたプラクティスが、構築から運用まで一貫して紹介されました。

これまで私は、ChatGPTのような生成AIを使う側として、その利便性を享受してきました。一方で、AIエージェントの仕組みや、コンテキスト設計といった用語、さらにはエージェント構築におけるベストプラクティスについては、正直理解が追いついてない状態でした。そうした背景もあり、「AIエージェントとは何なのか」「どのように設計し、構築していくべきなのか」を体系的に知りたいと思い、このセッションに参加しました。このセッションで持ち帰った学びを紹介します。

AIエージェントのアーキテクチャ

AI エージェントのアーキテクチャには、Anthropic 社のブログで紹介されている通り、大別して2種類あります。

エージェント型
計画作成・ツール実行・振り返り(Agentic Loop)を自律的に繰り返します。
こちらは、LLMが処理全体を統制するため、柔軟さと引き換えに不安定さを併せ持ちます。
ワークフロー型
事前定義されたコードパスを LLM とツールが順に実行します。
こちらは、処理のオーケストレーターが事前に定義済みで、安定して処理が可能な反面、柔軟な振る舞いがしにくい構成となっています。

これらアーキテクチャ選定の鍵はコンテキストエンジニアリングが握っています。

AIエージェントのコンテキストエンジニアリング

引用：The New Skill in AI is Not Prompting, It's Context Engineering

コンテキスト
LLMに与える情報全体を指す言葉
構成要素は、システムプロンプト、ユーザープロンプト、ツール、外部記憶など様々ある。

コンテキストエンジニアリング
必要なデータを必要なだけ、必要なタイミングでLLMに与えるように制御する行為

本セッションでは、とりわけ外部情報の扱いが重要なポイントとして取り上げられていました。外部情報の取得方法には、エージェント自身が必要に応じて取得する方式と、あらかじめプログラム側で取得した情報をエージェントに渡す方式の二通りがあります。この選択が重要なのは、どちらを採るかによってシステム全体のアーキテクチャが大きく左右されるからです。実際に福地さん自身が構築したエージェントに対して、どのアーキテクチャを選定したか、一例として挙げていただきました。

取得すべき外部情報が入力次第で異なる場合　→　エージェント型
取得すべき外部情報がある程度分かっている場合　→　ワークフロー型

このようにコンテキスト(外部情報)の取得プロセスを考えると、アーキテクチャが見えてきます。
ただ、アーキテクチャに最適解はないため現状の方針としては、コンテキストベースで考えることが重要です。

LLMOps まで見据えた構築方法を考える

本セッションで特に強調されていたのが、エージェントの評価を「後付け」ではなく設計の一部として考える重要性です。エージェントは一度作って終わりではなく、モデルのアップデート、プロンプト変更、ツール追加など、継続的な改善が前提になります。そのため、評価と改善のサイクル（いわゆるLLMOps）を最初から計画に含めておく必要があります。

エージェント特有のエラーハンドリングを意識する

エージェントはLLMや外部サービスに依存する点で特有の失敗パターンを持ちます。
モデル側の制限や一時的なエラーによって処理が止まる可能性があるため、

リトライ処理を入れる
複数モデルを使ったフェールオーバー設計を行う

といった工夫が、実践的なプラクティスとして紹介されていました。このあたりは「作ってみないと分からない領域」だからこそ、フレームワークやマネージドサービスを使って試行錯誤することが大切だと感じました。

独自性のないエージェントは使われない

後半で特に印象に残ったのが、エージェントの「独自性」についての話です。「それ、資料や既存ツールで良くない？」と言われてしまうエージェントは、結局使われません。

独自性を出す方法として例えば、

独自データをコンテキストとして与える
イベント駆動で自律的に動くエージェントにする
利用者の状況に合わせたUIを考える

などが挙げられていました。すべてを盛り込む必要はなく、どれか一つでも差別化できれば十分という点が現実的で良かったです。

このセッションが、「AIエージェントを一度作ってみよう」と思えるきっかけになりました。
非常に勉強になりました。

AgentCore BrowserとClaude Codeスキルを活用した『初手AI』を実現する業務自動化AIエージェント基盤

speakerdeck.com

登壇者（敬称略）：遠藤大介（株式会社ジェネラティブエージェンツ）

まず初めに雑感で言うと、このセッションは驚きの連続でした。

「初手AI 」～ビジネスイベントの一次処理をAIが担う～

本セッションでは、「初手AI」という考え方が紹介されました。
これは人間がAIエージェントにタスクを依頼するのではなく、AIエージェントが人間にタスクを依頼するという考え方です。従来は、人間が司令塔となりAIを補助的に使う構図でしたが、「初手AI」ではAIが主導してタスクを整理・実行し、人間は必要な場面だけに関与する、いわば人間を“リソース”として使う設計になっています。

この設計の狙いとしては、大きく2つ紹介されていました。

人間がボトルネックになる問題を根本から解消する
雑多な業務や下準備をAIに任せ、人間は最終判断や意思決定に集中できる状態を目指す

遠藤さんの会社では、この設計思想を具現化したシステムをコードネーム「タスクゼロ」と呼んでいました。

タスクゼロを支える技術構成

タスクゼロでは、Claude Code を汎用AIエージェントとして採用し、自然言語の業務マニュアルを専用スキルとして動かします。管理用WebやAIエージェントはすべてサーバーレス構成となっています。ただし、Claude Code 単体ではブラウザ操作ができないという制約があり、そこで導入したのが Amazon Bedrock AgentCore Browser です。初めて聞く機能でした...。