AIエージェントの費用はモデル料金だけでなく、長い文脈、再試行、確認、失敗対応で膨らみます。FoneClawのローカルAndroid操作の考え方から、総コストを見直します。
AIエージェントの費用を考えるとき、多くの人はまずモデルの利用料金を見ます。もちろんそれは重要です。OpenAIのAPI料金ページやVertex AIの生成AI料金ページを見ると、入力、出力、モデル、処理する内容によって費用が変わることが分かります。ただし、スマホ操作を任せるAIでは、単純なチャットよりも費用の膨らみ方が複雑です。
たとえば「同僚に到着予定を送って、会議前に通知を消して、地図を開いて」と頼む場合、AIは文章を返すだけでは終われません。意図を分け、連絡先を確認し、アプリや通知の状態を見て、危険な操作がないか判断し、必要ならユーザーに確認します。この一連のやり取りは、入力と出力の量を増やします。うまく進まなければ、同じ文脈をもう一度読み、別の手順を考え、ユーザーに追加説明を求めるため、費用と時間の両方が積み上がります。
私たちがFoneClawで見ている課題は、AIエージェントの費用を「モデルに何文字送ったか」だけで考えると、実際のスマホ利用に合わないことです。Androidのタスクは、アプリ、通知、権限、画面遷移、ユーザー確認が絡みます。だからこそ、Android タスク自動化を声で始める:FoneClawで複数手順を任せる考え方で述べているように、対応済みの操作をどこまで端末側で整理できるかが、コスト設計の出発点になります。
トークンの無駄は、長い文章を生成したときだけに起きるわけではありません。スマホAIエージェントでは、画面の説明、候補の列挙、ツールの説明、確認文、失敗理由、やり直しの計画が何度も会話に入ります。ユーザーから見ると「まだ終わっていないのに、AIが状況を説明し続けている」状態です。ここがクラウド型エージェントの隠れた費用になりやすい部分です。
具体例で考えると分かりやすくなります。通知の要約を頼んだあと、「重要そうなものだけ返信候補を作って」と続ける場合、AIは通知内容、相手、前後の文脈、返信してよいかどうかを判断します。ここまでは知的な処理です。しかし、返信画面を開けない、対象アプリが分からない、権限が足りない、画面状態を誤認する、といった問題が起きると、AIは再び状況説明に戻ります。やり直しのたびに、同じ情報をもう一度読み込ませることになり、トークン使用量は増えます。
もう一つの見落としは、ユーザーの修正もコストになることです。「その人ではなく別の田中さん」「その通知ではなく上の通知」「今は送らず下書きだけ」といった補足は、AIにとって追加文脈です。私たちは、こうした補足をゼロにできるとは考えていません。むしろ、対応アクション、対象、確認のタイミングを明確にし、曖昧なままクラウド推論を続けないことが重要だと考えています。信頼と費用は別問題に見えますが、実際にはつながっています。詳しくはAIエージェントの信頼性:クラウドAIとローカルAndroid操作をどう見分けるかでも整理しています。
クラウドAIは、調査、要約、文章作成、複雑な推論に強みがあります。一方で、ユーザーのAndroid端末で起きている細かな状態を安全に変えるには、端末側の権限、アプリの状態、ユーザーの承認が必要です。ここを無視して「AIが全部やる」と言ってしまうと、費用以前に信頼できない体験になります。
たとえば、クラウド上のAIが「設定アプリを開いて通知を変更してください」と案内することはできます。しかし、そのAIが実際に端末で通知設定を開き、対象アプリを見つけ、変更前にユーザーへ確認し、完了を画面で示すには、端末側の仕組みが必要です。Androidのプライバシーと権限は、アプリが勝手に何でも操作できないように設計されています。Androidのプライバシーとセキュリティの説明が示す通り、ユーザーの許可と安全な取り扱いは前提です。
クラウドだけでスマホ操作を代替しようとすると、AIは端末の状態を推測し続けることになります。スクリーンショットを読む、画面説明を受け取る、次のボタンを推測する、失敗したら再確認する。この流れは、トークンを使うだけでなく、誤操作の不安も増やします。私たちは、クラウドの推論を否定しているわけではありません。調査や言語理解には強力です。ただし、スマホ上の対応済み操作までクラウドの会話で抱え込むと、費用もUXも重くなる場面があると見ています。
費用を下げるために大切なのは、すべてを端末だけで処理することではありません。大事なのは、クラウドで考えるべき部分と、端末側で確実に進めるべき部分を分けることです。予定の要約や文章の生成はクラウドAIが得意な場合があります。一方、対応済みのAndroid操作、たとえばアプリを開く、通知を整理する、画面上の確認を表示する、対応範囲内の設定に進むといった処理は、毎回長い推論に戻す必要がない場合があります。
この分離ができると、AIエージェントは「何をしたいか」を理解したあと、実行可能な部分を端末側の確かな手順に渡せます。ここでいう確かさは、魔法のような全アプリ制御ではありません。対応している操作、ユーザーが許可した権限、確認が必要な場面、失敗時に止まる条件が決まっていることです。たとえば「会議中は通知を静かにして、終わったら戻して」といった依頼では、時間、対象、変更内容、復帰条件を明確にできれば、毎回同じ文脈をクラウドへ送り直す必要は少なくなります。
FoneClawでは、ローカルAndroid操作をコスト削減の万能策とは言いません。対応していないアプリや、外部サービスの複雑な判断、長文の要約、最新情報の取得では、クラウドの力が必要になることがあります。ただ、端末で完了できる操作まで毎回クラウド会話に戻すのは非効率です。企業利用での評価観点は、企業向けAIエージェント セキュリティ:スマホ上で動くエージェントをどう評価するかのように、費用だけでなく権限、記録、管理方法と合わせて見る必要があります。
私たちはFoneClawを、Androidスマホ上の対応アクションを扱うAIエージェントとして設計しています。狙っているのは、AIが長く話し続ける体験ではなく、ユーザーの依頼を実際のスマホ操作に変え、必要な確認を挟み、結果を見える形で返すことです。この違いは、費用にも直結します。何度も計画を作り直すより、対応済みの操作を安定して進めたほうが、トークンとユーザー時間の両方を減らしやすいからです。
たとえば「母に遅れると送って、地図を開いて、自宅までのルートを見せて」と言われた場合、AIは連絡先、メッセージ内容、送信確認、地図アプリへの移動を扱います。ここで重要なのは、送信のような敏感な操作を勝手に完了しないことです。ユーザーが確認できる文面を出し、送信前に止まり、完了後に結果が分かるようにする。この設計は安全のためだけではありません。誤送信ややり直しが減れば、再説明と再推論も減ります。
また、FoneClawはすべてのアプリを自由に操作できるとは言いません。私たちは、対応アクション、Androidの権限、ユーザーの承認を前提にしています。できないことを無理に推測し続けるより、「ここから先は確認が必要」「この操作は未対応」「この画面ではユーザー操作が必要」と明確に返すほうが、結果的に安く、分かりやすく、安全です。AIエージェントのコストを下げるには、賢いモデルを選ぶだけでなく、止まるべきところで止まる設計が必要です。
AIエージェントの費用を見積もるなら、モデルの単価だけを表にしても足りません。特にスマホ操作では、実行できなかったときの再試行、ユーザーの確認時間、サポート問い合わせ、誤操作の修正まで含めて考える必要があります。安いモデルでも、同じ失敗を何度も繰り返すなら総コストは下がりません。高性能なモデルでも、端末側で操作できないことを長く説明するだけなら、ユーザー価値は限定的です。
実務では、次の観点で見ると判断しやすくなります。
私たちの結論は単純です。AIエージェントの費用は、トークン単価だけではなく、失敗しにくい操作設計で決まります。クラウドAIは重要ですが、スマホで完了すべき対応済みタスクまで毎回長い会話に戻す必要はありません。FoneClawでは、ユーザーが声で頼み、必要なところで確認し、Android上の対応操作を確実に進めることを重視しています。コスト削減とは、AIを小さく見せることではなく、AIが考えるべき場面と、端末で進めるべき場面をきちんと分けることです。