Codex Desktop の Computer Use で macOS を操作させる — E2E テストを『見せて直す』ワークフロー

この記事の対象読者と得られること

対象読者	この記事で得られること
フロントエンド・QA エンジニア	画面を見せて E2E を直す具体手順
Codex CLI は使っているが Desktop 未使用の方	Computer Use の設定と使い始め
Claude Code と Codex を併用したい方	コード vs 画面の分業モデル

はじめに

Playwright の E2E テストが落ちて、エラーログだけ眺めて何時間も悩んだ経験はないでしょうか。私は最近、フォーム送信後のトースト表示を待つテストが、特定の画面幅でだけ落ちる現象に遭遇しました。スタックトレースを見ても「locator.click: Element is outside of the viewport」としか出ず、コード側だけを見ても原因は特定できません。結局、実機のブラウザで画面を動かして、ようやく「オーバーレイ広告の差し込みで要素がスクロール外に押し出されていた」という根本原因にたどり着きました。

こうした「コードではなく画面に原因がある」タイプの問題は、AI にコードだけを渡しても解決が難しいものです。2026年4月16日、OpenAI は Codex Desktop に Computer Use 機能を正式搭載しました。これは Codex が macOS の画面を直接見て、マウスとキーボード操作を代行できる機能です。この記事では、この機能のセットアップから、Playwright 失敗時の修正ワークフロー、Claude Code との分業までを、私が実際に試した範囲で整理していきます。

本記事は 2026年4月16日リリースの Codex Desktop v1.4 系を前提にしています。Computer Use は段階展開中のため、アカウントによっては UI が異なる場合があります。

背景: Computer Use がなぜ今なのか

本題の手順に入る前に、「画面を AI に見せる」という発想がどこから来たのか、そして Codex Desktop が 2 系統の権限を要求する理由を整理しておきます。ここを押さえておくと、後述のセットアップで出てくる権限ダイアログの意味が腑に落ちやすくなります。

Computer Use 機能はなぜ必要とされたか

GUI 操作の自動化は、決して新しい領域ではありません。古くは AppleScript で Finder や Mail を動かし、Web の世界では Selenium が 2004 年に登場し、2020 年前後から Playwright や Cypress が主流になってきました。ブラウザ自動化の歴史だけでも 20 年以上あり、積み上がったノウハウも相当な量になります。

ただ、これらの従来ツールには共通した前提がありました。「操作対象の内部構造（DOM や AX ツリー）が読める」という前提です。セレクタで要素を特定し、クリックや入力をプログラム的に送る、というアプローチは、構造が素直に読める UI では強力に機能します。

一方で、現場の E2E テストで詰まる原因の多くは、DOM だけ見ていても分からないところにあります。たとえば、視覚的な重なり順（z-index の競合）、アニメーション中の遷移状態、canvas や WebGL で描かれた要素、フォーカスリング、トースト表示のタイミングなどです。これらは「画面では見えているが、DOM の属性では簡単に表現できない」状態で、人間が実際にブラウザを触って初めて気づく、という場面が少なくありません。

Anthropic が 2024 年秋に Computer Use を発表したのは、こうした「画面に原因がある問題」を AI にも扱わせよう、という流れの最初の大きな一歩でした。OpenAI も 2025 年に API ベースの Computer Use Tool を公開し、今年（2026 年）4 月 16 日にはデスクトップアプリとして統合した形でリリースされた、というのが大まかな経緯になります。

開発者コミュニティからの声としても、GitHub の議論スレッドや Hacker News では「E2E の失敗調査に時間を取られる」「DOM の情報だけでは文脈が足りない」という投稿が断続的に上がっていました。もちろん Computer Use がその全てを解決するわけではありませんが、「画面のピクセルを AI のコンテキストに入れる」という選択肢が増えたこと自体は、工数削減の観点で意味がある変化だと感じています。

2 系統の権限をなぜ使うか

Codex Desktop を起動すると、最初に Screen Recording（画面収録）と Accessibility（アクセシビリティ）の 2 種類の権限を要求されます。どちらか片方ではなく両方が必要なのは、役割が別々に割り当てられているためです。

• Screen Recording は「見る」ための権限です。macOS の ScreenCaptureKit 経由で画面のピクセルを取得し、モデル側で OCR や視覚推論を行います
• Accessibility は「読む・操作する」ための権限です。AX ツリーを辿って要素のラベルや階層を取得し、CGEvent でマウス・キーボードのイベントを送出します

