Mole のために数百本の Mac アプリを検証

このところ、ちょっとばかげたことをしています。AI の時代にエンジニアが避けたくなるような、ひたすら同じ作業です。Mole のアンインストールと残存ファイルの検出を改善するために始めました。中国国内外の Mac アプリを 300 本以上集めると、ダウンロードは 100 GB を超えました。10 本ずつ 30 組に分け、AI に computer use で公式サイトからダウンロードしてもらい、私の Mac にインストール。ディレクトリ、更新用のバンドル、自動起動項目を調べ、削除後に何が残るか確認して、足りないルールを補いました。

100 本から 300 本、そして 800 本へ

最初は定番アプリを 100 本試すつもりでした。それが「あと 100 本」を繰り返すうちに 300 本を超え、後には App Store 版や拡張機能も含めて 709 本に。普段は Mac のアプリを 30 本ほどに抑えようとしている私のデスクトップが、テスト中はこんな状態になりました。

その後も確認を続け、一覧は 800 本になりました。削除が難しい Adobe 製品やウイルス対策ソフト、普段の開発で使うソフトやさまざまな AI ツールも含まれています。それだけ調べても、汎用ルールでは拾えない残存ファイルがまだ見つかり、各アプリが実際にどこへファイルを書き込むのかを追う必要がありました。

単調な作業ですが、インストールは毎回すんなりとは進みません。権限の要求、購入画面、管理者パスワードの入力。大半はエージェントが処理し、難しいところを私が手伝います。驚いたのは、AI が自分の作業を楽にするため、インストール、削除、残存ファイルの確認用スクリプトまで書いたこと。途中から私が助手になったようでした。

インストールは始まりにすぎない

時間がかかるのは、初回起動、権限の確認、更新、自動起動、削除までを一通り確かめることです。インストーラーの中身だけでは、起動後に作られるディレクトリは分かりません。アプリ本体を消しただけでは、別の場所に置かれたファイルの行方も分かりません。

誰がこのディレクトリを作ったのか、更新用 helper はどのアプリのものか、自動起動項目は残っているか。実際のパスと所有関係を確認してからルールに加えます。名前が似ているだけでは足りません。App Store 版と公式サイト版も、同じ名前でも保存先やインストール方法が違う場合があるため、別々に確認します。

AI は繰り返し調べ、分かった手順をスクリプトにできますが、権限や管理者パスワード、所有関係が不明なファイルには人の対応が必要です。すべて手作業なら、私の見積もりでは 10 倍の時間がかかったと思います。

実際に入れてみないと分からないこと

100 本も試せば、ソフトウェアの規則的な作りから残りも推測できると思っていました。でも実際には、汎用ルールでは見つからないパスがいくつもあり、バンドル ID が逆ドメイン形式でないアプリさえあります。整った慣例に見えても、開発者がその場で決めた値かもしれません。一つずつ入れて確認する必要がありました。

消さずに残すものも見つける

最初の 300 本以上のテストでは、再利用できるルールを 13 種類、個別の削除パスを 90 件以上追加しました。同時に、消すつもりだったけれど触るべきではない箇所を 30 件以上修正し、更新と自動起動の確認も補い、100 件以上のユニットテストを追加しました。これはその時点の記録で、アプリ一覧は今も増えています。

残すべきものの発見は、新しい残存ファイルの発見と同じくらい大切です。キャッシュは再生成できても、人が書いたファイルはそうはいきません。複数のアプリが共有するデータも、一つを削除しただけで消してはいけません。不要に見えるファイルが別のアプリで使われていることもあるので、所有関係が不明なら残す方が適切です。

削除量の数字を増やすことが目的になると、判断を誤ります。共通部分は汎用ルールに、特殊なパスは個別確認に任せ、削除してはいけない事例をテストに残すことで、後の変更で同じ間違いを繰り返しにくくなります。

Mole がなくても使えるアンインストール手順

各アプリのアンインストール手順もサイトにまとめました。先に終了するバックグラウンドプロセス、公式アンインストーラーが必要な場合、残すかどうか自分で判断するデータを、できるだけ具体的に書いています。現在は 800 本すべてに英語と簡体字中国語の無料ガイドがあり、Mole を購入していなくても参考にできます。自分の Mac に入っているアプリが一覧にあるか、探してみてください。

アクセシビリティが思わぬ助けに

Mole は初期のバージョンから視覚障害のある方の利用に取り組み、アクセシビリティ属性を追加してきました。今回、AI もその属性を使って正しい要素やボタンを見つけられ、テストが進めやすくなりました。利用者のために行った作業が、自分の助けにもなったのです。

アクセシビリティ属性は位置だけでなく、ボタンの名前、種類、現在の状態も伝えられます。レイアウトが変わっても同じ操作対象を探す手掛かりになります。画像と固定座標だけでは、ウィンドウやダイアログが動くと別の場所を押してしまいます。

ただし、まず人のための仕組みです。AI がボタンを見つけられても、VoiceOver の利用者が操作を終えられる証明にはなりません。ラベル、フォーカス順、結果の読み上げは別に確かめる必要があります。さまざまな使い方を支えることの価値を、今回あらためて感じました。

アプリや Web サイトを作る方は、コーディング AI にアクセシビリティの整備を手伝ってもらうのもよさそうです。視覚障害のある方が使いやすくなるだけでなく、自動テストも安定しやすくなるかもしれません。この作業は今後も続けます。実測アプリ一覧で記録を確認でき、ディスカッションでは次に試してほしいアプリを募集しています。 今回追加したルールは、今後 Mole CLI にも少しずつ移植していく予定です。