本記事では、2024/10/23 から Claude 3.5 Sonnet で使えるようになった「computer use」の実用的な使い方を紹介します (Anthropic のリリースノート)。本機能は端的にはコンピューターが操作できる能力 (※) なのですが、ユースケースを考えてみると API を呼んだ方が早かったりして具体的な使い道が意外とないかも ? と感じている方もいるのではないかと思います (私はそうでした)。いくつか実験をする中で有用そうなユースケースを見つけられたのでご紹介したいと思います。

※ LLM は決定的な入出力を行わないため、「機能 (function)」と表現するのに違和感があったため「能力 (capability)」の語を使っています

computer use とは

コンピューターの画面と指示から、操作するのに必要な入力を返すことが出来る能力です。例えば「ブラウザを起動して」というプロンプトと画面画像を Claude に与えると、アイコンの位置を特定してクリックするための座標を返してくれます。あとは GUI 操作のツールさえあればコンピューターを操作できます。

下図は、実際に画面とプロンプトを Claude へ入力し、座標を得ているところです。

computer use が使えると何がうれしいのか、というと LLM が扱える tool が実質コンピューターで行える操作すべてになったことです。Claude を含めた最近の LLM は「tool use」と呼ばれる与えられたツールを必要に応じ呼び出す能力があります。例えば、お買い物ボットに「100 円のリンゴと 300 円のリンゴを買ったら合計いくら ?」と聞くとき決定的な出力が苦手な LLM に計算を任せるより普通に電卓で計算した方が正確です。この時、電卓というツールの定義を与えることで返答する際にツールを使い正確な計算をさせることが出来ます。

tool use ではプロンプトで与えられたタスクを解く計画を作成し (Reasoning) 、その中でツールの実行が必要であればツールを実行 ( ※実行には実行環境が必要 ) 、受け取った結果を基に最終的な出力を作成します。

今回、computer use により上図の "environment" に普通のコンピューターが使えるようになったことから、手元のパソコンで行えることは理論上なんでも tool として使えるようになったのが大きな進化のポイントになります。

computer use の制限

公式ブログによれば、まだドラッグやズームといった操作は不得手であると言及されています。また、誤ってアプリケーションを操作して動作が止まることもあります。computer use の性能は OSWorld というベンチマークで計測されており、執筆時点で Claude Sonnet はスクリーンショットのみをヒントとして与える設定で成功率が最高性能であるものの、その値は 22% で人間が行った場合の 72% ほどと 3 倍以上差があります。

精度以外に、コストの問題もあります。computer use では複数枚のスクリーンショットをコンテキストとして与える必要があり非常にトークン数がかさみます。時間当たりのリクエスト可能な回数やトークン数には制限があり、computer use はそれを消費しやすい、つまり途中で止まりやすい用途です。コストと安定性を考えるとまだ途上のユースケースになると思います。

computer use に適したユースケース

computer use は、「扱うツール」と「扱うデータ」により特徴づけられることになります。いくつか使い分けて実験をしてみました。

画面・カメラの定期監視

「ブラウザ」を使って「動画」を要約するユースケースです。ブラウザを操作して指定した地域のウェブカメラにアクセスし、映っている状況を要約してもらっています。これが一番有効だと感じました。

以下のような出力が得られます。驚いたのは、日本の各地の固有名称を認識している点です。

日本の主要都市夜間状況レポート
報告日時：2024年11月10日
■ 札幌
天候：夜間、晴れ
都市の様子：夜景が美しく映し出されており、大通公園周辺の街路樹のイルミネーションが確認できます。交通の流れは平常通りで、目立った混雑は見られません。
治安状況：カメラに映る範囲内で暴力的行為やトラブルは確認されません。
■ 東京（レインボーブリッジ周辺）
天候：夜間、晴れ
都市の様子：レインボーブリッジがブルーにライトアップされ、港区周辺の夜景が美しく映っています。湾岸エリアの交通も円滑に流れています。
治安状況：カメラに映る範囲内で暴力的行為やトラブルは確認されません。
■ 大阪
天候：夜間、晴れ
都市の様子：市街地の明かりが広範囲に広がり、主要道路の車両の流れも確認できます。繁華街エリアでは通常の夜の賑わいが見られます。
治安状況：カメラに映る範囲内で暴力的行為やトラブルは確認されません。

動画の監視は人手がかかる業務で、生成 AI による効率化はすでに道路状況監視や災害監視に利用されています。そのため、ウェブカメラを参照できる Web 画面に定期的にアクセスしてサマリを作成する、時にはカメラをコントロールしてズームをするといったオペレーションは現実的かつニーズがあると感じています。

また、ゲームの画面テストなどにも使える可能性があります。キャラクターの表示やエフェクトの違和感などコードではテストできないビジュアルの検査に、このユースケースがはまるかもしれません。

(難点あり) データの読み取りと転記

「ブラウザ」を使って「数値データ」を取得するユースケースです。これは正直 (正しいマナーの元) スクレイピングをした方が効率的と思いました。動的なページもあると思いますが、間違えることが出来ない数字データを取得するには動作がまだ不安定な computer use は向いていないと感じます。↓も一見うまく取れているように見えますがデータは間違っています。

「数値データ」ではなく、レビューコメントや何らかのアナウンスの文言などであれば使えると思いますが、それもスクレイピングの方が効率的と思います。 "HTML" を読めば取得できるデータは HTML が正確に読める技術を使った方が良い印象です。先ほどの画像・動画は HTML を読んでも理解できない点が異なります。

(難点あり) 検索の実行と要約

「ブラウザ」を使って「テキストデータ」を取得するユースケースです。前述の通り、これは検索 API を使った方が良い印象です。最近は検索結果がカードで表示される場合がありその情報を取るのに向いていると思いきや、画面に記載されている内容を読み取らず「モデルが知っている知識」を記載する挙動を観測しています。次の動画では、ドラゴンボールのキャラクターを検索してスプレッドシートにまとめてもらっていますが、記載されている概要は検索結果とは異なるものです (なぜか検索トップのブルマも書いていないので名前も生成している可能性がある)。

「テキストデータ」を取得するケースは、テキストが LLM からではなくコンピューター画面から取得することを強制する必要がありそうです。

(おまけ) 図表を描画する

使っているツールがブラウザばっかりじゃん！と思われるのではないでしょうか。実際のところブラウザ以外のツールで何をさせたほうがいいのかあまり思いついていないのが現状です。ためしにドラゴンボールの悟空を検索して模写してもらいましたが、ちょっと人間には理解しがたい結果になりました。現在 drag が苦手ともされていたので、お絵かきは基本苦手なのかなという印象です。

computer use の可能性

全体として、computer use はエンドユーザー向けの機能と感じています。開発者がコード書いて～、 API 叩いて～、と便利なツールを作るのと同様、エンドユーザーの方が手元のコンピューターさえあれば便利なツールが作れるようになる機能、ということです。生成 AI により、自然言語さえ扱えれば「プログラミング言語」が扱える人と同様に複雑なタスクができるようになるというイメージです。逆にブラウザを使いたいならヘッドレスブラウザをコードから呼び出す、PPT/Excel なら専用のライブラリをつかって作成する、と考えられる人の方を向いた機能ではないかなと。

将来的に、computer use が "computer" の枠を超え、私たちが目にしているものを理解し操作できるようになると思います。その時はロボットへの搭載になると思いますが、搭載に当たりモデルの小型化、推論の高速化と高頻度か、そしてコストダウンが課題になると思います。

今後のモデルの進化に期待です！