Windows の管理者権限プロセスは ChatGPT / Codex の Computer Use から操作できない

前回の記事で OpenAI の GPT-6 Astra と Computer Use API を軸に、AI エージェントに QA テスターを任せる構成を整理しました。Windows の開発機で ChatGPT デスクトップアプリと Codex を並走させて実装中に Computer Use に一巡させる、という運用が思ったより効くと書いた直後に、越えられない壁が 1 つあることに気づきました。管理者権限で起動されたウィンドウは、標準ユーザーで動く Computer Use から一切操作できません。

症状としては単純で、対象が管理者権限で起動された「コマンドプロンプト（管理者）」「PowerShell（管理者）」「Hyper-V マネージャー」「サービス」「タスクスケジューラ」「グループポリシーエディター」「Docker Desktop の一部の管理ダイアログ」「IIS マネージャー」といったウィンドウにマウスカーソルが載っても、クリックもキー入力も画面には何ひとつ反映されません。エラーダイアログが出るわけでもなく、エージェント側は「クリックした」と認識したまま、次の推論ステップへ進んでしまいます。

Windows 側で何が起きているか

原因は Windows Vista 以降に導入された Mandatory Integrity Control（MIC）と User Interface Privilege Isolation（UIPI）です。

MIC は、プロセスとオブジェクトに Low・Medium・High・System の 4 段階の整合レベルを付与し、下位の整合レベルから上位の整合レベルへ書き込みや制御を及ぼせないようにする仕組みです。標準ユーザーとして起動したデスクトップアプリは Medium 整合レベルで動き、UAC（User Account Control）の昇格を通した「管理者として実行」は High 整合レベルで動きます。

UIPI はこの整合レベルを GUI 層に適用したもので、次の操作を Medium → High 方向で禁止します。

SendMessage / PostMessage による上位整合ウィンドウへのメッセージ送信
SetWindowsHookEx による上位整合プロセスへのフック
SendInput や keybd_event など、合成入力の上位整合ウィンドウへの送出
上位整合プロセスのメモリ・ハンドルへのアクセス

スクリーンショット取得と DPI や座標の読み取りは、ほとんどのケースで境界の下側に留まる操作なので、画面を「見る」こと自体は成功します。エージェントから見ると「画面は正しく取れている」「クリック API も正常終了した」ように見えるのに、対象ウィンドウ側では 1 ミリも動いていない、という食い違いはこの非対称性で説明できます。

Computer Use 側で起きること

ChatGPT デスクトップアプリの Computer Use は、モデルが決めたクリック・キー入力を OS のマウス・キーボード API 経由で送出する構造です。アプリ本体が UAC 昇格を経ずに標準ユーザーで起動される限り、その入力は Medium 整合レベルから発行され、High 整合レベルのウィンドウに届く前に UIPI が警告を出さずに破棄します。

「じゃあ ChatGPT デスクトップアプリを右クリック → 管理者として実行で起動すれば良いのでは」という発想は最初に湧きますが、この経路は 2 つの理由で採用しにくいものになっています。

1 つ目は、ChatGPT デスクトップアプリのインストーラが、ユーザープロファイル配下（%LocalAppData%\Programs\ChatGPT\ 相当のパス）にファイルを配置する Squirrel.Windows 系の per-user インストーラ形態を採る構成に寄せてきた点です。この構成は自動更新のために UAC 昇格を要求しない代わり、Program Files 配下ではなくユーザーが書き換え可能な領域に実行ファイルが置かれます。管理者として実行すると、標準ユーザーで書き換え可能なパスから昇格プロセスが起動される形になり、ローカル権限昇格の観点で会社の EDR やアンチウイルスが警告する経路になりがちです。