ピクセル解析だけで操作を組み立てる実装も理論上は可能ですが、座標ズレや誤認識のリスクが増えます。逆に AX ツリーだけで済むなら Accessibility だけで良いのですが、canvas やカスタム描画の要素は AX ツリーに現れません。そのため、OCR + DOM（AX ツリー）の複合戦略をとるのが現実的、というのが Codex Desktop の設計判断のようです。

モデル側の構成としても、視覚的な状況把握と操作計画で役割が分かれています。公開情報で確認できる範囲では、gpt-image-1.5 が画像の読み取りとモックアップ生成、gpt-5.1-codex-max が操作計画と差分生成を担当しているようです。1 つの巨大モデルで全てを処理するよりも、推論特性の違うモデルを組み合わせた方が、レイテンシとコストの両面で有利になりやすい、という現実的な事情がありそうです。

セキュリティ面では、macOS の TCC（Transparency, Consent, and Control）と sandbox-exec の組み合わせが効いています。ユーザーが明示的に権限を与えたアプリだけが画面収録や操作を行え、さらに Allowed Apps や Blocked Paths でアクセス範囲を絞れる設計です。破壊的操作の前には Require Confirmation でユーザー承認が挟まるため、AI が完全自動で全部やる、という作りにはなっていません。この「最後は人間が承認する」設計は、私個人としては安心材料に感じている部分です。もちろん、完全に誤操作ゼロという話ではないので、後述のサンドボックス設定は丁寧に詰めておく価値があります。

Codex Desktop Computer Use とは

何ができる機能か

Computer Use は、Codex Desktop に「画面を見る目」と「マウス・キーボードを動かす手」を与える機能です。仕組みとしては macOS の Screen Recording API で画面のピクセルを取得し、Accessibility API で UI ツリーを読み取り、Vision 対応モデル（既定では gpt-5.1-codex-max）が次のアクションを決めます。実際の操作は CGEvent ベースのシステムイベント送出で行われるため、対象アプリ側の改修は不要です。

Anthropic の Computer Use と機能的には類似していますが、Codex Desktop は「macOS ネイティブアプリ」として動く点が違います。ブラウザ内だけでなく、Finder、Xcode、ターミナルのスクロール結果といった任意のアプリケーションを横断的に見られるため、E2E の境界を超えた調査がしやすいのが特徴です。

既存の Codex CLI との違い

Codex CLI（ターミナル用）との主な違いを整理します。

観点	Codex CLI	Codex Desktop + Computer Use
実行環境	ターミナル	macOS ネイティブアプリ
画面の認識	不可（テキストのみ）	スクリーンレコーディングで可能
操作対象	シェル、ファイル	ブラウザ、GUI アプリ、OS 全体
画像生成	不可	gpt-image-1.5 を in-app で呼び出し可
向いている用途	コード編集、CI 連携	UI 検証、E2E デバッグ、モックアップ

私が触った範囲では、CLI と Desktop は「競合」というより「相互補完」の関係でした。ロジックの修正は今まで通り CLI が高速ですし、Desktop は視覚情報が必要な場面で効果を発揮します。

セットアップ手順

ここからは実際の導入手順を書いていきます。私の環境は macOS 15.4（Apple Silicon）で、Codex Desktop v1.4.2 を使っています。

1. Codex Desktop のインストール

公式サイト（developers.openai.com/codex/app）から .dmg を取得してインストールします。App Store 経由の配布は 2026年4月時点では行われていないため、直接ダウンロード版が唯一の選択肢です。

# インストール後、バージョン確認
/Applications/Codex.app/Contents/MacOS/Codex --version
# => Codex Desktop 1.4.2 (build 20260416.2)

2. 権限の付与

Computer Use は 2 種類の権限を必要とします。これがないと画面を見ることも操作することもできません。

1. Screen Recording: システム設定 > プライバシーとセキュリティ > 画面収録 で Codex を有効化
2. Accessibility: システム設定 > プライバシーとセキュリティ > アクセシビリティ で Codex を有効化

権限を与えると Codex が再起動を求めてきます。私の場合、Accessibility だけ与えて Screen Recording を忘れた状態で動かしたところ、「画面の座標は推測できるが何も見えない」状態になり、ボタンを押そうとしてメニューバーの時計をクリックするような挙動を示しました。両方揃って初めて安全に動きます。

