AIエージェントに隔離したパソコンを渡して操作させるOSS「Cua」を解説

AIエージェントに隔離したパソコンを渡して操作させるOSS「Cua」を解説

「AIエージェントに画面を見せて、表計算や社内システムの操作まで任せられるらしい。業務の効率化に使えないか」「でも、AIが勝手に送信や削除をしたら誰が止めるのか。承認の仕組みがあれば大丈夫なのか」——パソコン操作を任せるAIエージェントの検討を始めた企業の、情報システム部門からよく出てくる声です。検討の中心は「どこまで自動化できるか」に置かれがちですが、本当の論点はそこではありません。本当は、AIに貸し出すパソコンと権限と鍵の範囲を、人が先に決めて閉じ込めておけるかです。この記事では、AIエージェントにパソコン操作の手段と隔離した仮想のパソコンを与える基盤「Cua」について、一次情報で確かめられる構成、OSSでないアプリ部分との書き分け、公開されたセキュリティ勧告の中身、企業が先に決めておくことを、守る側の目線で整理します。導入や操作の手順は扱いません。


カメ先生カメ先生

パソコン操作を任せるAIは、人の代わりにマウスとキーボードを動かす便利な道具だと思われがちなんだ。でも本当は、そのパソコンにある画面・ログイン状態・鍵をまるごとAIに預けることなんだよ。


カメ子カメ子

便利さの裏で、預ける範囲がとても広くなる、ということですか。


カメ先生カメ先生

そう。だから Cua のような基盤は、仮想のパソコンで隔離したり、危ない操作の前に人の承認を挟んだりする部品を用意している。ただ、その承認や隔離の部品自体に弱いところが見つかった、というのが今回の勧告なんだ。


カメ子カメ子

守りの部品も点検の対象として見る必要がある、ということですね。


この記事のポイント
  • Cua は、AIエージェントに画面のアプリ操作の手段、仮想のパソコン、評価の仕組みを与える基盤。中心部分はMITライセンスのOSSで、アプリ「Cua Spaces」はOSSではないFSLで公開されている
  • 2026年10月に、人の承認を偽装されうる問題やAPIキーが漏れうる問題など4件の勧告が公開された。勧告ごとに修正版が示されているが、旧来の部品は保守が終わっている
  • AIに判断させず、承認と権限と鍵の範囲を人が先に決める。修正版にしても安全の保証にはならない

AIの導入・活用、何から始めるべきかお悩みですか?

デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。

目次

Cuaとは何か。2026年10月時点で確かめられる事実

Cua は、GitHub上で公開されている、AIエージェントにパソコンを使わせるための基盤です。READMEは自らを「AIエージェントに、使えるコンピューターを与える」ものと説明しています。一つのリポジトリの中に、画面のアプリを操作する部品、仮想のパソコンを作る部品、開発用の道具、評価の仕組み、小さな判断用のモデル、そしてデスクトップ用のアプリが同居しているのが特徴です。

規模と経緯も押さえておきます。リポジトリは2025年1月31日に作られ、2026年10月21日時点でスターはおよそ30,400、複製(フォーク)はおよそ2,200です。最終の更新は2026年10月20日で、開発は活発に続いています。運営するのは組織のアカウントで、2024年12月に作られ、公開しているリポジトリは46あります。公式サイトは cua.ai です。

ライセンスは、リポジトリの大部分がMITです。ただし後の見出しで詳しく扱うとおり、デスクトップ用のアプリ「Cua Spaces」などはOSI(オープンソースの定義を管理する団体)が承認していないFSLというライセンスで公開されています。この記事では、MITの中心部分を指して「OSS」と呼び、アプリ部分とは書き分けます。

AIに「パソコン操作」を任せるとはどういうことか

