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

◆イベント名
RAKUS Tech Conference 2025
https://techcon.rakus.co.jp/2025/

◆発表タイトル
『メールディーラー』へのAI機能実装─"20年"の歴史を持つ製品への導入プロセス

◆登壇者
メールディーラーAI開発課 神山賢太郎
メールディーラー開発課　廣部知生

Transcript

1. 「メールディーラー」へのAI機能実装 ──"20年"の歴史を持つ製品への導入プロセス メールディーラーAI開発課 メールディーラー開発課 神山賢太郎 廣部知生
2. ・22年4月からラクスにジョイン ・色々やります 　　PMM-デザイナ-開発との調整役 　　要望調査 　　プレ技術調査 　　ロードマップ作成 　　競合分析、失注・解約理由分析 　　要件定義（最近はもっぱらレビュー） 　　など... 神山賢太郎 登壇者紹介
3. ・21卒としてラクスに新卒入社 ・要件定義や設計、実装だけでなく、 運用やサポート対応など幅広く 　担当してます ・趣味：ストリートファイター6 廣部知生 登壇者紹介
4. メールディーラーとは？ 4
 メール共有管理システム 16年連続シェアNo.1（2009～2024）※ 歴史は更に長く、2001年4月に販売開始 ※出典：ITR「ITR Market View：メール／Webマーケティング市場2025」 メール処理市場：ベンダー別売上金額推移およびシェア（2009～2024年度予測）
5. メールディーラーとは？ 5

6. 世はまさにAI戦国時代 6

7. メールディーラーが負ける？ 〜忍び寄るディスラプト〜
8. 楽楽精算とは？ 法制度ニーズにより急成長 電子帳簿保存法の改正やインボイス制度への対応が求められたことにより、システムによる対応の ニーズが高まったことで近年急成長を遂げたプロダクト（成熟期に差し掛かる） 8
9. メールディーラーが負ける？〜忍び寄るディスラプト ビジネスサイド ・Geminiがすごい！自動でメールが書ける！ ・うかうかしているとディスラプトされる！ ・いち早く開発を進めよ 9
 ※ディスラプト：新しい技術やビジネスモデルが登場し、既存の業界や市場を揺るがし、既存の企業やプレーヤーを脅かす現象 ビジネスサイドと開発サイドのスピード感のずれ
10. メールディーラーが負ける？〜忍び寄るディスラプト 開発サイド ・Geminiのメール作成、使ってみたものビジネスメールとしては... ・ディスラプトされるってほんと？ ・他にもやることがある中で売れるかわからないのに優先度あげるべき？ 10
 ※ディスラプト：新しい技術やビジネスモデルが登場し、既存の業界や市場を揺るがし、既存の企業やプレーヤーを脅かす現象 ビジネスサイドと開発サイドのスピード感のずれ
11. メールディーラーが負ける？〜忍び寄るディスラプト 大きめの展示会に2週連続で参加 　・AIエージェントエリアが大盛況 →ラクス製品はそこに全く入り込めていない... 11
 ディスラプトされた世界を体感
12. ディスラプトされた世界とは 12

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

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

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

16. 最優先でディフェンスする！！ 16
 が、メールディーラーの開発スタイルは ウォーターフォール ↓ 関係者多数・承認プロセス多数 →開発〜リリースまで時間がかかる
17. 最優先でディフェンスする！！ 17
 どうすれば早くリリースできるのか
18. 製品の強み・打ち出す価値の整理 18
 メール共有管理システム から ナレッジデータ※を軸にした 問合せ削減 システムへシフト ※メールディーラー内の過去のメールデータや外部の FAQなど メールディーラー 統合型 ナレッジDB メール応対 フォーム チャットボット FAQ ナレッジB メール応対 フォーム チャットボット FAQ ナレッジC ナレッジ A Before それぞれが独立。 ナレッジが点在し、メンテナンスコストが増大 After メールからナレッジが自動抽出され すべてのコンテンツに適用される メンテナンス不要の ナレッジ基盤
19. 19
 早期リリースするために意識したこと パーキンソンの法則 〜人は与えれらたリソースを最大限使おうとする〜 　　開発期間をフルに使おうとする 　　→市場は常に変化している。スピード感を持って開発を推進する必要がある。 　　 ・ビジネスサイドからのリリース時期要求に対して、どうすればそれよりも早く出せるのかを考える。 ・MVPなどゴールを決め、最速で到達するためのやり方を考える 与えられた納期より早く
20. 20
 早期リリースするために意識したこと パレートの法則 〜結果の80%は20%の要素から生まれる〜 　　最初は20％の出来でいいので、まずはチャレンジ 　　→チャレンジを繰り返すことで自身・組織のナレッジが溜まっていく 　　 ・つぎはもっと早く、もっと筋の良いアウトプットが出せるようになる すぐにチャレンジする
21. 21
 製品の強み・打ち出す価値の整理 メールディーラーの強み →高品質な”問合せ対応”業務ができる →”問合せ対応”業務をラクにする 　∟問合せの数を削減する 　 ∟問合せ対応の稼働を削減する 方向性を決める
22. スコープと優先度の検討 22
 問合せを種別に分け、優先度をつける →簡単な問合せに対する回答削減と問合せ業務の稼働削減からチャレンジ 今できることを決める 問合せ 簡単な 問合せ 難しい 問合せ 過去の問合せ 履歴が使える 過去の問合せ 履歴が使ない
23. スコープと優先度の検討 23
 問合せを種別に分け、優先度をつける →簡単な問合せに対する回答削減と問合せ業務の稼働削減からチャレンジ 今できることを決める