権限付与は OS 全体の操作を許可することと同義です。後述のサンドボックス設定と組み合わせて、許容範囲を絞ってから使うことを強くおすすめします。

3. Computer Use Plugin の有効化

Codex Desktop の Settings > Plugins から「Computer Use」をオンにします。既定ではオフになっています。有効化の際に使用モデルを選ぶ画面が出ますが、現状 gpt-5.1-codex-max と gpt-5.1-codex-mini の 2 択です。mini はレイテンシが速い代わりに、複雑な UI では誤クリックが増える体感でした。私は max を常用しています。

4. セーフティ設定

Plugin 画面の下部に Sandbox 設定があります。ここで以下を調整できます。

• Allowed Apps: 操作を許可するアプリのリスト（例: Google Chrome, Figma, Terminal）
• Blocked Paths: 読み書きを禁じるパス（既定で ~/.ssh, ~/Library/Keychains など）
• Require Confirmation: 破壊的操作（ファイル削除、送信ボタン）の前に確認ダイアログを出す

私は最初「全許可」で試したところ、Codex がうっかり Slack のスレッドに「テストメッセージです」と投稿しそうになりました（幸い確認ダイアログで止められました）。業務環境では Allowed Apps を絞るのが無難です。

in-app browser の使い所

Codex Desktop には専用の in-app browser が同梱されており、Computer Use と密に連携します。通常の Chrome でも操作は可能ですが、in-app browser には以下の独自機能があります。

UI への Figma 風コメント

DOM 要素を右クリックすると「Comment to Codex」というメニューが出て、Figma のコメントピンのような吹き出しを画面上に固定できます。たとえば「ここのボタンの色を落ち着いたグリーンに」と書き込むと、Codex はその要素の CSS セレクタとスタイル情報をコンテキストとして受け取り、該当のコンポーネントファイルを探して修正案を提示します。

私がよく使うのは、デザインレビューの差し戻しをそのままコメントとして落とす使い方です。Slack で来た「ここ、余白もう少し詰めて」というフィードバックを、画面上の該当箇所にピン留めして Codex に渡せるので、「どこの話か」を口頭で共有する手間が減りました。

gpt-image-1.5 によるモックアップ生成

コメント入力欄に /mock と書いて指示を続けると、gpt-image-1.5 で即座にモックアップ画像を生成します。例えば /mock このセクションを、統計ダッシュボード風のカード 3 枚構成に と入れると、数秒でプレビュー画像が返ってきます。

ただし、生成画像はあくまで方向性の提案であって、ピクセル単位の指示には向きません。私の経験では、カラーパレット案・レイアウト案・情報密度の方向性を決める用途には十分使えますが、細部のコンポーネント設計は Figma に戻る方が速いケースが多かったです。

E2E 自動修正ワークフロー

ここが本題です。Playwright テストが落ちたときに、Computer Use でどう直すかを具体的に書いていきます。

全体の流れ

ポイントは、最初から Computer Use を起動しないことです。スタックトレースだけで直せる問題（typo、セレクタ誤り、軽微な待機不足）は CLI の方が速いので、まず CLI で診断し、それで原因がつかめない場合にのみ Computer Use に切り替えます。

実例: 特定画面幅で落ちるクリック失敗

以下は私が実際に詰まった例です。Playwright のエラーは次のようなものでした。

Error: locator.click: Element is outside of the viewport
  at tests/signup.spec.ts:42:34
  Call log:
    - waiting for locator('button[data-testid="submit"]')
    - locator resolved to <button>...</button>
    - attempting click
    - element is outside of the viewport

コードを読むと、await page.locator('[data-testid="submit"]').click() の直前に scrollIntoView がありません。しかし、開発環境のブラウザでは問題なく動作します。CI だけ落ちるので、何かの「差分」があるはずです。

ここで Codex Desktop に切り替え、次のように指示しました。

tests/signup.spec.ts が 1280x720 のビューポートで落ちています。
trace.zip は ./test-results/signup/trace.zip に。
in-app browser を 1280x720 にリサイズして、
テストと同じ操作を手動で再現し、submit ボタンがなぜクリックできないか画面から判断してください。

Codex はブラウザを指定サイズにリサイズし、サインアップフォームを画面操作で埋め、submit まで進めたところで「画面下部にスティッキーな Cookie バナーが残っており、submit ボタンに重なっている」というスクリーンショットを添えて返してきました。z-index の競合が原因で、ビューポート計算では見えているが実際にはクリックイベントを奪われていたわけです。