これまでのAIエージェントの多くは、文章を作ったり、決められた仕組み(API、つまり他の仕組みを呼び出すための窓口)を呼び出したりするところまでを担ってきました。パソコン操作を任せる型のAIエージェントは、そこから一歩進んで、人と同じように画面を見て、ボタンを押し、文字を打ち込みます。窓口の用意されていない古い社内システムや、ブラウザでしか使えない業務の画面も対象になりうる点が、注目される理由です。

READMEは、同じ作業の中でAIエージェントがプログラム、API、画面の操作を行き来する姿を「Computer-Use 2.0」と呼んでいます。言い換えると、AIが触れられる範囲が、画面に映るものすべてに広がるということです。画面に出ている社外秘の情報、ログインしたままのブラウザ、送信ボタンも、AIの手の届く範囲に入ります。

だからこそ、この種の基盤では「AIにどのパソコンを渡すか」「そのパソコンで何をさせてよいか」「危ない操作の前に誰が止めるか」が中心の論点になります。便利さの大きさと、預ける範囲の広さは表裏一体です。Cua が仮想のパソコンや承認の仕組みを用意しているのも、この問題に向き合うためだと読み取れます。

構成要素1:画面のアプリを操作する Cua Driver

READMEによると、Cua Driver は、macOS・Windows・Linux の上で動くアプリやブラウザを、AIエージェントが調べたり操作したりするための道具です。AIエージェントとは、命令を打ち込んで使う道具、MCP(AIと外部の道具をつなぐ共通の取り決め)、各言語の部品のいずれかでつながります。公式の文書では、AIの頭脳にあたる部分はあくまで利用者が用意するもので、Cua Driver はAIが提案した一歩一歩を実際の画面上の観察や操作に変える「手足」の役割だと説明されています。

守る側として注目したいのは、権限の扱いです。公式の文書によると、macOS では画面の読み取りや操作に必要なOSの許可が Cua Driver のアプリそのものに与えられます。また、どの範囲で動かすか、どのアプリを触ってよいかといった許可は起動のときに決まり、AIエージェントの側からは広げられない作りだとされています。外部から呼び出すための通信の窓口は既定で閉じており、開く場合は長い合言葉(トークン)が必要とも書かれています。

一方で、利用者の操作を邪魔しないよう、画面の裏側で操作を届ける仕組みもあります。人が気づかないうちにAIが操作を進められるということでもあるため、操作の記録を残し、人が後から確かめられるようにすることが、使う側の責任として重くなります。

構成要素2:仮想のパソコンを作る Lume、開発用の道具、評価の仕組み

Lume は、Apple の機械(Apple シリコンを積んだ Mac)の上で、macOS や Linux の仮想のパソコン(仮想マシン)を作って管理する道具です。READMEによると、Apple が用意している仮想化の仕組みを使います。AIエージェントに、利用者の普段のパソコンではなく、使い捨てにできる別のパソコンを渡すための部品と位置づけられます。

開発用の道具と命令の窓口(SDKとCLI)は、手元や自社の機械の上に「砂場」(サンドボックス、外に影響が出にくい隔離した実行環境)を用意するためのものです。READMEでは、Python・TypeScript・Rust 向けの部品が公開済みで、自社の機械を中継の仕組み(リレー)を通してつなぐ機能もあるとされています。この中継には、運営元が自ら運用するサービスも関わることが、セキュリティの方針の文書から読み取れます。

隔離は強力な守りですが、隔離した仮想のパソコンに何を持ち込むかで効果は大きく変わります。社内システムへのログイン状態や鍵を持ち込めば、隔離されているのはパソコンだけで、権限は外につながったままという状態になります。隔離の部品があることと、隔離が効いていることは別の話です。

構成要素3:アプリ「Cua Spaces」はOSSではない

リポジトリの入口で最も大きく案内されているのが、デスクトップ用のアプリ「Cua Spaces」です。READMEによると、AIエージェントに一つずつ丸ごとのデスクトップ(Space)を与え、自分の Mac、自分の持つ別の機械、または自社のクラウドの契約(AWS・Google Cloud・Modal)の上で動かせます。macOS 26 以降が対象で、個人は無料、上位の契約は月18ドル、チーム向けは1人あたり月30ドルとされています。

