ハッカソンから社内プロダクトへ AIエージェント ko☆shi 開発で学んだ4つの重要要素

by Tech Leverages

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 © 2025 Leverages Co., Ltd. 苑田朝彰普段の業務内容 ● AI エージェント開発（Strands Agent, Google ADK） ● 社内AI推進（Agent開発, AI駆動開発） ● クラウド（AWS, Google Cloud）資格 ● AWS Community Builders（ML） ● 甲賀流忍者検定（中級）趣味 ● 月一で面白いことをするのにハマってます ○ Spartanレース ○ 100kmウォーキング ○ 無人島かくれんぼ ○ 滝行 SNS ● https://x.com/sonoda_mj ● https://zenn.dev/tomomj ● https://note.com/sonoda_mj Tomotada Sonoda システム本部 / テクノロジー戦略室 AI Agent開発チームリーダー自己紹介

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 © 2025 Leverages Co., Ltd. 引き継ぎはめんどくさい引き継ぎは、ドキュメントの不備や時間の欠如によって「前任者しか知らないこと」が失われるリスクを常に孕んでいます。対話が消失した後は、些細な疑問すら解消できず、開発の停滞を招きます。ドキュメント不足暗黙知の言語化が追いつかず仕様がブラックボックス化するリリースや退職までに情報を整理しきれない聞けば5分で済むことが一生聞けなくなる時間の欠如対話の消失膨大な既存資料前任者後任者誰にも聞けない... 前任者ここはドキュメントにせんでええやろ不十分な引き継ぎ資料

Slide 8

Slide 8 text

8 © 2025 Leverages Co., Ltd. 引き継ぎコンシェルジュ ko☆shiとは ko☆shiを導入することで、暗黙知の情報を自動で吸い上げ、前任者がいなくなった後も、 24時間いつでも対話できるようになります。ドキュメント不足 ko☆shiが情報を抽出しブラックボックスを解消退職までの限られた時間で全情報を構造化まるで前任者と会話しているかのように対話できる時間の欠如対話の消失膨大な既存資料後任者 ko☆shi なんでも聞いてな ko☆shi 引き継ぎ資料作っといたで ko☆shi 全部読んどいたで

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 © 2025 Leverages Co., Ltd. 1. コンテキストエンジニアリングの基本戦略 LLMのコンテキストウィンドウには限りがあるので、コンテキストの取捨選択をしなければなりません。望ましい結果を得るために、最小限の情報セットを見つけ出すことが、コンテキストエンジニアリングの基本となります。引用： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents doc 1 Tool 1 Tool 2 Memory file 会話履歴 doc 2 doc 3 Tool 2 doc 1 doc 3 Memory file 会話履歴抽出入力 LLM 会話履歴

Slide 18

Slide 18 text

18 © 2025 Leverages Co., Ltd. 2. コンテキストの腐敗とは最近のLLMは広大なコンテキストウィンドウを持ちますが、入力する情報量に比例して性能が向上するわけではありません。むしろ、トークン数が増大するほど情報の検索精度や推論能力が低下する傾向にあります。したがって、単にすべての情報を入力するのではなく、本当に必要なコンテキストのみを渡す必要があります。引用：https://research.trychroma.com/context-rot Agent doc 1 doc 2 （関係なし） doc 3 (関係なし) doc 4 コンテキストウィンドウ Agent doc 1 doc 2 （関係なし） doc 3 (関係なし) doc 4 コンテキストウィンドウ

Slide 19

Slide 19 text

19 © 2025 Leverages Co., Ltd. 3. 34万Token事件公式のGitHub MCPを使用していた時、わずか1回の対話で34万トークン（コスト約0.5ドル）を消費する事象が発生しました。 Traceで詳細を分析したところ、多くの不純物が含まれていることが判明しました。参考：https://zenn.dev/leverages/articles/github-zenn-linkage-20251201-1 Toolのアウトプットリポジトリ2つ × 10 PR - PRの番号 - PRのタイトル - PRの内容欲しい情報 - user - assignee - commit url - comment url - など不純物最新のPRを 2件教えて

