# デスクトップアプリは実はWebページだ：これを理解すると、操作はもはや「デスクトップ自動化」ではなくなる

初はじめて chrome-use で Slack デスクトップ版ばんにつなぎ、snapshot で出でてきた名前付なまえつきのボタンの山やまを見みたとき、少すこし驚おどろいた。これはWebページを操作そうさするのとまったく変かわらない。あとで納得なっとくした。Slack デスクトップ版ばんは、そもそもWebページなのだ。

Electron アプリは、Chromium レンダリングエンジンに Node.js の外殻がいかくを足たしたものだ。Slack、VS Code、Discord、Figma、Notion を「デスクトップソフト」として使つかっているつもりでも、その画面がめんはすべて Chromium がレンダリングした HTML で、外側そとがわにネイティブウィンドウの殻からをかぶせているだけだ。この事実じじつを受うけ入いれると、もともとかなり難むずかしかったことが、崩くずれるように簡単かんたんになる。デスクトップアプリの操作そうさは、Webページの操作そうさへと退化たいかする。

デスクトップ自動化はもともとどれほど扱いにくかったか

まず、この道みちがなかったとき、プログラムにデスクトップアプリを操作そうささせるのがどれほど難むずかしかったかを話はなそう。

ひとつの方法ほうほうは、スクリーンショットを撮とり、ボタンのピクセル座標ざひょうを探さがし、そこをクリックすることだ。解像度かいぞうどが変かわり、テーマが変かわり、ウィンドウが動うごいただけで、座標ざひょうはすべてずれる。しかもプログラムは画面がめんに何なにがあるのかを「理解りかい」できず、ただ1枚まいの画像がぞうを見みているだけだ。もうひとつの方法ほうほうは、システムのアクセシビリティ API、つまり macOS の Accessibility や Windows の UIAutomation を使つかうことだ。これならコントロールツリーを取得しゅとくできるが、プラットフォームごとに API が別べつで、しかも Electron アプリがこの API に公開こうかいする情報じょうほうは、しばしば不完全ふかんぜんだ。なぜなら、その「コントロール」は実際じっさいにはネイティブコントロールではなく div だからだ。

どちらの方法ほうほうも手間てまがかかるし、どちらもひとつの事実じじつを迂回うかいしている。このアプリの内部ないぶには、構造こうぞうがはっきりしていて意味いみもある DOM があるのに、外側そとがわからピクセル越ごし、あるいは変換へんかんされた層そう越ごしに、それへ手てを伸のばしているのだ。

Chromium には最初から扉がある

レンダリングエンジンが Chromium なので、Electron アプリは自然しぜんに Chrome DevTools Protocol を話はなせる。起動時きどうじに --remote-debugging-port を付つけると、CDP ポートが開ひらき、内部ないぶの DOM がそのまま露出ろしゅつする。

open -a "Slack" --args --remote-debugging-port=9222
chrome-use connect 9222
chrome-use snapshot -i

（アプリごとに衝突しょうとつしないポートを割わり当あてればよい。全ぜんプラットフォームの起動きどうコマンドはドキュメントサイトにあるので、ここでは詳くわしく展開てんかいしない。）

snapshot が返かえすのは、その DOM のアクセシビリティ視点してんだ。すべてのボタンや入力欄にゅうりょくらんは名前なまえを持もつ要素ようそであり、@ref で特定とくていできる。あなたは「送信そうしんボタンはたぶん右下みぎしたあたりのピクセルにある」と推測すいそくしているのではない。button "Send" そのものを取得しゅとくしている。ウィンドウが動うごいても、テーマが変かわっても影響えいきょうしない。結むすびついているのは座標ざひょうではなく要素ようそだからだ。agent にとって、この違ちがいは本質的ほんしつてきだ。いまや agent は、このデスクトップアプリがどんな姿すがたをしているかを読よみ取とれる。スクリーンショットを相手あいてに当あてずっぽうでクリックしているのではない。

必ず知っておくべきトレードオフ

ここには、ブラウザの場面ばめんとは違ちがう点てんがある。思おもい込こみやすいので、別べつに話はなしておく価値かちがある。

普段ふだん使つかっている Chrome を操作そうさするとき、chrome-use はブラウザ拡張かくちょうと native messaging を使つかう。デバッグポートには触ふれないので、「リモートデバッグを許可きょかするか」という確認かくにんダイアログもなく、Runtime.enable のようなプロトコル層そうの痕跡こんせきもない。しかし Electron アプリには Chrome ウェブストアの拡張かくちょうを入いれられない。だから、この道みちでは --remote-debugging-port を使つかうしかない。つまり、ブラウザの場面ばめんにあった「痕跡こんせきゼロ」のような利点りてんは、Electron では得えられない。前提ぜんていは、自分じぶんでデバッグポートを開ひらいて、そこへ接続せつぞくすることだ。

Slack や VS Code のような「自分じぶんのアプリ」を自動化じどうかするなら、これはまったく問題もんだいではない。誰だれかをだまそうとしているのではなく、すでにログインしている自分じぶんのツールを自動化じどうかしたいだけだからだ。ただし、ブラウザでの「検出けんしゅつされない」という期待きたいを持もったまま Electron を操作そうさしに来くるなら、まず期待値きたいちを調整ちょうせいする必要ひつようがある。これは「自分じぶんのアプリへ接続せつぞくする」ことであって、「他人たにんのサイトを隠かくれて操作そうさする」ことではない。

おもしろい細部：アプリの中にさらにアプリを入れられる

Electron アプリの内部ないぶには、しばしば <webview> がさらに埋うめ込こまれている。たとえば Slack で開ひらいた第三者だいさんしゃアプリのパネルは、本質的ほんしつてきにはもうひとつの独立どくりつしたWebページだ。これらは CDP では独立どくりつした target になる。接続後せつぞくごにまず chrome-use tab で一覧いちらんを出だすと、メインウィンドウ、設定せっていウィンドウ、そしてそれらの webview が、それぞれ target になっているのが見みえる。個別こべつに切きり替かえて操作そうさできる。

だから、ひとつの Electron アプリは「ひとつのWebページ」ではない。「ネイティブの殻からの中なかに重かさなったWebページの束たば」だ。これを理解りかいすると、マルチウィンドウや入いれ子こパネルのような、もともと頭あたまを悩なやませる場面ばめんは、すべて「正ただしい target に切きり替かえる」だけになる。

境界

この方法ほうほうは、Chromium 内核ないかくのアプリにだけ成なり立たつ。Swift/AppKit で書かかれた純粋じゅんすいなネイティブアプリには CDP ポートがなく、接続せつぞくできない。その場合ばあいは、システムのアクセシビリティに戻もどるか、別べつのツールを使つかう必要ひつようがある。iPhone 上のネイティブ app を操作そうさするとき、私は別べつの仕組しくみを使つかっている。判断はんだんは簡単かんたんだ。Slack、VS Code、Discord、Figma、Notion、Spotify のような「ひとつのコードでマルチプラットフォームに対応たいおうする」デスクトップアプリは、基本的きほんてきに Electron だ。

「デスクトップアプリは実じつはWebページだ」と理解りかいしてから、私はデスクトップツールを見みると、まずそれが Electron かどうかを確認かくにんするようになった。Electron なら、それを操作そうさすることは、もはや私がずっと泥臭どろくさいと感かんじていた「デスクトップ自動化」ではない。すでによく知しっている、Webページを開ひらいて扱あつかうためのあの方法ほうほうになる。