この記事のポイント
- 2026年7月の更新で、ChatGPTデスクトップは 通常のチャット / Work / Codex を一つにまとめる方向へ進みました。Work は段階的ロールアウト中です
- Codex を使い始める順番は、プロジェクト・タスク・セッション -> フォルダ / ブラウザ -> レビュー -> スキル / プラグイン が自然です
- スキル / プラグイン はとても重要ですが、初日に全部設定する機能ではありません。まずは一つの小さな作業を完走しましょう
- スキルは主に
.agents/skills、Codex の設定・履歴・セッションは通常~/.codexにあります。ただし認証情報や会話ログを含み得るため、むやみに共有しません - GPT-Live は面白い新機能ですが、Codexデスクトップ本編ではなく、Web / モバイル向け ChatGPT Voice のおまけとして扱います
1. 導入: 大型アップデート直後、まず何を見ればいい？
こんにちは。AIおじさんです。
2026年7月9日、OpenAI は新しい ChatGPTデスクトップに、通常のチャット、Work、Codex をまとめる更新を出しました。ここで大事なのは、3つが常に横並びのタブとして見えるわけではないことです。通常のチャットは左ナビの Quick chat から始め、Work と Codex は左上のモード切替で選びます。Work は段階的ロールアウト中のため、まだ表示されないアカウントもあります。ChatGPT のリリースノート と ChatGPT Work and Codex
新しい Codexデスクトップは、相談からローカル開発、ブラウザ確認、レビューまでをまとめる「AI作業の管制塔」です。
すべてのボタンを覚える必要はありません。まずは使う順番を押さえ、必要になった機能を足していきましょう。
注意: 提供プラン、地域、ワークスペース設定、アプリのロールアウトにより、表示される項目や名称は異なります。本記事は 2026年7月13日時点の公式情報を土台にしています。
GPT-5.6 Sol / Terra / Luna 早見表
名前だけでは選びにくいので、まずは仕事の性質で分けると迷いません。
| モデル | 一言でいうと | 向いている仕事 |
|---|---|---|
| Sol | 最も深く考える主力 | 複雑な実装、曖昧な課題、調査・分析、設計、最終レビュー |
| Terra | 日常作業のバランス型 | 通常の開発、複数ツールを使う作業、Sol ほどの深さが要らない仕事 |
| Luna | 明確な反復作業を速く安く | 抽出、分類、変換、構造化要約、大量の定型処理 |
迷ったら Sol・標準推論から始め、日常作業は Terra、入出力が明確な大量処理は Luna に寄せます。利用できるモデルや設定はプラン・ロールアウトで異なります。Models
左のサイドバーには新しいタスク、スケジュール、プラグイン、サイト、プルリクエスト、チャットとプロジェクト一覧が並びます。右側のサイドパネルはブラウザで、作業中のサイトを開いて確認や注釈ができます。
2. 概念解説: チャット / Work / Codex は何が違う？
まず、3つの役割を分けると頭がすっきりします。これは画面上のタブ構成ではなく、用途の整理です。
| 場所 | 一言でいうと | 向いていること |
|---|---|---|
| チャット | 話す場所 | 質問、壁打ち、短い下書き、軽い相談 |
| Work | 任せる場所 | 調査、分析、資料、表、成果物づくり |
| Codex | 作る・直す・検証する場所 | コード、ローカルファイル、テスト、Git、PR、ブラウザ確認 |
例えるなら、チャットは同僚にちょっと聞く立ち話です。Work は依頼書を渡して成果物を作ってもらう机。Codex は、ファイル・端末・ブラウザ・レビュー画面がそろった開発作業台です。
Codex は Cursor や Claude Code の代わり？
完全に置き換えるかどうかは、使い方次第です。
すでに Cursor や Claude Code を使っているなら、Codexデスクトップの価値は「ターミナルを一つ増やすこと」だけではありません。プロジェクトとセッションを残すこと、ブラウザで確認すること、差分と PR をレビューすること、スキル / プラグインで作業を再利用することにあります。
CLI が得意な人は Claude Code や Codex CLI をそのまま使ってよいです。Codexデスクトップは、その前後の確認・継続・共有を一つの画面に寄せる役として考えると、無理がありません。
まず覚える順番と、実務での重要度は違う
ここが大事です。スキル / プラグインは長く使うほど効く超重要機能です。でも初日に設定から始めると、何が便利になったのか分からないまま終わりがちです。
| 最初に触る順番 | 目的 |
|---|---|
| 1. プロジェクト / タスク / セッション | 作業の置き場所と、続きから始める方法を知る |
| 2. フォルダ / ワークディレクトリ | Codex にどのファイルを見せるか決める |
| 3. 小さな依頼 | 例: テスト失敗の原因を調べる、README を直す |
| 4. 差分 / レビュー | AI が変えたものを自分で確認する |
| 5. サイドパネル / ブラウザ | ファイルを見ながら、実際の画面で確かめる |
| 6. スキル / プラグイン | うまくいった手順を再利用可能にする |
| 7. モデル / 推論 / 速度 | 難易度・待ち時間・コストを調整する |
| 8. ターミナル / スケジュール | 既存の開発運用や定期業務に合わせて足す |
個人的な実務優先度は、プロジェクト / セッション、スキル / プラグイン、フォルダ / ブラウザ、差分 / PRレビュー を最上位に置きます。
3. 実践: 画面の入口を一つずつ使い分ける
3-1. 左タブのプロジェクト: 作業部屋を先に作る
プロジェクトは、関連するチャット、タスク、ファイル、指示、参照元をまとめる箱です。Projects の公式ガイド にある通り、同じテーマやコードベースで何度も作業するなら、まずプロジェクトにまとめるのが正解です。
「記事執筆」「自社プロダクト A」「採用サイト改修」のように、仕事の単位で分けましょう。毎回ゼロから説明する回数が減ります。
ただし、ChatGPT のプロジェクトと、PC 上のフォルダを扱うローカルプロジェクトは同じではありません。前者は会話や資料の文脈をまとめる箱、後者は Codex がローカルの作業対象を持つための入口です。リポジトリを触るなら、対象フォルダを間違えないことが最初の安全策になります。
3-2. 新しいタスクとセッション履歴: 「新しいチャット」ではなく「新しい仕事」
タスクは成果単位で分けます。ただし、会話が長いからという理由だけで新しいタスクを切る必要はありません。
- ログイン不具合を直す
- PR のレビューコメントに対応する
- 今週の仕様変更を調べる
- Qiita 記事を下書きする
このように、完了条件が違うならタスクも分けます。同じプロジェクトの中で作れば、共通の資料や指示を使いやすくなります。逆に、同じ問題を掘り下げている途中なら、セッションを継続した方が、それまでの調査・判断・差分を引き継げます。
長いタスクは、切るより「圧縮して続ける」
長いタスクでは古い試行錯誤が混ざり、判断が鈍りやすくなります。自動圧縮もありますが、節目で /compact を使い、重要な前提だけを残して続けるのがおすすめです。Developer commands
| 状況 | 取る行動 |
|---|---|
| 目的は同じで、調査や実装だけが長くなった | 同じタスクを続け、節目で /compact
|
| 完了条件や対象フォルダが変わった | 新しいタスクを作る |
| 大きな目的を数時間以上かけて進めたい |
/goal で完了条件を明示し、同じタスクで進捗を継続する |
| 別案を試したいが、元の経緯も残したい |
/fork で分岐する |
ここは Claude Code との違いとして迷いやすい点です。/clear がないのではなく、CLI にはあります。 CLI の /clear は表示とタスク文脈をリセットして新しいタスクを始めます。一方、ChatGPTデスクトップの現行コマンド一覧には /clear はなく、/compact、/fork、新しいタスクを使い分ける設計です。
過去のタスクやチャットは、単なる履歴ではありません。前回の判断、試したコマンド、変更差分を持ったまま再開できる「作業ログ」です。迷子になったら新規タスクを乱発する前に、まず履歴を検索してください。
セッションはどこに保存されている？
Codex のローカルな状態のルートは CODEX_HOME で、通常は ~/.codex です。代表的には次のような場所があります。環境変数の公式リファレンス と トラブルシューティング で確認できます。
| 中身 | 代表的な場所 |
|---|---|
| セッションの記録 | ~/.codex/sessions |
| アーカイブ済みセッション | ~/.codex/archived_sessions |
| 履歴 | ~/.codex/history.jsonl |
| メモリー | ~/.codex/memories |
| 設定・認証・内部状態 |
~/.codex/ 配下 |
ここには会話ログや認証情報が含まれ得ます。特に auth.json のようなファイルは、Git に入れたり、スクリーンショットに写したりしないでください。保存場所を知るのは大切ですが、直接編集はまず UI や公式コマンドで代替するのがおすすめです。
3-3. サイドパネル: フォルダとブラウザが体験を変える
サイドパネルという呼び方には、バージョンによって多少揺れがあります。ここでは横に出る ファイル、プラン / 要約、レビュー、ブラウザ、補助タスク をまとめて指します。
個人的に、Codexデスクトップを CLI より使いやすいと感じる最大の理由がここです。AI に任せるだけでなく、IDE のようにファイルを横で確認しながら、今見ている箇所について指示できるからです。
これはリテラシーの優劣というより、作業の相性だと思います。ターミナルだけでファイルパスや画面の状況を言語化するより、横に表示した Markdown、仕様書、ソースコードを見ながら「この段落を直して」「この関数の意図を確認して」と頼める方が、非エンジニアを含めて操作しやすい人は多いはずです。
特に効くのは次の2つです。
- フォルダ / ファイル: Markdown、仕様書、ソースコードを確認しながら、対象を見失わずに依頼できる
- ブラウザ: 実際の画面を開き、注釈で変更したい場所を直接指定できる
ブラウザの強みは注釈です。画面を開いて変更箇所を直接指定できるので、「右上のボタン」を文章で説明したり、スクリーンショットに赤丸を付けたりする必要がほぼありません。ブラウザの公式ガイド では、ブラウザプラグイン、通常ブラウザとは別プロファイルで動くこと、機密性の高い操作には確認が入ることが説明されています。
@Browser で http://localhost:3000 を開いてください。
設定画面をスマホ幅で確認し、崩れている箇所に注釈を付けてください。
注釈した箇所だけを最小修正し、同じ画面で再確認して、変更点を要約してください。
ブラウザを使うと、「直したらしい」から「自分の画面で、直してほしい場所を指して確かめた」へ進めます。
3-4. 要約の表示切り替え、下部パネル、ターミナル
画面上の「要約」には、少なくとも2種類の意味が混ざりやすいです。
- 推論要約: AI がどの程度の短さで途中の考えを表示するか
- 変更の要約 / diff の範囲: 今回の turn だけを見るのか、タスク全体の差分を見るのか
前者は設定の model_reasoning_summary で auto、concise、detailed、none を調整できます。設定リファレンス を見ると、必要以上に長い表示が気になる人は短くする選択肢があります。
下部パネルは、主にターミナルを出す場所です。テスト、lint、開発サーバー、Git コマンドの出力を確認できます。統合ターミナルはタスク / プロジェクト / worktree の作業文脈とつながるので、エラーを毎回コピペしなくても状況を共有しやすいのが利点です。Integrated terminal では Cmd/Ctrl + J と Ctrl + backtick のショートカットも案内されています。
ただし、ターミナルは全員必須ではありません。すでに Claude Code や IDE のターミナルを使う運用なら、無理に一本化しなくて大丈夫です。Codexデスクトップ側ではブラウザ、差分確認、PR対応に寄せる使い方も十分ありです。
3-5. レビュー画面とプルリクエスト: AI の変更を必ず見る
ここは、コーディング用途やチーム開発で Codex を使う人なら必須です。AI がコードを書けるようになるほど、レビューは省けません。
一方で、全員が開発をするわけではありません。記事作成、調査、資料作成、サイトのたたき台づくりが中心なら、まずはファイルとブラウザを使いこなせば十分です。レビュー画面とプルリクエストは「Git で変更を管理し、他人とコードをやり取りする段階」に入ったら押さえる機能、と考えましょう。
レビュー画面は Git の変更差分を見て、コメント、stage / unstage、revert、/review による自己レビューなどを行う場所です。Code review の公式ガイド では、Codex が触っていないローカル作業ツリーの変更も見える場合がある点が説明されています。ここは少し注意です。自分や同僚の未コミット変更を、AI の変更と混同しないようにしましょう。
プルリクエストでは、プルリクエスト（PR）の文脈、差分、レビューコメントを見ながら、そのまま修正を依頼できます。GitHub 側から @codex review と頼む導線もあります。GitHub 連携の公式ガイド を確認し、必要なら gh のインストールと認証を済ませます。
この PR のレビューコメントを確認してください。
P1 相当の指摘から対応する候補を一覧にし、修正前に私の確認を待ってください。
修正後は diff、影響範囲、テスト結果を短くまとめてください。
「書かせる」より「差分を一緒に見る」。この習慣が、Codex を長く安全に使うコツです。
3-6. スキルとプラグイン: 自分の仕事を再利用できる形にする
繰り返す仕事が出てきたら、スキルとプラグインの出番です。最初に使うなら、Codex同梱の**スキルクリエイター（$skill-creator）**がおすすめです。何を自動化したいかを聞きながら SKILL.md の下書きを作ってくれます。Build skills
スキルは再利用可能な手順書、プラグインはスキルや外部接続をまとめて配るパッケージです。まずは「毎週のレポートをこの形式で要約する」のように、一つの定型作業から始めましょう。Skills & Plugins
プラグインは、いきなり自作の SaaS API 連携から始める必要はありません。まずは公式が用意しているプラグインを一つ入れ、何が追加されるのかを体験するのがおすすめです。その後、必要が見えたら MCP を通じて SaaS の API や社内ツールと接続できます。プラグインは便利なぶん権限も広がるので、提供元と要求権限は必ず確認してください。
| 用語 | ざっくりした役割 |
|---|---|
| スキル | 仕事の進め方を覚えさせる手順書 |
| プラグイン | スキルや接続機能を入れた配布パッケージ |
| アプリ / MCP | 外部データや外部操作につなぐ接続口 |
スキルはどこに保存される？ .agents と .codex の違い
まずはここだけ覚えれば十分です。
~/.agents/skills/ # 自分のためのスキル
<repo>/.agents/skills/ # リポジトリで共有するスキル
~/.codex/ # Codex の設定、履歴、セッション、認証などの状態
公式には、リポジトリの $REPO_ROOT/.agents/skills、個人の $HOME/.agents/skills、システムの /etc/codex/skills、OpenAI 同梱スキルが探索対象です。Build skills にまとまっています。
.agents は「仕事の型」を置く棚です。.codex は「Codex 自体の持ち物」を置く棚です。後者には機密情報や内部状態もあり得るので、スキル置き場のように気軽に編集・共有しないでください。
最初に作るスキルは、大きなものではなくて構いません。たとえば「PRレビュー用」「ブログ下書き用」「障害報告の要約用」など、月に何度も繰り返す仕事を一つ選ぶのがおすすめです。
Claude Code のスキルは引き継げる？
はい。手で .claude 配下のスキルをコピーする方法も考えられますが、先に公式の Import を試すのがおすすめです。ChatGPTデスクトップの Settings > Import では、対応エージェントから instructions、設定、スキル、プラグイン、プロジェクト、直近のタスク、MCP 設定、hooks、サブエージェントなどを選んで引き継げます。既存の Claude Code 側の設定は変更・削除されません。Import from another agent
手作業で移す場合は、.claude/skills を丸ごと増やす前に、一つずつ .agents/skills へ置いて試してください。パス、参照先、外部コマンド、権限設定に Claude Code 固有の前提が残っていることがあるからです。
3-7. モデル選定・推論レベル・速度: 最初はデフォルトでよい
この3つは、つまみに見えて意外と迷いやすい場所です。
| 項目 | 何を変えるもの？ | 最初の考え方 |
|---|---|---|
| モデル | 誰に頼むか | 難しい作業は強いモデル、繰り返し作業は軽いモデル |
| 推論レベル | どれだけ考え込ませるか | 迷ったら標準。設計・調査・難バグで上げる |
| 速度 / Fastモード | どれだけ急がせるか | 小さな仕事や待ち時間を減らしたい場面で使う |
モデルの出力差を毎回その場で判定するのは、正直かなり難しいです。私は工程ごとに、ざっくりした運用ルールを置く方が実用的だと思います。
| 工程 | まず選ぶ目安 |
|---|---|
| 調査・分析・計画・レビュー | 最上位モデル。推論も高め |
| 実装・修正 | 中位から上位モデル。難所だけ推論を上げる |
| ルーティン・大量の単調処理 | 下位モデル。入力と出力形式を明確にする |
これは絶対の正解ではありません。タスクの重要度、失敗コスト、待ち時間で調整するための「仮の交通整理」です。公式も、必要な結果が出る最も低い推論レベルから始め、計画・分析・確認が必要なときに上げることを勧めています。Models
Fastモードは贅沢品？
私は、基本は贅沢品という理解でよいと思います。Fastモードは品質や推論力を上げる機能ではなく、対応モデルを速く動かすために追加の credit を使う機能です。現行の公式説明では、標準より 1.5 倍速くし、GPT-5.5 では 2.5 倍、GPT-5.4 では 2 倍の credit 消費とされています。Speed
つまり、待ち時間をお金で買うオプションです。締切直前の短い反復や、手元で何度も確認する作業には価値があります。一方、バックグラウンドで走らせる仕事、長い調査、単純な大量処理では、まず Luna のような軽いモデルや推論レベルの調整を検討した方が、費用対効果はよいはずです。
3-8. スケジュールとサイト: 仕事が固まってから使う
スケジュールは、単発予約、定期実行、監視型の作業に使います。毎朝の差分要約、毎週の依存関係チェック、週次の PR棚卸しなどが候補です。Automations に詳しい説明があります。
ただし、定期化は手動タスクが安定してからです。毎回「今日の状況」を説明しないと動かないプロンプトは、すぐ古くなります。定期タスクには、入力、判断条件、出力形式、異常時の扱いを明示しましょう。ローカルファイルを使う場合は、PC とアプリが起動している必要があります。
毎週月曜 9 時に、このリポジトリの未対応 Issue と直近 PR を確認してください。
今週着手すべき候補を 5 件以内でまとめ、該当がなければ「大きな更新なし」と報告してください。
**サイト（Sites）**は、ChatGPT が作った Web サイトや Web アプリをホストして共有する機能です。プロトタイプ、社内ツール、LP の公開まで進めたい場面で便利です。Sites の公式ガイド にある通りパブリックベータなので、プランや設定に差があります。公開URLは本番URLと同じ気持ちで扱い、秘密値をプロンプトや設定ファイルに入れないでください。
3-9. Computer Use、worktree、サイドタスク: 使いどころを絞る
Computer Use は、GUI アプリを見ながらクリックや入力を行う機能です。ブラウザや API / MCP のような構造化された接続があるなら、まずはそちらを優先します。画面操作そのものが必要なときに使う機能です。macOS では Screen Recording と Accessibility、Windows では前面のデスクトップ操作という制約があります。Computer Use を確認しましょう。
worktree は、同じ Git リポジトリから独立した作業場所を作り、複数の変更をぶつけにくくする仕組みです。大きな実装や並列作業で効きます。Git worktrees の対象は Git リポジトリです。
サイドタスクやサブエージェントは、タスクを分けるほど得になる場面で使います。最初から並列化するよりも、先に一つのタスクをレビューまで完走できるようにする方が、結果的に速いです。
3-10. Goal mode と Record & Replay: 長い仕事と「見せて覚えさせる」仕事
Goal mode は、目的と完了条件を持たせて、長めの仕事を進めるための機能です。たとえば「管理画面の検索遅延を改善し、計測とテストまで終える」のように、完了の定義を最初に渡します。大きな仕事ほど、最初の依頼に「やらないこと」と「確認を求める条件」も書くと、途中でぶれにくくなります。
Record & Replay は、画面上の操作を一度見せて再利用可能なスキルに変える機能です。文章で説明しづらい定型作業に向いています。2026年6月時点の macOS 向け機能で、Computer Use の有効化と提供地域の条件があります。リリースノート を確認して、使える環境なら「毎月同じ画面で行う登録作業」から試すのがよさそうです。
4. 壁と解決: 初見のつまずきと、まだ解けていない運用課題
壁1: 機能が多すぎて、全部設定したくなる
これは自然な反応です。でも最初に必要なのは設定ではなく、小さなタスクを一つ終えることです。
プロジェクトを作り、フォルダを選び、小さな修正を頼み、差分とブラウザで確認する。ここまでできれば、スキル / プラグインの価値も見えます。
壁2: スキル、プラグイン、MCP がごちゃごちゃになる
定義は 3-6 の表に戻れば十分です。再利用したい手順はスキル、外部のデータや操作が必要ならプラグイン / アプリ / MCP、と判断できれば進めます。
壁3: AI が直したが、何を変えたか分からない
ここでレビュー画面が効きます。依頼文に、最初から「最小修正」「変更差分」「テスト結果」「影響範囲」を入れてください。
変更は最小にしてください。
修正後、diff とテスト結果、影響する画面を3点以内で報告してください。
不確実な点があれば、実装前に質問してください。
AI を信用しないという話ではありません。仕事の成果物として、人間が確認できる形にしてもらう話です。
壁4: モデル設定が正解探しになる
正直、ここは少し沼です。
解決策は「デフォルトを基準にする」こと。失敗したから推論レベルやモデルを上げる、軽い定型作業だから下げる。Fastモードは品質を上げる手段ではなく、待ち時間を減らすための贅沢品として必要なときだけ使う。比較対象があると判断できます。
運用課題1: プロジェクトが乱立して見づらい
これは正直、まだ答えが出ていません。プロジェクトは便利なので、つい仕事ごと、検証ごと、記事ごとに増えます。気が付くと一覧が長くなり、「この作業はどこだったか」を探す時間が増えます。
公式の考え方は明快です。継続する仕事、複数の成果物を出す仕事、同じファイルや資料を共有する仕事だけをプロジェクトにする。 単発で完結する調査や小さな検証は、プロジェクトを作らず単独タスクにします。Projects, chats, and tasks
表示の整理には、プロジェクトやよく戻るタスクをピン留め、成果が分かる短い名前へ変更、終わったタスクをアーカイブ、検索を使うのが公式導線です。まずは「継続する対象だけプロジェクト化」「単発はタスク」「完了したらアーカイブ」の3ルールを置くと、かなり減らせます。
ただし、プロジェクトにフォルダ・タグ・階層を付ける機能は、現行の公式案内には見当たりません。私も完全には整理し切れていません。これは製品側が今後解いてほしい課題です。
運用課題2: スキルとプラグインがだるま式に増える
便利だから入れる。入れたことを忘れる。似たものが増える。古い手順や使えなくなった接続が残る。これはスキル / プラグイン運用のあるあるです。
私の環境でも、スキルとプラグインは 200 件近くあり、全部を把握・メンテナンスできていません。Codex は大量のスキルがある場合、最初に渡す一覧をコンテキスト量に合わせて短縮し、一部を省略することもあります。Build skills つまり「たくさん入れておけば全部いつでも賢く使える」わけではありません。
公式には、不要になったスキルを削除せずに無効化する方法があります。~/.codex/config.toml に個別設定を置けば、休止中のスキルを残したまま初期候補から外せます。
[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false
また、チーム共有のスキルはリポジトリの .agents/skills、個人用は ~/.agents/skills に分けるのが公式の想定です。プラグインについては、組織環境なら管理者が配布・無効化・接続アプリの権限を管理できます。Build skills Plugins in Codex
当面の現実解は、よく使うものを明示して呼び出す、個人用とチーム用を分ける、四半期ごとに使っていないものを休止する、の3つです。なお、スキルだけのプラグインを個別に無効化する管理機能は弱く、ここもまだ発展途上です。
運用課題3: モデル選定の正解が分からない
出力の差を毎回きれいに比較するのは難しいです。そのため現状は、「調査・分析・計画・レビューは最上位」「実装は中位から上位」「ルーティンや大量の単調処理は下位」という工程別の目安で回しています。
それでも万能の正解はありません。自分の代表タスクを 5〜10 件だけ選び、モデルごとに「受け入れ可否」「やり直し回数」「所要時間」「credit」を記録する小さな評価表を作ると、感覚だけで選ぶ状態から抜け出せます。これを四半期ごとに見直せば、モデル更新にも追従しやすくなります。
5. まとめ: 最初の30分はここだけ見ればよい
新しい ChatGPTデスクトップは、できることが多いぶん、入口で迷いやすいアプリです。
でも、最初から全部使う必要はありません。
- プロジェクトを作る
- 一つのタスクを小さく切る
- 対象のフォルダ / ワークディレクトリを確認する
- 修正や調査を頼み、差分 / レビューを見る
- ブラウザで動作を確かめる
- 繰り返す仕事が見えたらスキル / プラグインを足す
まずは、いま抱えている小さなバグ修正か README 更新を一つ、Codex で最後までやってみてください。そこで「この手順は毎回使うな」と思えたら、次にスキルを作る番です。そこから一気に、自分用の作業台になっていきます。
おまけ: GPT-Live はモバイル向け？
はい。位置づけとしては Codexデスクトップ本体ではなく、ChatGPT Voice の新しい Live 体験です。
GPT-Live は自然な双方向会話を目指した音声体験で、Web と iOS / Android 向けにロールアウトされています。実際に使ってみると、壁打ちにはかなり向いています。考えがまとまっていなくても話し始められ、途中で割り込んだり、方向を変えたりできる体験は面白いです。ChatGPT Voice の案内 と Introducing GPT-Live を見ると、話しながら考えを整理したい、アイデア出しをしたい、といった用途に向いています。
現時点では、Live の会話を Work や Codex へそのまま引き継いだり、画面共有の裏でエージェントを動かしたりはできません。Live 自体も初期段階ではビデオ・画面共有に対応していません。ChatGPT Voice の案内
一方、ChatGPTモバイルアプリから、接続した Mac / Windows ホスト上の Codex 作業を開始・継続する仕組みはあります。ChatGPT Release Notes Live から Codex へ自然に仕事を渡せるようになれば、働き方はかなり変わりそうです。これは筆者が期待する次の一手です。