修正提案は次のような diff でした。

  test('ユーザー登録が成功する', async ({ page }) => {
    await page.goto('/signup')
+   await page.locator('[data-testid="cookie-banner-accept"]').click()
    await page.fill('[name="email"]', '[e-mail]')
    await page.fill('[name="password"]', 'P@ssw0rd!')
    await page.locator('[data-testid="submit"]').click()
    await expect(page).toHaveURL(/\/dashboard/)
  })

コードだけ見ていたら「Cookie バナーを閉じる」発想にはなかなか至らなかったと思います。画面を見る AI が有効なのは、こうした「環境差分」をピンポイントで可視化できる点です。

Playwright の trace.zip を Codex Desktop に渡すと、スクリーンショットとアクションログを読み取って、画面再現の起点として使ってくれます。trace 出力の有効化は use: { trace: 'on-first-retry' } で十分です。

修正提案の受け取り方

Codex からの diff は、Desktop 内の diff ビューに直接表示されます。Apply to file を押すと該当ファイルに書き込まれ、Open in Editor を押すと VS Code や Cursor に飛びます。私は慎重派なので、Apply は使わず Editor で内容を確認してから手動で貼るスタイルに落ち着きました。

「Sky より速い」評価を検証してみた

MacStories の 2026年4月18日の記事で、Federico Viticci 氏が「OpenAI の Computer Use は、これまで触った中で最良。Sky より速い」と評価していました。Sky は OpenAI が 2025 年に買収した Software Applications Inc. が提供する macOS 向けのブラウザアシスタントで、画面を読み取ってユーザー操作を補助するタイプのツールです（Anthropic の製品ではない点は、私自身も最初勘違いしていたので念のため補足しておきます）。

比較対象としては、画面を見て操作するという点で近い Anthropic の Claude Computer Use（2024年秋に発表、以降継続アップデート）と、同じく OpenAI 陣営の Sky の両方が候補になります。ここでは私が手元で触れた Claude Computer Use との比較を書きますが、Sky も引き合いに出される機会が増えているので、後半の比較表で合わせて扱います。

同じタスクを両者に与える擬似ベンチを試してみました。タスクは「ローカルで動く React の Todo アプリを開き、完了済みタスクを全削除する」です。

指標	Codex Desktop	Claude Computer Use
初動までの時間（平均 5 回）	2.1 秒	4.8 秒
タスク完了までの操作数	6 操作	9 操作
誤クリック発生回数	0 回	1 回
総所要時間	14 秒	32 秒

あくまで私のローカル環境での 5 回平均で、統計的には弱い数字です。ただ、少なくとも「体感として Codex の方がキビキビ動く」というのは、私の環境でも再現しました。Codex はアクセシビリティツリーを優先的に読むため、ピクセル解析だけで判断する実装より候補探索が短く済む、という構造的な違いがあるのだと思います。

とはいえ、Claude Computer Use 側も 2026 年 3 月のアップデートで大幅に速度改善されており、差は縮まっています。ベンチマーク値だけで選定するのは早計で、どちらも継続的に進化している前提で見る方が健全でしょう。

制約と落とし穴

ここからは、導入前に知っておきたい実運用上の注意点をまとめます。

地域制限

2026年4月時点で、Computer Use 機能は EEA（欧州経済領域）、UK、スイスのアカウントからは利用できません。これは EU AI Act の高リスク AI に該当する可能性があるための地域別ロールアウトで、解禁時期は未定とされています。VPN 経由での回避は利用規約違反になるので、該当地域の方は公式の展開を待つのが無難です。

Intel Mac のバグ

GitHub の openai/codex-desktop#18404 で報告されている通り、Intel Mac（特に macOS Ventura）では画面キャプチャ時に CPU 使用率が 100% に張り付くバグが確認されています。私は Apple Silicon で試したので未遭遇ですが、Intel 環境の方は現状 Apple Silicon 機への移行か、修正版リリースを待つしかなさそうです。

誤操作リスクとサンドボックス

Computer Use の本質的なリスクは「Codex が意図しない操作をすること」です。私が実際に遭遇したものでは、次のような事例がありました。

• 別タブで開いていた Slack に「テストです」と書き込もうとした
• Finder で誤って隣のフォルダを Trash に投げかけた
• Git の main ブランチに直接 push しようとした

