AIエージェントのサンドボックスとAndroid権限：3つの安全境界を分けて見る
AIエージェントのサンドボックス、Androidの権限、操作ごとの承認は別の安全境界です。分析結果をスマホの下書きへ移す例で、確認すべき層を整理します。
- AIエージェントのサンドボックス、Androidのアプリ分離、操作ごとの承認は、それぞれ守る対象が違います。
- Androidにはアプリごとのサンドボックスと権限モデルがありますが、権限の付与は宛先や本文の正しさまで承認するものではありません。
- gVisorのような実行環境のサンドボックスでも、設定されたファイルや許可されたネットワークは使えます。隔離だけで共有すべきデータを判断できるわけではありません。
- FoneClawでは、対応済みAndroid操作、現在画面の確認、編集欄への入力、ポリシーに沿った承認を別の層として扱います。入力だけでは送信しません。
3つの保護は別の問いに答える
AIエージェントのサンドボックスとAndroid権限を比べる時は、ひとつの「安全」という言葉にまとめないほうが分かりやすくなります。実行環境のサンドボックスは、コードやファイル操作をホストからどう隔離するかを扱います。Androidの権限は、端末上のデータや制限された操作へアプリがどうアクセスするかを扱います。操作ごとの承認は、いま実行しようとしている宛先、本文、共有、送信などをユーザーがどう確認するかを扱います。
| 層 | 主に制御するもの | 承認しないもの | ユーザーが見るべき点 |
|---|---|---|---|
| 実行環境のサンドボックス | コード実行、ファイル、プロセス、ホストとの境界 | スマホ上の宛先、本文、送信判断 | 使えるファイル、通信先、資格情報の扱い |
| Androidの権限とアプリ分離 | アプリごとのデータ、通知、連絡先、ファイル、特別なアクセス | その操作が今回の意図に合うか | 必要最小限の権限か、いつ求められるか |
| 操作ごとの承認 | 送信、入力、共有、購入、削除などの実行前確認 | サンドボックスやOSの設計そのもの | 相手、本文、対象アプリ、実行結果 |
Androidのアプリサンドボックスに関する公式説明では、AndroidがLinuxのユーザーIDやプロセスを使ってアプリを分離し、通常は他アプリの私有データへ直接アクセスできないようにしていることが説明されています。これは端末側の基礎です。FoneClawはこのOS側の分離を置き換えるものではなく、対応済みAndroid操作を現在の画面と権限の範囲で扱います。
サンドボックスにもファイルと通信の制限が必要
サンドボックスは「外へ何も出ない箱」という意味ではありません。たとえばgVisorのセキュリティモデルでは、サンドボックス化されたアプリケーションとホストカーネルの間に境界を追加する考え方が説明されています。同時に、サンドボックス内のアプリケーションは、設定されたファイルや許可されたネットワークリソースへアクセスできます。通信を制限したいなら、別途そのためのポリシーが必要です。
これは、AIエージェントでも同じです。サンドボックス化された実行環境で分析を行うことは、ホストへの影響を減らす上で有効です。しかし、マウントされたファイル、外部API、ネットワーク、ログ、資格情報の扱いは別に確認します。隔離は重要ですが、「どのデータを渡すべきか」「どこへ送ってよいか」までは自動で判断しません。
クラウド側の処理と端末側の操作を分けて考える視点は、AIエージェントの信頼性：クラウドAIとローカルAndroid操作をどう見分けるかでも詳しく扱っています。サンドボックスは実行環境の安全境界であり、Android上の権限や操作確認とは別に評価します。
Androidのアクセス権と操作承認は別
Androidの権限に関する公式概要では、権限が制限されたデータや制限された操作を保護し、インストール時、実行時、特別な権限が区別されることが説明されています。つまり、連絡先、カレンダー、位置情報、通知、ファイル、アクセシビリティのような領域は、それぞれ必要な場面で確認します。
ただし、Android権限を許可したことは、今回の宛先や本文が正しいことまで承認するものではありません。連絡先へアクセスできることと、どの相手に送るべきかは別です。編集欄へ入力できることと、その文章を送ってよいかも別です。支払い、共有、削除、送信のように外部へ影響する操作では、OS権限だけでなく、操作ごとの確認が必要になります。
FoneClawでは、現在見えている画面を確認し、対応するAndroid操作を進めます。編集欄へテキストを入れる操作は、送信やEnter確定ではありません。承認の出方は全体設定とツールごとのポリシーに従います。設定したオンラインモデルを使う場合、ユーザーが渡した依頼文や画面文脈が処理に使われることがあります。スマホ上で実行していることは、すべての推論やデータ処理が端末内だけで完結する証明にはなりません。スキル単位のアクセス確認を深く知りたい場合は、AIエージェントのスキル安全性：スマホ権限は実行時に確認すべき理由が近い補助になります。
分析結果を確認済みのスマホ下書きに変える
ここでは、考え方を説明するための例を使います。リモートの分析環境で、非機密の注文メモから「部品は在庫確認中。見積もりは本日17時までに連絡」と整理できたとします。この分析結果をAndroid上の顧客メッセージへ使う場合、サンドボックスからFoneClawへ自動で安全な橋がかかるわけではありません。ユーザーが必要な要点を確認し、スマホ側で使う文面として渡す流れにします。
FoneClawでは、まず対象アプリや会話を開き、現在見えている画面を確認します。相手が「佐藤さん」で正しいか、会話スレッドが合っているか、入力欄が見えているかを確認します。そのうえで、「佐藤様、部品の在庫を確認中です。本日17時までに見積もりをご連絡します。」のような下書きを表示中の編集欄へ入れます。ここでの入力は下書きの配置であり、送信ではありません。
ユーザーは本文、宛先、会話の流れ、金額や時刻の事実を確認します。送る場合は、別途送信の判断をします。手動で送る運用でも構いません。FoneClawでできるのは、対応済みのAndroid画面と編集欄を使い、確認できる下書きへ進めることです。Android上の実行手順の全体像は、AIエージェントでAndroidを操作する仕組み：意図、確認、実行、検証までの完全ガイドで整理しています。
この例で見るべき層は3つです。分析環境では、どのファイルと通信が許可されていたか。Androidでは、対象アプリや入力欄へアクセスできるか。操作承認では、相手と本文が正しいか。どれか1つだけを安全にしても、全体の確認にはなりません。
不確かな操作を繰り返さずに復旧する
失敗時の復旧でも、サンドボックスと外部への実行結果は分けて考えます。サンドボックスのチェックポイントを戻せても、すでに送信されたメッセージ、作成済みの予定、外部サービスに届いた変更まで巻き戻せるとは限りません。外に影響する操作は、実際のアプリ状態を見てから復旧します。
| 状況 | 安全な対応 | 避けること |
|---|---|---|
| 権限が拒否された | 必要性を確認し、手動手順へ戻る | 別の権限で無理に進める |
| 画面が変わった | 現在の画面を読み直し、対象を確認する | 古い画面情報を前提に操作する |
| 送信結果が不明 | 実際のメッセージアプリで送信済みか確認する | 同じ本文をすぐ再送する |
| 分析環境を戻した | 分析中のファイルや状態だけが戻った前提で確認する | 外部の送信や共有も戻ったと考える |
FoneClawでは、結果が不確かな時に、外部へ見える操作を繰り返す前に実際のアプリ状態を確認することを重視します。原因切り分けを詳しく進めたい場合は、スマホAIエージェントの失敗診断と復旧：原因切り分け、権限回復、失敗したツールだけ再実行する手順が役立ちます。
各層で根拠を確認する
最後は、層ごとに短く確認します。実行環境では、使えるファイル、通信先、資格情報、ログ。Androidでは、アプリ分離、必要な権限、現在の画面、対象アプリ。操作承認では、宛先、本文、共有先、送信や保存の結果です。
- サンドボックス内でアクセスできるファイルと通信先は明確か。
- Androidで必要な権限は依頼に対して最小限か。
- 現在の画面と対象の入力欄を確認できているか。
- 送信や共有の前に、相手と内容を見られるか。
- 不確かな結果では、実際のアプリ状態を見てから再実行できるか。
FoneClawの現在の対応範囲はFoneClawの機能一覧で確認できます。サンドボックス、Android権限、操作承認を分けて見れば、どの層で何が守られているかを具体的に判断できます。