Dots・Grok Bot・Museの使い分けと、ローカルLLM・小型モデルの使いどころ

「寄り道AI砂場」は、IT企業でリサーチエンジニアをしている戸田さんが、AI関連の論文やライブラリを実際に試した結果を共有する番組です。今回は番組初のゲスト回になりました。

ゲストのてりすけさんは、戸田さんとは高校の吹奏楽部で出会った仲です。最近、展示会で偶然再会したことがきっかけで、今回の出演につながりました。現在は福岡でエンジニアをしながら、会社を経営しています。

てりすけさんの経歴は少し変わっています。高校時代はトランペット奏者で、未経験からエンジニアになったといいます。登壇の自己紹介でも、その経歴をスライドの1枚目で説明しているそうです。

てりすけさんによると、未経験のころは仕事がなかなか取れず、ひたすら登壇を重ねていたといいます。戸田さんはこの再会を「何かの運命」と感じ、ポッドキャストに誘ったと話しています。

戸田さんが最初に持ち出した話題は、いわゆる「エージェント2.0」と呼べるAIエージェントです。OpenAIのDots、Grok Bot、MetaのMuseに加えて、ClaudeからもDuetが出ていると紹介しています。戸田さんは、Duetは日本ではまだ使えないかもしれないとも話しています。

戸田さんはDuet以外をひととおり試しており、メインで使っているのはGrok Botです。てりすけさんも同じ考えで、Grok Botを使うためにCursorのプランを最上位まで上げたといいます。

一方の戸田さんは、Grok Botを使える最低限のプランで、月3000円ちょっとのものを契約しています。てりすけさんからXの青バッジにも付いてくると聞き、戸田さんは自分もプランを上げようか考え始めているそうです。

戸田さんがGrok Botに唯一感じている不満は、AIの側から働きかけてくる力の弱さです。この点ではDotsのほうが優れていると、戸田さんは具体的な体験を挙げて説明しています。

戸田さんの会社では、隔週の持ち回りで勉強会を開いています。ある日の前日、自分の担当回だと気づいていなかった戸田さんに、Dotsが「明日あなたの担当ですよ」とメンションを送ってきたといいます。

戸田さんの見立てでは、Dotsは勉強会の予定だけでなく、連携したNotionページの中身まで確認していました。担当者の欄に戸田さんの名前があるのに、資料が空のままだと判断したうえで、気を利かせて知らせてくれたと考えられます。

ただし戸田さんは、Dotsには「諦めがち」な面もあると感じています。何かを頼んでも「ここで止まってしまいました。どうしましょう」と返してくることが多いそうです。

それに比べて、Grok Botは頼んだ作業を最後までやりきってくれる印象だといいます。戸田さんの評価では、Museはその中間です。そのため、普段の作業は基本的にGrok Botに任せています。

てりすけさんはDotsとGrok Botをかなり使い込んだうえで、ChatGPTのCodexのプランを下げることにしました。その分を、Grok Botを動かすCursorのほうに回しています。

てりすけさんがGrok Botを選ぶ理由は、役割ごとにボットを分けられる点にあります。Dotsは1体のエージェントがすべてのコンテキストを抱えるため、タスクが増えると前の話を忘れやすいと感じているそうです。

てりすけさんの日々の業務は、会計ソフトのページや契約のサインを確認しながら、Gmailにも対応し、実装の確認もするというものです。このように作業が多岐にわたると、1体のエージェントでは手に負えないといいます。てりすけさんは、Googleドライブの認証が知らないうちに外れて作業が消えていた経験も挙げています。

戸田さんは、てりすけさんの話にうなずきつつ、自分の使い方を説明しています。プログラミングでは、ターミナルの画面を分割して複数のエージェントを並べる使い方に、結局戻ってきたそうです。一方のてりすけさんは、ターミナルを見る時間があまりないといいます。そのためGrok Botに情報を集めさせ、実装はClaude Codeのデスクトップ版で確認し、必要なときだけCursorを開くという流れを組んでいます。

