注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。
3行要約
- 自然言語のプロンプトをmacOS上のマウス移動・クリック・キー入力に変換し、GUI操作を自動化するツール
- 既存のRPAやAppleScriptのような複雑なコード記述を排除し、視覚的な認識と推論で「人間のように」操作する
- 定型業務を自動化したいMacユーザーには最適だが、精度とレイテンシの観点からミッションクリティカルな用途には不向き
結論から: このツールは「買い」か
結論から言えば、Openclickは「Macでのルーチンワークをプログラミングなしで自動化したい中級以上のユーザー」にとって、非常に価値のある投資になります。★評価は4.0です。
GUI自動化において、最大の障壁は「要素の特定」でした。従来のセレクタ指定(XPathやIDなど)は、アプリのアップデートで簡単に壊れます。Openclickはこの問題をLLM(主にGPT-4oやClaude 3.5 SonnetのVision機能)による画面認識で解決しています。ただし、1アクションごとに数秒の推論時間がかかるため、リアルタイム性を求める操作には使えません。また、セキュリティ権限を広範囲に許可する必要があるため、企業ポリシーが厳しい環境では導入ハードルが高いでしょう。それでも、APIが提供されていない古いデスクトップアプリを無理やり自動化できるパワーは、エンジニアにとって大きな武器になります。
このツールが解決する問題
従来、デスクトップアプリの自動化は「苦行」でした。WebであればSeleniumやPlaywrightがありますが、ネイティブアプリ(Slack、Zoom、独自の業務ソフトなど)を操作するには、AppleScriptを組むか、座標指定の泥臭いPythonスクリプトを書くしかありませんでした。
特にSIer時代の経験から言えるのは、商用RPAツールは導入コストが高く、かつ独自のスクリプト言語を覚える学習コストが無視できない点です。結局、簡単な作業でもエンジニアが数日かけて実装することになり、投資対効果が見合わないケースが多々ありました。
Openclickは、この「APIがない、あるいはAPIを叩くのが面倒なアプリの操作」を、プロンプトひとつで解決します。「Slackの未読を確認して、特定のチャンネルに『確認しました』と返信して」という曖昧な指示を、実際の画面上の座標にマッピングして実行できる点が画期的です。要素の座標が変わっても、LLMが視覚的に再認識するため、メンテナンスコストが劇的に下がります。
実際の使い方
インストール
OpenclickはmacOS専用のエージェントです。Python環境でのライブラリ利用、またはスタンドアロンのアプリとして動作します。ここでは、エンジニアがカスタマイズしやすいCLI/Python経由での導入を想定します。
# Python 3.10以上が推奨
pip install openclick-agent
# 初回起動時にアクセシビリティ(画面記録・システム操作)の許可が求められます
openclick setup
macOSの「システム設定 > プライバシーとセキュリティ」にて、ターミナル(またはIDE)に対して「アクセシビリティ」と「画面収録」の権限を許可する必要があります。これを忘れると、ツールが画面を読み取れず、マウスを動かすこともできません。
基本的な使用例
公式のインターフェースに基づいた、基本的な自動化スクリプトの例です。
from openclick import OpenClickAgent
# エージェントの初期化(GPT-4oなどのVisionモデルを使用)
agent = OpenClickAgent(model="gpt-4o", api_key="YOUR_OPENAI_API_KEY")
# 画面上の操作を指示
# 指示内容は具体的であるほど精度が上がります
task = "ブラウザを開いて、Googleドキュメントの新しいファイルを作成し、タイトルに『週次レポート』と入力してください"
# 実行
# エージェントは現在のスクリーンショットを撮り、座標を計算して操作を繰り返します
result = agent.run(task)
if result.success:
print(f"完了しました: {result.message}")
else:
print(f"エラー発生: {result.error_details}")
このコードの肝は、エージェントが「現在の画面状態」をループで確認しながら進む点です。もし途中でポップアップが出ても、LLMがそれを認識して「閉じるボタンをクリックする」といった判断を自動で行います。
応用: 実務で使うなら
実務で最も役立つのは、複数のアプリをまたぐワークフローの構築です。例えば、Excelのデータを読み取り、自社の古い業務システム(GUI版)に一行ずつ入力していく作業などです。
import pandas as pd
from openclick import OpenClickAgent
df = pd.read_csv("input_data.csv")
agent = OpenClickAgent(model="claude-3-5-sonnet")
for index, row in df.iterrows():
# 既存の入力フォームをリセットし、新しいデータを入力するプロンプト
prompt = f"入力フォームの『顧客名』に {row['name']} を、『金額』に {row['amount']} を入力して保存ボタンを押して"
agent.run(prompt)
# 1件ごとに画面の更新を待機するスリープを入れるのがコツ
# LLMの推論時間(2〜5秒)が自然なウェイトになります
このような「バッチ処理的なGUI操作」は、従来のRPAではエラー処理に多大な時間がかかっていましたが、Openclickなら「失敗したらリトライ」というロジックをLLM側で完結させられる可能性があります。
強みと弱み
強み:
- 座標指定が不要: 画面解像度やウィンドウ位置を気にせず、ボタンの名前や見た目で指示できるため、スクリプトの堅牢性が高い。
- マルチモーダル推論: テキストだけでなく、アイコンの意味(ゴミ箱、設定ギアなど)を理解して操作できる。
- セットアップが迅速: インストールから最初の動作確認まで、OpenAIのキーがあれば5分もかからない。
弱み:
- 推論コスト: 1アクションごとにVisionモデルのトークンを消費するため、数千件の連続操作をするとAPI料金が膨らむ(1件0.1ドル程度かかる場合もある)。
- プライバシー懸念: 画面全体のスクリーンショットをクラウドのLLMに送信するため、機密情報を扱う際はローカルLLM(Llava等)との連携が必須(ただし精度は落ちる)。
- 日本語対応の壁: macOSのシステム言語が英語でない場合、ボタン名の認識で稀にミスが発生する。
代替ツールとの比較
| 項目 | Openclick | Claude Computer Use | Open Interpreter |
|---|---|---|---|
| 主な形態 | macOSエージェント | API/Docker | CLI/Python |
| 操作対象 | GUI全般 | GUI全般 | OS/CLI/コード実行 |
| 設定難易度 | 低(導入が容易) | 高(Docker環境推奨) | 中(Python知識が必要) |
| 特徴 | macOS特化のUI | モデル純正の機能 | コード実行に強い |
Openclickは「Macユーザーが手軽にGUI自動化を始める」ことに特化しています。一方で、より高度なプログラム実行を含めた自動化ならOpen Interpreter、エンジニアが基盤から構築するならAnthropicのComputer Use APIが適しています。
私の評価
星5つ中の4つ(★★★★☆)です。
実務経験上、GUI自動化は「8割は簡単だが、残りの2割の例外処理で死ぬ」領域でした。Openclickはこの2割の例外処理(突然の通知、位置の微増、ボタンの色の変化)をLLMの「眼」で解決しようとしています。これはエンジニアにとって、AppleScriptのデバッグから解放されることを意味します。
ただし、RTX 4090を2枚積んでローカルLLMを回している身としては、すべての画面情報をクラウドに投げる設計には慎重になります。また、推論のレイテンシにより、クリックのタイミングがズレて誤操作を招くリスクもゼロではありません。したがって、本番環境のクリティカルなDB操作などを任せるのではなく、「面倒なレポート作成の補助」や「定型的なデータ転記」といった、失敗してもやり直しが効く範囲から導入するのが賢明です。macOSのアクセシビリティ機能をこれほど直感的に扱えるツールは貴重であり、試す価値は十分にあります。
よくある質問
Q1: 操作中に自分でマウスを動かしても大丈夫ですか?
推奨されません。エージェントがスクリーンショットを撮った時点の座標と、実行時の座標がズレるためです。実行中は専用の仮想デスクトップ(操作スペース)を割り当て、そちらでエージェントを走らせるのが実務的な運用です。
Q2: 実行にかかるコスト(API料金)はどのくらいですか?
使用するモデルによりますが、1ステップ(認識+クリック)で数円〜十数円程度です。複雑なタスクで30ステップ踏めば数百円かかります。毎日数時間回すような用途では、API経由よりも自前でモデルをホストする構成を検討すべきです。
Q3: 日本語のアプリでも正確にボタンを認識できますか?
GPT-4oやClaude 3.5 Sonnetを使っている限り、日本語の認識精度は非常に高いです。ただし、「保存」と「上書き保存」など似た選択肢がある場合、プロンプトで「青色の保存ボタン」のように視覚的特徴を添えると確実性が増します。