Slide 20

Slide 20 text

20 © 2025 Leverages Co., Ltd. 3. 34万Token事件必要な情報だけを取得する自作関数を作成しました。実際に評価パイプラインを実行したところ、アウトプットの品質は下げずに、Token使用量を9割削減することに成功しました。公式MCPは便利ですが、不要な情報が多すぎる場合、推論精度が低下する可能性があります。 Toolのアウトプット - PRの番号 - PRのタイトル - PRの内容欲しい情報 - user - assignee - commit url - comment url - など不純物 ← 33.5万 ← 3.5万 0.37ドル 0.05ドル

Slide 21

Slide 21 text

21 © 2025 Leverages Co., Ltd. 3. 34万Token事件必要な情報だけを取得する自作関数を作成しました。実際に評価パイプラインを実行したところ、アウトプットの品質は下げずに、Token使用量を9割削減することに成功しました。公式MCPは便利ですが、不要な情報が多すぎる場合、推論精度が低下する可能性があります。呼び出しているツールの種類は同じ最新の2件のみを取得できている

Slide 22

Slide 22 text

22 © 2025 Leverages Co., Ltd. 4. 適切なツールを選択するツールは多ければ多いほど多機能に思えますが、LLMにとっては「一度に何十種類もの道具を渡されて、その中から今すぐ一つ選べ」と言われているようなものです。この認識負荷を下げてあげることが、エージェントを賢く動かすための鍵になります。 Strands Agentsでフォーマット name: ツール名 description: ツールの説明 inputSchema: 入力パラメータ Tool A name: ツール名 description: ツールの説明 inputSchema: 入力パラメータ Tool B name: ツール名 description: ツールの説明 inputSchema: 入力パラメータ Tool C Tool群 Amazon Bedrock 抽出入力

Slide 23

Slide 23 text

23 © 2025 Leverages Co., Ltd. 5. 会話管理（Conversation Management）の選択基本的にはSlidingWindow（デフォルト搭載）を標準とし、コンテキストオーバーフローが頻発する場合にSummarizing へ移行するのが良さそうです。会話履歴を変更しないシンプルな実装 Null ConversationManager 直近の会話履歴を一定数保持する SlidingWindow ConversationManager コンテキスト溢れ発生時、履歴を要約する Summarizing ConversationManager 会話履歴 1 会話履歴 2 会話履歴 3 会話履歴 4 会話履歴 1 会話履歴 2 会話履歴 3 会話履歴 4 会話履歴 1 会話履歴 2 会話履歴 3 1, 2, 3を要約した会話履歴独自にコンテキストをカスタムできる Custom ConversationManager 会話履歴 1 会話履歴 2 会話履歴 3 独自にカスタムした会話履歴

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 © 2025 Leverages Co., Ltd. 1. プロンプトをちょうどいい粒度で書く指示が細かすぎるとLLM特有の柔軟性がなくなり、曖昧すぎると暴走します。したがって、 AIが自分の頭で考えて最短ルートを見つけられるような、ちょうどいいガイドラインを作る必要があります。 get_weather(city_name) 関数を呼び出す。戻り値の temperature が25 度以上なら『暑いです』、それ未満なら『涼しいです』とだけ答える。それ以外の言葉は一切話さないでください。 ## 役割あなたは、ユーザーの生活をサポートする親切な「お天気エージェント」です。提供されたツールを使用して正確な気象情報を取得し、ユーザーに役立つアドバイスを提供します。あなたは天気予報AIです。ユーザーの質問に答えてください。具体的すぎる抽象的すぎるちょうどいい引用： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Slide 28

Slide 28 text

