AIにどこまで任せる？実務で使える(かもしれない)AIエージェント設計の考え方

2025/06/18(水) KAGのLT会 #6 〜御社のエンジニア育成どうしてる!? スペシャル〜 での登壇資料です

Transcript

1. AIにどこまで任せる？ 実務で使える(かもしれない) AIエージェント設計の考え方 2025/06/18 (水) KAGのLT会 #6 ~御社のエンジニア育成どうしてる!?スペシャル~ 福地開
2. Who am I ? 福地 開 (ふくち はるき) @har1101mony 所属：NECソリューションイノベータ株式会社 年次：3年目 業務：インフラエンジニア、少しだけLLM触る人 活動：AWS Community Builders (AI Engineering)
3. 今日話すこと ◆AIエージェントシステムの設計について • AIエージェントの実装形式 • AIエージェントの評価 • AIエージェントの権限分離 • AIエージェントのエラーハンドリング ※AIエージェントそのものの話や、実際の構築方法などはお話しません ※資料中で「AI」と記載しているものは「生成AI」とりわけ「LLM」のことを指します ※所属組織とは一切関係ない、私個人の意見・考えとなります
4. AIエージェントの実装形式を考える
5. AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる
6. AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ！→完全自律型AIエージェント • そこまでは無理！→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか？ (全て任せますか？) 完全自律型 AIエージェント ワークフロー型 AIエージェント
7. AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ！→完全自律型AIエージェント • そこまでは無理！→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか？ (全て任せますか？) 完全自律型 AIエージェント ワークフロー型 AIエージェント ・目標だけをインプット ・手段はAIが考えて実行 ・性能がLLMに依存？ ・ある程度の流れが決まっている ・どこまで自由度を与えるかは 要件次第
8. AIエージェントって(ざっくり) 2種類あんねん ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ！→完全自律型AIエージェント • そこまでは無理！→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか？ (全て任せますか？) 完全自律型 AIエージェント ワークフロー型 AIエージェント Agentic Workflow 定義済み Workflow 参考：https://zenn.dev/pharmax/articles/d1d3695e4114c0
9. 設計ポイント①2種類のうち、どちらにするか？ ◆AIにどこまで任せるか次第で実装形式は変わる • エージェントに全て賭けろ！→完全自律型AIエージェント • そこまでは無理！→基本的にはワークフロー型AIエージェント ※完全な対立構造ではない。ワークフローの中に自律型を組み込むなども可能 エージェントに全て 賭けられますか？ (全て任せますか？) 完全自律型 AIエージェント ワークフロー型 AIエージェント Agentic Workflow 定義済み Workflow 参考：https://zenn.dev/pharmax/articles/d1d3695e4114c0 設計ポイント① どちらにするか？
10. AIエージェントの評価を考える
11. そもそも「評価」って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して…
12. そもそも「評価」って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解
13. そもそも「評価」って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による
14. そもそも「評価」って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による ◆評価：AIの回答において「何を正解とするか」を定める行為 • 人間側で「正解」を設定し、そこからどのくらい差が生じているかを 定性的・定量的に判断する必要がある • 回答に有害な内容やハルシネーションが含まれていないかをチェックする (責任あるAI)
15. そもそも「評価」って何？ ◆大前提：AIが生成した回答の正解は1つではない • (例)世界で一番高い山は？という問いに対して… AI「エベレストです」→正解 AI「ヒマラヤ山脈にあるエベレストです。その標高は8848mで〜」→正解 AI「1位はエベレスト、2位はK2、3位はカンチェンジュンガです」→正解 • だが、どの回答を求めているかは利用者による ◆評価：AIの回答において「何を正解とするか」を定める行為 • 人間側で「正解」を設定し、そこからどのくらい差が生じているかを 定性的・定量的に判断する必要がある • 回答に有害な内容やハルシネーションが含まれていないかをチェックする (責任あるAI) • 「評価は継続的な道のりである(Evals is a continuous journey)」
16. AIエージェントの評価は更に大変！？ ◆単なるLLMアプリであれば、回答を評価するだけでOK
17. AIエージェントの評価は更に大変！？ ◆単なるLLMアプリであれば、回答を評価するだけでOK ◆AIエージェントでは、エージェントの振る舞いも確認する必要あり • ツールを使うタイミングや回数は適切か？ • プラン作成や思考は正しく行えていたか？ • 検索クエリは適切だったか？ • 最終的に生成した回答は適切だったか？ etc…
18. AIエージェントの評価は更に大変！？ ◆単なるLLMアプリであれば、回答を評価するだけでOK ◆AIエージェントでは、エージェントの振る舞いも確認する必要あり • ツールを使うタイミングや回数は適切か？ • プラン作成や思考は正しく行えていたか？ • 検索クエリは適切だったか？ • 最終的に生成した回答は適切だったか？ etc… ◆自律的に動く部分が多いほど、評価が難しい • 全部AI自身で考えて動くため、性能を上げたければ 細かくチェックする必要がある(マルチエージェントの場合は…もっと大変！？) • ワークフロー型であれば、回答評価のみでOKなケースも
19. 評価方法って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
20. 評価方法って2種類あんねん ◆オフライン評価 • 用意した模範解答と、AIが出力した回答を照らし合わせる(できれば数値化) • プロンプト・モデル・パラメータなどを変更する前後で比較する • LLM as a Judge など、AI自身に回答を評価させる手法もある • MCP Server as a Judge も選択肢の1つ ◆オンライン評価 • 人間(特に利用者)が実際に使った上で結果を評価する • 簡単なもので言えば、Good/Bad • よりリアルなフィードバックを得られるので、可能な限り実施したい →結局、使う人間の感覚次第で良いか悪いかは決まる (コーディングエージェントにおいてベンチマークばかり見るのではなく 自分で試してみろ、と言われていることからも)
21. 設計ポイント②評価観点やスケジュールを考える ◆評価って設計段階から考えるの？ ◆考えておいたほうが良い • 少なくとも現状、LLMアプリは「リリースして終わり！」にはならない • 評価+改善のサイクル(LLMOps)が一生付き纏う(進化が早すぎる…) 実装 テスト 評価 改善
22. 設計ポイント②評価観点やスケジュールを考える ◆評価って設計段階から考えるの？ ◆考えておいたほうが良い • 少なくとも現状、LLMアプリは「リリースして終わり！」にはならない • 評価+改善のサイクル(LLMOps)が一生付き纏う(進化が早すぎる…) ◆具体的に「どうやって評価を行うか」も考えておく • 何を以て「正解」とするのか？ • 2種類ある評価手法をどのくらいの比率で行う？ • LLMOps用のツールは何か使う？ • お客様が利用するシステムを作る場合は、 精度向上のためのフィードバック協力を要請しておく 実装 テスト 評価 改善
23. AIエージェントの権限分離を考える
24. ツール実行権限をどこまで与えるのか？ ◆AIエージェントは、ツールがあってこそ真価を発揮する • ツールがあって初めて、AIはただ考えるだけではなく、 色んなものを参照したり操作したりできるようになる • MCPはツールの与え方を統一化したもの • どのツールをいつ使うか自分で判断する→自律型 • 使うツールとそのタイミングを人間が設定する→ワークフロー型
25. ツール実行権限をどこまで与えるのか？ ◆AIエージェントは、ツールがあってこそ真価を発揮する • ツールがあって初めて、AIはただ考えるだけではなく、 色んなものを参照したり操作したりできるようになる • MCPはツールの与え方を統一化したもの • どのツールをいつ使うか自分で判断する→自律型 • 使うツールとそのタイミングを人間が設定する→ワークフロー型 ◆AIエージェントに、ツール実行権限をどこまで与えるのか？ • コーディングエージェントによる、DBやフォルダ抹消事故を一時期散見 • 旅行エージェントに決済まで任せられるか？ • 在庫管理エージェントに発注まで任せられるか？ →これで事故が起こった時の責任の所在は？
26. 設計ポイント③ AIに与えるツールと権限 ◆1ツール1機能の原則 • なんでもできる汎用ツールではなく、1つの機能だけ持ったツールを与える • AIが使いやすいようなツール名・ツール説明を設定する(my-funcなどは控える)
27. 設計ポイント③ AIに与えるツールと権限 ◆1ツール1機能の原則 • なんでもできる汎用ツールではなく、1つの機能だけ持ったツールを与える • AIが使いやすいようなツール名・ツール説明を設定する(my-funcなどは控える) ◆AIとツールで権限を分離する • IAM、フレームワーク独自の認可機能などを用いる • AIとツールには最小権限を付与 →ツールを機能単位で分割できていれば、 権限も絞りやすい(はず)
28. 設計ポイント③ AIに与えるツールと権限 ◆1ツール1機能の原則 • なんでもできる汎用ツールではなく、1つの機能だけ持ったツールを与える • AIが使いやすいようなツール名・ツール説明を設定する(my-funcなどは控える) ◆AIとツールで権限を分離する • IAM、フレームワーク独自の認可機能などを用いる • AIとツールには最小権限を付与 →ツールを機能単位で分割できていれば、 権限も絞りやすい(はず、多分) ◆Human in the loop • 何か重大なアクションを行う際には、人間への確認を必須とする • 人間の判断を元にAIが動く形(AIだけに責任を負わせない)
29. AIエージェントの エラーハンドリングを考える
30. AIならではの追加考慮：APIレート制限 ◆分単位/日単位で利用可能なAPI利用上限値が決まっている • (例)1分あたりの最大リクエスト数：4,000 • (例)1分あたりの最大入力トークン数：200,000 • サービスにおいて1つのモデルだけを使うようにしていると、 アクセス過多の時にサービスが止まる可能性あり
31. 設計ポイント④ 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など
32. ◆AIエージェントシステムの設計について、お話しました • AIエージェントの実装形式 • AIエージェントの評価 • AIエージェントの権限分離 • AIエージェントのエラーハンドリング ◆いきなり全部やる必要はない！ 大事なのは、まず作ってみること！ ◆進化の速い領域なので、 引き続きキャッチアップ&シェアしていきましょう〜〜〜！ まとめ
33. 全人類読んでください！ https://speakerdeck.com/minorun365/ben-bu-chang-nodai-wariniti-an- shu-rebiyu-kddiying-ye-gamei-ri-shi-uaieziento-a-boss-kai-fa-mi-hua