『メールディーラー』へのAI機能実装─"20年"の歴史を持つ製品への導入プロセス / rakustechcon2025-maildealer

by Rakus_Dev

Slide 1

Slide 1 text

「メールディーラー」へのAI機能実装 ──"20年"の歴史を持つ製品への導入プロセスメールディーラーAI開発課メールディーラー開発課神山賢太郎廣部知生

Slide 2

Slide 2 text

・22年4月からラクスにジョイン・色々やります　　PMM-デザイナ-開発との調整役　　要望調査　　プレ技術調査　　ロードマップ作成　　競合分析、失注・解約理由分析　　要件定義（最近はもっぱらレビュー）　　など... 神山賢太郎登壇者紹介

Slide 3

Slide 3 text

・21卒としてラクスに新卒入社・要件定義や設計、実装だけでなく、運用やサポート対応など幅広く　担当してます・趣味：ストリートファイター6 廣部知生登壇者紹介

Slide 4

Slide 4 text

メールディーラーとは？ 4  メール共有管理システム 16年連続シェアNo.1（2009～2024）※ 歴史は更に長く、2001年4月に販売開始 ※出典：ITR「ITR Market View：メール／Webマーケティング市場2025」メール処理市場：ベンダー別売上金額推移およびシェア（2009～2024年度予測）

Slide 5

Slide 5 text

メールディーラーとは？ 5 

Slide 6

Slide 6 text

世はまさにAI戦国時代 6 

Slide 7

Slide 7 text

メールディーラーが負ける？〜忍び寄るディスラプト〜

Slide 8

Slide 8 text

楽楽精算とは？法制度ニーズにより急成長電子帳簿保存法の改正やインボイス制度への対応が求められたことにより、システムによる対応のニーズが高まったことで近年急成長を遂げたプロダクト（成熟期に差し掛かる） 8

Slide 9

Slide 9 text

メールディーラーが負ける？〜忍び寄るディスラプトビジネスサイド・Geminiがすごい！自動でメールが書ける！・うかうかしているとディスラプトされる！・いち早く開発を進めよ 9  ※ディスラプト：新しい技術やビジネスモデルが登場し、既存の業界や市場を揺るがし、既存の企業やプレーヤーを脅かす現象ビジネスサイドと開発サイドのスピード感のずれ

Slide 10

Slide 10 text

メールディーラーが負ける？〜忍び寄るディスラプト開発サイド・Geminiのメール作成、使ってみたものビジネスメールとしては... ・ディスラプトされるってほんと？・他にもやることがある中で売れるかわからないのに優先度あげるべき？ 10  ※ディスラプト：新しい技術やビジネスモデルが登場し、既存の業界や市場を揺るがし、既存の企業やプレーヤーを脅かす現象ビジネスサイドと開発サイドのスピード感のずれ

Slide 11

Slide 11 text

メールディーラーが負ける？〜忍び寄るディスラプト大きめの展示会に2週連続で参加　・AIエージェントエリアが大盛況 →ラクス製品はそこに全く入り込めていない... 11  ディスラプトされた世界を体感

Slide 12

Slide 12 text

ディスラプトされた世界とは 12 

Slide 13

Slide 13 text

製品を使うきっかけ（フック）を作り出せない＋製品を使い続ける価値（ロック）がない状態 13 

Slide 14

Slide 14 text

メールディーラーを使ってもらえない ↓ データが貯まらない ↓ 業務改善に活かせない 14 

Slide 15

Slide 15 text

最優先でディフェンスする！！ 15 

Slide 16

Slide 16 text

最優先でディフェンスする！！ 16  が、メールディーラーの開発スタイルはウォーターフォール ↓ 関係者多数・承認プロセス多数 →開発〜リリースまで時間がかかる

Slide 17

Slide 17 text

最優先でディフェンスする！！ 17  どうすれば早くリリースできるのか

Slide 18

Slide 18 text

製品の強み・打ち出す価値の整理 18  メール共有管理システムからナレッジデータ※を軸にした問合せ削減システムへシフト ※メールディーラー内の過去のメールデータや外部の FAQなどメールディーラー統合型ナレッジDB メール応対フォームチャットボット FAQ ナレッジB メール応対フォームチャットボット FAQ ナレッジC ナレッジ A Before それぞれが独立。ナレッジが点在し、メンテナンスコストが増大 After メールからナレッジが自動抽出されすべてのコンテンツに適用されるメンテナンス不要のナレッジ基盤

Slide 19

Slide 19 text

