LLMがもたらす“ニッチな業務のデジタル化革命”とは　LayerXのLLM活用戦略から学ぶ知的単純作業の革新

LLMがもたらすニッチな業務のデジタル化革命

中村龍矢氏：先ほど紹介した銀行のユースケースの例に限らずですね、こういうドキュメントワークはけっこうニッチなものになりやすいかなと思っています。こういう文書は多かれ少なかれその業界とかその会社のなんらかのビジネスのドメインに特化していますので、例えばここに挙げているような融資稟議とか損害保険会社のほにゃららとか、医療系の研究機関のほにゃららとかというかたちで、一つひとつはニッチになりやすいかなと思っています。

ですが、このニッチなものというのが我々としてはすごくおもしろいかなと思っているところで、ある意味ニッチじゃない業務。それこそ冒頭にご紹介したバクラクで扱っているような請求書とかは、ほとんどどの会社にも存在しますので、ある意味そういう何十億円ものお金を投資して、良いSaaS、プロダクトを作ろうというインセンティブがあるため、比較的、社会的にデジタル化されやすいと思うんです。

けれどもこういうニッチな業務は、ある意味でいうと単体では市場が小さいので技術的にはすごく効率化ができるとしても、そこにお金を投資して事業をやってくれる会社がなかなか現れにくかったりするのかなと思っています。ですので、従来だとこういう一個いっこのニッチな業務はSIerさんに何億円も払ってシステムを作ってもらうか、そもそもデジタル化を諦めるかというかたちだったのかなと思うんです。

けれども、そういった業務の全部ではないんですが、比較的単純な作業に関してLLMがすごくイノベーションで、ある意味こういうニッチな一個いっこのユースケースをガガッとまとめて新たな市場を作ってくれるというのが、可能性として見ているところです。

技術的なチューニング

こういったドキュメントワークにLLMを使っていく上で我々がすごく大事だと思っているのがチューニングになります。ここで言うチューニングというのは、いわゆるファインチューニングではなくて、広い意味でアルゴリズムを特定のユースケースに合わせて精度を上げていくということを意味しています。具体的にはですね、チューニングは主に2つのカテゴリがあるかなと思っています。

1つ目が左側に書いてある「技術的なチューニング」というところですね。LLMは単純になにかプロンプトを書いて処理すれば、その1個の処理は終わるんですけれども。現実的なユースケースに適用しようと思うと、その処理をたくさん組み合わせたりとか、前後にいろんな細かいことをやって初めて全体のアルゴリズムが構成されるかなと思っています。

例えばいろんなファイルを処理する時に、そのファイルをどういうふうに前処理をするかとか。あとは多かれ少なかれドキュメントがたくさんある時は前段で、いわゆるリトリーバル、検索をして絞り込んだ上でLLMに投げたりすると思いますので、そのあたりの検索を工夫したりであったりとか。

あとはLLMは基本的にいろいろやらせると精度が上がりにくいです。なので、LLMに指示するものはすごく小さい単位にして、それをいろいろと組み合わせて全体を作るというのはあるかなと思うんですが。そういう処理の分割と構成であったりとか、そのあたりが技術的なチューニングとして書いてあるところです。

ドメイン知識的な観点

もう1個が「ドメイン知識的な観点」というところで、これは例え話ですけれども、ある意味LLMはものすごく地頭が良いけど、地頭がいいだけの新入社員というイメージが近いのかなと思っています。基本的にはインターネット上の情報からしか学習をしていないので、あなたの会社の業務ルールとか、あなたの会社の言葉遣いはまったくなにも知りませんので、そういうものを埋めていく必要がある。これが右側に書いてあるドメイン知識的な観点というところです。

感覚値というか、我々が今いろいろなこういったドキュメントワークにおけるLLMの活用の事例がすごく増えてきている中でのちょっとしたイメージなんですけれども。たいていのケースだとなにもしないままのLLMのだいたいの精度は30点から50点ぐらいの感覚です。

そこに対して、いろんなその会社の業務ルールとか知識を入れていくと粘って粘ってなんとなく70点から80点ぐらいにいって、そこから必要に応じてさらに技術的に難しいことをして、より精度が上がっていくみたいな感覚を持っています。ものによると思うんですけれども、だいたい70点から80点前後ぐらいのところに、これだったら新しいシステムを入れてもいいのかなみたいな、そういう実用化をしてもいいかなという判断の水準があって、これを超えられるかどうかが重要かなと思っています。