28 © 2025 Leverages Co., Ltd. 1. プロンプトをちょうどいい粒度で書く指示が細かすぎるとLLM特有の柔軟性がなくなり、曖昧すぎると暴走します。したがって、 AIが自分の頭で考えて最短ルートを見つけられるような、ちょうどいいガイドラインを作る必要があります。 get_weather(city_name) 関数を呼び出す。戻り値の temperature が25 度以上なら『暑いです』、それ未満なら『涼しいです』とだけ答える。それ以外の言葉は一切話さないでください。 ## 役割あなたは、ユーザーの生活をサポートする親切な「お天気エージェント」です。提供されたツールを使用して正確な気象情報を取得し、ユーザーに役立つアドバイスを提供します。あなたは天気予報AIです。ユーザーの質問に答えてください。具体的すぎる抽象的すぎるちょうどいい引用： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ツールの強制力がなく、最新の天気データをどこから取得するのか定義されていない。

Slide 29

Slide 29 text

29 © 2025 Leverages Co., Ltd. 1. プロンプトをちょうどいい粒度で書く指示が細かすぎるとLLM特有の柔軟性がなくなり、曖昧すぎると暴走します。したがって、 AIが自分の頭で考えて最短ルートを見つけられるような、ちょうどいいガイドラインを作る必要があります。 get_weather(city_name) 関数を呼び出す。戻り値の temperature が25 度以上なら『暑いです』、それ未満なら『涼しいです』とだけ答える。それ以外の言葉は一切話さないでください。 ## 役割あなたは、ユーザーの生活をサポートする親切な「お天気エージェント」です。提供されたツールを使用して正確な気象情報を取得し、ユーザーに役立つアドバイスを提供します。あなたは天気予報AIです。ユーザーの質問に答えてください。具体的すぎる抽象的すぎるちょうどいい引用： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 単純なタスク処理には向いていますが、ユーザーが「傘は必要？」と聞いても、この指示通りだと「涼しいです」としか返せない（あるいはエラーになる）可能性があります。

Slide 30

Slide 30 text

30 © 2025 Leverages Co., Ltd. 1. プロンプトをちょうどいい粒度で書く指示が細かすぎるとLLM特有の柔軟性がなくなり、曖昧すぎると暴走します。したがって、 AIが自分の頭で考えて最短ルートを見つけられるような、ちょうどいいガイドラインを作る必要があります。 get_weather(city_name) 関数を呼び出す。戻り値の temperature が25 度以上なら『暑いです』、それ未満なら『涼しいです』とだけ答える。それ以外の言葉は一切話さないでください。 ## 役割あなたは、ユーザーの生活をサポートする親切な「お天気エージェント」です。提供されたツールを使用して正確な気象情報を取得し、ユーザーに役立つアドバイスを提供します。あなたは天気予報AIです。ユーザーの質問に答えてください。具体的すぎる抽象的すぎるちょうどいい引用： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 動作を効果的に導くのに十分な具体的さと、柔軟性のあるバランスの取れたレベルです。

Slide 31

Slide 31 text

31 © 2025 Leverages Co., Ltd. すべてをAIに任せるのではなく、「確実な処理」と「不確実な判断」を切り分けることが重要です。手順が確定している処理は従来のコード（Workflow）に任せ、Agentは調査や高度な推論が必要なシーンにのみ活用します。 2. プログラム（if文）で書けることをAgentでやらない Workflow Agentic Workflow 金額は 3000円以下？経費申請自動承認 Yes 上長承認 No 経費申請（ゲーム機）過去の履歴 ① ゲーム機だけどテスト端末かもしれない過去の履歴を確認する担当者 ② 用途を具体的に書いてください - Anthropic: プロンプトにif-elseロジックを詰め込むのは、保守性を下げる「失敗モード」である。 - LLMのプロンプトエンジニアリング: 決定論的な処理は、LLMより従来のコードの方が信頼性が高く安い。

Slide 32

Slide 32 text