2 つ目は、管理者権限で起動した ChatGPT デスクトップアプリは、今度は逆方向で、標準ユーザーで動いている大半のアプリと同じセッションのように見えなくなります。エクスプローラ・ブラウザ・IDE といった普段の作業に使うアプリは Medium 整合レベルで動くので、ドラッグ & ドロップやクリップボード連携・ウィンドウフォーカス制御の一部が期待どおりに動かなくなる場面があります。Computer Use に「日常の作業画面をひととおり触ってもらう」用途で使う限り、この副作用が響きます。

uiAccess の抜け道と、なぜ選ばれていないか

UIPI には「アクセシビリティ支援アプリケーションのために設計上の抜け道が要る」という配慮があり、アプリケーションマニフェストの uiAccess="true" 属性が用意されています。この属性を持ち、かつ次の条件を満たすアプリは、Medium 整合レベルの延長線上で、上位整合ウィンドウへ入力を送出できます。

有効な発行元証明書で署名されている
Program Files など、標準ユーザーが書き換えられない安全なパスにインストールされている
マニフェストで uiAccess="true" を宣言している

代表的なのが Windows のスクリーンリーダー「ナレーター」と、リモート制御ソフトの TeamViewer・AnyDesk といったカテゴリです。

Computer Use 系のクライアントがこの経路を採るには、上記 3 条件に加えて、勝手に uiAccess を持つバイナリを配布したら誰でも UAC の境界を越えられるのか、という利用者・IT 管理者側の合理的な疑問に答える必要があります。ChatGPT デスクトップアプリと Codex CLI は、現時点でこの経路を使っていません。したがって、コマーシャルなクライアントを普通にインストールしただけの状態では、AI テスターは High 整合レベルのウィンドウに触れません。

実務で影響を受けるのはどこか

Windows で管理者権限がほぼ必須になる操作は、ざっと以下です。

Hyper-V マネージャー・Windows サブシステム for Linux（WSL）の一部管理コマンド
サービス（services.msc）・イベントビューア（eventvwr.msc）・タスクスケジューラ（taskschd.msc）
グループポリシーエディター（gpedit.msc）とローカルセキュリティポリシー
IIS マネージャー・SQL Server 構成マネージャー
Windows のシステム設定のうち、UAC 盾アイコンが付いた操作全般
hosts ファイル・C:\Windows\System32\drivers\etc\ 配下・レジストリの HKEY_LOCAL_MACHINE の書き換え
MSI インストーラの実行と、大半のドライバインストール
Docker Desktop の一部の管理ダイアログ（Hyper-V との連携やネットワーク設定など）

前回の記事で「開発者のローカル環境で Codex と ChatGPT デスクトップアプリの Computer Use を併走させる」と書いた運用のうち、上のリストに触れるフローは AI テスターに任せられません。逆にいえば、Web アプリのフロントエンド確認、DOM だけで完結するダッシュボード、Program Files 配下に普通にインストールされた業務クライアントのうち標準ユーザーで動くもの、といった Medium 整合レベルで完結する対象は、これまでどおり Computer Use に任せられます。境界は「Windows OS の管理系操作を含むかどうか」であって、「業務アプリかどうか」ではありません。

取り得る回避策と、それぞれのコスト

このまま Windows の開発機上で AI テスターに管理系操作を触らせようとすると、いずれも副作用を伴う回避策になります。

1 つ目は、Windows のサンドボックスや Hyper-V による仮想マシンの中で、AI テスターと対象アプリを両方動かす方法です。VM の中では両方とも同じ整合レベル境界の下に置けるので、AI テスターの側だけを VM 内で管理者として動かせば、対象ウィンドウにも入力が届きます。開発機のホスト側にはエージェントの権限が漏れない利点があり、機密データやレジストリ書き換えの実験を切り離せるのも副次的に有効です。コストは VM のセットアップと、テスト対象アプリの再インストール・データ準備の手間です。

