OpenAIのCodexを、単なる「コードを書いてくれるAI」と見ていると、いま起きている変化を少し見誤るかもしれない。Codexのロードマップは、より良いコード生成だけでなく、ユーザーが作業を渡し、エージェントが並行して進め、必要に応じてアプリやブラウザまで操作する方向へ整理されつつある [17][
18][
21]。
とはいえ、これは「もう万能のPCアシスタントが完成した」という話ではない。OpenAI自身の説明でも、Codexの中心はまだ開発者向けワークフローにあり、Computer Useは現時点でmacOS向け、かつローンチ時点では欧州経済領域（EEA）、英国、スイスでは利用対象外とされている [18][
23]。
変化の本質は「回答」ではなく「委任」
Codexはもともと、codex-1を搭載し、多くのタスクを並行して処理できるクラウド型のソフトウェアエンジニアリング・エージェントとして紹介された [13]。この出自は今も強く残っている。現在のCodexアプリのドキュメントでも、並列のCodexスレッド、worktree、オートメーション、Git機能を備えたデスクトップ体験として説明されている [
17]。
ただし、最近の方向性で重要なのは、Codexが「答えを表示する場所」から「仕事を走らせる場所」へ近づいている点だ。OpenAIはCodexアプリを、複数のエージェントを同時に管理し、作業を並列実行し、長時間かかるタスクでエージェントと協働するためのmacOS向けインターフェースとして発表した [25]。
つまり、プロンプトに一問一答で返す道具というより、いくつかの仕事を渡して進捗を見守り、必要なタイミングで人間が戻って共同作業する「作業キュー」に近づいている。
Computer Useが、コーディングの外側へ踏み出す鍵
最も分かりやすい拡張がComputer Useだ。OpenAIのドキュメントによると、ユーザーはComputer Useプラグインをインストールし、macOSの「画面収録」と「アクセシビリティ」の権限を許可することで、CodexがmacOS上のグラフィカルユーザーインターフェースを見て操作できるようになる [18]。
OpenAIはこの機能を、コマンドラインや構造化された連携だけでは足りない場面向けだと位置づけている。たとえばデスクトップアプリの確認、ブラウザ操作、アプリ設定の変更、プラグインとして用意されていないデータソースの利用、GUIでしか再現しない不具合の検証などだ [18]。
ユースケース文書では、CodexがMac上のアプリをクリックし、文字を入力し、画面を移動できること、さらにMacアプリ、ウィンドウ、ブラウザセッション、ローカルファイルをまたぐ複数ステップの作業を任せられることが説明されている [19]。
これはCodexの役割を大きく変える。Codexはコードや手順を「提案する」だけでなく、対応環境ではソフトウェアの中で実際に「動く」ことができる。ただし、繰り返しになるが、Computer Useは現時点ではmacOS向けで、ローンチ時点ではEEA、英国、スイスを除く提供とされている [18]。
プラグインは整った作業に、Computer Useはこぼれ落ちる作業に
OpenAIは、Codexの周辺にプラグインと連携の層も作っている。2026年3月のCodex changelogでは、プラグインが「first-class workflow」、つまり主要なワークフローとして扱われるようになり、Codexが起動時にプロダクト単位のプラグインを同期し、/pluginsで閲覧し、認証やセットアップを分かりやすくしながらインストール・削除できるようになったと説明されている [21]。
2026年4月のchangelogでも、マーケットプレイスからのインストール、リモートバンドルのキャッシュ、リモートアンインストールなど、プラグインまわりの改善が挙げられている [20]。
さらにCodexはチーム作業にも入り込んでいる。OpenAIはCodexの一般提供を発表した際、チームのチャンネルやスレッドからCodexにタスクを委任したり質問したりできるSlack連携と、Codexのエージェントをワークフロー、ツール、アプリに組み込むためのCodex SDKを紹介した [29]。
見取り図は比較的はっきりしている。API、プラグイン、チームツールで処理できる作業は構造化された連携で進める。一方、ローカルアプリ、ブラウザセッション、設定画面、プラグイン化されていないインターフェースに依存する作業はComputer Useで扱う、という役割分担だ [18][
21][
29]。
並列スレッドと記憶は「継続するエージェント」への布石
日常的な作業エージェントに必要なのは、単発の返答だけではない。複数の仕事を同時に管理し、途中経過を保ち、後から人間が戻って続きを進められる場が必要になる。
Codexアプリはこの方向に向かっており、並列スレッド、worktree、オートメーション、Git中心のワークフローを備えると説明されている [17]。OpenAIのアプリ発表でも、複数エージェントの管理、並列実行、長時間タスクでの協働が強調された [
25]。
もう一つの重要な要素が永続性だ。OpenAIのコミュニティ向け発表では、Codexはコーディングを超えてより広い範囲の仕事を支援する方向に拡大している一方、焦点は引き続き強力な開発者ワークフロー、より良い連携、プロジェクト間の摩擦削減にあるとされている [23]。同じ発表では、メモリのプレビュー、将来的な作業スケジューリング、進行中プロジェクトへのより能動的な支援も示されている [
23]。
一回きりのコード補助なら、現在の質問に答えるための文脈があれば足りる。しかし、仕事を任せるエージェントには、セッションをまたいで文脈を保ち、好みや進め方を覚え、繰り返し発生する作業を再開する力が必要になる。OpenAIはこれらをプレビューや今後の方向性として説明しており、Codexがすでに完成した汎用オフィスアシスタントであると主張しているわけではない [23]。
GPT-5.4は、このエージェント化を支えるモデル層
製品の変化と並行して、モデル側の戦略も動いている。OpenAIはGPT-5.4をChatGPT、API、Codexで提供するとし、プロフェッショナルな仕事向けの最も高性能で効率的なフロンティアモデルだと説明している [9]。
さらにOpenAIは、GPT-5.4について、CodexとAPIで提供する初の汎用モデルであり、ネイティブなcomputer-use能力を備え、エージェントがコンピューターを操作し、複数アプリにまたがる複雑なワークフローを実行できるようにすると説明している [9]。
デスクトップ操作は、単にUI上の権限を与えれば済むものではない。画面を解釈し、次に何をすべきか判断し、複数ステップの作業を続けるモデル側の能力が必要になる。OpenAIはGPT-5.4を、その能力スタックの一部として位置づけている [9]。
それでも、Codexはまだ万能アシスタントではない
現時点のCodexを最も正確に表すなら、「開発者ファーストのエージェント基盤が、より広いPC作業へ拡張している段階」だろう。
根拠はOpenAI自身の説明にある。Codexアプリのドキュメントは、今も並列Codexスレッド、worktree、オートメーション、Git機能を中心に据えている [17]。Codexの拡張を伝える発表でも、より広い仕事への対応を掲げつつ、焦点は開発者ワークフロー、統合、プロジェクト上の摩擦削減にあるとされている [
23]。そして最も汎用的に見えるComputer Useも、現在はmacOS向けで、ローンチ時点では地域制限がある [
18]。
したがって、Codexの新しさは「もっと多くの質問に答えられる」ことだけではない。ユーザーがアプリ、ファイル、ブラウザ、接続サービス、長期プロジェクトにまたがる作業を任せるための操作面になりつつある点にある [17][
18][
19][
21]。
まとめ
OpenAIがCodexを日常的なPC作業エージェントへ近づけるために組み合わせているのは、主に3つの層だ。並列で長時間走るエージェントを管理するデスクトップアプリ、プラグインとComputer Useからなる実行レイヤー、そしてGPT-5.4のネイティブなcomputer-use能力である [17][
18][
21][
9]。
その結果、Codexはコード生成ツールから、コンピューター上の仕事を委任するための場へ移りつつある。ただし、その出発点も主な利用領域も、今のところは開発者ワークフローにある [17][
23]。
