SmartHRのテックブログで公開された、社内問い合わせBotの精度評価をどう仕組み化したかの記事です。 単にAIを導入する話ではなく、「導入したAIをどう評価するか」をもう一段AIで自動化した事例です。
「うちには関係ないテック話」と読み飛ばす前に、ここだけ押さえておきたいです。 中小企業の社内Bot導入がPoC止まりで終わる最大の原因は、「効いてるかどうか測れない」ことです。 SmartHRはここを正面突破した、というのが本質です。
僕が注目したのは、Slackのスタンプ(Good/Bad/Copy)をそのまま教師データにしてしまっている設計です。 新しいデータを集めるのではなく、現場で勝手に貯まっているシグナルを拾う発想は、中小企業にこそ刺さります。
社内問い合わせBotの課題
社内FAQ Botを導入した組織で、必ずぶつかる壁です。
- AIの回答が「良いか悪いか」を人間の感覚でしか評価できない
- 改善ループが遅く、プロンプトを直しても効果が見えない
- 安全性(誤った断定)と使い勝手(さっと答える)のバランスが取れない
- 結局「PoCはやったけど、効いてるか分からないまま放置」になりがち
評価器がないAI Botは、温度計のない暖房と同じです。設定温度をいくら変えても、効いてるかどうか分かりません。
2段階DSPyの仕組み
SmartHRテックブログ(2026-01-15)で説明されている流れは以下です。
第1段階: Judgeプロンプトの学習
教師データはSlack上のユーザー反応をそのまま点数化します。
- 3点: Good + Copy(回答をコピーして実務で即活用された)
- 2点: Good または Copy(改善の余地あり)
- 1点: Bad(問題解決に未達)
DSPyのエコシステム上で動くGEPAアルゴリズムを使い、質問と回答のペアからスコアを予測する「Judgeプロンプト」を自動で最適化します。手動ルールでもなく、教師あり学習でもなく、「解釈可能なテキスト形式のプロンプト」として評価器が出来上がります。
第2段階: 生成プロンプトの最適化
学習済みのJudgeプロンプトを評価関数に組み込み、UX指標と安全性指標の多目的評価で、回答生成側のプロンプト自体をGEPAで最適化していきます。
つまり「評価器をAIに作らせて、その評価器でAIを育てる」という二段構えです。
何が嬉しいのか
報告された主なメリットは以下です。
- ユーザーの実感に近い評価軸をテキストとして再利用できる
- 「断定的な言い回し」など、ユーザーが暗黙的に重視している基準を可視化できた
- 改善ループを「人間の感覚レビュー」から「自動評価」に置き換えられた
- 安全性とUXのバランスを取りながらプロンプトを進化させられる
注意点として、これは「評価インフラを構築した話」であり、「導入直後のBotが急に賢くなった」話ではありません。社内Bot運用の継続改善が回る土台を作った事例として読むのが正しい解釈です。
中小企業で再現するなら
ここからが本題です。社内Botを「PoCで止めない」体制を中小企業で組むならどう削るか。
構成
| 項目 | SmartHR | 中小企業(年商5〜30億・社員30〜100名) |
|---|---|---|
| 対象 | 社内問い合わせBot | 社内FAQ Bot or 顧客サポートBot |
| ツール | DSPy + GEPA + Slack | DSPy(OSS) + LLM API(月従量) + Slack/Teams |
| 月額費用 | (社内利用) | 推定 月2〜10万円(LLM API+評価実行コスト) |
| 初期費用 | 推定中規模(社内エンジニア工数) | 推定 100〜300万円(評価インフラ構築+教師データ整備) |
| 体制 | 社内エンジニア+データチーム | 社内エンジニア1名+外部AIエンジニア月10〜20時間 |
| 期間 | 段階展開(数ヶ月) | 3〜6ヶ月でPoC→継続改善体制 |
評価軸スコア
| 評価軸 | スコア |
|---|---|
| ROI(投資対効果) | ★★★☆☆ |
| 再現性(中小企業) | ★★☆☆☆ |
| 難易度(低いほど簡単) | ★★★★☆ |
(難易度=数字小さいほど簡単)
スコア根拠は以下です。
- ROIは中。BotがPoC止まりだったコストを回収できるが、効果が出るまで時間がかかる
- 再現性は低め。エンジニアリングリソースが必須で、非エンジニアだけでは難しい
- 難易度は高め。DSPy/GEPA/LLM-as-a-Judgeの理解が前提
前提条件・必要データ
- すでに社内Botが運用されており、ユーザーフィードバックが蓄積されている
- Slack/Teams上のスタンプ反応など、評価シグナルとなるデータが取得できる
- DSPy等のOSSを扱えるエンジニアが社内 or 外部に確保できる
- 「評価インフラ構築」のフェーズに3〜6ヶ月使える経営判断ができる
失敗条件・適用しないケース
- そもそも社内Botがまだ稼働しておらず、評価データがない
- スタンプ反応など、ユーザーが自然に残すシグナルが収集できていない
- エンジニアリングリソースが無く、ツール導入を非エンジニアだけで完結させたい
- 短期(1〜2ヶ月)で成果を出す前提でしか動けない
「DSPyを入れればBotが賢くなる」のではありません。
Bot稼働→ユーザー反応の収集→Judgeプロンプト学習→評価器を組み込んだ最適化、という4段階を踏んで初めて、自動評価ループが動き始めます。
特に「評価データの収集経路」を最初に設計しておかないと、いくらDSPyを入れても回らないので、ここを最優先で押さえたいところです。
出典・参考
市野
愛知県岡崎市でAI活用支援を手がける一人社長。 中小企業の現場でAIを実装してきた経験から、他社事例を「うちで再現するには」の視点で読み解いて発信中。
愛知県岡崎市を拠点に、中小企業向けのAI活用支援を提供。ChatGPT・Claude Code等を活用した業務自動化やSEO・広告運用の内製化を支援。経営者が自らAIを使いこなせる体制づくりをサポートしている。
＞＞詳細なプロフィールはこちら