Codex Computer Useは、Codexアプリから可視のMacアプリを操作させるための機能です。最初に見るべきなのは設定場所ではなく、画面操作が本当に必要かどうかです。作業対象がローカルアプリ、設定画面、ブラウザ内の実フロー、シミュレーター、またはGUIでしか再現できない不具合なら候補になります。ファイル、ログ、API、リポジトリ、構造化データで処理できるなら、そちらを先に使うべきです。
2026年4月19日時点で、OpenAIの文書はCodexアプリのComputer UseをmacOS at launchの能力として説明しています。利用にはComputer Use plugin、Screen Recording、Accessibility、対象アプリやフローの承認が必要です。これは全システムを自由に操作する許可ではありません。macOSのセキュリティやプライバシー確認、管理者認証、支払い、パスワード、不可逆操作を代理で進めるためのものではありません。
まず使う条件を決める
Codexに画面を見せる価値があるのは、結果の証拠が画面上にあるときです。ボタンが表示されたか、設定が保存されたか、モーダルが邪魔しているか、レイアウトが崩れたか、ローカルWebアプリの実ブラウザ操作が通るか。こうした判断はファイルだけでは弱く、可視UIが作業対象になります。
一方で、コード修正、ログ確認、API呼び出し、データ抽出、Issue整理、メールやカレンダーの処理は、画面操作より直接ツールのほうが安定します。Computer Useは権限面が広いので、使う理由が「画面を見ないと分からない」まで絞れているかを確認してください。
最初の実行ルートを選ぶ
ローカルWebアプリの検証なら、まずCodexアプリ内ブラウザを使います。ブラウザ上の状態を見れば十分な作業で、いきなりデスクトップ全体へ権限を広げる必要はありません。
GitHub、Gmail、Calendar、Vercelのように対象が構造化されているなら、プラグインやMCPを優先します。対象、操作、結果が明確に残るため、あとから確認しやすく、失敗時の修正も具体的です。
コマンドやスクリプトで再現できるなら、Shell、script、APIを選びます。Computer Useは、こうしたルートでは届かない可視UIの最後の一段に使うものです。
Codex全体の最近の位置づけは OpenAI Codex 2026年3月アップデート で確認できます。ただし、Computer Useの判断はもっと狭く、画面が必要かどうかで決めます。
権限は段階的に有効化する
手順は段階化してください。まずComputer Use pluginを入れる。次にmacOSでScreen RecordingとAccessibilityを許可する。その後、Codexが操作してよい対象を一つのアプリまたは一つの短いフローに絞って承認する。最後に、最初のタスクを観察から始めます。
いきなり長い作業を任せないでください。まず「画面を見て、次に何をするか説明する」だけを求めます。その説明が妥当なら、一つのクリックや一つの入力だけを承認します。画面変化を確認したら、次の小さなステップへ進みます。
アカウントや地域によって入口が見えない場合は、アプリ内の実際の表示を優先してください。現在の源情報で安全に言えるのは、Computer UseがmacOS at launchとして文書化され、EEA、UK、Switzerlandではローンチ時に利用不可とされていることです。
向いている作業
向いているのは、短く、見える結果があり、取り消しや中断がしやすい作業です。たとえば、ローカルアプリの設定が保存されたか確認する、GUI上でしか出ない不具合を再現する、ブラウザのログイン後ではない安全なテストフローを通す、UI変更後に実ウィンドウで崩れがないか見る、といったものです。
依頼文には対象アプリ、禁止操作、停止条件を入れてください。例として「この設定画面を観察し、現在値を説明してから、保存ボタンを押す前に待ってください」と書くと、Codexは観察と操作を分けやすくなります。
別ルートのほうがよい場面
コードを直すなら、Codexにファイルとdiffを扱わせます。Webの構造を読むならブラウザ自動化やAPIを使います。繰り返し処理ならscriptにします。外部サービスと連携するなら、まずプラグイン、MCP、公式APIを探します。
Computer Useを、すべての自動化の上位互換として扱うと危険です。画面操作は便利ですが、構造化された権限、入力、出力を持つツールより監査しにくいからです。Claude側の画面操作と比較したい場合は Claude Computer Use を、開発ワークフロー全体の選択なら Claude Code vs Codex を分けて読むほうが判断しやすくなります。
安全停止ライン
支払い、銀行、パスワードマネージャー、本番管理画面、アカウント復旧、秘密情報、管理者認証、macOSのセキュリティ許可、不可逆削除は開始地点にしないでください。これらは見えていても、Codexにクリックさせるべき対象ではありません。
安全な運用は、観察、説明、承認、一手だけ実行、再確認です。Codexが「完了」と言ったときも、画面上のどの変化で完了を判断したかを聞いてください。画面を扱う機能だからこそ、完了条件も画面上の証拠で返させます。
アプリのComputer UseとAPI computer useは別物
CodexアプリのComputer Useは、人が見ているデスクトップ上で、承認したMacアプリをCodexに委任する使い方です。API computer useは、開発者がスクリーンショット、行動、状態管理、再試行、業務ルールを自分のコードに組み込む使い方です。
一時的なローカルGUI作業ならアプリ側が向いています。プロダクトや社内システムとして繰り返し実行するならAPI側の設計問題になります。この責任の違いを先に分けると、「Computer Useがあるなら何でも任せられる」という誤解を避けられます。
最初の安全な試し方
最初は低リスクなローカル作業を選びます。テスト用アプリまたはローカルWebアプリを開き、Codexには観察だけを頼みます。次に一つの操作案を説明させ、あなたが承認した一手だけ実行させます。最後に画面上の変化を説明させます。
この小さな往復で確認するのは、クリック能力ではありません。Codexが狭い目標を保ち、画面上の証拠を言語化し、危険な操作の前で止まれるかです。
よくある質問
Codex Computer Useは公式機能ですか？
はい。OpenAIの現在の文書では、CodexアプリのComputer Use能力として説明されています。
Windowsでも使えますか？
自動的に使えるとは書かないほうが安全です。Codexアプリ全体にはWindowsルートがありますが、Computer Useの確認済み文書はmacOS at launchとして説明しています。
TerminalやCodex自身を操作できますか？
その用途には使わないでください。コマンド、ファイル、リポジトリ作業は通常のCodex作業面で扱うほうが安全で再現性があります。
プラグインやMCP、APIとはどう選びますか？
対象が構造化されているならプラグイン、MCP、Shell、script、APIを優先します。実画面が証拠または操作面になるときだけComputer Useを選びます。