スマホAIエージェントの失敗診断と復旧：原因切り分け、権限回復、失敗したツールだけ再実行する手順
AndroidスマホAIエージェントのタスク失敗を、停止、証拠保存、根本原因の切り分け、権限回復、最小再実行、サポート報告、再発防止テストまで実用的に診断するランブックです。
- スマホAIエージェントのタスクが失敗したら、すぐ全体を再実行せず、外部への送信、発信、削除、設定変更が完了済みかを確認してから止めます。表示されたエラーは根本原因ではない場合があります。
- 診断では、元の依頼、直前の画面、実行済みステップ、使ったツール、権限、承認、ネットワーク、外部サービスの状態を最小限の失敗バンドルとして残します。個人情報や認証情報は伏せます。
- AgentDebugXのDetect、Attribute、Recover、Rerunの考え方は、スマホでは入力、モデル、能力ルーティング、現在画面、権限、ツール、外部効果、確認の層に分けて使うと実用的です。
- FoneClawでは、現在画面の文脈、タスク継続、実行確認、停止、再試行、権限回復、結果確認を組み合わせ、失敗した部分だけを安全に直して進める体験を作っています。
失敗したタスクをまず安全に止める
スマホAIエージェントの失敗診断と復旧で最初にすることは、再実行ではなく停止です。送信、発信、削除、支払い、予定変更、設定変更のように外部への影響がある作業では、全体をもう一度走らせると重複送信や二重変更が起きることがあります。表示されたエラーだけを見て、すぐアプリ再起動や全タスク再実行に進むのは避けます。
最初の五分は、次の順番で見ます。まず現在画面と最後に見えた結果を確認します。次に、その作業が読み取りだけか、外部効果を持つ作業かを分けます。読み取りだけなら再試行しやすい一方、発信や送信のような作業では完了済みの効果を先に確認します。最後に、AIエージェントが止まった場所、ユーザー確認待ちだったか、権限画面だったか、外部アプリが前面にあったかを記録します。
AgentDebugXの研究は、表示された失敗点の前に根本原因があることを前提に、Detect、Attribute、Recover、Rerunという流れで調べる考え方を示しています。これはFoneClawに組み込まれた機能という意味ではなく、スマホAIエージェントのトラブルシューティングにも役立つ調査の型です。私たちはFoneClawを作る中で、この型を端末状態、権限、実行確認、外部効果に合わせて考えることが重要だと学んでいます。
最小限の失敗バンドルを残す
復旧できる失敗と、再現が難しい失敗の差は、証拠の残し方で大きく変わります。必要なのは大量のスクリーンショットや全文ログではなく、意図、軌跡、状態、結果を再構成できる最小限の失敗バンドルです。元の依頼、期待した結果、直前の画面、実行済みステップ、使ったツール、承認した操作、拒否した権限、ネットワーク状態、外部サービスの応答を短く残します。
AgentDebugXが重視する軌跡全体の理解は、スマホでは特に大切です。最後のエラーが「連絡先が見つからない」でも、根本原因は連絡先権限、別アカウント、画面文脈の取り違え、モデルの引数生成、外部アプリの状態変化かもしれません。スクリーンショット一枚では、どの時点でずれたかが分かりません。逆に、個人情報を含む全履歴を送る必要もありません。
- 元の依頼：何をしてほしかったか。
- 期待結果：どのアプリ、相手、設定、ファイル、予定が変わるはずだったか。
- 実行済み結果：送信済み、未送信、下書き、画面遷移、設定変更など。
- 状態：権限、ネットワーク、電池制限、前面アプリ、ロック状態。
- 直前の操作：最後に成功したステップと、最初に変になったステップ。
- 伏せる情報：認証情報、連絡先の詳細、本文、トークン、住所、金融情報。
AIエージェントの権限、実行主体、監査証跡の考え方を深く確認したい場合は、AIエージェントのアイデンティティ、権限、監査ログ：ツール単位で安全に実行する設計が役立ちます。失敗バンドルは、サポートに渡すためだけでなく、自分で安全に再開するための地図にもなります。
失敗した層を切り分ける
Android AIアシスタントのトラブルシューティングでは、エラー文をそのまま原因名にしないことが大切です。スマホAIエージェントの失敗は、入力、モデル、能力ルーティング、現在画面の文脈、権限、ツール、外部アプリ、外部サービス、ユーザー確認、結果検証のどこかで起きます。同じ「実行できませんでした」でも、根本原因はまったく違うことがあります。
| 層 | よくある症状 | 診断の見方 |
|---|---|---|
| 入力 | 相手名や対象アプリが曖昧 | 元の依頼を短く言い換え、対象を明示する |
| モデル | 手順や引数が意図とずれる | 計画の対象、相手、日時、数量を確認する |
| 能力ルーティング | 使うべき操作候補が違う | 対応能力、Fallback、提案内容を確認する |
| 現在画面 | 前面アプリや画面状態が想定と違う | 直前画面、選択中のタブ、入力欄、ダイアログを見る |
| 権限 | 連絡先、通知、位置情報、マイクが使えない | 使う直前に許可状態を確認する |
| ツール | 呼び出しは合っているが結果が失敗 | ツール結果、エラー、再試行可否を見る |
| 外部効果 | 送信済みか未送信か分からない | 外部アプリや相手側の状態を確認する |
| 確認 | 承認待ちのまま止まる | ユーザー確認カード、システム確認画面、タイムアウトを見る |
Androidの実行時権限ガイドでは、権限は使うときに確認し、ユーザーが拒否、取り消し、恒久的に拒否できることが説明されています。つまり、昨日動いたタスクが今日失敗しても、モデルが悪いとは限りません。権限の自動リセット、端末設定の変更、アプリ更新、バッテリー制限、ネットワークの変化が原因になることがあります。
能力ルーティングの失敗を詳しく見る場合は、AIエージェントの能力ルーティング：AutoAttach、Suggest、FallbackでAndroid操作を選ぶ実践ガイドで、文脈を付ける、候補を出す、代替手順へ戻す流れを分けて確認できます。
最初に壊れた因果ステップを探す
エージェント 根本原因を探すときは、最後のエラーから前へ戻ります。AgentDebugXのAttributeの考え方は、表面に出た失敗ではなく、最初に因果的に壊れたステップを探すことです。スマホでは、最後にツールが失敗したとしても、その前に現在画面が違った、ユーザー確認が未完了だった、権限が取り消されていた、モデルが相手名を誤って引数に入れた、という形で前段に原因があります。
まず、最後に確実に成功したステップを決めます。次に、最初に期待と違ったステップを探します。その間にある前提条件を読み取りだけで検査します。連絡先が見つからないなら、連絡先権限、対象アカウント、表示名、検索語を確認します。メッセージ送信が失敗したなら、下書きが作られたか、送信ボタンが押されたか、システム確認画面に止まったか、相手を取り違えていないかを分けます。
根本原因は一つに決めつけず、信頼度を付けて書きます。例として「主原因は連絡先権限の拒否。代替候補は表示名の曖昧さ。根拠は、同じ検索語で権限許可後に候補が出たこと」のように残します。この書き方なら、後でサポートや開発者が再現しやすくなります。ベンチマークや評価設計まで広げたい場合は、Androidスマホエージェント ベンチマーク：2026年の評価指標と再現可能なテスト設計で、失敗例をテストケースへ変える方法を確認できます。
完了済みの効果を重複させず復旧する
AIエージェント タスク失敗から復旧するときは、RecoverとRerunを分けます。Recoverは、壊れた前提を直す段階です。権限を許可する、アプリを前面へ戻す、ネットワークを回復する、相手を選び直す、下書きを修正する、ロックを解除する、確認カードに戻る、といった作業です。Rerunは、直した後にどこから再実行するかを選ぶ段階です。
重要なのは、失敗したツールだけ再実行できるかを確認することです。読み取りや状態確認のような操作は再実行しやすい一方、送信、発信、削除、購入、共有、予定変更のような操作は外部効果があります。すでに送ったメッセージをもう一度送らないよう、まず外部アプリ側の状態を見ます。下書きが残っているなら本文だけ直します。送信済みなら完了扱いにし、後続の確認だけ行います。
Androidの権限は、拒否、恒久的拒否、自動リセット、設定変更の影響を受けます。Androidの権限ベストプラクティスでは、許可済みと取り消し済みの組み合わせをテストすることが推奨されています。復旧でも同じで、権限を直したら全タスクを走らせるのではなく、直した前提に関係する最小の後続ステップだけを試します。
- 完了済みの外部効果を確認する。
- 壊れた前提を一つだけ直す。
- 読み取りで状態を確認する。
- 失敗したステップだけを再実行できるか判断する。
- 高影響操作ではユーザー確認を再度挟む。
- 最終状態を確認し、タスクを閉じる。
自動ロールバックがすべての操作にあると考えず、外部アプリや相手側に残った効果を確認してから進めます。復旧の目的は「もう一度全部やる」ではなく、「安全な最小範囲だけを再開する」ことです。
FoneClawの現在の復旧コントロールを使う
FoneClawでは、スマホAIエージェントの失敗を診断しやすくするために、タスク状態、現在画面の文脈、実行確認、停止、再試行、権限回復、結果確認を一つの作業の流れとして扱っています。私たちが作ってきたのは、AIが何かを試して黙って終わる体験ではなく、ユーザーが進行を見て、必要なところで止め、直した後に進める体験です。
現在画面の文脈は、ユーザーが選んで渡すものです。FoneClawは全画面を自動で取り続けるのではなく、ユーザーが必要な場面で現在画面を添付し、タスクの理解に使えるようにします。現在画面からの使い方を詳しく知りたい場合は、Android フローティングAIアシスタント 画面認識：現在画面から安全に操作へ進む方法で、画面文脈と操作のつなぎ方を説明しています。
FoneClawの対応範囲では、100+ built-in tools（100以上の内蔵ツール）を含む能力を、読み取り、設定変更、通信、予定、端末状態、ワークフロー、拡張といった作業に分けて扱います。ツール結果、必要な権限、実行確認の有無、停止や再試行の操作は、失敗診断の証拠になります。権限が足りないときは権限回復へ進み、外部効果がある操作では完了済みかを見てから後続だけを進めます。
FoneClawの機能ページでは、現在の対応機能の大枠を確認できます。FoneClawの最新情報ページでは、現在画面の文脈、タスク継続、実行確認、停止、再試行、権限回復、能力ルーティング、状態確認に関するユーザー向けの改善を追えます。私たちは、復旧を特別な裏技ではなく、日常のAndroidワークフローに含まれる操作として育てています。
役に立つサポート報告を作る
自分で復旧できないときは、サポートや開発者が再現できる形で報告します。必要なのは、個人情報を丸ごと渡すことではありません。元の依頼、期待結果、最後に成功したステップ、最初に壊れたと思うステップ、前面アプリ、端末名、Androidの大まかなバージョン、権限状態、ネットワーク状態、エラー文、時刻を残します。連絡先、メッセージ本文、認証情報、トークン、住所、金融情報は伏せます。
サポート報告の本文は、短く構造化します。「何をしたかったか」「どこまで進んだか」「何が起きたか」「何を試したか」「再現条件」「伏せた情報」の順に書くと、エージェント 根本原因を探しやすくなります。スクリーンショットを送る場合も、個人情報を隠し、送信前に必要性を確認します。全履歴を渡すより、再現できる最小手順のほうが修正につながります。
受け入れテストで再発を防ぐ
一度直った失敗は、小さな受け入れテストに変えます。権限が許可された状態、拒否された状態、恒久的に拒否された状態、ネットワークが切れた状態、外部アプリが別画面にいる状態、ユーザー確認で止まった状態を分けて試します。一回成功した再実行だけで恒久的な修正と見なさず、同じ失敗が戻らない条件を決めます。
テストには、合格、停止、復旧の三つの結果を用意します。合格は期待どおりの最終状態です。停止は高影響操作の前でユーザー確認が出ることです。復旧は、権限や前面アプリが壊れても、必要な説明と再試行の道が見えることです。これにより、スマホAIエージェントの失敗診断と復旧は、場当たり的なトラブル対応から、次の改善へつながる運用になります。