32 © 2025 Leverages Co., Ltd. 3. 指示ではなく、ツールの使い方を記載するプロンプトに手順を書くと柔軟性が失われます。Agentにはツールの利用条件のみを提示し、具体的な実行手順を委ねることで、状況に応じた柔軟な対応が可能になります。引用：https://www.anthropic.com/engineering/writing-tools-for-agents ツールの使い方を説明コードでは記述できない「曖昧な状況」の判断基準を教えることで、様々な聞き方をされても、エージェントが自律的に「最短ルート」を導き出せます。

Slide 33

Slide 33 text

33 © 2025 Leverages Co., Ltd. 4. 【re:Invent 2025】ステアリング機能を使う参考：https://zenn.dev/leverages/articles/github-zenn-linkage-20251206-1 指示や禁止事項は、コンテキストが長くなるほど見落とされるリスクが高まります。ステアリング機能なら、プロンプトをスリムに保ちつつ、必要なタイミングで確実にルールを徹底できます。ただし、レイテンシーとコストは注意してください。 Agent Tool （取得）アウトプットステアリング ● Proceed: そのままツール実行を許可する。 ● Guide: ツール呼び出しをキャンセルし、エージェントにフィードバックを返す。エージェントはこのフィードバックを受けて別のアプローチを試みる。 ● Interrupt: ツール実行を一時停止し、人間の入力を待つ。承認されれば実行、拒否されればキャンセル。 Proceed Guide / Interrupt

Slide 34

Slide 34 text

34 © 2025 Leverages Co., Ltd. 4. 【re:Invent 2025】ステアリング機能を使う参考：https://zenn.dev/leverages/articles/github-zenn-linkage-20251206-1 指示や禁止事項は、コンテキストが長くなるほど見落とされるリスクが高まります。ステアリング機能なら、プロンプトをスリムに保ちつつ、必要なタイミングで確実にルールを徹底できます。ただし、レイテンシーとコストは注意してください。 7.96s 10.31s

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

38 © 2025 Leverages Co., Ltd. ● search_users ● find_user_by_name ● get_user_profile ● list_users 1. APIをそのままToolとして使用するのは避けるべき APIの情報をそのまま渡すと、Agentは情報の多さに混乱し、誤作動を起こします。ムダなコストを抑え、Agentの判断精度を最大限に高めるために、「AIが理解しやすい形」に整えて渡すことが重要です。モデルが理解しやすいように、パラメータを必要最小限に削ぎ落とした関数を定義する人間がAPI仕様書を読むように、モデルは「関数名」と「引数名」からその機能を推測する機能の重複を避け、担当領域を明確に分割する Toolの定義 Toolと引数の命名適切なツールの選択 ● PRの番号 ● PRのタイトル ● PRの内容欲しい情報 ● user ● assignee ● commit url ● comment url ● など不純物「名前でユーザーを探して」と頼まれた時に、機能が似ているとどちらを使うべきか判断できなくなる

Slide 39

Slide 39 text

39 © 2025 Leverages Co., Ltd. 2. ゴールから逆算して適切なToolを選択する最初から完璧な設計は困難です。まずは多様なツールで試作し、「理想のアウトプット」から逆算してツールの役割を再設計することで、エージェントの精度が高まります。 PR取得 Issue 作成ファイル検索 commit 削除コメント書き込み commit 編集 Agent 最新#64って何をしていますか？〇〇さんがコードを修正しました。具体的には... 1. PRの情報が必要 2. PRに紐づくファイルの内容を確認する必要なTool 適切なToolを選択 Tool群

Slide 40

Slide 40 text

40 © 2025 Leverages Co., Ltd. 3. 粒度の大きさを定義するツールの「粒度」は、エージェントの自由度と安定性のバランスを左右します。細かすぎると判断ミスやループのリスクが増え、大きすぎると特定の用途以外に使い道がなくなります。目的に応じた最適なサイズ感の設計が必要です。回答の安定性と品質を確保できる一方で、タスク特化型になりやすく応用（拡張性）が利かなくなります。粒度大きめ Agent Tool （粒度大）アウトプット自律的で柔軟なタスク処理が可能になる一方で、探索の失敗による無限ループや暴走のリスクが高まります。粒度小さめ Agent Tool （粒度小）アウトプット

