# AIに知識を渡す。その先の『判断』をどう任せる？ はい、それでは始めていきます。 おはようございます。しゅんすけです。 今ちょっと考えていることを言語化してまとめておこうと思うので、 ちょっとしばらくお付き合いください。 今考えていることなんですけど、 ちょうど最近流行りのジェブ、ジェブ? ジェブってやつ出てきたじゃないですか。 ジェブね。知ってますか?みなさん。 ジェブが出てきて、今考えていることをまとめておこうと思います。 タイトルが、AIに知識を渡して、 その先の判断をどう任せるか、みたいなことをちょっと考えていました。 前提として、ジェブって今流行ってるじゃないですか、Xとかで。 ジェブが何なのかをちょっと直近いろいろ試しながらやっていたこととともに、 今の自分の中の解像度をまとめておこうと思います。 数日ジェブに関していろいろ触ってみたり、実装してみたり、使ってみたりして、 分かったことをちょっとまとめておきますね。 ジェブって何か。 簡単に言うとどういうふうに動くものかというと、 ジェブは質問に対して3種類のモードがあって、 それぞれのモードに従って回答を提供してくれるもの、みたいなイメージなんですけど、 ジェブの使い方として、質問があるじゃないですか。 質問に対して一つ目のモードが、 何て言うのかちょっとよく分からないんだけど、 ノールモード。 ノールっていうのかな。 N-O-U-Lモードっていうのがあって、 これがその質問が合っているか、合っていないか、 イエス・ノーで考えた場合、イエスになる確率がどのくらいか、 みたいなのが多分ノールだったような気がします。 その次がチョイスっていうモード。 例えば質問に選択肢がいくつかあって、 どの選択肢になる可能性が高いかを判定するモードがチョイスモード。 最後にスコアってやつがあって、 それぞれどのくらいのスコアになるか、みたいな判定ができるものがジェブ。 っていう理解でだいたい合ってると思うんですけど、 なんかイメージできますかね。 例えばカレーの話をしようか。 例えばカレーが食べたいとするじゃないですか。 カレーが食べたいとして、 チャットGPTとかにカレーが食べたいって言ったとすると、 例えばカレーが食べたいって今言ったとしたら、 チャットGPTどう答えるかっていうとおそらくなんですけど、 カレーが食べたいんですね。 例えばどうだろうな。 どんなカレーが食べたいですかとか、 カレーを食べたいとのことですけど、 どうしたいんですかって多分聞いてくると思うんですよね。 カレーが食べたいってなると、 レシピが欲しいのか、 注文したいのか、 食べに行きたいのか、みたいな感じでいくつか選択肢があると思うんですよ。 その場合、なんだろう。 どうLLMとしてカレーの例えに対してどう答えるかみたいなイメージ。 ちょっと軽くまとめると、 どうなるかっていうと、 ちょっと今GPT挟みながら出させてるんですけど、 ちょっと待ってくださいね。 カレーが食べたいとしよう。 例えばカレーが食べたいとすると、 どんな挙動になるかっていうと、 純粋なLLM。 純粋なLLMだとすると、 LLMの処理の場合。 LLMの処理の場合は、 出てくるかな、ちゃんと。 はい。 で、通常のLLMなら、その入力からレシピを紹介する、 お店をお勧めする、など文脈に応じて生成を返答しますってなるじゃないですか。 で、一方、JEBの場合、 JEBの場合は、 JEBの場合は、 JEBの場合は、 JEBの場合は、 JEBの場合。 JEBを使おうとするとどうなるかっていうと、 じゃあJEBなら、 例えばこんな感じで、 あらかじめ用意した問いに沿って判断を返します。 例えば、自炊したいのか、外食したいのか、まだわからないのかです。 カレーが食べたいだけならば、そこまではわからない。 なので、情報不足という判断を受けて、 LLMが作りたいですか、食べに行きたいですか、という聞く行動にできる。 この判断過程のプロセスにJEBを使うんですよね。 どう使うかっていうと、 この判断過程のプロセスにどうやってJEBを使うかっていうのを 分かりやすく説明するとしたらどうなるか。 例えばカレーを食べたい、JEBを使って正しく処理しようと思うと、 まずカレーが食べたいを例にすると、例えばこうなります。 まず入力を受け取るじゃないですか。 カレーが食べたいってインプットされるわけですよ。 その次にJEBが用意された問いで判断をする。 用意された問い。 この場合は自炊か外食か分かる。 この発言だけで判断できる。 自炊か外食か分かる。 この発言だけでは分からない。 これがモードとしては、自炊か外食か分かるかの質問に対して イエスかノーか。 多分これはイエスかノーかが分からないので ノー判定になって次の質問にルーティングすることになるんですよ。 その判断を受けてLLMは質問を作ります。 家で作りたいですか。外で食べに行きたいですか。 もう一回返事を受けて 家で作りたい場合、自炊の手順が 材料が分からなければ次の材料を確認するみたいな 工程に移るようになる。 これはどういうことを言っているかというと 昔、僕が言っていた ゴールシックプロンツとの概念でいくと あなたが達成したいゴールは何ですか。 それじゃないですか。 あなたが達成したいゴールに対して カレーが食べたいゴールがあるとするとすると それだけじゃ曖昧なゴールなので ゴールを確定させるために ステップバッククエスチョンをしましょうと 昔言っていたことがあると思うんですけど もう一個具体的にするためにステップバックして 質問をすることによって ゴールの解像度を上げていく作業が必要になるんですよね。 その場合に ジェブっていう判断プロセスの ロジカルな確率論的な分岐を入れるといいんじゃないかな みたいなところで 結構可能性があるんじゃないかな っていうのが理解できるかなと思います。 ちょっと伝わったかよくわからないんだけど カレーの例えでいくとこういう感じね。 ジェブがなぜいいかっていう話なんですけど インプットトークンに対して アウトプットトークンの出力コストが0円なので かなりコスト削減になるのとともに 超スーパースピードが速いっていうのがあります。 なので今まで LLMのモデルが上がっていくにつれて トークンコストとともに時間がかかる立て付けが 避けられなかったんですけど それが一気にどちらの方向にも解消される見込みである っていうところなんですよね。 これが前提の状況です。 今のエージェントに何が物足りないのか っていうところを一つずつ分解していこうと思うんだけど 今のエージェントって結構賢くなってきて 何でもできるようになってきたと思うんですけど LLMの正解に到達する正解の解像度 ゴールのイメージと成果物の形を正しく言語化を 100%一発でできる人ってなかなかいないと思うんですよ。 例えば何だろうな 議事録を作ってほしいとするじゃないですか 会議の議事録 議事録のフォーマットって 会社でそれぞれフォーマットがあったり 個人的に言うと何だろう 僕はこういうフォーマットでまとめたいみたいな 着地の成果物のイメージがあると思うんですよね それを毎回説明して始めて 今のエージェントはそれに達成することができるんですけど ただそれは毎回全員が同じクオリティの インプットができるわけじゃないって考えると 全員同じ答えにならないのが 今現状課題になっていることです 一つ目がゴールの解像度と成果物の流度というか イメージする成果物のそれぞれの個別 成果物の解像度が人それぞれ違ってくるという問題 ってなってくるとやっぱり概念としては 使いこなすっていう概念と 使い方っていう概念と その人に対する言語化能力というか 成果物の解像度能力というか ゴールを言語化できる能力っていう意味では 特殊能力系を持つ必要があるっていうのが 今のAIエージェントを使いこなそうと思うと 求めないといけないところになってくると思うんですよね あとさっきも言ったように どんどんトークンコスト お金がかかるようになってきてしまっている というところで議事録を作るぐらいで AIを使うんであれば 議事録を作るごときに お金がかかってくるわけですよ 時間は短縮するとしても その時間対価とともに お金 コストが乗ってきてしまうっていうのが 現在結構課題ですよね あと推論は良くなってきてはいるんですけど 推論すれば推論するほどに どんどん時間がかかってしまう なんか遅いな遅いなと最近思ってるんですけど これが結構課題ですよね 僕がずっとAI社員を作る文脈の中で AIエージェントを オペレーションとして正しく使えるようにならないと 企業および業務および会社としては 一般的にはちゃんと使えないと ずっと言い続けてるんですけど AIエージェントを個人で こなす文脈においてはいいんですけど それぞれ勝手な個人の能力値だけで 使う分にはね ただそれを チームとか組織とか会社とかで使おうと思うと ばらついちゃダメなんですよね ばらつくとなると 工程が不安定になっちゃうので そもそも採用することができないじゃないですか だってこの人がやったらいい答えが出るんだけど この人がインプットをこうやってやっちゃうと 正解が変わってしまうということになっちゃうんですよ なので AIエージェントにインプットを渡したとしても 同じ成果物に到達しない可能性が大きく 残ってしまうっていうのが今の現状値 AAOE AIエージェントオペレーションエクセレンスっていって 僕が作ろうとしていた概念は その渡すものの精度と 業務ナレッジ層 会社が思っているべき情報を 全員共通のものにするということ その成果物をある程度 ゲーティング クオリティチェックをした上で 承認することによって 人で成果物の品質を担保しようとしてきたのが この流れの中の一部 課題であったところ あとはSOP 標準作業手順ということで 定義したプロセスにおいては AIエージェントを使えるようにしようね みたいな概念が 今 AIエージェントに物足りない 足りてない部分を補う方向性として 作ろうと思っていた そうだったということですね そこに コストがかかる 時間がかかる およびインプット精度 ボールの解像度 業務ナレッジ層の違いとともに クオリティチェックの品質チェック問題を含めた上で こんなような課題がありますと この課題を前提にした上で そこにジェブが入ると 何かいいことが起きそうだな っていうような僕は感覚があるんですよ 今のところ感覚値として 感覚値としていい方向に動きそうだ感覚があって それが何なのかっていう言語化を 今やらないといけないな って思ってるのが今の課題感 課題感というか いいことが起きるのは多分いいことが起きるんだけど どこまでを導入した上で どこまでを任せて どこからは切り分けないといけないか をちょっとしっかり整理しないといけないな って感じているのが 今なんだろう ジェブってものをいろいろ触ってみて こんなことができるんだ あんなことができるんだ ただこれは全知全能のものじゃなくて ある一定の部分は任せるけど 任せない部分を決めないといけない 任せる部分と任せない部分と どういう風に使って どういう風なオペレーションを組んで どう任せるかをちょっと言語化して 決めないといけないなってところに ちょっと入り始めているところです 使えそうは使えそうなんですよ 使えそうは使えそうなんだけど 具体的にイメージとして 使えそうな部分を言っていくと ジェブを入れることによって インプットの部分から言うと 例えばユーザーがインプットをする上での インプットの情報量 例えば曖昧インプットの場合に突き返す 曖昧インプットを受け取っちゃって そのインプットを曖昧に解釈した結果のゴールが違う ユーザーゴールとAIの達成する 今セットされているゴールが 解釈が違うまま進むっていうことを まず一番最初手前の時点で ゲーティングでチェック 最初のインプットに対するAIの解釈が 合ってるか合ってないかのチェックポイントとして まず最初にジェブが使えるなとまず思っていて あと使えるとしたら オペレーションを組んだ場合のルールとして SOPとかクオリティ基準があると思うんですけど そこのチェック そこのチェックを今は多分 人を介しながらLMを使いながら 何とかやってるみたいなイメージだと思うんですよね それを機械的に数値化した上で 品質チェックで回せると Xとかの事例とかでも色々出てきてると思うんですけど 早いしコストも安いんで バッチというか超スピードを上げながら 複数のタスクが同じ基準でチェックできる っていうところがあるので それを使うとだいぶ効率化できるな その数値化のパラメータを調整することで その会社が欲しい品質であったり その個人が欲しい品質の成果物を 適切に定義してパラメータ調整することによって それ自体の品質チェックパラメータが 価値になってくる みたいなところが言えるんじゃないかなと思ってます 何ができたらこの組み合わせに意味があると 今期待しているかというと それを使える形で再現性高くパラメータ調整をした結果 超効率化された上で 誰でも同じ品質クオリティで この仕組みの中でAIエージェントを使えるようになると なんか超良くなるんじゃないかな みたいに思ってるっていう話 伝わりましたかね 大体僕が言いたいことはこんな感じなんですけど じゃあ一旦言語化の部分はこんな感じになります 伝わりましたでしょうか ちょっと質問等あれば コメントのほうで教えてほしいなと思います 何分ぐらいしゃべったんだろうな 10分ぐらいしゃべったのかな 何分しゃべったのかな はいしゃべりたいことは以上でございます 伝わりました