解決できる課題 事業紹介トップ 経営データ分析基盤 AI導入・業務改善 AI 業務アプリ 基幹システムのWeb化・段階移行 複雑な SaaS を専用 UI に Shopify Plus 移行・拡張 生成AI 活用(Multi AI) SEO / AIO / 広告運用 顧問・アドバイザリ インフラ構築 自社メディア投資・開発
AI導入 AI導入・業務改善 ChatGPTの社内導入 OpenAI Codex導入 AI運用・定着 Claude / MCP 総合 Claude Cowork Claude Code 導入支援 Claude Code 使いこなし支援 Claude Design MCP 開発・サーバー構築
EC構築・移行 Shopify Plus トップ EC-CUBE からの移行 大手カートからの移行 Shopify 通常プラン EC サイト構築
実績
業界ニュース 業界ニュース トップ AI ニュース └ Claude └ ChatGPT・Codex └ Gemini └ その他 Shopify ニュース SaaS ニュース お知らせ(自社発信)
会社情報 相談する
2026.10.01

SmartHR CRE、問い合わせ対応AI「DESK AIエージェント」を開発中 人間は評価・改善役へ

記事のサマリー(TL;DR)

  • SmartHRのCRE(Customer Reliability Engineer)チームは、プロダクトに関する技術的な問い合わせに対応するAIエージェント「DESK AIエージェント」を開発しています。目指しているのは人間の回答作成を補助するツールではなく、エージェントが問い合わせに対応し人間がその結果を評価・改善する仕組みです。
  • 現在は労務管理領域のプロダクトの問い合わせを中心に、Slackの起票ワークフローやメンションを通じてエージェントが過去の問い合わせやヘルプページを検索し、回答をスレッドに投稿しています。
  • 2026年下期(2026年7月〜12月)の成果目標として、CREユニットが担当する技術的な問い合わせの50%を、CREメンバーの介在なしでクローズできる状態を掲げています。2026年下期には労務管理を含む5つのプロダクトへの対応を目標としています。

詳細

DESK AIエージェントとは

DESK AIエージェントは、SmartHRのプロダクトに関する問い合わせに対して、必要な情報を調査し、回答するAIエージェントです。DESKは、SmartHR社内で「プロダクトに関する技術的な問い合わせ対応」やその窓口を指す呼称です。

現在は、SmartHRの労務管理領域のプロダクトに関する問い合わせを中心に利用しています。問い合わせ者(お客さまからの問い合わせを受けた社内のメンバー)がSlackの起票ワークフローでフォームに入力すると、ワークフローの1ステップとしてエージェントが呼び出され、問い合わせの内容を読み取り、過去の問い合わせやヘルプページを検索して、回答をスレッドに投稿します。起票ワークフローを経由せず、エージェントへ直接メンションして質問することもできます。最近では、起票前にメンションで質問し、問い合わせ者自身が解決に至るケースも増えてきたとのことです。

エージェントの役割は、単に検索結果を並べたり、もっともらしい回答文を作ったりすることではなく、問い合わせを解決するために必要な情報を集め、根拠とともに整理し、次に取るべき行動が分かる回答を返すことを目指しているとしています。

現在できていること

現在のDESK AIエージェントは、主に次の情報を利用して回答できます。

  • 過去にCREが対応した問い合わせの要約
  • SmartHRのヘルプページ
  • 問い合わせに関連する類似事例

過去の問い合わせには、プロダクトの仕様だけでなく、どのような状況で問題が発生し、CREがどのように調査・回答したかという実践的な知識が含まれており、エージェントがこれらの対応記録を検索できるようにすることで、CREメンバーが蓄積してきた知識を新しい問い合わせへの回答に活用しています。

一方で、現在のエージェントだけでは解決できない問い合わせも多くあります。例えば、お客さまごとの設定や利用状況を確認する必要があるもの、問い合わせ文だけでは情報が不足しているもの、複数の可能性から状況に応じて判断する必要があるものです。こうしたケースに対しては、情報源をやみくもに増やすのではなく、実際に解決できなかった問い合わせを分析し、必要性が高いものから調査手段を追加しているとしています。

目指しているのは「回答支援」ではない

開発当初、DESK AIエージェントは、CREメンバーが問い合わせに回答するためのサポート役という位置づけが中心でした。エージェントが回答案を作り、人間が内容を確認して投稿する関係です。

しかし、問い合わせの件数や対象となるプロダクトが増えていくなかで、人間がすべての対応の主体であり続ける運用には限界があるといいます。回答文を作る時間だけを短縮しても、問い合わせの受付、調査、追加質問、進捗管理、クローズまでを人間が担う構造は変わりません。

