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

by Har1101

Slide 1

Slide 1 text

AIエージェントの設計で注意するべきポイント6選 2025/12/20 (土) JAWS-UG Presents AI Builders Day 福地開

Slide 2

Slide 2 text

Who am I ? 福地開 (ふくちはるき) @har1101mony 所属：JAWS-UG東京/NECソリューションイノベータ年次：3年目業務：LLM Engineer 選出：AWS Community Builders (AI Engineering) 2025 Japan AWS Jr.Champions 2025 Japan All AWS Certifications Engineers

Slide 3

Slide 3 text

今日話すこと ◆LLM組み込みシステム・AIエージェントシステムの設計について • 私が作っているAIエージェント • Architecture • Build • Context • Domain • Evaluation • Fail-safe ※資料中で「AI」と記載しているものは「生成AI」とりわけ「LLM」のことを指します ※以降、LLM組み込みシステムを「AIエージェント」に含めます ※所属組織とは一切関係ない、私個人の意見・考えとなります

Slide 4

Slide 4 text

今日話すこと ◆LLM組み込みシステム・AIエージェントシステムの設計について • 私が作っているAIエージェント • Architecture・Context • Build・Evaluation・Fail-safe • Domain ※資料中で「AI」と記載しているものは「生成AI」とりわけ「LLM」のことを指します ※以降、LLM組み込みシステムを「AIエージェント」に含めます ※所属組織とは一切関係ない、私個人の意見・考えとなります

Slide 5

Slide 5 text

対象とレベル感 ◆本セッションの対象 • これからAIエージェントを構築していく(いきたい)方 • AI Builder入門者 ◆レベル感 • AWSのセッションレベルだと200-300の間くらい ※資料中で「AI」と記載しているものは「生成AI」とりわけ「LLM」のことを指します ※以降、LLM組み込みシステムを「AIエージェント」に含めます ※所属組織とは一切関係ない、私個人の意見・考えとなります

Slide 6

Slide 6 text

私が作っているAIエージェント • 私が作っているAIエージェント • Architecture・Context • Build・Evaluation・Fail-safe • Domain

Slide 7

Slide 7 text

私が作っているAIエージェント ◆レポート生成エージェント ◆セキュリティレビューエージェント ◆アウトプット集約エージェント ◆英会話練習エージェント(草案のみ) ※当然すべてAWS環境上で動いて(動かそうとして)います

Slide 8

Slide 8 text

レポート生成エージェント ◆Step Functions×BedrockでAIワークフローを構築 • Input：DB内のデータ • Output：月次レポート ◆設計構築運用を担当 ◆現在本番環境で稼働中 • これから評価・改善へ

Slide 9

Slide 9 text

セキュリティレビューエージェント ◆構築したAWS環境のセキュリティチェックを行うエージェント ◆今週リリース • 社内で稼働中 • これから評価と改善へ • AgentCoreや S3 Vectorsへのリプレイスも実施中 ◆設計構築運用を担当

Slide 10

Slide 10 text

アウトプット集約エージェント(個人開発) ◆個人のアウトプットを集約してフィードバックするエージェント • Strands Graphを活用 • Ambient Agent風 • プロトタイプ完成、これからブラッシュアップ

Slide 11

Slide 11 text

私が作っているAIエージェント ◆レポート生成エージェント ◆セキュリティレビューエージェント ◆アウトプット集約エージェント ◆英会話練習エージェント(草案のみ) ※当然すべてAWS環境上で動いて(動かそうとして)います ◆ちょこちょこエージェントを作ってきた中での知見・学びなどを共有させていただきます！

Slide 12

Slide 12 text

Architecture・Context ✓ 私が作っているAIエージェント • Architecture・Context • Build・Evaluation・Fail-safe • Domain

Slide 13

Slide 13 text

AIエージェントのアーキテクチャ ◆アーキテクチャは大きく2種類存在 • Anthropic社のブログ「Building Effective Agents」→ ◆エージェントは、LLM が独自のプロセスとツールの使用を動的に指示し、タスクの達成方法を制御するシステムです。 ◆ワークフローは、LLM とツールが事前定義されたコードパスを通じてオーケストレーションされるシステムです。 ◆ここでは少し表現を変えて、以下のように記載 • エージェント→自律型エージェント • ワークフロー→ワークフロー型エージェント

Slide 14

Slide 14 text

自律型エージェント ◆計画作成・ツール実行・振り返りのループを自律的に繰り返す • AWSの言葉を借りると Agent Loop • LLMが処理全体を統制するので、良く言えば柔軟・悪く言えば不安定 • AWS上ではStrands Agents SDKで実現するのが主流

