BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

AI による業務改善の1年の振り返り

こんにちは！CSE Group でエンジニアをしている上野です。

この記事は BASE AdventCalender の13日目の記事です。

12日目は kagano さんの GitHub Copilot の Custom Instruction でのコードレビューについての記事でした。この 1 年は AI に関する話題、特に Coding Agent の話題がたくさんありましたね。日々モデルも機能も進化していて、今どこの AI は何ができるんだっけ？と迷子になってしまっているので、私自身参考になりました。

さて、BASE AdventCalender 13日目のこの記事でも AI についての話ですが、開発業務以外の業務改善について、この1年間の取り組みをお話します。

はじまりから PoC 期

はじまり

2025年に入る前から各個人や部署毎で生成 AI のサービスを積極的に試したり導入してみたり、ということはされていましたが、2025年の頭から、会社としてしっかりと生成 AI を使っていこうという方針が打ち出されました。

私の所属する CSE は社内の業務改善をエンジニアリングで支援するチーム*1 ですが、このときの方針としては CSE に依頼しよう、ではなく各部門で業務を効率化できるようにしていこう、という流れでした。しかし、CSE としてなにかしようというものではなかったのですが、いずれはなにか依頼があるであろうということを見越し、CSE でも準備をしていくことにしました。

そこでまずは生成 AI を利用した簡単なアプリケーションを実装したり、SaaS などを検討したりしてみよう、という事になりました。

いくつか実装するアプリケーションの案はあったのですが、

  • ナレッジが整備されている
  • 問い合わせの Slack チャンネルでも問い合わせが多く、ある程度の効果が見込める

という2点から人事・労務の質問回答 Bot を作成することにしました。

AI Chat Bot の PoC

各種サービスの検討

作成するものが決まったため、次にいくつか SaaS などを比較検討をしました。

また、汎用的に使用できるということで Dify と、Amazon Bedrock も比較対象としました。

そこでのなかで挙がったそれぞれのメリット、デメリットなどを紹介します。

検討対象 メリット デメリット
SaaS 製品 簡単な設定ですぐ構築できる
ダッシュボードなど、必要な機能も利用可能 		Chat Bot 以外でやりたいことがでてきた際にできないことも多い
価格は比較的高い
Dify 色々な人がワークフローを構築できる 会社で使用する場合、SaaS版ではなくセルフホスト版を使用することになり、メンテナンスコストがかかる
社員全員に開放する場合、Notionにあるナレッジのセキュリティが課題
Amazon Bedrock Agent、KnowledgeBase 柔軟に構築が可能
コストも低い 		キャッチアップが必要
構築の工数は高くなる

上記のメリット・デメリットを勘案し、長期的な視点では技術力を持っている必要があること、単純な Chat Bot だけではなく今後業務に組み込まれていくであろうことをから、Amazon Bedrock で構築していくことに決定しました。また、Chat Bot への問い合わせのインターフェースは Slack としました。これは「ナレッジが Notion にあるのであれば、構築をせず NotionAI でよいのでは」という考えもあったものの、NotionAI で各個人が人事・労務の情報を確認してしまうと、ハルシネーションによる誤った情報だった場合人事担当がキャッチできないこと、オープンな場で質問することで他の人に見えないことで情報が個人で閉じてしまうことがあるため、Slack のオープンな場での問い合わせをするようにしました。(当然人事関連の問い合わせは非公開であるべきものもあるため、そういうものは既存のクローズドな問い合わせ窓口を利用してもらうよう案内しました。)

実装

実装するアプリケーションは以下のようなアーキテクチャとなりました。また、今回は Notion のデータを Bedrock KnowledgeBase に取り込みましたが、PoCということで継続的に更新するなどの仕組みは作らず、ダウンロードをして S3 に配置し、そのバケットを Bedrock KnowledgeBase で読み込むという単純なものにしました。

PoC 結果

PoCの結果、PoC 期間の約1ヶ月間で、問い合わせの件数が46件、正答率が 70%(32件/46件)、誤答の分類としては

  • ナレッジの記事の内容が曖昧だった(ナレッジの課題)
  • 質問内容について明記されていない、記事がなかった(ナレッジの課題)
  • ナレッジの画像に情報がありAIが参照できなかった(技術的課題)
  • 別の記事の内容が参照されてしまった(技術的課題)
  • 古い記事の内容が参照されてしまった(ナレッジの課題)
  • その他(ハルシネーションなど)

学び

PoC の結果から以下のような教訓、学びが得られました。

  • 少し曖昧であったり、抽象的な書き方の記事でも、人が読むとある程度行間を読んだり、入社時の研修で案内されていたり質問ができていたため補完されていたが、AI は前提知識がなにもないため誤った解釈をしてしまう事がある。
  • プロンプトや KnowledgeBase の RAG の設定はあまり凝ったことはしていないがある程度の正答率が得られ、生成 AI の力を改めて感じた。
  • 過去の記事を参照してしまうなど、AI活用にはまずデータの整備が大事だと痛感した。

CS の問い合わせ改善プロジェクト

はじまり

PoC を進めていた頃と並行して、CS チームから「今後 CS の業務を AI で改善するだけでなく、AI 前提の業務に変革したい」という相談がありました。その中で、まずは工数がかかっている「問い合わせを一部委託しているパートナーからのエスカレーションの対応を AI で一次受けする AI」(以下エスカレーション AI) の依頼がありました。

