1000 TPS LLMとスマートフォンAIエージェント：高速推論が変えること

速いモデルだけではスマホエージェントは完成しない

1000 TPS LLMとスマートフォンAIエージェントの話で、最初に分けたいのは「返答が速いこと」と「スマホ上の作業が終わること」です。1000 tokens/s級の高速推論は、待ち時間を大きく下げます。ユーザーが依頼し、モデルが意図を読み、次の手順を出すまでの時間が短くなるからです。しかし、メッセージを準備する、通知を整理する、経路を確認する、設定画面に進む、送信前に確認する、といったAndroid操作には、モデルの出力とは別の仕組みが必要です。

電話エージェントの体験では、数秒の遅れが積み重なります。たとえば「明日の予定を確認して、移動時間を見て、必要なら相手に返信案を作って」と頼む場合、モデルは一度答えて終わりではありません。予定を読む、候補を考える、地図や通知の状況を確認する、下書きを作る、ユーザーに見せる。この一連の流れでは、推論が速いほどテンポはよくなります。ただし、どこまで自動で進めてよいか、どこでユーザー確認を挟むかは別問題です。

FoneClawでは、私たちはモデル速度を重要な上流の能力として見ていますが、それだけでプロダクトが完成するとは考えていません。高速推論は、スマホエージェントの計画や判断を支える力になります。一方で、実際の端末上では、対応済み操作、権限、画面上の確認、失敗時の戻し方が必要です。より広い基礎はスマートフォンAIエージェントの文脈でも扱われますが、このページでは1000 TPS級の速度が何を変え、何を変えないのかに絞ります。

MiMo UltraSpeedが示したこと、まだ示していないこと

MiMo V2.5 Pro UltraSpeedは、1000 TPS級の高速推論がスマートフォンAIエージェントの議論に入ってきた分かりやすいシグナルです。2026年7月15日に確認したXiaomiのMiMo公式ページでは、MiMo-V2.5-Pro-UltraSpeedはMiMo-V2.5-ProのUltraSpeed体験モードとして説明されています。Xiaomiは、MiMo-V2.5-Proを1T級の旗艦モデルとし、UltraSpeedでは最高推論速度が1000 tokens/sを突破したと説明しています。

同じ公式ページでは、テキスト入力と出力、tool calling、ストリーミング、キャッシュ対応が示され、出力TPSについてMiMo-V2.5-Proが50から100程度、UltraSpeedが500から1000程度と説明されています。さらに、定量取引、リアルタイムリスク管理、科学研究、リアルタイムのコーディング支援といった利用場面が挙げられています。これは、高速推論が単なるチャットの快適さだけでなく、短い判断を何度も繰り返す作業に向いていることを示す主張です。

ただし、ここで重要なのは、これはXiaomiによる公式主張であり、独立したベンチマーク証明として扱うべきではないという点です。私たちは、FoneClawがMiMoを使っているとは言いません。すべてのphone agentが1000 TPSに到達するとも言いません。モデル選びやモデル系統の整理はMiMo V2.5 Pro UltraSpeedを含む別の視点で扱えますが、このページの焦点は、速度のシグナルがスマホ操作の設計にどんな意味を持つかです。

長いタスクでは、待ち時間が積み上がる

高速推論の価値が最も分かりやすいのは、長いタスクです。一問一答のチャットなら、少し待てば済むこともあります。しかし、電話エージェントは、計画して、行動候補を出し、結果を確認し、次の行動に進むという繰り返しで動きます。この小さな待ち時間が何度も積み上がると、ユーザーは「自分で操作した方が早い」と感じます。

たとえば、朝の通知整理を考えてみます。未読メッセージを見て、急ぎのものを選び、返信案を作り、カレンダーと照合し、必要ならリマインダーを追加する。あるいは、外出前に予定を確認し、目的地までの移動時間を見て、相手に到着予定を送る。どちらも一つの巨大な処理ではなく、小さな判断と確認の連続です。ここでモデルの出力が速いと、ユーザーは流れを失いにくくなります。

一方で、速度が上がっても、正しい確認点がなければ安心は増えません。返信案を高速に作れても、送信先が間違っていれば問題です。経路候補をすぐ出せても、現在地や目的地の扱いに権限が必要なら、端末側の確認が欠かせません。長いタスクでは、速さは信頼を支える条件の一つですが、信頼そのものではありません。高速LLMとスマホ操作をつなぐには、速い推論と安全な実行の両方が必要です。