Slide 15

Slide 15 text

ワークフローエージェント ◆事前に定義したとおりに処理を実行し、その中でLLMが動く • 処理のオーケストレーターは事前に定義済み • 良く言えば安定して処理可能、悪く言えば柔軟性がない • AWS上ではStep Functions×Bedrockや、Bedrock Flowで実現可能 • エージェンティックワークフローというのもある

Slide 16

Slide 16 text

エージェンティックワークフロー ◆ワークフローの中で自律型エージェントが動くイメージ • 処理のオーケストレーターはワークフロー • その中で一部、LLMによる分岐処理や判定処理があったりする • AWS上ではStep Functions×BedrockでもStrands Agents SDKでも可能

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

アーキテクチャとコンテキストエンジニアリング ◆コンテキスト：LLMに与える情報全体を指す言葉 • ただし一気に情報を与えすぎるとLLM側がパンクする画像引用: https://www.philschmid.de/context-engineering

Slide 20

Slide 20 text

アーキテクチャとコンテキストエンジニアリング ◆コンテキスト：LLMに与える情報全体を指す言葉 • ただし一気に情報を与えすぎるとLLM側がパンクする ◆コンテキストエンジニアリング • 必要なデータを必要なだけ、必要なタイミングでLLMに与えるようにコントロールする行為画像引用: https://www.philschmid.de/context-engineering

Slide 21

Slide 21 text

Slide 22

Slide 22 text

コンテキストの構成要素 ◆システムプロンプト: 会話中のモデルの動作を定義する最初の一連の指示 ◆ユーザープロンプト: ユーザーからの入力内容 ◆短期記憶: ユーザーとモデルの会話履歴 ◆長期記憶: 過去の会話から収集されたナレッジベースやり取りの内容をコンパクトにして保持する(例: ユーザーの好み、過去のプロジェクトの概要、将来の使用のために記憶するように指示された事柄など) ◆外部情報: 特定の質問に答えるためにドキュメント・データベース・ APIなどから取得した外部の関連情報 ◆ツール: 利用できるすべてのツールの定義(例: current_time、send_email) 特にツールの名前と説明を指す ◆構造化出力: モデルの応答の形式の定義 (例: JSON オブジェクト) 引用: https://www.philschmid.de/context-engineering

Slide 23

Slide 23 text

コンテキストの構成要素 ◆システムプロンプト: 会話中のモデルの動作を定義する最初の一連の指示 ◆ユーザープロンプト: ユーザーからの入力内容 ◆短期記憶: ユーザーとモデルの会話履歴 ◆長期記憶: 過去の会話から収集されたナレッジベースやり取りの内容をコンパクトにして保持する(例: ユーザーの好み、過去のプロジェクトの概要、将来の使用のために記憶するように指示された事柄など) ◆外部情報: 特定の質問に答えるためにドキュメント・データベース・ APIなどから取得した外部の関連情報 ◆ツール: 利用できるすべてのツールの定義(例: current_time、send_email) 特にツールの名前と説明を指す ◆構造化出力: モデルの応答の形式の定義 (例: JSON オブジェクト) ◆外部情報のコンテキスト取得方法を考える(他は後述) 引用: https://www.philschmid.de/context-engineering

Slide 24

Slide 24 text

エージェントが外部情報を取得するには ◆大きく2つの方法がある 1. エージェント自身が自ら取得する 2. 事前にプログラムなどで取得し、その後エージェントへインプットする

Slide 25

Slide 25 text

エージェントが外部情報を取得するには ◆大きく2つの方法がある 1. エージェント自身が自ら取得する 2. 事前にプログラムなどで取得し、その後エージェントへインプットする ◆この方法がアーキテクチャ決定に繋がる • 必要な情報をすべてエージェント自身が取得する場合は、自律型 • 外部から必要な情報を与える仕組みにする場合は、ワークフロー型

Slide 26

Slide 26 text

余談：その他のコンテキスト構成要素 ◆外部情報以外のコンテキスト構成要素は、エージェント自身は取得できない ◆システムプロンプト: 開発者がエージェントに設定する ◆ユーザープロンプト: ユーザーの入力をエージェントにインプットする ◆短期/長期記憶: 開発者がエージェントのメモリー用DBを設定する ◆ツール: 開発者がエージェントに設定する ◆構造化出力: 開発者がエージェントに設定する引用: https://www.philschmid.de/context-engineering

Slide 27

Slide 27 text