24. 24
 ・問合せの数を削減する 　→問合せフォームに入力された質問への回答候補表示エージェント ・問合せが入ってきた後への対応 　→過去の問合せ履歴を活用した自動メール作成エージェント スコープと優先度の検討 ゴールを決める
25. 回答候補表示エージェント 　　「FAQを見れば解決できるレベル」の問合せの減少 25
 スコープと優先度の検討 ゴールを決める
26. 自動メール作成エージェント 　　「FAQや過去の履歴を参照すれば解決できるレベル」の問合せにする自動返信メール作成 26
 スコープと優先度の検討 ゴールを決める
27. 27
 ・メールディーラーのAI開発に特化した課を新設 　→完全アジャイル開発にシフトし、価値の可視化と改善サイクルの　 　　 高速化に着手 ・βユーザを募ってトライ→結果ヒアリング→改善（クレーム検知機能） ・依頼や相談はフランクに、すぐに実施 ・顧客ヒアリングは週1ペース。基本みんな参加し、解像度を揃える 　・お客様の課題、代替手段、ペインの強弱 　・検討中のUI、検証中の精度がお客様に受け入れられるのか？ 　・今後検討が必要そうな課題の抽出 PMM
 デザイナ
 PdM
 (開発)
 開発サイクルの高速化 PMM：プロダクトマーケティングマネージャー(Product Marketing Manager) 　　　 主に製品の企画を担当する。 PdM：プロダクトマネージャー 　　　 主に、製品ロードマップの整備とPMM・デザイナ・開発との橋渡しを担当する
28. 28
 製品コンセプトの作成 マーケ観点での情報整理 　・競合他社の状況ウォッチ 　・提供形態 　・顧客ヒアリング 営業／カスタマーサクセスチームと迅速に連携 →お客様の反応を収集 開発サイクルの高速化（PMM） PMM
 デザイナ
 PdM
 コンセプトを具体化
29. 29
 ・ペライチ、雑コラレベルのモック作成 　→ゴールが可視化されていればみんな同じ方向で議論できる。 ・アイデアのトライ、提案 　　まずは手を動かしてみてあたりをつける ・プロトタイプ作成 ・バックエンド：Python ・フロントエンド：Tampermonkeyスクリプト ほぼ全てGPTで作成。 ・プロンプト：ひたすらトライ&エラー ・検証結果、精度の共有 　　→どう提案するか？どう見せるかをPMM・デザイナと検討 開発サイクルの高速化（PdM） PMM
 デザイナ
 PdM
 アイデアを具体化
30. 30
 顧客ヒアリングの結果と精度の両面からみて、「どうお客様に機能を見せ るか？」を検討 →カスタマージャーニーの整理 →モック作成 →各方面からのFBを収集し迅速に対応 フロントエンドエンジニアとの密に連携 開発サイクルの高速化（デザイナ） PMM
 デザイナ
 PdM
 機能を具体化
31. 31
 軽く作成したプロトタイプ リリース時のデザイン 回答候補エージェントのプロトタイプ
32. 32
 メール作成エージェントのプロトタイプ 軽く作成したプロトタイプ リリース予定のデザイン
33. スケジュール見直し これらの施策により大幅にスケジュールを短縮 33
 2026年3月 2025年10月 2025年10月 2025年6月 回答候補表示エージェント メール作成エージェント
34. 34
 実装者への引き渡し PMM
 デザイナ
 PdM
 実装者 
 ある程度具体化できた状態になれば 背景知識、要求、顧客ヒアリングの結果、コンセプト、プロトタイプを実装者に連携
35. PdMから開発へ引き継ぎ PdMが作成してくれた要件定義とプロトタイプを引き継ぎ、 設計を始める が、メールディーラー特有の課題が浮き彫りに 35

36. メールディーラーとは？（再掲） 36
 メール共有管理システム 16年連続シェアNo.1（2009～2024）※ 歴史は更に長く、2001年4月に販売開始 ※出典：ITR「ITR Market View：メール／Webマーケティング市場2025」 メール処理市場：ベンダー別売上金額推移およびシェア（2009～2024年度予測）
37. メールディーラーはレガシーシステム 2001年4月に販売開始 →既に20年の歴史がある Laravelは2011年リリースなので、10歳年上 典型的なLAPP構成（Linux, Apache, PostgreSQL, PHP）で 動作しており、単一サーバ上でほぼすべての機能が稼働する 巨大なモノリシックアプリケーションとなっている。 37

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

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

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

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

42. 技術選定 選定ポイントは以下の通り • 既存システムから独立して動かせること • メールディーラー内で採用実績があること ◦ スピード感を持った開発のために重要視 • 今後のAI開発でも使えること 42
 🤔
43. 技術選定 JavaScript（Node.js）を採用！ • APIサーバを構築すれば独立して動かせる • さらに、APIサーバの構築実績もあり ◦ スピード感を持った開発が期待できた • OpenAI、Gemini、Claudeといった幅広い生成AIの 公式ライブラリも存在し、将来的にも使っていけそう 43

44. あとはひたすら開発 44

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

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

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

48. リリース！ 48

49. • PDCAサイクルの高速化 ◦ 顧客に提供する価値を決め、優先度をつける ◦ プロトタイプを素早く作る • 適切な技術選定と役割分担 ◦ 技術スタックを活かす ◦ チームの特性を把握し、強みを活かす まとめ
50. ご清聴ありがとうございました。 50