19  早期リリースするために意識したことパーキンソンの法則〜人は与えれらたリソースを最大限使おうとする〜　　開発期間をフルに使おうとする　　→市場は常に変化している。スピード感を持って開発を推進する必要がある。　　・ビジネスサイドからのリリース時期要求に対して、どうすればそれよりも早く出せるのかを考える。・MVPなどゴールを決め、最速で到達するためのやり方を考える与えられた納期より早く

Slide 20

Slide 20 text

20  早期リリースするために意識したことパレートの法則〜結果の80%は20%の要素から生まれる〜　　最初は20％の出来でいいので、まずはチャレンジ　　→チャレンジを繰り返すことで自身・組織のナレッジが溜まっていく　　・つぎはもっと早く、もっと筋の良いアウトプットが出せるようになるすぐにチャレンジする

Slide 21

Slide 21 text

21  製品の強み・打ち出す価値の整理メールディーラーの強み →高品質な”問合せ対応”業務ができる →”問合せ対応”業務をラクにする　∟問合せの数を削減する　 ∟問合せ対応の稼働を削減する方向性を決める

Slide 22

Slide 22 text

スコープと優先度の検討 22  問合せを種別に分け、優先度をつける →簡単な問合せに対する回答削減と問合せ業務の稼働削減からチャレンジ今できることを決める問合せ簡単な問合せ難しい問合せ過去の問合せ履歴が使える過去の問合せ履歴が使ない

Slide 23

Slide 23 text

スコープと優先度の検討 23  問合せを種別に分け、優先度をつける →簡単な問合せに対する回答削減と問合せ業務の稼働削減からチャレンジ今できることを決める

Slide 24

Slide 24 text

24  ・問合せの数を削減する　→問合せフォームに入力された質問への回答候補表示エージェント・問合せが入ってきた後への対応　→過去の問合せ履歴を活用した自動メール作成エージェントスコープと優先度の検討ゴールを決める

Slide 25

Slide 25 text

回答候補表示エージェント　　「FAQを見れば解決できるレベル」の問合せの減少 25  スコープと優先度の検討ゴールを決める

Slide 26

Slide 26 text

自動メール作成エージェント　　「FAQや過去の履歴を参照すれば解決できるレベル」の問合せにする自動返信メール作成 26  スコープと優先度の検討ゴールを決める

Slide 27

Slide 27 text

27  ・メールディーラーのAI開発に特化した課を新設　→完全アジャイル開発にシフトし、価値の可視化と改善サイクルの　　　高速化に着手・βユーザを募ってトライ→結果ヒアリング→改善（クレーム検知機能）・依頼や相談はフランクに、すぐに実施・顧客ヒアリングは週1ペース。基本みんな参加し、解像度を揃える　・お客様の課題、代替手段、ペインの強弱　・検討中のUI、検証中の精度がお客様に受け入れられるのか？　・今後検討が必要そうな課題の抽出 PMM  デザイナ  PdM  (開発)  開発サイクルの高速化 PMM：プロダクトマーケティングマネージャー(Product Marketing Manager) 　　　主に製品の企画を担当する。 PdM：プロダクトマネージャー　　　主に、製品ロードマップの整備とPMM・デザイナ・開発との橋渡しを担当する

Slide 28

Slide 28 text

28  製品コンセプトの作成マーケ観点での情報整理　・競合他社の状況ウォッチ　・提供形態　・顧客ヒアリング営業／カスタマーサクセスチームと迅速に連携 →お客様の反応を収集開発サイクルの高速化（PMM） PMM  デザイナ  PdM  コンセプトを具体化

Slide 29

Slide 29 text

29  ・ペライチ、雑コラレベルのモック作成　→ゴールが可視化されていればみんな同じ方向で議論できる。・アイデアのトライ、提案　　まずは手を動かしてみてあたりをつける・プロトタイプ作成・バックエンド：Python ・フロントエンド：Tampermonkeyスクリプトほぼ全てGPTで作成。・プロンプト：ひたすらトライ&エラー・検証結果、精度の共有　　→どう提案するか？どう見せるかをPMM・デザイナと検討開発サイクルの高速化（PdM） PMM  デザイナ  PdM  アイデアを具体化

Slide 30

Slide 30 text

30  顧客ヒアリングの結果と精度の両面からみて、「どうお客様に機能を見せるか？」を検討 →カスタマージャーニーの整理 →モック作成 →各方面からのFBを収集し迅速に対応フロントエンドエンジニアとの密に連携開発サイクルの高速化（デザイナ） PMM  デザイナ  PdM  機能を具体化

Slide 31

Slide 31 text

31  軽く作成したプロトタイプリリース時のデザイン回答候補エージェントのプロトタイプ

Slide 32

Slide 32 text

32  メール作成エージェントのプロトタイプ軽く作成したプロトタイプリリース予定のデザイン