高速モデルと慎重なモデルを分ける発想

1000 tokens/s級の速度が現実味を帯びると、エージェント設計では「すべてを一つの重いモデルで処理する」以外の考え方が重要になります。軽い確認や短い会話は高速モデルで進め、影響が大きい判断や曖昧な依頼は、より慎重なモデルや追加確認に回す。こうした役割分担は、リアルタイム会話や長いタスク実行で特に効果があります。

たとえば、ユーザーが「この予定に間に合うようにして」と言った場合、最初の意図理解や候補作成は速く進めたいところです。候補の予定、移動時間、通知の必要性をすばやく並べることで、会話のテンポを保てます。一方で、誰かに送る文面、公開される内容、削除や設定変更のような操作では、速さより確実性が必要になります。ここで追加確認を挟む設計が、ユーザーにとって自然です。

この発想は、特定のFoneClaw内部構成を説明するものではありません。私たちは未公開のアーキテクチャを主張しません。重要なのは、エージェントの質はTPSだけで決まらないということです。高速モデル、慎重な判断、端末上の確認、ユーザーに見える結果。これらをどう組み合わせるかが、スマートフォンAIエージェントの体験を左右します。

Android操作には、推論とは別の実行設計が必要

モデルは「何をすべきか」を考えるのに強くなっています。しかし、スマホは考えただけでは動きません。メッセージアプリ、カレンダー、地図、設定、通知、写真、位置情報などには、それぞれ権限と画面上の制約があります。Android操作を実際に進めるには、モデルの出力を端末上の対応済みアクションへ変換する仕組みが必要です。

ここで重要なのが、権限、確認、対応範囲、フォールバックです。権限がなければ、エージェントは勝手に情報へ触れてはいけません。送信や削除、公開、設定変更のような影響が大きい操作では、ユーザーが内容を見て確認できる必要があります。対応していないアプリや画面では、無理に進むのではなく、止まる、説明する、手動操作へ戻すことが必要です。高速推論があっても、この部分は省略できません。

FoneClawでは、私たちはこのスマホ側の実行設計を自分たちの役割として見ています。電話そのものがAIエージェントの実行場所になっていく背景はAndroid操作の文脈でも整理できますが、私たちの焦点は、対応済みAndroidアクションを見える形で進めることです。速いモデルは上流の判断を強くします。しかし、端末上で安全に完了させるには、別の設計が必要です。

FoneClawでは高速化の教訓をどう見るか

FoneClawでは、私たちはMiMo V2.5 Pro UltraSpeedのような高速推論の流れを、スマホエージェントにとって前向きなシグナルとして見ています。待ち時間が短くなれば、ユーザーとの会話は途切れにくくなり、長いタスクでも確認と修正を入れやすくなります。計画、候補生成、追加質問、結果確認のテンポが上がることは、日常のAndroid操作にとって大きな意味があります。

この変化は、FoneClawの実際の体験改善にもつながっています。FoneClawはMiMo V2.5 Pro UltraSpeedの内部テストアクセスを取得しており、Xiaomiがピークで1000 TPS超と説明する1兆パラメータ級モデルを使って、FoneClawの操作体験を改善しています。スマホエージェントにとって重要なのは抽象的な速度ではなく、意図理解、手順の修正、対応済みスマホ操作の反応をより速くすることです。

ただし、私たちはFoneClawがMiMoを使っているとは言いません。1000 TPSを自分たちの性能として主張することもしません。私たちの立場は、高速モデルが上流の推論を強くする一方で、スマホ操作を実際に安全に進めるには、対応済みアクション、権限、確認、フォールバックが必要だというものです。FoneClawでは、そこをAndroid phone-action assistantとして担うことに集中しています。

実用上の結論は明確です。1000 TPS LLMは、スマートフォンAIエージェントの会話と判断を速くできます。長いタスクの待ち時間を減らし、plan-act-checkの繰り返しを滑らかにできます。しかし、速度だけでスマホが安全に動くわけではありません。モデルの速さを、ユーザーが見える形のAndroid操作へつなぐこと。FoneClawでは、その変換部分を、私たちの製品設計の中心に置いています。