2人の話をまとめると、細かいところまで気づいて知らせるリマインダーとしては、Dotsのほうが完成度は高いという見方です。ただ、生活全般を任せる秘書のような使い方では、1体のエージェントだとコンテキストが混ざりすぎてしまいます。

戸田さんはこの点を、AIの都合ではなく人間の側の問題として捉えています。ボットが話題ごとに分かれていると、使う自分が混乱しないことに価値があるという考えです。

てりすけさんは、Grok Botの未読表示も便利だと話しています。スマートグラスの作業がBluetoothの切断で止まっていたことに、青い印を見て気づけたそうです。そのうえで、Museも触ったうえで「Grok Botが覇権を取りそう」と見ています。

Museについて、てりすけさんは無料である点を評価しています。学生が最初に触るにはちょうどいいかもしれないという見方です。戸田さんは、アプリを横に開いて1つの画面で作業を完結させようとするUIの工夫に好感を持っています。それでも、Grok Botの出来が良すぎるため、Museは「悪くないけど良くもない」という印象だといいます。

戸田さんは最近、英会話を始めたそうです。AIが翻訳してくれる時代に英語はいらないと思っていたものの、子どもが自分から英会話に通いたいと言い出したことに触発されたといいます。

戸田さんが使っているのはDMM英会話です。朝や昼休み、仕事終わりなど空いた時間に受けるため、毎回講師が変わります。そのため、前回どのフレーズを忘れていたかといった進捗を、講師の側では管理しきれません。

戸田さんは以前、この学習管理をCodexのプロジェクトでAIに任せていました。現在は、Grok Botの中に英会話コーチ専用のボットを置いています。

てりすけさんも、専門ごとにエージェントを分けるべきだと考えています。人間でもコンテキストが混ざるのだから、AIなら収拾がつかなくなる、というのがてりすけさんの見方です。

話題はGeminiへ移ります。戸田さんは、Geminiの新モデルが出るたびにベンチマークでは他を引き離しているのに、実際に使うと期待外れだと感じることが多いと話しています。

戸田さんにとってGoogleは、AIの道に入るきっかけをくれた会社でもあります。2016年ごろ、AlphaGoがイ・セドル棋士に勝ったことを受けて、前職の会社でAI部署が新設されました。戸田さんはそこに手を挙げて異動したといいます。

ただ、戸田さんはGeminiを使っていないわけではありません。コーディングエージェントではあまり使わない一方で、業務プロセスを最適化するワークフローを自分で組み、LLMのAPIを呼び出す場面ではよく使っているそうです。

戸田さんの例として、以前作った仕組みがあります。オンライン会議にbotが参加して録画し、書き起こしと要約を作ってSlackに通知するものです。この仕組みでもGeminiを使っていたといいます。

てりすけさんは、最近の仕事でGoogle CloudのCX Agentを触った経験を話しています。チャットボット構築用のDialogflowを発展させたもので、てりすけさんはAWSのコールセンター構築サービスへの対抗だと見ています。

てりすけさんが驚いたのは、CX AgentのUIが告知もなく昨日と今日でまったく違っていたことです。気になる設定ボタンが、画面サイズを変えても表示されなかったこともあったそうです。エンタープライズ向けの製品なのに、と首をかしげています。

てりすけさんはこの経験から、GoogleはAI単体で売るのではなく、ワークフローの一部として組み合わせた売り方を高速で探っているのではないかと推測しています。戸田さんは、Google Workspaceとセットにする狙いかもしれないと応じています。

MetaとMuseについても、2人は推測を交わしています。戸田さんによると、MetaはLlamaでローカルLLMの流れをつくったものの、Llama 3のころから迷走していたそうです。それでも、Museで巻き返してきた印象があるといいます。

てりすけさんは、Metaがクローズドな最先端モデル開発を諦め、オープンソースで知見を集めて自社製品に生かす方向ではないかと見ています。戸田さんも、MetaはSNS広告で稼ぐ会社なので、サブスクで稼ぐ必要がないのかもしれないと話しています。

てりすけさんは、GoogleがGrok Botのように役割ごとにボットをつなぐ形を取れば非常に強いと見ています。そうなれば、Grok Botへの課金をやめてGeminiに乗り換えるとまで話しています。

