AI技術の現状と課題
Atsushi Hatakeyama
はい、London Tech Talkです。今回は、ホストの和頭さんがいらっしゃらないので、今回畑山がお伝えします。
今回は、Atsuさんと一緒にRAGについてだったりだとか、あとはSAIのセキュリティ周りについて話していきたいと思います。
それでは、Atsuさん、よろしくお願いします。
Yosuke Asai
よろしくお願いします。
今日は、London Tech Talkをジャックする企画、これ第2弾か、ちょっと分からないですけど、
せっかく、せっかくというか、Kenさんがいないので、ぜひサポートしたいなというのもありますし、
せっかくなので、この機会で話したいなというので、はい、和頭さんとやっていけたらと思います。
Atsushi Hatakeyama
そうですね、よろしくお願いします。
Yosuke Asai
はい。
Atsushi Hatakeyama
最近は、和頭さんもサイバーマンデーとか2CM系の人たちは、なかなか忙しい時期ですよね。
Yosuke Asai
ああ、言ってましたね。ちょうど、今日がブラックフライデーですね。
だから、それもあって、お子さんの世話もあってというので、すごい忙しそうにしてますね、Kenさんは。
はい。
Atsushi Hatakeyama
なかなか大変なので、助け出しというところで進めていきたいと思います。
Yosuke Asai
はい、ぜひぜひ。
なんか今日、この、すいません、やろうと思ったきっかけみたいなのもきっと話していいですか。
なんか、僕がまず、和頭さんの収録を聞いて、あれはブッククラブのまとめの回でしたね。
で、そこで今結構、ラグとかAIのことを仕事でやってるっていうのを聞いて、
で、それすごい僕は内容に興味を持ったんで、
まあ、スラックじゃなくてDiscordでメッセージをして、
ちょっとこの、どういうことしてるのかもっと教えてくださいみたいな話をして、
聞いてみたところ、全然メッセージが収まりきれないくらい気になる話があったので、
今回、ぜひ収録で話してみませんかっていう話をしたっていう感じでやってますか。
Atsushi Hatakeyama
そうですね。
自分も今ラグをやっていて、
アサヒさんのセキュリティー、特にそのCubeの話とか、
多分今後AI、バイブコーディングとかの文脈ですごくホットだなと思ったので、
自分も今回おきにいろいろお聞きできたら嬉しいなと思います。
Yosuke Asai
よろしくお願いします。
Atsushi Hatakeyama
よろしくお願いします。
SonaSweepプロジェクトの詳細
Atsushi Hatakeyama
じゃあ早速なんですけども、
導入も兼ねて直近の業務でどういうことをやってるのかっていうのを言える範囲で、
お互い共有できたらいいなと思うんですけど、
最初にアサヒさんの方をお伝えしていただくことって可能でしょうか。
Yosuke Asai
はい、もちろんです。
ちょっと前のエピソードでも話はしたんですけど、
僕はもともとSREをしていて、
プロダクションで起きる問題とかを対応したり、
それを事前に回避したりみたいな仕事だったんですけど、
今は1ヶ月前に移動して、
プロダクションに出る前のサービスを開発するチームというか、
新しいサービスを開発していくチームにいて、
チームの中にLLMとかAIのリサーチャーの人たちがいるので、
その人たちと一緒にAI、LLM関連のサービスを作っていくような仕事をしています。
もう少し詳しく言うと、
僕が今やっているのは、
SonaSweepというプロジェクトがありまして、
これ自体は、
僕の会社が作っているSonaCubeというサービスは、
基本的にコードとかの問題を見つけるというか、
開発したコードのセキュリティの問題とかバグとかを
静的解析によって見つけるツールなんですけども、
今皆さんがLLMでコードを書くときに、
LLMのモデルが持っているデータというのが、
LLMのトレーニングをするときに、
LLMに対してたくさん大量のコードのデータを読み込ませないといけない。
そうするとコードを出してくれないんですよね。
今あるアンソロピックのモデルとか、
GPTのモデルとかは、
すごい大量のコードデータを読んでいるはずなんですけれども、
もしコードのデータの質が低かったら、
出てくるコードの質も低いんじゃないの?
という癖だと出て、
それをSonaの機能でデータセットを解析して、
よりよくできるんじゃないみたいな。
データセットをよくして、それを読み込ませれば、
もっといいLLMのモデルができるのではないかみたいな。
データセットの改善をするのが、
Sona Sweepという感じですね。
今は僕はそのモデルの評価みたいな。
Sona Sweepによって作ったデータセットを使った、
モデルの評価みたいなことをしています。
Atsushi Hatakeyama
すみません、長くなりました。
いやいや、ありがとうございます。
そもそもポジションとしても、
SREから新規サービスっていうので、
すごくジャンプアップがあるのと、
あとプロダクト自体もすごく面白いなと思っていて、
どちらかというと、
ファインチューニングとかする、
ガベッジイン、ガベッジアウトじゃないですけど、
いいものを入れることで、いいものが出るでしょう思想で、
学習データセットのコード自体を評価するプロダクトを、
開発をやっているみたいな認識であっていますかね。
Yosuke Asai
まさにそんな感じです。
Atsushi Hatakeyama
ありがとうございます。
そうですね。
この後話すんですけど、
自分はどちらかというとラグで、
モデルと外部情報をどう組み合わせるかみたいな話なんですけど、
今浅井さんがやられているのは、
モデル自体を学習させるための前処理というか、
の部分で、
分類とか改善を行うというので、
近しい部分もありつつ、
ちょっと違う領域もありつつ、
新しいことが聞けるのかなというのを思いましたね。
Yosuke Asai
はい。
ちょっと前段階の場所でもあるし、
確かに関連するところもあるんで、
カスタマーサポートの自動化
Yosuke Asai
今後の話がすごい楽しみです。
じゃあ、安土さんの仕事内容も聞いてみてもいいですか。
Atsushi Hatakeyama
そうですね。
自分は今、A.coeというAIの研究組織に所属していて、
その中で何個かプロジェクトをやっているんですけど、
大きく2つやっていますと。
1個目が企業向けのラグシステムで、
大企業であればあるほど、
データソースってなるべく分離したいみたいな、
欲求とかニーズがあるので、
それをエンタープライズ向けに実現できる、
プラットフォームを1つ作っていますと。
2個目が企業向けカスタマーサポートサービスを、
完全自動化させるプラットフォームを作っていて、
例えば、サービスナウとかから、
問い合わせが来てチケットが起票されたタイミングで、
エージェントワークフローで回答まで持っていくみたいな、
必要な情報を取ってきて、
回答まで持っていくっていうのを、
N8nっていうローコードのコードツールとか、
あとはそのPythonを使って開発しているような、
感じになりますね。
Yosuke Asai
なるほど。
なかなかそれ両方とも結構違うサービスだけど、
両方とも同時に開発している感じですか?
Atsushi Hatakeyama
そうですね。
最初、今まだPoCからプロダクションに持っていくみたいな、
フェーズで、
どっちもその4ヶ月4ヶ月で一気に作って、
今スケールさせていくみたいなタイミングなんですけども、
最初にそのラグを作っていて、
そこで使えるナレッジとかっていうのは、
大体AIサービスと共通してくるので、
そのナレッジを活かして、
今度はカスタマーサポートに活かせるんじゃないか、
みたいな横展開していったみたいな感じです。
ちょっと意味わかんないと思うのでお伝えすると、
自然言語で問い合わせたいときって、
うぞうむぞうのPDFとかExcelデータを、
数値データに変換して、
自然言語でも取ってこれるような仕組みにするんですけども、
多分それってチャットでもできますし、
例えばカスタマーサポートの問い合わせの対応っていうのにも、
使えたりするので、
ベースの考え方は一緒なんだけれども、
その上でどういうふうに使うのかっていうのが、
微妙に違うみたいなイメージですね。
Yosuke Asai
なるほど。
そのカスタマーサポートを結構気になったんですけど、
これは実際に何か、
僕がこういう質問があります、
ここは僕行きませんっていう質問をしたときに、
その質問をした段階でも、
例えばエージェントがそれを拾って、
回答を用意してくれるみたいな、
そんなイメージであってますか。
Atsushi Hatakeyama
そうですね、大きくそんな感じで、
どういうふうに回答させたいかとか、
どういうふうにエージェントを振る舞わせたいかみたいなので、
ちょっと変わってくるんですけども、
例えばカスタマーサポートの回答って、
多分テンプレとか手順っていうのがある程度固定化してると思うんですよね。
まずインシデント分解して、
必要なログ取ってきたりして、
回答できなかったら、
上のエンジニアにエスカレーションするとかっていう、
いろんな分岐があると思うので、
その手順に従ってエージェントのワークフローを組んであげて、
必要に応じてログ取ってきますし、
必要に応じて類似チケットの、
どういうふうに過去解決したかみたいなの取ってきて、
参考にしたりとかすることで、
最終的にはユーザーは結果だけを確認するだけで良い、
みたいなことを目標に開発してるって感じですね。
Yosuke Asai
どういう分岐にするかとかは、
お客さんごとに分けて設定してあげて、
あとお客さんが全部自動で回答、
レビューできるところに行けるようにっていう感じなんですかね。
Atsushi Hatakeyama
そうですね。
本当にサーズとかクラウドベンダーとか、
いろんなカスタマーサポートの方いると思うんですけど、
その企業企業によってどういうふうに、
アナライズして対応するかっていうのが、
多分形式化されていると思うので、
その既存フローに従って、
なるべくエージェントが振る舞えるように、
裏側をオーケストレートさせるみたいなのが、
Yosuke Asai
結構大事かなっていう感じですね。
なるほど。
これはちなみに、
お客さん付きそうというか、
思い込みのお客さんがいたりするんですか。
Atsushi Hatakeyama
そうですね。
いるみたいなんですけど、
具体的に誰とか降りてきてなくて、
一応まずパイロット版で、
インターナルのチーム、
自社の似たような業務をやっているチームで、
内部ツールとして使ってもらって、
そこでドックフーディング的に、
自分たちのプロダクトを使って精度を高めて、
それを売り出すというか、
いろんな企業に展開していくみたいなのが、
Yosuke Asai
今後の流れになるのかなと思います。
このカスタマーサポートサービス自体も、
Atsushi Hatakeyama
ラグを使っているってことでいいんですよね。
そうですね。
ラグを使っていて、
カスタマーサポートのSOP、
サーバーオペレーションとかの手順書とかって、
もちろんパブリックにないデータもあるので、
それらを外部情報として突っ込んで、
適宜引っ張ってきて、
LLMに投げるみたいなことをしているので、
Yosuke Asai
内部的には使っています。
もう少しラグの技術的な詳細というか、
どういう風に構築するのかみたいなのが、
全然分かっていないので、
説明してもらってもいいですか?
Atsushi Hatakeyama
そうですね。
ラグとはなんぞやみたいな話からお伝えすると、
教科書的な回答をすると、
リトリバルオーギュメントジェネレーションみたいな、
RAGの基礎と仕組み
Atsushi Hatakeyama
の頭文字でラグって、
日本語だと検索拡張生成みたいなテクニックで呼ばれています。
端的に言うと、LLMが用いていない外部情報、
情報を外部情報として付け加えてあげることで、
LLMが知らない情報も回答させる、
みたいな仕組みになっています。
LLMは特定時点のデータ、
まさにアサイシさんがやられているように、
何かしらのデータを学習させて、
その特徴に基づいて回答させるなり、
言語生成させているという仕組みがあると思うんですけども、
これらはもちろんパブリックなデータを用いて学習しているので、
少し前のことは回答できるんですけども、
最新データが回答できなかったりだとか、
学習していないデータ、社内データとかはもちろん回答できませんと。
例えば少し前のチャットGPTとかだと、
これらは2023年10月時点のことで回答できないとかっていう、
不正書きみたいなのがあったと思うんですけど、
そういうことが起きますと。
一方で企業側のニーズとしては、
社内のHRについて聞きたいであったりだとか、
または営業情報について、
自然言語で対話せたいみたいなニーズがありますと。
ここのギャップを埋めるために、
LMが知らない情報、向かい部情報、
ベクトルDBと呼ばれるようなデータベースに対して突っ込んであげて、
ユーザーの質問と外部情報を一緒にLMに投げることで、
LMが不足している社内情報も自然言語で質問できますっていうのが、
ラグのざっくりとした流れになります。
Yosuke Asai
ありがとうございます。めっちゃ分かりやすかったです。
本当です。
このラグのデータベースがあって、
このプロンプトをまずユーザーが投げますよね。
投げたプロンプトに対して、
それが社内情報とかが必要な場合は、
まずはデータベースに問い合わせをして、
その情報を元にさらにプロンプトを編集して、
モデルに投げるみたいな感じであってますか?
Atsushi Hatakeyama
そうですね。近くてですね。
大きな流れとしては、まずユーザーが何かしらの質問を投げますと。
その時にまず外部情報に対して、
そのクエリと外部情報として登録してある何かしらの社内ドキュメントが近しいものがあれば、
そのドキュメントのチャンクって呼ばれるかな、
ドキュメントの短編情報を取っていきますと。
その短編情報とユーザーが元々投げていたクエリを一緒にLLMに投げるので、
最終的にLLMにたどり着く頃にはユーザーが、
例えば有給の取り方は何っていうクエリと、
有給はこうやって取りますっていう回答のドキュメントが
一緒にLLMに入って、それをもとにLLMが回答をいい感じに生成してくれるみたいな流れですね。
データマネジメントの課題
Yosuke Asai
なるほど。
じゃあそっか。付加情報を与えてプロンプトを作るっていう感じですね。
Atsushi Hatakeyama
そうですね。
Yosuke Asai
そのデータベースから取ってくる部分っていうのはLLM使ってるんですか?
Atsushi Hatakeyama
そうですね。ここも精度を向上させるためにいろんなアプローチがされるところであって、
基本的にはセマンティックサーチのように高次元、1500とかっていう次元で、
意味的に近しいところをコサイン類似度みたいなところで取っていきますと。
ベクトルDBにはそもそも何が入ってるのみたいな話をまずお伝えすると、
ドキュメントをベクトルDBに登録したいときにテキストを分割するんですよね。
そのテキスト情報とそれを数値情報に変換した埋め込みデータが一つのローに入ってくるイメージですね。
ユーザーが何か質問を投げたときに、そのクエリ自体も埋め込み数値情報に変換されて
2つの数値データの近しいところをマッチさせて、
ドキュメントが取ってこられるみたいなイメージです。
これ伝わってますかね。
Yosuke Asai
いやちょっと難しいですね。
コサインとか出てきてからちょっともう。
Atsushi Hatakeyama
意味的に近しい情報がどこにあるのかっていう判断は、
エンベディングデータっていう高次元データで算出することができるんですよね。
Yosuke Asai
これ例えば同じ質問を投げたら、ほぼ必ず同じ答え返ってくるっていうことになりますかね。
Atsushi Hatakeyama
そうですね。
そこも設定することができまして、
例えばその確率でこの質問に対してこのドキュメントどのぐらい近いみたいなのをある程度固定してるんですけども、
それをどのぐらいばらけさせるかみたいなのも編集することができて、
基本的には同じ質問をしたら同じような答えが返ってくるんですけども、
その設定に応じてある程度そのばらつきが出るような設定にしたりだとか、
確率が高いものが1位に返ってくるような設定にしたりすることもできますね。
Yosuke Asai
なるほど。
実際にその辺のツールとかライブラリーはあつしさんが変わっているんですか、
それとももうちょいコアな人が作っているみたいな感じですか。
Atsushi Hatakeyama
そうですね。今2つプロジェクトをやってるとお伝えしたんですけども、
1個目の時は自分はどちらかというとバックエンドとインフラのアーキテクチャを考えるみたいな仕事をしていて、
逆に2個目では同じかアーキテクチャを考えると今バックエンドをメインにやってる感じですね。
なので本当にこのラグでどうやって情報を取得してくるかっていうところも結構考えてはいるところです。
Yosuke Asai
じゃあ細かいライブラリの違いとか設定とかそういうのも理解しないといけないというか。
Atsushi Hatakeyama
そうですね。
Yosuke Asai
勉強しているという感じですかね。
Atsushi Hatakeyama
そうですね。この辺は本当にモデルとかあとはどうやって取得してくるかっていうテクニックに応じて
最終的に出てくるアウトプットの回答精度がかなり変わってきたりするので、
Yosuke Asai
難しくもあり改善の余地がすごくあるポイントかなと思ってます。
いや本当に難しそうですね。でもすごい面白いところですね。かなり。
Atsushi Hatakeyama
そうですね。
じゃあラグの話は一旦この辺にして、
逆にアサヒさんが行われているソナースウィープについてもちょっと深掘っていきたいんですけども。
本当ですか、はい。
Yosuke Asai
もうちょいでもラグの話聞いてもいいですか。
Atsushi Hatakeyama
全然。
Yosuke Asai
ちょっと気になるところがあって。
っていうのもやっぱりデータの管理とかちょっと気になっていて、
要は例えば人のデータとかを入れるわけじゃないですか。
例えば私はこの日に勤務していますとこの日に休みですとかそういうのがあれば
この人は休みですかみたいなのを聞けたりするわけですよね。
そういうのってどんどん更新されていくじゃないですか、社内の情報って。
それをベクテルDBに反映しなきゃいけないと思うんですけど、
それってどういうふうに反映していくのかとか気になるので聞けたら嬉しいです。
Atsushi Hatakeyama
そうですね、まさにデータをスケールさせていく方法とか
マネジメントって結構難しいトピックかなと思っていて、
結論ここ企業のニーズ次第みたいなところがあるんですよね。
というのも、例えば意図的に過去分を知りたいニーズがあったりだとか、
一方で逆に最新データしかいらないよみたいなニーズがあるので、
そのアプローチに応じてどういうふうにデータバッジ的に削除するのか更新するのかみたいなのが変わってくるので、
一位にこの方法が絶対いいですみたいなのがないっていうのが前提としてあります。
具体的なユースケースを挙げると、
例えば建設企業さんとかだと年度ごとに設計基準書とかがあるので、
そういった場合だと逆に意図的に消さずにどんどんストックさせるみたいなアプローチが取られますと。
逆にその最新データしか必要ないよっていう場合は、
さっき言ったVectorDBの中にメタデータみたいなのを付け加えてあげて、
これは例えば2025年のデータみたいなラベリングをして検索をするときに、
まず数値データでセマンティック検索するのではなく、
まずメタデータの段階で2025年のデータだけをフィルタリングしてきて、
その後にラグを検索するみたいなことをすることで、
逆にその最新データしか取ってこられないみたいなことが実現できたりしますね。
なのでデータマネジメントに関してはユースケース次第で、
どういう風に取るかっていうのはそういったメタデータとか、
いろんなアプローチを用いて期待する結果だけを取るようにするっていうのが、
基本的な手段というか戦略になるかなと思います。
Yosuke Asai
かなりお客さんごとに違うから、
お客様のニーズに応じたソリューション
Yosuke Asai
その辺はカスタマイズして設定を変えて使ってもらうっていう感じですかね。
そうですね。
どんどん更新が必要な場合のお客さんっていうのは、
どうやってデータを更新していくかってもう想定はありますかね。
例えばそのデータの更新ってすごい難しいじゃないですか。
ライブで反映させなきゃいけないとかってすごい大変だと思うんですけど、
その辺もちょっともし分かっていることがあれば聞いてみたいです。
Atsushi Hatakeyama
更新方法もお客さん時代になってきて、
お客さん、例えば大企業であればあるほど、
例えば年代の時代、シェアポイントを使っていた時代だとか、
今でいうとBOXっていうクラウドストレージを使っている時代であれば、
いろんなところにいろんな情報が散らばっているので、
それをどういうふうにAIのインフラに適応させるかっていうのが、
一つ考え方としてあるのかなと思っていて、
例えばそのBOXの情報をラグ検索できるようにしたい場合は、
BOXとかのMCPを使ってあげて、
まず疎通できるようにして、
あとはこっちがアプリケーションサイドからバッジ的に、
数値データに変換する処理をかけることもありますし、
逆にそのユーザーが一時的にこのドキュメントに対して質問したいとかっていうときは、
アプリケーション内に手動でアップロードする画面とかを設けてあげて、
ユーザーが適宜自分のナレッジベースを作れるようにするっていうようなアプローチがあるので、
どういうデータが保存されていて、
こういうふうに参照したいかに応じて、
MCPなり柔軟に入り口を提供するっていうのが手段かなと思います。
Yosuke Asai
ありがとうございます。
じゃあやっぱりお客さんごとにかなりアプリケーションのコードも異なるというか、
コアの部分は多分近いと思うんですけど、
異なるソースコードをデプロイしていくっていう感じだったんですかね、その辺は。
Atsushi Hatakeyama
そうですね、まさにおっしゃる通りで、
たぶんSaaS、逆にここのSaaSとかっていうのはそこの辺のフレキシビリティがないので、
ここ結構クルーするところかなと思うんですけど、
逆にソフトウェアを提供する側としては、
ある程度基本的なアセットを、基本的にラグのワークフローとかを組んだ上で、
細かいどういうふうにデータを登録したいだとか、
っていうところをある程度お客さんごとにカスタマイズして提供することで、
企業向けのラグっていうのが価値が出てくるのかなと思ってますね。
Yosuke Asai
理解しました。じゃあ保室する先もおそらくお客さんの環境というか、
オンプレなりお客さんのクラウド環境なりっていう感じなんですかね。
Atsushi Hatakeyama
そうですね、お客さんが例えばAWSと契約しているのであれば、
AWSに展開できるようなインフラを作りますし、
AzureならAzureなりで展開できるように、
テラフォームでコードを組んで即座に環境ができるようになっているような感じです。
Yosuke Asai
じゃあもうマルチプラットフォーム対応できるというか、
準備しているという感じですか。すごいなそれ。
それなかなか大変そうですね。
ラグモデルの運用
Yosuke Asai
それちなみに聞いてもらえれば何人くらいのチームでやってるんですか、
その全体のラグのサービスを。
Atsushi Hatakeyama
今は人出たり入ったりしてるんですけど、
平均6人くらいでクイックに回していて、
まだ6人で対応できる理由はプロダクションとかみたいに
何千人何万人が使ってるわけじゃないので、
基本的なベースラインだけ作ってあげて、
あとそのお客さんに提供するときは人をもっと増やしたり減らしたりすることで
対応してるみたいな感じです。
Yosuke Asai
それはすごいですね。6人でマルチプラットフォームもやって、
カスタマイズもやって、
ラグの内部も理解してっていうのはなかなか大変そうですね。すごいな。
Atsushi Hatakeyama
そうですね。これなんかちょっと余談みたいなんですけど、
なんか上のレイヤーの人、エグゼクティブの人とかって、
なんかAIがあればもっと生産性上がるでしょみたいな仮説があって、
じゃあもっと働けるよねみたいな。
Yosuke Asai
いやそれも。
Atsushi Hatakeyama
結果その業務が増える、めちゃめちゃ増えてるみたいなのがあるので、
そこはちょっと苦しい部分でもあります。
Yosuke Asai
本当にそうなんですね。AIがあるからもっとできるでしょみたいな感じで。
それは僕の会社もありますね。すごいプレッシャーが増えました。
Atsushi Hatakeyama
ちょっと辛いですよねそれは。
そうですね。そういうところで、
今カスタマサポートのところもベースはもう2,3週間で作ってくれって言われていて、
多分裏側のバックエンドのコードをPythonで書くと時間かかるので、
さっきちょっとちらっと言ったんですが、
N8nっていうローコードのコードツール使って一応構築したんですけども、
やっぱりそういうツールってパフォーマンス上の
ボトルネックがあったりだとかするので、
結局Pythonに変えようみたいな感じになってますね。
Yosuke Asai
そうなんだ。カスタマイズもしずらそうですね。
ローコードとか使うと思いようができないところが多かったり。
Atsushi Hatakeyama
そういうツールのいいところって、
あらかじめビルドインでツールが使えるところだと思うんですけど、
逆に捉えるとビルドイン以外をやろうとすると制限がかかったりだとか、
その内部にPythonツールを書けるところがあるんですけど、
ライブラリーが読み込めなくて結局外のPythonスクリプトを
わざわざ読み込むみたいなことをしてるので、
これは一体何をしてるんだみたいな。
Yosuke Asai
だったらPythonで書いた方が早いっていう。
Atsushi Hatakeyama
っていうなんかありますね。
その辺のバランスはやってみないと分かんないところもあるから難しいですよね。
Yosuke Asai
初めてのことだし。
Atsushi Hatakeyama
そうですね。
この話題のついでにラグの課題をもう少しお伝えすると。
Yosuke Asai
ぜひ。
Atsushi Hatakeyama
やっぱり制度向上っていうのがラグの課題というか、
達成したい一つの目標としてあると思っていて、
アサヒさんもまさにどういうふうにコードの品質を高めるかっていうのが、
AIを使う上で肝になってくるポイントかなと思ってます。
ラグだと、さっきお伝えしたLLMにコンテキストとして与える情報が
すごく重要になってきているので、
それを実現するためにいくつかのテクニックが用いられてますと。
1個あるのがOCRっていうのは非常に重要になってきていて、
エンタープライズム系だとExcelとかPDFとかいろんな
はたまた手書きのデータがあったりとかするので、
そういったテキストデータを画像とかPDFに含まれる文字っていうのを
正しく読み取ってデータベースにいかに正しく登録するかっていうのが
回答精度を高める上で非常に重要になっていきますと。
今いろんなモデルが出てきているんですけども、
まず日本語系の処理は中国系のモデルがすごく優秀というか精度が高くて、
クエンとかっていうモデルであったりだとか、
パブルOCRみたいなのがあるんですけども、
そういう中国製のモデルを使うことで手書きデータとか、
あとはPDF内の表データっていうのを正しく読み取って
ベクトルDBに登録するっていうのが、
すごく精度向上のために非常に重要なポイントになりますっていうのと、
あともう一つあるのがリランキングみたいな仕組みがありまして、
これはLM、例えばユーザーが質問を投げたときに、
まず外部情報から意味的に近いものを30件ぐらいガサッと取っていきますと、
このときに例えばユーザーがPythonについて教えてみたいなクエリを投げたときに、
例えばPython言語に関するドキュメントも取ってこられますし、
はたまたヘビに関する情報とかももしかしたら取ってこれる可能性があります。
Pythonとヘビ、キーワード的には近いので、
混ぜてくる可能性もあるんですよね。
こういった30件のデータに対して、今度は別の方法で類似度検索することで、
今度は意味的に近い順にさらに別のアプローチで並び替えるみたいなことができるんですね。
その並び替えのテクニックをリランキングみたいな言うんですけども、
こういうアプローチを取ることで、
30%ぐらい精度が向上したみたいなのがあるので、
こういったドキュメントを取ってくるプロセスの中で、
いろんなテクニックを使うことで最終的なアウトプットの演出を高められますよっていうのが、
ラグで気にするポイントというか、あるのかなと思ってます。
Yosuke Asai
なるほど。ありがとうございます。
セキュリティの新たな課題
Yosuke Asai
中国製のクエンとかの精度がいいっていうのは面白いですね。日本語だと。
Atsushi Hatakeyama
そうですね。漢字で近いのかわかんないですけど、
あと純粋にやっぱり中国の研究力というか、高いなっていうのを持っていて、
やっぱりそのディープシークとか、いろんな企業も使ってますし、
あとコストが安いとかっていうのもあるので、
今後使う企業増えるのかなっていうのを勝手に思ってますね。
Yosuke Asai
なんか僕も結構論文とか最近読むんですけどたまに、そういうキャッチアップが必要なんで。
読んでみるとやっぱり中国から来てる論文がすごい多いというか、
すごいAI関連のリサーチとか開発とかはすごい中国で活発だなっていうのは自分も感じてるところですね。
うん。
あとはその、なんかそういうキャッチアップみたいな、ほんと大変ですよね。
これまでの開発だったら、やられることに制約があったというか、
この言語とこのインフラとこれを使ってみたいな、
だったらできることってもちろんあるけど、そんなにたくさんあるわけじゃないというか、
この今AIの文脈でいうと、どんどん新しいこと出てきて、
どんどんキャッチアップしなきゃいけない内容が増えてるというか、
これやったらもっとよくなるかもしれないみたいなのがあまりにも多すぎて、
なんか大変じゃないですか。
Atsushi Hatakeyama
そうですね。まさに、まだなんか、今までそのJavaScriptとかフロントエンドとか、
あとはそのインフラのことを知ってた、勉強してたんだあれですけど、
で、その時に機械学習っていう新しいフィールドで目新しさがあって、
面白いなっていう気分は続いてるんですけども、
なんかずっとこれが続いてるんで、正直ここ2年ぐらい。
いつの日か、バンアウトじゃないですけど、
ちょっと疲れたなみたいな日が、もしかしたら来るかもしれないですね。
Yosuke Asai
いやー、なんかふと疲れたなって僕は最近思いますね。
ちょっと休みたいなみたいな。
Atsushi Hatakeyama
そうですね。まあ、量もそうですけど、やっぱりスピードが尋常じゃないみたいなところがあって、
うん、ほんとに。
ちょっと前の最新が、もう1年前ってすごい古いなみたいなのがあるので、
やっぱりその、前お話しした、若妻さんとお話しした話じゃないですけど、
学び方をどう学ぶかとか、誰の情報を参照するかみたいなのが、
なんかすごいマインドとして重要になってるなっていうのは感じます。
Yosuke Asai
うん、確かに。本当に。
必要のないことはなるべく削がないとちょっとやっていけないですね。
そうですね。リソースも限られてるので。
本当にそう思います。
Atsushi Hatakeyama
あと、なんかラグこういうところとか、
企業どういう課題あるとかなんかお聞きしたいことありますか。
Yosuke Asai
でも結構聞けたんで、満足しました。
Atsushi Hatakeyama
ありがとうございます。
Yosuke Asai
ちょっともっとキャッチアップしてからしたら質問したいことありそうですけど、
はい、ありがとうございます。
Atsushi Hatakeyama
ありがとうございます。
ちょっとじゃあ自分もお聞きしたくてですね、
純粋にざっくりセキュリティの話みたいなのをさせていただきたいなと思っていて、
今AIとかが登場したことによって、
攻撃パターンとかも変わってきたのかなみたいな思ってですね、
例えばエージェントがブラウザを実行できるようになったりだとか、
そういった意味で、
例えばバイブコーディングによって脆弱性の高度が増えたとか、
AIを用いた攻撃が増えたみたいなのを、
セキュリティの会社に勤められている方から見て、
どういう変化があったのかなみたいなのがもしあればお伺いしたいです。
Yosuke Asai
セキュリティの会社に勤めているかもしれないですけど、
僕全然その辺詳しくなくて、
全然関係ないビリングっていうプランとか決めるドメインにいたので、
全然ちょっと分かんないんですけど、
最近ちょっとやっぱり勉強しなきゃいけないこともあって、
分かる範囲でっていうと、
OWASPっていうの知ってますかね?
Atsushi Hatakeyama
はい、日売り団体。
Yosuke Asai
リスクとかで公表している、
2025年OWASP Top 10 for LLM Applicationsっていうのがあるんですけど、
それによると、
第1位がプロンプトインジェクションっていうのが出てきて、
プロンプトに対してインジェクトするのをしてくる、
プロンプトを編集して、
それを悪意のあるプロンプトをLLMに投げるとか、
そういういろんな新しいのが出てきているっていうのは、
すごい話題になっていて、
LLMでもサプライチェーンアタックっていう、
多分モデルのトレーニングの時に悪いデータを仕込むとか、
あとは何だろうな、
あとはあれですね、
たぶん畑山さん、厚木さんのやつでも関係ありそうですけど、
アウトプットが、
例えば出すべきでないアウトプットを出してしまう、
ラグとかだと特に問題ないそうですけど、
ある平社員の人がこの情報をくださいって言って、
本来見るべきじゃない情報が見えてしまうとか、
そういうのもあるっていう話なので、
その辺の情報は社内ではいろいろとキャッチアップが進んでいるっていう感じですかね。
AI活用の未来
Atsushi Hatakeyama
そうですね、
まさにAIとかエージェントでどこまでやらせるかみたいなのが、
結構難しいようなポイントになってきていると思っていて、
エージェントがある種自由にログとかを見に行ける分、
どこまでやらせるのかっていうのが、
そこの権限決めっていうのがすごく大事かなと思っています。
あとラグとかだとガードレールって言って、
ユーザーの入力情報を評価してLMに投げるかどうか決めたりだとか、
逆にLMのアウトプットを見てユーザーに返すかどうかを決めたりだとか、
いろんなレイヤーを設けてあげることで、
いかに安全に自由に使わせることができるかっていうのが、
難しいところかなっていうのを確かに開発していて思います。
Yosuke Asai
本当に多分いろんな可能性が増えているというか、
これまでだったらSQLインジェクションとかクロスサイトスクリプティングとか、
静的解析の概要
Yosuke Asai
そういうメジャーなのがあって、
さらにLMに含まれるデータに問題があるとかそういうのが出てくるので、
いろいろとその辺は僕ももっと勉強していきたいなっていう感じですけど。
Atsushi Hatakeyama
ここ追加で質問してもいいですか。
Yosuke Asai
はい、どうぞ。
Atsushi Hatakeyama
アサヒさん、多分行動の中で良いデータと悪いデータの識別みたいなのを
しているのかなっていうのを勝手に思っているんですけども、
なんかその中で危険なデータ、危険な行動っていうのが
どういう風に分類しているのかなっていうのが気になりました。
Yosuke Asai
僕の今の業務ではそんなにそういうことはまだやっていないんですけれども、
ソナーの製品、ソナーキューブがやっていることは簡単にお話できて、
そもそもソナーキューブは何をしているかというと、
静的解析っていうのをしていますと、
静的解析とは何かというと動的解析というのもあって、
動的解析というのは要はテストですよね。
要はテストを書いて実際にプログラムを実行して確認する。
あとはセキュリティの文脈でいうと、
Penetration Test、日本語で痛感テストっていうんですかね。
ちょっと分からないですけど、そういう実際にブラックボックスでテストをするとか、
実行するテストが動的解析で、
静的解析の方はコンパイラーとか、
コンパイル段階でのコードを実行せずに解析していくっていうのをやってますね。
いろんなテクニックがあるんですけど、
一つ有名なのはASTっていうのがあって、
Abstract Syntax Treeって言うんですけど、
これは単純にコードの情報とクラスとメソッドと、
if文と変数があってみたいな、
そういう情報を全部ツリーにして解析しますみたいなのがあって、
これは例えばなんだろうな、
どういうのかな。
例えばif文で、
このif文に到達しませんとか、そういうことが分かったりするのかなっていうのがあったり、
もっとセキュリティ系の検知しやすいロジックもあって、
それが例えばTaint Analysisっていうのがあるんですけど、
知ってますかね、こういうの。
Atsushi Hatakeyama
ASTまではついていったんですけど、
その単語がちょっと分からなかったです。
Yosuke Asai
Taint Analysisっていうのもあって、
これはなんだろうな、それこそSQL Injectionとか、
そういうメジャーなセキュリティ系の問題を検知できるやつで、
どういうものかというと、ソースとシンクっていうのがあって、
必ずSQL Injectionするためには入力が必要で、
ユーザーからの入力があって、
その入力っていうのは基本的には信頼できないですと。
それが実際にSQL実行されるところに到達するかどうか、
みたいなのをチェックするもので、
そのプログラムのコントロールフローっていって、
その流れを全部フローにして解析していくっていう感じですね。
その入力がもしサニタイズされずに実行されてしまうと、
例えばドロップテーブルみたいなものがそのまま実行されちゃう可能性があるので、
そういうのを検知するっていうのがTaint Analysisになりますね。
脆弱性検知の手法
Yosuke Asai
他にもいくつか手法はあるんですけど、こんな感じですかね。
Atsushi Hatakeyama
ありがとうございます。
Yosuke Asai
ちょっとあれですよね。
Atsushi Hatakeyama
個人的にESLintみたいなの頑張って作ろうと思ってたので、
勝手にASTにしたものに対して何か事前定義したルールベース、
例えばこういうパターンだったらSQL Injection起きるなとか、
わかるのかなと思ったので、そういうわけじゃなくて、
Taint Analysisみたいないろんなアプローチで、
コードの中の脆弱性っていうのを検知してるみたいな流れになるんですかね。
Yosuke Asai
そうですね。
特徴があって、ASTの場合はやっぱりやれることが限られてるというか、
見つけられるバグの数が少ないんですよね。
その分、正確性は高いというか、
見つけたものはバグである可能性が高いっていうのもあるんですけど、
一方でコントロールフローとかTaint Analysisを使うと、
よりいろんなものを見つけられる、やっぱりフローがわかるので。
一方で正確性が低くなりがち、そのASTに比べると。
なので、フォルストポジティブ、擬陽性みたいなのが出やすいっていう特徴があって、
その辺はうまく組み合わせて使うというか、必要がありますね。
セキュリティ系の問題っていうのは、
ケンさんがお得意のアナロジーで言うと、
手洗い部屋みたいなのと結構近くて、
例えば、自分が外から帰ってきて、
手に細菌がついてるかついてないかはわかんないけど、
とりあえず手を洗っておくっていうのはついてるかもしれないし、
ついてたら風邪ひいちゃうかっていうのはありますよね。
このTaint Analysisも、
もしかしたらこれはセキュリティ的に問題ないかもしれないけど、
可能性があるから、擬陽性でもとりあえず上げておくっていう。
上げたほうがいいっていうのはあるので、
これは結構擬陽性が出るのは仕方ないっていう方向で解析をする。
でも擬陽性が多すぎてもその辺のバランスは大事なんですけど。
一方でASTのほうはバグの検知とかが多いんで、
例えばアレルギー検査みたいな。
例えば卵は食べれませんみたいなのが擬陽性で言ったら、
そうすると一生卵は食べれなくて、だいぶ人生損するじゃないですか。
っていうので、そういうバグとかを見つけ、
これはバグですよっていうのをちょっと嘘で言ってしまうと、
結構それも逆に問題なんで、
ASTや正確性を重視しているみたいなところはありますかね。
逆にこれ混乱したかもしれないですけど。
Atsushi Hatakeyama
こんな感じの説明で大丈夫でしょうか。
ありがとうございます。
じゃあフェーズじゃないですけど、
どういったアプローチに応じて正確性が違かったりだとか、
検出できるパターンが違かったりするみたいな感じなんですか。
Yosuke Asai
そうですね。
より複雑な分析をするとより時間もかかるんで、
その辺はトレードオフというか、
しながら多分開発しているんですかね。
Atsushi Hatakeyama
なるほど。
なんかここの検知のプロセスの中において、
ある程度傾向というか、
ルールベースで検出できるのか、
そのプロセスの中にAIみたいなのが入る余地があって、
統計的にとか特徴的にこの可能性があるみたいな判別をしているのかというと、
どういうアプローチが取られているのか。
Yosuke Asai
基本的に今ソナーがやっているのはルールベースの解析ですね。
逆にAIを使って新たなルールを見つけていくっていうのはありますけど、
解析の段階では今はAIは使っていないという認識です。
使っているかもしれないです。
逆にAIを使ってできるのは、
どんな新しい接着性があるかっていうのを、
エージェントにチェックしてもらうとか、
そういう製品外でそういうのはかなりやっているとは思いますね。
Atsushi Hatakeyama
そうですね。ソースコードの検出だとルールベースとかでいいかもしれないですけど、
なんかモンキーテストというか、
ダストみたいな投擲テストだとエージェントが頑張って動いて、
ここ行けそうだなとかっていうのを見つけるとかっていう余地があるのかなっていうのを勝手に思いましたね。
Yosuke Asai
そうですね。
多分それをやるとエージェントとかAIのリスポンスを待ってとかやらなきゃいけないので、
その分やっぱり解析の時間は増えるので、
それでも問題ないかとか、
多分それを認めてもらえる状況であれば、
そういうのがもっと実装されていくのかもしれませんね。
例えばマスターブランチだけはそれを確認してみるとか、
だったらコスト的にも問題ないですよみたいな感じになるかもしれないですし。
Atsushi Hatakeyama
ありがとうございます。
関連した質問なんですけど、
例えばルールベースで決めるっていうことは、
ある程度こういう書き方がまずいよねとかっていうのが分かっている状態で
ルール定義ができると思うんですけども、
そういった情報とか、もしくは脆弱性の情報っていうのは
どういうふうに取得されているのかなみたいなのが気になりました。
Yosuke Asai
これも僕はあまり分かんないんですけど、
僕の会社のソナの社内にはセキュリティチームがいるので、
間違いなく最新のCVEって書いてありますかね、
セキュリティ系の脆弱性の情報を引っ張ってきて、
チェックしてこれを製品に反映するべきかどうかっていうのは議論していると思います。
あとは、うちの会社で最近買収した会社の製品で、
ソフトウェアコンポジションアナリシススカっていうのがあって、
それ自体は脆弱性の、
何をしているかというと、
サードパーティーのライブラリとかをチェックする。
自分たちが書いたコードだけじゃなくて、
自分たちが使っているサードパーティーのライブラリに問題がある可能性もあるので、
それをチェックするみたいな製品も導入していて、
それを使うと、
そのサービス自体が脆弱性のデータベースを持っているんですよね。
このライブラリのこのバージョンは脆弱性がありますとか、
このバージョンを使っている場合はダメですよみたいな検知してくれますし、
逆にサードパーティーのコードを解析することで脆弱性を見つけたりとかこともできるんですよね。
なので、そういうのを今は開発しているというか、
Atsushi Hatakeyama
製品として出していますね。
確かに今なんか自分の視点、
自分が書いたソースコードみたいな視点になってますけど、
もちろんその使うサードパーティーの中で脆弱性があって、
それに引っ張られるみたいなことも全然ありますよね。
Yosuke Asai
確かに。
僕が一番覚えているのはログ4Jっていうので、
インシデントが、バグがあったっていうのは何年前だろうな。
7年前くらいか5年前くらいかにあったんですけど、
Javaのライブラリですね。
そういうのでかなり多くの企業が影響を受けて、
すぐパッチ出さなきゃみたいな感じになっていたので、
そういうのを早めに解析できたらやっぱりいいですよね。
Atsushi Hatakeyama
セキュリティチームがありつつ、
買収した企業もそういったナレッジを持っているっていう感じなんですね。
Yosuke Asai
そうですね。
Atsushi Hatakeyama
ありがとうございます。
Yosuke Asai
おっしゃる通り、
セキュリティはかなり会社の中でも注目されるトピックになっている感じはあって、
やっぱりLLMの登場で、
このLLMに書かれた行動が安全じゃない可能性がやっぱりまだ高いので、
それはしっかりチェックしたいよねっていうのは、
ニーズとしてもすごいあるのかなという気はしますね。
ありがとうございます。
Atsushi Hatakeyama
ちなみに今あったソースコード上のセキュリティに限ってお話したと思うんですけど、
逆にエージェント自体のセキュリティチェックとかっていう、
Yosuke Asai
もっと幅広い分野に拡張していくみたいなビジョンとかってあったりするんですかね。
今後の展望
Yosuke Asai
その辺は僕あんまり分からないんですけど正直。
エージェント、
ソナーさっき言った通りのドメインは静的解析なので、
エージェントのチェックをするとなると、
実際実行されているもののチェックになるので、
どうやってやるのかっていまいち分からないですね。
やっぱりエージェントを動かす部分のコードとか、
例えばプロンプトというかガイドラインみたいなのをチェックするっていうのは、
確かにできるのかもしれないですけど。
その辺は僕はあんまり分からないですね。
Atsushi Hatakeyama
じゃあセキュリティっていうドメインは同じでありつつ、
より詳細にコードなのかエージェントなのかって、
Yosuke Asai
結構文脈が違ってくるみたいな感じなんですね。
そうですね。
さっきおっしゃったようにダイナミックなテストっていうの多分うちはあんまりやってないんで、
それはまた別のサービスとかを使ってやる必要があるのかなっていう、
間違ってたらすいません。
Atsushi Hatakeyama
いえいえ。
他の企業さんとかで不正検知で、
本当にマウス動かしてるのが人間かどうかみたいなので、
タンピングみたいなマウスの動きとかを見たりとかで判断するみたいなのがあったので、
そういうこと考えてるのかなと思って質問しました。
Yosuke Asai
それは分からないですね。
なんかあれも僕すごい気になって、
ロボットじゃないですかみたいな確認、
たぶんクラウドフレアとかでどうやって確認してるんだろうみたいな。
気になりましたね、確かに。
全然僕には分かりません。
Atsushi Hatakeyama
分かります。
じゃあ最後に、
今SREからAIエンジニアに転身されたと思うんですけど、
今後深掘りしたいトピックとか、
個人的に面白いなって思ってる領域があるかどうか聞いてみたいですね。
Yosuke Asai
なんだろうな、難しいな。
でもやっぱりロノテキトークで、
データベースの本とかすごい読んだので、
けんさんたちと一緒に。
データベースの知識とかも活かしつつ、
それでLLMと絡められるところがあればいいなと思ってて。
やっぱりさっきおっしゃったようなベクトルデータベースとか、
すごい面白そうだなって思いますし、
今LLMのトレーニングはしてないですけど、
トレーニングとかに近いところにいるので、
その辺どうやってやったら効率がいいのかみたいなのは、
もっと調べてみたら面白そうだなと思ってますし、
あんまり今目の前のこと精一杯なんで、
ちゃんと決まってないですね。
あつしさんはどうですか。
Atsushi Hatakeyama
そうですね。
自分も短期的には同じで、
まずラグとか、
先生を使ったアプリケーションの深掘りとか、
精度向上っていうのを深掘りをしていきたいんですけども、
長期的に面白いなと思っているのが、
自分もセキュリティとロボティックス、
ロボットの分野が長期的に面白いのかなと思っていて、
自動運転とかもそうですけど、
ロボットが人間社会に入ってくる未来とか、
中国の動画とかすごい、
テスラもそうですけど、
とか思うんですけど、
その辺もし時間があったら、
修士とか行って、
こういう感じなんだみたいなのを深掘りしたら、
すごい面白いのかなと思いますね。
Yosuke Asai
いいですね。
そっか、修士か。
夢があるな、それは。
でもなんか本当に、
そろそろ学校終わるんでしたっけ?
そうですね。
Atsushi Hatakeyama
あと1年でちょうど卒業できるような感じですね。
Yosuke Asai
それでそれが終わってからまた次の分野にっていう感じですかね。
Atsushi Hatakeyama
そうですね。
多分なんかセキュリティとかも、
いたちごっこじゃないですけど、
多分今後いくら行動がかかれても、
残り続ける分野かなと思っていて、
AIが発展したことによって攻撃種も多様化していると思うので、
セキュリティを深掘るっていうのも、
Yosuke Asai
すごく面白いなっていうのを思ってますね。
いやーちょっと楽しみですね、今後。
ラグとデータベースの展望
Atsushi Hatakeyama
ちょっと若いうちに頑張っておこうっていうようなモチベーションでやってます。
Yosuke Asai
素晴らしいです。
大学も通いながら、
こんだけ仕事をしてるっていうのはすごすぎますね。
パワフルだ。
Atsushi Hatakeyama
新しいことに向けてちょっと頑張ろうかなって感じですね。
Yosuke Asai
はい。きっと今後のアップデート楽しみにしてます。
Atsushi Hatakeyama
浅井さんのセキュリティの分野について、
Yosuke Asai
またアップデートがあればお話ししたいです。
僕はセキュリティそんなにメインでやってないんですけど、
でもこうやって興味を持ってもらえて、
Atsushi Hatakeyama
僕も勉強できると思うので頑張ります。
Yosuke Asai
ちょっと1時間ぐらいお話ししましたね。
じゃあこんなところで終わりにしますか。
Atsushi Hatakeyama
そうですね。
本日は浅井さんとラグとセキュリティについてお話ししました。
コメント、ご感想あればツイッターにてよろしくお願いします。
本日はありがとうございました。
Yosuke Asai
ありがとうございます。
なんだっけ、Googleドックスじゃなくて、Googleフォームでぜひお願いします。
Atsushi Hatakeyama
ありがとうございます。
ありがとうございました。
