社内FAQボットを作っていたら、"エージェントハーネス"が出来上がっていた話
はじめに
いえらぶＧＲＯＵＰの開発部で執行役員を務めています、和田です。わだけんです。
社内SaaSプロダクトに関する問い合わせ対応が、地味に開発チームの時間を食いますよね。
「管理画面のこの計算って合ってます？」「この機能の仕様ってどうなってますっけ？」みたいな調査依頼が、社内チケットシステム経由で日々やってきます。
そこでやはり考えるのは「LLM＋社内ナレッジで自動回答するボットを作ろう」でした。
当然ですがいきなり精度はでず。結局人間が確認し直す必要があって、工数削減になっていない。しかしそこからの 1ヶ月間の試行錯誤が、段階的にハーネスを整備していたことに結果なった 面白い話だったので記事にしています。
最初にやったこと：ボット本体を頑張る
Week 1: パイプラインを組む
- チャットツールの質問 → 社内GitLab Issue自動起票 → LLMが定期巡回 → 回答コメント → チャット通知
- 「対象画面のURLがないと回答できない」ことに気づき、URL必須化
- 情報が足りない質問には追加ヒアリングを自動コメント
パイプライン整備ができたので、精度上げるか～、という感じ。
Week 2: ボット本体をいじる
- LLMモデルの切替
- エージェントのアーキテクチャ再設計
- メモリ管理の高度化、テナント分離の検討 → めんどくさすぎて断念
もしかしなくても、LLMの賢さの問題ではないな？という仮説。
気づき：ポイントは周辺
精度が出ない原因を分析してみると、ボット本体（LLM呼び出し）の問題ではありませんでした。
- 質問の分類が雑で、適切なナレッジが注入されていない
- ナレッジはあるが、LLMが「どのファイルを見ればいいか」分からない
- 精度を測る仕組みがないから、改善ループが回らない
「LLMを正しく動かすインフラ」のほうの整備に方針を変更。
福島良典氏（LayerX CEO）のnote記事にこういう記述があって、これだなあと思いました。
本質的な価値は「AIエージェント」そのものではなく、エージェントを包み込むインフラストラクチャにある
整備した5つのハーネス要素
Week 3以降、精度改善のために周辺を整備していったら、結果的に5つの「ハーネス要素」を整備していた形になっていました。
| # | 要素 | 問題 | 対処 |
|---|---|---|---|
| 1 | ルーティング | 質問が「その他」に分類→ナレッジ注入されない | 分類キーワード追加 |
| 2 | 知識基盤 | ナレッジはあるがLLMが見つけられない | 各ファイル冒頭にエントリポイント標準化 |
| 3 | 学習ループ | 解決済みパターンが蓄積されない | resolved案件からFAQ自動追加 |
| 4 | オーケストレーション | 単一カテゴリの視点でしか調査しない | 横断調査ルール+複数方向性の提示 |
| 5 | 監視・改善 | 精度が上がっているか分からない | 週次自動評価+改善提案のcronサイクル |
以下補足。
1. ルーティング
質問が「その他」に分類されると、ナレッジが注入されない。LLMが素の知識だけで回答するのはそりゃ精度悪い。分類キーワードを追加して正分類率を上げました。
2. 知識基盤
数千行のナレッジドキュメントがあるが、参照すべきコードのパスが本文中に散在していて、LLMが「まずどこを見ればいいか」を判断できていなかった。全ファイルの冒頭に主要エントリポイントを統一フォーマットで追加しました。
3. 学習ループ
過去に60〜94時間かけて人間が解決した質問パターンが、FAQ化されていなかった。同じ質問が来るたびに再調査していた。resolved案件を分析して、頻出パターンをFAQに追加するループを追加しました。
4. オーケストレーション
密接に関連する複数の業務領域があるのに、単一カテゴリの視点でしか調査していなかった。横断調査ルールと、「設定変更で解決可能か」「コード上の仕様制約か」の両方向を提示するルールを追加しました。
5. 監視・改善
Bot回答と人間の最終回答を突き合わせて精度を評価する仕組み（ABC定義）を作り、週次で自動実行するcronを設定。改善提案も自動生成されるようにしました。
Before / After
| 指標 | Before | After |
|---|---|---|
| 「その他」分類 | 頻発 | 正分類 |
| ナレッジ未使用率 | 50%（8件中4件） | エントリポイント標準化で改善 |
| 頻出質問の解決時間 | 60〜94時間 | FAQ即答 |
| 精度改善サイクル | 手動・不定期 | 週次自動 |
振り返り：fukkyy「エージェントハーネス」との照合
改めて福島氏の「エージェントハーネス」の概念と照らし合わせてみると、自分がやっていたことがそのままハーネスの構成要素でした。
| ハーネスの概念 | 実際に作ったもの |
|---|---|
| エージェントの監視・管理 | 週次精度評価、Bot回答vs人間回答の突き合わせ |
| セキュリティと信頼性 | 分類ルールによるナレッジ注入制御 |
| 組織プロセスとの統合 | チャット→チケット→GitLab→LLM→通知のパイプライン |
| 継続的改善メカニズム | cron精度チェック→改善提案→ナレッジ更新の自動サイクル |
| スケーラビリティ | 別モジュールへのパターン横展開 |
エージェント本体（LLM呼び出し）にかけた工数は、全体の10%以下だったと思います。ほぼ周辺。
面白いのは、「ハーネスを設計しよう」と思って作ったわけじゃなく、精度が出なくて困って、一個ずつ周辺を整備していったら、振り返ったときにハーネスが出来上がっていた、という流れです。
おわりに
なので「エージェントハーネスを設計してから作れ」、ではなくて精度改善をメンバーにやらせる感覚でやれば、ハーネスは自然にできる気がします（と、思っています）。
社内FAQボットに限らず、AIエージェントを組織に導入しようとしている方の参考になれば。
おわり。
CM
こんな感じで泥臭くAIと格闘してくれる方を、いえらぶは常に募集中です。