Android AIエージェントのタスクキュー：複数会話、承認、復旧を安全に扱う方法

複数会話には本物のタスクキューが必要になる

Android AIエージェントのタスクキューは、チャット履歴を上から並べるためのリストではありません。電話上で実行される可能性のある作業を、どの会話から始まり、どの対象に向かい、どこで止まり、どの承認を待ち、どの条件で再開するかまで管理する仕組みです。私たちがFoneClawを作る中で最初に見えた問題は、複数の会話が開けても、電話側のタスク状態が混ざると実行が危うくなるということでした。

たとえば、一つ目の会話で「会議前にDNDを確認して」と頼み、二つ目の会話で「この画面を見て返信文を考えて」と頼む場面を考えます。どちらも自然な依頼ですが、スマホ側では状態が違います。DND確認は設定状態と承認が関わり、返信文は現在画面と宛先確認が関わります。ここで会話の文脈だけを共有してしまうと、承認対象や操作対象がずれます。

タスクキューが担うのは、会話を独立させながら、電話上の操作を順序よく進めることです。あるタスクは権限待ちになり、別のタスクは下書き待ちになり、さらに別のタスクはユーザーの確認を待つことがあります。待機は完了でも失敗でも承認でもありません。タスクの状態を見える形で分けるほど、ユーザーは今どの作業を任せているのかを理解しやすくなります。

実行中、待機中、承認待ち、権限待ち、停止、完了

複数会話AIエージェントをAndroidで使うなら、状態名はユーザーが見ても分かる粒度にする必要があります。内部の処理がどれほど複雑でも、ユーザーが知りたいのは「今動いているのか」「自分の判断を待っているのか」「権限が足りないのか」「止めたのか」「終わったのか」です。FoneClawでは、この見え方を電話上の安心感に直結するものとして扱っています。

この状態モデルがあると、一つのタスクが待機している間も、別の会話で調査や下書きを進められます。重要なのは、待機中のタスクが電話側の実行権を握り続けないことです。たとえば権限待ちのDNDタスクがある間に、現在画面について質問する会話は使えます。ただし、その質問の結果がDNDタスクの承認として使われることはありません。

複数手順の自動化そのものを作る場合は、キュー状態とは別にWorkflow設計も必要になります。手順の組み立てを深く知りたい読者には、Android タスク自動化を声で始める：FoneClawで複数手順を任せる考え方が役立ちます。このページでは、保存された手順よりも、複数会話の実行状態をどう分離するかに集中します。

会話の識別子とタスク分離

セッション単位の承認を実現するには、まず会話とタスクを識別できる必要があります。会話には、ユーザーの依頼、表示していた画面、参照した情報、候補として出した操作、待っている承認、実行結果が結びつきます。これらが一つの会話から別の会話へにじむと、ユーザーは「どの依頼に対する確認なのか」を失います。

タスク分離で守るべきものは六つあります。第一に、元の依頼です。第二に、操作対象です。第三に、画面やアプリの文脈です。第四に、使うToolや権限の状態です。第五に、承認や拒否の履歴です。第六に、結果と復旧先です。モデルの一時的な文脈ウィンドウだけでは、これらを電話側の状態として持ち続けるには足りません。Android上のタスクには、再開時にも参照できる耐久的な識別子が必要です。

たとえば「この画面を添付して説明して」と頼んだ会話と、「会議モードにして」と頼んだ会話があるとします。前者は画面内容を読むタスクで、後者は設定状態と承認を扱うタスクです。ユーザーが会話を切り替えた時、見える文脈も切り替わるべきです。説明の会話に戻れば添付した画面の話に戻り、会議モードの会話に戻ればDNDや音量の状態に戻る。この分離があると、複数のAIエージェント会話を同時に持っても、電話側の操作が混ざりにくくなります。

アイデンティティ、権限、監査ログをさらに深く扱う場合は、AIエージェントのアイデンティティ、権限、監査ログ：ツール単位で安全に実行する設計で、実行単位ごとの記録と責任を整理しています。

セッション単位の承認を一つの操作に結びつける

承認は、単なる「はい」ボタンではありません。Androidエージェントの並行処理では、承認がどの会話、どのタスク、どの対象、どの操作に効くのかを明確にする必要があります。ユーザーが会話を切り替えたあとに承認する場合でも、その承認は元のタスクだけに結びついていなければなりません。

承認カードに最低限必要なのは、タスク名、発生元の会話、対象アプリまたは設定、提案された操作、実行後の影響、再確認が必要な条件です。たとえば「DNDをオンにする」承認と、「この相手に下書きを送る」承認は、見た目が似ていても意味が違います。待機、拒否、あとで確認、停止の選択も、そのタスクだけに作用するべきです。

この仕組みがあると、承認UIをむやみに増やさずに、実行の安全性を上げられます。ユーザーは毎回長い説明を読まなくても、今承認しようとしている操作の対象を確認できます。承認カードや信頼度、理由、タスク状態の見せ方を詳しく知りたい場合は、AIエージェント承認UI設計：提案、信頼度、理由、タスク状態をスマホでどう見せるかで、UI側の設計を掘り下げています。

並列Agentチームとスマホのタスクキューの違い

複数エージェントの並列処理と、Androidスマホのタスクキューは似ているようで役割が違います。MiniMaxはMiniMax Agent Teamの発表で、leader、worker、verifierのような役割を持つ長時間タスク向けのAgent構成を説明しています。このような仕組みは、調査、コード、文書、分析のような知識作業を分担する時に向いています。途中状態を保持し、人間が介入し、再開できる作業ライフサイクルが重視されます。

