agent-desktopとは​──画面の​構造を​読んで​アプリを​操作する​AIツール

agent-desktopは、AIエージェントからパソコンのアプリを操作するためのオープンソースのツールです。画面上のボタンや入力欄をOSから読み取り、選んだ対象に操作を実行します。macOS、Windows、Linuxに対応し、コマンドを呼び出せる既存のエージェントから利用できます。^[1]

特徴は、アプリが持つ「画面の構造」を操作の手掛かりにすること。 読み取りに使うのは、読み上げ機能などを支えるアクセシビリティ情報です。本記事では、何を操作できるのか、仕組み、複数エージェントのカーソル、業務での使いどころ、導入条件を紹介します。

2026年11月2日時点の公式資料を確認しました。直近のv1.0.2は日本時間10月31日に公開され、Vercel Labsへの移管が更新内容に含まれています。以前から開発されてきたプロジェクトであり、今回がツール自体の初公開ではありません。以下の説明は公式資料に基づくもので、CAGによる実行速度や操作精度の実測は含みません。^[2]

コーディングエージェントは、プログラムを書くだけでなく、ファイルを読み、コマンドを実行できます。agent-desktopを組み合わせると、その作業経路をデスクトップのアプリまで広げられます。たとえば、開いているウィンドウを調べる、入力欄に文字を入れる、ボタンを押す、といった操作です。^[1]

agent-desktop自体に、依頼を理解するAIモデルは組み込まれていません。何をするかは呼び出し元のエージェントが考え、画面を読むことと操作することをツールが担います。 CLIは、文字のコマンドでソフトを動かす仕組みです。エージェントがCLIを呼べる環境なら、特定のAI製品専用の連携を前提にせず組み込めます。アプリへの埋め込み向けにはC言語から呼ぶライブラリも用意されています。^[1]

これは利用場面を説明するための例です。対象アプリが必要な構造や操作をOSへ公開していることが前提になり、どのアプリでも同じように動くという意味ではありません。

アクセシビリティツリーとは、画面を「ウィンドウの中にフォームがあり、その中に入力欄とボタンがある」という親子関係で表したものです。名前、役割、状態などを読み取れるので、画像の中の見た目だけからクリック位置を決める場合とは、対象の探し方が変わります。^[1]

基本の流れは、読む、対象を指定して操作する、もう一度読む。 最初の読み取りをsnapshotと呼び、ツールは結果をJSONという構造化されたテキストで返します。エージェントが操作できる要素にはrefという参照番号が付きます。押したいボタンのrefを渡すことで、対象を指定できます。^[1][3]

refには取得したsnapshotを識別する情報も含まれます。画面が更新されて対象を確定できなくなった場合は、古い指定を使い続けず、取り直して選びます。公式仕様では、参照が古い場合のSTALE_REFや、対象が一つに定まらない場合のAMBIGUOUS_TARGETといったエラーを返す設計です。操作要求が受け付けられたことと、業務上の完了は分けて考える必要があります。^[3]

通常は、アクセシビリティAPIを通じて、ボタンを押す、値を設定するといった意味のある操作を行います。初期設定では、実際のマウスポインターの移動、疑似的なキー入力、クリップボード利用、アプリを前面へ出す操作を暗黙には行いません。物理的な入力を許す場合は、--headedという明示的な指定を使います。^[3]

スクリーンショットを取得する機能もあります。したがって、画像を一切扱わないツールではありません。構造から読める情報と、画像で確認したい情報を、呼び出し元のエージェント側で使い分ける形です。

複数のエージェントが動くとき、「いま誰がどこを操作しているのか」を見失いやすくなります。agent-desktopには、エージェントごとにラベル付きのカーソルを表示する仕組みがあります。各エージェントに識別子を割り当て、同じセッション内で動きを見分けます。^[3][4]

このカーソルは、操作先を見せるための表示です。 OSのマウスポインターを増やす機能ではありません。クリック時には効果を表示できますが、見た目のカーソルと実際に入力を届ける仕組みは区別されています。共有する物理入力は、順番を管理して実行します。^[3]

たとえば、片方が資料を調べ、もう片方が入力内容を組み立てる、という役割分担は考えられます。ただし、同じアプリの同じ入力欄を同時に更新するような競合まで、カーソル表示が解決してくれるわけではありません。作業対象の分担は、エージェントをまとめる側で設計します。

分かりやすいのは、資料を読んで別のアプリへ入力する作業です。たとえば、請求書の内容から、業務ソフトの下書きを準備する流れが考えられます。エージェントが資料から項目を整理し、ツールが入力欄を取得して値を入れ、最後に人が原本と照らし合わせる、という分担です。

最初の利用範囲は「確認できる下書き」までにすると、結果を点検しやすくなります。 保存された値を読み戻す、合計を照合する、送信前の画面で止めるなど、何をもって完了とするかも先に決められます。これは業務への組み込み方の例であり、CAGが特定の会計ソフトで動作を確認した事例ではありません。

外部サービスとデータを直接やり取りするAPIが整っている場合は、その連携も選択肢です。デスクトップ操作は、画面で行う必要がある工程をエージェントにつなぐ手段として考えると位置付けが明確になります。業務全体のうち、どの工程に画面操作が残るのかを切り出すところから始められます。

公式の導入方法には、npmというソフトウェア配布の仕組みからCLIを入れる手順が案内されています。ただし、導入してコマンドを呼べることと、目的のアプリを操作できることは別の確認です。2026年11月2日時点で、OSごとの主な前提は次のとおりです。^[5]

AT-SPIは、Linuxでアプリのアクセシビリティ情報へアクセスする仕組みです。「Linux対応」という表示だけで、すべてのデスクトップ環境に同じ機能がそろうと考えない方がよいでしょう。たとえば、前述の表示用カーソルはX11向けで、Waylandには対応していません。^[3][5]

対象アプリが構造を十分に公開していない場合、ボタンの名前や入力欄を取得できないことがあります。画像や独自描画が中心の画面も、構造を読む方法だけで扱えるとは限りません。最初に実際の対象画面を読み取り、必要な要素が取得できるかを確かめます。^[6]

もう一つは、取得した情報の行き先です。画面の構造やウィンドウ名にも、顧客名や作業中の文書名が含まれることがあります。ネイティブCLI自体に遠隔のAIサービスは必須ではありませんが、呼び出し元のエージェントが得た情報をどこへ送るかは、そのエージェントと利用モデルの設定によります。^[6]

導入時は、次の項目を対象業務に合わせて確認すると、試す範囲が決まります。

• 操作したい画面のボタンや入力欄を取得できるか。
• OSの権限と、必要な入力方法がそろっているか。
• 他のエージェントや人の作業と、更新先が重ならないか。
• 取得する業務データと、AIへ渡してよい範囲が一致しているか。
• 下書き、確認、送信のどこまでを任せ、何を読み戻して完了とするか。

agent-desktopは、既存のエージェントとデスクトップのアプリをつなぐための選択肢です。まず一つの入力画面で、読む、入力する、読み戻すという小さな工程を確かめると、自社の仕事に使える範囲が見えてきます。