ここで書き分けが必要なのは、Cua Spaces のライセンスがFSL-1.1-MITである点です。FSLは、ソースを公開しつつ、一定期間は競合する商用の利用を制限するライセンスで、各版は公開から2年後にMITへ移ると説明されています。OSIの承認ライセンスではないため、この記事では Cua Spaces を「OSS」とは呼びません。READMEは評価用の部品の一部(Cua Driver Bench)も同じライセンスだとしています。

READMEは、MITの部分がFSLの部分に依存することはないと明記しています。また、追加で入れられる一部の部品はAGPL-3.0という、ネットワーク越しに提供する場合にも元のソースの公開を求めうるライセンスだとされ、公式の文書もAGPLを受け入れない組織はその部品を使わないよう案内しています。部品ごとにライセンスが違うため、主な部分を表に整理します。

部品役割(READMEの説明)ライセンス
「Cua Driver」macOS・Windows・Linux のアプリやブラウザを調べ、操作するMIT
「Lume」Apple の機械の上に macOS・Linux の仮想のパソコンを作るMIT
開発用の部品と命令の窓口手元や自社の機械に隔離した実行環境を用意するMIT
「CUA-S1」画面操作の判断に特化した小さなモデル(研究段階)ソースはMIT。モデルと学習データは個別の条件
「Cua Bench」課題を作り、AIエージェントを評価し、操作の記録を書き出すMIT(一部の部品はFSL)
「Cua Spaces」AIエージェントに丸ごとのデスクトップを与えるアプリFSL-1.1-MIT(OSSではない)
画面認識の追加部品画面の要素を読み取る追加機能AGPL-3.0を含む

Cua Bench は、パソコン操作の課題を作り、AIエージェントを評価し、操作の記録を学習用に書き出すための仕組みです。READMEによると、仮想のパソコンやAIの利用の鍵がなくても、模擬の課題から始められるとされています。社内でパソコン操作型のAIを試すとき、本番の画面でいきなり試すのではなく、模擬の課題で失敗の傾向を先に見ておける点は、守りの面でも意味があります。

CUA-S1 は、画面操作の判断に特化した小さなモデルの群れで、最初の研究用の型は入力欄の多い画面(申込書のような画面)を対象にしているとされています。READMEでは、まだ早い段階の研究用の公開で、モデルの重みは Hugging Face に置かれていると説明されています。

注意したいのは、モデルや学習データについてはソースのMITとは別に、それぞれの説明書きに書かれた条件に従うとREADMEが明記している点です。業務で使う場合は、モデルの説明書きでライセンスと想定する用途を個別に確かめる必要があります。この記事では、モデルの性能については確認できた一次情報が限られるため扱いません。

想定される使い方と、企業で使う場面

READMEと公式の文書から読み取れる使い方は、大きく三つです。一つ目は、利用者がすでに使っているAIエージェント(開発支援のAIなど)に Cua Driver をつなぎ、手元のアプリを操作させる使い方です。二つ目は、Lume や Cua Spaces で用意した隔離したパソコンの中で、AIエージェントに作業させる使い方。三つ目は、Cua Bench で評価や学習用の記録を作る使い方です。

企業の場面に置き換えると、窓口の用意されていない社内システムへの入力作業、定型の画面確認、ソフトウェアの動作の確認などが候補になりそうです。ただし、これは一次情報に書かれた事例ではなく、機能から推測した使い道です。実際にどこまで安定して動くかは、確認できる情報が限られます。

どの使い方でも共通するのは、AIエージェントが人と同じ画面に触れるという点です。Cua Spaces には、人とAIが同じデスクトップをそれぞれのカーソルで操作し、人が途中で選択を引き取ってまた戻す機能もあると説明されています。人が途中で関われるのは利点ですが、どの場面で人が引き取るかを、使い始める前に決めておくことが前提になります。

安全性の評価:注意付きとした根拠