参考：私の場合 1. 取得すべき外部情報が、入力次第で異なる場合 →自律型 2. 取得すべき外部情報が、ある程度わかっている場合 →ワークフロー型

Slide 28

Slide 28 text

参考：私の場合 1. 取得すべき外部情報が、入力次第で異なる場合 →自律型 2. 取得すべき外部情報が、ある程度わかっている場合 →ワークフロー型コンテキスト(外部情報)の取得プロセスを考えると、アーキテクチャが見えてくる！

Slide 29

Slide 29 text

アーキテクチャに最適解はない ◆業務で使うならワークフロー or エージェンティックワークフロー派 • ただ、すべてを0から構築し運用・改善していくのは大変！ • 後から入力値が増えた際のコード修正も大変 ◆Strandsチームとしてはモデル駆動エージェント • 「全体のオーケストレートに手間を掛けるべきではない、LLMに任せよう」 • とはいえ実業務で不確定要素(=LLMの判断)が増えるのは足踏みしてしまう ◆現状の大方針としては、 • コンテキストベースで考える • エージェントに対して何をインプットし、どんなことをして、何をアウトプットしてもらいたいかを考え、定義する

Slide 30

Slide 30 text

Build・Evaluation・Fail-safe ✓ 私が作っているAIエージェント ✓ Architecture・Context • Build・Evaluation・Fail-safe • Domain

Slide 31

Slide 31 text

LLMOpsまで見据えた構築方法を考える ◆大前提：ユースケースや開発チームのスキルセットを優先 • チャットアプリでストリーミングレスポンスできない構成にするのはダメ

Slide 32

Slide 32 text

LLMOpsまで見据えた構築方法を考える ◆大前提：ユースケースや開発チームのスキルセットが大事 • チャットアプリでストリーミングレスポンスできない構成にするのはダメ ◆その上で、LLMOps(評価・改善)まで見据えた技術選定が重要 • 普通のアプリケーションの運用とは似て非なる世界 • 私の場合、設計・構築(評価の仕組みづくり含む)は自分の担当だが、実運用は別チームが実施する、というケースがある • この時は、運用チームのスキルセットも考慮しておく必要がある

Slide 33

Slide 33 text

Build: どうやってエージェントを動かす？ ◆エージェントの構築方法 • フレームワークを使う(Strands Agents SDK, LangGraph, Mastra…) • AWS SDKを使う(Converse API) • Bedrock Agentsを使う(最近あまりアップデートされていない…) ◆AWSへのデプロイ方法 • Bedrock AgentCore Runtime • Lambda • ECS/EKS • Step Functions/Lambda Durable Function ◆自分たちのチーム事情・要件に合わせて選ぶ • 判断するためにも、好奇心を持って触ってみることが重要

Slide 34

Slide 34 text

Evaluation: 評価って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して…

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Evaluation: 評価って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による ◆評価：AIの回答において「何を正解とするか」を定める行為 • 人間側で「正解」を設定し、そこからどのくらい差が生じているかを定性的・定量的に判断する必要がある • 回答に有害な内容やハルシネーションが含まれていないかをチェックする (責任あるAI)

Slide 38

Slide 38 text

Slide 39

Slide 39 text

自律型エージェントの評価は更に大変！？ ◆シンプルなワークフローであれば、回答を評価するだけでOK

Slide 40

Slide 40 text

Slide 41

Slide 41 text

自律型エージェントの評価は更に大変！？ ◆シンプルなワークフローであれば、回答を評価するだけでOK ◆自律型エージェントでは、エージェントの振る舞いも評価しよう • ツールを使うタイミングや回数は適切か？ • プラン作成や思考は正しく行えていたか？ • 検索クエリは適切だったか？ • 最終的に生成した回答は適切だったか？ etc… ◆自律的に動く部分が多いほど、評価が難しい • 全部エージェント自身で考えて動くため、性能を上げたければ細かくチェックする必要がある(マルチエージェントの場合は…もっと大変！？)

Slide 42

Slide 42 text

2種類の評価方法 ◆オフライン評価 • 用意した模範解答と、AIが出力した回答を照らし合わせる • プロンプト・モデル・パラメータなどを変更する前後で比較する • LLM as a Judge など、AI自身に回答を評価させる手法もある • MCP Server as a Judge も選択肢の1つ https://speakerdeck.com/pharma_x_tech/llmapurikesiyonnoping-jia-toji-sok-de-gai-shan https://speakerdeck.com/licux/mcp-server-as-a-judge

Slide 43

Slide 43 text

