生成AIを使って割り込み業務を現場で勝手に改善したらちやほやされた話

こんにちは。2019年と2024年に記事を書いていた山本です。ますます元気にモノタロウで働いております。

さて、毎日、散発的に、突然やってくる割り込み業務って、地味～に疲れますよね。そんな負担がかかっているチームメンバーたちを少しでも楽にするため、生成AIを活用して業務改善をし、我ながら見事な成果を上げたものの、全然スマートじゃない野暮な設計をしているのが恥ずかしくて、公表と展開はチーム内だけに留めていました。

当社の生成AI活用のレベルが高いのは、他のブログ記事をご覧になれば分かると思います。これらに比べたらショボすぎて、恥ずかしかったのです。 tech-blog.monotaro.com

しかし、AI駆動開発チームのリーダーの市原さん（この記事の人）に何故か見つかってしまい。
意外なことに「すごい発想！面白い！」と褒めちぎられ、「すごいから社外カンファレンスで発表しましょう！」と神輿に担がれ、気づいたら2025年秋のAI駆動開発カンファレンスに登壇していました（超展開）

登壇後、会場やSNSにて、驚きの声や賞賛の声をたくさん頂き、とても嬉しかったです。登壇の機会を下さった主催の皆様、当時SNSで発表を盛り上げて下さった皆様、ありがとうございました。

さて、本記事は、カンファレンスの発表内容を記事として再構築したものです。発表内容にかなり加筆しているので、よかったらご覧ください。
（発表当時に使用したスライドはこちら。私のパートは27～52スライドです）

これと似たようなの見たことある気がする……　を自動化する

私は自チームの問い合わせ対応業務を改善しました。
改善した結果、現在どのような運用になっているかという実例を先にご紹介します。仕組みはあとで解説します。 ↑OSL（法人向け集中購買サービスのONE SOURCE Lite）をご利用のお客様から、営業チームやカスタマーサポートチームが問い合わせを頂き、その一部、システムに関する問い合わせが、私たちのチームに転送されます。
私たちは調査をおこない、回答は営業さんを通じてお客様にお伝えするという流れです。

自チームが調査・回答するところをAIに手伝ってもらえないかと考えました。

↑営業さんから転送が発生すると、このスクリーンショットのようにSlackで自動通知されます。これは承認依頼メールの不達に関する問い合わせですね。

この投稿に、特定の絵文字でリアクションをつけますと、↓以下の内容の自動投稿が20～30秒程度で投稿されます。 この投稿内容を考えてくれているのが生成AI、今回はOpenAIのAPIです。
先頭に「過去の問い合わせ履歴のうち、内容が似ている事例」とあるとおり、今まで私のチームで対応したことのある問い合わせの履歴のうち、今回来た新しい問い合わせに似ている履歴をランキング形式で投稿してくれています。

内容を見てみると、いずれも、承認依頼メールの不達に関する内容ですね。

ということは、これらの「前回対応分」と同じ対応を今回もすればいい、ということが分かりますので、調査メンバーは、前回と同じく「メール送信ログの調査」を行えばいいわけです。

もし、ログ調査の仕方が分からなければ、Slackのリンクを開けば当時の対応者が誰なのか分かるので、その人に聞けばいいし、
そして、送信ログが見つかれば、前回の回答内容はSlackのリンクを開けば見つかるので、参考にすればいいわけです。

約4割の問い合わせは「よく見るやつ」または「前にやったことあるやつ」なので、割と気楽に対応することができます。
提案精度は非常に高いです。

「何その魔法！？」「何って……意味ベクトルをスプシで管理するようにしただけだが？」

では、どのような仕組みでSlackの自動投稿がされるのでしょうか。以下が概要図です。

肝となる部分は意外にもスプレッドシートです。