2023年くらいからですね、多くの企業さんで社内用の「ChatGPT」みたいな、社内用のLLMを使える環境を整備して、一応全従業員の方が使えるというふうにしている企業さんがすごく多いんじゃないかなと思うんですけれども。そのパターンがなかなかうまくいかないというか。ちょっと最初は使われるんだけど、そのあとすぐに定着しなくて使われなくなってしまう。

その理由の1つは、この左側の素のLLMに近い状況で全従業員向けに提供しちゃっているからかなと思っています。それだとなかなか実用化のラインを超えにくいのがあるかなと思います。

チューニングによる精度向上の重要性

というところで、2023年の1年ぐらいですかね、我々としてはいろんなドキュメントワークでのLLMのチューニングに取り組んできて、だいたい毎回このあたりをいじっているなみたいなパターンができつつありますので、そのパターンを落とし込んだLLMのチューニングの基盤、LLMOpsみたいなものを構築しています。

毎回ゼロからプログラムを書かなくても、LLMのチューニングに必要な要素をパターンにして、なにか設定ファイルみたいなものを与えるとアルゴリズムが自動で動くようなかたちを作っています。これでこのチューニングの作業を効率化することによって、先ほどのロングテールなニッチなユースケースになるべく効率的にLLMをお届けできるようにということに取り組んでいます。

あまりエンジニアに閉じないようにするというのが大事かなと思っていまして、なるべくふだんプログラムを書く仕事じゃなかった人でも、このチューニングという作業に参加できるといいのかなと思います。実際に弊社だとビジネスとか関係なく、事業部の全員のメンバーでLLMのチューニングをするハッカソンみたいな合宿をやったりしていましたけれども、そのぐらいみんなでできるといいのかなと思っています。

こういったチューニングが大事という前段から考えると、逆に着手したほうがいいユースケースの性質もあるのかなと思っています。平たく言うとチューニングで精度が上がりやすいユースケースという感じなんですけれども、1つ目の要素が、正解が明確であるというところです。チューニングをして精度を上げていくためには、そもそもその精度って何ですか？　というのが評価できないとやりにくいです。なので正解が、LLMに何をしてほしいのかという、その求めるものが明確なもののほうがやりやすいかなと思っています。

もう1個が、その正解に至るまでのプロセスが明確というところです。チューニングしている時はたいてい、人間はどうやってやっているんだろう？　とか、人間はどういう思考過程でそのアウトプットを作っているんだろう？　というのを想像というかヒントにしながらやることが多いです。

なので、このやり方が言語化できるようなユースケースのほうがチューニングはしやすいかなと思います。なので、新入社員に渡すようなマニュアルがありますか？　みたいなのが揃っているユースケースのほうがチューニングはしやすいかなと思いますし、こういうところからAI活用のクイックイン、最初の成功体験を作って、より難しいケースに展開できるといいんじゃないかなと思います。

精度評価の複雑性と課題

ここでちょっと難しい話として精度はけっこう難しいところがあって、精度評価というのは大事なんですけれども、精度は何パーセントならOKなんですか？　みたいな、精度のゴールを決めるのはすごく難しいと思っています。例えば、ちょっと今日は金融の話が多かったので金融系の会社があるとして、上場企業とかの決算レポートから10個ぐらいの財務的な数字、売上とか流動資産とかを取ってくるとして、その10個のうち何個当たっていればOKみたいな精度を測るとします。

その時に、例えば同じ精度80パーセントでもぜんぜん意味が違うんですよね。1つ目の箇条書きにありますけれども、「項目によってうれしさが異なる」というのがあります。例えば決算レポートから売上を取るとなったら、だいたいP/Lの表があるページの冒頭にあったりするので、そんなのはすぐにわかりますよという感じで、人間もまぁAIにやってほしいけど、最悪自分でやってもいいかなという、そんなに苦労しないかなという項目だったりします。

一方で、決算のその変動要因とか、売上のその変動要因を探してほしいみたいになると、決算レポートによってはそのP/Lの表の下にあるかもしれないし、場合によっては冒頭のサマリーとかにあるかもしれないし、場合によってはなんかいろいろ表があったあとに全体を分析するページがあって、そこにあるかも……と、いろんなケースがあります。

