OpenAIのCodexにSlackスレッドのスクリーンショットを1枚渡し、「これ、そのまま作ってくれる?」と頼むだけで、動作するmacOS向けのリアルタイム翻訳アプリが4分2秒で完成しました。同じコーディングエージェントはクラウドサーバー上で一晩放置され、400人規模の聴衆向けライブQ&Aサイトの構築に15時間以上を費やしました。OpenAIのデベロッパーエクスペリエンスチームのメンバーによると、こうした成果と期待外れの結果を分けるのは巧みなプロンプトよりも、エージェントに渡すコンテキスト、エージェントが使えるプラグイン、そして人が介入するチェックポイントの3つだといいます。
プロンプトより先にコンテキストを渡す
翻訳アプリの出発点はSlackでのブレインストーミングでした。ある同僚がリアルタイム翻訳機を提案し、別の同僚がOpenAI Agents SDKとGPT Realtime APIで作ることを提案しました。エンジニアは会話をコピー&ペーストする代わりにappshotを使いました。Macで左右のCommandキーを同時に押すと、アクティブなウィンドウが内部のテキストやメタデータごとキャプチャされ、そのままCodexに送られます。
CodexはすぐにネイティブのmacOSアプリの骨組みを作り始めました。コードの記述、ビルド、検証、パッケージ化までにかかった時間は4分2秒です。完成したアプリStageTranslateはSwift、SwiftUI、AppKitで作られ、マイク入力、WebSocketクライアント、音声再生、OpenAI Realtime APIを組み合わせています。英語で話しかけるとリアルタイムで文字起こしし、ドイツ語訳を表示したうえで、その訳を読み上げます。
最初から完璧に動いたわけではありません。macOSのサウンド設定でマイク入力と音声出力を手作業で直すまで、音声の権限とデバイスの経路が噛み合いませんでした。この点は覚えておく価値があります。エージェントは数分でアプリを作れても、実際の機材と環境で動くかを確かめるのは、依然として人の仕事のようです。
このアプリを作ったエンジニアはデータサイエンティスト出身で、Swift、AppKit、WebSocketの経験はほとんどありませんでした。その穴を埋めたのが「Build macOS Apps」プラグインです。AppKitとの連携、ビルドとデバッグ、Liquid Glassのスタイル、署名と公証などを扱う11のスキルがまとめられています。
チームは音声入力とappshotを、AI開発ツールの中で最も活用されていない生産性機能の2つに挙げています。人はタイピングよりはるかに速く話せ、現在の言語モデルはまとまりのない話し言葉も明確な指示に変えられるからです。チームによれば、Codexはappshotだけで90%を超える割合でユーザーの意図を正しく読み取ります。
コンテキストを定着させる4つの仕組み
あるタスクのコンテキストを次のタスクへ引き継ぐ機能がいくつかあります。
| 機能 | 役割 | 知っておきたい点 |
|---|---|---|
| プラグイン | スキル(再利用できる指示とチームの作業手順)、外部アプリとの接続、MCPサーバー(外部ツールをAIにつなぐ標準の仕組み)をまとめる | 内蔵のディレクトリにGmail、Slack、GitHub、Figma、Google Driveなどのプラグインが並ぶ |
| Memories | Pythonのパッケージ管理にpipではなくuvを使うといった選択を、別々のスレッドをまたいで記憶 | 既定ではオフ。「Skip tool-assisted chats」設定で外部ツールやWeb検索の結果を記憶から除外できる |
| Chronicle | 短時間の画面コンテキストを取り込み、失敗したGitHub Actionsの診断など、ユーザーが何をしているかを推測 | Proサブスクライバー向けのオプトイン型リサーチプレビュー |
| パーソナライズ | すべての会話にカスタム指示を適用 | ホームディレクトリにAGENTS.mdファイルを置くのとほぼ同じ働き |
MemoriesとChronicleはモデルが処理するテキストの単位であるトークンをより多く消費しますが、プロジェクトの経緯を覚えているエージェントが得られるなら追加コストに見合うとチームは考えています。ツールやWeb検索から得る機密データを日常的に扱うなら、「Skip tool-assisted chats」をオンにしておくほうが安全です。
OpenAI Developersプラグインを使うと、ブラウザのダッシュボードに移動しなくてもCodexがOpenAIのAPIキーを作成・設定できるため、キーの紛失や集中の中断を防げます。また、厄介な問題をあるスレッドで解決したら、その手順を新しいスキルやプラグインとして保存するようCodexに頼めます。次からは指示なしで同じ作業をこなせます。
Codexがコンピューターを操作する3つの方法
大企業では、価値あるデータがAPIのない古い社内ダッシュボードに閉じ込められてしまうことがあります。この問題を示すために作られた模擬例では、リポジトリ分析ダッシュボードからレポートを取り出すのに、カレンダーの日付ピッカーをクリックし、カテゴリーごとにダウンロードボタンを押す必要がありました。
この作業を引き受けたのが、人と同じように画面を見てマウスとキーボードを操作するCodexのcomputer use機能です。エンジニアは音声で、直近7日間のコミット履歴をCSVファイルで、6月初めから現在までのプルリクエストのデータをJSONで出力するよう頼みました。Codexはレイアウトとアクセシビリティ識別子を調べ、独自のソフトウェアカーソルで日付ピッカーを操作しました。実行中の複数のアプリが同じバンドル識別子を共有していたときは、推測せずにウィンドウ名で対象を指定しました。macOSではcomputer useがユーザーのカーソルを奪わないため、人はほかのウィンドウで作業を続けられます。
Web上の作業も同じです。CodexはGoogle Docsのドキュメントに下書きされたアンケートの質問を読み取り、多肢選択式、均等目盛、自由記述の質問としてGoogle Formsに組み込み、すべてを必須に設定しました。繰り返しのクリックが多く、切り替えを忘れやすい作業です。
| 方式 | 呼び出し方 | 向いている作業 |
|---|---|---|
| ネイティブのcomputer use | @computer または @アプリ名 | APIのないデスクトップアプリや古いソフトウェア |
| Chrome拡張機能 | @chrome | ログイン済みのブラウザで行うWeb作業 |
| アプリ内ブラウザ | @browser | ローカルのWeb開発、レイアウトとDOMの検査、操作テスト |
画面を表示せずに動くブラウザであるheadless Chromiumでの自動化は、終わりのないCAPTCHAやログインのブロックに阻まれがちです。Chrome拡張機能はすでにログインしているセッションの中で動くため、Gmailのようなサービスや多要素認証のかかったアプリに適しています。

