出してみてわかったAIエージェントプロダクトの舞台裏〜楽楽AIエージェント for 楽楽精算〜 / Behind the Scenes of Rakuraku AI Agent

Slide 1

Slide 1 text

Slide 2

Slide 2 text

経歴とか - ⼊社前は、⼤⼿SIerにてPMやITコンサルやUXデザイナー「Agile開発×Global開発」(11年以上） - ベトナム（ハノイ）に3.5年移住 - 副業で⽇本やベトナムの⼤学/⼤学院での⾮常勤講師経験 - 情報⼯学やプロジェクトマネージメント - デザインシンキングを⽤いたビジネスデザイン講座 AIエージェント開発課⽯⽥浩章 Hiroaki ISHIDA 　　自己紹介社歴 2024年 10⽉⼊社 ● 明細開発部明細2課を担当 2025年 5⽉ ● AIエージェント開発課を担当

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 今⽇お伝えしたい内容は AIプロダクトのあるある課題をどのように乗り越えたかというお話です

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 ラクスAIエージェント開発課発⾜！ 2025年5⽉1⽇ AIエージェント開発の専⾨チームが⽴ち上げ『年内リリース』が⽬標「楽楽精算」が対象「何を作るか」から開始「RAKUS AI Meetup Vol.1」でお伝えした内容

Slide 7

Slide 7 text

7 楽楽AIエージェント for 楽楽精算 12⽉1⽇にリリース‧CM公開楽楽精算「盛り上がる社員」篇 https://youtu.be/7UWPMHsZZwI?si=Q35iUlk2XgYOU0dE リリース後の反応メディアへの掲載: 5 ※ ⽇経（電⼦版）やEnterpriseZineなどお問い合わせ数: 143件希望社数: 数⼗社以上 → 随時提供開始社内利⽤: 11⽉より開始

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 これまでの経費精算フロー ①事前申請選択 ②クレジット連携選択 ④各明細に紐づけ ⑥領収書を紐づけ経費精算書に関連帳票を紐付け、経費の内容を手入力していく...😣 ①事前申請選択 ②クレジット連携選択 ③事前申請に紐づく明細選択 ④各明細に紐づけ ⑤編集をクリック ⑥領収書を紐づけ ⑦経費精算内容を入力

Slide 10

Slide 10 text

楽楽AIエージェントの経費精算ワークフロー 10 (中略) ①領収書を選択 ②関連帳票を確認 ③一時保存完了 ④内容確認＆申請

Slide 11

Slide 11 text

関連帳票の紐付けの⾃動化 11 楽楽AIエージェント機能の特徴申請者との対話的に進⾏過去申請情報も参考に従来⽐ 30%〜50%短縮領収書の内容を元に、意味的推論を⾏いながら、紐づける事前申請やクレジットカード利⽤明細を提案わずか3ステップで申請直前まで到達（領収書選択 → 紐づけ結果の確認 → 内容の最終確認と申請）選択した領収書や紐づける関連帳表だけでなく、過去申請の⼊⼒内容もコンテキストとして活⽤各段階（プランニング→帳票作成）ごとに、申請者の確認を⼊れながら進⾏

Slide 12

Slide 12 text

12 ここまではスゴそうに⾒えるんですが、こっからが本番です

Slide 13

Slide 13 text

Slide 14

Slide 14 text

LLM原価の試算: 約1000円/申請 ※ 2025年07⽉ごろの話経営層を巻き込んだ⼤問題へ!!! なぜこのような試算になったのか？ ‧全ての項⽬について丁寧に推論 ‧1申請あたり15~30回のAPI呼び出し ‧細かい粒度に分けて呼び出す ‧精算業務のコンテキストの⼊⼒ 14 ①コスト問題 14

Slide 15

Slide 15 text

「類似伝票の探索」数ヶ⽉前から極秘に進んでいた『機械学習』を⽤いた機能を応⽤対象となる帳票群と似た過去の経費精算書を利⽤し、LLMの推論量を⼤幅に削減（数⼗分の⼀に削減）コスト問題への対策 15 ※ 本機能⾃体はサービスインしておりません

Slide 16

Slide 16 text

16 ②精度問題 16 ⽣成したデータの品質もバラバラ加えて、経費精算ルールもベツベツ AIで作成したデータの品質が不安定顧客の経費精算パターンは多様補⾜: 経費精算パターンの例 Case1: 事前申請と経費精算が1:N ● 1ヶ⽉分の予算を1回の事前申請で確保 ● 複数回の経費利⽤ → N回の経費精算 Case2:事前申請と経費精算がN:1 ● 複数回の経費を利⽤ → ⽉末に、1回にまとめて経費精算

Slide 17

Slide 17 text

「規定違反チェック機能」楽楽精算が持つ、会社ごとに設定可能な柔軟なルールベースのチェック機能 ‧AIエージェントは「申請業務の効率化」 ‧本チェック機能が「申請の品質担保」 17 精度問題への対策 https://www.rakurakuseisan.jp/function/expenses.php

Slide 18

Slide 18 text

１回の作成で最低2~5分『経費精算書作成』時に、複数回の推論が実⾏されるため、完了までに時間が掛かるそれ以外にも以下のような課題が残る ● アクセスが集中するケース ● 帳票の数や明細が多いケース 18 ③速度問題 {code} 18

Slide 19

Slide 19 text

「帳票紐付けと作成の分離」当初の想定（右上図）『作成指⽰』〜『経費申請』⼀気通貫フローの修正後（右下図）『作成指⽰（→ 精算書作成）』を並列実⾏可より⼀層エージェンティックな流れへ変化 19 速度問題への対策作業終了作業開始作成指⽰作成指⽰作成指⽰内容確認内容確認内容確認経費申請経費申請経費申請作業終了作業開始作成指⽰作成指⽰作成指⽰内容確認内容確認内容確認経費申請経費申請経費申請 Before: 同期的に進める流れ After: ⾮同期化した流れ

Slide 20

Slide 20 text

20 速度問題への対策「帳票紐付けと作成の分離」精算書作成パートを⾮同期処理へ作成中に次々に経費精算書を作成できるようにワークフロー⾃体を変更作成依頼は⼀気にまとめて → 内容確認や申請はあとから１つずつ

Slide 21

Slide 21 text

Slide 22

Slide 22 text

22 ユーザーの率直なフィードバック⾃分でやった⽅が早い（待ち時間が無駄）事前申請なしでは使えないの？驚くほど早く終わった気づいたら完了していた複数明細の経費精算でも正しく紐付けられ、備考欄まで記載してくれた⼀回ごとに経費精算を完了させたい（⾮同期処理に慣れない）

Slide 23

Slide 23 text

Slide 24

Slide 24 text

事業継続性 (Viability) 実現可能性 (Feasibility) 複数の技術的や既存機能を活⽤することで、原価削減や申請書の品質向上に繋げられた。ただし、今後も継続的に改善に取り組む。実現可能性のトレードオフとして妥協。当初予定していたものと⽐べると、体験として使い勝⼿が良いとは⾔えない状態になってしまった。 24 有⽤性 (Desirability) 3観点からみる現状のプロダクト評価年内リリースの前提に、実装可能な⼿段を選択。今後も、エージェントの実装技術やLLMの活⽤ナレッジの蓄積を⾏い、⾼い要求にも応えられるようにする

Slide 25

Slide 25 text

まだ⼈間が介在が多い → 次の様な体験を提供 ‧領収書を選択すれば⼀時保存まで⼀気通貫へ ‧まとめて領収書を選択しても、⾃動的に分類し、複数の精算書を作成現在は経費精算だけ → 今後は以下の種別へ ‧交通費精算 ‧出張精算 ‧交際費精算 ①「事前申請 ✖ クレカ」は利⽤ハードルが⾼い → 必須情報を減らす ②スマホだけ対応 → PCでの利⽤も 25 いまはまだ25%程度の完成度多様な精算種別への対応利⽤条件の緩和⼈の⼿間を減らす

Slide 26

Slide 26 text

26 SaaS ✖ AIエージェントの⼭場はこれからクローズド版を通して、より使いやすいケース突き詰める⻑期的にSaaSとして提供し続けられる、有⽤性と事業継続性のバランスを取る 4段階12サイクルを想定 ● PoC版: プロトタイプによるAIエージェントのあるべき姿を⾒つけ出す # => Vol.1時 ● α版: 社内データ基盤との接続やAIエージェントフレームワークを⾒つけ出す ● β版: 既存データや顧客ごとの運⽤ルールに照らし合わせて価値を⾼める # => 今ここ ● γ版: 実際の顧客へ提供開始し、スケーラビリティを検証する

Slide 27

Slide 27 text

前提: 経費精算をしたい⼈はいない ● 「経費精算は⾯倒くさい」 ● 「精算作業を始めるのも億劫」 ● 「私の代わりに、作ってくれない？」これからの経費精算起点: AIエージェントが状況を理解し主導責任: ヒトが確認や承認だけを担当 27 経費精算エージェントのVISION ヒトが経費精算から解放される世界へ

Slide 28

Slide 28 text

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