Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIにどこまで任せる?実務で使える(かもしれない)AIエージェント設計の考え方
Search
Har1101
June 18, 2025
Technology
3
1.4k
AIにどこまで任せる?実務で使える(かもしれない)AIエージェント設計の考え方
2025/06/18(水) KAGのLT会 #6 〜御社のエンジニア育成どうしてる!? スペシャル〜 での登壇資料です
Har1101
June 18, 2025
Tweet
Share
More Decks by Har1101
See All by Har1101
私たちはなぜAWS Summitに参加するのか?
har1101
1
360
Bedrockのプロンプト管理どうしてる?
har1101
6
610
Ambient Agent on AWS!
har1101
3
480
Bedrockエージェントにおける MCP利用ケースについて考えてみる
har1101
4
450
AWS上でMCPを安全に使いたい ~Mastraを添えて~
har1101
7
1.7k
Bedrock×MCPで社内ブログ執筆文化を育てたい!
har1101
7
2.1k
Amazon Bedrock Agentsのマルチエージェント機能で競馬予想アプリ作ってみた!
har1101
5
920
re:Inventのアップデートを使ってRAGアプリ開発とRAGOpsに入門してみた!
har1101
1
340
BedrockのナレッジベースとLlamaIndexでGraphRAGを作って精度比較してみた!
har1101
3
500
Other Decks in Technology
See All in Technology
AI専用のリンターを作る #yumemi_patch
bengo4com
5
4.1k
ゼロからはじめる採用広報
yutadayo
1
230
Connect 100+を支える技術
kanyamaguc
0
190
What’s new in Android development tools
yanzm
0
190
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
160
論文紹介:LLMDet (CVPR2025 Highlight)
tattaka
0
300
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
260
本が全く読めなかった過去の自分へ
genshun9
0
880
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
2
18k
LangChain Interrupt & LangChain Ambassadors meetingレポート
os1ma
2
290
AWS認定を取る中で感じたこと
siromi
1
170
Delta airlines Customer®️ USA Contact Numbers: Complete 2025 Support Guide
deltahelp
0
310
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
94
6.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Become a Pro
speakerdeck
PRO
28
5.4k
Adopting Sorbet at Scale
ufuk
77
9.4k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
The Cult of Friendly URLs
andyhume
79
6.5k
Statistics for Hackers
jakevdp
799
220k
A better future with KSS
kneath
239
17k
Testing 201, or: Great Expectations
jmmastey
42
7.6k
Stop Working from a Prison Cell
hatefulcrawdad
270
21k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Typedesign – Prime Four
hannesfritz
42
2.7k
Transcript
AIにどこまで任せる? 実務で使える(かもしれない) AIエージェント設計の考え方 2025/06/18 (水) KAGのLT会 #6 ~御社のエンジニア育成どうしてる!?スペシャル~ 福地開
Who am I ? 福地 開 (ふくち はるき) @har1101mony 所属:NECソリューションイノベータ株式会社
年次:3年目 業務:インフラエンジニア、少しだけLLM触る人 活動:AWS Community Builders (AI Engineering)
今日話すこと ◆AIエージェントシステムの設計について • AIエージェントの実装形式 • AIエージェントの評価 • AIエージェントの権限分離 • AIエージェントのエラーハンドリング
※AIエージェントそのものの話や、実際の構築方法などはお話しません ※資料中で「AI」と記載しているものは「生成AI」とりわけ「LLM」のことを指します ※所属組織とは一切関係ない、私個人の意見・考えとなります
AIエージェントの実装形式を考える
AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる
AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ!→完全自律型AIエージェント • そこまでは無理!→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか?
(全て任せますか?) 完全自律型 AIエージェント ワークフロー型 AIエージェント
AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ!→完全自律型AIエージェント • そこまでは無理!→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか?
(全て任せますか?) 完全自律型 AIエージェント ワークフロー型 AIエージェント ・目標だけをインプット ・手段はAIが考えて実行 ・性能がLLMに依存? ・ある程度の流れが決まっている ・どこまで自由度を与えるかは 要件次第
AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ!→完全自律型AIエージェント • そこまでは無理!→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか?
(全て任せますか?) 完全自律型 AIエージェント ワークフロー型 AIエージェント Agentic Workflow 定義済み Workflow 参考:https://zenn.dev/pharmax/articles/d1d3695e4114c0
設計ポイント①2種類のうち、どちらにするか? ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ!→完全自律型AIエージェント • そこまでは無理!→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか? (全て任せますか?)
完全自律型 AIエージェント ワークフロー型 AIエージェント Agentic Workflow 定義済み Workflow 参考:https://zenn.dev/pharmax/articles/d1d3695e4114c0 設計ポイント① どちらにするか?
AIエージェントの評価を考える
そもそも「評価」って何? ◆大前提:AIが生成した回答の正解は1つではない • (例)世界で一番高い山は?という問いに対して…
そもそも「評価」って何? ◆大前提:AIが生成した回答の正解は1つではない • (例)世界で一番高い山は?という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解
そもそも「評価」って何? ◆大前提:AIが生成した回答の正解は1つではない • (例)世界で一番高い山は?という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による
そもそも「評価」って何? ◆大前提:AIが生成した回答の正解は1つではない • (例)世界で一番高い山は?という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による ◆評価:AIの回答において「何を正解とするか」を定める行為
• 人間側で「正解」を設定し、そこからどのくらい差が生じているかを 定性的・定量的に判断する必要がある • 回答に有害な内容やハルシネーションが含まれていないかをチェックする (責任あるAI)
そもそも「評価」って何? ◆大前提:AIが生成した回答の正解は1つではない • (例)世界で一番高い山は?という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による ◆評価:AIの回答において「何を正解とするか」を定める行為
• 人間側で「正解」を設定し、そこからどのくらい差が生じているかを 定性的・定量的に判断する必要がある • 回答に有害な内容やハルシネーションが含まれていないかをチェックする (責任あるAI) • 「評価は継続的な道のりである(Evals is a continuous journey)」
AIエージェントの評価は更に大変!? ◆単なるLLMアプリであれば、回答を評価するだけでOK
AIエージェントの評価は更に大変!? ◆単なるLLMアプリであれば、回答を評価するだけでOK ◆AIエージェントでは、エージェントの振る舞いも確認する必要あり • ツールを使うタイミングや回数は適切か? • プラン作成や思考は正しく行えていたか? • 検索クエリは適切だったか? •
最終的に生成した回答は適切だったか? etc…
AIエージェントの評価は更に大変!? ◆単なるLLMアプリであれば、回答を評価するだけでOK ◆AIエージェントでは、エージェントの振る舞いも確認する必要あり • ツールを使うタイミングや回数は適切か? • プラン作成や思考は正しく行えていたか? • 検索クエリは適切だったか? •
最終的に生成した回答は適切だったか? etc… ◆自律的に動く部分が多いほど、評価が難しい • 全部AI自身で考えて動くため、性能を上げたければ 細かくチェックする必要がある(マルチエージェントの場合は…もっと大変!?) • ワークフロー型であれば、回答評価のみでOKなケースも
評価方法って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
評価方法って2種類あんねん ◆オフライン評価 • 用意した模範解答と、AIが出力した回答を照らし合わせる(できれば数値化) • プロンプト・モデル・パラメータなどを変更する前後で比較する • LLM as a
Judge など、AI自身に回答を評価させる手法もある • MCP Server as a Judge も選択肢の1つ ◆オンライン評価 • 人間(特に利用者)が実際に使った上で結果を評価する • 簡単なもので言えば、Good/Bad • よりリアルなフィードバックを得られるので、可能な限り実施したい →結局、使う人間の感覚次第で良いか悪いかは決まる (コーディングエージェントにおいてベンチマークばかり見るのではなく 自分で試してみろ、と言われていることからも)
設計ポイント②評価観点やスケジュールを考える ◆評価って設計段階から考えるの? ◆考えておいたほうが良い • 少なくとも現状、LLMアプリは「リリースして終わり!」にはならない • 評価+改善のサイクル(LLMOps)が一生付き纏う(進化が早すぎる…) 実装 テスト 評価
改善
設計ポイント②評価観点やスケジュールを考える ◆評価って設計段階から考えるの? ◆考えておいたほうが良い • 少なくとも現状、LLMアプリは「リリースして終わり!」にはならない • 評価+改善のサイクル(LLMOps)が一生付き纏う(進化が早すぎる…) ◆具体的に「どうやって評価を行うか」も考えておく • 何を以て「正解」とするのか?
• 2種類ある評価手法をどのくらいの比率で行う? • LLMOps用のツールは何か使う? • お客様が利用するシステムを作る場合は、 精度向上のためのフィードバック協力を要請しておく 実装 テスト 評価 改善
AIエージェントの権限分離を考える
ツール実行権限をどこまで与えるのか? ◆AIエージェントは、ツールがあってこそ真価を発揮する • ツールがあって初めて、AIはただ考えるだけではなく、 色んなものを参照したり操作したりできるようになる • MCPはツールの与え方を統一化したもの • どのツールをいつ使うか自分で判断する→自律型 •
使うツールとそのタイミングを人間が設定する→ワークフロー型
ツール実行権限をどこまで与えるのか? ◆AIエージェントは、ツールがあってこそ真価を発揮する • ツールがあって初めて、AIはただ考えるだけではなく、 色んなものを参照したり操作したりできるようになる • MCPはツールの与え方を統一化したもの • どのツールをいつ使うか自分で判断する→自律型 •
使うツールとそのタイミングを人間が設定する→ワークフロー型 ◆AIエージェントに、ツール実行権限をどこまで与えるのか? • コーディングエージェントによる、DBやフォルダ抹消事故を一時期散見 • 旅行エージェントに決済まで任せられるか? • 在庫管理エージェントに発注まで任せられるか? →これで事故が起こった時の責任の所在は?
設計ポイント③ AIに与えるツールと権限 ◆1ツール1機能の原則 • なんでもできる汎用ツールではなく、1つの機能だけ持ったツールを与える • AIが使いやすいようなツール名・ツール説明を設定する(my-funcなどは控える)
設計ポイント③ AIに与えるツールと権限 ◆1ツール1機能の原則 • なんでもできる汎用ツールではなく、1つの機能だけ持ったツールを与える • AIが使いやすいようなツール名・ツール説明を設定する(my-funcなどは控える) ◆AIとツールで権限を分離する • IAM、フレームワーク独自の認可機能などを用いる
• AIとツールには最小権限を付与 →ツールを機能単位で分割できていれば、 権限も絞りやすい(はず)
設計ポイント③ AIに与えるツールと権限 ◆1ツール1機能の原則 • なんでもできる汎用ツールではなく、1つの機能だけ持ったツールを与える • AIが使いやすいようなツール名・ツール説明を設定する(my-funcなどは控える) ◆AIとツールで権限を分離する • IAM、フレームワーク独自の認可機能などを用いる
• AIとツールには最小権限を付与 →ツールを機能単位で分割できていれば、 権限も絞りやすい(はず、多分) ◆Human in the loop • 何か重大なアクションを行う際には、人間への確認を必須とする • 人間の判断を元にAIが動く形(AIだけに責任を負わせない)
AIエージェントの エラーハンドリングを考える
AIならではの追加考慮:APIレート制限 ◆分単位/日単位で利用可能なAPI利用上限値が決まっている • (例)1分あたりの最大リクエスト数:4,000 • (例)1分あたりの最大入力トークン数:200,000 • サービスにおいて1つのモデルだけを使うようにしていると、 アクセス過多の時にサービスが止まる可能性あり
設計ポイント④ AIの冗長化 ◆方針1. 複数のモデルを切り替える • メインモデルとバックアップモデルを用意しておく • Claude Sonnet 4
→ Claude Sonnet 3.7(精度を犠牲にする可能性がある) ◆方針2. 同じモデルを複数の方法で使用できるようにする • Claude Sonnet 4を色んな方法で呼び出す • Bedrock API、Anthropic API、Vertex AI APIを利用するなど ◆方針3. プロンプトルーティング • 質問内容に応じて利用するモデルを自動で振り分ける • 複雑な質問にはClaude Sonnet 4、簡単な質問にはClaude Haiku 3.5など
◆AIエージェントシステムの設計について、お話しました • AIエージェントの実装形式 • AIエージェントの評価 • AIエージェントの権限分離 • AIエージェントのエラーハンドリング ◆いきなり全部やる必要はない!
大事なのは、まず作ってみること! ◆進化の速い領域なので、 引き続きキャッチアップ&シェアしていきましょう〜〜〜! まとめ
全人類読んでください! https://speakerdeck.com/minorun365/ben-bu-chang-nodai-wariniti-an- shu-rebiyu-kddiying-ye-gamei-ri-shi-uaieziento-a-boss-kai-fa-mi-hua