YT YouTube2Text

YouTube2Text → Transcripts → 生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化：バクラク事業 AI・機械学習部部長松村優也 / Tech Lead 島越直人 (2025年)｜Bet AI Day

生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化：バクラク事業 AI・機械学習部部長松村優也 / Tech Lead 島越直人 (2025年)｜Bet AI Day — Transcript

by LayerX 公式 · 957 words · 957 segments · language ja · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00よろしくお願いします。最後の、あ、ありがとうございます。最後のセッションとなりましたが、皆さんお元気ですか?もう中にはもう半日以上付き合いただいてるかと思いまして本当にありがとうございます。私は結構疲れております。で、そんちょっと
0:04[拍手]
0:1845
0:19分っていう長めなんですが、最後までお付き合いただけると嬉しいです。
0:23え、生成AI時代におけるAI機械学習
0:26技術を用いたプロダクト開発の進化と進化
0:30と題しましてお話ししていきます。
0:35で、簡単に自己紹介ですけども、改めて、
0:38え、松村ゆと申します。爆落事業部にいて
0:42AI機械学習部の部長を務めております。
0:45学生時代は京都大学にて情報検索や情報
0:49推薦の研究に従事しており、そこでAIや
0:52機械学習といった技術と出会いました。
0:552018年に新卒でオテットリー株式会社
0:58へ入社し、推薦システム開発チームを
1:00立ち上げに携わった後、え、テックリード
1:03やプロダクトマネージャー、
1:04エンジアリングマネージャーと検任した後
1:06にAI領域の技術に就任しました。
1:10その後2022年9月にレアスに入社し
1:14まして爆落を横断したAI機械学習技術を
1:17使ったプロダクト開発に携わっております
1:20。ま、その他大学にて非常としてAIの
1:24社会実に関する講義を行ったり、AI関連
1:27の書籍を執筆したりと、ま、10年ほど
1:29AI領域において、え、活動しております
1:31機械学習エンジアでございます。
1:36初めに我々の目指す業務の完全自動運転と
1:40その実現に向けた課題についてご紹介
1:43いたします。
1:46本日何度も聞いているキーワードとなるか
1:48と思いますが、レアXあるいは爆落は業務
1:52の完全自動運転を目指しております。
1:56例えばご自身が出張する際のことを
1:58思い出してください。私もちょうど昨日
2:01までAI系の学会に参加するために、え、
2:04京都まで出張していました。
2:06最新の研究同向をキャッチアップしたり、
2:09渾新会や企業ブースにて様々な方と交流し
2:12て非常に有意義な時間を過ごすことができ
2:14ました。
2:16一方でそのような出張本来の目的を達成
2:20するためには、え、出張を実施するために
2:24必要な事前の出張申請や車内規定に沿った
2:28交通手段や泊施設の手配あるいは事後の
2:31経算など正直めんどくさい車内業務を
2:35片なすく必要があります。
2:38このような人間がやりたいわけではないが
2:41やらないといけないといったような業務を
2:43AIで代替しようというのが業務の完全
2:47自動運転の分かりやすい例の1つです。
2:51例えば出張が決まると皆さんご自身の予定
2:53管理のためにカレンダーに出張予定を入れ
2:55たりはすると思います。そうするとあとは
2:59もう勝手に爆楽のAIエージェントが
3:02先ほど述べたような出張に伴うめんど
3:04くさい初業ムっていうのを終わらして
3:06くれるというような世界が見えていると
3:08思いますし、実際我々はそれに向けて開発
3:11を進めております。
3:17もちろんいきなり全ての業務が完全に自動
3:19化されるわけではありません。こちらも
3:22本日何度か現れておりますが、え、自動車
3:24の自動運転について国土交通省等が発表し
3:27ているレベル分けなどを参考に業務の自動
3:31運転についてその程度0から5の6段階で
3:35レベル分けしたものになります。
3:38例えばレベル5ですとあらゆる状況化に
3:41おいて例外処理まで含めてAIが業務を
3:44代替してくれるといういわゆる業務の完全
3:47自動運転の状態を指します。
3:51車内規定で定められていないケースでも
3:54AIが合理的に意思決定して業務も遂行し
3:57てくれたり、あるいは好転で飛行機が結行
4:01してしまったような際でもAIが大体手段
4:04を手配してくれるといったようなイメージ
4:06です。
4:08もちろん我々最終的にはそのような高い
4:10レベルを目指しているんですけども、まず
4:12はレベル3と定義している限られた条件化
4:16において単純な業務においては人間でなく
4:20システムが主体となって自動で、え、業務
4:24を完了させることができるという状態を
4:26目指していますし、これはもう目の前に来
4:28ていると感じております。
4:33一方で業務の完全児童運転に向けては
4:36大きな壁があると考えております。私たち
4:40爆落はいわゆるサースとして提供しており
4:42、え、累計では1万5000車を超えるお
4:45客様にご利用いただいてきております。
4:48その精の企業が共通して持つ発生頻度の
4:53高いケースを満たす、いわゆる汎用的な
4:57機能を開発して提供するというのが一般的
5:00なサースの動きで、我々も基本的にこれに
5:02習って、え、これまで来ております。逆に
5:05言うと会社ごとに多様な個別性が高く発生
5:11頻度の低いケースを満たすための機能は
5:14開発リソースやシステム的な制約などの
5:17理由でなかなか開発することが難しいです
5:19。
5:21その結果システムに合わせる形でお客様の
5:25業務を変更いただいたり、あるいは
5:27システム内外における運用でカバーして
5:30いただくしかないというのが現状であり、
5:32これが業務の完全自動運転に向けて1つの
5:36壁となっていると考えております。
5:42そのような壁を乗り換える鍵となるのが
5:45LLMやAIエージェントと言った技術
5:47です。
5:49その高い性や知性が現在は人間が自ら判断
5:54し実施している多様なケースを自動化
5:58できる可能性を秘めていると考えており
6:00ます。
6:02エージェントの詳細については本日の発表
6:04でもいくつかありましたので割愛いたし
6:06ますが、AIエージェントがごとの車内
6:10規定を参照しつつ、爆落のドメインに
6:13目指した様々なツールや爆落外のサービス
6:16をも利用しつつ爆落の機能としては提供し
6:20ていないような業務を遂行するというのが
6:23現実身を帯びてきていると考えております
6:25。
6:30そのようなAIエージェントがその高い
6:33自立性や知性を存分に発揮できる環境、
6:36プラットフォームを開発することで主要な
6:39ケースの隙間を埋めていくことができると
6:42考えています。
6:44これまでは諦めていたようなごとの業務
6:47フローをAIエージェントが代わりに受視
6:50するパーソナライゼーションされた業務の
6:53自動運転が実現できるのです。
7:00このパーソナライゼーションされた業務の
7:03自動運転をどう実現するのかをエンジアと
7:06して日々考えて実践しており、その一部を
7:09本日はご紹介できればと思っております。
7:16で、そのようなパーソナライゼーションさ
7:18れた業務の自動運転の爆落における実例を
7:21いくつかご紹介いたします。
7:261つ目の例は爆落のAI機能の、え、顔で
7:30あるAIOC機能が進化した
7:33パーソナライズドAICRです。こちらは
7:36昨年末にリリースいたしました。
7:39請求書や領収書といった調から金額や日付
7:44、支払い先などの項目を中止するACER
7:48機能の開発にはこれまでも機械学習中系統
7:51のチームとしても非常に力を入れてまいり
7:53ましたし、お客様にも大変ご公表を
7:55いただいている機能です。そこからさらに
7:58深い課題を解くために
8:00パーソナライゼーションされた業務の自動
8:02化体験を提供するためにパワーアップした
8:04ものとなります。
8:07相談の通り、お客様ごとの運用に応じた
8:11金額や日付などの項目を自動で読み取って
8:14くれるAI機能です。ま、つまり同じ請求
8:17書や領収書を爆落にアップロードしたとし
8:20ても、お客様会社によって異なる値が自動
8:23で埋め取られるっていうようなものになっ
8:25ております。
8:30お客様ごとの運用に応じた値というのは
8:32例えばホテルの領収書想像していただき
8:34たいんですけども一口に日付と言っても
8:38例えばチェックインとかチェックアウト日
8:40あるいは予約日や決済日などなど様々な
8:43ものが記載されております。
8:46一方で例えば宿泊時の経費生産に際して
8:50どの日付を使うかというのは実は会社の
8:53運用によって様ざまでチェックアウト病を
8:56使う運用のところもあれば決済日を使うっ
8:58ていうような会社もあります。そのため
9:02従来の特定の日付や金額しか読み取れない
9:05AICR機能、ま、具体的に言うとある
9:08調して1つの日付や金額を正解として学習
9:13した機械学習モデルを使っていたような
9:16従来のAICR機能ではどうしても全ての
9:19お客様を業務の自動化をすることができ
9:22ませんでした。そこで生まれたのがこの
9:25パーソナイizドAIOCRです。
9:29この機能を実現するために裏側では最新の
9:32LLMや従来の機械学習モデルを複数
9:35うまく組み合わせているのですが、その
9:37詳細一部は後半のパートでご紹介いたし
9:39ます。
9:43次に紹介するのは先月リリースしたばかり
9:46の爆楽では初のAIエージェント機能で
9:48あるAI申請レビューです。
9:55AI申請レビューではAIがお客様ごとの
9:59車内規定や過去の申請データからその会社
10:03で守るべき申請のルールを学習します。
10:07そしてそのルールに基づいて従業員の方が
10:10作成している申請内容をリアルタイムで
10:14レビューし、フィードバックを返すことで
10:17正しい申請を作ることをサポートして
10:19くれる。あるいは今まで代わりにチェック
10:22していたような上司や経入の方の仕事を
10:24代替するようなAIエージェント機能です
10:26。
10:27これによって皆様も経験したことがあるか
10:29と思いますが、ま、誤った申請をして
10:32しまって差し戻されたり、ま、その後修正
10:34したりといった、ま、そういったような
10:36業務がなくなることを期待している機能
10:38です。
10:40少しだけ内部に触れておくと、え、この
10:42車内規定だけではなくて、過去の申請
10:44データも活用することでレビュールールを
10:47学習しているっていうのがポイントとなり
10:48ます。というのも、ま、理想としては車内
10:52規定に全ての必要事項が必要な情報が記さ
10:55れていて、AIはもちろん人間もそれを
10:59見れば完璧な申請業務が行えるというよう
11:01な状態が、ま、理想かと思うんですけども
11:03、ま、残念ながら人間ってそんなに
11:05ドキュメント作るのうまくないし、管理
11:06するのもうまくなかったりしますので、え
11:09、ま、なかなかそのドキュメントだけでは
11:11完結しないという現状があります。という
11:14ところで、え、ドキュメントそうですね、
11:16読むだけでは曖昧で判断できないことが
11:18あったりだとか、あるいはもう
11:20ドキュメントにそもそも書かれていなくて
11:22、ま、暗黙のルールがあったりとか、ま、
11:24そういったのが現実で、そん中で、え、
11:26どうしてるかと言いますと、過去の申請
11:29データっていうのを参考にすることで
11:31ドキュメントだけでは分からないような
11:33情報を補っております。実際皆さんもなん
11:37か車内申請する際って、ま、車内
11:39ドキュメントを参考に0から申請を
11:41作り上げたりするわけではないと思ってい
11:43て、過去の同じような申請を参考にしたり
11:45、あるいは申請の仕方を同僚に聞かれた時
11:48にはなんか1から説明するわけじゃなくて
11:50、こんな感じでやっといてって、ま、昔の
11:53やつを渡したり、ま、そういったような
11:54ことが、え、経験ある方も多いんじゃない
11:56かと思いますけど、そのイメージですね。
12:00で、この辺の技術の取り組みも
12:01めちゃくちゃ色々と面白いんですけども、
12:03ま、まだ検証中の部分は大きいですので、
12:06ここに関してはまた別の機会で共有できれ
12:08ばなと思っております。
12:12で、そのようなAI申請レビューなんです
12:15けども、結局何ができるねんってところで
12:17いくつか実際でもお見せできたらなと思っ
12:19ております。おそらくリリース後に実際の
12:23画面を外に見せるのは初めてかつ、これ
12:25昨日の夜僕の手元で収録したんで多分最新
12:28の状態ですと。で、1つ目のユースケース
12:32では、え、セキュリティ等の観点でカフェ
12:35で打ち合わせするなっていうカフェでの
12:37打ち合わせが原則禁止されていて、
12:39もちろん経算申請もできないっていうよう
12:41な運用において、ま、申請時点でそれを
12:43検知してアラーをしてくれたり、あるいは
12:46、ま、申請を姿勢いでその申請者に啓蒙を
12:48したいっていうな、そういう
12:49モチベーションのものですね。
12:52で、ちょっとちっちゃいから後頭では、え
12:54、補足するんですけども、え、これは領収
12:58書アップロードしていて、タリーズ、ま、
12:59いわゆるカフェですねの領収書
13:01アップロードして、で、やる機能が日付
13:04金額等々をいつも通り入れてくれるんです
13:06けど、打ち訳け、ま、形成産の種類として
13:09会議費っていうのを入れるとAI君を
13:11チェックしてくれて、ま、このように、え
13:13、カフェの領収書はダメなんだよって言っ
13:15て怒ってくれる、ま、そんなイメージです
13:17ね。
13:19で、このようにあのアップロードされた
13:21画像データ、いわゆる非構造化データって
13:24いうのを対象として、ま、この回は
13:26カテゴリー分類押した上で申請内を
13:28チェックしてくれる。ま、こういったこと
13:30ができたりします。
13:34で、動画の読み子、あ、で、次のユス
13:38ケースはタクシー利用時の経算申請につい
13:41てのものです。で、
13:45始まるかな。
13:47で、これもさっきと同じようにタクシーの
13:49領収書アップロードしているんですけども
13:52、で、さっきと同じように、えっと、金額
13:55等々埋められてタクシーの形成さんです
13:57よってすると、今これ怒られたのが乗車
14:00経路と乗車利を入れてねえっていう風に
14:02怒られているんですよね。で、ここで今、
14:05えっと、書いているのが自宅から東銀座
14:07オフ室まで結構ちょっと私を想定した
14:08みたいな入力をしてるんですけど、で、
14:10乗車経路入れたんですけど、乗車理由書い
14:13てませんよと。って時に、え、上車理由
14:15抜けてるよっていうちゃんと具体的な上昇
14:17理由回転起こってくれる、そういう
14:19イメージですね。で、これ現状では
14:22タクシーのその乗車経路とか乗車理由を
14:25入力するための専用の機能ホームが存在し
14:27ていないので、今の例のように、ま、内容
14:30メモランといういわゆる自由ですねに、え
14:33、そういった追加の情報っていうのを記載
14:35してもらうっていうの運用しています。
14:37ただ、ま、いわゆバリデーションも
14:40リクワードなんか入力されてるかどうかの
14:42チェックぐらいしかできないので、ま、
14:44さっきのケースで言うと、え、乗車経路
14:46だけ書くとそういったバリデーションを
14:48通過してしまって、ま、申請した後で
14:50差し戻されるみたいなが世の中でたくさん
14:51起こっておりますと。っていうとこにおい
14:54て、ま、このようにAI申請レビューでは
14:56非高速データ、ま、テキストですねに
14:59対するこれは裏では情報注意をうまいこと
15:01してくれているんですけどもを行うことで
15:04、え、今回のケースのように自由が対象
15:06だったとしても必要な情報、この会社の
15:09運用として必要な情報がきちんと入力され
15:12てるんだっけってのチェックすることが
15:14できます。
15:18で、次に
15:20結構推しのでもなんですけども、タクシー
15:23今さっき乗車理由がありませんって怒られ
15:24て終わったんですけど、その続きですと。
15:26で、乗車理由を入力するんですけど、乗車
15:28理由って何でもいいわけじゃないんですよ
15:30ね。で、基本的には、え、業務上必要だと
15:33判断されるような時しか経算としては認め
15:36られないはずで、ま、その基準も会社に
15:38よって様々かと思います。そのような会社
15:42ごとの基準に合わせた妥当性の判断と呼ん
15:44でいますが、妥当性の判断までAI申請
15:47レビューはできてしまいます。
15:50これもちっちゃいんですが、ま、さっきの
15:51続きですと。で、あ、乗車理由を書き忘れ
15:54てたってことで書くんですけども、これ
15:57ちっちゃいんですけど、ま、通勤のため
15:58って書いてるんですよね。で、通勤のため
16:00って、ま、確かに理由なんですけど、
16:02あんまり具体性なくてこれだけで通ると
16:04思えないみたいなものを書くと今これ怒ら
16:05れているんですよね。具体的な情報がない
16:08し、一般的な話なので、これ多分通らない
16:10すよって怒られていて、これを思って人間
16:13は、あ、確かにこれじゃあ不十分だよねっ
16:15ていう風に気づいて、今これ入力している
16:18のが、えっと、完全今日の話。ベッド
16:20AIDで登壇する必要があるから、オ室に
16:22行く必要があるんだけど電車止まっちゃっ
16:25てましたみたいなことを書くと
16:28通ってくれるはずで、通ってこれで、ま、
16:31申請が実際できると。で、これ、ま、実際
16:34でもしているわけなんですが、別に裏側で
16:37ルールベースでこういったものの入力を
16:38期待してるみたいな行動を実装してるわけ
16:40ではなくて、本当に簡単に過去のいくつか
16:43の例と、ま、こういったレビューをしてく
16:45れっていうのをAIに伝えているだけで
16:47こういったものができるという機能になっ
16:49ておりますと。
16:51で、電話は以上なんですけども、AI申請
16:53レビューでは、え、ここでは紹介しきれ
16:55ないぐらいたくさんのユースケースに、ま
16:56、裏側としてほとんど追加の開発なしで
16:59対応することができるAI
17:00プラットフォームですと。で、AI申請
17:03レビューを初めとしてこれからどんどん
17:05登場する爆落のAIエージェントは従来の
17:08サスでは拾いきれなかった様々なケースに
17:10も、え、答えられる形に進化することで
17:13業務の完全自動運定を目指しております。
17:16これもしうちでも使いたいって方がいたら
17:17後で今新回答で是非話しかけてください。
17:23で、えっと、業務の完全自動運転向きて
17:25エージェンティックワークフローっていう
17:27概念が鍵となりますという話で、え、前半
17:29終えるんですけども、
17:33え、
17:36なぜ、え、重要かというところで言うと、
17:38ま、LLMやAIエージェントがいかに
17:40賢いと言えとも、まだアレールタスクを
17:42丸投げで解決してくれるほどのものでは
17:44ありません。今日の発表でも何回か出てき
17:47たかなと思います。例えば爆落で扱って
17:49いる請求書内の明細から明細表から複数の
17:54仕訳を作成するっていうタスクを例に
17:55上げると、ま、請求所だけ渡して仕訳け
17:58切ってってポンと渡してもなかなかうまく
18:00いかなかったりするんですね。っていう
18:02場合は例えばまず表を抽出して次にそっ
18:06から主役権使用する特定の業を注意してっ
18:08ていう風に一定のリドで、え、タスクを
18:10分解してあげる方がうまくいくことが多い
18:12です。このようにLLM、AI
18:16エージェントでポンではなくてシンプルな
18:18課題軍に、え、事前に分解してあげること
18:21がポイントになるかと思います。触る人に
18:24は座るかと思いますが、ディープでポンっ
18:26ていうフレーズがね、昔流行ったのが
18:27懐かしいですね。
18:30で、そこで書きとなるが、え、自立性と
18:32決定性を兼ね揃えたエージェンティック
18:34ワークフローだと考えていて、
18:36エージェンティックワークフローにおいて
18:37はAIエージェントの自立性を生かしつつ
18:39も取り組むタスクが事前定義された決定的
18:43なAIワークフローやAIOC機能等
18:46ドメイン特化した高性能の通路をAI
18:48エージェントが事在に活用して時には人間
18:51とも強調しつつ助けに取り組むことができ
18:53ます。
18:55エージェンティックワークウロの仕組みに
18:56よって例えばよくある交通費の形成生産
18:59申請の手順はAIワークロードして事前
19:02定義しておいて成功確率を上げることが
19:04でき一方で例外的な申請の場合はAIが
19:07自立的に考えた上で必要に応じて人間に
19:10確認を求めたりだとかAをしる等々の通路
19:13を使ったり外部リソースにアクセスする
19:16ことで、え、タスクをこなしていくって
19:18いう体験が実現できるはずです。実際
19:20先ほど紹介したAI申請レビューもこの質
19:23に基づいて開発を行っています。
19:28ただ、えっと、エージェンティック
19:29ワークローもちろん夢のような、え、機能
19:31ではなく、いろんな難しさがあって、
19:33例えばAIワークフローとして取り組む
19:36タスク軍を事前決定的に定義できたとして
19:39も、それぞれのタスクは成功するかどう
19:41かっていうのはまた別の話です。ま、そこ
19:43で重要になるのは当たり前かもしれません
19:45が、それぞれのタスク内で使われるツール
19:47の性能です。例えば先ほどの例の一部なん
19:51ですけども、請求書から主役を作成するっ
19:54ていうタスクを3つ分解した時に1つ1つ
19:57のタスクが9割っていう比較的高い制度で
20:00成功するとしても3つがつなると最終的な
20:02制度は73%まで落ちてしまいますとゆに
20:06この1つ1つ1つのツールを性能高く作る
20:10ことは、ま、非常に重要であってかつ、ま
20:12、そのドメインならで、あのビジネス
20:14ロジックや工夫を取り組めるっていう意味
20:16でもエンジニアの腕の見せどころだと考え
20:18ております。
20:21というとこで後半のパートではこの重要な
20:23ツール軍、特にAIや機械学習技術を活用
20:26したツール開発について実例と共に機械
20:30学習領域のテックリードである島越紹介さ
20:32せていただきます。
20:46[音楽]
20:53ではここから松村に変わって島越の方から
20:55お話をします。簡単に自己紹介させて
20:58いただきますと、私は松村と同じ爆落事業
21:01部のAI機会学習部というところでテック
21:03リードをしております。レアXには
21:062023年4月に入社し、AIOCRなど
21:09の機械学習機能開発全般を担当しており
21:12ます。また趣味でかるという機会学習
21:15コンペットフォームにも参角しており、
21:17最高位のグランドマスターという称号を
21:19持っています。
21:22先ほど松村の方から話があったように、私
21:25からはエージェンティックワークフローに
21:27おけるツールをどのように選定していけば
21:29いいかというお話をします。少し技術的な
21:32話も多くなるのですがお付き合いください
21:35。
21:37まずツールという名前を聞くと一般的には
21:40単純なAPI操作や関数呼び出しを皆さん
21:43イメージするかもしれません。しかし我々
21:46が考えるエージェンティックワークフロー
21:48におけるツールというのはそれらだけでは
21:50なく機械学習モデルや事前に課題を分解し
21:53た決定的なAIワークフローはまた人間に
21:56よる介入なども全てツールとして捉え
21:58られるのではないかなという風に考えてい
22:00ます。これらを村さんの発表であったよう
22:03なリーダーエージェントが1つ1つ
22:05呼び出していくことによって業務の自動
22:07運転というものが実現実現できると我々は
22:10考えております。
22:14その上で多種多様な選択肢が今言ったよう
22:17にあったんですけど、それぞれのタスクに
22:19対してどのようなツールを選択するかが
22:22エンジニアの腕の見せどだと我々は考えて
22:24います。例えばここに書いてあるように、
22:27ま、前半でも紹介があったんですけど、
22:29請求書から仕訳を作成したいといった
22:31タスクを分解していくと、ま、まず文字を
22:34検出し、検出しないとダメですよね。表を
22:36検出しないとダめですよね。みたいな
22:38タスクに分解されていきます。この中で1
22:41つピックアップして仕訳に使用する業を
22:43じゃあ抽出しましょうというものを
22:45ピックアップしてみるとこのタスクを解く
22:47にはどのようなツールを使えばいいと思い
22:49ますか?単純に人間にやってもらうという
22:53手段もありますし、LLMのAPIで予測
22:55するという手段もあると思います。
22:59本日はこのツールの技術の中でも特にAI
23:03を用いた手段を取る時にどうすればいいか
23:05という話を紹介いたします。
23:09まず1個確実に言えることとしては、
23:11とりあえずフロンティアの生成AIを使え
23:14ばいいというわけではないと我々は考えて
23:16います。ではどのようにすればいいの
23:19でしょうか?
23:21そのためにもまず識別モデルと生成モデル
23:24の違いについて説明します。少し専門的な
23:28用語になるのですが、識別モデルというの
23:30は条件付き確率を学習し、生成モデルは
23:34同時確率というものを学習します。簡単に
23:37説明すると、識別モデルはXという特徴を
23:40観測した時にYに近づくように学習する
23:44ような学習をするのですが、LLMなどは
23:47こういう文脈だから次にYが来そうだなと
23:49いった分布を学習するといった学習の違い
23:52があります。そのような学習の違いにより
23:55出力の分布や入力方法にも違いが生じます
23:58。例えば識別モデルの場合はクラス分類で
24:02あればクラス数などの固定次元であったり
24:05自系列予測やランキングのようなタスクに
24:08おいてはスカラーチになったりします。
24:11また解きたいラベルを予測するために必要
24:13な関連情報を追加で与えようとする際には
24:16、ま、それと関連した情報っていうものを
24:19加工した上で、ま、特徴量としてXとして
24:21加えてあげでそれ専用に学習するという
24:24ような流れを取ることになります。一方で
24:28LLMなどの生成モデルは一般的に文脈を
24:31考慮した上で下変のテキストっていうもの
24:33を逐時的に出力します。そのため出力空間
24:38が5位移サイズみたいな高次元になるので
24:41一般的に計算効率が悪くなります。また
24:45解きたいタスクの関連情報というものを
24:47追加で与えたいという場合は村さんの発表
24:50などでもありましたがコンテキストを
24:52いかに与えるかというところで、ま、
24:54すでに学習された分布上でなんとか
24:57コンテストでやりくりするということに
24:59なります。このような違いを考慮した上で
25:03どちらのモデルを使うべきかということを
25:05考えることが重要だと考えています。
25:09また最近ではOSSのスモールランゲッジ
25:12モデル、いわゆる10ビリオン以下の
25:14サイズのモデルLLMへの注目が高まって
25:17いまして、ま、これらの選択肢というのも
25:20深夜に入れる必要があると我々は考えてい
25:22ます。例えば制度の観点で言うと、ま、
25:26先ほど紹介あったエージェンティック
25:27ワークフローっていうものを構築する際に
25:29、ま、タスクを分解していくと多くの場合
25:32は構造化データ抽に落ち着くと言われて
25:34おり、ま、それに対して大体1万件から
25:3710万件ぐらいのデータサイズでSLMを
25:40自己学習すれば十分な制度が出るよと論文
25:43で報告されていたりします。また運用面で
25:47の扱いやすさとしてもいくつか利点があり
25:49まして、例えば自分たちでモデルを運用
25:52することで定期的な学習が可能になり、
25:55新しいフォーマットであったり要件にも
25:58素早く適用することが可能になります。
26:02他にもLLMAPIの運用を続けると
26:05プロンプトが複雑になったりコンテキスト
26:07がコンテキストが非大化してコンテキスト
26:09に乗りきらなくなってしまったりといった
26:11問題がありますが、自前で学習する場合に
26:14はパラメーターとしてメモリを保持する
26:16ためそのような運用から逃れられるという
26:19メリットもあります。
26:22これらの違いをより理解するために爆落の
26:25実で検証をしてみました。ここでは前半
26:28紹介になったパーソナライズドAICRの
26:32まず色々なラベルを抽出する候補抽出性の
26:36タスクを一部観略したものをもに、ま、
26:39ロバータといった従来からある識別モデル
26:42であったり、クエといったOSSのモデル
26:45、GPT4.1CloudといったAPI
26:48で提供されてる生成モデルなどで構造化
26:51データ抽チュータスクでどのような違いが
26:53出るかというものを紹介します。
26:57例えば出力空間の違いなんですけれども、
27:01識別モデルの場合は事前に定義された
27:03支払い金額といったラベル分類を文字列に
27:06対して行っていきます。そのため事前定義
27:10したラベル以外の出力をしたり元の文字列
27:12を改変するといったハルシネーションは
27:14発生しません。ただ事前定義したものは
27:18以外は出力できないといった欠点もあり
27:21ます。一方で生成モデルの場合は5位の中
27:25からユーザーが求めるフォーマットに従っ
27:27てこのような税損形式で文字列を出力し
27:30ます。なのでユーザーが求めれば、ま、
27:34そのコンテキストに従ってあらゆるラベル
27:36を抽出できるという強みがあるんです
27:38けれども、そもそも正しいJソon
27:41フォーマットで出力できていなかったり、
27:43元の文字列が改変されてしまったり、文字
27:47列のどの部分から抜き出したのかといった
27:49ことが分からず、多少
27:50アンコントローラブルな部分が増えてき
27:52ます。
27:54また計算効率の部分に関しては一般的に
27:58モデルサイズや、ま、先ほどお話しした
28:00出力の方式の違いなどからも式別モデルの
28:03方が効率が良くなります。生成モデルの
28:07出力効率もライブラリーなどが最近は充実
28:09してきており、徐々に効率が良くなってき
28:11てはいるんですけれども、効率という意味
28:14に関しては式別モデルの方がまだまだ効率
28:17がいいです。
28:20実際に先ほどのタスクで検証してみた
28:23ところ、ま、縦軸がちょっとログの
28:25スケールになってて見にくい部分があるん
28:27ですけれども、ロバータの0.Cという
28:29ものが中央地で生成モデルより100倍
28:32ほど高速になるというような検証結果に
28:34なりました。
28:37また事後学習した区園だったり生成モデル
28:40APIだったりっていうところの0天に
28:42大差はないんですけれども軽量なAPI
28:45例えばGPT4.1なのやminiって
28:47いうところを見てみていただくと
28:50先ほどのJonソンの例のような期待して
28:53いるフォーマットっていうものを1度で
28:54出力できずリトライの影響で割とちょっと
28:57不安定な挙動をするっていうものを観測し
28:59たりしました。
29:02一方で制度の面ではどうかと言うと、金差
29:05でありますが、ま、全体としては事後学習
29:08した区園の4Bモデルが1番精度が高いと
29:10いう結果になりました。これは先ほどの
29:12論文の例と実でも同様の結果が得られた得
29:16られました。とはいえ0.C見ると100
29:20倍ほどの差があるので0.C要件と制度の
29:23要件などから、ま、識別モデルを使った方
29:25が、ま、ユーザーの体験としてもいいし、
29:27バランスもいいのではないかなっていう風
29:29に思いますと。一方で実務とかだと私も
29:34コストの観点からよくGPT4.1
29:36miniとかを使ったりするんですけど、
29:38そういったモデルがロバーターのような
29:40手法よりも取り先、取引先名といった項目
29:43で20ポイントほど正解率で劣るという
29:45ような結果が得られました。これは取引先
29:49名とは特有のドメインだったりの知識が
29:52必要のため0ショットへはなかなか難しい
29:54のかなと考えていたりします。一方で金額
29:58や日付といった一般的な項目については
30:00精度が高いモデルもあるので、使うところ
30:03次第ではLLMのAPIも有にはなりそう
30:05というような検証結果になりました。
30:10またOSSのスモールランゲッジモデルの
30:12事己学習結果についても面白い結果が得
30:15られました。
30:17ここではクの他にラマ系列のモデルについ
30:20ても検証したんですけれども、自後学習
30:22する前は適切なフォーマットを全く出力
30:25できなかったんですけども、たった
30:262000サンプルほどで8時間学習する
30:29だけで適切なフォーマットをほぼ完璧に
30:31出力できるようになり、制度も前日のよう
30:34に高い制度を達成することができました。
30:39次にどのように関連情報を加えるかによる
30:42違いというものを検証するために
30:44パーソナイズダヤの先ほどは候補抽出部分
30:47だったんですけどその後のランキング部分
30:49のタスクで検証を行いました。
30:53この場合パーソナライドAIOCRは識別
30:56モデルを内部では使っているんですけども
30:57、識別モデルで特徴を行い、一方生成
31:01モデルの場合はAPIを用いて過去の入力
31:05値とテキストペアを与えて
31:06インコンテストラーラーニングを行う形で
31:08検証を行いました。
31:11この場合は爆落のユーザーが最終的に選択
31:14した3つのラベルを1番を推薦できてるか
31:18というところの正解率を評価します。
31:23このようなタスクの場合にも出力空間の
31:25違いがあります。識別モデルの場合は各方
31:29に対して何かしらの最適化指標で
31:31ランキングスコアを付与するという形に
31:33なるので一定スコアの理論的な解釈性も
31:36ありますしとの紐付けなども特に意識せず
31:40行うことができます。一方で生成モデルの
31:43場合は与えられたコンテキストによって
31:46内部的に何かしらの基準で並び替えられた
31:48ものが出力されます。なのでそれをどの
31:51程度信頼していいのかみたいな理論的な
31:53保証がありません。
31:56さらに生成されるのは文字列になるので
32:00追加でIDへのマッピングが必要になっ
32:02たりしますと。なのでマスターデータなど
32:04と多数用いる場合には構成が割と複雑に
32:07なるなというような特徴があります。
32:13この今回のようなタスクの場合の関連情報
32:16の取り扱い方の違いですと。
32:19識別モデルの場合は学習したいに対して
32:23関連する情報にその統計処理などをして
32:26加工したものをモデルに入力するので一般
32:29的に小メモリに関連情報を組み込めます。
32:32ですので長期の情報も取り組みやすかっ
32:35たりこの特徴に対して比例して欲しいなと
32:37いった数値情報の特徴を扱いやすくなり
32:39ます。しかし訓練レンジに利用した特徴
32:43のみでしか予測ができないためある程度
32:45汎用的な用途に限られるといった制限が
32:48あります。一方で生成モデルはどのように
32:52扱うかというと、プロンプトの一部に自然
32:55言語で組み込むため、一般的に水論個数が
32:57少し高くなります。
33:00このような方式のため式別モデルのように
33:03この特徴に対して比例して欲しいなみたい
33:05な挙動を意図的にするのが難しい部分が
33:08あるのですが、絶対に固定のコンテキスト
33:11を出ないといけないということがないため
33:14、同的にコンテキストを切り替えることが
33:16できるというメリットもあります。
33:21このような特徴の違いがある場合に識別
33:24モデルと生成モデルでも制度の比較を行い
33:26ました。今回の検証だと単純に過去の選択
33:30結果を入れるだけのコンテキスト
33:32エンジニアリングでは一貫して我々の提供
33:34しているパーソナイizドAIOCRの方
33:36が精度が高い結果になりました。我々の
33:40場合、過去データを構造化して保持して
33:43いるので、特徴量エンジニアリングの方が
33:46追加で様々な統計処理をして特徴を多数
33:49与えやすいという扱いやすさみたいな部分
33:51も制度向上に起与したのではないかなと
33:54いう風に考えております。
33:58ここまで見ると生成モデルのAPIは精度
34:01も出ないし遅いし使えので使えないのでは
34:04ないかとなるのかもしれませんが、生成
34:06モデルのAPIが優れてる部分も多くあり
34:09ます。例えばリーダーエージェントのよう
34:12にタスクプランニングを行うようなタスク
34:14の場合は今回検証していないようなO3の
34:18水論モデルが有効に働くことがあります。
34:22また構造化データ抽中のようなタスクでも
34:25データがない場合にモデルを作れないと
34:27いう機械学習の弱点をカバーできることが
34:30カバーすることができます。そのような
34:33場合にまず生成モデルAPIを用いて
34:36プロトタイプを作ることでお客様の反応を
34:39見て早期にプロダクトへの導入判断を行う
34:41ことができます。
34:44また同的な入力や柔軟なフォーマットで
34:46タスクをこなすことができるので申請理由
34:49や申請理由といった自由入力欄に対しての
34:53レビュー機能であったり、一部のお客様で
34:56しか必要とされない項目の抽出などで威力
34:59を発揮します。
35:02ではこれらを踏まえて我々はAI機械学習
35:06プロダクトダクトをどのように作っていく
35:08べきでしょうか?
35:10やはり生成モデルAPIのコールド
35:13スタートの状態からAI機能を作れると
35:16いう部分はプロダクトを作る上ではとても
35:18魅力的な部分がありますし、開発の速度も
35:21とても早くなります。なのでまずデータが
35:24ないところに関しては生成モデルのAPI
35:27でMVPやプロトタイプを作成し、最速で
35:31動くものを作ることが重要になると考えて
35:33ます。その上で紹介したような使いにくさ
35:37であったりに直面しながら別の手法に
35:39切り替えたり呼ばれる頻度や反復性データ
35:43の蓄積といったタスクの性質やフェーズの
35:46変化に従って識別モデルやOSSの生成
35:49モデルの学習を行うことで制度改善や
35:52コスト削減0天C改善を狙っていこうと
35:55考えています。
35:57そのため最初に作った段階で後々学習
36:01できるデータを貯めるということも重要に
36:03なると思っています。
36:05もちろん元からデータがあるのであれば
36:07最初から識別モデルを作るのも1つだと
36:10思っています。
36:13ではちょっと抽象的な話をしていたんです
36:15けど、ここからは実際に爆落において開発
36:17した事例でどのように試してAI機械学習
36:21プロダクトを開発してきたかについて紹介
36:23します。まずはパーソナイized
36:27AIOCRの事例です。
36:30パーソナライズドAIOCRの開発処器は
36:33データとしては最終的に力したいしか
36:37データが存在しないという課題がありました。
36:40ここで欲しいのは右で書いてあるような、
36:43ま、単純な日付ではなく、どのような日付
36:45なのかという意味まで含めたラベルが
36:47欲しかったのですが、あのテーションの
36:49データがためる、溜まるのを待つと時間が
36:51かかりますし、追加でこういうラベルも
36:53アノテーションしたいんだよなという要件
36:56が発生した場合に手戻りのコストが発生し
36:59てしまうという課題がありました。
37:02そのような場合に単純にLLMのAPIに
37:05書き換えてしまうと大幅に0点Cが悪化し
37:08てしまいますし、リクエスト数も多いため
37:11コストもかかってしまうという問題が発生
37:13してしまいます。そのためフロンティア
37:16生成モデルのAPIを用いて疑似的に
37:18アノテーションを行ったデータで開発を
37:20まず行うことでモデル開発アノテーション
37:23定義修正の開発のイテレーションを拘速に
37:26し早期にリリースを行うことができました
37:28。
37:30次にAI申請レビューの事例です。AI
37:34申請レビューの場合はモデルに入力される
37:36のが内容メモランに記入される自由記述の
37:39自然言語や添付ファイルの非構造化データ
37:42などルールによって同的に変わるものです
37:44。また要件として機能として時間がかかっ
37:49てしまうとレビューが終わる前に申請を
37:51出しちゃうよね。だったりと体験が悪く
37:53なってしまうので、ま、リアル体制、
37:55リアルタイム性の要件だったりレビュー
37:58結果がNGの場合には理由を自然言語で
38:00フィードバックできるようにしたいといっ
38:02た要件がありました。さらに申請ルールが
38:06お客さんによって多種多様なのでスケール
38:08できるようにしなければいけないといった
38:10課題もありました。
38:13そのような際にやはりルールの多様性から
38:16単一のモデルを汎用的に学習するというの
38:18は困難なので幅広いケースをカバーでき
38:22フィードバックを自然言語で返すことが
38:24できるLLMAPIを用いました。今回の
38:27場合は先ほど検証したレートは異なり内容
38:30メモランに記述できる文字数は限られて
38:33いるのでリアルタイム性も問題ありません
38:35でした。少し工夫している点としては頻度
38:38高く利用されるようなルールは
38:40エージェンティックにするのではなく、
38:42固定のAIワークフローで一定決定的な
38:44動作にすることで構成制度化を狙ってい
38:47ます。この場合も後々のためにより自立的
38:50に差し戻しデータなどから学習適用できる
38:53ようにデータを蓄積するといったことも
38:55意識しております。
38:57最後に先ほどから何度か例に出している
38:59請求書から表を抽出し仕訳を作成するAI
39:02明彩仕訳という開発中の機能について紹介
39:05します。この機能の場合も全く新しい機能
39:09であるため表のどのような内容に対して
39:11どういう仕訳が切られていたとかという業
39:14のデータが存在しないため事前検証が
39:17難しいという課題がありました。また表の
39:20構造もカラム名や表組が請求書によって
39:24同的に変化するため構造化して識別モデル
39:27で解くというのも難しく他にも100行業
39:30の仕訳を切るといったことを考えるとどの
39:32部分を参考に仕訳けを切られたのかが
39:34分からないとユーザーとしても認知負荷が
39:37高くなります。さらに生成モデルを単純に
39:40用ると表の行数がずれてしまったりと
39:43ユーザー化するとユーザーからすると元の
39:45請求書との対応関係が取れなくなって
39:48しまい逆に負担になってしまうというよう
39:50な間違い方をしてしまうというような課題
39:51もありました。
39:54そこでどのように開発を進めたかというと
39:56まずLLMのAPIでプロトタイプを作成
39:58しユーザーヒアリングや壁打ちを行いまし
40:01た。そこでどこで間違えると負荷になり
40:04そうかどういうUIだったら許容できるか
40:06というものを調査しました。
40:09その上で表の抽出部分はユーザーの
40:11レビュー観点でも重要なので式別モデルを
40:14使うようにしユーザー的に絶対に間違って
40:18欲しくないなという部分は予測した上で
40:20ユーザーに最終的に選択してもらうという
40:23フォールバックの形式を取ることにしまし
40:25た。
40:26また業のデータから仕訳を作成する部分は
40:30LLMのAPIを用いて開発したんですが
40:32、0天Cやコストなどの観点、また識別
40:35モデルの方が精度が高くだろうなるだろう
40:38なみたいな肌裸感であったり、行数を
40:40間違えるなどのハレーションもなくなるの
40:42で、後々識別モデルに切り替えれるように
40:44業員でどういうデータからどういう仕訳を
40:47最終的にユーザーが入力したかというよう
40:49なデータを蓄積するようにしました。この
40:53ようにして徐々に複雑な処理を行うツー
40:55ルっていうものを我々は作成していって
40:57おります。まとめに入らせていただきます
41:00。最後になりますが、我々はユーザーに
41:04向き合いながらAI、エージェンティック
41:06ワークフローから呼ばれる制度の高い
41:08ツールを揃えていくことで業務の完全自動
41:10運転を実現していきます。そのために今回
41:13話したことであったり、ナ村さんの話に
41:15あったようなエージェントシステムが今後
41:16重要になってくると考えております。ご
41:19成聴ありがとうございました。
41:21[拍手]
41:28ありがとうございました。
41:31それでは質疑応答に入っていきましょう。
41:35そうですね、申請レビュー、AI申請
41:38レビューについての質問です。かなり多く
41:41のAIの呼び出しがあるように思えました
41:43。AI
41:44サービスを使うとコストがかなりかかると思いますが、それを抑えるために実施している試があれば伺いたいですと関連して費用体効果をどのように図っているかというところも質問がありました。合わせてご回答お願いします。
42:00私からお話します。ありがとうございます。そうですね。一般的なコスト対策はしておりまして、無駄なコンテスト入れないであったりとかある程度リーズナブルなモデルを使う等々はやっておりますと。
42:12ただ一方で申請レベに関しても結構初期
42:15段階なのである意味コストそこまで気にせ
42:17ずにできるだけより良い体験を届けること
42:20が重要かと思っておりますのであんまり
42:23正直考えきってないですしそこまで深く
42:25考えなくてもま大丈夫だよねっていう
42:27コスト範囲で収まっているのが今ですね。
42:31で、その上で費用体効果で言いますと、え
42:34、費用は、ま、そのような形なんですけど
42:36、効果で言うと、ま、実際今、えっと、
42:38オプションで提供したりもしてるので、
42:39その辺に反応しているかなというところ
42:40ですと。で、我々の提供してる申請
42:43レビューって、え、発表内でもちょろっと
42:45お話したんですけども、実際今まで申請の
42:48内容を確認してたような、ま、上長であっ
42:50たりだか、経理の方の仕事をなくしてい
42:52くっていう、今までそこにかかってた人件
42:54費がなくなっていくという性質を持ってい
42:57たりするので、ま、そういう意味でも、え
42:58、実際のその収益性というか、え、
43:03コ、え、費用体コスト効果っていうのは
43:05大きいと考えていて、そこに向けて実装し
43:08ております。はい。ありがとうございます
43:12。では次は島さんに聞きたいと思います。
43:19先ほど生成モデルと式別モデルの使い分の
43:21お話がありましたが、生成モデルで
43:24ひとまず対応したものを識別モデルに移行
43:27するその判定の仕方、どこにジャッジの
43:30ラインがあるのかというところとどのよう
43:32なプロセスでジャッジしているのかという
43:35質問が来ています。
43:36あとは似たものでシステムに組み込んだ
43:40LM
43:40の機能をこのタイミングで剥がした方がいいというそのタイミングってどのように決めていますかという質問がありました。
43:48はい。
43:51はい。
43:53あ、書いてる。あ、はい。ありがとうございます。
43:55そうですね。その生成モデルをどのように
43:58識別モデルに変えていくかという点に関し
44:01てはそれがどれぐらい呼ばれてるかって
44:04いう部分であったりとかお客さんの体験的
44:06にやっぱりこのぐらいの0点かかってるの
44:08は体験として良くないよねったりとかその
44:12コストであったり体験面でもっと良く
44:14できるのであれば変いていこうみたいな
44:16意思決定をしていこうと思っています。
44:19で、逆に頻度低い部分とかであればそこまでコストが、ま、逆に日致な部分とかであればコストとかはあまり気にせず生成合な
44:27API
44:28をそのまま使うといった選択肢も考えれるかなという風に思っております。
44:32ありがとうございます。まさに業務の隙間を
44:34AI
44:35エージェントで埋めていくというあの初期から話されていたことをそのままなぞってお話しいただいたかなと思います。ありがとうございました。以上でこちらのセッション終了となります。ありがとうございました。
44:50[拍手]

About this transcript

This page contains the full transcript of 生成AI時代におけるAI・機械学習技術を用いたプロダクト開発の深化と進化：バクラク事業 AI・機械学習部部長松村優也 / Tech Lead 島越直人 (2025年)｜Bet AI Day by LayerX 公式, generated from the public captions YouTube serves with the video. The transcript has 957 words across 957 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.