ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素

1 © 2025 Leverages Co., Ltd. ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素 2025.12.20
苑田朝彰 @sonoda_mj

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開発チームリーダー自己紹介

4 © 2025 Leverages Co., Ltd. Contents 引き継ぎコンシェルジュ ko⭐shiとは  コンテキスト管理 
プロンプト設計  ツール設計  評価  まとめ    01. 02. 03. 04. 05. 06.

6 © 2025 Leverages Co., Ltd. AWS Summit Japan 2025
生成AIエージェントハッカソンで準優勝！！社内プロダクトへ！

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

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

13 © 2025 Leverages Co., Ltd. 構成図（Agent編） Orchestrator Agent Github
Agent Asana Agent Slack Agent 地図 Github関連 Asana関連 Slack関連 DynamoDB Agent Tool （自作関数）評価

14 © 2025 Leverages Co., Ltd. 構成図（Agent編） Agent Tool （自作関数）
Orchestrator Agent Github Agent Asana Agent Slack Agent 地図 Github関連 Asana関連 Slack関連 DynamoDB プロンプト管理コンテキスト管理 Tool管理評価評価

16 © 2025 Leverages Co., Ltd. コンテキスト管理 1. コンテキストエンジニアリングの基本戦略 2.
コンテキストの腐敗とは 3. 34万Token事件 4. 適切なツールを選択する 5. 会話管理（Conversation Management）の選択

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 会話履歴

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 コンテキストウィンドウ

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件教えて

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ドル

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

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 抽出入力

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 独自にカスタムした会話履歴

24 © 2025 Leverages Co., Ltd. 学び 1. 情報を読ませるほど賢くなるわけではなく、逆に精度が下がる可能性がある 2.
提供されているMCPは不純物を含んでる可能性がある 3. 適切にツールを選択する必要がある

26 © 2025 Leverages Co., Ltd. プロンプト設計 1. プロンプトをちょうどいい粒度で書く 2.
プログラム（if文）で書けることをAgentでやらない 3. 指示ではなく、ツールの使い方を記載する 4. 【re:Invent 2025】ステアリング機能を使う

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

必要があります。 get_weather(city_name) 関数を呼び出す。戻り値の temperature が25 度以上なら『暑いです』、それ未満なら『涼しいです』とだけ答える。それ以外の言葉は一切話さないでください。 ## 役割あなたは、ユーザーの生活をサポートする親切な「お天気エージェント」です。提供されたツールを使用して正確な気象情報を取得し、ユーザーに役立つアドバイスを提供します。あなたは天気予報AIです。ユーザーの質問に答えてください。具体的すぎる抽象的すぎるちょうどいい引用： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ツールの強制力がなく、最新の天気データをどこから取得するのか定義されていない。

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

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

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

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

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

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

35 © 2025 Leverages Co., Ltd. 学び 1. 具体的すぎると柔軟性が失われ、抽象的すぎると暴走するため、バランスが重要
2. if文で書ける確定的な処理はコードで行い、Agentには不確実な判断を任せる 3. 「何をしろ」ではなく「これを使うには何が必要か」を書き、Agentに思考させる

37 © 2025 Leverages Co., Ltd. Tool設計 1. APIをそのままToolとして使用するのは避けるべき 2.
ゴールから逆算して適切なToolを選択する 3. 粒度の大きさを定義する 4. 「答え」ではなく、「地図」を渡す 5. 認知負荷の軽減のためにマルチエージェントへ変更

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 • など不純物「名前でユーザーを探して」と頼まれた時に、機能が似ているとどちらを使うべきか判断できなくなる

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

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

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

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番号その他: 要約内容など

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関連）

44 © 2025 Leverages Co., Ltd. 学び 1. APIをそのまま渡さず、モデルが理解しやすい関数名と最小限の引数で再構築する
2. いきなり「答え」を探させず、メタデータや要約を渡して最短ルートへ導くのも効果的である 3. マルチエージェントに分割することで、回答精度を向上できる

46 © 2025 Leverages Co., Ltd. 評価 1. ある程度Agentが完成したら、評価パイプラインを作る 2.
何を評価するか決める 3. 【re:Invent 2025】Strands AgentsのEvaluation機能を使う 4. テストデータを作成する 5. 【re:Invent 2025】Experiment Generator機能を使う

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

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

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

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

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

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とタスクの定義テストデータを生成する

58 © 2025 Leverages Co., Ltd. まとめ 1. コンテキスト：量より質。不純物を削ぎ落とし、精度を最大化する
2. プロンプト：具体的すぎず抽象的すぎず、バランスよく定義する 3. ツール設計：モデルの認知負荷を下げ、迷わせないための「地図」を作る 4. 評価：定量的な指標に基づき、確信を持って開発サイクルを回す

ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素

ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素

More Decks by そのだ

Other Decks in Technology

Featured

Transcript