Codexのプロンプト入力欄の左側にある「＋」を開くと、「ChatGPTの会話」「タブ」「ファイルとチャット」といった項目が表示されるようになっているのに気がついた。
一見すると添付機能が増えただけのようにも見えますが、実際にはかなり重要な変化です。
これまで私は、ChatGPTでWebアプリの仕様を相談し、その内容をCodex向けの指示書にまとめてもらい、それをコピーしてCodexへ渡していました。
Codexで実装した後は、その回答を再びChatGPTへコピーし、Webアプリの表示状態についても文章やスクリーンショットでChatGPTに説明する、という作業を何度も繰り返していました。
今回確認した機能を使うと、この「人間がChatGPTとCodexの間を何度も往復して情報を運ぶ」という作業をかなり減らせそうです。
この記事では、これらの機能が何をするものなのか、実際の開発フローをどう変えられるのか、さらにプラグイン「ブラウザ」やプラグイン「コンピュータ（Computer Use）まで組み合わせると何ができるのかを整理します。
注）本記事の内容は正確性を保証するものではない。
（2026年8月27日 追記）YouTube動画を追加しました。 https://youtu.be/2nK3C91ncI4
Codexの「＋」はファイル添付ではなく「コンテキスト追加」になっている
Codexの「＋」は、以前のような単純なファイル添付ボタンと考えるより、「Codexに何を見せて仕事をさせるかを決めるボタン」と考えた方が分かりやすくなっています。
主な項目は次のとおりです。
| 表示 | 機能 | 主な使い方 |
|---|---|---|
| ChatGPTの会話 | 過去のChatGPT会話を現在のCodex作業のコンテキストとして追加 | ChatGPTで相談した仕様をCodexへ引き継ぐ |
| タブ | Chromeなどで現在開いているWebページをCodexへ追加 | Webアプリ、管理画面、ドキュメントなどを見ながら修正する |
| ファイルとチャット | 一覧にないファイルやChatGPT会話を検索 | 過去の会話、仕様書、READMEなどを探して追加する |
| ＋ボタン全体 | Codexへ追加するコンテキストの入口 | 会話・Webページ・ファイルを組み合わせて作業する |
特に便利なのが「ChatGPTの会話」です。
ChatGPTで、「こういう機能を作りたい」と相談して仕様を固めた後、Codexを開いて、
＋ → ChatGPTの会話 → 該当する会話
を選択できます。
そのうえで、
このChatGPT会話で確定した仕様に従って実装してください。
と指示できます。
元のChatGPT会話そのものがCodexへ移動するわけではありません。
ChatGPTの会話は元の場所に残り、Codex側がその会話を作業コンテキストとして参照する形です。
（ChatGPT-5.5 Solへの質問）これらの機能はいつから使えるようになったのですか
ここは少し複雑でした。「ChatGPT の会話／タブ／ファイルとチャット」がまとまったメニューについて、OpenAIは「○月○日にこのメニューを追加した」とは発表していません。
ただし、変更履歴を追うと段階的に導入されたことが分かります。
| 日付 | 変更 |
|---|---|
| 2026年2月26日 | Codexのcomposerに「Add context」メニューがすでに存在。MCPサーバーのサブメニューなどが追加された |
| 2026年5月7日 | 「Codex for Chrome」拡張機能を正式導入。ブラウザの複数タブを使った作業が可能に |
| 2026年7月9日 | Codexが独立アプリからChatGPTデスクトップアプリの一部へ統合 |
| 2026年7月10日までには | ChatGPTの会話をCodexへ「Add to task」する機能が実際に利用されていたことを確認可能 |
| 2026年7月30日 | OpenAIがChrome拡張機能から開いているタブをmentionできる機能を公式変更履歴に明記 |
| 2026年8月25日 | タブ参照・ブラウザ操作がChromeだけでなくEdge、Brave、Opera、Vivaldiにも拡大 |
「Add context」という仕組み自体は少なくとも2026年2月26日には存在していました。
ブラウザについては、Codex Chrome拡張機能が2026年5月7日に登場しています。この時点で複数タブをバックグラウンドで扱う仕組みが導入されました。
大きな転機は2026年7月9日です。この日にOpenAIは「Codex joins the ChatGPT desktop app 26.707」と発表し、macOSとWindowsでCodexをChatGPTデスクトップアプリへ統合しました。
そして翌日の7月10日には、OpenAIのCodex公式GitHubリポジトリに「ChatGPT Webの会話を追加し、『Add to task』してCodexへ送った際の不具合」という報告が出ています。つまり、少なくともこの時点ではChatGPT会話をCodexのコンテキストとして追加する機能が実際に提供されていたことが確認できます。
さらに7月30日の公式更新で、Chrome拡張機能について「開いているタブをmentionする」機能が明示的に追加・案内されています。
そして8月25日には、このタブ参照機能がEdge、Brave、Opera、Vivaldiまで広がりました。
したがって今回の画面については
私の調査結果をまとめると、「＋」によるコンテキスト追加自体は以前からあったものの、添付画像のようにChatGPTの過去会話やブラウザのタブまで一体的に選べるようになったのは、2026年7月のChatGPT・Codex統合以降と考えるのが妥当です。
特に 「ChatGPT の会話」については少なくとも7月10日には利用可能、「タブ」については7月30日の更新で公式に明記、というところまでは日付を裏付けられます。
今回の機能は、これまでの「ChatGPTで仕様を相談してからCodexへ移る」という作業をかなり変える可能性があります。
次に、「ChatGPTで仕様検討 → 過去会話を＋で指定 → Codexで実装」という実際の操作を、現在のブログ記事編集アプリを例にして一度テストしてみると、この機能がどこまで会話内容を正確に引き継げるか確認できます。
「タブ」では、現在ブラウザで見ている状態をCodexへ渡せる
もう一つ大きいのが「タブ」です。
Chromeなどで開いているWebページをCodexへコンテキストとして追加できます。
例えば、
- localhostで動かしているWebアプリ
- Microsoft Clarity
- Google Search Console
- 管理画面
- 公式ドキュメント
などを開いた状態でCodexへ渡せます。
これまでなら、
実装後に確認すると、○○の下に××が表示されています。
と文章で説明したり、スクリーンショットを撮ったりしていました。
タブを直接渡せれば、
このWebアプリの現在の表示を確認し、問題を修正してください。
という依頼に近づきます。
通常のWeb検索とは違い、自分が今ブラウザで開いているページを明示的にCodexへ渡すところがポイントです。
「ファイルとチャット」は必要な情報を探す入口
「入力してファイルやチャットを検索」という欄から、過去の会話やファイルを探せます。
例えば、
- Stream Deck
- WordPress
- Safari
などのキーワードから、必要な会話や資料を探す使い方です。
重要なのは、何でもCodexへ渡すのではなく、
「今回の作業に本当に必要なものだけ探して渡す」
ことです。
後述しますが、これはCodexのコンテキストやPlusの利用枠を節約するうえでも重要になります。
ChatGPTとCodexの間で行っていた「伝令作業」を減らせる
私がこれまで行っていた開発では、おおむね次のような流れになっていました。
ChatGPTで仕様相談
↓
実装方針を決める
↓
Codex向け実装指示書を作成
↓
Codexへコピー＆ペースト
↓
Codexが実装
↓
Codexの回答をChatGPTへコピー
↓
ChromeでWebアプリを確認
↓
画面状態を文章やスクリーンショットで報告
↓
修正仕様を相談
↓
再びCodex用指示書を作成かなりの部分を私自身が中継していました。
今回の機能を使うと、これを次のようにできます。
ChatGPTで仕様相談
↓
Codexの「＋」から
そのChatGPT会話を選択
↓
必要ならWebアプリのタブも追加
↓
Codexが実装
↓
コードと実画面を確認
↓
必要な場合だけChatGPTへ戻るつまり、
「仕様をコピーする作業」と「Webアプリの状態を文章で説明する作業」をかなり減らせます。
毎回「Codex向け実装指示書」を作らなくてもよくなる
これまで私は、ChatGPTで仕様が決まると、
この内容をCodex向け実装指示書にしてください。
と依頼し、その回答をCodexへ貼り付けることがよくありました。
今後は、Codex側で該当するChatGPT会話を選び、
このChatGPT会話で確定した仕様を確認してください。 確定事項だけを現在のプロジェクトへ実装してください。
程度の指示で済むケースが増えます。
もちろん、大規模な変更や、正式な記録として残したい仕様では、今後も実装指示書を作る価値があります。
しかし、小規模な修正まで毎回長い実装指示書を作る必要はなくなりそうです。
ChatGPT会話・コード・Web画面をCodex側へ集める
Webアプリ開発なら、さらに効果が大きくなります。
Codex側へ、ChatGPT会話「どういう仕様にするべきか」、ローカルコード「現在どう実装されているか」、Chromeタブ「実際にどう表示されているか」を集められるからです。
これまでは、この3つの情報を人間が何度も行き来しながら説明していました。
今後はCodex側で、
仕様を読む
↓
コードを確認
↓
修正
↓
ブラウザで確認
↓
問題があれば再修正というループをできるだけ完結させ、人間は最後の確認と仕様判断に集中する、という使い方が考えられます。
ChatGPTとCodexの役割分担も変えられる
この仕組みを使うと、ChatGPTとCodexの役割も整理しやすくなります。
| ChatGPT | Codex |
|---|---|
| 要件整理 | コード調査 |
| 仕様相談 | 実装 |
| UI方針 | ファイル編集 |
| 複数案の比較 | テスト |
| 仕様変更の判断 | エラー調査 |
| 記事化・説明 | Web画面確認 |
| 次フェーズの設計 | リファクタリング |
つまり、
ChatGPT＝設計・相談
Codex＝実装・検証
という分担です。
これまで人間がその間の「伝令係」も担当していました。
今回のコンテキスト機能は、その伝令作業のかなりの部分を減らすものだと考えています。
ただし、ChatGPTとCodexが完全同期するわけではない
ここで一つ問題が残ります。
今回の機能で非常に簡単になるのは主に、ChatGPT → Codexです。
さらに、Chrome → Codexも簡単になります。
しかし、Codex → ChatGPTについては、常時自動的に同期されるわけではありません。
Codexでどのファイルを変更し、どのテストを行い、何が未解決なのかをChatGPTへ戻したい場合には、別の受け渡し方法が必要です。
そこで考えたのが、共有Markdownファイルを「AI間の受け渡し箱」として使う方法です。
CODEX_LATEST.mdをCodexとChatGPTの受け渡し箱にする
第一候補として考えたのが、Google Drive上などに固定のMarkdownファイルを用意する方法です。
例えば、
AI Skill ランチャー/
└ handoff/
├ CODEX_LATEST.md
├ PROJECT_STATUS.md
└ history/
├ 2026-08-27_001.md
└ 2026-08-27_002.mdという構成です。
CODEX_LATEST.md
直前のCodex作業だけを保存します。内容の例は下記の通りです。
Codex 作業引き継ぎ
今回の依頼:
「よく使うSkill」の登録機能追加
実施内容:
- skill_launcher.pyを変更
- favorites.jsonを追加
- UIに「よく使う」を追加
変更ファイル:
- skill_launcher.py
- favorites.json
テスト結果:
- 一覧表示: 成功
- Skill起動: 成功
- 履歴保存: 成功
現在の問題:
「よく使う」から削除した直後に表示更新されない
ChatGPTに相談したい事項:
一覧を即時再描画する方式にするか、
アプリ再起動時更新にするか判断が必要ChatGPTでは、
CODEX_LATEST.mdを参照して、未解決事項について相談したいです。
という使い方を目指します。
PROJECT_STATUS.mdにはプロジェクト全体の現在地を保存する
長期開発では、直前の作業だけでは足りません。
そこで、「PROJECT_STATUS.md」も用意します。
例えば、
AI Skill ランチャー 現在の状態
完成済み:
- Skill一覧
- 最近使ったSkill
- Codex CLI起動
- 日本語用途名
実装中:
- よく使うSkill
未実装:
- アイコン
- Skill追加時の自動認識
既知の問題:
...
次の予定:
...という形です。
すると、新しいChatGPT会話を始めた場合でも、
PROJECT_STATUS.mdとCODEX_LATEST.mdを読んで、現在の開発状況を把握してください。
という形で状況を復元しやすくなります。
クリップボードよりファイルを使う
一時的な受け渡しならクリップボードでも可能ですが、長期的なAI間連携には向いていません。
理由は、
- 次にコピーすると内容が変わる
- 履歴を管理しにくい
- どの時点のCodex回答かわかりにくい
- 長文の引き継ぎに向かない
ためです。
そのため、
一時的な受け渡し＝クリップボード
継続的な引き継ぎ＝Markdownファイル
と分ける方が扱いやすくなります。
Terminalの結果もChatGPTへコピーしなくてよい
開発中には、ChatGPTから、
このコマンドをTerminalで実行して、その結果を教えてください。
と言われることがよくあります。
これまでは、
ChatGPT
↓
コマンドを教えてもらう
↓
Terminalで実行
↓
結果をコピー
↓
ChatGPTへ貼り付けという流れでした。
macOSのChatGPTデスクトップアプリには「アプリと連携（Work with Apps）」があり、Appleのターミナル、iTerm、Warp、Promptなどの内容をChatGPTから参照できます。
開いているTerminalペインの末尾200行程度が渡され、文字列を選択している場合は選択部分が優先されます。
そのため、
ChatGPT
↓
コマンドを提示
↓
Terminalで実行
↓
「Terminalの結果を確認してください」まで短縮できます。
Terminal結果をコピーして貼り付ける作業を減らせます。
Terminalの実行自体はCodexへ任せた方がよい場合もある
ただし、ChatGPTがTerminalを参照できることと、Terminalへコマンドを入力して実行することは別です。
開発作業なら、
ChatGPTがTerminal結果を読んでCodexへ伝える
より、
Codex自身に必要なコマンドを実行させて結果を判断させる
方が効率的な場合があります。
そこで全体を整理すると、次のようになります。
| 作業 | 主な担当 |
|---|---|
| 仕様相談 | ChatGPT |
| ChatGPT → Codex | ChatGPT会話をコンテキスト追加 |
| 実装 | Codex |
| コマンド実行 | 可能ならCodex |
| 人間がTerminalを実行した場合 | ChatGPTデスクトップアプリから参照 |
| Webアプリ画面確認 | Codex＋ブラウザタブ |
| Codex → ChatGPT | CODEX_LATEST.md |
| プロジェクト全体の状態 | PROJECT_STATUS.md |
便利だからといって何でもCodexへ渡せばよいわけではない
ここで気になるのがCodexの利用枠です。
Plusプランでは5時間枠、週間枠があるため、
- ChatGPT会話
- Chromeタブ
- ファイル
- Terminal
を大量に連携すると、どの程度影響するのかという問題があります。
結論としては、
連携機能を利用可能にしているだけで大きく消費するというより、実際にCodexへ渡して処理させるコンテキストやツール利用が増えるほど、消費も増える方向
と考えた方がよさそうです。
「接続している数」より「実際に読ませる量」が重要
例えば、
- ChatGPT会話が10件候補にある
- Chromeタブが8枚開いている
- ファイルが100個ある
というだけで、それら全部が毎回Codexへ送られているわけではありません。
しかし、
- ChatGPT会話3件
- Chromeタブ5枚
- 巨大なログファイル
- Terminalの大量ログ
を今回の作業で実際に読ませれば、当然コンテキストは増えます。
連携数そのものより、そのターンで何を実際に使わせるかが重要です。
長いChatGPT会話を何件も渡さない
過去の長い会話には、
- 初期仕様
- 古い仕様
- 修正版仕様
- Codexの回答
- Terminalログ
- スクリーンショットの説明
などが混ざっていることがあります。
これを何件もCodexへ渡すと、コンテキスト消費だけでなく、古い仕様と新しい仕様が混ざる危険もあります。
そのため、今回必要なChatGPT会話を1～2件だけ選ぶくらいの方が扱いやすくなります。
PROJECT_STATUS.mdはコンテキスト節約にも使える
ここで先ほどの引き継ぎファイルが効いてきます。
過去の長いChatGPT会話を毎回読ませる代わりに、
PROJECT_STATUS.md
CODEX_LATEST.mdだけを参照させれば、かなり短い情報量で現在の状況を伝えられます。
つまり、この方式は、手動コピーを減らすだけではなく、Codexへ渡すコンテキストを減らすという効果もあります。
キャッシュがあるから大量に渡してもよい、とは考えない
同じ内容を繰り返し使えばCached Inputが効く可能性はあります。
しかし、Plusの5時間枠や週間枠について、キャッシュがヒットすれば具体的に何％利用枠を節約できるかという計算式は公開されていません。
したがって、
たくさんコンテキストを渡せばキャッシュが効くから有利になる
とは考えない方が安全です。
毎回変化する、
- Chromeタブ
- Terminalログ
- 最新ファイル
- 新しいChatGPT会話
を大量に追加すれば、キャッシュできる固定部分があっても、新しく処理する情報も増えます。
「固定情報」と「今回だけの情報」を分ける
私が使うなら次のように分けます。
【常時・安定】
AGENTS.md
PROJECT_STATUS.md
────────────────
【作業ごと】
CODEX_LATEST.md
今回関係するChatGPT会話
必要なChromeタブ
必要なファイル
────────────────
【問題調査時だけ】
Terminal大量ログ
過去の全履歴
複数Chromeタブ
古いChatGPT会話つまり、連携機能は、
「全部つないで常時見せる」ためではなく、「必要な情報を必要な時だけ追加する」ための仕組み
として使うのがよさそうです。
そもそも、これらの機能は何のために作られたのか
ここからは少し一般的に考えてみます。
「ChatGPTの会話」「タブ」「ファイルとチャット」は、単なる添付機能の拡張ではなく、
人間がこれまで文章で説明していた「作業背景」をCodexへ直接渡すための仕組みと考えると理解しやすくなります。
| 機能 | 本来想定されていると考えられる使い方 | さらに広げた使い方 |
|---|---|---|
| ChatGPTの会話 | ChatGPTで行った相談・設計・調査をCodexへ引き継ぐ | 会話を一時的な仕様書、Issue、障害報告として使う |
| タブ | 今見ているWebページやWebアプリをCodexへ見せる | Webページそのものを動く仕様書やテスト対象にする |
| ファイルとチャット | 必要な資料・過去会話を検索する | PROJECT_STATUS.mdなどを選ぶコンテキスト・ルーターとして使う |
| ローカルファイル | コードや設定を参照する | AI間の引き継ぎメモリとして使う |
| 画面コンテキスト | 現在の画面状態を理解させる | 画面を動作確認やテスト結果として使う |
Browserと組み合わせると「見る」だけでなく「確認する」へ進む
プラグイン「ブラウザ」の機能（Browser）と組み合わせると、さらに用途が広がります。
| 組み合わせ | できること |
|---|---|
| ChatGPT会話＋Browser | ChatGPTで決めたUI仕様を読み、実際のWebアプリを確認しながら修正 |
| タブ＋Browser | 問題のある画面を確認し、修正後にリロードして再確認 |
| ファイル＋Browser | ソースコードと実際の表示を突き合わせる |
| 仕様書＋Browser | 文書上の要求を現在のWebアプリが満たしているか確認 |
| テストケース＋Browser | Markdownの手順に従って画面操作と結果確認 |
| 不具合報告チャット＋Browser | 過去に報告された症状を実際の環境で再現 |
| 公式資料＋ローカルアプリ | ドキュメントと現在のコードを比較 |
特にWebアプリ開発なら、
仕様を読む
↓
コードを直す
↓
ブラウザを見る
↓
また直すというループをCodex側へ寄せられます。
Computer Useまで組み合わせるとWeb以外にも広がる
プラグイン「コンピュータ」（Computer Use）では、画面を見て、クリックし、文字入力するといった操作まで対象になります。
すると、ブラウザだけでは完結しない作業にも広げられます。
| 組み合わせ | 使い方 |
|---|---|
| ChatGPT会話＋Computer Use | 会話で決めた手順をデスクトップアプリで実行 |
| ファイル＋Computer Use | Markdownの操作手順書を読んでGUI操作 |
| タブ＋Computer Use | Webで確認した内容を別アプリへ反映 |
| コード修正＋Computer Use | コード変更後、実際のアプリを起動して動作確認 |
| テスト仕様＋Computer Use | GUIテスト項目を順番に実行 |
| 不具合チャット＋Computer Use | 過去の症状を読み、アプリ上で再現操作 |
| Browser＋Computer Use | Webとデスクトップアプリをまたぐ作業 |
これまで人間が行っていた、
説明する
↓
コードを書かせる
↓
人間が操作する
↓
結果を説明する
という流れを、
コンテキストを与える
↓
Codexが判断する
↓
コードを変更する
↓
実際の画面を操作・確認する
という形に近づけられます。
「コンテキスト → 判断 → 操作」の3層で考えると分かりやすい
今回調べた機能全体は、次の3層に分けると整理しやすくなります。
| 層 | 主な機能 | 役割 |
|---|---|---|
| ① コンテキスト層 | ChatGPT会話、タブ、ファイル、画面情報 | 必要な情報を集めて理解する （何を知っておくべきか） |
| ② 判断・実装層 | Codex、Goal mode、Skills | 目標を理解し計画し実装する （何をどう変更するか） |
| ③ 操作・検証層 | Browser、Computer Use、Terminal | 実際に操作し結果を検証する （実際に動かして確認する） |
これらがつながることで、Codexは単にコードを書いて返すだけではなく、
過去の相談を読む
↓
現在の画面を見る
↓
コードを変更する
↓
実際に動かす
↓
結果を確認するところまで担当する開発エージェントへ近づいています。
私が一番変わると感じたのは「AI同士の間で人間が運ぶ情報」が減ること
今回の機能を見て最初に感じたのは、個々の機能の便利さよりも、
ChatGPTとCodexの間で私が何度も行ってきた情報の中継を減らせる
ということでした。
今後の開発フローは、例えば次のようにできます。
【ChatGPT】
仕様を相談
↓
仕様確定
【Codex】
├ ChatGPTの該当会話
├ 必要なWebアプリのタブ
└ 必要なファイル
↓
実装
↓
テスト
↓
画面確認
↓
CODEX_LATEST.md更新
【ユーザー】
最終確認
↓
問題なし → 完了
仕様判断が必要
↓
【ChatGPT】
PROJECT_STATUS.md
CODEX_LATEST.md
を参照して相談
↓
【Codex】
更新されたChatGPT会話を参照
↓
再実装完全な自動同期ではありません。
それでも、
- ChatGPTの仕様をCodexへ貼る
- Webアプリの状態を文章で説明する
- TerminalログをChatGPTへ貼る
- Codexの長い回答をChatGPTへ貼る
といった作業はかなり減らせそうです。
そして重要なのは、何でもCodexへ渡すのではなく、その作業に必要なコンテキストだけを選んで渡すことです。
「ChatGPTの会話」「タブ」「ファイルとチャット」は、単なる便利な添付機能ではなく、人間がAI同士の間で行っていた情報伝達そのものを変える機能だと感じています。
他の記事中にも記載したが、ChatGPTチャットとCodexとの間の情報伝達を何度も何度もやらされた。しかも、ChatGPTチャットが、重要な機能が実現可能かを小さく試すという方針（PoC（Proof of Concept、概念実証）で実装することを提案したので、余計に工程が細かくなり、工程数が増大した。Codexに、「あまりに細かく作業を分けすぎる」と文句を言ったところ、ある程度作業をまとめて指示しますとの回答があった。本記事の仕組みがあるなら、早めに教えてくれたらよかったのにと思う。
これまで、OpenAIからバラバラに発表されていた新機能を組み合わせて使う活用方法がようやく現実的なものになったように思われた。