2 つ目は、Computer Use API の呼び出し側で明示的に管理者権限つきのランナー（Windows Server の仮想マシンや、ホスト側で管理者として起動したエージェントプロセス）を用意し、そこにモデルからのツール呼び出しを配線する方法です。ChatGPT デスクトップアプリの中の Computer Use ではなく、trycua の cua-driver のような呼び出し側の制御レイヤに置き換えると、ホスト側プロセスの整合レベルは自分で選べます。前回の記事で扱った API ベースの構成に寄せる形の解で、既存の CI に載せる用途ではむしろこちらが自然です。

3 つ目は、対象アプリ側の管理者権限依存を減らす方向です。Web ベースの管理コンソールで置き換えられるものはそちらに寄せる、hosts の書き換えは Windows 上ではなく、開発用の DNS ゾーンで名前解決させる、といった対応です。テスト実行のために本番ツールの側を変えるのは筋の悪い方向に見えますが、そもそも AI テスターだけの理由でなく、ローカルの再現性・CI 自動化・監査ログのすべてが管理者権限依存を減らすほうへ寄せてきているので、他の目的と一緒に整理できるならコスト対効果は悪くありません。

4 つ目は、uiAccess="true" 属性を持つ自前のホストランチャを社内で署名・配布して、そこから Computer Use のツール呼び出しをディスパッチする方法です。技術的には成立しますが、社内の署名ワークフローの用意、Program Files 配下への配置ポリシー、そして「開発機に UAC の穴を 1 個追加する」ことに対する情報システム部門の合意が必要です。少人数の R&D で回すには重すぎる選択肢で、社内の QA 基盤として恒常的に維持できる規模のときに検討する範囲です。

AI テスターの配置にどう反映するか

前回の記事で切り出した 4 つの配置に、この境界を重ねると次のようになります。

開発者のローカル環境（ChatGPT デスクトップアプリ + Codex 併走）で任せられるのは、標準ユーザー整合レベルで完結する画面と業務アプリだけです。管理系ツールを触るシナリオは、この配置では担当外にします。開発者本人がキーボードで進めるか、あるいは 2 つ目・3 つ目の配置に回します。

PR ごとの探索テストと夜間の広域スイートは、もともと CI やクラウド上のランナーで動かす前提だったので、そちら側で管理者権限のランナーを 1 つ切り出せば境界を越えられます。API ベースの Computer Use 呼び出しの中で、対象アプリごとにランナーの整合レベルを選び直す設計に寄せておくと、ここでは詰まりません。

手動 QA の一次巡回の差し替えでも、この境界は素直に効きます。管理系操作を含むシナリオは AI テスターに一巡させるより、人間の QA が受け持ち続けるほうが確実で、代わりに Medium 整合レベルで完結する画面は AI テスターへの一次巡回に寄せる、という時間配分になります。「AI テスターが不得意な領域に人間の時間を寄せる」という原則のうちに、Windows の管理系操作という項目が 1 つ足された、という理解が実務的にはいちばん扱いやすい形です。

覚えておくこと

Windows の Mandatory Integrity Control と UIPI は、標準ユーザー整合レベルから高整合レベルへの GUI 入力を意図的に遮断する OS 機能で、これは Computer Use 側の不具合ではない
ChatGPT デスクトップアプリと Codex CLI はどちらも uiAccess="true" の抜け道を採っておらず、標準ユーザーで動くアプリと同じ境界に留まる
管理者権限を要するツールを AI テスターに触らせたい場合は、VM か、API ベースの Computer Use を管理者ランナーで動かす経路のどちらかを選ぶ
ローカルの Computer Use に任せる対象は「標準ユーザー整合レベルで完結する画面」に限定し、Windows の管理系操作は AI テスターの担当外として明示的に切り分ける

以上、Windows の管理者権限プロセスは UIPI の境界の向こう側にあり、Computer Use から素直には操作できない話を、現場からお送りしました。

サイト内検索

Windows の管理者権限プロセスは ChatGPT / Codex の Computer Use から操作できない — UIPI が引く壁の位置