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

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

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

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

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

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

世はまさにAI戦国時代 6 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あとはひたすら開発 44 

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

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

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

リリース！ 48 

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

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

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