戸田さんがGrok Botで特に評価しているのは、GrokのX検索の力です。毎朝定期実行のワークフローを組み、興味のありそうな話題を集めさせると、8〜10個ほどの記事が届くといいます。

戸田さんはこれまで、AIのおすすめ情報はあまり信用していなかったそうです。Grok Botの精度が高い理由については、情報源のXが良いのか、Grokのモデルが強いのかはわからないと話しています。

てりすけさんは、この情報収集をさらに実装までつなげています。テーマはXで盛り上がっているローカルLLMです。てりすけさんの手元には、メモリ128GBのEVO-X2が3台ほどとDGX Sparkが1台あります。これらにまたがって推論を分散させ、量子化せずに高速でトークンを出せないかを研究しているそうです。

てりすけさんが狙っているのは、Transformerの同じ層を、アーキテクチャの違う複数のマシンに分けて並列計算させる方法です。層ごとに別のマシンへ割り振る例や、同じPCの中で複数のGPUに分ける例はあっても、まったく違うノードに同じ層を分けるという発想はなかったといいます。

戸田さんは、Xは「オワコン」と言われながらも、やはり技術者が発信している場所だと話しています。そこを情報源にしてエージェントに試行錯誤させるのは、とても良さそうだと評価しています。

戸田さんが次に紹介したのは、Liquid AIのLFM3です。Liquid AIは、1B以下から2B程度の小規模言語モデル（SLM）を出している企業です。

戸田さんによると、LFMはTransformerだけでなくCNNなども組み合わせた特殊なアーキテクチャを持っています。小さくて速いのに優秀なため、戸田さんはよく使っているそうです。ライセンスは独特で、一定の金額以下なら無料、それを超えるとエンタープライズ契約が必要だといいます。

戸田さんは、日本語と英語で学習したLFM2のモデルを使い、ローカルで動くDeepLのような翻訳ツールを作りました。新幹線の中で通信が途切れても論文を翻訳できるようにするためです。新しいLFM3はメジャーアップデートで多言語に対応し、画像と音声を同時に扱える「Omni」も出ています。

てりすけさんが疑問を投げかけたのは、Qwenなどで使われるMixture of ExpertsMixture of Experts ── 複数の専門家ネットワークを持ち、入力ごとに一部だけを動かす仕組み。モデル全体は大きくても、1回の計算で使うパラメーターは少なく済みますとの違いです。

戸田さんの答えは、モデルを載せるための容量の違いでした。Mixture of Expertsは、動かす部分は小さくても、モデル全体を載せるだけの容量が必要になります。

戸田さんは、LFMはそうではなく、純粋に小さいモデルとして出しているのではないかと見ています。てりすけさんが確かめると、パラメーター数は1.7Bでした。2人は、スマホやロボットに載せる用途がありえそうだと話しています。

戸田さんのローカルLLMは、ほぼ趣味として取り組んでいるものです。強いモデルを大きめの環境で動かすてりすけさんとは違い、MacBookの上で気軽に動かせるモデルを中心に試しています。

戸田さんのお気に入りは、Qwenの27Bモデルや、QwenをもとにしたOrnisです。特定のサイトを10個ほど登録して巡回させ、要約して表示するRSSリーダーのような仕組みを作り、そこでOrnisを使っているそうです。

一方のてりすけさんは、仕事ではセキュリティ上の理由でローカルLLMを使いたいという案件を扱っています。業務で使う場合は、QwenやDeepSeekなど大きめのモデルを1つ置き、定期的に巡回させるのが現状のベストプラクティスだと考えています。

てりすけさんは、リアルタイム処理を重視するLFM3と、その場で瞬時に判断するタイプのモデルとの使い分けを戸田さんに尋ねています。2人が「Gem」と呼んで話しているモデル（Gem）がその例です。

戸田さんの答えは、出力が離散的か連続的かで分ける、というものです。判断を担うモデルについては、「BERTと同じ」という意見には賛成できないと話しています。ゼロショットの分類器として高い精度を出せたことに価値がある、というのが戸田さんの見方です。