このラインでは、ソフトウェアを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Cua の判定は「注意付き」です。中心部分はMITで、運営の実績や開発の活発さに不自然な点は見当たりませんでした。

注意付きとした主な根拠は、2026年10月19日と20日に、合わせて4件のセキュリティ勧告が公開されたことです。内訳は、深刻度「高」が2件(人の承認の仕組みに認証がない問題と、開発用の画面からAPIの鍵が漏れうる問題)、「中」が1件、「低」が1件です。4件とも、勧告の中に修正された版が示されていて、修正版の公開もリリースの一覧などで確認できました。ただし後で述べるとおり、修正版の扱いには注意点が残ります。

このほか、案内されている導入方法の多くが、配布元の導入用の仕組みを取得してそのまま実行させる形式である点も、社内の導入の手順と照らして確認が必要です。なお、精査の範囲で、導入の際に自動で動く処理の記載は見つかりませんでした。とはいえ、問題が見つからなかったことは安全の保証ではありません。勧告が出たことも、裏を返せば報告と修正の仕組みが働いている表れであり、使う側の確認を省いてよい理由にはなりません。

勧告1:人の承認を偽装されうる問題

深刻度「高」の1件目は、cua-agent という部品に含まれる、人の承認を受け付ける仕組みに関するものです。この仕組みは、AIエージェントがファイルの削除、購入、メッセージの送信といった危ない操作をする前に、人が許可するかどうかを決めるために用意されています。勧告によると、0.9.0以前の版ではこの承認の窓口に認証がなく、同じネットワークや同じ機械の他の利用者から届く状態でした。

勧告が示す影響は二つです。保留中の承認の依頼とその文脈を第三者が読めること、そして人の代わりに第三者が承認の答えを送り、AIエージェントがそれを本物として受け入れてしまうことです。人が確認する前提で組んだ安全装置が、人の確認なしに通過されうるという意味で、影響は小さくありません。この記事では、具体的な再現の方法は扱いません。

勧告によると、0.9.1で、既定では自分の機械からしか届かない設定になり、すべての窓口で合言葉の確認が必須になりました。修正前の版については、共有の機械やネットワークにつながった機械で動かさない、または自分の機械からの接続だけを許す設定で守ることが回避策として示されています。承認の仕組みは「あるかどうか」だけでなく、承認の答えが本当に人から来たものかを確かめられるかまで見る必要がある、という教訓です。

勧告2:開発用の画面からAPIの鍵が漏れうる問題

深刻度「高」の2件目も cua-agent に関するもので、開発者がパソコン操作型のAIを試すための手元の画面(プレイグラウンド)の裏側の仕組みが対象です。勧告によると、0.9.0以前の版ではこの仕組みに認証がなく、どの外部のサイトからの呼び出しも受け入れる設定(CORS、ブラウザが他のサイトからの呼び出しを許すかどうかの決まり)になっていました。

勧告が示す影響は、開発者が悪意のあるウェブページを開いたり、同じネットワークに攻め手がいたりした場合に、開発者の言語モデル用のAPIの鍵が外部に送られうることと、攻め手が用意した応答をAIエージェントが自分の判断として扱いうることです。なお勧告は、確認された影響がパソコンの操作そのものの乗っ取りにまでは及ばなかったと記しています。

勧告によると、0.9.1で、既定では自分の機械からしか届かず、呼び出しを許すサイトを自分の機械と明示したものだけに絞る修正が入りました。修正前の版の回避策は、他の機械から届く状態で動かさないこと、動かしている間は信頼できないサイトを開かないことです。開発用の手元の画面は軽く扱われがちですが、開発者のパソコンには本番でも使える鍵が置かれていることが多いため、守りの対象から外せません。

勧告3と4:引き継ぐ範囲の食い違いと、許可の照合の甘さ

