「OutputOps」なエージェントを作りたかった… ~エージェント開発Tipsを添えて~

9/27(土) JAWS-UG 茨城 #7 JAWS FESTA2025 CfP･LT供養祭りの登壇資料です

Transcript

1. 「OutputOps」なエージェントを… 作りたかった… ~エージェント開発Tipsを添えて~ 2025/09/27 (土) JAWS-UG 茨城 #7 JAWS FESTA2025 CfP･LT供養祭り 福地開
2. Who am I ? 福地 開 (ふくち はるき) @har1101mony 所属：NECソリューションイノベータ株式会社 年次：3年目 業務：LLMで遊ぶだけ 選出：AWS Community Builders (AI Engineering) 2025 Japan AWS Jr.Champions 2025 Japan All AWS Certifications Engineers
3. 今日話すこと ◆私が作っている、「OutputOpsエージェント」とは？ • よくある悩み • OutputOpsエージェントとは • プロダクトとしての設計思想 ◆アーキテクチャ • AWSとしてのアーキテクチャ • AIエージェントにおける処理フロー ◆実装で難しかったところ&エージェント開発のTips ※資料中で「AI」と記載しているものは「生成AI」とりわけ「LLM」のことを指します ※所属組織とは一切関係ない、私個人の意見・考えとなります ※AIエージェントとは、みたいな基礎基本の話は省略しております。すみません。
4. JAWS界隈の人たちは アウトプット熱が高い！！
5. ただ、そのアウトプット、 どのくらい振り返り・改善 できていますか…？ (私は全く振り返ってないです)
6. 振り返りは大事 ◆振り返りの軸その1：自身のアウトプット歴 • 何か目標があるとして、自分が今どこまでできているのかを振り返る • 今月は何件ブログ書いて、何回登壇して、聴講者何人で…な感じ ◆振り返りの軸その2：アウトプット内容のフィードバック • 技術ブログ/登壇資料の内容がどうだったのか、聴講者の学びになったのか • 人から直接貰う+今ならLLMからも貰える
7. 振り返りは大事 ◆振り返りの軸その1：自身のアウトプット歴 • 何か目標があるとして、自分が今どこまでできているのかを振り返る • 今月は何件ブログ書いて、何回登壇して、聴講者何人で…な感じ ◆振り返りの軸その2：アウトプット内容のフィードバック • 技術ブログ/登壇資料の内容がどうだったのか、聴講者の学びになったのか • 人から直接貰う+今ならLLMからも貰える
8. 振り返りは大事 ◆振り返りの軸その1：自身のアウトプット歴 • 何か目標があるとして、自分が今どこまでできているのかを振り返る • 今月は何件ブログ書いて、何回登壇して、聴講者何人で…な感じ ◆振り返りの軸その2：アウトプット内容のフィードバック • 技術ブログ/登壇資料の内容がどうだったのか、聴講者の学びになったのか • 人から直接貰う+今ならLLMからも貰える
9. 振り返りは大事 ◆振り返りの軸その1：自身のアウトプット歴 • 何か目標があるとして、自分が今どこまでできているのかを振り返る • 今月は何件ブログ書いて、何回登壇して、聴講者何人で…な感じ ◆振り返りの軸その2：アウトプット内容のフィードバック • 技術ブログ/登壇資料の内容がどうだったのか、聴講者の学びになったのか • 人から直接貰う+今ならLLMからも貰える https://github.com/minorun365/aws-level-checker
10. 振り返りは大事、とはいえ面倒くさい… ◆アウトプット履歴をまとめたり、フィードバック集めて改善したり する暇があったら次のアウトプットに向けて準備をしたい… ◆ただ、この履歴・フィードバック収集が避けられないこともある • 社内の報告向け • Community Builders/Top Engineersなどの表彰応募 • (特殊)Jr.Champions内でも定期的にアウトプットの報告が必要
11. 振り返りは大事、とはいえ面倒くさい… ◆アウトプット履歴をまとめたり、フィードバック集めて改善したり する暇があったら次のアウトプットに向けて準備をしたい… ◆ただ、この履歴・フィードバック収集が避けられないこともある • 社内の報告向け • Community Builders/Top Engineersなどの表彰応募 • (特殊)Jr.Champions内でも定期的にアウトプットの報告が必要 ◆「差別化されない重労働」 • AWS(もといサーバーレス)の思想に則れば、改善するべきポイント • GPT-5 Thinkingにやらせると、しっちゃかめっちゃかな内容が返ってきた
12. じゃあOutputOps Agent 作るか…
13. プロダクト設計：設計思想 ◆作りたいもの： アウトプットの保存・フィードバックなどを自動で行ってくれる AIエージェント
14. プロダクト設計：設計思想 ◆作りたいもの： アウトプットの保存・フィードバックなどを自動で行ってくれる AIエージェント ◆絶対にデータの格納に手間を掛けたくない！！！ • (前提：AIエージェントはデータが有って初めて真価を発揮する) • わざわざ専用のアンケートフォームやWebアプリを作っても開くのが億劫 • できるだけデータ格納のハードルを下げたい →毎日自然とアクセスする場所で、URLだけ貼り付ければOK、が理想 ◆複数人や組織、コミュニティでも使えるようにしたい • 自分だけのアウトプット履歴を蓄えるなら、既存のAIチャットで十分 • アウトプットは他人に共有すると更に有意義なもの
15. プロダクト設計：作っているもの ◆アウトプットのリンクをSlackに投げるだけで、記録完了 • アウトプット履歴を記録(日付、投稿者、内容…) • レベル判定などのフィードバックも実施 ブログ書いたで！ https://blog.com/~ りょ
16. プロダクト設計：作っているもの ◆アウトプットのリンクをSlackに投げるだけで、記録完了 • アウトプット履歴を記録(日付、投稿者、内容…) • レベル判定などのフィードバックも実施 • Slackならスケールしやすい、組織やコミュニティでも使える ワイも書いたで！ https://blog.com/- りょ
17. プロダクト設計：作っているもの ◆とはいえSlackにそんな便利機能はない どうしろと…
18. プロダクト設計：作っているもの ◆とはいえSlackにそんな便利機能はない ◆無いならAIエージェント作れば良いじゃない！ AIエージェントくん 頼んだ！ おｋ さんきゅー
19. プロダクト設計：作っているもの ◆保存だけじゃなく、振り返りもしたい 8月は5件やね 2025年単位で見ると 一番多いで！ 先月何個ブログ 書いたっけ？
20. プロダクト設計：作っているもの ◆保存だけじゃなく、振り返りもしたい ◆社内報告・表彰応募時のレポート叩き台も作ってほしい！！！ 1年でブログ300件、 登壇50回してるで カテゴリーどうする？ CB申し込むから この1年のアウト プット内容まとめて
21. プロダクト設計：作っているもの ◆保存だけじゃなく、振り返りもしたい ◆社内報告・表彰応募時のレポート叩き台も作ってほしい！！！ 関連するブログが60件、登壇が10件やな じゃあ申し込み文考えるわ〜 じゃあAI Engineeringで
22. 作るAIエージェントのイメージ 1. アウトプット格納エージェント • Slackのメッセージを取得する • メッセージ内のURLを元に、Web検索を行う • 取得した内容を元に、フィードバック文とレベル判定を考える • 諸々のデータをデータベースに格納する • 投稿者にフィードバックを返す 2. アウトプットに関する質問受付エージェント(Agentic RAG的な) • アウトプット履歴の参照 • 年単位・月単位でのフィードバック作成 • 表彰申込時の叩き台作成
23. 作るAIエージェントのイメージ 1. アウトプット格納エージェント(まだこっちしか喋れません…) • Slackのメッセージを取得する • メッセージ内のURLを元に、Web検索を行う • 取得した内容を元に、フィードバック文とレベル判定を考える • 諸々のデータをデータベースに格納する • 投稿者にフィードバックを返す 2. アウトプットに関する質問受付エージェント(Agentic RAG的な) • アウトプット履歴の参照 • 年単位・月単位でのフィードバック作成 • 表彰申込時の叩き台作成
24. アーキテクチャ
25. アーキテクチャ
26. アーキテクチャ ・エージェントは定期実行させたい ・ただ、EventBridgeからAgentCoreを 直接実行できない ・EventBridgeはオーケストレーター Lambdaを起動するだけ
27. アーキテクチャ ・Slack APIで特定のチャンネルから メッセージを取得
28. アーキテクチャ ・LambdaからinvokeAgentRuntime API をコール ・Firecrawl MCPでURL検索 ・レベル判定を行い、Lambdaへ返す
29. アーキテクチャ ・レスポンスを元に、 Lambda側でデータを格納
30. アーキテクチャ ・処理が終わったらSNSで管理者へ通知 ・バックグラウンドで動作するため、 エラーでも成功でも必ず通知が必要 ・Langfuseにはエージェントのトレース が出力されている ・コスト管理、品質管理を目的に参照
31. アーキテクチャ ※Step Functionsは現状無理です。 Step FunctionsからBedrock AgentCore がコールできないため。 ちなみにBedrock Agentsもコール不可。
32. 実装で難しかったところ& エージェント開発のTips
33. アーキテクチャ設計で難しかった点 ◆良くも悪くもAgentCoreの自由度が高すぎる • やろうと思えばSlackアクセス~ユーザー通知まで、 全部AgentCore Runtimeの中に閉じ込めることも可能(多分) ◆ただ現状はEventBridgeからAgentCoreを直接実行できないので Lambdaを挟んだ • Lambdaを挟むのであれば、LambdaでできることはLambdaでやりたい • その場合はAgentCoreにはエージェントのロジックだけ 入れておくようにする方が良いと判断(役割分担)
34. アーキテクチャ設計で難しかった点 ◆無理やりAgentCoreの中に閉じ込めると、こんな感じ • エージェントがSlackメッセージ取得、Web検索、データ格納まで実施 • Strands Agents SDKのGraph採用→自律性+安定性を両立 • こっちの方が「AIエージェント」っぽい！ ◆動きはする、が色んなものを犠牲にする…
35. プロトタイプのデモ
36. Tips1. マルチエージェントから始めるな ◆初手でマルチエージェントやAgentic Workflowに手を出すと大変 • Anthropic「シンプルに設計しろ」(Building Effective Agents) • ワイ「やってみたいからGraph使ったろｗいけるやろｗ」←終わりの始まり ◆まずはLLM+Tooluse、もしくはシングルエージェントで設計 • 試して、思ったより精度が出ないときに拡張していく • コスト・処理時間・複雑度はトレードオフなことを理解しておく • (さっきのデモだと1メッセージの処理に2-3分、約10万トークン消費 ) ◆「その処理はエージェントが実行しないといけないか？」を考える • 今回で言えば「Slackからのメッセージ取得はエージェントの仕事か？」 • 安定性と柔軟性のどちらを取るか？は要検討
37. Tips2. Strands Agent Graphにかなり癖あり ◆複数のエージェントを繋ぎ、決まった順序で確実に実行する設計図 • Agentic Workflowをコードベースで定義できる機能 ◆登場人物 • ノード：エージェントや関数そのもの • エッジ：ノード間の接続パーツ • Step Functionsを完全にコードベースで 定義するようなイメージ ◆何が嬉しい？ • 複雑な作業を小さな専門ノードに分割し、順序と受け渡しを明示できる • 精度向上、処理の安定化、開発とデバッグがやりやすい…など
38. Tips2. Strands Agent Graphにかなり癖あり ◆ノードがAgentなのが難しい • 同じようなことができるLangGraphだと、ノードがLLMとツール • ある程度柔軟にカスタマイズ可能(な認識、分岐処理やステート管理など) • Strands AgentsのGraphだと、ノードがAgent • LLMとツール実行のカスタマイズに限りがある(エージェント数珠つなぎみたいになる)
39. Tips3. AgentCore GatewayのMCPツールに注意 ◆Gatewayには3rdパーティのMCPサーバーが予め用意されている • 問題は、このMCPサーバーの中身がほとんど見えないこと ◆Anthropic「ツールには説明と仕様を詳細に書け」 • Gatewayだと何も見えない…(かろうじてツール名は出力できる) • GAされたら見えるようになっているといいなぁ… • 現状Gateway使うなら、ツールを自前実装して使う方が良いかも？ Writing effective tools for agents with agents
40. Tips4. エージェント開発とObservability ◆LLMを組み込んだアプリ開発においては、不確実性が付き纏う • 開発者はLLMの挙動を把握できるようにしておくべき • 開発〜運用まで、幅広い領域で有効活用できる ◆GenAI Observability(CloudWatch + X-ray) • AWS環境上でもエージェントの挙動はある程度確認できる • ログ出力も確認できる
41. Tips4. エージェント開発とObservability ◆AgentCoreからLangfuseへのトレース送信方法 • AgentCoreはデフォルトだとCloudWatch+X-rayへトレースを送信する • Langfuseは上記の方法だとトレースを受け取れないので、少しアレンジ • つよつよBedrockerなお二方に助けていただきました https://github.com/har1101/strands- agent-with-langfuse-on-agentcore https://github.com/moritalous/ strands-agents-langfuse
42. Tips4. エージェント開発とObservability ◆現状だと正直Langfuseの方が見やすいのでこちらが必須かなと…
43. おまけ：Bedrock AgentCoreのIaC化 ◆AWS CDK ver.2.217.0にて待望のL1 Construct登場 ◆既に記事が出ているのでぜひご一読ください https://qiita.com/Syoitu/items/65fda40c75d d467b5cd7?utm_campaign=post_article&utm _medium=twitter&utm_source=twitter_share https://zenn.dev/aws_japan/articles/ 2025-09-25-agentcore-runtime-l1
44. おまけ：Bedrock AgentCoreのIaC化 ◆ちなみにAgentCore SDKを使ってのデプロイには、 CDK(およびCloudFormation)だと対応していないようです (@app.entrypoint などのラッパー関数を使う方法、ハンズオンだとこちらが一般的でした) https://strandsagents.com/latest/documentation/docs/user- guide/deploy/deploy_to_bedrock_agentcore/#option-b-custom-agent
45. ◆今作っているものと過程で詰まったポイントのお話をしました！ • シンプルなエージェントから始めよう • Strands Agent Graphは癖あり • AgentCore Gatewayの既成MCPサーバーはほぼブラックボックス • エージェント開発においてObservabilityは必須 • 祝・AgentCoreのIaC対応 ◆懺悔：完成品を持ってこれずすみません…… • これがPJだったら今頃大炎上 • とはいえ手を動かすことでしか得られない経験値もある(多分) • エージェント開発やっていきましょう！ • 完成次第公開するので良ければ使ってみてください！ まとめ
46. 2025.12.20(土) AI Builders Day！