2種類の評価方法 ◆オフライン評価 • 用意した模範解答と、AIが出力した回答を照らし合わせる(できれば数値化) • プロンプト・モデル・パラメータなどを変更する前後で比較する • LLM as a Judge など、AI自身に回答を評価させる手法もある • MCP Server as a Judge も選択肢の1つ ◆オンライン評価 • 人間(特に利用者)が実際に使った上で結果を評価する(Good/Badなど) • AgentCore EvaluationsはLLMでのオンライン評価が可能 • よりリアルなフィードバックを得られるので、可能な限り実施したい →結局、使う人間の感覚次第で良いか悪いかは決まる (コーディングエージェントにおいてベンチマークばかり見るのではなく自分で試してみろ、と言われていることからも)

Slide 44

Slide 44 text

LLMOpsを見据えて設計する ◆評価は設計段階から考えておく必要がある • 少なくとも現状、エージェントは「リリースして終わり！」にはならない • 評価+改善のサイクル(LLMOps)が一生付き纏う実装テスト評価改善

Slide 45

Slide 45 text

LLMOpsを見据えて設計する ◆評価は設計段階から考えておく必要がある • 少なくとも現状、エージェントは「リリースして終わり！」にはならない • 評価+改善のサイクル(LLMOps)が一生付き纏う ◆具体的に「どうやって評価を行うか」も考えておく • 何をもって「正解」とするのか？ • 2種類ある評価手法をどのくらいの比率で行う？ • LLMOps用のツールは何か使う？ • お客様環境用のエージェントを作る場合は、精度向上のためのフィードバック協力を要請しておく実装テスト評価改善

Slide 46

Slide 46 text

Fail-safe: LLMならではのエラーハンドリング ◆分単位/日単位で利用可能なAPI利用上限値が決まっている • (例)1分あたりの最大リクエスト数：4,000 • (例)1分あたりの最大入力トークン数：200,000 • インフラではなくLLM側の原因で、アクセス過多の時にエージェントが止まる可能性あり

Slide 47

Slide 47 text

Fail-safe: LLMならではのエラーハンドリング ◆方針1. リトライ処理を入れておく • Strands Agents SDKはデフォルトで自動リトライ処理が実装されている • 自分で設定する場合は、指数バックオフでのリトライなどを用いる ◆方針2. 複数のモデルを複数の方法で使用できるようにする • Bedrock API、Anthropic API、Vertex AI APIを利用する • フェイルオーバー用セカンダリモデルを用意する(Sonnet 4.5→Haiku 4.5)

Slide 48

Slide 48 text

エージェント開発ならではのプラクティスがある ◆エージェントはWebアプリケーションだが、普通のWebアプリケーションのように作るわけではない • 独自のプラクティスが存在する • 未だ発展途上の領域 ◆まずは手を動かしてみることが重要 • フレームワークを使えば簡単にエージェントを作ることができる • AWS CDKやCLIを用いたデプロイ手順もたくさん用意されている • 試す中で、評価の勘所や考えるべきエラーハンドリングも見えてくる

Slide 49

Slide 49 text

Domain ✓ 私が作っているAIエージェント ✓ Architecture・Context ✓ Build・Evaluation・Fail-safe • Domain

Slide 50

Slide 50 text

Domain: 特化・独自エージェントを作るべし ◆エージェントを作る際は以下を自問自答してみる • そのエージェントは、どんな作業を代替してくれるのか？ • その役割はChatGPTやClaude Desktopではダメなのか？ ◆GPTやClaudeではできないことをやらせよう • エージェント自身の独自性や、プロダクトとしての独自性を見据えておく • せっかく作っても「それ〇〇でいいじゃん」となると使われない

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Domain: 特化・独自エージェントを作るべし ◆独自データをコンテキストとして与える • RAGに始まり、現在はToolUse/MCPなどで簡単にデータを活用できる ◆イベント駆動・スケジュール駆動で動かす • Ambient Agent(より環境に溶け込んだエージェント)に本気で取り組む ◆Chat UIにこだわらない • 利用者が常にPC前にいてタイピングするとは限らない • 音声を用いる方が有用なケースも ◆難しく考えすぎなくてOK！ GPT/Claudeとの差別化点を1つ考えよう

Slide 53

Slide 53 text

◆エージェントの設計について6つの要素を凝縮してお伝えしました • Architecture • Build • Context • Domain • Evaluation • Fail-safe ◆日々プラクティスが更新される領域だからこそ経験値を貯めていくことが重要 ◆設計で悩みすぎると進めない、ベストプラクティスを待っていると時代に取り残される ◆Now, go build! まとめ