深刻度「中」の3件目は、Cua Spaces の「Teleport」に関するものです。Teleport は、ログインしたままのアプリ(たとえば Chrome や Slack)を隔離したデスクトップに移す機能で、ログイン状態は Mac の上の暗号化された保管庫(Keyvault)に置かれ、人が承認したときだけ移るとREADMEは説明しています。勧告によると、0.1.0の先行版から0.10.0までは、呼び出し側が一部の項目だけを選んでも、承認するとそのアプリについて保管されているもの全体が移りうる状態でした。

さらに、利用者に見える説明が狭い選択のままで、実際の依頼より狭い範囲に見えたまま承認してしまう恐れがあったこと、Linux では承認の画面に依頼の中身が示されなかったことも書かれています。勧告によると0.11.0で修正され、リリースの一覧でも0.11.0と、その後の0.12.0の公開を確認できました。承認の画面に出ている範囲と、実際に動く範囲が一致しているかは、承認の仕組み全般で確かめるべき点です。

深刻度「低」の4件目は、Cua Driver の Windows 向けの、触ってよいアプリを絞る仕組みに関するものです。勧告によると、0.37.0より前の版では、アプリの指定の一つの方法を使うと、同じファイル名の別のプログラムにも許可が当てはまりえました。勧告は0.37.0での修正と、それまでは別の指定の方法を使う回避策を示しています。ただし、リリースの一覧で確認できた0.37.0は先行版(プレリリース)の表示で、勧告の対象と同じものかどうかは確かめきれていません。

修正版の注意点:保守が終わった部品と、古い版への修正の扱い

深刻度「高」の2件が対象とする cua-agent は、PyPI(Python の部品の公開場所)で0.9.1が2026年10月19日に公開されていることを確認できました。一方で、同じページにはcua-agent はすでに保守が終わっており、今後の更新や修正は行われないと明記されています。代わりに、Cua Driver をMCPでつなぐ方法や、新しい開発用の部品へ移ることが案内されています。

つまり、0.9.1は勧告への修正を含む版ですが、今後新たな問題が見つかっても、この部品には修正が出ないと読めます。既存の版は公開されたままで、入れ済みの環境は動き続けるとも書かれているため、社内に古い部品が残っていても気づきにくい点に注意が要ります。READMEも、別の古い部品について既知の問題があるとして使用をやめるよう呼びかけています。

また、セキュリティの方針の文書によると、修正は各部品の最新の公開版にだけ入り、古い版へさかのぼった修正は行わないとされています。自社の機械で動かす場合は、最新版を使い続けることが前提になります。報告の窓口は GitHub の非公開の報告の仕組みで、受付の連絡は2営業日以内などの目安が示されていますが、方針の文書はこれらを保証ではなく目標としています。

悪用されうるリスク

パソコン操作を任せる基盤は、使い方を誤ると、それ自体が攻め手にとって都合のよい足場になりえます。今回の勧告に共通するのは、人の承認、APIの鍵、ログイン状態、触ってよいアプリの範囲という、守りの要となる部分に弱いところがあったことです。どれも、AIエージェントに預ける範囲を決める部品です。

推測を含めて想定すると、まず、画面に表示された文書やウェブページに紛れ込んだ命令にAIエージェントが従い、意図しない操作をする危険があります。これはパソコン操作型のAI全般に言えることで、Cua に固有の問題ではありません。次に、隔離したパソコンにログイン状態や鍵を持ち込んだ場合、そのパソコンでの誤操作や乗っ取りが、社内システムや社外のサービスにそのまま波及する可能性があります。

さらに、承認の仕組みを形だけ置いて安心してしまうことも、運用上の危険です。今回の勧告1のように承認の答えが偽装されうる状態や、勧告3のように承認の画面が実際の範囲を正しく示さない状態では、人が確認しているつもりでも確認になっていません。なお、許可のない他者のパソコンや仕組みにAIを向けて操作させる行為は、法律上の問題になりうることも社内で共有しておくべきです。

導入を検討するときに確かめること

Cua を社内で試すかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。ここでは手順ではなく、判断の順番を示します。

