Open-Interface：スクリーンショットとLLMでPCを操作させるGPL-3.0ツールの実力と境界
Control Any Computer Using LLMs.
ひと目でわかる
- これは何？
- Open-Interfaceは、LLMにスクリーンショットを渡して次の一手を決めさせ、pyautoguiでキーボードとマウスを動かすデスクトップ自動化ツールだ。導入は簡単だが、権限・コスト・GPL-3.0の扱いを先に確認したい。
- 誰に向いている？
- Open-Interfaceは、GUIしか持たない業務アプリの操作をLLMに代行させたい個人や小規模チームに向く。一方、本番運用や機密データを扱う環境、監査要件のある現場には向かない。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 61 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Open-Interfaceが埋める「APIのないGUI」という空白
多くの自動化ツールは、対象アプリがAPIやCLIを公開していることを前提にする。だが業務ソフトの多くはGUIしか持たない。Open-Interfaceはこの空白を、画面のスクリーンショットをLLMに読ませ、次に押すべきキーやクリック位置を推論させることで埋めようとする。READMEには「Self-drives your computer by sending your requests to an LLM backend (GPT-4o, Gemini, etc) to figure out the required steps」とあり、対象はmacOS、Linux、Windowsの3環境。利用者は、Pythonを書かずに自然言語の指示だけでPC操作を任せたい人、あるいはRPAツールのセレクタ管理に疲れた人になる。
推論ループの構造：指示、スクリーンショット、実行、再評価
仕組みは3段階のループとしてREADMEに記されている。第一に、利用者のリクエストをLLMバックエンドへ送り、必要な手順を判断させる。第二に、その手順をキーボードとマウスの入力シミュレーションで実行する。第三に、進捗のスクリーンショットを再びLLMへ送り、軌道修正する。この「Course-corrects by sending the LLM backend updated screenshots of the progress as needed」という設計が、固定シナリオ型の自動化との決定的な違いだ。セレクタや座標を事前に定義せず、画面の見た目そのものを状態として扱う。裏を返せば、各ステップで画像を送るため、API呼び出し回数とレイテンシが操作の複雑さに比例して増える。
バイナリで入れるか、Python 3.12で走らせるか
導入経路は2つある。配布バイナリを使う場合、macOSは最新リリースのバイナリをダウンロードして解凍し、Applicationsフォルダへ移動する。Apple Silicon機ではアクセシビリティと画面収録の許可を求められ、拒否した場合はSystem SettingsのPrivacy and Securityから手動で追加する。Intel Macでは「Open Interface cannot be opened」が出ることがあり、その場合はCancelを押したうえでSystem PreferencesのSecurity and PrivacyからOpen Anywayを選ぶ。Windows版はWindows 10で、Linux版はUbuntu 20.04でテスト済みとREADMEに明記されている。スクリプトとして動かす場合はPython 3.12以降を用意し、git clone https://github.com/AmberSahdev/Open-Interface で取得する。いずれの経路でも、LLM接続のためにSetupセクションでOpenAI GPT-4Vなどのバックエンドを設定する必要がある。
見えないコスト：画像トークン、レイテンシ、権限の広さ
最大の制約は、操作のたびにスクリーンショットをLLMへ送る点にある。テキストのみの自動化と比べて入力トークンが大きく、長いタスクではAPI費用が読めない。READMEはレイテンシやトークン量の数値を示していないため、実際の負荷は自分の環境で測るしかない。次に権限。macOSではアクセシビリティと画面収録を許可する必要があり、これは事実上、画面上のあらゆる情報と入力操作をツールに委ねることを意味する。パスワード入力や個人情報を含む画面を扱う場面では、そのまま使うべきではない。加えて、READMEに記載されたテスト環境はWindows 10とUbuntu 20.04であり、それ以外のディストリビューションや新しいOSでの挙動は保証されていない。
RPAやスクリプト自動化との分岐点
比較対象として素直なのは、SeleniumやPlaywrightのようなブラウザ自動化、あるいはUI Automation系のRPAだ。これらは要素の識別子や座標をコードに固定するため、実行は速く、再現性も高い。代わりに、画面レイアウトが変わればセレクタを書き直す必要がある。Open-Interfaceは逆のトレードオフを選ぶ。画面の見た目を毎回LLMに解釈させるのでレイアウト変更に比較的強いが、実行速度と決定性を犠牲にする。同じ操作を毎日同じ順序で回す定型業務なら、RPAやスクリプトのほうが適している。逆に、対象アプリが頻繁に更新される、あるいは操作手順を事前に書き下せない探索的なタスクでは、この方式に意味が出る。
GPL-3.0であることの実務的な意味
ライセンスはGPL-3.0。社内でそのまま使う分には問題が起きにくいが、改変して配布する場合や、自社製品に組み込んで提供する場合は、ソースコードの開示条件が及ぶ可能性がある。ここで注意したいのは、Open-InterfaceがLLMバックエンドへ接続する設計だという点だ。GPL-3.0はネットワーク越しの利用そのものに開示義務を課すライセンスではないが、配布の形態によって判断が変わる。法務判断が必要な領域であり、本記事は法的助言を与えるものではない。導入前に、自社のライセンスポリシーと照合することを勧める。
メンテナンスとアップグレードの見取り図
リリースはv0.9.0が2025年3月、v0.8.0が2025年1月、0.7.0が2024年12月と、短い間隔で続いている。ただし0.x系であり、APIや設定項目が今後変わる前提で見ておくべきだ。バージョンを上げる際は、リリースノートでSetupセクションの接続設定に変更がないかを確認する。バイナリ配布の場合、macOSでは毎回アクセシビリティと画面収録の許可状態を確認する必要がある。スクリプト運用ならPython 3.12以降の要件を満たしているかを都度チェックする。LLM側のモデル名やエンドポイントは外部要因で変わるため、動かなくなったときはまずバックエンド設定を疑うのが順序として早い。
編集部の結論
Open-Interfaceは、GUIしか持たない業務アプリの操作をLLMに代行させたい個人や小規模チームに向く。一方、本番運用や機密データを扱う環境、監査要件のある現場には向かない。導入前に確認すべきは、macOSならアクセシビリティと画面収録の許可、WindowsならWindows 10での動作実績、そしてGPL-3.0の下で社内配布や改変がどう扱われるかである。
コミュニティノート