AIエージェント承認UI設計：提案、信頼度、理由、タスク状態をスマホでどう見せるか
AIエージェント承認UIに必要な提案と適用の区別、信頼度による確認の振り分け、短い理由表示、タスク単位の承認、スマホ操作の復旧設計を解説します。
- AIエージェント承認UIでは、変更が起きる直前を特定し、対象、内容、影響、確定後の状態を一画面で確認できるようにします。
- 提案、確認用プレビュー、即時適用は別の状態です。信頼度は確認の優先順位を決める材料であり、正しさや安全性の保証として扱いません。
- 承認には短い理由と根拠を添え、元の会話、タスク、待機状態に結び付けます。権限管理やサーバー側の安全対策は承認画面とは別に必要です。
- 現在のFoneClawでは、実行中と待機中の状態、セッション単位の承認、タスク分離、権限不足からの復旧、ホーム画面から始めた実行の復旧を改善しています。
スマホ上で変更が起きる直前を特定する
AIエージェント承認UIの設計は、確認ボタンを追加することから始まるのではありません。最初に決めるのは、ユーザーの端末、データ、相手、外部サービスに変化が生じる瞬間です。文章案を生成するだけならまだ提案ですが、メッセージを送る、設定値を書き換える、ファイルを削除する、経路案内を開始するといった操作では、画面の外にも結果が残ります。その直前が、内容を見直し、進めるか止めるかを選べる判断地点です。
判断地点は操作の影響に合わせて配置します。たとえば「山田さんに到着が15分遅れると伝えて」という依頼では、文面作成、連絡先選択、送信は別々の状態です。承認画面には宛先、使用するアプリまたはアカウント、本文、送信後に起きることを表示します。「送信しますか」だけでは、別の山田さんが選ばれていても気付きにくいためです。
画面上の状態名も具体的である必要があります。「処理中」だけでは、生成中なのか、確認待ちなのか、すでに変更したのか分かりません。「下書きを作成中」「送信前の確認待ち」「送信済み」「権限が必要」のように、次に誰が動くのかまで読み取れる表現が適しています。ユーザーが判断する段階なら、エージェント側の作業は待機状態へ移し、承認されるまで対象を変更しません。
私たちがFoneClawで重視するのも、依頼から結果までの状態を見えるようにすることです。現在のFoneClawでは、実行中と待機中を分け、承認を現在のセッションに結び付け、別のタスクと混ざらないよう改善しています。承認対象が分からなくなった場合は進めず、元の依頼と対象を表示し直せることが、スマホ上の実用性につながります。
提案、プレビュー、即時適用を分ける
同じ候補でも、「提案する」と「適用する」では結果が異なります。提案は変更案を並べる状態、プレビューは適用後の内容を確定前に見せる状態、即時適用はその場で変更を反映する状態です。AIエージェント承認UIでは、この三つをボタン名、色、状態表示、操作後の案内で区別します。「続行」のように結果が曖昧なラベルより、「下書きに反映」「送信」「変更せず閉じる」のような具体的な動詞が適しています。
2026年7月23日に公開プレビューとして発表されたGitHub Issuesのエージェント自動化制御は、この違いを理解する参考になります。対応するIssue操作について、変更をすぐ適用する代わりに提案として保留し、ユーザーが確認して受け入れるか拒否できる仕組みです。これはGitHub Issuesにおける対応操作の設計であり、スマホ操作やFoneClawの機能を説明するものではありません。
モバイル画面へ応用するなら、まず影響の小さい準備を進め、外部へ影響する直前でプレビューを出す構成が分かりやすくなります。メッセージなら下書き作成までは進め、送信前に止めます。設定変更なら候補値を示し、現在値と変更後の値を並べます。ファイル操作なら対象名、保存場所、上書きの有無を確定前に表示します。
| 表示状態 | ユーザーに見せる内容 | 適した操作 |
|---|---|---|
| 提案 | 候補、理由、選択肢 | 分類、文面案、設定候補 |
| プレビュー | 対象、変更前後、影響 | 送信前、保存前、設定変更前 |
| 即時適用 | 実行内容、完了結果、戻し方 | 明示的に許可された低影響の操作 |
| 確認待ち | 待機しているタスクと期限 | 外部への送信や重要な変更 |
承認の有無だけで安全性を判断してはいけません。GitHubも、この承認機能を作業上の利便性として位置付け、サーバー側の安全対策そのものではないと説明しています。スマホでも同様に、Android権限、アプリ側の認証、データへのアクセス制御、操作履歴が別に必要です。提案画面は判断を助けますが、本来持っていない権限を生み出すものではありません。
信頼度で確認の優先順位を調整する
多数の候補を毎回同じ重さで確認すると、ユーザーは重要な項目まで読み飛ばしやすくなります。そこで信頼度を、どの候補を自動適用し、どれを確認待ちにするかを振り分ける材料として使えます。ただし、信頼度は正解率の保証ではありません。モデルが高い信頼度を示しても、対象データが古い、同名の相手がいる、現在の端末状態を誤認しているといった問題は残ります。
GitHubの公開プレビューでは、対応するIssue操作について高信頼度の変更を自動適用し、中または低信頼度の変更を提案として保留する仕組みが示されました。これは、確認の手間を不確かな候補へ集中させる一例です。適用対象はラベル、フィールド、Issueの種類、クローズ、担当者など、GitHubが定める対応操作に限られます。スマホ上の送信や設定変更へ同じ基準をそのまま移すことはできません。
電話では、信頼度に加えて操作の影響を見ます。連絡先候補が一人しか見つからなくても、機密情報を含むメッセージ送信なら確認が必要です。逆に、画面を少しスクロールする操作は候補が多少曖昧でも、すぐ止めて戻せます。つまり振り分けは「どれだけ確からしいか」と「間違えたときに何が起きるか」の組み合わせで決めます。
| 判断材料 | 確認を軽くできる条件 | 確認を強める条件 |
|---|---|---|
| 対象の特定 | 一意で画面上に表示されている | 同名候補、複数アカウント、非表示の対象 |
| 操作の影響 | 端末内で容易に戻せる | 送信、削除、共有、支払い、公開 |
| 根拠の鮮度 | 現在の画面から取得 | 古い会話、推測、欠けた情報 |
| 復旧方法 | 取り消しや再編集が可能 | 取り消せない、相手へ即時反映される |
FoneClawの現行機能を説明するときも、GitHub型の信頼度自動適用を備えているとは扱いません。私たちが現在提供しているのは、タスク状態の分離、セッションに結び付いた承認、権限不足からの復旧などです。信頼度を承認設計へ取り入れる場合でも、ユーザーが設定した方針と操作の影響を優先し、数値だけで確定操作を決めないことが基本です。
理由、対象、影響、根拠を短く示す
承認画面には、「なぜこの操作が提案されたのか」を短く表示します。ただし、長い推論過程をそのまま載せる必要はありません。ユーザーが知りたいのは、対象、行う変更、提案理由、根拠となった情報、実行後の影響です。これらを数行で読めれば、移動中や片手操作でも判断できます。
たとえばカレンダー候補なら、「会話内の『8月12日14時』を予定候補として検出」「仕事用カレンダーへ60分の予定を作成」「参加者への招待はまだ送信しない」と表示します。理由だけでなく、どの情報を使い、どこまで進めるかが分かる構成です。日時やカレンダーが推測なら、その項目を強調し、修正してから承認できるようにします。
GitHubの公開プレビューでは、対応する変更ごとに理由が記録され、提案を確認するときだけでなく、自動適用された場合も変更理由を追跡できます。モバイルUXで参考になるのは、結果だけでなく「なぜその対象と操作を選んだか」を後から確認できる点です。一方、表示された理由が正しいからといって、アクセス権限や操作の妥当性まで保証されるわけではありません。
理由表示は簡潔さと検証可能性を両立させます。「最適だと判断しました」では根拠を確かめられません。「現在開いている会話の最新メッセージに返信依頼があるため」のように、参照位置を示します。情報が不足しているなら、断定的な説明を作るのではなく、「送信先が二件見つかったため選択が必要」と示すほうが役立ちます。
より深い設計では、誰の権限でどの機能が呼ばれ、何が記録されるかも重要です。承認画面の先にある本人性、権限、操作履歴を整理するには、AIエージェントのアイデンティティ、権限、監査ログ：ツール単位で安全に実行する設計が関連する判断材料になります。
承認を正しいタスクと待機状態に結び付ける
スマホでは、承認を表示してからユーザーが戻るまでに時間が空くことがあります。その間に別の会話を開いたり、新しい依頼を始めたり、対象アプリの状態が変わったりします。したがって承認は、単なる「はい」という回答ではなく、元のタスク、会話、対象、提案内容、作成時点に結び付けなければなりません。
たとえば、仕事用チャットへの返信と家族へのメッセージ下書きが同時に待機している場面を考えます。確認画面に本文だけを表示すると、どちらへの承認か取り違える可能性があります。画面にはタスク名、対象アプリ、宛先、作成時刻、現在の状態を表示し、承認後もそのタスクだけを再開します。別の会話で発行された承認を流用してはいけません。
現在のFoneClawでは、複数のタスクについて実行中と待機中を独立して表示し、承認を該当セッションに結び付け、タスク同士の状態を分離しています。あるタスクがユーザー確認を待っていても、別のタスクの内容や承認状態と混ざらないことが目的です。再開時には、承認対象が作成時から変わっていないかも確認します。
時間の経過によって前提が変わる操作には、有効期限や再確認を設けます。経路、価格、端末状態、開いているファイルなどは、承認待ちの間に変わる可能性があります。古い提案をそのまま適用せず、「内容が変更されたため更新が必要」と表示し、新しいプレビューを作るほうが安全で分かりやすい設計です。
複数タスクを一覧で扱う画面では、実行中、確認待ち、権限待ち、完了、失敗を視覚的に分けます。各項目から元の会話と操作内容へ戻れるようにすると、ユーザーはどの判断を保留しているか把握できます。こうした管理画面の考え方は、スマホ AI エージェント コントロールは、承認と可視化が中心になるでも詳しく扱っています。
メッセージ、設定、ファイル、経路案内へ応用する
承認UIは、すべての電話操作へ同じ確認画面を出せばよいわけではありません。操作ごとに、間違えやすい対象と実行後の影響が異なります。メッセージでは宛先と本文、設定では変更前後の値、ファイルでは対象と保存場所、経路案内では目的地と移動手段が中心です。確認画面は、その操作で最も重大な誤りを発見しやすい順に情報を並べます。
| 電話上の操作 | 承認前に見せる内容 | 適した戻り方 |
|---|---|---|
| メッセージ | 送信元、宛先、本文、添付 | 下書きへ戻って修正 |
| 端末設定 | 現在値、変更後、影響する機能 | 変更せず設定画面を開く |
| ファイル操作 | ファイル名、場所、上書き・削除の影響 | 対象を選び直す |
| 経路案内 | 目的地、出発地点、移動手段 | 候補一覧へ戻る |
| 外部共有 | 共有先、公開範囲、共有内容 | 共有範囲を変更 |
メッセージの例では、文章を生成しただけなら「下書き」と表示します。宛先を選んだ段階でプレビューを更新し、送信操作は独立したボタンにします。返信先が複数ある場合は、AIが一人を推測して確定するのではなく、候補を提示します。送信後は完了表示とともに、どのアカウントから誰へ送ったかを確認できるようにします。
設定変更では、確認より前にAndroid権限が必要になる場合があります。権限を求める画面と操作を承認する画面は役割が違います。前者は端末機能へのアクセス許可、後者は具体的な変更への同意です。サンドボックスや権限だけでは個々の操作意図まで確認できない理由は、AI Agent サンドボックスとスマホ権限：安全なAgentにも確認が必要な理由で整理しています。
経路案内の開始や画面移動のように、比較的戻しやすい操作では確認を簡略化できます。ただし、同名の場所が複数ある、現在地が取得できない、海外の目的地が選ばれている場合は、候補を表示して判断を戻します。操作の種類だけで一律に決めず、その時点の曖昧さと影響を見て確認方法を変えることが重要です。
拒否、修正、取り消し、権限回復を用意する
良い承認UIは、承認ボタンよりも断った後の動きを丁寧に設計します。「拒否」だけでは、提案内容が悪いのか、今は実行したくないのか、対象が違うのか分かりません。「内容を修正」「対象を変更」「後で確認」「この操作を中止」といった選択肢を用意すると、ユーザーは依頼全体を捨てずに問題のある部分だけを直せます。
修正後は、古い承認をそのまま使わず、新しい内容を再表示します。宛先、金額、日時、公開範囲など、結果に影響する項目が変わった場合は再承認が必要です。一方、誤字の修正など影響が限定的な変更では、変更箇所を強調して確認時間を短くできます。何が変わったか分からない状態で再度「承認」を求めるべきではありません。
実行後に取り消せる操作では、完了通知に戻し方を添えます。ただし「元に戻す」が実際に可能な場合だけ表示します。外部へ送信済みのメッセージや完全削除など、取り消せない結果には偽の安心を与えず、完了状態と次に取れる対応を示します。実行結果が不明な場合は、同じ操作を繰り返す前に現在の状態を確認します。
権限不足で止まったときは、必要な権限、必要な理由、設定を開く操作、許可後の再開地点を表示します。現在のFoneClawでは、この権限回復と、ホーム画面から始めた実行が途中で止まった場合の復旧を改善しています。許可後に別の対象へ進むのではなく、元のタスクとセッションを確認し、その操作だけを再開します。
- 提案内容、対象、影響、根拠を確認する。
- 問題があれば、拒否ではなく修正する項目を選ぶ。
- 修正後のプレビューで変更箇所を確認する。
- 権限が不足している場合は、必要性を確認して設定へ進む。
- 再開時に元のタスク、会話、対象が保持されているか確かめる。
- 実行後は結果を読み、利用可能な場合だけ取り消し操作を使う。
- 画面状態が想定と違う場合は、自動処理を止めてタッチ操作へ切り替える。
AIエージェント承認UIの目的は、確認回数を増やすことではありません。ユーザーが判断すべき瞬間に、必要な情報だけを示し、進める、直す、断る、戻るという選択を保つことです。提案と適用を分け、信頼度を振り分けに使い、理由を短く示し、承認を正しいタスクへ結び付けることで、スマホ上のAI操作は理解しやすくなります。途中で止まっても、状態と次の手順が見えることが、日常的に使えるエージェント体験の条件です。