STEP1
使う部品と目的を決める

MITの部品だけを使うのか、FSLの Cua Spaces も使うのか、AGPLを含む追加部品を使うのかを分けて書き出します。部品ごとにライセンスと保守の状況が違うため、ここが最初の分かれ目です。

STEP2
保守の終わった部品を使わない

保守が終わったと明記された部品を候補から外し、社内にすでに入っていないかも確かめます。修正版が出ていても、今後の修正が見込めない部品を業務に組み込むのは避けます。

STEP3
勧告と修正版を一次情報で確かめる

勧告の一覧と、使う部品の版を照らし合わせます。先行版の表示がある修正は、正式な版の公開を待つかどうかも判断します。勧告は今後も増えうるため、確認を一度で終わらせません。

STEP4
AIに渡すパソコンと鍵の範囲を決める

隔離したパソコンに持ち込んでよいログイン状態とAPIの鍵、触ってよいアプリを、業務の目的から逆算して最小限に決めます。本番の管理者の権限は持ち込まないことを原則にします。

STEP5
人の承認と記録の仕組みを決める

どの操作の前に人が承認するか、承認の答えが本人から来たことをどう確かめるか、操作の記録をどこに残して誰が読むかを決めます。社外の中継のサービスを使う場合は、何が送られるかも確かめます。

企業が取るべき対策

Cua を使うかどうかにかかわらず、パソコン操作を任せるAIエージェントを検討する企業が取るべき対策は共通しています。第一に、AIには使い捨ての隔離したパソコンを渡し、普段の業務用のパソコンを渡さないことです。隔離したパソコンには、業務に必要な最小限のログイン状態と鍵だけを置きます。

第二に、APIの鍵は、AIに預ける専用のものを用意し、利用の上限と失効の手順を決めておくことです。開発者のパソコンに置かれた鍵も対象に含め、漏えいが疑われたらすぐに止められるようにします。第三に、承認の仕組みや開発用の画面など、通信の窓口を開く部品は、自分の機械からしか届かない状態を既定にすることを確かめます。

第四に、承認の画面に表示される範囲と、実際の処理の範囲が一致しているかを試験で確かめることです。第五に、社内のAI利用の規程に、パソコン操作を任せてよい業務、持ち込んでよい鍵、承認が必要な操作、記録の保管期間、勧告を確認する担当者を書き込みます。部品の更新と勧告の確認を、一度きりではなく定期の作業として組み込むことが、守りを続けるための要点です。

AIに任せる範囲と、人が決める範囲

パソコン操作を任せる基盤では、AIが画面を見て次の一歩を決めます。だからこそ、何をしてよいか、どこで止まるかの判断はAIに任せないことが大前提です。AIに任せてよいのは、人が決めた範囲の中で、画面を読み、操作を提案し、実行することまでです。

人が先に決めるのは、AIに渡すパソコンと権限、承認が必要な操作の一覧、承認する人、記録を確かめる人と頻度です。そのうえで、AIエージェントには操作ごとに、何を見て何をしようとしているのか、根拠を書かせるようにし、承認する人がその根拠を読んで判断できるようにします。公式の文書も、操作が確かに反映されたと確認できない場合はもう一度画面を観察して確かめるべきだとしています。避けたい使い方を挙げます。

  • 普段の業務用のパソコンに、ログインしたまま AIエージェントをつないで操作させる
  • 承認の仕組みがあることだけを理由に、承認の答えの出どころを確かめずに使う
  • 本番でも使えるAPIの鍵を、開発用の手元の画面にそのまま置いて試す
  • 保守が終わったと明記された部品を、修正版が出たからと業務に組み込み続ける
  • 承認の画面に出ている範囲だけを見て、実際に移るものを確かめずに許可する

どれも、AIの能力ではなく、人が先に決めるべきことを決めていないために起きる失敗です。人が確認する範囲を先に決め、その確認が本当に効いているかを試すことが、パソコン操作を任せるAIとの付き合い方の基本になります。