• Slack → Zapier → スプレッドシート
  • お客様から来た問い合わせが、システム部門に転送される。
  • 問い合わせ担当者が、自身に割り振られた問い合わせのSlack自動投稿に絵文字を手作業でつける。
  • Slackの特定チャネルで特定の絵文字がついた事をトリガーに動くZapが、絵文字がついた投稿の内容をもとに、必要事項を問い合わせ対応履歴管理シートというスプレッドシートに転記する。
  • このとき、同じスプレッドシート内の「Zap-GAS連携用」というシートにも必要な内容を書き込んでおく。
• スプレッドシート → GAS → OpenAI → GAS → Slack
  • 毎分起動のスクリプトが、「Zap-GAS連携用」が1分前と同じ内容かどうかを監視しているため、Zapの書き込みに反応し処理を開始する。
    • ※本当はonEdit()で監視したかったが、人間ではない操作による更新にはonEdit()は反応しない仕様らしくて断念した。
  • 新たな問い合わせの文章をOpenAIに送信し、
    • まずその問い合わせをいい感じに1文に要約する。
      • ※要約することで、あいさつ文や専門用語のぶれ、具体的な企業名・商品名といったノイズを消すことができる。
    • 次に、その要約文の意味ベクトルを取得する。
      • ※モデルは text-embedding-large-3（3072次元！）
  • 過去の全問合せのそれぞれの要約とそのベクトルはあらかじめ取得してあり（毎日深夜1回起動）、問い合わせ対応履歴管理シートの右端に記録してあるので、それぞれとのコサイン類似度を計算する。
  • さらに、新たな問い合わせの文章と過去の文章のキーワード一致率を、簡易的な2-gramで比較する。
    • ※要約時に消えてしまった専門用語による情報を補完する目的。
  • コサイン類似度とキーワード一致率をいい感じに足し合わせて、数値の大きい順に並べ、類似率が0.5以上の事例を最大5件、Slackに投稿する。
    • ※今は適当に、コサイン類似度 * 0.8 + キーワード一致率 * 0.2

そもそも改善を検討するよりずっと前から、対応履歴を記録するスプレッドシートが存在したため（以下はそのサンプル）、それらをすべて要約して意味ベクトル化することで、改善導入時点で既に十分な量の「前例データ」が溜まっていたわけです。（当社の、マメに記録して知見を資産にする文化のおかげ）

あとは、問い合わせ対応をやればやるほどデータが増え、提案能力が高くなっていくのです。

評価ポイント

▪1日で作った

小さなことでもいいから生成AIに手伝ってもらえないかなと、なんとなく設計を思い描いてから、ChatGPTで指示を出しまくってGASを1日で完成させました。私はインラインコメントしか書いていません。いや～、いい時代ですね。

↓余談ですが、設計当時に自分の脳内整理のためにホワイトボードに書き出して撮影したのが残ってました。ほぼ完成形です。 ↓実装当時のGPT-4oとの相談コンテキストを読み返してみると、あまりにもスムーズに行って感動したのか、最後に「ありがとうございました」と労っていました。 生成AIにコーディングを丸投げして書かせたコード（全450行）を、ろくにテストもせずにリリースするなんてことは、普通なら許されませんし、許されても保守性が低く負債になりがちです。
これが許されたのは、このツールは現場でしか使う予定がないからです。現場の問題を現場でAIで解決するならば、こんなんでいいと思います。

▪当番の負担減

誰でも問い合わせ対応に入れるようになりました。
誰でも、というのはそれこそ入社1か月の新米メンバーでも、という意味です。当社システムに詳しくない状態でも、過去に類似例があれば真似すればよく、その類似例は自動で出力されてくるので、特別な訓練や指導が必要ありません。

対応に慣れた当番についても、類似例を探す手間が減りましたし、「類似例が提案された」ということは「回答実績がある」事が確定しているので安心して参考にできます。割り込み対応の気が楽になって、好評でした。

▪GASだから何もかも楽