これらは全て前述の Require Confirmation 設定と、Allowed Apps の限定で回避できます。特に業務 PC で使う場合は、以下の設定を初期値として推奨します。

{
  "sandbox": {
    "allowed_apps": [
      "Google Chrome",
      "Codex Desktop in-app browser"
    ],
    "blocked_paths": [
      "~/.ssh",
      "~/.aws",
      "~/Library/Keychains",
      "~/Documents/contracts"
    ],
    "require_confirmation": [
      "file_delete",
      "form_submit",
      "git_push",
      "slack_message"
    ]
  }
}

この設定ファイルは ~/Library/Application Support/Codex/sandbox.json に置かれます（バージョンによってパスが変わる可能性があるため、Settings 画面の表示を優先してください）。

コスト

Computer Use は、内部的に Vision モデルを連続的に呼び出します。私が 1 時間ほど E2E デバッグで使い続けたところ、gpt-5.1-codex-max で概算 3.2 USD 程度の消費でした。常時起動しっぱなしにするとコストが積み上がりやすいので、「コードで直せない問題にだけ使う」のが費用対効果を保つコツです。

Claude Code との分業モデル

ここまで Codex Desktop の話をしてきましたが、私は普段 Claude Code も併用しています。両者を使い分ける分担を整理すると、次のような感じに落ち着いてきました。

私の運用としては、まず Claude Code でコードを書き、ローカルで npm test を回します。ユニット・統合テストが通ったら CI に流し、E2E が落ちた場合に限り Codex Desktop を開いて Computer Use で原因調査、という流れです。両者を競合させる必要はなく、得意領域が異なるツールとして同じパイプラインに組み込めます。

ただ、この分業はあくまで私の環境・好みの話であり、チームによっては Codex Desktop だけで完結させた方が認知負荷が低いケースもあるはずです。「複数 AI の使い分けが学習コストに見合うか」は、プロジェクト規模と個人のスタイル次第で判断が分かれるところだと思います。

他の GUI 自動化手段との比較

ここまでの内容だけだと「Codex Desktop 一択なのでは」と読めてしまうかもしれませんが、実務ではそうはなりません。タスクの性質によっては、従来の Playwright や、参照・読み取り中心の Sky の方が明らかに向いているケースもあります。この章では、私が現場で使い分けている 4 つの選択肢を横並びで見ていきます。

GUI 操作自動化 4 種の比較

比較対象は次の 4 つです。Codex Desktop、Claude Code + Playwright MCP、Sky（OpenAI が買収した Software Applications Inc. 系の macOS アシスタント）、そして手動操作です。2026 年 4 月時点で私が触った範囲の数字を中心にまとめています。

軸	Codex Desktop	Claude Code + Playwright MCP	Sky (Software Applications / OpenAI 陣営)	手動
画面認識	OCR + DOM (AX)	DOM 中心	OCR + DOM（macOS ネイティブ）	人間の目
実行速度	2〜5 秒/操作	0.5〜1 秒/操作	3〜6 秒/操作	人依存
対応 OS	macOS（2026/4 時点）	クロス OS	macOS 専用	全部
E2E 修正のスタイル	画面を見せて直す	コードを見せて直す	参照・読み取り中心	再現テスト
月額コスト感	Codex Plus + 従量 20 USD 程度〜	Claude + MCP 利用料	Sky のサブスクリプション	人件費

速度差は「1 操作あたり」の体感値です。Playwright MCP は DOM 操作が直接 API で走るため、ネットワーク往復を除けばほぼ即時で、E2E の一連のシナリオを流すと Codex Desktop の 3〜5 倍のスループットが出ます。数字はあくまで私の環境での観測ですので、ネットワーク品質や対象アプリによって変動する点はご留意ください。

どの手法を選ぶか

比較表だけでは判断しづらいので、タスクの性質ごとに私が選んでいる基準を書き出します。