こちらについても NotionAI などで代替できないかなどの検討を行ったところ、契約の関係上NotionAI を利用できず、また AI への一次エスカレーションの内容を弊社社員も確認できるようにしておきたいという要件、PoC で構築した仕組みと同等のものを転用できるということで、Slack をインターフェースに、ナレッジを参照して回答するAIを実装しました。

実装について

Slack から AI への問い合わせ部分実装は PoC の仕組みとほぼ同じですが、PoC ではなく日々ナレッジが更新されていくため、Notion のデータを日次で S3 にアップロードし、その後 Bedrock KnowledgeBase のデータソースを再同期するという仕組みを構築しました。

また、当時 Notion のインテグレーションの作成はワークスペースオーナーのみができましたが、インテグレーションを記事にコネクトする操作 (つまりインテグレーションに読み込む許可をする操作) は任意のユーザーが、そのユーザーがアクセスできる任意のページ・データベースに可能でした。これにより、もし誤って社外秘の情報をコネクトしてしまった場合、AI がその情報を読んでしまい、意図せず情報が流出してしまうという課題がありました。( 現在はワークスペースオーナーのみがコネクトを許可する設定が実装され、この課題は解決されています。 )

そのため、Notion の記事連携機能部分では、Notion のホワイトリスト方式でデータベース ID、ページ ID を設定し、Pull Request でのレビューを必須とすることで意図しない記事の連携を制御するようにしました。 アーキテクチャは以下のようになりました。

効果

エスカレーション AI の実装により、以下のような効果が得られました。

  • 約200件/週 のエスカレーションの20~30%削減ができた。
  • また、可能性として「BASE 側の工数が削減されたが、パートナー側でナレッジを確認したりなどの工数が発生しており、負担が移っただけではないか」という事も考えられましたが、CS のマネージャーに詳細をヒアリングをしたところ、そうではなく純粋にこの効果を得られた、とのことでした。

ヘルプページ改善プロジェクト

はじまり

前述のエスカレーション AI が無事本番運用された後、次は CS で工数のかかっていたヘルプページの AI による改善の相談があり、そのプロジェクトが開始しました。 ヒアリングをする中で、以下のような状況や課題が見えてきました。

  • 状況
    • PRD から仕様書や SOP の生成は NotionAI である程度自動作成ができていた
    • 元々PRD、仕様書、SOP はすべて Notion で管理されており親和性が高かった
    • しかしヘルプページは zendesk にしか存在していなかった
  • 課題
    • ヘルプページが Notion になく、仕様書や SOP の作成後、どのヘルプページを更新すべきか検索が難しく、工数がかかり更新漏れもあった

そこで、まずはAIで更新するなどの前に、Notion にヘルプページをもってきて、SSoT (Single Source of Truth) とする、その後 SOP や仕様書とヘルプページを紐づけることで、まずは管理ができるようにするよう提案し、その後紐づけたデータを NotionAI が参照し、内容を作成するという形で進めました。

技術的な部分

ここでは NotionAI を用いたため実装は zendesk の API を実行する Lambda など多くはありませんが、Notion 上での設定などを簡単に紹介します。

  • ドキュメントがすべて Notion にあるためすべて情報を Notion に集約し、 AI は NotionAI を使用
  • zendesk のヘルプページはセクション ID が必須なため、セクションの情報も同期するように構築
  • 仕様書、SOP、ヘルプページのデータベースで、それぞれリレーションを設定し、紐づいているドキュメントを NotionAI が読み込み記事を生成
  • ヘルプページの完全自動公開は NotionAI の仕様上現状は難しいが、プロンプトを管理して最低限の操作で生成するように構築
  • ヘルプページについてはユーザーの目に触れる部分のため必ず人が最終チェックをしてから公開するようにしている

学び

このプロジェクトは最近のもののため、具体的な数字としての効果はまだ得られていませんが、進める中で以下のような教訓や学びを得られました。

  • AI でなにかをやりたいという要望でも、しっかりと業務や課題を洗い出して課題を解決するというのは大事
  • AWS Bedrock Agent Core など、気になる技術はたくさんあるものの、それにこだわらずに、既存のツールで工夫することも時には大事

おわりに

大変だったこと

この1年間業務改善に生成 AI を適用するという取り組みを進めてきましたが、(きっと同じことをしている多くの人が感じているであろう)大変なこともありました。そのうちの全てではないですがいくつか紹介します。

  • 生成 AI のモデルや各社の機能拡充の対応速度が早く、実装してすぐ不要になる機能があったり、前提が変わったりしてしまうこと
    • モデルだけでなく色々な機能(AI ワークフローや各種ドキュメントシステムとのナレッジ連携など)も次々でてきて、今実装しているこの機能は不要になってしまうのではないか、という不安はいつもつきまとっていました。
    • そのうえでどれにベットするのか、というのを考えるのが非常に難しかったです。(複数人が使用する業務システムなので、頻繁に「やっぱりこっちに変えます」ということはできないため。)

この記事では、この1年間、BASE の CSE チームが生成 AI の業務改善への適用の取り組みを紹介しました。まだまだこの記事には書ききれなかった紆余曲折ややったことなどもありますし、もちろん昨日の記事のように BASE のアプリケーション開発での AI の取り組みなどもあります。興味を持っていただいたら、採用情報をご覧ください！

採用情報 | BASE, Inc. - BASE, Inc.

明日は 02 さんの「数百万行でも怖くない！MySQL INSTANT DDLで「完全無停止」カラム追加」の記事です！以前 gh-ost の記事もありましたが、それとの違いや技術選定についてなど気になりますね！お楽しみに！

*1:CSE チームについての説明はこちらの記事や、今年のアドベントカレンダー17日目の記事をご覧ください。