環境を用意したり、デプロイしたりが不要なGASを採用したため、導入コストがとても安いです。OpenAI APIの利用料はかかりますが、問い合わせは日に平均して1～3件のため軽微と言えるでしょう。

また、当チームと同じように対応記録をまめにつけているチームであれば、GASをコピペして少し調整するだけで展開できます。近所のチームには、以下のようにスプシに提案を出力する形式で機能提供しました。

▪勝手に進めて良かった

この改善の導入時に自チーム以外と調整が不要でした。というのも、回答作業を全部生成AIに任せるなら、関連部署への説明・合意が必要ですが、あくまで私たちの裏側に生成AIが増えただけなので、調整がいらないんですね。
だからこそ、私の一存でさっさと導入し、導入後はチームメンバーとの軽い相談だけで改善サイクルをすみやかに回すことができました。

営業チームへの回答文作成を人間の責務にしたことにより、生成AIの長所だけを活かせている点が、私はお気に入りです。
「似た質問を探す」というAIの得意分野をお願いしているのでとても頼もしいし、一方でハルシネーションリスクがありません。

改善ポイント

• バージョン管理していないため、改修をDevinやCursorに一任できていません。GASなので一工夫すればできますが、その一工夫が面倒くさくて……ちなみに、私はいちいちGASの関数をChatGPTにコピペして改修指示を伝えて、直してもらい、またコピペして関数を上書きしている（怖い話）
• 対応記録シートがあることが前提の設計なので、記録がないチームには展開できません。
• 今は過去対応履歴が300行しかないので、GASの実行時間は短時間（10秒前後）で済んでいますが、増えるにつれパフォーマンスに問題がある設計をしています。一行ずつコサイン類似度を計算し、一行ずつ2-gramしているからですね。雑すぎるだろ。
• 調査と回答文作成は人間の仕事なので、そこは割り込み業務として重いままです。気軽な導入とトレードオフではあるものの。
• 今の実装で正確な検索ができているのか、客観的指標がありません。役に立っているかどうかは、メンバーの肌感で計るしかなく、中期的な改善に踏み切れずにいます。まあ、いくつか手は思いつくので直にやります。

まとめ

こうして自分の取り組みを客観視してみると、
そもそもこの改善スピードの速さに、モノタロウの良い文化が出ているように思いました。

当社のサイト運営にまつわる開発部門は、どのチームも問い合わせ対応業務をサブ業務として持っており、お客様に対する回答の的確さとスピードを保てるなら、運用は各チームの裁量に任されています。
現場の問題を現場で解決していいし、むしろ現場で課題感を掴んだなら自分らで対策を練るのは当然と映る。
サブ業務だからとやりっぱなしにしないし、改善フローがまだ組めてなくても将来のために記録を残す。

だから、改善のPoCを現場判断で始めて良くて、
PoCが初動から効果を発揮することが多いんですね。

そして、この土着の行動様式は、

• 小さく試す
• 現場でPDCAを回す
• 初めから完璧を求めず育てる

といったAI駆動開発の哲学と相性が良いはずです。

ああ、なるほど……冒頭の話に戻りますが、AI駆動開発チームリーダーである市原さんが喜んでいた理由が、ようやく分かりました。技術的な興味深さだけでなく、こうした草の根的成功が自身の知らない間に成されていたのが嬉しかったんですね。
綺麗なお庭を作りたくてお世話してたら、まだ種を撒いていない花壇で野良のコスモスが咲いていたような。

であれば、私はこの改善で満足せず、次のアイディアを探しに行きましょう。「こんなんでいいんだ」と実感したことで、自分の中のハードルが下がった気がします。センスのいい発想なんて、生成AIを壁打ち相手にして思考し続ければ、いつかはきっと出てきますからね。

最後まで読んでいただき、ありがとうございました。

MonotaRO では一緒に開発生産性の向上を推進していく仲間を募集しています！もしご興味がありましたら、ぜひお気軽にお声がけください。カジュアル面談もやっています！