そこで、プロダクトに関する技術的な問い合わせ対応の主役を、人間からAIエージェントへ段階的に移し、CREメンバーが「問い合わせを処理する人」から「エージェントを評価・改善する人」へ移行することを目指しています。エージェントが問い合わせを受け付け、必要な調査や追加質問を行い、解決まで対応し、人間はエージェントの対応を観察・評価して、解決できなかった理由を分析し、次の改善につなげます。

ただし、エージェントがすべての問い合わせに無理やり回答することがゴールではありません。解決に必要な情報が足りない場合や、人間の判断が必要な場合には、回答できないことを適切に判断する必要があるとしています。そのうえで、調査したこと、分かったこと、不足している情報を整理して人間へ引き継ぐところまでを、エージェントの役割として考えているとのことです。

「エージェントが回答した割合」ではなく「人間の介在なしで解決した割合」を見る

エージェントの成果を考えるとき、単純な「回答数」や「回答を投稿した割合」は指標として十分ではないとしています。エージェントが回答を投稿しても、その内容で問い合わせが解決せず、最終的にCREメンバーが調査と回答をやり直していれば、問い合わせ対応を担えたとは言えないためです。

SmartHRは2026年下期(2026年7月〜12月)の成果目標として、CREユニット(CREメンバーが所属する組織単位)が担当するプロダクトに関する技術的な問い合わせの50%を、CREメンバーの介在なしでクローズできる状態を掲げています。

この50%という数値は、過去の問い合わせの内訳から積み上げて算出したものではなく、問い合わせの半分を人間の介在なしでクローズできれば、対応の主役がエージェントに移ったと実感できる水準だと考え、挑戦的な目標として設定したとしています。

残りの問い合わせは引き続き人間が担い、この目標はCREメンバーを不要にするためのものでもなく、複雑な判断やお客さまとの深い対話が必要な問い合わせにこそ人間の時間を使えるようにすることを意図しているとのことです。重視しているのは、エージェントが何かを回答したかではなく、問い合わせの受付から解決までを担えたかどうかであり、この目標を通じて、単なる回答生成機能ではなく、問い合わせ対応の一連の業務を担うエージェントへ進化させようとしています。

評価は、次に何を作るかを決めるためにある

エージェントの対応を人間が評価すると聞くと、回答に点数を付けたり正解率を測ったりする仕組みを想像するかもしれませんが、回答品質の確認は必要としつつも、評価の目的は次に何を作るべきかを決めることだとしています。

エージェントが解決できなかった問い合わせについて、例えば次の観点で理由を分析します。

  • 必要な知識が情報源になかった
  • 適切な情報を検索できなかった
  • お客さまごとの状況を調べる必要があった
  • 問い合わせ元への追加質問が必要だった
  • 回答できないと判断し、人間へ引き継ぐべきだった

「この情報があれば答えられた」「この調査手段があれば解決できた」という失敗パターンが見つかれば、それが次の開発テーマになるとしています。

実際に、提供を始めた当初のエージェントは、検索結果を提示するだけの回答が多く、それだけでは問い合わせを解決できなかったといいます。「問い合わせを解決すること」を回答の主目的に据えてプロンプトを改善したことで、質問に対して具体的な解決策まで踏み込んだ回答を返せるようになりました。

評価は開発後の品質チェックではなく、次の開発サイクルへの入力であり、評価の結果から次に追加する情報源やツール、改善する入力情報や指示が決まるとしています。

評価を支える仕組みづくりも進めており、現在は、エージェントの回答ごとにCREメンバーがボタンやリアクションでフィードバックを残せるようにしているほか、回答品質をLLM(大規模言語モデル)が自動で採点する仕組み(LLM-as-a-Judge)も導入しています。こうして蓄積したデータを、失敗パターンの分類や利用状況の可視化につなげる分析基盤は、まだ整備の途上とのことです。

小さく作り、実際の問い合わせから学ぶ

DESK AIエージェントの開発は、次のサイクルで進めています。

  1. エージェントの挙動を観察し、課題を見つける
  2. 改善案を小さく実装する
  3. 実際の問い合わせで利用する
  4. 利用状況と対応結果を観察する
  5. 評価結果から次の課題を決める

