ChatGPTで、Workというサービスの提供が開始され、特定の用途ではCodexと同様の処理が可能であるということなので、現在、Codexで実行している処理を、Workで実行するように変更すべきかを調査した。また、Codexの各機能について、Workで同様の処理を行えるかについてGPT-5.6 Solを用いて調査した。
（注）本記事の内容は正確性を保証するものではない。
（2026年7月11日 追記）YouTube動画を追加しました。 https://youtu.be/NikHCbQuQ7M
毎朝受けているニュース配信の例
現在、GoogleのRSSを情報源として、AIやCarPlayに関する情報を毎日収集し、重複を除去して電子メールで配信してもらう定期実行タスクをCodexで実行しています。これは、Codexで継続すべきか、Workに移すべきでしょうか
結論として、現在のCodexタスクが安定して動いているなら、そのままCodexで継続するのが適切です。
この処理は「情報を考えてまとめる」だけでなく、RSS取得・既読履歴の保存・重複判定・メール送信という、状態管理と確実性が重要な処理を含みます。
Workへ全面移行するより、必要に応じて要約・記事選別部分だけWorkに任せる構成が向いています。
CodexとWorkの適性比較
| 比較項目 | 現在のCodex構成 | Workへ移行 | 今回の適性 |
|---|---|---|---|
| Google RSSの取得 | スクリプトで安定して取得可能 | Webアクセスやツールで取得可能 | Codexが有利 |
| URLや記事IDによる重複除去 | JSON・SQLiteなどへ確実に保存可能 | 前回実行の文脈を参照できるが、厳密な永続DB管理には工夫が必要 | Codexが有利 |
| 過去に配信した記事の長期保存 | ローカルファイルやDBで管理可能 | Workの会話履歴・監視履歴に依存しやすい | Codexが有利 |
| タイトルの類似判定 | コード＋AIの併用が可能 | AIによる意味的な重複判定が得意 | Workがやや有利 |
| 記事の重要度判定 | プロンプトやコードで可能 | 一般業務として自然に判断できる | Workがやや有利 |
| 日本語要約の作成 | 可能 | 得意 | ほぼ同等 |
| メール本文の整形 | テンプレートで安定 | 読みやすい文章生成が得意 | 用途による |
| メールの自動送信 | Gmail API・SMTP等で確実に実装可能 | Gmailアプリの権限と承認条件に依存 | Codexが有利 |
| Macを停止しても実行 | ローカル実行なら不可 | クラウドWorkなら可能 | Workが有利 |
| 正確な実行時刻 | launchd／cron等に任せられる | 日次処理には十分だが、外部サービスや利用枠の影響を受ける | Codex側が安定 |
| 失敗時の再試行 | コードで細かく設定可能 | Workに指示できるが制御の厳密さは低い | Codexが有利 |
| 実行ログ | ファイルとして詳細に残せる | Workの外部取得可能な詳細ログは限定的 | Codexが有利 |
| HAダッシュボード連携 | 現在の仕組みをそのまま活用可能 | 独自の状態送信が必要 | Codexが有利 |
| 保守の容易さ | コードの管理が必要 | 自然言語で条件を変更しやすい | Workが有利 |
| 利用枠停止時の影響 | AIを使う部分は影響を受ける | Work全体が影響を受ける | Codex構成の方が分離しやすい |
Workのスケジュール済みタスクは、日次ブリーフや継続監視に対応し、Gmailなどの接続アプリも利用できます。
ただし、利用できる操作は付与された権限に依存し、管理設定によっては承認が必要になったり、一部操作を実行できなかったりします。(OpenAI Help Center)
今回、Codexを継続した方がよい理由
1．重複除去には「確実な記録」が必要
重複除去では、少なくとも次の情報を毎回保存する必要があります。
| 保存項目 | 用途 |
|---|---|
| 記事URL | 完全一致の重複除去 |
| Google Newsの識別子 | 中継URLが変わった場合の判定 |
| 原文タイトル | タイトル一致・類似判定 |
| 配信日時 | 検索対象期間の管理 |
| 情報カテゴリ | AI、CarPlay、Android Autoなどの分類 |
| メール送信結果 | 取得済みだが未送信の記事を識別 |
| エラー・再試行回数 | 送信漏れの防止 |
Codexのローカル処理なら、これらをJSONやSQLiteへ確実に保存できます。
Workの監視タスクも過去の実行を記憶して、重要な変化があるときだけ報告できます。(OpenAI Help Center)
ただし、「記憶しているから同じ記事を出さない」というAI判断より、URLや記事IDをDBで照合する方が配信システムとして確実です。
2．メールの完全自動送信はCodex側が安定
Workのスケジュール済みタスクはGmailなどのアプリを利用できますが、OpenAIの公式利用例は、メールを自動送信するよりも、下書きを作成し、人が確認してから送信する運用を推奨しています。(OpenAI Developers)
現在のCodex処理がGmail APIやSMTPなどでメールを送信しているなら、
RSS取得
↓
重複除去
↓
要約・整形
↓
メール送信
↓
送信済みとしてDB更新という一連の処理を、トランザクションに近い形で管理できます。
Workへ移すと、
RSSを調べる
↓
前回内容との重複をAIが判断
↓
メール本文を作る
↓
Gmail操作の権限・承認を確認
↓
送信または下書きとなり、完全自動送信に関する不確定要素が増えます。
3．現在のHA監視をそのまま利用できる
あなたの現在の構成では、Codexの実行状態、進捗、トークン、処理時間などをHome Assistantで監視しています。
（補足）次の章で詳述する。
Workへ移すと、次の情報が取りにくくなります。
| 監視項目 | Codex | Work |
|---|---|---|
| タスク開始・終了 | 取得しやすい | 独自記録が必要 |
| 実行工程 | ログから追跡可能 | Workに書き出させる必要 |
| エラー内容 | ローカルログから取得可能 | 外部からの取得が難しい |
| RSS取得件数 | スクリプトログから取得可能 | 独自記録が必要 |
| 重複除外件数 | 正確に取得可能 | AI判断では集計が曖昧になり得る |
| メール送信結果 | APIの応答を保存可能 | 接続アプリの処理結果に依存 |
| トークン内訳 | Codex履歴から取得できる場合がある | Work単独値は取得しにくい |
そのため、現在の監視システムを含めると、移行コストの割に得られる利点が小さいと考えられます。
Workへ移行する価値があるケース
次の条件が多く当てはまるなら、Workへの移行を検討できます。
| 条件 | Work移行の価値 | 私の判断（追記内容） |
|---|---|---|
| Macを常時起動したくない | 高い | Mac mini常時起動で問題なし |
| RSSだけでなくWeb検索も幅広く行いたい | 高い | 他の情報も魅力的だが、情報過多になっても困る |
| Gmailへの配信ではなく、ChatGPTの通知でよい | 高い | 電子メールの方が見逃しが少ない |
| 重複除去は多少曖昧でも問題ない | 中 | |
| 毎日の情報から重要な記事だけ選びたい | 高い | 1テーマにつき、配信記事数は多くても5件なので、さらなる選別は不要 |
| 読みやすい日本語ブリーフを自動生成したい | 高い | 詳細を知りたい記事だけを「共有」でChatGPTに別途ブリーフを確認するので不要 |
| ローカルDBやログを管理したくない | 高い | 管理が必要とか、データが肥大化するとは思っていなかった |
| メールは自動送信せず、下書きでよい | 高い | 電子メール配信の方が、他の通知に埋もれず見逃しが少ない |
| HAダッシュボードで細かく監視しなくてよい | 高い | もともと監視対象とは考えておらず、電子メールの配信があれば正常動作していることが分かる |
Workはクラウド上でスケジュール、トリガー、変化監視を行えます。
Web上のWorkタスクは、接続ツール、アップロードした情報、Skillsなどを使用できますが、Mac上のローカルフォルダを直接維持するものではありません。(OpenAI Help Center)
おすすめの構成
全面移行ではなく、次の分担が適しています。
| 工程 | 担当 | 理由 |
|---|---|---|
| RSS取得 | ローカルスクリプト | 高速・確実・低コスト |
| URL正規化 | ローカルスクリプト | 決定的に処理できる |
| 配信済みDBとの照合 | ローカルスクリプト | 重複を確実に防止 |
| タイトルの完全一致除去 | ローカルスクリプト | AI不要 |
| タイトルの意味的重複判定 | CodexまたはWork | AIが有効 |
| 記事の重要度判定 | Work | 一般読者・ブログ視点の判断が得意 |
| 日本語要約 | WorkまたはCodex | どちらでも可能 |
| メール本文生成 | Workまたはテンプレート | 品質重視ならWork |
| メール送信 | ローカルスクリプト | 成否を確実に管理 |
| 実行状況の監視 | Home Assistant | 現在の仕組みを維持 |
| スクリプトの保守 | Codex | コード変更・テスト向き |
構成イメージは次のとおりです。
Codexが作成・保守するローカル処理
├─ Google RSS取得
├─ URL正規化
├─ 既配信DBとの照合
├─ 候補記事をJSONへ保存
└─ メール送信・結果記録
↓
必要に応じてWork
├─ 意味的な重複判定
├─ 記事の重要度評価
├─ 日本語要約
└─ メール本文の編集
↓
Home Assistant
├─ 取得件数
├─ 重複除外件数
├─ 採用記事数
├─ 送信結果
└─ 次回実行日時最終判断
| 選択肢 | 評価 |
|---|---|
| 現在のCodexタスクをそのまま継続 | 推奨 |
| 全処理をWorkへ移行 | 現時点では非推奨 |
| 取得・重複除去・送信はCodex、選別・要約はWork | 最も機能的 |
| 将来的にクラウド化する | Work単独ではなく、クラウドDBや定型処理との組み合わせを推奨 |
現在のタスクは、単なる「毎日のニュース要約」ではなく、重複管理とメール配送を備えた小規模な情報配信システムです。したがって、今のCodex構成が安定している限りは継続し、Workは記事選別や要約品質を改善したい部分にだけ導入するのが妥当です。
特別難しいニュース配信ではないと思っていたので、CodexとWorkの差は小さいのではないかと考えていたが、より信頼性が高く、重複除去（同日での重複記事排除、及び、直近1週間以内での重複記事排除）という付加価値を付けたニュース配信については、Codexでの実行を継続すべきであることが確認できた。
Workには、過去の履歴が不要な「変化監視」のタスクを依頼し、他の同様のサービスと色々な観点で比較したい。
Home AssistantのCodex監視ダッシュボード
Codexの処理の状況を添付画像（下記画像）のダッシュボード（Home Assistantのダッシュボード）を作成してモニターしています。
Workも同様の考え方でダッシュボードを作成できると思いますか
はい、Workも同じ考え方で監視ダッシュボードを作れます。
ただし、添付画像のCodexダッシュボードをそのまま複製できるわけではありません。
特に、現在のダッシュボードにある次の項目のうち、
- 5時間枠・7日枠
- 入力／出力／キャッシュトークン
- 処理別の推定費用
- コンテキスト使用量
- ジョブの進捗段階
利用枠は共通値として監視できますが、Work単独のトークン量や費用を取り出す部分には工夫が必要です。
各項目をWorkでも表示できるか
| 現在の表示項目 | Workでの実現性 | 考えられる取得方法 | 注意点 |
|---|---|---|---|
| Workジョブ名 | ◎ | Workの会話タイトル、または開始時にジョブIDを付与 | 任意の名前を付けると安定 |
| 実行中・完了・停止 | ◎ | Work自身に状態ファイルを更新させる | 公式の個人向け状態取得APIは確認できない |
| 進捗段階「4/5」 | ◎ | 作業開始時に工程を定義し、各工程完了時に記録 | Work標準の内部工程番号を直接読むのではなく、自前管理が確実 |
| 開始・終了時刻 | ◎ | 状態ファイルやGoogle Sheetsなどへ記録 | クラウド実行ではMac内ファイルに直接書けない場合がある |
| 処理別の所要時間 | ◎ | 各工程の開始・完了時刻から計算 | 自前のタイムスタンプが必要 |
| 5時間枠 | ◎ | 現在のCodex側の利用枠取得処理を流用 | WorkとCodexの合算値になる |
| 7日枠 | ◎ | 同上 | Work単独の割合には分離できない可能性 |
| 使用枠のリセット時刻 | ◎ | Codex Usage画面または現在の取得処理 | 共通エージェント枠として表示 |
| 購入クレジット残高 | ○ | CodexのUsage Dashboard | WorkとCodexで共通の残高 |
| Work単独の入力トークン | △ | ローカルログの調査、または利用量の前後差 | 公式にWork用の詳細ログ仕様は公開されていない |
| Work単独の出力トークン | △ | 同上 | スライドや画像、ツール操作を含むと単純ではない |
| キャッシュ済み入力 | △ | Workログに記録されていれば取得 | Codexと同じ形式で保存される保証はない |
| 推論トークン | △ | ローカルログの実測 | Workで常に公開されるとは限らない |
| コンテキスト使用量 | △ | ローカル履歴から推定 | Workの内部コンテキスト全体は見えない可能性 |
| 処理別費用 | ○～△ | クレジット残高・利用量の実行前後差 | 円換算は推定値になりやすい |
| 承認待ち・入力待ち | ○ | 状態ファイル、通知、画面状態 | 外部取得用APIは未確認 |
| 利用制限で停止 | ○ | エラーログまたは利用枠＋更新停止を組み合わせて判定 | 「通信停止」と「枠停止」の区別が必要 |
Work、Codex、ChatGPT for Excelなどは、対象プランでは同じエージェント利用枠とクレジット残高を共有します。
CodexのUsage Dashboardには残高と最近の使用量が表示されるため、添付画像の5時間枠・7日枠のカードは、Work導入後も共通利用枠の表示として利用できます。(OpenAI Help Center)
最も重要な違い
Codexの場合
現在のダッシュボードは、Codexが保存するローカルのスレッド履歴やイベントを読み取り、次の情報を集計していると考えられます。
Codexのローカル履歴
↓
ターン、トークン、モデル、時刻を抽出
↓
費用・進捗・利用率を計算
↓
Home Assistantへ表示Codexには、API要求、応答、ツール実行、承認、エラー、完了時のトークン数などをOpenTelemetry形式で出力する公式機能もあります。
したがって、Codexは外部ダッシュボードとの連携を比較的構築しやすい設計です。(OpenAI Developers)
Workの場合
WorkはCodexの技術を内蔵していますが、Codexと同じローカル履歴形式やOpenTelemetry出力をWorkでも使えるとは、公式には説明されていません。
Workの画面では進捗確認、質問への回答、方向変更、重要操作の承認が可能ですが、そのデータを個人ユーザーが外部プログラムから取得する公開APIは現時点で確認できません。(OpenAI)
そのため、Workについては次の構成が確実です。
Work
↓ 各工程の開始・完了時に状態を記録
状態ファイル／Google Sheets／データベース
↓
集計プログラム
↓
Home Assistantおすすめの構成
ローカル版Workを使う場合
ChatGPTデスクトップ版のWorkには、ローカルファイルやアプリを扱える機能があります。
そこで、各Workジョブに次のような指示を加えます。(OpenAI)
作業開始時に5段階の工程を定義してください。各工程の開始時と完了時に、指定した
work_status.jsonを更新してください。エラー、入力待ち、承認待ち、利用制限で停止した場合も状態を記録してください。
状態ファイルは、例えば次の形式です。
{
"job_id": "work-20260711-001",
"title": "Android Auto最新情報の調査",
"status": "running",
"stage": 3,
"total_stages": 5,
"stage_name": "記事構成を作成中",
"started_at": "2026-07-11T14:20:00+09:00",
"updated_at": "2026-07-11T15:05:00+09:00",
"execution": "local",
"needs_input": false,
"estimated_credits": null
}このファイルを現在のCodex監視プログラムと同様に読み取れば、添付画像の上段に近い表示を作れます。
クラウド版Workを使う場合
Web・モバイルで開始したWorkは、Mac内のJSONファイルを直接更新できないケースがあります。
その場合は、Workが書き込める接続先を中継します。
| 中継先 | 適性 | 特徴 |
|---|---|---|
| Google Sheets | ◎ | Workが行単位でジョブ状態を更新しやすい |
| Google Drive上の文書 | ○ | 状態履歴としては使えるが解析しにくい |
| ChatGPT Sites | ○ | Work内でライブダッシュボードを作りやすい |
| Dropbox上のファイル | △ | 使用するプラグインに書き込み機能がある場合 |
| Home AssistantのWebhook | △ | WorkからHTTP送信できる環境・プラグインが必要 |
| Mac内のJSON | ×～○ | クラウド実行では不可、デスクトップ実行なら可能 |
Workには、Sheets、ドキュメント、スライドなどを接続アプリ経由で更新する機能があります。
また、Sitesはライブダッシュボードやプロジェクトトラッカーの作成用途として案内され、元データの変化に合わせて更新できます。(OpenAI)
利用枠は分けずに表示するのが適切
添付画像では「Codex使用量」となっていますが、Workを使い始めた後は、次のように名称を変えるのが正確です。
| 現在の名称 | 変更案 |
|---|---|
| Codex使用量 | エージェント共通使用量 |
| Codex 5時間枠 | Work／Codex 共通5時間枠 |
| Codex 7日枠 | Work／Codex 共通7日枠 |
| Codex費用 | Codex処理別費用 |
| 新設 | Work処理別推定費用 |
WorkとCodexが同じ枠を使うため、例えば次のような表示になります。
エージェント共通使用量
├─ 5時間枠：23%
├─ 7日枠：4%
├─ 次回リセット：02:45
└─ 内訳
├─ Codex：推定18%
└─ Work：推定5%ただし、内訳の18％と5％は公式値ではなく、各処理の実行前後差から算出した推定値になります。
Workの費用を処理別に推定する方法
現実的には、各ジョブの開始前と終了後に共通利用量を記録します。
| 時点 | 5時間枠使用率 | 差分 |
|---|---|---|
| Work開始前 | 23.0% | — |
| Work終了後 | 27.5% | 4.5ポイント |
| 推定Work消費 | — | 4.5ポイント |
クレジット残高が使われている場合も同様です。
開始前：1,000 credits
終了後：972 credits
Workジョブの消費：28 creditsこの方法なら、正確な入力・出力トークンを取得できなくても、そのWorkジョブが共通枠や購入クレジットをどの程度消費したかを記録できます。
実現性の判断
| ダッシュボード部分 | 判断 |
|---|---|
| Workの実行中ジョブ一覧 | 実現可能 |
| 進捗段階 | Workに明示的に記録させれば実現可能 |
| 開始・終了・経過時間 | 実現可能 |
| 入力待ち・承認待ち | 状態記録を組み込めば実現可能 |
| 5時間・7日枠 | 現在の共通枠表示を流用可能 |
| WorkとCodexの個別使用率 | 推定なら可能 |
| Workの正確なトークン内訳 | 現時点では保証できない |
| Workの正確な処理別円換算 | クレジット差分なら可能、プラン内枠では推定 |
| Home Assistantへの統合 | 十分可能 |
したがって、最も現実的なのは、現在のCodexダッシュボードを「AIエージェント共通ダッシュボード」に拡張し、上段にWorkとCodexのジョブを一緒に表示する構成です。
AIエージェント実行中・最近の処理
├─ 種別：Work／Codex
├─ ジョブ名
├─ 状態
├─ 進捗
├─ 実行場所：ローカル／クラウド
├─ 開始・更新時刻
└─ 推定消費量
AIエージェント共通使用量
├─ 5時間枠
├─ 7日枠
├─ リセット時刻
└─ 購入クレジット残高
詳細
├─ Codex：正確なトークン・推定費用
└─ Work：枠の前後差・推定費用まず小さなWork処理を1件実行し、現在読み取っているCodexのローカル履歴にWorkのイベントも保存されるかを確認するのが第一段階です。
保存されていなければ、状態JSONまたはGoogle Sheetsを中継する方式に切り替えるのが安全です。
Workのダッシュボード実現のために色々と提案してくれたが、現在実行中のCodexダッシュボードと同様の情報の表示には向かないことが確認できたので、Workダッシュボードは作成しないこととした。
私の場合、プライベートで、会社で使うような業務ファイル（いわゆるOfficeファイル）が必要になることはほとんど無いので、そのような処理を行う必要がある場合は、プロンプトに色々な情報を記録するように指示を追加し、1回だけ実行して費用などの目安を確認しておけば十分のなような気がする。
CodexとWorkのオートメーション・定期実行比較
Workでも添付画像と同様のことができますか。
WorkとCodexのオートメーション・定期実行の違いをまとめてください
WorkとCodexのオートメーションは何が違うのか
結論から言うと、WorkでもCodexのオートメーションに近い定期処理を実行できます。
ただし、同じ目的の機能ではありません。
Workでは主に「Scheduled Tasks（スケジュール済みタスク）」、Codexでは従来から「Automations（オートメーション）」という名称が使われています。
現在のChatGPTデスクトップアプリでは、WorkとCodexのどちらからでもScheduled Taskを作成・更新し、共通の「Scheduled」画面で有効・一時停止・完了したタスクや最近の実行結果を管理できます。(OpenAI Developers)
一方、OpenAIは両者を、次のように目的別に区別しています。
- WorkのScheduled Tasks：リマインダー、日次ブリーフ、調査、監視などの一般業務
- CodexのAutomations：コード、Git、CI、テストなどを対象とした開発作業
OpenAIのヘルプでも、「Scheduled TasksはChatGPTの能動的な作業機能」「Codex AutomationsはCodex内で動く、より焦点を絞ったワークフロー」と説明されています。(OpenAI Help Center)
WorkとCodexの比較
| 比較項目 | WorkのScheduled Tasks | CodexのAutomations |
|---|---|---|
| 主な目的 | 調査、情報収集、要約、通知、資料作成、一般業務 | コード調査、修正、テスト、CI確認、リポジトリ保守 |
| 定期実行への対応 | 対応 | 対応 |
| 1回だけの予約実行 | 対応 | 共通のScheduled Taskとして設定可能 |
| 条件監視 | 対応 | 対応 |
| 変更があった場合だけ報告 | 対応 | 対応 |
| 同じ会話の続きを実行 | 対応 | 対応 |
| 毎回独立したタスクとして実行 | 対応 | 対応 |
| Web検索 | 得意 | 技術調査などで利用可能 |
| Gmailなどの接続アプリ | 得意 | 利用できるが、開発作業が主目的 |
| 文書・表・プレゼンの作成 | 得意 | 可能だが主目的ではない |
| ローカルフォルダの利用 | デスクトップ版で可能 | 可能 |
| Gitリポジトリの利用 | 可能だが主目的ではない | 中心機能 |
| worktreeでの分離実行 | GitプロジェクトのScheduled Taskで利用可能 | 特にCodex向き |
| コマンド・テストの実行 | 対応環境では可能 | 中心機能 |
| 実行結果の確認 | Scheduled画面 | Scheduled画面またはレビュー画面 |
| スマホ・Webからの利用 | Workを直接利用可能 | Codexは選択不可。 対応タスクはRemoteから確認 |
| クラウド実行 | Web・モバイルのWorkはクラウド実行 | Codexの開発環境とは別の仕組み |
| ローカル実行 | PCとアプリの稼働が必要 | PCとアプリの稼働が必要 |
| 外部監視のしやすさ | 低い | ローカルログなどを利用しやすい |
| 向いている成果物 | レポート、通知、調査結果、文書、表 | コード差分、テスト結果、修正、レビュー |
Workは1回だけの実行、スケジュールやトリガーによる繰り返し、変更の監視に対応しています。
CodexのAutomationsは、指示と必要に応じたSkillを組み合わせて定期的に実行し、結果をレビュー用の画面へ送る仕組みです。(OpenAI Help Center)
「オートメーション」と「定期実行」は同義ではない
オートメーションは、定期実行よりも広い概念です。
| 用語 | 意味 | 例 |
|---|---|---|
| 予約実行 | 指定日時に1回だけ実行 | 明日の午前8時に資料を作る |
| 定期実行 | 決めた時刻や間隔で繰り返す | 毎朝8時にニュースをまとめる |
| 条件監視 | 定期的に確認し、条件成立時だけ報告 | 台風情報に重要な変化があったら知らせる |
| 継続追跡 | 同じタスクに戻って状態を確認する | 処理が終わるまで定期的に確認する |
| オートメーション | 上記を含む自動処理全般 | 調査、判断、通知、ファイル更新まで行う |
したがって、
定期実行はオートメーションの一種だが、オートメーションがすべて定期実行とは限らない
という関係になります。
なお、通常の独立したChatGPT Scheduled Taskは、原則として1時間に1回を超える頻度では実行できません。
一方、進行中の同じタスクへ戻って確認する追跡ループについては、分単位の間隔も公式資料で案内されています。(OpenAI Developers)
WorkでもCodexのオートメーション画面と同じことができるか
ChatGPT内では、Workのタスクについても次の情報をScheduled画面で確認できます。
| 表示・管理項目 | Workでの対応 |
|---|---|
| タスク名 | ○ |
| 有効／一時停止 | ○ |
| 次回実行予定 | ○ |
| 最近の実行結果 | ○ |
| 完了したタスク | ○ |
| タスクの再開 | ○ |
| スケジュールの編集 | ○ |
| タスクの削除 | ○ |
| 同じ会話での継続実行 | ○ |
| 毎回新しいタスクとして実行 | ○ |
Scheduled画面はタスクの受信箱として機能し、実行結果や確認が必要なタスクを一覧管理できます。(OpenAI Developers)
Home Assistantのダッシュボードにも表示できるか
ChatGPT内ではCodexと同様の一覧管理ができますが、現在のHome Assistantダッシュボードへ自動的に追加されるわけではありません。
| HAに表示したい項目 | Codex | Work |
|---|---|---|
| タスク名 | ローカル履歴などから取得しやすい | 独自に記録すれば可能 |
| 実行中／完了 | ログやイベントから判定しやすい | Workから状態を送る仕組みが必要 |
| 次回実行日時 | Codex側の設定から取得できる場合がある | Scheduled画面には表示されるが、HAへの自動連携はない |
| 実行履歴 | ローカルログを集計可能 | 別の保存先へ記録する必要がある |
| 進捗「3/5」 | ログから推定または独自記録 | Workに工程数を明示して記録させる |
| 入力待ち・承認待ち | 取得しやすい | 外部からの安定した取得方法は限定的 |
| 入出力トークン | Codex履歴から取得できる場合がある | Work単独の詳細取得は難しい |
| 5時間枠・7日枠 | Workを含む共通値 | Workの処理によって値が変化する |
OpenAIの公式資料では、Workのタスク状態はScheduled画面で管理する仕組みが説明されていますが、Home Assistantなどの外部ダッシュボードへ状態を出力する個人向けAPIは案内されていません。(OpenAI Developers)
用途による選び方
| 実行したい処理 | 適した機能 |
|---|---|
| 毎朝、AIやCarPlayのニュースを集めて要約 | Work |
| 特定情報に変化があった場合だけ通知 | Work |
| Gmailを確認して日次ブリーフを作成 | Work |
| 毎週、調査結果からレポートを作成 | Work |
| GitHubのIssueを定期確認 | Codex |
| CIエラーを調べてコードを修正 | Codex |
| 定期的にテストやlintを実行 | Codex |
| コード変更をworktreeへ分離して実行 | Codex |
| ローカルスクリプトを正確な時刻に実行 | launchd、cron、Home Assistant |
| WorkとCodexの処理状態を一覧表示 | Home Assistant＋独自の状態連携 |
まとめ
| 質問 | 回答 |
|---|---|
| Workでも定期実行できるか | できる |
| Workでも条件監視できるか | できる |
| Workでも次回日時や実行結果を確認できるか | Scheduled画面で確認できる |
| WorkとCodexの仕組みは同じか | 管理機能は共通化されているが、対象業務が異なる |
| Workは何に向いているか | 調査、通知、文書・表・レポート作成 |
| Codexは何に向いているか | コード、Git、テスト、CI、リポジトリ保守 |
| Workのタスクが現在のHA画面へ自動表示されるか | 表示されない |
| WorkをHAに表示できるか | 状態送信の仕組みを追加すれば可能 |
要するに、WorkのScheduled Tasksは一般業務を自動化する仕組み、CodexのAutomationsはソフトウェア開発に重点を置いた自動化機能です。ChatGPT内では似た形で管理できますが、Home Assistantで監視する場合は、CodexよりWorkの方が追加の連携設計を必要とします。
オートメーション・定期実行の処理の場合、CodexとWorkのどちらが向いているかについて一般的な回答が行われ、Workが有利なように回答されているが、詳細を検討していくと、Codexの方が、実行の信頼性が高い場合もあるので、鵜呑みにはできない。
Codexの各機能をWorkでも使えるか
Codexの各機能について、Workでも使えるかについて回答してください
以下は、Codexの各機能を、「Workでも使えるか」「Codex専用か」という観点でまとめたものです。
Codexの各機能はWorkでも使えるか
| 機能 | Work | Codex | 判定 | 主な違い・注意点 |
|---|---|---|---|---|
| Record & Replay | × | ○ | Codex専用 | macOS版ChatGPTデスクトップアプリで、Codex使用時に人の操作を記録し、再利用可能なSkillへ変換する機能。 Computer Useを有効にする必要がある |
| Computer Use | ○ | ○ | 共通機能 | Workでは一般的なアプリ操作、Codexではアプリのテストや不具合再現などに使う。macOSとWindowsに対応 |
| In-App Browser／内蔵ブラウザ | ○ | ○ | 共通機能 | ChatGPTデスクトップアプリ内でWebページやローカルWebアプリを表示する機能。 普段使っているブラウザとは別のプロファイルを使用 |
| Browser Use | ○ | ○ | 共通機能 | ChatGPTがブラウザ内でページ移動、クリック、入力、スクリーンショット確認などを行う。 WorkではWeb業務、CodexではWebアプリの検証に向く |
| Appshots | ○ | ○ | 共通機能 | Macの最前面ウィンドウを画像と取得可能なテキスト付きでタスクへ渡す。 macOS版デスクトップアプリで利用 |
| Remote Control | ○ | ○ | 共通機能 | スマホや別のPCから、接続したMac／Windows上のWorkまたはCodexタスクを確認・操作できる |
| Remote SSH | × | ○ | Codex専用 | SSH先のファイルシステムやシェルを開発環境として扱う。 リモートホストにもCodexのインストールと認証が必要 |
| タスクのHandoff | × | ○ | Codex専用 | タスクとGitの状態を、ローカルPCとSSHホストの間で移動する。 Gitリポジトリとworktreeを使う開発機能 |
| Codex App Server | × | ○ | Codex専用 | Codexを独自アプリや専用UIへ組み込むための開発者向けインターフェース。 認証、履歴、承認、実行イベントなどを提供 |
| Codex全機能の総合判定 | 一部対応 | ○ | 機能の種類による | 画面・ブラウザ・アプリ操作は共通するものが多いが、Git、SSH、App Server、CLI、IDE、worktreeなどはCodex専用 |
Computer Useは、公式にChatGPTデスクトップアプリのWorkとCodexの両方で利用できると明記されています。(ChatGPT学習)
各機能の位置づけ
| 分類 | 含まれる機能 | Work対応の傾向 |
|---|---|---|
| 画面を見せる機能 | Appshots | Workでも利用可能 |
| Webサイトを表示・操作する機能 | In-App Browser、Browser Use | Workでも利用可能 |
| デスクトップアプリを操作する機能 | Computer Use | Workでも利用可能 |
| 人の操作から手順を学習する機能 | Record & Replay | Codex専用 |
| 別端末からタスクを操作する機能 | Remote Control | Workでも利用可能 |
| SSH先を開発環境として扱う機能 | Remote SSH、Handoff | Codex専用 |
| Codexを外部システムへ組み込む機能 | Codex App Server | Codex専用 |
Record & ReplayとComputer Use
この2つは関連していますが、同じ機能ではありません。
| 項目 | Record & Replay | Computer Use |
|---|---|---|
| 役割 | 人の操作を記録し、再利用可能なSkillへ変換 | ChatGPTが実際に画面を見て操作する |
| Work | × | ○ |
| Codex | ○ | ○ |
| 主な対応OS | macOS | macOS・Windows |
| 操作時の主体 | 記録時は人が操作 | 実行時はChatGPTが操作 |
| 単独利用 | Computer Useが必要 | 単独で利用可能 |
| 主な用途 | 定型操作の学習・再利用 | アプリ操作、動作確認、GUIテスト |
公式には、Record & Replayは「ChatGPTデスクトップアプリでCodexを使用しているとき」に利用する機能とされています。(OpenAI Help Center)
Browser関連機能
| 機能 | 内容 | Work | Codex |
|---|---|---|---|
| In-App Browser | ChatGPTアプリ内にWebページを表示 | ○ | ○ |
| Browser Use | ChatGPTがページを操作 | ○ | ○ |
| Chrome拡張機能 | 普段のChromeタブやログイン状態を利用 | ○ | ○ |
| ページへの注釈 | 表示箇所を指定して修正指示を出す | ○ | ○ |
| CDP開発者モード | コンソール、DOM、通信、性能などを詳しく調査 | 一般業務では通常不要 | Codex向け |
| ローカルWebアプリの修正と再確認 | — | 可能 | Codexが適する |
ブラウザ機能自体はChatGPTのWeb版とデスクトップアプリで利用でき、内蔵ブラウザではChatGPTとユーザーが同じWebページを見ながら作業できます。
Codex CLIとIDE拡張では内蔵ブラウザを利用できません。(ChatGPT学習)
Appshots
AppshotsはCodex専用ではありません。
| 項目 | 内容 |
|---|---|
| 利用モード | Work／Codex |
| 対応環境 | macOS版ChatGPTデスクトップアプリ |
| 取得対象 | 最前面のアプリウィンドウ |
| 取得内容 | 表示画像と、取得可能なウィンドウ内テキスト |
| Workでの用途 | メール、資料、表、設定画面などの分析 |
| Codexでの用途 | エラー画面や開発中アプリを基にコードを修正 |
| 自動操作機能 | なし。操作が必要な場合はComputer Useと併用 |
公式資料でも、Appshotsから得られる情報が不足する場合、WorkまたはCodexで対応するプラグインを利用できると案内されています。(ChatGPT学習)
Remote connections
「Remote connections」は一つの機能名ですが、内部には共通機能とCodex専用機能が混在しています。
| Remote機能 | Work | Codex | 補足 |
|---|---|---|---|
| スマホからタスクを見る | ○ | ○ | Remote Control |
| スマホから追加指示を出す | ○ | ○ | Remote Control |
| 質問や承認要求に答える | ○ | ○ | Remote Control |
| 結果・スクリーンショットを見る | ○ | ○ | Remote Control |
| PC上のローカルファイルを利用する | ○ | ○ | 接続先PCが稼働している必要がある |
| SSHサーバーへ接続する | × | ○ | Remote SSH |
| SSH先でコマンドを実行する | × | ○ | Codex App ServerをSSH先で起動 |
| Git状態を別ホストへ移す | × | ○ | Handoff |
| worktreeを移動先で作成する | × | ○ | Codex専用 |
スマホのRemote画面からは、接続した端末上のWorkとCodexの両タスクを操作できます。
一方、SSH接続とGit状態を含むHandoffは、公式資料でもCodexの機能として説明されています。(ChatGPT学習)
Codex App Server
Codex App Serverは、明確にCodex専用です。
| 項目 | 内容 |
|---|---|
| 対象 | 開発者 |
| 目的 | Codexを独自アプリや専用クライアントに組み込む |
| 通信形式 | JSON-RPCベース |
| 主な提供情報 | 認証、会話履歴、承認要求、ストリーミングイベント |
| Work用App Server | 提供されていない |
| HAダッシュボードとの相性 | Codexの状態監視システムを構築しやすい |
| Workの状態取得 | App Server経由では取得できない |
Codex App Serverは、CodexのVS Code拡張のようなリッチクライアントを動かすためのインターフェースです。
Work用の同等サーバーは案内されていません。(OpenAI Developers)
最終的なまとめ
| 判定 | 機能 |
|---|---|
| WorkとCodexの共通機能 | Computer Use、In-App Browser、Browser Use、Appshots、Remote Control |
| Codex専用機能 | Record & Replay、Remote SSH、Git状態のHandoff、Codex App Server |
| 基本機能は共通だがCodexで高度化されるもの | Browserの開発者モード、ローカルWebアプリ検証、ターミナル出力やコード差分のリモート確認 |
覚え方としては、次のように整理できます。
画面を見る・ブラウザやアプリを操作する機能は、WorkとCodexで共有されることが多い。
操作をSkill化する機能や、SSH・Git・外部システムとの開発者向け統合はCodex専用。
Codexの各機能がWorkでも使えるかについて、基本的な事項の確認ができた。
ちょっと特殊な機能以外は、Workでも使えることが確認できた。
worktreeは、Codex専用の機能であることが確認できたが、使用したことがなかったのであらためて調査を行った。
worktreeは、コーディングでしか使えないのですか
いいえ。worktreeは「コーディング専用」ではありません。
正確には、Gitで管理しているファイルを、元の作業フォルダから分離して並行編集する仕組みです。
そのため、コード以外でもGitに登録されていれば利用できます。
ただし、ChatGPTデスクトップアプリでworktreeを作成・操作する機能は、現時点ではCodexの実行環境機能です。
公式ドキュメントにも、worktreeはCodexでのみ利用でき、開始前にCodexを選択するよう記載されています。(OpenAI開発者)
コーディング以外でも使える例
| 作業対象 | worktreeの利用 | 適性 | 用途例 |
|---|---|---|---|
| Python・JavaScriptなどのコード | ○ | ◎ | 機能追加と不具合修正を並行する |
| Home AssistantのYAML | ○ | ◎ | 現行設定を保ったまま別案を作る |
| Markdownのブログ原稿 | ○ | ◎ | 元原稿と全面改稿版を分離する |
| WordPressテーマのCSS・設定ファイル | ○ | ◎ | デザイン案を複数並行で試す |
| HTMLサイトの文章・画像配置 | ○ | ◎ | ページ構成案を別ブランチで作る |
| JSON・CSV・設定データ | ○ | ○ | データ変換や設定変更を分離する |
| スライドのMarkdown／HTMLソース | ○ | ○ | 複数の構成案を並行作成する |
| Word・Excel・PowerPointのバイナリファイル | 技術的には○ | △ | Gitで差分を確認しにくく、競合解決も難しい |
| PDF・JPEG・PNG | 技術的には○ | △ | 複製・管理はできるが、行単位の差分を確認できない |
| Git管理していない通常フォルダ | × | ― | worktreeは作れない |
| Dropbox同期フォルダ | 条件付き | △ | そのフォルダがGitリポジトリなら可能 |
worktreeは各作業用にリポジトリ内の全ファイルを別フォルダへ展開し、ブランチやコミット履歴などのGit情報を共有します。
したがって、対象がプログラムか文章かではなく、Gitリポジトリに含まれているかが利用条件です。(OpenAI開発者)
WorkとCodexの関係
| 操作 | Work | Codex |
|---|---|---|
| Git管理された文書や資料を扱う | ○ | ○ |
| 手動タスクをWorktreeモードで開始 | × | ○ |
| worktreeを自動作成 | × | ○ |
| worktreeごとのGit差分を表示 | × | ○ |
| Localとworktree間をHandoff | × | ○ |
| worktreeからブランチを作成 | × | ○ |
| worktreeでコミット・Push・PR作成 | × | ○ |
| worktreeを使うScheduled Taskを設定 | Workから設定を依頼できる場合あり | ○ |
| Gitを使わない一般資料のクラウド処理 | ◎ | ○ |
スケジュール済みタスクはWorkまたはCodexから作成できます。Gitリポジトリを対象にする場合、ローカルのメインフォルダか専用worktreeで実行するよう設定できます。
ただし、worktreeで実際にローカルファイルを処理する部分はCodex側の環境機能として扱われます。(OpenAI開発者)
つまり、
Workで依頼やスケジュールを作成できる場合はあるが、worktreeという分離実行環境を提供しているのはCodex
という整理です。
ブログ原稿で使う例
例えば、ブログ原稿をGitで管理している場合、次のような使い方ができます。
blog-project/
├─ articles/
│ └─ work-vs-codex.md
├─ images/
└─ references/Codexに2つのworktreeを作らせると、
メインフォルダ
└─ 現在公開中の原稿
Worktree A
└─ 初心者向けに短く書き直す
Worktree B
└─ 技術解説を追加した詳細版を作るという形で、元原稿に影響を与えず複数案を並行作成できます。完成後に差分を確認し、採用する案だけをメイン側へ反映できます。
worktreeが有効な条件
| 条件 | worktreeを使う価値 |
|---|---|
| 複数案を同時に作りたい | 高い |
| 元のファイルを変更されたくない | 高い |
| 作業結果の差分を確認したい | 高い |
| 変更をブランチやコミットで残したい | 高い |
| Markdown、YAML、HTMLなどテキスト中心 | 高い |
| WordやPDFを1ファイルだけ編集 | 低い |
| Gitを使っていない | 利用不可 |
| 単純な読み取り・要約だけ | ほぼ不要 |
あなたの用途での判断
| 作業 | worktreeの必要性 |
|---|---|
| HAダッシュボードのYAMLを別案で修正 | ◎ |
| ニュース収集スクリプトを改修 | ◎ |
| WordPress用HTML・CSSを変更 | ◎ |
| ブログのMarkdown原稿を複数案作成 | ○ |
| 記事を調査して文章を作るだけ | △ |
| Dropbox内のWord文書を修正 | △ |
| PDFを読んで要約する | 不要 |
| Gmailを調べてレポートを作成 | 不要 |
したがって、worktreeはコードだけでなく、YAML、Markdown、HTML、設定ファイル、ブログ原稿などにも使えます。ただし、ChatGPT上でworktreeを管理する専用機能はCodex側にあり、Workの一般的な資料作成機能として直接提供されているわけではありません。
設定ファイルの変更履歴、システム変更の変更履歴の記録に活用し、ユーザーとAIの両方が参照・編集できるファイルの管理に利用して、AIにも書き込んでもらうようにすれば、記録の手間の軽減、システムの信頼性・再現性の向上に繋がるかもしれない。
CodexとWorkの費用体系は同じか
WorkはCodexの同じ利用枠を使うということですが、費用の考え方（各種トークン使用量に依存）は同じですか。利用枠の使い方に違いがあるかを表形式で回答してください
はい。WorkとCodexは基本的に同じ「エージェント利用枠」を共有し、消費量も入力・キャッシュ済み入力・出力の各トークン量に基づいて計算されます。
ただし、同じ仕事を頼んでも消費量まで同じになるわけではありません。
読み込むファイル量、モデル、出力量、作業工程などで差が出ます。
公式にも「WorkはCodexと同じ利用構造だが、Codexの例はコーディング作業を前提としているため、Workの消費量は仕事によって異なる」と説明されています。(OpenAI Help Center)
WorkとCodexの利用枠の違い
| 比較項目 | Work | Codex | 違い |
|---|---|---|---|
| 利用枠 | Codexなどと共通のエージェント利用枠 | Workなどと共通のエージェント利用枠 | 別枠ではない |
| 消費の基本単位 | トークン量からクレジット換算 | トークン量からクレジット換算 | 基本的に同じ |
| 計算対象 | 入力・キャッシュ済み入力・出力トークン | 入力・キャッシュ済み入力・出力トークン | 同じ |
| 主な入力 | 資料、Web情報、メール、アプリ、各種ファイル | ソースコード、リポジトリ、ログ、仕様書 | 入力内容が異なる |
| コンテキストが大きくなる場面 | 多数の資料やメール、長いPDFを読む | 大規模なコード一式や多数の関連ファイルを読む | どちらも大量消費の可能性 |
| 出力が多くなる場面 | 長い報告書、表、スライド、複数成果物 | 大量のコード、テスト、説明、変更差分 | どちらも出力が多いほど高くなる |
| キャッシュの効果 | 同じ資料や作業内容を再利用すると低減しやすい | 同じリポジトリやコードを再利用すると低減しやすい | 同じ仕組み |
| モデル選択の影響 | Sol・Terra・Lunaなどで消費率が異なる | Sol・Terra・Lunaなどで消費率が異なる | 基本的に同じ |
| 高速モード | 対応状況や選択モデルによる | Fast modeは通常より高い率で消費 | Codexでは特に注意 |
| 典型的な消費量 | 仕事の種類によるため一定ではない | GPT-5.5の典型的タスクで約5～45クレジット | Workはコーディング以外も含むため幅が読みづらい |
| 利用状況の確認 | 共通利用枠として反映 | Codexの「Settings → Usage」で確認 | 実質的に同じ残量を参照 |
| 枠を使い切った場合 | WorkとCodexの両方に影響 | WorkとCodexの両方に影響 | 一方の多用が他方に影響する |
Work、Codex、ChatGPT for Excel、Workspace Agentsは、利用可能なプランでは同じエージェント利用枠とクレジット残高から消費します。(OpenAI Help Center)
利用枠が消費される順番
| 順番 | 使用されるもの | 内容 |
|---|---|---|
| 1 | プランに含まれる利用枠 | Plusなどの月額料金に含まれるエージェント利用枠を先に使用 |
| 2 | 購入済みクレジット | 含まれる利用枠を使い切った後、残高があればクレジットを使用 |
| 3 | 追加購入または自動補充 | 残高不足時に手動購入。設定していれば自動補充 |
| 4 | 利用停止・制限 | 追加クレジットがなければ、枠が回復するまで対象機能を利用できない可能性 |
公式には、プラン付属の利用枠が必ず先に使われ、その後に購入クレジットが使われると説明されています。
WorkとCodexのどちらを優先するという順番はなく、先に実行した作業から共通枠を消費すると考えてよいでしょう。(OpenAI Help Center)
モデルごとの消費率
現在のトークンベース料金は、100万トークン当たり次のように設定されています。
| モデル | 入力 | キャッシュ済み入力 | 出力 | 相対的な消費 |
|---|---|---|---|---|
| GPT-5.6 Sol | 125クレジット | 12.5 | 750 | 高い |
| GPT-5.6 Terra | 62.5 | 6.25 | 375 | 中程度 |
| GPT-5.6 Luna | 25 | 2.5 | 150 | 低い |
| GPT-5.5 | 125 | 12.5 | 750 | 高い |
| GPT-5.4 | 62.5 | 6.25 | 375 | 中程度 |
| GPT-5.4-Mini | 18.75 | 1.875 | 113 | 低い |
| GPT-5.3-Codex | 43.75 | 4.375 | 350 | コードレビューなどで使用 |
料金表から分かる重要な点は、出力トークンが入力トークンよりかなり高いことです。
たとえばGPT-5.6 Solでは、出力の消費率は入力の6倍です。一方、キャッシュ済み入力は通常入力の約10分の1です。(OpenAI Help Center)
GPT-5.6 SolとGPT-5.5のトークンベース料金は同じで、単価差による節約にはならないため、品質・速度・実際のトークン効率で選ぶとよいとのこと。ただし、GPT-5.6 Solの回答は、GPT-5.5の回答に比べて、さらに輪をかけて長いので、出力トークンは数割、割高になりそうな気がする。
使い方による消費傾向
| 使用例 | Workの消費傾向 | Codexの消費傾向 |
|---|---|---|
| 簡単な文章修正 | 小 | Codexを使う必要性が低い |
| Web調査＋短い要約 | 小～中 | ― |
| 大量のPDFを読んで報告書作成 | 中～大 | ― |
| 表・グラフ・スライドを一括作成 | 中～大 | ― |
| 小さなプログラム修正 | ― | 小～中 |
| 大規模リポジトリ全体の調査 | ― | 中～大 |
| 修正・テスト・再修正の反復 | ― | 大 |
| 複数エージェントの並列実行 | Work側も並列数に応じて増加 | 特に大きくなりやすい |
| 定期オートメーション | 実行のたびに消費 | 実行のたびに消費 |
結論
| 質問 | 回答 |
|---|---|
| WorkとCodexの費用の考え方は同じか | 基本的に同じ。トークン量をクレジットへ換算 |
| 利用枠は別々か | いいえ。共通枠 |
| 同じ依頼なら同じ消費量か | 必ずしも同じではない |
| 何が消費量を左右するか | モデル、入力資料量、キャッシュ量、出力量、作業工程、並列処理 |
| どちらが先に枠を使うか | 優先順位はなく、実際に実行した処理から消費 |
| 追加クレジットが先に使われるか | いいえ。プラン付属枠が先 |
| 通常のChatも同じ枠か | 通常Chatのメッセージ枠とは基本的に別 |
実用上は、軽い相談や文章作成はChat、資料やアプリをまたぐ完成物の作成はWork、実際のコード修正はCodexと分けると、共通エージェント枠を節約しやすくなります。
WorkとCodexの実行環境とスマホとの連携
WorkとCodexについて、実行環境（ローカルかクラウドか）、スマホとの連携機能について教えてください
2026年7月11日時点では、WorkもCodexもローカルとクラウドの両方で利用できます。
ここでいう「ローカル実行」は、ファイルの読み書きやコマンド実行が自分のMac／Windows上で行われるという意味です。
全体比較
| 項目 | ChatGPT Work | Codex |
|---|---|---|
| Web・モバイルでの実行 | OpenAI側のクラウドで実行 | Codex Cloudとしてクラウド実行可能 |
| デスクトップでの実行 | ローカルファイルやアプリを使って実行可能 | Local／Worktree／Cloudから選択可能 |
| ローカルフォルダの直接操作 | ○ | ○ |
| ターミナル・ビルド・テスト | 一般業務向け。 必要に応じてツールを利用 | ○。開発作業の中心機能 |
| 専用クラウド環境 | 一般的なWorkのクラウドタスク | GitHubリポジトリ単位のCodex Cloud環境 |
| スマホ単独でクラウド作業開始 | ○ | Codex Cloudまたは接続先環境で可能 |
| スマホからPC上の作業を操作 | ○ | ○。特にCodexの機能が充実 |
WorkはWebやモバイルではクラウド上で処理でき、デスクトップ版ではローカルファイルやデスクトップアプリも扱えます。Codexではタスクごとに「Local」「Worktree」「Cloud」を明示的に選べます。
LocalとWorktreeは自分のコンピューター上、CloudはOpenAI管理のクラウド環境上で動作します。(OpenAI)
1. Workの実行環境
| Workの利用方法 | ファイル処理の場所 | PCを起動しておく必要 | 主な用途 |
|---|---|---|---|
| Web版Work | クラウド | 不要 | 調査、文書・表・スライド作成 |
| スマホ版Work | クラウド | 不要 | 外出先から依頼、確認、修正 |
| デスクトップ版Work・クラウドタスク | クラウド中心 | 基本的に不要 | 長時間の一般業務 |
| デスクトップ版Work・ローカルフォルダ | 自分のPC | 必要 | PC内の文書や画像を直接処理 |
| Remote経由のWork | 接続先のPC | 必要 | スマホから自宅PC上の作業を操作 |
| SSH先を利用する処理 | 接続したリモートマシン | 接続先が稼働している必要 | 常時稼働PC、サーバー上の資料やツール |
デスクトップ版ではフォルダを開き、Workにその場所のファイルやコンテキストを利用させられます。
Webで作成したタスクは、アップロード済みファイルや接続済みサービスは使えますが、PC内のフォルダへ直接アクセスできません。(OpenAI Developers)
2. Codexの実行環境
Codexでは、開始時に実行場所を選べます。
| モード | 実行場所 | 元のフォルダへの変更 | PC停止後の継続 | 用途 |
|---|---|---|---|---|
| Local | 自分のPC | 直接変更 | × | 小規模な修正、すぐ確認したい作業 |
| Worktree | 自分のPC | Git worktree内で分離 | × | 複数タスクの並行処理 |
| Cloud | OpenAI管理環境 | クラウド側のGitブランチ | ○ | 長時間処理、並行処理、PR作成 |
| SSHリモート | 自分で用意したサーバー | サーバー上のファイルを変更 | サーバーと接続ホストによる | Mac mini、開発サーバー、devbox |
| Remote操作 | 上記の接続先 | 接続先に従う | 接続先に従う | スマホから操作・承認 |
Codex CloudはGitHubアカウントを接続し、対象リポジトリを選択して専用環境を作る方式です。
依存関係、環境変数、シークレット、セットアップ処理などを環境ごとに設定できます。(ChatGPT 学習サイト)
3. スマホとの連携
Workのスマホ機能
| 機能 | 対応 |
|---|---|
| スマホから新しいWorkタスクを開始 | ○ |
| クラウド処理の進捗確認 | ○ |
| 作成途中の文書を確認 | ○ |
| 追加指示・方向修正 | ○ |
| Web・PCで同じ仕事を継続 | ○ |
| PC内のローカルフォルダへ直接アクセス | 単独では× |
| Remoteで自宅PCのフォルダを操作 | ○ |
| 完了・入力待ち通知 | ○ |
Workはスマホからタスクを開始し、外出中にドラフト確認や長時間処理の状態確認ができます。
帰宅後にWebやデスクトップから同じ作業を続けられます。(OpenAI)
Codexのスマホ機能
| 機能 | 対応 |
|---|---|
| 実行中タスクの確認 | ○ |
| 新しいCodexタスクの開始 | ○ |
| 追加指示・軌道修正 | ○ |
| コマンド実行の承認 | ○ |
| コード差分の確認 | ○ |
| ターミナル出力の確認 | ○ |
| テスト結果の確認 | ○ |
| スクリーンショットの確認 | ○ |
| モデル変更 | ○ |
| PCをスリープさせたままLocal処理 | × |
| クラウドタスクをPCなしで継続 | ○ |
スマホ版ChatGPTのRemote機能では、接続したMacまたはWindowsで動作しているWork／Codexを遠隔操作できます。
ファイル、認証情報、プラグイン、開発環境はPC側に残り、スマホには差分、ターミナル出力、テスト結果、スクリーンショット、承認要求などがリアルタイムで送られます。(OpenAI)
あなた向けの整理
| やりたいこと | 適した構成 |
|---|---|
| 外出先からMac mini上のコードを修正する | Codex Remote |
| Mac miniを止めても処理を続ける | GitHub＋Codex Cloud |
| スマホから調査や資料作成を依頼する | モバイル版Work |
| Gitのブランチ・テスト・PRまで自動化する | Codex Cloud＋GitHub |
PC停止後も続くコード処理にはGitHub＋Codex Cloud、という組み合わせでほぼ希望する運用を実現できます。
Codexをローカルで動かす場合、ローカルに、実行環境関連のファイルを多く保存するので、処理内容についての情報がそれらのファイルから得られると思いますが、Workは、ローカルに同種のファイルをあまり保存しないのですか
はい。ただし、正確には 「Workはローカルにあまり保存しない」というより、Codexほど“外部から解析できる形”で実行情報を保存・公開していないと考えるのが適切です。
デスクトップ版Workについては、公式に「デスクトップWorkのスレッド、ローカルファイル、出力はそのコンピューターに残る」と説明されています。
したがって、Workもローカル保存を行います。
しかし、Codexの~/.codexのような、保存場所・形式・イベント構造が公開された監視向けデータ群は、Workでは現時点で確認できません。(OpenAI Help Center)
CodexとWorkのローカル保存の違い
| 保存・取得対象 | ローカルCodex | デスクトップ版Work | Web／スマホ版Work |
|---|---|---|---|
| 作業対象ファイル | ローカルフォルダやリポジトリ | 許可したローカルフォルダ | 原則クラウド上のファイル |
| 作成した成果物 | ローカルに保存可能 | ローカルに保存可能 | クラウド側に保存 |
| 会話・タスクのスレッド | ローカルセッションとして保存 | デスクトップスレッドがPCに残る | クラウドに保存 |
| 保存場所の公式公開 | あり | 詳細な公開なし | ローカルには原則なし |
| セッション記録 | ~/.codex/sessions | 内部データはあると考えられるが、形式非公開 | クラウド側 |
| アーカイブ済みセッション | ~/.codex/archived_sessions | 公開された専用パスなし | クラウド側 |
| 履歴JSONL | ~/.codex/history.jsonl | 同等の公開JSONLなし | ローカルにはなし |
| アプリログ | 公式の保存場所あり | 一般的なアプリログはあり得るが、Work専用仕様は非公開 | ブラウザ／アプリの通常キャッシュ程度 |
| 設定ファイル | ~/.codex/config.toml | 同等のWork用設定ファイルは未確認 | なし |
| 作業ディレクトリ情報 | セッションやイベントから取得可能 | 公開インターフェースなし | なし |
| コマンド実行履歴 | セッションやログ、App Serverから取得可能 | 構造化履歴としての公開なし | 原則取得不可 |
| ファイル変更イベント | Codexのイベントとして取得可能 | 成果物の実ファイルを監視することは可能 | クラウド側 |
| ターン開始・完了イベント | App Serverで取得可能 | 同等の公式イベントAPIなし | 同等の公式イベントAPIなし |
| トークン情報 | ログやセッションに含まれる場合がある | Work単独の詳細情報を得る公式手段は未確認 | 利用画面などの集計値中心 |
| 外部監視への適性 | 高い | 低い～中程度 | 低い |
Codexでは、公式にCODEX_HOMEが定義され、config.toml、history.jsonl、ログ、キャッシュなどが保存されます。
また、セッション記録とアーカイブ記録の標準パスも明示されています。(OpenAI Developers)
Codexで情報を取得しやすい理由
Codexはローカル開発ツールとして設計されているため、次の情報をローカルで管理する必要があります。
| 情報 | 必要になる理由 |
|---|---|
| 作業フォルダ | どのリポジトリを変更しているか識別するため |
| 現在のブランチ・worktree | 並行作業やGit差分を管理するため |
| 実行したコマンド | ビルド・テスト・検証を追跡するため |
| ファイル変更 | 差分表示、レビュー、取り消しに必要 |
| 承認状態 | 危険なコマンドや書き込みを制御するため |
| ターンとセッション | 中断した作業を再開するため |
| 設定・権限 | sandboxやネットワーク、承認ポリシーを維持するため |
| ログ | 不具合調査や外部監視に利用するため |
さらにCodex App Serverは、スレッド、ターン、コマンド実行、ファイル変更、ツール呼び出しなどを構造化イベントとしてストリーミングできます。
これが、あなたのHome Assistantダッシュボードのような監視構成と相性がよい理由です。(OpenAI Developers)
Workは何をローカルに保存するのか
デスクトップ版Workでは、少なくとも次のものがローカルに残ります。
| 種類 | ローカル保存 |
|---|---|
| Workで開いたローカルファイル | ○ |
| Workがローカルフォルダへ作成した成果物 | ○ |
| デスクトップWorkのスレッド | ○ |
| 作業中に生成された文書・表・スライド | 保存先がローカルなら○ |
| アプリの設定・認証情報 | OSのアプリ領域やキーチェーン等 |
| 内部キャッシュや一時データ | 通常は存在すると考えられる |
| 構造化された全実行イベント | 公式には公開されていない |
| Work専用App Server | なし |
| Work専用JSONL履歴 | 確認できない |
| Work専用OpenTelemetry出力 | 確認できない |
公式には、デスクトップWorkのスレッドとローカルファイルはそのPCに残り、Web／スマホのWorkはクラウドで実行される、と明確に区別されています。(OpenAI Help Center)
一方、従来のChatGPT macOSアプリで会話にアップロードしたファイルは、ローカルではなくクラウドに保存されるという説明もあります。
これは、ローカルフォルダを直接開くデスクトップWorkと、会話へファイルをアップロードする操作が別の扱いであることを意味します。(OpenAI Help Center)
「保存量」よりも「公開形式」が重要
仮にWorkのアプリ内部に大量のデータが保存されていても、次のような状態では監視には利用しにくくなります。
| 状態 | ダッシュボード利用 |
|---|---|
| JSONLとして公開されている | 容易 |
| App Serverからイベントを取得できる | 容易 |
| SQLiteだが仕様が公開されている | 比較的可能 |
| アプリ内部の非公開SQLite | 解析できても壊れやすい |
| 暗号化・独自形式 | 困難 |
| キャッシュだけに存在 | 欠落や削除が起きる |
| クラウドだけに存在 | ローカル監視不可 |
したがって、Workについての問題は、単に「ファイルが少ない」ことではなく、
タスクの進捗や内部イベントを、外部プログラムが継続的に読み取れる公式形式がない
という点です。
現在のダッシュボードへの影響
| 表示したい情報 | Codex | Work |
|---|---|---|
| ジョブ名 | ローカル履歴から取得可能 | スレッド名などから取得できる可能性 |
| 開始・終了時刻 | セッションイベントから取得 | 独自記録が必要になりやすい |
| 実行中・完了 | イベントやログから判定 | アプリ内部データだけでは安定取得困難 |
| 承認待ち | App Serverやイベントから取得 | 公式な外部取得方法なし |
| 実行コマンド | 取得可能 | 一般業務ではそもそもコマンドがない場合も多い |
| 処理段階 | ツール実行から推測可能 | Workに明示的に記録させるのが確実 |
| 入出力トークン | ログから取得できる場合あり | Work単独値の取得は困難 |
| 使用モデル | セッション情報から取得可能 | UI外からの安定取得は困難 |
| エラー内容 | ログから取得可能 | Work画面には出ても外部取得しにくい |
| 5時間・7日枠 | 共通利用枠として取得 | Codexと共通の値 |
| 成果物の生成・更新 | ファイル監視可能 | ローカル成果物ならファイル監視可能 |
Workを監視する現実的な方法
Work内部の非公開データを直接解析するより、Workに監視用データを明示的に出力させる方式が安定します。
Workタスク
↓
各工程の開始・完了時に status.json を更新
↓
Mac上の監視プログラム
↓
Home Assistant例えば次の情報を保存させます。
{
"source": "work",
"job_id": "work-20260711-001",
"title": "Android Auto最新情報の調査",
"status": "running",
"stage": 3,
"total_stages": 5,
"stage_name": "記事構成を作成中",
"started_at": "2026-07-11T14:20:00+09:00",
"updated_at": "2026-07-11T15:05:00+09:00",
"needs_input": false,
"error": null
}ただし、Workが利用制限、アプリ異常、通信切断などで突然停止すると、停止直前のJSON更新が行われない可能性があります。
その場合は、最終更新時刻から一定時間経過したらstalledと判定する仕組みが必要です。
判断のまとめ
| 質問 | 回答 |
|---|---|
| Workもローカルにファイルを保存するか | デスクトップ版は保存する |
| Codexほど多数の管理ファイルを作るか | 公式には確認できない |
| Codexと同じような履歴JSONLがあるか | 公開されたものはない |
| Workの内部データを解析できる可能性 | あるが、非公開形式なら更新で壊れやすい |
| Work用App Serverはあるか | ない |
| Workの正確な進捗を外部取得できるか | 現時点では困難 |
| 成果物や状態JSONを監視できるか | 可能 |
| HAダッシュボードとの相性 | Codexより劣るが、明示的な状態出力で補える |
つまり、Cod劣るが、明示的な状態出力で補える
つまり、Codexは処理の過程を記録・再開・統合するためのローカル基盤を持ち、Workは成果物とスレッドを中心に管理する設計です。
Workにもローカルデータはありますが、現状では、Codexのように外部監視へ転用できる公開され「実行記録群」としては整備されていない、という違いです。
Codexで定期実行のタスクをローカルで作成しようとした際、MacOSの制限があるため、cronの機能を使うという提案を受けたことがあります。Workでもそのようになる可能性はありますか。それとも、もともと、そのような処理はクラウドで設定すべきものでしょうか
はい、Workでもローカル実行を選べば、Codexと同じようにmacOS側の制約を受けます。
ただし、現在のWorkには公式の「スケジュール済みタスク」があるため、最初からcronを使う必要はありません。
基本的には次の選択になります。
| 処理内容 | 適した実行場所 |
|---|---|
| Web検索、接続サービス、メール、クラウド上の資料だけで完結 | Workのクラウド実行 |
| Mac内のファイル、Dropbox同期フォルダ、ローカルアプリを使用 | デスクトップWorkのローカル実行 |
| 正確な時刻にスクリプトを確実に起動 | macOSのlaunchd／cronなど |
| Home Assistantへ定期的に数値を送信 | Home Assistant自身、Python、launchdなど |
| 取得データを分析し、報告書や解説を作る | Workのスケジュール済みタスク |
Workのスケジュール済みタスクは2種類ある
| 項目 | クラウドWork | ローカルWork |
|---|---|---|
| 設定場所 | ChatGPTのWeb／モバイル | ChatGPTデスクトップアプリ |
| 実行場所 | OpenAIのクラウド | 自分のMac |
| Macの電源 | 不要 | 必要 |
| ChatGPTアプリの起動 | 不要 | 必要 |
| Macがスリープ中 | 実行可能 | 原則実行できない |
| Mac内フォルダ | アクセス不可 | アクセス可能 |
| Dropbox同期フォルダ | 直接は不可。接続ツール経由 | 普通のローカルフォルダとして利用可能 |
| ローカルアプリ操作 | 不可 | Computer Useなどで可能 |
| Home AssistantのローカルURL | 通常は不可 | Macから接続できれば利用可能 |
| Web検索・接続アプリ | ○ | ○ |
| Git worktree | × | Gitプロジェクトでは利用可能 |
| 保守の容易さ | 高い | Macの稼働状態や権限管理が必要 |
公式資料では、デスクトップのスケジュール済みタスクはローカルプロジェクト内またはworktreeで動かせます。
ただし、ローカルファイルが必要な実行では、Macの電源を入れ、ChatGPTデスクトップアプリを起動し、対象フォルダを利用可能にしておく必要があります。
Web上のタスクはクラウド実行ですが、Mac内のフォルダやworktreeを保持できません。(OpenAI Developers)
Workでもcronが必要になる可能性
可能性はあります。ただし、Workの機能不足というより、求める実行条件がAIタスクよりOSの定期処理に適している場合です。
| 条件 | Workの標準スケジュール | launchd／cronなど |
|---|---|---|
| 毎朝ニュースを調査して要約 | ◎ | 不向き |
| 毎週資料を読み、報告書を更新 | ◎ | 不向き |
| 接続サービスの変化を監視 | ◎ | 不向き |
| 毎時ちょうどにPythonを実行 | ○ | ◎ |
| 5分ごとにセンサー値を取得 | 不向き | ◎ |
| ChatGPTアプリが終了していても実行 | × | ○ |
| AI利用枠がなくてもデータ取得を続ける | × | ○ |
| 同じ処理結果を毎回厳密に再現 | △ | ◎ |
| 処理失敗時に細かな再試行制御 | △ | ◎ |
| 実行後に内容を判断・要約 | ◎ | AI API等を別途組み込む必要 |
| Mac内アプリを人間のように操作 | ◎ | 単独では難しい |
つまり、Workに適しているのは、単なる「時刻起動」ではなく、起動後に情報を読み、考え、判断し、成果物を作る処理です。
一方、cronやlaunchdに適しているのは、決められたコマンドを決められた時刻に実行する処理です。
Codexでcronを提案された理由として考えられること
当時、次のいずれかが理由だった可能性があります。
| 考えられる理由 | 内容 |
|---|---|
| Codexのオートメーションが未対応だった | 現在のスケジュール済みタスク追加前の提案だった |
| CLIから設定しようとしていた | Codex CLIにはスケジュール管理画面がない |
| Macのスリープ中にも動かしたかった | ローカルChatGPTタスクはMacとアプリの稼働が必要 |
| AIを毎回起動する必要がない処理だった | 単純なPython処理ならOSスケジューラの方が合理的 |
| 短い間隔で繰り返したかった | AIタスクより常駐スクリプトやHAの方が適する |
| 実行時刻の確実性が重要だった | AIタスクは外部サービスや利用枠などの影響を受ける |
| ローカル環境へのアクセス制限があった | OS側の権限・サンドボックス設定を回避または整理する必要があった |
現在は、ChatGPTデスクトップアプリのWorkまたはCodexから、プロンプト、実行周期、実行対象、ローカルプロジェクトなどを指定してスケジュール済みタスクを作成できます。
CLIやIDE拡張にはその管理画面がないため、デスクトップアプリまたはWebを使用します。(OpenAI Developers)
Workはクラウド設定を基本にすべきか
一般業務はクラウドを第一候補にし、ローカル資源が必要な場合だけデスクトップ実行にするのが扱いやすいです。
| タスク例 | 推奨構成 | 理由 |
|---|---|---|
| Android Autoのニュースを毎朝調査 | クラウドWork | Mac不要で継続可能 |
| Gmailを調べて週報を作成 | クラウドWork | 接続サービスだけで完結 |
| Dropbox内のクラウド文書を要約 | クラウドWork＋Dropbox接続 | Macの同期フォルダが不要 |
| Dropbox同期フォルダのファイルを直接編集 | ローカルWork | Mac内フォルダへのアクセスが必要 |
| WordPress管理画面を操作 | クラウドまたはローカルWork | ログイン方法・ブラウザ環境による |
| Home Assistantのローカル画面を操作 | ローカルWork | 家庭内LANへのアクセスが必要 |
| WBGT値を1時間ごとにHAへ送信 | HA／Python／launchd | AIを毎回使う必要がない |
| WBGTの異常値を分析して説明文を作成 | Work | 判断・文章作成が必要 |
| Codexのログを集計してHAへ送信 | ローカルスクリプト | ローカルファイルを正確に処理する |
| 集計結果から週次分析レポートを作成 | Work | 分析と成果物作成に適する |
WorkのWeb／モバイル版はクラウドで動き、デスクトップ版は許可されたローカルファイルやアプリも利用できます。
クラウドWorkとデスクトップWorkのスレッドやローカルファイルは、提供開始時点では別管理です。(OpenAI Help Center)
あなたの環境でのおすすめ構成
現在のHome AssistantやMac miniを考えると、次の3層に分けるのが安定します。
【定時起動・データ取得】
Home Assistant／Python／launchd
↓
【データ保存・状態監視】
JSON・SQLite・Home Assistantセンサー
↓
【判断・調査・レポート作成】
WorkのクラウドまたはローカルScheduled Task具体的には次のようになります。
| 担当 | 処理 |
|---|---|
| Home Assistant／Python | センサー値取得、API呼び出し、Webhook送信 |
| launchdなど | ローカルスクリプトの定刻起動 |
| Codex | スクリプトの作成、修正、テスト |
| Work | 結果の分析、異常の説明、週報・ブログ原稿の作成 |
| HAダッシュボード | 実行状態、成功・失敗、次回時刻の表示 |
判断基準
Macのファイルやアプリが不要なら、Workはクラウドで設定する。
Mac内のものを扱うなら、デスクトップWorkのスケジュール済みタスクを使う。
正確な定刻実行と単純処理が目的なら、WorkではなくOSまたはHome Assistantに任せる。
したがって、Workでもローカル定期実行によるmacOS側の問題は起こり得ます。
しかし、現在はWork自身のスケジュール済みタスクを先に試し、Macのスリープやアプリ終了に左右されたくない場合はクラウドWork、厳密なローカル定期処理ならlaunchdなどへ分けるのが適切です。
（参考）本ブログ記事の主題からは外れるが、Workのサービス提供も開始されたのでも利用枠制限に関する質問を行った。
利用枠が解除された際の自動継続・通知は可能か
5時間枠や7日枠の制限により利用が停止したのち、それらの制限がリセットされた際に、自動的に続きの処理が行われるという機能はありますか。また、制限により利用が停止した際に通知することはできますか
結論
現時点では、5時間枠や週次枠が回復した時点で、停止していたWork／Codexの処理を自動的に再開する標準機能は確認できません。
制限解除後に、同じ会話を開いて「続けて」と指示するか、Codexの再開操作を行う必要があります。
ただし、制限到達時に実行中だった1回のターンについては、すぐ中断せず、そのターンだけ完了まで継続できる設計です。これは無制限ではなく、フェアユース上の制約を受けます。(OpenAI Developers)
再開できないような状態で中断されるのではなく、ターン区切りで処理が継続され、完了まで継続されたターンが記録されることが分かった。
制限到達時の動作
| 状況 | Work | Codex |
|---|---|---|
| 作業ターンの途中で5時間枠に到達 | 原則として、そのターンは完了まで続行可能 | 原則として、そのターンは完了まで続行可能 |
| ターン完了後に次の工程へ進む | 利用枠がなければ停止 | 利用枠がなければ停止 |
| 5時間枠がリセットされた後 | 自動再開しない。会話から手動で「続きを実行」と指示 | 自動再開しない。同じタスクから手動再開 |
| 週次枠がリセットされた後 | 同様に手動再開 | 同様に手動再開 |
| 作業状態や会話履歴 | 同じ会話に残るため、そこから続けられる | タスクや会話を再開可能 |
| Goalモード利用時 | 一時停止・再開ボタンで手動操作 | /goal resumeなどで手動再開 |
| リセットまで待たずに続ける方法 | 追加クレジットが利用可能なら継続 | 追加クレジット、APIキー、リセット権などを利用 |
長時間作業用のGoalモードにも「一時停止・再開」はありますが、公式説明はユーザーが操作する方式です。
回線切断などが予想される場合も、いったん停止して後から再開する手順が案内されており、利用枠回復時の自動再開は記載されていません。(ChatGPT 学習サイト)
「1回のターン」とは
たとえば、次のような流れです。
| 工程 | 制限到達時の可能性 |
|---|---|
| 資料を読む | 同じターン内なら続行する可能性 |
| 分析する | 同じターン内なら続行する可能性 |
| 報告書を作る | 同じターン内なら続行する可能性 |
| 完成後、次の修正に移る | 新しいターンなので停止する可能性 |
| 追加でスライドを作る | 新しいターンなので停止する可能性 |
つまり、制限を少し超えても現在処理中のまとまりは完了させるが、その後の追加作業は開始できないという考え方です。
制限到達時の通知
| 通知・表示 | Work | Codex | 制限到達専用か |
|---|---|---|---|
| 画面内のエラー／案内 | ○ | ○ | おおむね○ |
| リセット予定時刻の表示 | アカウント・画面による | ○。取得できる場合に表示 | ○ |
| デスクトップのターン完了通知 | ○ | ○ | × |
| 質問・承認待ち通知 | ○ | ○ | × |
| 「Blocked」状態の表示 | ○ | ○ | ×。原因は制限以外も含む |
| スマートフォンへの完了通知 | 対応するクラウド作業・設定による | 対応タスクで利用可能 | × |
| 利用枠到達を知らせる専用プッシュ通知 | 公式には確認できない | 公式には確認できない | ― |
| 利用枠到達を知らせる専用メール | 公式には確認できない | 個人向け標準機能としては確認できない | ― |
| リセット後の自動再開通知 | × | × | ― |
Codexでは、利用制限エラーが画面内に表示され、分かる場合はリセット時刻も案内されます。(OpenAI Developers)
一方、デスクトップ通知として公式に説明されているのは、主に次の状態です。
- ターンが完了した
- 質問への回答が必要
- 操作の承認が必要
- 作業が「Ready」「Needs input」「Blocked」になった
通知はデスクトップアプリの設定で「常に通知」「バックグラウンド時のみ」「通知しない」などを選択できます。
ただし、「5時間枠を使い切った瞬間だけ通知する」という専用項目は公式資料に記載されていません。(ChatGPT 学習サイト)
実際の運用で期待できる通知
| 発生したこと | 通知される可能性 |
|---|---|
| 正常に作業が完了した | 高い |
| 承認が必要になった | 高い |
| ユーザーの入力待ちになった | 高い |
| 利用枠がなくなり「Blocked」になった | 状態表示される可能性はあるが、専用通知は保証されない |
| 5時間枠が回復した | 通知されない |
| 週次枠が回復した | 通知されない |
| 枠回復後に作業が自動再開した | 自動再開自体がない |
停止を避ける方法
| 方法 | 効果 | 注意点 |
|---|---|---|
| 追加クレジットを購入 | プラン内枠終了後も続行できる | 従量課金 |
| クレジットの自動補充 | 残高不足による停止を防ぎやすい | 設定金額まで自動購入される |
| 小さいモデルへ変更 | 同じ枠で多く処理できる | 品質や推論力が下がる場合がある |
| 作業を小さな単位に分割 | 中断後の再開地点が明確になる | タスク管理が必要 |
| 作業ログを残すよう指示 | 手動再開しやすくなる | 自動再開ではない |
| Goalモードを利用 | 長い作業の目的と進捗を保持しやすい | 再開操作は必要 |
Plus／Proでは、プラン内枠を使い切ると購入済みクレジットへ移行します。
自動補充を設定しておけば、クレジット残高が指定額を下回ったときに補充されるため、リセット待ちによる停止を回避する方法としては最も確実です。
WorkとCodexは同じクレジット残高を利用します。(OpenAI Help Center)
長時間作業を依頼するときの書き方
次のように指示しておくと、制限後の手動再開が容易になります。
作業を工程ごとに区切り、各工程が終わるたびに進捗を記録してください。利用制限やエラーで停止する場合は、完了済みの工程、未完了の工程、次に実行すべき処理を最後に記録してください。
現状をまとめると、制限到達時の画面表示はある、通常の完了・入力待ち通知もある、しかし「枠回復後の自動再開」と「利用枠専用の確実なプッシュ通知」はないという状態です。