▲ ユーザーのカーソルと並行して動くcomputer use
長時間タスクには目標と監督が必要
大規模な開発タスクは5時間から20時間かかることがあります。前夜にクラウドサーバーで開始した3つのジョブから、その規模がわかります。
| タスク | 実行時間 | Codexが作ったもの |
|---|---|---|
| ライブQ&Aサイト | 15時間30分55秒 | 400人規模の聴衆向けの新規サイト。リアルタイム同期にConvex、ホスティングにVercel、OpenAI Moderation APIを使用 |
| 社内フォームビルダー | 5時間57秒 | オープンソースのフォームビルダーを、ChatGPTのサインインで保護された社内ツールに改造 |
| 最適決定木パッケージ | 7時間1分40秒 | もともとJuliaとRで書かれた研究アルゴリズムを実装した、Rustバックエンドを持つPythonパッケージ |
15時間の実行を見守り続けることは誰にもできません。そのため監督の仕組みは最初から組み込んでおく必要があります。
- 目標ファイル:計画とマイルストーンをGOALS.mdファイルに書かせます。
- 進捗ダッシュボード:progress-dashboard.htmlファイルを生成させ、マイルストーンの状態(完了、進行中、保留)、テストの合格率、未解決のブロッカーを更新し続けさせます。
- 監査スレッド:1本の長いスレッドにせず、コードレビューと目標監査のための別スレッドをCodexに立ち上げさせます。マイルストーンごとに監査スレッドが作業内容をGOALS.mdと照らし合わせ、逸脱があればメインスレッドを引き戻します。
- Slackへの報告:完了したマイルストーン、進行中の作業、APIキーの不足といったブロッカーをSlackチャンネルに投稿させます。週末はそのスレッドをスマートフォンで確認し、必要なときにエージェントのブロックを解除できます。
- サイドスレッド:
/sideコマンドでメインスレッドの横に一時的な会話を開き、直近1時間に何があったか、次に何をするか、何が進行を妨げているかを尋ねます。サイドスレッドは消えるため、残すべき決定はメインスレッドに戻しておきます。
認証情報がなくデプロイが止まったときは、ブロックされた項目をサイドスレッドに送り、段階的な対処法を尋ねました。Codexは、Convexのデプロイキーをリモートの環境ファイルに直接書き込むシェルコマンドを返しました。これでシークレットがチャット履歴に残りません。
クラウドのスレッドは、開発者自身のマシンにあるChromeブラウザにはアクセスできません。代わりにリモートのスレッドがローカルのワーカースレッドにブラウザテストを任せ、結果を報告させます。ある例では、開発者が眠っていた午前3時にローカルのワーカーがChromeを開き、フォーム作成の流れを最初から最後まで検証しました。
「完了」をプログラムで確認できるものにする
/goal コマンドは持続的な目標を設定し、Codexは推論のたびに成功基準と照らし合わせてから、マイルストーンを完了とするか判断します。曖昧な目標は、エージェントが文面は満たしても意図は満たさない「猿の手」のような結果を招きます。そのため基準はテストスイートや文字列の完全一致など、プログラムで確認できるものにすべきです。ある開発者はこの方法でCodexを40時間動かし続け、DoomをSwiftで再実装しました。主な用途は大規模なコードベースの移行、リファクタリング、デプロイの再試行ループ、自動化された実験です。
こうした長時間の実行を可能にしているのがコンパクションです。スレッドが長くなるにつれ、プロジェクトの重要な状態を残してノイズを捨てます。2025年11月19日にGPT-5.1-Codex-Maxとともに登場し、このモデルはモデルが一度に考慮できるテキスト量の上限であるコンテキストウィンドウを複数またいで作業するよう学習されています。チームによれば、これによりエージェントが以前の要件を忘れずに済み、トークンも節約できます。