AIエージェントの開発では、技術の前提が短期間で変わるといいます。実際に、新しいモデルが公開されるたびに応答の比較や性能・コストの再評価を行い、エージェントで利用しているGoogleのLLMであるGeminiのモデルを更新するかを判断しています。モデルに限らずAI関連のツールやサービスの進化も速いため、比較検討を頻繁に行っており、状況によっては技術選定そのものを見直す可能性もあるとしています。また、AIエージェントを実際の業務で継続的に運用するためのプラクティスは、まだ確立されているとは言えないとのことです。

そのため、最初から完成形を詳細に設計するのではなく、小さく作って実際に使い、得られたフィードバックから方向を修正する反復設計を採用しています。

この方針は、開発初期の失敗から学んだものでもあるといいます。最初期には、Googleが提供するAIリサーチツールのNotebookLMや、Google Driveに置いた過去の問い合わせの要約ドキュメントをGeminiで検索して回答する仕組みも用意していましたが、利用するユーザーは増えず、当時の検索精度も十分ではなかったため、ほとんど使われなくなりました。最終的にこれらの仕組みはすべて使うのをやめ、Google CloudのAI開発プラットフォームであるGemini Enterprise Agent Platform(旧 Vertex AI)を使って自作する方針へ切り替えています。

DESK AIエージェント自体も、α版、β版と期待値を調整しながら提供を始め、1〜2か月ほど実際の問い合わせで改善を重ねたうえで、起票ワークフローに組み込んで正式リリースしました。エージェント本体だけでなく、検索対象となるデータの整備を自動化する周辺システムについても、最初から作り込むのではなく、必要最低限の実装から始めているとのことです。

問い合わせの全領域を一度に自動化するのではなく、まずは過去の事例やヘルプページから回答できる問い合わせ、次に追加質問が必要な問い合わせ、さらにお客さまごとの調査が必要な問い合わせへと、対応できる範囲を段階的に広げていく方針です。

ひとつのプロダクトから、複数のプロダクトへ

SmartHRは現在、労務管理領域の問い合わせを中心に、エージェントの回答・調査能力を深めています。一方で、特定のプロダクト専用の仕組みを作ることが最終目的ではないとしています。

労務管理プロダクトで見つかった失敗パターンや改善方法をもとに、プロンプト、情報検索、評価方法、運用方法のうち、他のプロダクトでも利用できる部分を共通化し、そのうえで対象プロダクト固有の情報源や問い合わせ特性を組み合わせられる構成を目指しています。

2026年下期には、労務管理を含む5つのプロダクトに関する技術的な問い合わせに、エージェントが対応できる状態を目標にしています。

ここでいう「対応できる状態」は、単に各プロダクトのDESKへエージェントを導入することではなく、次を満たすことだとしています。

  • 実際の問い合わせで継続的に利用される
  • 必要なナレッジや検索手段へアクセスできる
  • 対応結果を評価・モニタリングできる
  • 評価結果をもとに改善できる
  • 他のプロダクトで得た改善を横展開できる

これらを満たし、複数のプロダクトで継続的に改善できる共通基盤と導入方法を作ろうとしています。

CREの仕事はどのように変わるのか

エージェントが問い合わせ対応を担う範囲が広がると、CREの仕事がなくなるのでしょうか。SmartHRは、仕事がなくなるのではなく役割の中心が変わると考えているとしています。

個々の問い合わせを調査して回答することから、次のような仕事へ比重が移っていくといいます。

  • エージェントの対応品質を評価する
  • 解決できなかった理由を分析する
  • 次に追加すべき情報源や調査手段を決める
  • 問い合わせの傾向を把握する
  • 得られた知見をプロダクトの改善へつなげる

問い合わせ対応を通じてお客さまやプロダクトへの理解を深め、改善へつなげることは、これまでもCREが担ってきた役割であり、エージェントが対応作業を担うことで、CREはその上流の仕事に、より多くの時間を使えるようになるとしています。「エージェントが対応し、人間が評価する」という関係は、問い合わせ対応を効率化するためだけのものではなく、CREが本来注力したい仕事へ移行するための仕組みでもあるとのことです。

おわりに

DESK AIエージェントの開発は、問い合わせに回答するAIを作るだけの取り組みではないとしています。AIエージェントが実際の業務を担うようになったとき、人間は何を評価し、どのように改善し、そこで得た知見をプロダクトへ還元するのか、問い合わせ対応という実際の業務を通じてその働き方を模索しているとのことです。

現在のエージェントは、まだ理想に至る途中であり、人間が対応しなければ解決できない問い合わせも多く、評価やモニタリングの仕組みも整備を進めている段階だといいます。今後は、どのようなシステム構成や手法でエージェントを開発しているのか、試行錯誤の過程やそこから得た知見についても、技術ブログで共有していく予定としています。