国語と算数をつなぐ「翻訳」がポイント
質問：前回に引き続き、岡さんにお話を聞いていきたいと思います。
前回はLLMが国語、システムが算数、というお話でしたが、これを受けて、「業務システムへの組み込み」という部分についてお話を伺いたいと思います。
岡：ええ。まず、大前提として、「業務システムは、間違ってはいけない」というものがあります。
要するに、「業務システムは、算数」なのです。国語じゃないんです。
質問：確かにそうですね。レストランを予約したら別のお店だったとか、有給申請をしたら1ヶ月ズレていたとか、経費精算をしたら金額が間違っていたとか、そういうことが起きてしまうと、大問題になりますよね。
岡：それを踏まえると、LLMをそのまま業務システムにはめ込む、というのは、なかなか難しいということが分かってもらえると思います。
LLMは、あくまでも「国語」です。対人間のインターフェースとして、非常に有用ですが、後ろ側の仕組みの部分まで担わせるのは、荷が重いんです。
質問：では、どのように組み込んでいくのが良いのでしょう？
人との対話は国語の世界
岡：国語機能が強いLLMが人間と対話することで、システム入力の際の制約をうまく減らしてあげることができます。これは、非常に有意義な使い方だと言えます。また、システムの出力をそのまま人間に渡すのではなく、LLMが介在することで「わかりやすい・理解しやすい」カタチに変換することもできます。
こうした、人間とのインターフェースの部分をLLMに担わせることで、ユーザー体験が大きく改善することが期待されます。いわゆる「UI/UX」の部分ですね。
質問：人との接点、対話の部分で、生成AIが活躍するわけですね。これは、ギックスが提供している「AI wrapping（AIラッピング）」のお話と関連するのでしょうか。
岡：ええ。そうです。「AIで、業務システムをラッピングする」ということは、つまり、「人から見ると、生成AIと対話しているように見える」ということです。
その裏側には、業務システムが存在していて算数の世界でギュンギュン動いているわけですが、人間から見ると国語の世界で会話できている、そんな状態です。
そうすることで「システムへの入力ストレスを減らし、知りたいこと・結果を理解しやすい形で受け取れる」というメリットが生まれます。
質問：なるほど。目指すポイントがよく分かりました。ここからは、もう少し「仕組み」「技術」に寄った部分を教えていただければと思います。とはいえ、私自身が「国語」の人間なので、あまり難しくならないようにしていただけると助かります。
岡：努力しますね（笑）
システムの世界は算数で動く
岡：先ほども申し上げた通り、ミスの許されない算数の世界が「業務システム」です。この業務システムは人間との相性が悪い。
一方で、LLMは国語の世界で、人間との対話が得意です。
そのため
人間→【国語】→生成AI（LLM）→【算数】→業務システム
という風な構造にしていくことが良さそうだ、ということになりますよね。
質問：わかります。まだ、ついていけてます。
岡：じゃぁ、どうやって、国語を算数に変換するんだ？ってことになりますよね。ここが1つのポイントです。
質問：はい。大丈夫です。
岡：ここで、超えるべきハードルは2つあります。国語の世界でのハードルと、算数の世界でのハードルです。
国語の世界のハードルは、「全然関係ない情報を引っ張ってきてしまう」というリスクを減らすことです。例えば、「ビール」と言ったときに、世の中では「ハイボール」「ワイン」などが近いところに居そうだな、と思いますよね。
でも、もし、この話が「ビール専門店のレストラン」に関するものだった場合は、「ソーセージ」「ザワークラウト」のような料理や、「ヴァイツェン」「スタウト」のような特定のビールの種類の名前を引っ張ってきてほしい、という風になりそうじゃないですか？
こういう風な情報を、しっかりと準備して、「その場面・シーンでは関係ない情報はとってこない」ように整理する必要があります。
質問：なるほど。辞書を準備するイメージでしょうか。
岡：辞書という感覚でも間違ってはいないのですが、「適切な情報群」という風に捉えてもらうのがいいかもしれません。また、前回お話したように「ベクトル空間」に配置しておくというのもポイントです。
この仕組みを「RAG（ラグ）」と言います。Retrieval-Augmented Generationの略で、日本語で言うと「検索拡張生成」なのですが、まぁ、「いい感じで検索するためのお手伝いをしてくれるヤーツ」です。
これを適切に準備しておくことで、国語の世界でのハードルを越えることができるのですが、大切なのは「業務に適した形で、適切に分けて保持しておくこと」です。
質問：なんでもかんでも一緒くたにすると、結局は、余計な情報を引っ張ってきてしまうかもしれない、ということですね。
岡：その通りです。とはいえ、足りなければ、欲しい情報が出てこないわけですから、実際に取り組む業務にフィットする形で保持しないといけません。
知識範囲（RAG）の切り分けと、その業務領域への振り分け機能が勝負の鍵
岡：そうやってRAG、つまり情報のカタマリを適切な単位で切り分けて設定し、その情報を活用していこうとすると「適切なRAGにアクセスできるようにする」という仕組みが必要になってきます。実際には、RAGとセットになったエージェントに向かって、人間からの指示を適切に渡していくわけですが、まずは「業務で必要な知識をうまく使えるようにしないといけない」ということをイメージしてもらえれば大丈夫です。
質問：確かにそうですね。せっかく綺麗に分けたのに、適切ではない情報のカタマリを使わせてしまったら、なにがなんだかわからなくなってしまいますもんね。
岡：はい。それはつまり「ミスったらダメ」という話になりますよね。
質問：あ、算数だ！
岡：そうです。算数なんです。
だから、適切な情報へのアクセスをするために人間からの指示や問い合わせを振り分けるという行為は、絶対にミスらないように気を付けながら「算数の世界」に連れて行くことが求められるんです。
このあたりのお話が、「AIオーケストレーター」とか「AI Agent（AIエージェント）」とかいう言葉の領域になってくるのですが、「AIオーケストレーター」が適切な「AI Agent+RAG」に対して情報を振り分けていく役割を担います。
この部分について「どこまで国語でやらせるのか」というのが論点です。
繰り返しますが、「間違ってはいけない算数の世界」は、LLM（国語）には担当させてはいけません。
質問：それはつまり、それはつまり、「AIオーケストレーター」の振り分け機能は、LLMだけにまかせるわけではない、ということですね。
岡：はい。そうなんです。オーケストレーターが人間と対話する部分は、LLMを活用するのですが、そこから得られた情報を適切なエージェントに振り分けていく部分は、間違いが起こらないように作り込んでおくべきです。
ギックスでは、LLMによって確率的な”近さ”を算出した上で、Pythonによって振り分けるかたちで実装することで、ミスが起こらないようにしています。
質問：オーケストレーターの主要機能が、必ずしも生成AIで動いていないというのは面白いですね。続いては、オーケストレーターの「先」にいる、AIエージェントについてお話を聞かせていただければと思います。
（次回に続く）
