AI料金設定の再訪と実証実験の開始
こんにちは。
いつもの雑談、まじめな技術、略していつまじラジオのじえです。
おやはらです。
はい、本日は私の持ち込み企画ですね。
今日は、懐かしのAIの料金について。
なんか聞いたことあるか?
以前、第何回だ?4回か5回ぐらいですかね。
結構最初の方に。
多分、AIの料金について話させていただいて、
その当時、価格設定難しいですっていう話をさせていただいたと思います。
それから、あれからだから収録自体は1月にしていて、配信自体は確か2月の初めにしたんですよ。
で、あれからもう5ヶ月ぐらい経ちまして、
多分聞いてる方々も気になってるんじゃないかと思って。
まあ一旦それで進めよう。
これで気になってない人は終わっちゃうからね。
気になってないって言われたら、もうネタがなくなっちゃうから。
気になってる体で話したいと。
僕は気になってる体で手を出せるんで、まかしが。
よろしくお願いします。
前回覚えてます?どこまで、どういう話をしたか。
なんで、今から実際に試験的に運用するっていうところぐらいで、
実際そこからチューニングしなきゃいけないみたいなのだったっけ?
はいはい。前回はその価格設定は理論値で決めようとしてたんだけど、
どうしても価格幅が大きすぎて決めれないと。
そんな中、これは実際に業務で使ってもらって、
どんなもんかを見た方がいいという結論に至り、
じゃあ実証実験しましょうって終わった。
うん。前回はね。
前回は。
リアルタイムAIの課題：業務フローのボトルネック
で、あれから5ヶ月ぐらい経って、だいぶ機能も充実してきましたと。
あっから機能追加をしてる。
機能追加もしてます。
で、まず実証実験をまずしましたと。1回。
で、したんですけど、
まあ、その端的に言うと、業務に耐えられなかったんだよね。
業務に耐えられないとは。
はい。その業務をする上で、薬局で薬剤師さんが業務をする上で、
調剤したりとか指導したりみたいな、
患者さんに指導したりとかっていうのをするんだけど、
その中で、要するにAIが普段のその業務フローの中に、
AIで何かを生成するっていう時間が発生するようになっちゃった。
要するに待ち時間。
今までこの業務フローにはなかった待ち時間が発生するようになってしまって、
で、その待ち時間が1分から1分半あるんだけど、
結構薬局って思ってる以上に忙しくて、
いろいろ時短でさばかないといけないかったり、
患者さんも待たせ、患者さんもどんどん吐かせていかないといけないってなった時に、
やっぱその待ち時間がボトルネックになって、
業務運用上に乗せられなかった。
勝手に薬作ってる時にこれ動かしといてとかそんな感じで問題ないのかなと思ってたけど、
そうじゃないって。
そうだね。
パッパパッパっていくから、それを待って、
その次のアクションに行くっていうのが、
業務上耐えられなくて、
ダメだな。
これは多分このままじゃあこの機能を公開したとて、
うまく使ってもらえないだろうなっていう結論に至ったのが1回目の実証式でした。
課題解決策：バッチ処理の導入
ここからもともと必要だよねと思われてたんだけど、
要するにそこではリアルタイムでの生成っていうのが待てないっていう話だから、
しかもこの機能って別にそのリアルタイムにあって、
リアルタイムに待って作ってもらわなくても割と活かせるものだったんだよね。
っていうのも、この機能って慢性疾患の患者というか、
何日も14日ごとに、服用日数とかあるじゃん。
14日ごとに定期的に来る人たち。
同じ薬を定期的に処方される人たちとかに結構使える機能だったりしたから、
そういう意味で、じゃあそういう人たちをターゲットにするなら、
事前に作られてればいいじゃん。
毎回似たような処方で来るんだから、
同じような注意事項になるけど、
でも同じような注意事項になるんだけど、
薬剤師としては同じような注意を服薬指導したいわけではなくて、
たまにはその表情とその注意すべき薬の組み合わせで、
なんか違うふうに指導したりとかしたい。
それが要するに患者個別に指導してますよっていう証になるから、
そういうふうなニーズもあるんで、
事前に作っておけばいいよねっていうのがあって、
バッチ機能みたいなのを作らないといけないよねっていう話に。
なんかこの比較的まだまだ若くて健康な我々は、
たまに薬局に行くだけだからあんまわかんないけど、
薬局から見ると、
よく適切な表現がわかんないけど、
リピーターみたいな人が多くて、
事前にやっていくことでも、
やっていくのも結構需要があるっていう話。
年老いた方たちとかは、
やっぱり慢性的な治らない疾患みたいなのを持ってたりするんで、
それって定期的に薬を処方されて、
飲まないといけなくて、
そのたんびに薬局行って表情を見て、
副作用とかを考慮しながら、
その人に指導をしたりするのが薬剤師の仕事なんだけど、
そういった時に毎日機械のように同じことばっかり言ってても仕方ないから、
そういう風にバリエーションを変えて話したりするっていうことがある。
だからその生成されたやつの、
今日はこれを重点的に伝えようとか、
明日、次来た時にはこれを伝えようとか、そういうことですか?
そう、機能としては、
患者さんの処方の情報と、
なんか基本、頭かきって言われる患者さんの基本情報とか、
そういった患者さんに由来するような情報っていうのを、
AIに渡して、プロンプトめちゃくちゃいろいろやってるんだけど、
その中でAIが分析して、
この薬とこの薬とこの薬が出てるから、
こういうことを注意しないといけないよっていうのを、
いくつか、6個?6個とか7個とかのテキストボックスを作ってくれて、
それを見ながら、
今日はこれを説明しようとかを選べるようになるみたいな。
そうそう。
なんか、ちょっともしかしたら、
聞いてくれてる人を置き去りにしながら質問したいかもしれない。
そうだね。
バッジ処理っていうのは定期実行なの?
定期実行だね。
その場合って、例えば2週間間隔で来てるとして、
13日目ぐらいに、
明日来る患者さんのデータを事前生成しといて、
みたいなことが起きるってこと?
そう予測して、
ぶっちゃけると、今の予測はまだまだ精度が良くなくて、
できれば患者さんが来る日までに作られていて欲しいところだけど、
今はなかなか予測、
来局予測って言って、
副用日数に応じて、
副用日数って14日とか7日とか出るんだけど、
データとして7日とか14日って持ってるから、
前回来局してから何日経ってるかで、
その薬がなくなってるかどうかっていうのは、
システム的には、
ちゃんと飲んでるのね、その人が。
システム的には出せるから。
その場合ってもう受付データを作っちゃうって話ですか?
いや、受付データじゃなくて、
今回の場合だと、
バッチの場合だと婚会処方っていうのは捨てる、捨てる。
捨てる?
婚会処方ってまだ来てないから、
前回処方された薬を元に生成する、みたいな機能。
で、さっき言ったけど、
慢性の患者っていうのは、いわゆる処方があまり変わらないから、
だから前回の処方されたもので作られたその注意事項でも、
今回の指導に活かせるよねっていう話。
はい、すいません。じゃあ戻っていただいて。
AI料金体系とリソース割り当ての現実
それで、そういったバッチを選ぶ理由としてもう一つあるのは、
価格なんでね。
普通にリアルタイムで標準で使うってなった場合って、
結構高くて、
忘れちゃったけどどんくらいだったっけな。
結構高いのよ。
そのトークンあたりの利用料みたいな。
そう、トークンあたりのコストが高くて。
しかも買わせもひどい有様じゃないですかね。
かなり高くて、
一回、やっぱり検証したけど、
一回20円ぐらいはかかっちゃうから、
リアルタイムだと。
そう。20円以上かかっちゃうときも普通にあるし、
それも薬の量に応じて上下するから、
もうこれ選べんよなーとか思って、
やっぱり理論値で出したように、
やっぱこれ無理やなーって感じになったんでね。
で、バッチだとそれが半額になる。
なんでそれを?
それなんで半額になるんですか?
リアルタイムは、
ちゃんとリクエストされたら、
AIのリソースを割り当てないといけない。
AIのリソースを割り当てるってどういうことですか?
物理的なリソースをその場で割り当てないといけないんだけど、
でもバッチは、
リソース渡した瞬間に、
まずは待機して、
要するにリソースが空いたらそこに割り当てるみたいな。
だから有料ユーザーの方が優先しますよ、みたいな感覚?
みたいな感覚。
今もクロードで言ってるじゃん。
速度がなんちゃらかんちゃらとか、
遅い速いって、
あれってお金をかければかけるほど、
要するに優先的に、
プライオリティーハイで、
マシンリソースを使えますよって言ってる。
今、電力もそうだし、
電力と建物かデータセンターって、
やっぱ枯渇してるから、
それこそ大手企業をいっぱい使ってる企業ほど、
声優が多いとかもあるし、
そういうのがあるの、裏で本当に。
だから実際に話してて、
そういう割り当て方をされるみたいだから。
それは何に含むと優先度を調整できますか?
一応APIなんだけど、
APIの場合は、
そういうタグみたいなのつければできるんだけど、
めっちゃ高い。
さらに高い。
標準もやっぱりなんだかんだ言って、
何リクエストかすると、
そういうマチとかが発生したりとか、
本当の意味での即時ではないって。
本当の意味で即時で使いたかったら、
プライオリティーみたいなのつけて、
私優先ですよっていうのになるんだけど、
確か2、3倍くらいする。
そう、確かに。
めっちゃ高くて、
それは無理やろって言うと、
今でさえ標準でさえ、
そういう風に速度とか、
速度もそうだし、
料金で苦しんでるのに、
無理やなって思って。
そうなんだ。
第二次実証実験：事前生成の有効性検証
でもトンザしたわけじゃないんですよ。
トンザしたわけじゃない。
今まだ、バッチの機能は、
ちょうど今検証をして、
で、検証する際にやったのが、
それこそ、我々がこう、
知りたかったのは、
事前にそのさっき言ってた注意事項っていうのが、
存在すること。
存在していることがどれだけ業務を回す上で意味があるのか、
っていうのを知りたかったから、
バッチだとピンポイントでやらないといけなかったり、
精度がやっぱり低かったりするんで、
ピンポイントでできないわけ。
だから患者さんが来た時に、
その来た患者さんの、
その注意事項ができてくれてればいいんだけど、
精度が弱いからできてなかったりするとかあって、
それだとまあやっぱり、
我々が確かめたかった事前にあることでの業務を、
業務がどれだけ効率的になったりとか、
本当に活かせるのかとか、
より質の高い調査、
指導とかができるようになったのかっていうのを確かめたかったんだけど、
で、それで対処したのが、
事前に3ヶ月前の患者さん、
来局した患者さんを対象に、
注意事項を一括で作って、
検証してもらおうってことで、
今2回目の実証実験をしてる。
もうしてるんですか。
もうしてる。
ただその、やる前、やるにあたっては、
やってくれてる、協力してくれる薬局さんと話して、
こういうのだったら確かに役に立つかもねっていうのは、
話した上でそれをやってると。
そうそう、それを話した上で事前にあったら、
やっぱり生成する時間っていうのが、
やっぱりボトルネックでしたよねっていうのは、
本当に双方で理解した上で、
じゃあ事前に作られていることで、
確かに新しい処方には対処できないですけど、
あることで慢性だとか、そういった日数が長い患者さんには、
有効に働く可能性がありますよねっていうところで、
今使ってもらってるってことで。
薬局業務へのAI統合と費用対効果
その場合って、1回生成したら、
基本的には再生成はしないんですか。
再生成は処方が変わったタイミングとかで再生成するっていう感じ。
だから継続して同じのだったら別にわざわざ再生成してない。
してない。
思うのは、毎回同じなんだったら、
そもそもこのAIで生成してほしいっていうニーズがあるイメージがなかったけど。
毎回一緒だよね。変わった時には作らないといけないんで、
それは次バッチでやるなり、
リアルタイムの業務時間にやるなりして作るっていう方法になるかなっていう感じ。
なんかこう、理想、これがどの程度実際にいいのかわかんないですけど、
聞いた感じの理想としては、受付で処方箋何かしら読み取った瞬間、
もう裏でAI動いて、あれが始まってるみたいな。
それがベストではあるよね。
仮にやったとして、それでもちょっとやっぱり待ちは発生しそうなんですか。
いや、あれはだから結局、
すげえ専門用語になっちゃうけど、
専門用語っていうか、
薬局向けの、薬局業界の専門用語になっちゃうけど、
AIとかOCRとか電子処方箋とかで、要するに読み込んで、
それをまずレセコンに渡すじゃん。
で、レセコンに渡して、レセコンで入力するじゃん。
で、入力してSIPSになって初めて薬歴に来るわけよ。
読み込んだ時点でSIPSになってもらわないと困る。薬歴としては。
そういうことか。
そうしたら、読み込んでもう自動で生成するってことができると思うんでね。
3文を読み込んで。
それって、レセコン側でAI乗っけた方が良かったって話もある。
いや、でも、今回作らないといけないものは薬歴上にある情報からしか作れないから。
あ、そうね。
で、欲しいのは処方の情報。
最初の処方、今回処方の情報だけSIPSで欲しいんだけど、
SIPSになるまでにはその過程を踏まないといけないじゃん。
レセコンで色々やった後に来てって。
そしたらもう来た時は結局もう薬剤師の仕事ってやってて、
で、後は来たものに対して入力をするみたいな感じになるから。
確かに処方されたものと頂戴されたものが必ずつも一致してるわけじゃないから。
結局レセコンで入力しなきゃいけないのか。
色々と補足をしていくと、
レセコンっていうのが料金を計算するためのシステムで、
薬歴っていうのは、その料金を計算するにあたって色んなお薬の情報を入れて金額を出します。
色々と入力した情報を元に、
お客さんに副薬指導っていう、
これお薬出てるからこう飲んでくださいねとか、
っていうのを作ったりしますと。
そこの受け渡しをしてるのがSIPSっていう企画。
そうだね、インターフェース。
大体そんな感じです。
伝わらない。
なかなか伝わらん気がする。
そういう事情で、
なかなか難しいところだった。
レセコンでもった気がする。
そうそうそう。
だからやっぱそうなると、
大金叩いて超高性能なの。
使うのかバッチ使うのかみたいな。
バッチだったら半額になって安いし、
それこそ価格設定の面でも、
もう一つあってその注意事項っていうものを使って、
実際に患者さんにどう指導するかっていうのを自動生成してくれるやつがある。
それはもう30秒以内で終わるんで、
それは早いんだけど、
早いから全然気にしなくていいんだけど。
実際にその注意事項ができてて、
30秒ぐらいだったら、
業務フロー上問題ないですよねっていうのは確認してたりして。
例えば、実際にプランとして、
ちょっといいプランで用意して、
リアルタイムで高性能なAIを使います、
でもちょっと高いですって用意した場合って、
1位受付あたりに取れる単価って、
別に薬局さんの努力でどうこうできる話じゃないじゃないですか。
そうだね。
そうなった場合に、薬局側としては、
どう足掻いても結構感化できないぐらいの料金にはなっちゃうんですかね。
多分1位受付あたり、1位処方あたり、確か
言ってたんだよな。
2500技術料とかそもそもで、
多分薬局の利益としては2500円とか取れる。
それは患者さんの10割が2500円っていう話じゃなくて、
そこからの利益が2500円。
多分。
だからその
しかもそこで人件費とかいろいろ考えたら1処方あたり。
それかかるよね。
だからやっぱり高い料金払ってる場合じゃないのか。
そうですよね。
なんかね、客担かけられるみたいな施策があるんだったら、
私もそうじゃないって思うときついよな。
そう10円とかだったらね。
やっぱり薬局はその、病院とかと違ってやっぱ安いから
町財報酬が。
だからまあ結構苦しいよね。
だからなんか僕の感覚だと、
その薬剤師さんが丁寧に説明してくれたとか、
多数に説明したとかで選ぶ薬局多分変わんないんですよ。
近くの薬局行くだけだから。
だからなんかそのAIによってどの程度メリットを享受してるのかは
なんか全然わかんないなみたいな、薬局側は。
料金設定の難題と「Flex」モデルの登場
まあ今作ってる機能っていうのは要するに、
患者さんのベースの情報っていうものをもとに、
ベースを作るものだから、
例えばここからその情報を使って、
薬剤師って、
それを処方してくれた医者に対して情報提供、
要するにこういう指導とかしましたよ、
こういうことがありましたよみたいなのを、
こういう薬の副作用とかが飲み合わせちょっと良くないかもしれないですよとか、
そういう情報提供する情報提供資料みたいなのって、
これで情報提供するとその分の技術料みたいな、
料金もらえたりしたりとか、
あとは患者さんを副薬指導して、
その後帰ったりした後に、
実際に飲んだりした時に、
事後のフォローするみたいな、
帰った後のフォローするみたいなことをするんだよね。
ちゃんと飲んでるかなとか、
どんなフォローするか俺もあんまりわかんないけど、
受けたことないからそういうの。
そういうのをフォローすると、
それまたそういうちゃんとした点数が取れたりするんで、
確かそういう風に、
多分今回の機能っていうのは、
今は副薬指導にしか役立ててないけど、
そういった情報提供とか、
そういう患者のフォローアップとかにも繋げられるような機能になっているので、
この先そういうので発展していく予定ではいるって感じかな。
でもなんか、
例えば新人薬大師さんとかにとっては、
そこそこ質の自分のレベル以上の副薬指導ができるとかっていうメリットは確かにありそうですよね。
そう、たまたまそれこそ実証実験の店舗の中に、
そういったインターンの学生を招いているところがあって、
その留意事項を使ってその学生に教えるっていうのはすごく便利だったっていうのは聞いているので、
一定アカデミックな場面では割と使えるのかなっていうところがメリットとしては。
確かにAIで作ってくれれば、
その後輩指導っていうところの観点でいくと、
まあとりあえずAI使ってみてっていう感じでできる部分もありそうだから、
そういう何だろう、対患者さんのより体験を上げるっていうのも、
まあもちろん必要でしょうけど、そうじゃなく社内での教育とか、
まあ一種の福利構成じゃないけど、みたいなのにもちょっと使えそうな。
そう、とはいえリアルタイムの、
今はそこでまず2回目の実証ができたから、バッチの機能とかが全部できたから、
2回目の実証実験みたいなのをしている最中って感じで、
で、とはいえやっぱりこう一般公開する上で、
そのリアルタイムの実行って業務に耐えられないって話したじゃん。
とはいえ、あの薬局によってはリアルタイムで使う薬局も出てくるでしょ。
でもこのリアルタイムって高いのよ。
業務上、なんか耐えられねえなって言われてるのに高いのよ。
だから我々としてはどちらかって多分、使ってほしくないとは言わないけど、
こいつがいた状態だと価格設定がめっちゃ難しくて。
バッチとリアルタイムでプランが分かれてるわけじゃないって。
いや、例えばバッチと今まではリアルタイム、注意を作るやつと指導分を作るやつ。
で指導分を作るやつっていうのは10円とか15円ぐらいで多分いけるとか、
まあいくらになるかまだ分からないけどまあ安い。
でリアルタイムで実行するやつはまあそれなりに高い値段ですと。
でバッチは半額じゃん。
要するに今3つの価格が出てきたわけだよね、ここで。
これって、じゃあユーザーがじゃあこれはこの値段でポチと、これはこの値段でポチみたいな、
考えながら操作するわけないじゃん。
だからユーザーとしてあってほしいのは共通した金額。
なんかそういうAI機能は1回いくらですよっていうぐらい。
だったら使いやすいじゃん。
もしくは指導分っていうものと、まあその留意事項っていうんだけど留意事項っていうものは、
留意事項はいくら、1回いくら、バッチも含めて。
で指導分は1回いくら、みたいなにするじゃん。
すればまだ2つあるのも嫌だけど、まだまあまあわかるよっていう感じになると思うんだよね。
画面のどっかに今いくら使ってます、だからバッチだったらあと何回いける、
こっちだったらあと何回いけるみたいなの出してあげるみたいな。
そうだね。でも実際やりたいのはやっぱ共通の金額1回、AI機能1回いくらですってやりたい。
月額はもう無理そう。月額いくらは無理そう。
定額は、定額で使い放題は無理。
でも月額、例えば今のクロードみたいに月額これだけ払えばこれだけのトークン使えますよみたいな。
1日とか5時間と1週間、これだけ使ってリセットされますっていう話になると思うんだよね。
でもじゃあ逆に聞くけど、このトークンあたりこれだけ使えますって薬局に言うじゃん。
ハニアだよ。
そうっすね。
わからんって言ってなるじゃん、絶対に。だからこれをトークンっていう単位も絶対使えないわけ。
てなるとやっぱ回で使うしかなくて、
回はじゃあこの機能と紐づいてるから回いくら、この機能だったら回いくらみたいなのも覚えたくないでしょ、覚えないでしょっていう話になる。
しかも5時間制限みたいなのあったらピークでトークン食いまくって途中から使えませんとか入ってたでしょ。
そうだからそういう、我々開発者だからトークンでいくらとかって覚えるし、分かるけど。
僕は分かんないですけどね。
トークンの概念ね。
でもなんかトークンがこれだけ、こういう問題をAIとするとトークン食っちゃうんだなーとか酒どこかとかなるし。
開発者はトークンでいいんだけど、一般人にはトークンなんて通じないから。
そうっすね。
だってクロードコードとかコーデックスとか使ってない限りトークンなんて気にしないでしょ。
うーん、そうかもしれんですね。
そもそもね、ソースでAIに課金してる人がどれくらいいるんだっていう話もあるし。
そう、ブラウザ上のさ、だから1割ぐらいしかいないんでしょ、クロードコードとかそういうの使ってる人全人口というか。
1割の人数しかトークンなんて気にしてないよね。
それにトークンっていうのでやるっていうのをつけると、まあ分かんねーよなっていう話になり。
Flexとバッチモデルの比較、ローカルLLMの可能性
じゃあ点数で出してあげますか。
点数?ポイントとか?
調材何点とかの点数に合わせた桁にしてあげることによって分かるやつ。
いいよ、分かんねーだろ。
だからそれがネックで、まだ価格設定のボトルネックがあって、ほんとどうしよっかなーとか思っているんだけど、
ちょっと巧妙が指したというか。
留意事項、さっきリアルタイムで高いって言ってたやつって、さっき業務に耐えられないって言ったじゃん。
つまりリアルタイムである必要がないんだと。
その場で結局実行されないんだったら、そうする必要がないから、
じゃあそもそもリアルタイムでの作成っていうのを、生成っていうのをやめてしまえばいいじゃん。
っていうのは、またこれもちょっと違うかなって思っていて、
で、そんな中リアルタイムじゃないんだけど、標準ではないんだけど、
フレックスっていうモデルが、モデルっていうか使い方があって、標準バッチフレックスっていうモデルがあって、
フレックスってなんと半額なんです。標準の。
バッチと同じお値段で使えますと。
で、ただし何があるかって言ったら、
生成には1分から15分の幅を持たせていますと。
1分から15分?
そう。だから要するに標準はそれを即座にっていうか、そういう1分とか単位で、
ベストエフォートっていうかできるだけ早く返すという感じだけど、
フレックスはもう1分から15分。要するにこれも一緒ね。
リソースに空きがあったら15分までの、15分なのか何分だったかな、忘れた。
それ以降もあるのかな、わかんないけど、それくらいで、
それくらいの時間を見込んでもらいますよみたいな、
っていう感じの使い方をするんだけど、
性能は一緒ってことですよね?
性能は一緒のものを選んで半額になる。フレックスを選べば半額になる。
へー、そんなことあるんだ。
そういうのがあって、あ、これでいいじゃんって思った。
で、したら、まあそもそも今の状況的に、そのなんだろうな、
初号の情報だけとか、今の状態でもいいんだけど、
今はそれこそこういう業務の後、初号が届いたら、
これをポチって押してくれたら今回の初号とかが生成されますよっていう流れになってるけど、
これをそうじゃなくて、全ての薬歴、今回分の薬歴を全部入力した後に生成してくれれば、
今回の入力した薬歴も分析の対象にして、
例えばその薬歴の中にはフォローをするとか、患者さんにフォローをするとか入ってたら、
そのフォローの情報とかも抜いて、その普通のなんだろう、フォロー、
フォローアップ、この患者しないといけないですよみたいな機能にもつなげられたりとかするから、
だからむしろUXを、体験をその患者に体験自体を後に持ってきたというか、
その生成を後に持ってくることによって、時間も気にしなくていいし、
取れる情報も増えるしっていうアプローチした。
だからあんまピントきてないのが、バッチとフレックスの違いがあんまよく分かってないというか。
バッチは結局、バッチで生成対象になるものっていうのは、システムが決定論的に決めてるもので、
それって正しいか正しくないかって言ったら分からない、正直な話。
でもリアルタイムでできるものっていうのは、要するにユーザーが、
いやこれはこういうのために生成ボタンを押しときたいみたいな、
っていうユーザー独自のその薬局独自の運用かもしれないし、薬剤師独自の運用かもしれないけど、
それに則った使い方をしてくれる。
に対してバッチは別に則った対応じゃなくて、我々が決定論的に予測で決めたものだけを対象にするから、
もしかしたら生成されないって可能性もある。
バッチっていうのは、どのバッチが半額ですって言うと、
半額って言うことはAIの使い方がリアルタイムと違う使い方をしてるから半額なわけです。
でフレックスも1分から15分の待ちがあります。で半額です。
ってなった時に、どう言ったらいいんだろうな。
半額同士でどっちとも待ってもいいよっていうもの。
そうしてみた時にフレックスとバッチって。
何が違うのか。
バッチはちなみに24時間。
24時間以内に作るけど、いつ作られるか分からない。
最大24時間かかるっていう話。
でもフレックスは1分から15分じゃない?
フレックスの方が優秀そうに見えるよね、もちろん。
でもフレックスって標準をモデル、標準の使われ方をモデルにしてるんで、
要するにリクエスト、1リクエストごとに処理するみたいな。
に対してバッチっていうのは今回の予測なんでいっぱい出るわけ。
たくさんのものを一気にバンってやって、24時間以内に返してくれる。
だからAPIのリクエストのインターフェースが違う?
違う。
そういうことか。
単発のいっぱいバッチでやってるわけじゃなくて、どんと投げてる。
バッチにどんと投げて、バッチで処理してもらうっていう感じ。
それだったら理解。
でもそうなるとバッチもうちょっと安くてもいいんじゃないかなって。
でもバッチはだってさ、本来はフレックスだったら24時間かかって処理できないものも24時間以内に処理してくれる。量によっては。
ちょっと計算できないけど、今回バッチで処理したい患者が1万人いたとかなったときに、
じゃあ1万人フレックスであれやってたら終わるのかっていう話。
フレックスで直列で1万人やるのに比べて、バッチで1万人やった場合は24時間以内に終わることが保証される。
保証されてる。
なるほど、だから件数がでかい件数のメリットがバッチにはあるってことか。
だからバッチなんだ。
でもフレックスをAPI的にはこっちとしては一気に1万ボーンって。
投げてもいいんだけど、これまた今のAIの話になるんだけど、優先ってあったじゃん。リソースの優先って。
しかも1オーガニゼーションが1分間あたりにリクエストできる数っていうのが決まってる。
そうなんだ。
だからその制限に引っかかっちゃうから引っかかるし、その制限に引っかからなくても待ちになっちゃうから割と時間かかったりとか、
急に溜められて処理時代がスタートしなかったりとかっていうのもあるっぽいから、結構そのあたりでリソースの奪い合いが発生していて、
バッってやる中で、さっき1万って言ったけど、1000とか1万って言ったけど、それよりもっと少ない数でバッチの方が優位なんだと思う。
今の事情的にね。
全然わからず言うんですけど、自分たちで自前のAI用の筐体用意する方が安いんじゃなくて。
あるのかな。
全然どういうものを用意、どういうような規模のものを用意しなきゃいけないのか、何の見当もついてないけど。
値段だけで見たら、筐体との値段だけで見たら安いんじゃない?
どうなんだろう、どんくらい安いんだろう、わかんないけど、まあまあ安いと思うよ。
でも、そこに結局Geminiとかクロードとかのモデル、進化し続けるモデルを置けないじゃん。
そうなるのか。
ローカルLLMみたいな話の知見がほぼないから。
ローカルの、ああそうだね、あれは置けない、だって公開してないしOSSじゃないから。
それの廉価版というか、ちょっと落ちたバージョンをOSSに出してくれてたりするから、
それを自分たちでファインチューニング、強化学習なりして、ローカルで動かすとかできると思うけど。
そういうことなんだ。なるほど。色々と難しいですね。
でもレセコムみたいにクライアントアプリで使うんなら、今やっぱりローカルで簡単に動く?
中国製が多いけど、ローカルLLMみたいなやつと連携して何かできるといいんだろうなと思う。
それはいいっすね。
そう。
Mac導入の検討とAI料金設定の展望
そうだったらマニュアルを各PC上に置いてもらって、
うちで用意してるとやっぱりAIの料金って話を考えなきゃいけないから、
ローカルLLMにアップデートのタイミングで一緒にマニュアルのドキュメントを入れておいて、
起動の時にローカルLLMが読めるようにしておくみたいな。
そういうのも使えるけど、今メモリーとかディスクがめっちゃ高いから、PCめっちゃ高いよ今。
だって普通に今までよりもDELLのPCとか5、6万上がってるよ。
普通のスペックのが。
しんどいな。
そう。
なんかちょっと大きく脱線するんですけど、
最近ふと思ったのが、全然薬局のことを一切無視して話すんですけど、
全薬局にMacにしてもらうとかにする方がサポートコスト安いんじゃないの?って思うんですよ。
それはなんで?
そもそもまずメーカーの差がなくなるから、そこの差がなくなるっていうのと、
なんかネットで見たんですけど、パソコンの故障の問い合わせはやっぱりWindowsであることの方が多いんだ。
だからWindowsは、何だったかな、社内SEか何かの人の話だったと思うんですけど、
週に2、3回来るけどMacは年に1回みたいな。
Macは故障しないもんね。
だからそういうメーカーの差がないっていうのと故障のしにくさとかを考えた時に、薬局にMac使ってもらおうがいいんじゃない?みたいな。
確かに。
でもなんか、ユーザーからの問い合わせでWindowsコイルなんかのこと聞かれても、ぶっちゃけわかんないんですよ。
いやーわかんねーなーと思ったら調べて、今度出たらちょっとこれ聞いてもらっていいですかみたいな。
自信ないけどみたいな。
っていうのをしてるぐらいだったらMacの方がいい説みたいなのをちょっと最近考えた。
Macはね、でも使い勝手が全然違うから、そこのインターフェースの違いが大きすぎて多分Windowsユーザーは結構辛いんじゃない?
辛くなる可能性は高いだろうなって思う。
だから最近その案を後押ししてるのがMacBook Neo。
あー確かに。
だからね、無しではない気がしてる。
でもMacで動く?
まあ動かそうと思えば何かしらできるんじゃないですか?
まあビルドすればいい。
それこそビルドのコード書くなんてAIが書いてくれるから結構。
しかもね、開発者はほとんどMacだから。
確かに。
だからね、いろいろと都合がいい気がするんですよね。
ちょっとぜひ検討してください。
これからの導入薬局に対してとか。
いやーむずいやろなー。
ちょっとずつ今の薬局もMacに置き換えていってみたいな。
Macも選べるようにすれば。
だからWindowsかMacどっちか選びます。
でもMac選ぶってなったら次サポートが大変なんだよ。
まあサポートはまずキャッチアップしていく。
なるほどね。
だからMac選ぶ方がサポートちょっと月額安くなりますよ。
サポートが減るからみたいな。
プランを用意しておくみたいな。
いいじゃないですか?いいじゃないですか?
でも筐体なんで安くするの?
サポートコストは多分WindowsよりMacの方が安いだろうという仮定のもとで、
Mac選んでくれるとその店舗に対するサポートコストが軽減されるということで月額ちょっと割り引いてあげる。
それは何?サポートコストが安くなるっていうのはWindows固有の問題と補償がないからってこと?
そうそうそうそう。
ちょっとありじゃないですか?
でも大体の問い合わせって自分たちのアプリに対する問い合わせだから。
いやでもあのね、結構何だっけ、何問題だっけな。
隣のチームは一生懸命結構1年くらい前から一生懸命対応してた。
印刷?
印刷だったかな。途中でクラッシュしちゃうとか。
メモリめっちゃ使ってクラッシュしちゃうみたいなのはなんかあって。
何だっけ。
アウトオブメモリーが発生みたいな。
何だっけあそこ。
IBMじゃなくて何だっけ。
レノボか。
あれでしたっけ。
レノボの常駐アプリみたいなのが。
あーとかなんかそんなのもあるし、それと一緒だったかわかんないけどそんなのもあるしみたいな。
そんなのあるから。あれとか結構コスト、人件費的な意味でかかってるから。
確かに。
ありだと思うな。
ありか。まあまあ検討してみますよ。
お願いします。
フレックスになったので、価格もこれでバッジとフレックス一緒になったんで。
これで多分共通になるっていう夢を見れるようになったっていうのが5ヶ月経った今です。
まあ着実に前には進んでおります。
まあ難しさを戦いながら。
そんな感じです。
じゃあ終わりですかね。ありがとうございました。
ありがとうございました。