Slide 41

Slide 41 text

41 © 2025 Leverages Co., Ltd. 4. 「答え」ではなく、「地図」を渡す闇雲に「答え」を探させると、不要な情報の読み込みによってコンテキストが溢れ、回答精度が低下します。まず情報の全体像を示す「地図（メタデータや要約）」をツールとして提供し、どこを調べるべきかAgentに「当たり」をつけさせる設計にしました。 Agent Tool （取得）アウトプットユーザーまずはPRを全部読んで Asanaを確認して・・・ Agent アウトプットユーザー Tool （取得）地図（PRあればわかるマン） PR番号はわかったから関連情報を検索しよう Before After EventBridgeってなぜ作られた？ EventBridgeってなぜ作られた？

Slide 42

Slide 42 text

42 © 2025 Leverages Co., Ltd. 4. 「答え」ではなく、「地図」を渡す GitHub PRの背景情報を構造化し、DynamoDBへ「インデックス（地図）」として蓄積。エージェントがこの地図を起点に探索することで、最短ルートで目的に到達できる仕組みを構築しました。 # 背景請求計算システム（ Billing System）の夜間バッチ処理を自動化する必要があったため、 EventBridgeを作成。 - 議論の経緯：SlackのURL（リトライ回数の決定について） # 詳細 - terraform/main.tf に、毎日AM2:00に `calc-billing-lambda` をトリガーする EventBridge Ruleのリソースを作成。 # 備考 - タスク管理：Asanaのリンク（要件定義書あり） Pull Request Agent (Slack調査) Agent (Github調査) Agent （Asana調査） Amazon DynamoDB Agent ユーザー EventBridgeってなぜ作られた？ PK: Slack チャンネル ID SK:link#org/repo/pr:PR番号その他: 要約内容など

Slide 43

Slide 43 text

43 © 2025 Leverages Co., Ltd. 5. 認知負荷の軽減のためにマルチエージェントへ変更シングルエージェント構成では、膨大なツール定義と実行結果がコンテキストを圧迫し、回答精度の低下を招きます。そこで、特定の役割を切り出したAgent as Tools（サブエージェント構成）を採用しました。 Agent Tool （Asana関連） Tool （GitHub関連） Tool （Slack関連） Agent Agent Agent Agent Tool （Asana関連） Tool （GitHub関連） Tool （Slack関連）

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

47 © 2025 Leverages Co., Ltd. 1. ある程度Agentが完成したら、評価パイプラインを作る手動による品質確認は、モデル変更やプロンプト調整のたびに膨大な工数を要します。開発の初期段階で評価パイプラインを構築することで、継続的な精度向上を実現できます。評価器 Datasets ユーザー評価したい Agent スコア1.0 Input: 入力 Expected Output: 予期する回答 Input Expected Output Output ● モデルを変更した ● プロンプトをチューニングした ● 精度を上げるために、 Toolを追加・変更した ● など ● StrandsAgents Eval ● DeepEval ● ragas ● など

Slide 48

Slide 48 text

48 © 2025 Leverages Co., Ltd. 1. ある程度Agentが完成したら、評価パイプラインを作る手動による品質確認は、モデル変更やプロンプト調整のたびに膨大な工数を要します。開発の初期段階で評価パイプラインを構築することで、継続的な精度向上を実現できます。評価器 Datasets ユーザー評価したい Agent スコア1.0 Input: 入力 Expected Output: 予期する回答 Input Expected Output Output ● モデルを変更した ● プロンプトをチューニングした ● 精度を上げるために、 Toolを追加・変更した ● など ● StrandsAgents Eval ● DeepEval ● ragas ● など

Slide 49

Slide 49 text