その一方で、会議の要約のように自然な文章を出す必要がある作業は、判断を担うモデルではこなせません。そのため、文章を出す作業にはいまもLLMが必要だというのが戸田さんの考えです。サイトを巡回して要約する作業も、古典的な抽出要約で代用するより、全文を読ませて要約させるほうが自然だと話しています。

小型モデルは今後増えるのかという問いに対しては、戸田さんは中国勢がこの領域に参入するイメージは持てないと話しています。DeepSeekやQwenはテクニカルレポートを出してTransformerの改良を進め、GPTやClaudeと最先端で競っているため、モデルを小さくしている場合ではないという見方です。

小型モデルの代表例として戸田さんが挙げたのは、GoogleのGemmaです。てりすけさんも、フィジカルAIやロボティクスの仕事でGemmaをよく使うといいます。戸田さんは、最先端のモデルが進めば下位のモデルも自然とレベルが上がるので、間接的には中国勢も関わっているのかもしれないと話しています。

最後の話題は、てりすけさんが訪れた深圳のロボット企業です。てりすけさんは、ロボットのマラソンやカンフーの映像を見て、介護に使えるのではないかと期待していたそうです。そこで、業界上位の会社を見学しました（社名は伏せられています）。

見学先では、かっこいいロボットが格闘技の技を披露していました。ところが、案内役の人の手にはラジコンのような操作機が握られていたといいます。

てりすけさんが若手社員に英語で聞いたところ、格闘技のデモは別室で人間がリングのような装置を付けて動き、その動きをロボットに再現させていたそうです。

指が5本ではなく3本だったことにも、てりすけさんは落胆しています。理由を尋ねると、5本にすると価格が倍近くになるからだという答えでした。人間と同じ道具を使えることがヒューマノイドの利点のはずなのに、とてりすけさんは話しています。

こうした経験から、てりすけさんは中国のロボティクスは今「バブル」だと見ています。AIが使われていたのは、立ったままバランスを保つ制御の部分でした。こうした制御なら大きなモデルは必要なく、フィジカルAIは小型モデルに収斂するのではないかというのが、てりすけさんの考えです。

戸田さんは、遠隔操作でも介護ロボットには意味があると考えています。人が施設を回ると移動に時間がかかりますが、各施設にロボットを置けば状況は変わります。

戸田さんの考えでは、遠隔会議と同じように施設を切り替えれば、移動時間がなくなります。てりすけさんも同意しつつ、自動運転と同じでインフラが整っていないことが課題だと指摘しています。戸田さんは、インフラが整うのが先か、ロボットが賢くなるのが先か、と話しています。

てりすけさんは余談として、見学先のグッズショップで買った折りたたみ傘がAmazonベーシックより安くて出来が良かったと笑います。キャラクターショップのような売り方にも、バブル感を感じたそうです。

収録は無料通話の残り時間ぎりぎりで終わりました。戸田さんは、毎週5人ほどが聴く番組なので、てりすけさんのリスナーも加わって10人になればうれしいと冗談を交えています。今後も定期的に一緒に収録したいと話して、この回を締めくくりました。

まとめ

この回では、AIエージェントの使い分けからローカルLLM、ロボットまで、2人のエンジニアが自分で試した実感をもとに語り合いました。共通しているのは、ベンチマークやデモより、実際に使ってわかる使い心地を重く見る姿勢です。

• Dotsは先回りの気配りに優れる一方、タスクの途中で止まりがち。Grok Botは役割ごとにボットを分けられ、コンテキストが混ざりにくい
• 英会話コーチや毎朝の情報収集など、用途ごとに専用ボットを置く使い方が紹介された
• Grok Botで集めた情報をCursor Agentで試す流れで、ローカルLLMの分散推論を実験している
• 分類のような判断は判断を担うモデル、文章を出す作業はLLMという使い分けを、戸田さんは提案している
• 深圳のロボット見学から、デモの見栄えと実用性の差や、遠隔操作の介護ロボットという可能性が話された