はじめに
Windows版CodexのComputer UseでChromeを操作しようとしたところ、エラーが発生しました。
今回は、その原因と対処方法について調査した内容をまとめます。
結論
- 2026/10/11時点で、Computer UseによるChromeの読み取りはおそらくできない
- CodexにChromeの情報を読み取らせる場合はBrowser Useで代替できた
1. エラー①：Chromeへのアクセスが承認されない
最初に発生したのは、以下のエラーです。
Computer Use was not approved to use Google Chrome
権限関係のエラーのようです。
原因を特定するため、まずComputer UseがChromeを読み取る仕組みを調べました。
1.1. Computer UseでChromeを読み取る仕組み
大まかに、以下の流れでChromeの情報を取得します。
- 操作方法の取得： SkillからComputer Useの操作方法を確認
- 対象アプリの特定： Chromeと対象ウィンドウを特定
- アクセス許可の確認： アプリへのアクセス承認やポリシーを確認
- 画面情報の取得： ウィンドウの状態を取得
エラー内容から、「3. アクセス許可の確認」で問題が発生していると考えられます。
そこで、この処理をもう少し具体的に見ていきます。
1.2. Chromeへのアクセス承認の仕組み
該当箇所の処理は、COmputer Use内部で使用される@oai/sky というライブラリで行われています。
承認処理は、大まかに以下の流れです。
- 対象アプリへのアクセス承認を要求
- ユーザーの承認結果を受け取る
- 結果を検証し、承認されていれば処理を続行
このとき、今回の承認エラーが返される条件として、以下の2つの条件がありました。
- 承認応答の
actionが"accept"ではない - 永続承認が許可されていない要求に対して、永続承認の応答が返された
まずは、承認処理に問題があると考え、Codexの設定を確認しました。
1.3. 原因の調査と対処
Codexの承認設定を確認したところ、以下の状態でした。
- 承認方法が「カスタム」
approval_policy = "never"- Chromeが常時許可アプリに未登録
ここから、設定方法に以下の2つの問題があることが分かります。
- Chromeが常時許可されていない
- アプリを新たに承認するためのダイアログが表示されない設定になっている
通常、常時許可されていないアプリにアクセスする場合、ユーザーによる承認が必要になります。しかし、今回の設定では承認ダイアログが表示されず、アクセスできない状態になっていたのです。
そこで、config.tomlの承認設定を変更しました。
// 変更前
approval_policy: "never"
// 変更後
approval_policy: "on_request"
再実行するとChromeへのアクセス承認ダイアログが表示され、「許可」を選択することでエラーが解消されました。
今回の原因は、未承認のアプリに対して承認を要求できない設定になっていたことだと分かりました。
1.4. アクセス承認エラーが発生した場合の確認項目
同様のエラーが発生した場合は、以下を確認するとよさそうです。
| 確認項目 | 確認内容 |
|---|---|
| Computer Use | 機能が利用できるか |
| 常時許可アプリ | 常時許可アプリとして登録されているか |
| 承認方法 | 未承認アプリへの承認要求が表示される設定か |
※ 常時許可アプリはconfig.tomlからも設定できます。
[computer_use.windows]
always_allowed_app_ids = ["chrome.exe"]
2. エラー②：ChromeのURLを確認できない
エラー①の解決後、次のエラーが発生しました。
Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Stop your work and send a final message noting why Computer Use ended.
「現在のブラウザURLを、セキュリティポリシーの適用に必要な確度で確認できなかった」という意味です。
今度は「4. 画面情報の取得」に伴うURL確認処理で失敗しているようです。
2.1. 画面情報を取得する仕組み
画面情報の取得で実行するコードは以下です。
await sky.get_window_state({
window: chromeWindow,
include_screenshot: false,
include_text: true
});
内部のJavaScriptを調べると、以下の処理経路が確認できました。
sky.get_window_state()
↓
Windows用クライアント
↓
transport.request()
↓
Windows側の実行サービス
↓
結果・エラーを返却
transportは、JavaScript側とWindows側の実行サービスとの通信を担当します。
2.2. エラーの発生箇所を追跡
コードを追うと、transportには受信したエラーをJavaScriptの例外として返す処理がありましたが、今回のURL確認エラーを生成する処理が見つかりませんでした。
エラーが返される経路は分かったものの、実際にエラーを生成している処理までは追跡できませんでした。
2.3. 別の方法で原因を切り分ける
コードから原因を特定できなかったため、別のブラウザやツールで検証しました。
| 検証 | 結果 |
|---|---|
| ① Edgeでも読み取れるか | 同じURL確認エラーが発生 |
| ② Microsoft InspectでURLを取得できるか | ChromeのURL値を取得できた |
| ③ Browser UseでChromeを読み取れるか | タブ情報・ページ内容を取得できた |
特に②の結果が気になります。
Microsoftのアクセシビリティ診断ツール「Inspect」を使うと、Windows UI Automation経由でChromeのアドレスバーの値を取得できました。
つまり、WindowsのUI AutomationからURL値を取得すること自体は可能だと分かりました。
また、Browser UseではChromeの読み取りに成功しました。
両者は情報の取得経路が異なるようです。
| Computer Use | Browser Use | |
|---|---|---|
| 操作対象 | デスクトップアプリ全般 | ブラウザ |
| 主な取得経路 | WindowsのUI・アクセシビリティ機能 | ブラウザ連携・拡張機能 |
この違いが、読み取り結果の差につながっている可能性があります。
2.4. 原因の考察
検証結果から、CodexのComputer Use内部で、ブラウザURLの取得・識別・検証がうまくいっていない可能性が考えられます。
例えば、URLの取得には成功していても、そのURLが現在のウィンドウのものか確認できていない可能性があります。
2.5. GitHub Issueでも同様の問題が報告されていた
GitHubを調べると、同様のエラーを報告したIssueが見つかりました。
根本原因は発見できませんでしたが、同様の不具合が報告されていることは確認できたため、ここまでで調査を終えようと思います。
おわりに
今回の調査では、Chromeへのアクセス承認エラーは解消できましたが、URL確認エラーの根本原因は特定できませんでした。
もともとはChromeの状態を確認しながら、ほかのWindowsアプリも操作させたかったのですが、今回の環境では実現できなさそうです。
ひとまず、Chromeのページ情報取得にはBrowser Use、Windowsアプリの操作にはComputer Useを使い分けようと思います。