49 © 2025 Leverages Co., Ltd. 1. ある程度Agentが完成したら、評価パイプラインを作る手動による品質確認は、モデル変更やプロンプト調整のたびに膨大な工数を要します。開発の初期段階で評価パイプラインを構築することで、継続的な精度向上を実現できます。評価器 Datasets ユーザー評価したい Agent スコア1.0 Input: 入力 Expected Output: 予期する回答 Input Expected Output Output ● モデルを変更した ● プロンプトをチューニングした ● 精度を上げるために、 Toolを追加・変更した ● など ● StrandsAgents Eval ● DeepEval ● ragas ● など

Slide 50

Slide 50 text

50 © 2025 Leverages Co., Ltd. 2. 何を評価するか決める Agentの特性や用途によって定義すべき品質は異なるため、汎用的な正解は存在しません。まずは「何を担保すべきか」を明確に定義し、小さく構築することが重要です。評価項目日本語評価の視点 Trajectory 軌跡目標達成までのアクションの流れ。 Interactions 相互作用タスク完了までに要したやり取りの回数。 Helpfulness 有用性応答や行動がユーザーの目的に貢献した度合い。 Faithfulness 忠実性情報源や指示内容に対する正確さと誠実さ。 Goal Success Rate 目標達成率最終的なタスクやゴールの達成できた割合。 Tool Selection Accuracy ツール選択精度タスクに対し、適切な外部ツールを選べた正確性。 Tool Parameter Accuracy ツール引数精度ツールの利用時に渡した引数の正確性。 Custom カスタム評価者が独自に定義・設定した評価基準。

Slide 51

Slide 51 text

51 © 2025 Leverages Co., Ltd. 2. 何を評価するか決める Agentの特性や用途によって定義すべき品質は異なるため、汎用的な正解は存在しません。まずは「何を担保すべきか」を明確に定義し、小さく構築することが重要です。評価項目日本語評価の視点 Trajectory 軌跡目標達成までのアクションの流れ。 Interactions 相互作用タスク完了までに要したやり取りの回数。 Helpfulness 有用性応答や行動がユーザーの目的に貢献した度合い。 Faithfulness 忠実性情報源や指示内容に対する正確さと誠実さ。 Goal Success Rate 目標達成率最終的なタスクやゴールの達成できた割合。 Tool Selection Accuracy ツール選択精度タスクに対し、適切な外部ツールを選べた正確性。 Tool Parameter Accuracy ツール引数精度ツールの利用時に渡した引数の正確性。 Custom カスタム評価者が独自に定義・設定した評価基準。

Slide 52

Slide 52 text

52 © 2025 Leverages Co., Ltd. 2. 何を評価するか決める評価したい Agent Trajectory Tool 1 Tool 2 Tool 3 目標達成までのアクションの流れ最終的なタスクやゴールの達成できた割合 Goal Success Rate 適切なツールが呼び出されるか評価したい Agent アウトプット最終的にユーザーの目的が果たされたかたまたま正解しただけの非効率な動き（まぐれ）や、手順は完璧なのに最後の一歩で間違えたのかを切り分けたいので、この２つを選択しました。

Slide 53

Slide 53 text

Slide 54

Slide 54 text

54 © 2025 Leverages Co., Ltd. なんでもいいのでテストデータを作成することをお勧めします。 4. テストデータを作成する実データから作成ユーザーファイル検索がちゃんとできるか確認したい！担保したいものから自分で作成 Datasets Input: 〇〇ファイルについて詳しく教えてください Output: 〇〇は苑田さんが作成して、詳しくは... テストデータ自作して Datasetsに登録

Slide 55

Slide 55 text

55 © 2025 Leverages Co., Ltd. 5. 【re:Invent 2025】Experiment Generator機能を使う参考：https://zenn.dev/leverages/articles/github-zenn-linkage-20251206-1 Experiment Generatorを使用すると、Agentの特性に沿ったテストデータを作成することが可能です。しかし、LLMで生成しているので、人間のチェックが必須です。 Toolとタスクの定義テストデータを生成する