ものによっては人間にとってもすごく難しいところがあったりして、同じ1項目でもそれが正解できた場合のうれしさは違ったりしますので、同じ80パーセントでも意味が違ってくるというのが、まずあるかなと思います。

もう1個が、こういった類のユースケースにあるのが取り過ぎと取りこぼしの違いというものです。LLMになにか情報を探させる時に、それっぽいものがあったらたくさん出してねというタイプのアルゴリズムにするのか。それともけっこう確実に当てにいってくださいという、答えらしい、もっともらしいものをしっかり絞って出してくださいとするのかによって大きく変わってきていて、多くのケースで人間にとっては取り過ぎているものを「あ、これは取り過ぎ」という感じで消していくのは簡単です。

けれども、取りこぼされてしまうと結局元の文書を全部読む必要があるので、「あれ？　AIにやってもらうんじゃなかったの？」という感じになってしまって効果が下がってしまうというのがあります。これは、どっちがどれくらい許容できるの？　というのを意識しないと、場合によっては同じ精度何パーセントでも意味がぜんぜん変わってしまうというのがあるかなと思います。

人材スキルと直接対話の重要性

というところで精度をどう評価するかとか、評価以上にどういうふうにゴールラインを決めるのかは、我々も本当にまだまだ答えは完全に見えているわけじゃないんですけれども。1つのやり方は、そもそも業務削減というのがゴールなんだったら精度何パーセントみたいな別の数字に置き換えるのを止めて、始めからストップウォッチを持って時間を測ってしまおうというのが一番シンプルかなと思います。変に中間的な目標数値に置き換えるんじゃなくて、ABテストっぽく比較してみようという感じかなと思います。

冒頭にお話した、どういう人材が活躍うんぬんというのは我々もこの1年ぐらいのこういうチューニング等々の経験を踏まえて解像度が上がっているところもあります。その1つがですね、基本的にはやはりアルゴリズムがわかるとか、アルゴリズム改善が得意というのは、ものすごく大事な要素なんですけれども、それ以上に直接ユーザーと対話できるかどうかがすごく大きなスキルかなと思っています。クライアントワークができるエンジニアみたいな感じになるわけですけれども。

今日いろいろと話をしましたが、とにかくチューニングにおいてはユーザーの業務を理解して、ユーザーにとっての精度の良し悪しという、ユーザーにとってのうれしさをしっかり理解して、それをヒントにアルゴリズムを変えていくのがすごく大事です。

なので、そういったユーザーのことを理解する時に、自分が直接自分の気になるところをピンポイントで聞けるかというのは、すごく大きいところです。例えばですけれども、ちょっとメールで質問するのは嫌だなとか思わずに、相手がメールが得意な人だったら臆せずにビジネスメールを書いてどんどん自分で対話をするであったりとか。

あともう1個あるのは、質問はできるという人は多いと思うんですけれども、ちょっと手間がかかることをお願いするのに遠慮しちゃう人はけっこう多いかなと思っています。先ほどの精度の評価を採点してほしいとか、新入社員向けの業務マニュアルをほしいとか、マニュアルがない時にマニュアルを作ってほしいとかですね。

大概にしてユーザーに少し負担をかけることによって突破できることがけっこう多いかなと思うんですけれども。こういう時に臆せずにお願いをしてみようというのが、すごく表面的な話のように見えて大事なのかなと思っています。

基盤モデル開発よりもアプリケーション開発に注力

最後にちょっと細かい補足ですけれども、よくご質問をいただくので書いてあるんですが、弊社では基盤モデルの開発は今のところやっていません。こういった精度の問題を分析していくとLLMのせいじゃないことがすごく多いかなと思っているので、現状は投資をしていないという感じになります。

一方で、いろんな観点でモデル開発は価値があるかなと思っています。なので、今日はいろんなトピックとか登壇者の方々がいらっしゃいましたけれども、モデル開発されている企業さまをすごく応援していますし、我々もアプリケーション側からいろんなヒントを出すことで貢献できればと思っています。

ちょっとまとめなんですけれども、たぶん時間がないと思うので少し飛ばしますが。我々としてはLLMへの参入はすごく自然な流れでしたというところと、知的単純作業を効率化させるためにがんばっていますというところです。

ちょっと延びちゃいましたけれども、ありがとうございました。

（会場拍手）