▲ メインスレッドと監査スレッドの役割分担
作業を分ける:サブエージェント、ハンドオフ、フック
サブエージェントはタスクの一部を自分専用のコンテキストウィンドウで受け持つため、メインの会話を散らかしません。subagents.toml ファイルで、それぞれの説明、ツールの権限、サンドボックスのポリシー、推論の強さを定義します。フロントエンド、バックエンド、テスト、ドキュメント調査、コードレビューといった役割を作り、定型的なチェックには小型で高速なモデルを、念入りなレビューには推論能力の高いモデルを割り当てられます。推奨される方法ではありませんが、初期ビルドのスクリーンショットに「not very good」とだけ添えて送っても十分でした。Codexはチャット領域が窮屈だと判断し、メインスレッドが修正をUI担当のサブエージェントに渡し、そのサブエージェントがレイアウトを調整してブラウザで結果を検証しました。
スレッド間のハンドオフは、委任の過程を人から見える状態に保ちます。目安は、委任を自分で見る必要があるならハンドオフ、メインのモデルだけが知っていればよいならサブエージェントです。ある週末のゲーム制作では、「クリエイティブディレクター」スレッドがアート、音楽、アニメーション、ゲームメカニクスのスレッドを統括し、AGENTS.mdで各スレッドが作業完了の前にディレクターの承認を得るよう定めていました。
フックはCodexのライフサイクルの決まった時点で固定のスクリプトを実行する仕組みで、config.toml で設定します。主な用途は次のとおりです。
- APIキーなどのシークレットが漏れないようプロンプトを途中で確認する
- 実行しようとするシェルコマンドを承認済みリストと照合する
- 会話ログを社内のオブザーバビリティや分析のシステムに送る
- ターンの終了時に、テストと、コードをスタイル規則に照らして確認するツールであるリンターを実行する
OpenAI Agents SDKのリポジトリでは、Codexがターンを終えるたびにフックがPythonの整理スクリプトを実行します。チームは、エージェントに自律性を与えるほど、モデルの判断に頼らないこうしたガードレールが必要になると強調しています。
スケジュールで動く自動化
Codexは2種類の自動化に対応しています。
| 種類 | 仕組み | 例 |
|---|---|---|
| スレッド内のハートビート | 既存のスレッド内でタイマーにより起動し、何かを確認する | 新しいサーバーの準備完了まで確認を続ける。Slack、メール、Linearの変更を毎日Obsidianのノートにまとめる |
| 新規スレッドのスケジュール | 決まった時刻に新しいスレッドを開いてバッチ処理を行い、確認後にアーカイブする | 週次のチーム要約と分析の集計 |
DigitalOceanプラグインによるクラウドサーバーのプロビジョニングには数分かかるため、Codexは5分ごとに確認するハートビートを自ら設定しました。サーバーの準備が整うと、ハートビートを削除してSSHキーを設定しました。
Slack、スケジュール、そして同じリポジトリの作業コピーを別々に持てるgit worktreeを組み合わせると、保守作業をバックグラウンドの仕事にできます。ある自動化は翻訳アプリのフィードバック用Slackチャンネルを30分ごとに読み、メッセージを称賛、バグ報告、機能要望に分類します。バグと要望についてはブランチとworktreeを作って変更を実装し、プルリクエストを開いてレビュアーを割り当て、24時間以内にレビューが行われなければ催促します。
個人の自動化にも使えます。金曜日のジョブでその週の会話を振り返り、AGENTS.mdのスキルを追加、改善、削除できます。別の自動化はメールの返信案を作り、後で実際に送られたメッセージと比べて違いを次回のための好みとして記録します。
これらすべての土台にあるのが、オープンソースのapp-serverプロトコルです。JSON-RPCによる橋渡しで、デスクトップアプリ、ターミナルのCLI、Visual Studio Codeの拡張機能を同じエージェントハーネスにつなぎます。JetBrainsのIDEやXcodeなどのツールも同じ方法で接続でき、開発者は既存のChatGPTプランで動く独自のクライアントを作れます。その一例として、4時間のバックグラウンド実行でレトロなデザインの独自Codexクライアントが作られ、そのセッションは通常のデスクトップアプリと同期しました。
Codexに仕事を任せる前に整えること
これらの例に共通するのは、個々のプロンプトの言い回しよりも、エージェントを取り巻く仕組みのほうが重要だという点のようです。チームは、現在の推論モデルにプロンプトの小技は要らず、豊富で明確なコンテキストと曖昧さのない目標が必要だと主張します。そして、次のような問いを繰り返し投げかけることを勧めています。
- 自分でやる前に、実際にCodexにタスクを任せてみたか
- 完了を妨げているのは権限か、コンテキストか、ツールか
- 単発のプロンプトを繰り返し回るループにできないか
- この時点で本当に人が介入する必要があるか
今すぐ取り組める実践的な手順は次のとおりです。
- コンテキストはコピー&ペーストではなく、appshotと音声入力で渡します。
- 数時間かかる作業では、目標ファイル、進捗ダッシュボード、監査スレッドを最初に指示します。
- 完了の条件は、テストなどプログラムで確認できるもので定義します。
- シークレットをファイルに書き込むコマンドを頼み、チャットにシークレットを残さないようにします。
- 自律的な作業のガードレールとして、フックでテストとリンターを自動実行します。
エージェントが数分でアプリを作れても、実際の機材で動くか、本当に目標を満たしているかは人が確かめる必要があります。そうした確認をどこで行うかを前もって決めておくことが、より長い作業をCodexに任せるための第一歩です。