中村氏の自己紹介と、LayerXの事業紹介
中村龍矢氏：「LLMアプリケーションの安定性を高めるための精度評価・改善」という題名で発表します。よろしくお願いします。
まず簡単に自己紹介できればと思います。私は今LayerXで事業部執行役員をしていて、LLMやテクノロジーを使って事業を作ることを担当をしています。
もともとはエンジニアをやっていて、LLMで盛り上がっている前の段階の自然言語処理の機械学習のエンジニアをやっていたり、あとはセキュリティの研究として論文を書いたり、オープンソースの界隈で活動したりしていました。今は事業をやっていて、半分ぐらいは技術っぽいこと、半分ぐらいはビジネスっぽいことをやっています。
LayerXの紹介をできればと思います。
LayerXは、今3つの事業があるスタートアップで、一番有名で大きいのが「バクラク」というコーポレート向けのSaaSを展開しています。ここでもAIを使っていて、特にOCR（Optical Character Reader）のところの精度にこだわっています。
もう1個は、共同事業として三井物産さまのほか、金融機関さまとアセットマネジメントの事業をやっています。スタートアップと大手の企業さまとの連携という意味では、かなり発展しているものじゃないかなと思っています。
データやAI関連の取り組みとしては、もともとエンタープライズ企業さまとの取り組みが多くて、特にプライバシー技術を扱っていたので、企業さまのセンシティブな情報を使って事業を作って取り組んでいました。行政、金融、医療みたいな、データがセンシティブな業界との協業があります。
2023年3月、4月頃からLLMの取り組みもしています。LLMが来る前からやっていたデータ活用の支援を、我々の見立てとして、ある意味ではLLMが2歩も3歩も進めてくれるんじゃないかというところで、事業参入の判断をしました。
手前味噌ながら我々がこだわっているところとしては、これまでは本当にブロックチェーンやプライバシーテック、LLMなど、いわゆるバズワードっぽいものに事業を作ろうというところで取り組んできたのですが、いろいろ失敗と反省があったわけです。その中で、そういう技術をバズワードで終わらせないように、しっかりお客さまのペインというか、本当の課題に集中して事業に活かすというのが1つ目です。
もう1個は、エンジニアを含めて、toCのアプリを作っていたメンバーが多くて。toCのメディアやゲームは使いやすさが本当に勝負で、それが負けると事業としては負けることが多いかなと思います。
僭越ながら、これまでのtoBのSaaSやソフトウェアは、使いやすさも大事なんだけれど一要素という感じで。そこにすごくこだわりがあったものは、そんなに多くなかったんじゃないかなと勝手ながら思っています。「toBにtoCの使いやすさを」みたいなこだわりのあるメンバーもいるかなと思います。
余談で、LayerXの祖業はブロックチェーンをやっていたのですが、そういう経緯から今のLLMのトレンドをどう見ているかというと、もともと我々の中では「DXってレベルがあるよね」と思っていて。「紙とハンコをなくそう」みたいな、ある意味でレベル1の取り組みから、ブロックチェーンなどで議論されていたような、「企業の基幹システムをつないで産業の全体のDXをするんだ」みたいな。「お金の自動運転だ」みたいなテーマとグラデーションがありました。
その中で、我々としては、上のレベルからチャレンジして、いろいろ失敗をしてしまったわけです。その中で1つあった課題は、理論上は自動化できる、連携できるシステムも、表面的にデータやシステムのフォーマットが違うことによって連携できなくて、なかなかうまくいかないことが多かったなと思っています。
LLMは、ある意味、中身は同じなんだけど表面が違うものを吸収する能力に長けているかなと思うので、こういった企業間のシステム連携、DXに土台を作ってくれるんじゃないかなと勝手ながら思っていて。つながりがあるんじゃないかなというところで、個人的にも楽しく取り組んでいます。
PoCで終わらせず本番適用するために心掛けている2つのこと
では本題にいければと思います。まずBeyond PoCさせるLLM活用というところで、「Beyond PoCとは？」についてお話します。
先ほどもお話ししましたが、ブロックチェーンやプライバシーテックなど、そういういろいろなテクノロジーを起点に事業を作ろうとすることをやってきた中で、いわゆるPoC貧乏というか、PoCをやったものの先に進まない、Beyond PoCできないことをたくさん経験してきました。
そういう中で、PoCで終わらせないでしっかりと本番に適用するために心掛けているところとして、1点目が、テクノロジーが新しいと、なぜかそれにつられて使い方も新しく考えようとしがちな時があるかなと思っています。
解き方も新しくて、テクノロジーも新しくて、適用範囲、課題も新しくなると、新しいものの掛け合わせ同士ですごく難しくなってしまうので、片方は固定しようというところです。課題のほうは明確で、今でもすごくつらくて、ペインとして語れるようなものを対象にしようというのが1点目として考えているところです。
2点目が、これは我々のスタンスですが、受託開発でやるのではなくて、しっかりプロダクトにしていく。そうじゃないと、開発の投資がどんどん増えてしまって、ある意味「投資したんだから、なんかこういう方向性で」みたいなバイアスが起こりやすいので、しっかりと汎用的な技術を狙っていくのが2点目です。
「粘り強い精度改善によって実現できるユースケース」をどう実現するのか
LLMについては、この数ヶ月間ぐらいで「ChatGPT」の使用が減少したとか、少し落ち着いてきたような雰囲気もあるのかなと思っています。
あくまで我々の観測範囲ですが、ChatGPTやAzureのAPIとかをそのまま使うだけだと、それで多くの人が幸せになるようなユースケースはそんなに多くないんじゃないかなと思っています。
（スライドを示して）氷山の絵を描いていますが、既存のツールだけで十分なユースケースはすごく少なくて。一方で、あと少しというか、「もうちょっと粘ればちゃんと実用に堪えるんだ」みたいなユースケースは本当に幅広いんじゃないかなと思っています。なので、オレンジで書いてある下の部分をどういうふうに実現するのかが今日のテーマの背景です。
Beyond PoCしやすいユースケース選定の観点
難しいケースというのは、基本的には精度が悪いとか、思ったとおりに動いてくれない。AIが我々のことを思ったとおりに便利にしてくれないということが多いんじゃないかなと思っています。
そのAIの出力の精度、安定性をしっかり担保する上で、ユースケースをどういうふうに選ぶのかがけっこう大事で、ある意味では初めから勝負が決まっている側面が多いのかなと思っています。
このあたりはクリエイティブ系など、別の切り口、ユースケースが違う可能性があるのですが、あくまで我々が着目している一般的な企業の業務効率化という観点でユースケース選定の重要なポイントとして考えているのが、「精度評価がやりやすいか」というところです。
1点目は正解が明確か。「LLMでなにしたい」という、「なにしたい」ということを考えた時に、「LLMがなにを吐いてくれれば正解なんですか」ということを実は答えられないケースがけっこうあるんじゃないかなと思っています。
人間すらも答えが言語化できていないんだとするとLLMも難しいというところで、正解、不正解が判定しやすい業務であるというのが1点目です。
2点目が、正解が明確なのに加えて、その次の正解に至るプロセスも明確な業務がいいかなと思っています。LLMを改善する時は、やはり改善して近づけたい対象が明確なほうがやりやすいかなと思っています。
プロセスがあまり言語化されていない……。「いやぁ、なんかこれは誰々さんの職人芸でね」というものがあると、LLMの改善という時に、できなくはないとは思うんですが、時間がかかるかなと思っています。
この2点がそろっているユースケースだと、改善のサイクルが回しやすいので、先ほどの分類でいくと、粘り強く突破できるユースケースになり得るんじゃないかなと思っています。
（次回に続く）
