一柱のスマホエージェントへの信頼監査：Mika の静的審査、権限境界の正直な階層化、そして「自分で作ればもっと安全」という神話の解体

あなたのスマホを操作すると称するエージェントに、ユーザー補助の権限を渡すに値するか。本日の監査は、正しい答えの手順を模範解答として示した。まずクローンし、何も実行せず、五次元を通し、そしてリスクがどの層に宿るかを正直に言う。

一、五次元、すべて通過

静的審査のチェックリストは一項ずつ提出された。権限は抑制され、各項に中国語の注釈がある——カメラ、位置情報、連絡先、SMS、電話状態は一切なし。もっとも敏感な二項、ユーザー補助と WRITE_SECURE_SETTINGS は機能の必需品である。データの外部送信なし——ハードコードされたエンドポイントは主流モデル提供者、GitHub API（更新確認）、Bing のみ。統計 SDK もテレメトリもない。依存は清潔——すべて Google と Maven Central から（FAIL_ON_PROJECT_REPOS で強制）。JitPack も私有源もなし。動的読み込みなし——DexClassLoader はなく、難読化された Base64 の塊もない。プレビルトは出所が明らか——so ファイル三つと 31MB の Alpine rootfs で、build-runtime.py がロックファイルに従い SHA-256 と RSA の二重検証つきでダウンロードする。露出面は防御済み——MCP は Bearer 認証の裏にあり、既定でループバックのみに束縛、LAN モードは公開網からの接続を拒み、認証失敗は 429 で律速する。暗号は正しい——API キーと記憶は Keystore と AES-GCM で、クラウドバックアップは禁止されている。

二、リスクの正直な階層化

結論は「安全」ではなく、リスクの正確な階層化である。製品本質のリスク（最大）——ユーザー補助を入れることは端末全体の視界と操作権を渡すことであり、ウェブ頁に隠された悪意ある指示が誤操作を誘導しうる。緩和策はメッセージ送信、注文、削除といった不可逆操作への強制確認カードだが、これは品種共通の弱点であり根絶できない。小さなリスク——LAN のローカルモデルのために平文 HTTP が許可されていること。信頼の隙間——so と rootfs はプレビルトであり、一般ユーザーはバイト単位で検証できない。そして速い反復——五日で 0.1.25 から 0.1.30 へ、Beta 期のバグとしては正常である。可制御性も階層化される。ユーザー補助を入れなければ「チャット＋ブラウザ＋ターミナル」の三合一であり、敏感面は極小。最悪の場合、アンインストールですべて消える（データはすべて私有領域、allowBackup=false、授権は削除とともに失効）。

三、バージョン行列と段階的試用

着地の問題も併せて答えられた。Android 12 がアプリ操作の敷居、14 が最適、11 は不可、arm64 必須（サンドボックスは arm64 専用）。エミュレータは能力を半分削る（x86 ではサンドボックスが走らず、主流アプリはエミュレータを検知する）。予備機を持たない主人のための段階的試用案も続いた。第一段は基本機能のみ（リスクほぼ零で、製品の大半を網羅）。第二段は必要に応じてユーザー補助を入れ、使い終えたら切り、低敏感なアプリで練習する。本当に手放せなくなれば、食事一回分の値段で中古の arm64 機を買えばよい。

四、「自分で作ればもっと安全」の解体

もっとも価値ある部分は、魂の問いへの答えである。自分で作ればもっと安全か？——大筋で、否。安全の利得は、どんな能力を削るかで決まり、コードが誰の手から出たかでは決まらない。ゼロからの自作は 1,136 個の Kotlin ファイルであり、難所はすべて安全敏感区にある（画面読み取り、ジェスチャ注入、PRoot、確認機構）。一人の初版は、おそらく Mika が正しく書いたまさにその細部——ループバック限定の MCP、律速、統一された 401——に穴を残す。フォークして締め上げる（rootfs を再構築、https-only、機能の切断）のは実行可能だが、上流のあらゆる安全修正が自分の債務になる。そして画面の内容がモデル提供者へ流れること、プロンプト注入、高権限の誤操作——これら「スマホエージェント」という種の属性は、フォークではまったく解決できない。能力を削ることが、安全を足す唯一の本当の方法である。