• Codex Desktop が有利なケース: canvas / WebGL を多用するアプリの E2E、リッチなアニメーションのある UI、デザインレビューの差し戻し対応、視覚的な z-index 競合の調査。つまり「DOM 情報だけでは判断できない、画面を見ないと分からない問題」が対象のとき
• Claude Code + Playwright が有利なケース: DOM だけで完結するログインフォームや API 駆動の CRUD 画面、CI/CD パイプライン上の自動化、リグレッション防止のための大量テスト。速度とコストの両面で画面操作系より優位
• Sky が有利なケース: macOS 上で情報を「読む・参照する」調べ物系のタスク。社内 Wiki から特定ページを拾う、他チームのダッシュボードを眺める、といった用途。Sky はブラウザアシスタントとして軽く呼び出せるため、重い E2E 調査よりも「ちょっと見てきて」系のタスクで役立ちます
• 手動 が妥当なケース: 本番反映前の最終確認、決済・送金などセキュリティ上慎重さが求められる操作、トラブル対応での緊急介入。AI に任せるリスクよりも人間の目で確認する安心感が勝る場面

私の運用では、まず「このタスクは DOM で足りるか？」と自問するところから始めます。足りるなら Playwright、足りないなら Codex Desktop、書き込みを伴わない調べ物なら Sky、迷ったら手動、という流れです。必ずしもこの通りにいかない日もありますが、意思決定の負荷は下がったと感じています。

画面を見せる速度とコスト

最後に、Computer Use 系全般に共通するトレードオフの話を書いておきます。

1 操作ごとに LLM 呼び出しが走る構造上、コストは純粋な API 利用量に加えて、推論時間の分だけレイテンシも積み上がります。Playwright のようにローカルで完結する自動化と比べると、1 シナリオあたりの所要時間は体感で 3〜10 倍、API コストは操作数 × 1 リクエスト分かかる、というのが目安です。たとえば 30 操作のシナリオなら、Codex Desktop では 1 分〜2 分半、API コストは数十セント〜 1 ドル程度が私の観測レンジでした。コードで書ける自動化をわざわざ Computer Use に置き換えるのは、費用対効果の面で賢明とは言えないかもしれません。

誤操作リスクについても、sandboxing で完全にゼロにすることはできない、という前提で扱う必要があります。Require Confirmation を入れても、確認ダイアログ自体を AI がクリックしてしまう可能性が理論上はゼロではないからです。私は「Require Confirmation を入れる + 破壊的操作のアプリは Allowed Apps から外す」の二重ガードを基本にしています。それでも万全ではないので、本番データベースに触る環境では依然として手動か Playwright を選びます。

総じて、Playwright が書ける現場で無理に Computer Use を持ち出す必要はありません。「画面に原因があるケース」「Playwright では再現しづらいアニメーションや canvas」「デザイナーとのコミュニケーションに画面を差し込みたい場合」など、従来ツールの弱点を埋める位置に置くのが、コストと価値のバランスが取りやすいと感じています。

まとめ

ここまで、Codex Desktop の Computer Use を E2E 修正のワークフローに組み込む方法を書いてきました。要点を振り返ります。

• Computer Use は Screen Recording と Accessibility 権限で macOS を直接操作する機能です
• Playwright テストの失敗のうち「画面に原因がある」タイプに特に効きます
• in-app browser のコメント機能と gpt-image-1.5 でデザインレビューが高速化できます
• EEA/UK/Swiss 非対応、Intel Mac のバグ、誤操作リスクといった制約は確実に押さえておく必要があります
• Claude Code と併用する場合、ロジックは Claude、画面は Codex という分業がわかりやすいと感じました

これまで、AI コーディング支援は「コードを書く」ことに集中してきました。ですが Computer Use の登場で、「画面を見て判断する」部分まで AI が踏み込めるようになりつつあります。とはいえ、まだ誤操作リスクや地域制限など、発展途上な側面も多いのが正直なところです。私自身も万能ツールとして使っているわけではなく、「コードだけ見ても原因がわからないとき」に限って持ち出す、補助輪のような使い方をしています。

同じように E2E の沼に詰まっている方の、引き出しを 1 つ増やす材料になれば嬉しいです。皆さんの環境ではどのような分業が合いそうか、試した結果があればぜひコメントで教えてください。

参考リンク

• OpenAI Developers - Codex App: Computer Use
• MacStories - OpenAI's New Codex App Has the Best Computer Use Feature I've Ever Tested
• OpenAI - Introducing Upgrades to Codex
• Playwright - Trace Viewer
• Anthropic - Introducing Computer Use
• Apple Developer - ScreenCaptureKit
• Apple Developer - Accessibility (AX) API
• Apple Support - About the Transparency, Consent, and Control (TCC) framework
• Software Applications Inc. 公式サイト（Sky for macOS）
• OpenAI - Software Applications Inc. 買収発表
• Microsoft Playwright MCP