OPPOも、Google CloudとのAIOS方向性の中で、Agent-to-Agentの相互運用、デバイスとクラウドの協調、記憶、プライバシーを含む次世代AIOSの方向を説明しています。さらに、OPPO Mente LabのX-OmniClawリポジトリでは、複数セッションの並行性、セッションごとのAgentループ、分離された実行環境、停止の連鎖が設計信号として見えます。これらは、業界が「複数の作業をどう分けて動かすか」に向かっていることを示しています。

一方で、スマホ上の実行は、研究Agentを並列に増やすだけでは扱えません。電話には一つの画面、一つの現在状態、一つの入力先、権限ダイアログ、通知、Bluetooth、DND、アプリ切り替えがあります。調査Agentが同時に走れても、送信、削除、設定変更、共有のような電話側の外部影響は、順序、確認、停止、復旧が必要です。Microsoftのワークフロー志向のマルチAgent設計でも、オーケストレーション、Agent、状態、プロセス制御を分けて考えます。FoneClawでは、この考え方をAndroid上の実行に引き寄せ、並列チームではなく、電話タスクの状態と順序を管理する方向で実用化しています。

停止、再開、権限回復、古い状態の再確認

タスクキューの価値は、順番に並べることだけではありません。止まった作業を、元の意図と現在の条件を照らし合わせて戻せることにあります。Androidでは、タスクが途中で止まる理由が多くあります。権限が足りない、アプリが更新された、画面が変わった、ネットワークが切れた、ユーザーが別の会話へ移った、承認を保留した、手動でアプリを操作した。これらを同じ「失敗」として扱うと、復旧が雑になります。

たとえば、会議準備タスクがDND権限待ちになったとします。その間にユーザーは別の会話で「今の画面を説明して」と頼めます。あとで会議準備に戻る時、FoneClawのような電話エージェントは、元のタスク、必要な権限、現在のDND状態、画面の変化、ユーザーがまだ同じ目的を持っているかを確認します。待機していたからといって、外部影響のある操作をそのまま進める設計にはしません。再開前に状態を読み直し、必要なら短く確認します。

古い状態のチェックも重要です。5分前の画面、10分前の通知、さっき選んだ相手、前のネットワーク状態は、今のスマホでは変わっている可能性があります。タスク分離ができていると、古くなった情報を「どのタスクのどの段階の情報か」として扱えます。そのうえで、再プレビュー、再確認、破棄、手動継続を選べます。

この復旧設計は、スマホをAIエージェントの監督画面として見る考え方にもつながります。より広いコントロールセンターの視点は、スマホ AI エージェント コントロールは、承認と可視化が中心になるで扱っています。

現在のFoneClawが複数会話タスクを運ぶ仕組み

現在のFoneClawは、この記事で扱う現時点までの最新情報にもとづく基準です。導入や現在の情報確認はFoneClawのダウンロードから進められます。この基準では、複数会話管理、厳格な会話横断タスクキュー、独立した実行中・待機中状態、セッション単位の承認、タスク分離、権限回復を土台にし、動かせるフローティングアシスタント、意図して行う現在画面の添付、Homeとフローティングアシスタントの間のタスク継続を加えています。

私たちがこの方向へ進めた理由は、Androidの作業が一つのチャットで終わらないからです。ユーザーはホームで依頼し、別のアプリへ移り、フローティングアシスタントで続け、権限が必要になれば設定を確認し、また元のタスクへ戻ります。ここで会話とタスクが分離されていれば、FoneClawは「どの依頼の続きか」「何を待っているか」「どの承認が必要か」を保ったまま、電話側の作業を進められます。

現実的な例を挙げます。朝、ユーザーは一つ目の会話で「今日の会議前に通知を整えて」と頼みます。FoneClawはDNDや音量など対応済みの状態を確認し、必要な承認を表示します。その後、ユーザーは別の会話で「今表示している画面を見て要点をまとめて」と頼みます。現在画面の添付は、その会話に結びつきます。あとで会議準備に戻ると、FoneClawは元のタスクの状態、承認、権限、現在の電話状態を照合して再開します。

FoneClawの対応済みAndroid能力は、FoneClawの機能一覧で100+ built-in toolsとして確認できます。私たちは、この能力を同時にばらまくのではなく、タスクごとの状態、承認、停止、復旧に結びつけて扱います。複数会話AIエージェントの使いやすさは、開けるチャット数よりも、どのタスクが今どの状態にあるかをユーザーが見失わないことから生まれます。

Androidエージェントのタスクキュー評価チェックリスト

最後に、Androidエージェントの並行処理を評価するための低リスクなテストを用意します。まず二つの会話を作ります。一つ目では、戻しやすい設定確認を頼みます。二つ目では、現在画面の説明や短いメモ作成を頼みます。次に、一つ目のタスクを承認待ちまたは権限待ちにして、二つ目の会話へ切り替えます。ここで、文脈、承認、対象、結果が混ざらないかを見ます。

• タスクごとに元の会話と依頼が見えるか。
• 実行中、待機中、承認待ち、権限待ち、停止、完了が区別されているか。
• 承認が特定のタスク、対象、操作に結びついているか。
• 別会話へ切り替えても、待機タスクが勝手に進まないか。
• 再開時に現在の画面、権限、対象、効果を読み直すか。
• 停止後に、再開、破棄、手動継続の選択肢が分かるか。

評価で見るべきなのは、開いているチャット数ではありません。見えるタスク識別、状態の明確さ、承認の結びつき、操作の順序、復旧の自然さです。低リスクな検証でこの五つがそろえば、次に複数手順の電話ワークフローへ広げる判断がしやすくなります。