Slide 33

Slide 33 text

スケジュール見直しこれらの施策により大幅にスケジュールを短縮 33  2026年3月 2025年10月 2025年10月 2025年6月回答候補表示エージェントメール作成エージェント

Slide 34

Slide 34 text

34  実装者への引き渡し PMM  デザイナ  PdM  実装者   ある程度具体化できた状態になれば背景知識、要求、顧客ヒアリングの結果、コンセプト、プロトタイプを実装者に連携

Slide 35

Slide 35 text

PdMから開発へ引き継ぎ PdMが作成してくれた要件定義とプロトタイプを引き継ぎ、設計を始めるが、メールディーラー特有の課題が浮き彫りに 35 

Slide 36

Slide 36 text

メールディーラーとは？（再掲） 36  メール共有管理システム 16年連続シェアNo.1（2009～2024）※ 歴史は更に長く、2001年4月に販売開始 ※出典：ITR「ITR Market View：メール／Webマーケティング市場2025」メール処理市場：ベンダー別売上金額推移およびシェア（2009～2024年度予測）

Slide 37

Slide 37 text

メールディーラーはレガシーシステム 2001年4月に販売開始 →既に20年の歴史がある Laravelは2011年リリースなので、10歳年上典型的なLAPP構成（Linux, Apache, PostgreSQL, PHP）で動作しており、単一サーバ上でほぼすべての機能が稼働する巨大なモノリシックアプリケーションとなっている。 37 

Slide 38

Slide 38 text

メールディーラーとプロトタイプのギャップ AIまわりの技術はPythonが多い　→プロトタイプもPythonで作成されていたリリースまでの時間を考えるとノウハウのないPythonで保守運用まで含めて設計、実装するのは難しい →特に、巨大なモノリスに新しくPythonをインストールして　 PHPと連携させるような作りは避けたい 38 

Slide 39

Slide 39 text

AI機能がメールディーラーに与える影響 AI機能は、メールディーラーの根幹をなすメール送受信機能に影響が出やすい例えば…… ● 受信したメールをAIで解析したい！ ○ 不具合があると、メール受信できなくなる ● 返信文をAIに考えてほしい！ ○ 不具合があると、メール返信できなくなる 39 

Slide 40

Slide 40 text

AI機能がメールディーラーに与える影響メール共有管理システムでメール送受信できなくなるとお客様の仕事が止まるできる限りAI機能を独立させ、主幹機能に影響がないようにしたい！ 40 

Slide 41

Slide 41 text

技術選定からスタート！ 41 

Slide 42

Slide 42 text

技術選定選定ポイントは以下の通り ● 既存システムから独立して動かせること ● メールディーラー内で採用実績があること ○ スピード感を持った開発のために重要視 ● 今後のAI開発でも使えること 42  🤔

Slide 43

Slide 43 text

技術選定 JavaScript（Node.js）を採用！ ● APIサーバを構築すれば独立して動かせる ● さらに、APIサーバの構築実績もあり ○ スピード感を持った開発が期待できた ● OpenAI、Gemini、Claudeといった幅広い生成AIの公式ライブラリも存在し、将来的にも使っていけそう 43 

Slide 44

Slide 44 text

あとはひたすら開発 44 

Slide 45

Slide 45 text

設計商材特性に合わせたAI利用時の設計を整理していくメールディーラーで特に考慮した点は以下の通り ● メール受信などの遅延が発生しては困る箇所で利用する際は、タイムアウトなどを厳密に設定していく ● メールの大量受信による想定外の高額請求防止の為、内部的に上限を持ち、制御する設計に 45 

Slide 46

Slide 46 text

実装　メールディーラーではオフショアを採用していて　オフショアといっしょに開発しはじめたのは2014年と、実に10年以上メールディーラーに携わってくれている　　そのため既存技術は素早く実装できるが、ノウハウがない機能の実装には時間がかかる傾向もあった 46 

Slide 47

Slide 47 text

実装既存技術で実装できるメールディーラー側はオフショア先に依頼例：設定画面やAPI呼び出し部分など新しい技術を利用するAPIサーバ側は日本で実装役割分担を適切に行い、オフショアと並行実装することでスピード感を持って実装を進められた 47 

Slide 48

Slide 48 text

リリース！ 48 

Slide 49

Slide 49 text

● PDCAサイクルの高速化 ○ 顧客に提供する価値を決め、優先度をつける ○ プロトタイプを素早く作る ● 適切な技術選定と役割分担 ○ 技術スタックを活かす ○ チームの特性を把握し、強みを活かすまとめ

Slide 50

Slide 50 text

ご清聴ありがとうございました。 50 