よくある質問:修正版に更新すれば安心してよいのか

答えは「勧告の問題には対処できるが、それで安全になるわけではない」です。修正版は、勧告に書かれた弱いところを直したものです。パソコン操作を任せる仕組みそのものが持つ危険、つまりAIが画面上の情報に誘導されたり、持ち込んだ鍵や権限が悪用されたりする危険は、修正版でも残ります。また、この記事では修正の中身をコードで確かめたわけではなく、勧告とリリースの一覧の記載に基づいています。

もう一つ、「Cua Spaces を使えば、隔離と承認がそろっているから安心なのか」という問いもありそうです。Cua Spaces はOSSではないFSLのアプリで、有料の契約もあり、運営元が運用する中継や認証のサービスとも関わります。業務で使う場合は、ライセンスの条件、何が運営元のサービスを通るのか、契約の内容を、OSSの部品とは別に確かめる必要があります。運営元のサービスの扱いについて、確認できた一次情報は限られます。

結局のところ、どの部品を使う場合も、AIに預ける範囲を狭く決め、人の承認と記録が実際に効いているかを確かめ続けることが前提です。修正版への更新は、その前提の上に乗る一つの対策にすぎません。

  • Cua の構成・ライセンス・勧告・修正版の公開状況は、GitHubのリポジトリ(README・リリースの一覧・セキュリティの方針・4件の勧告)、PyPI の cua-agent のページ、公式の文書を2026年10月21日に確かめた範囲に基づきます。版の更新や新たな勧告で内容は変わる可能性があります
  • 修正の中身をコードで確かめてはいません。Cua Driver の0.37.0はリリースの一覧で先行版の表示で、勧告の対象と同じものかは確かめきれていません
  • この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、勧告の再現の方法は扱いません

まとめ

Cua は、AIエージェントに画面のアプリ操作の手段、隔離した仮想のパソコン、評価の仕組みを与える基盤です。中心部分はMITライセンスのOSSですが、デスクトップ用のアプリ Cua Spaces はOSSではないFSLで公開され、追加部品にはAGPLを含むものもあります。

2026年10月には、人の承認を偽装されうる問題、APIの鍵が漏れうる問題を含む4件の勧告が公開されました。勧告ごとに修正版が示されていますが、深刻度「高」の2件の対象の部品は保守が終わっており、修正は最新版にだけ入る方針です。AIに判断させず、渡すパソコン・鍵・承認の範囲を人が先に決め、操作の根拠を書かせ、その確認が効いているかを試し続けることが、Cua のようなパソコン操作の基盤との現実的な付き合い方です。

出典(一次情報)
  • Cua(GitHubのリポジトリ・README):https://github.com/trycua/cua
  • リリースの一覧:https://github.com/trycua/cua/releases
  • セキュリティの方針:https://github.com/trycua/cua/blob/main/.github/SECURITY.md
  • 勧告(人の承認の仕組みの認証の欠如・2026年10月19日):https://github.com/trycua/cua/security/advisories/GHSA-gj99-rv7m-vm79
  • 勧告(開発用の画面の認証の欠如と呼び出しの許可の設定・2026年10月19日):https://github.com/trycua/cua/security/advisories/GHSA-8jjf-g53q-cr56
  • 勧告(引き継ぐ範囲の食い違い・2026年10月20日):https://github.com/trycua/cua/security/advisories/GHSA-5cjh-q5qq-72f7
  • 勧告(許可の照合の甘さ・2026年10月20日):https://github.com/trycua/cua/security/advisories/GHSA-f42q-9h29-hw57
  • PyPI の cua-agent のページ(保守終了の記載):https://pypi.org/project/cua-agent/
  • Cua Driver の公式の文書(仕組みの説明):https://cua.ai/docs/cua-driver/concepts/how-cua-driver-works

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。

AIの導入・活用、何から始めるべきかお悩みですか?

デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。

運営会社:株式会社デボノ

目次