
【実録】ChatGPTのProをCodexで使う。モデル選択エラーと言語設定の落とし穴を突破した記録
「これ良いじゃん」
画面に映るリポジトリを見つけて、、
チャットで真っ先にそう打ち込みました。
目にとまったのは、GitHubで見つけたひとつのツール。
その名も、codex-chatgpt-web。
思わず背筋がゾクッとしました。
、、おいおいおいっ!!
ちょっと待てと。
Codexの使い慣れた作業場にいながら、
ブラウザのChatGPT Web側で契約しているモデルを、
そのままモデル選択画面から呼び出せる、、?
しかも作者の設計説明を読むと、
Webモデルとのやり取りはChatGPT側のアカウント枠を使い、
Codex側の利用枠を消費しないというのです。
「いつものエディタ画面に、ChatGPT側の頭脳を直接呼べる選択肢が増えるのか、、?」
知的好奇心の針が一気に跳ね上がりました。
日頃から長文の執筆、泥臭いリサーチ、
大量のファイル操作や資料作りに追われている実務家にとって、
作業場のモデル選択肢がひとつ増える意味は、
想像以上に大きいのです。
手元のエディタから1ミリも離れずに、別の強力なモデルへ思考を渡せる。
これは私にとって、まさに作業の常識を覆すほどの衝撃だったのだ。
「じゃあ入れて」
私はCodexにそう声をかけ、セットアップを進めることにしました。
もちろん、難しいコードを自力で解読したわけではありません(笑)。
頼れる相棒のCodexと一緒に、公式の案内や資料を確認しながら進めました。
しかし、、。
待ち受けていたのは、一筋縄ではいかない泥沼の落とし穴でした。
ツールの導入って、マニュアル通りにやっているつもりでも、
予期せぬ場所でピタッと止まり、
何が悪いのか分からなくなって頭を抱える瞬間がありますよね。
今回もまさに、その洗礼を真正面から浴びることになりました。
私がWindows環境で実際に試したのは、v6.1.3。
(※調査時に公式リポジトリを確認したところ、
最新版の案内はv6.1.4に更新されていました。
ツールの世界は刻一刻と変化するため、
これから触る方は最新の公式リリースページを確認してください)。
今回、私がCodexと一緒に踏み抜いた生々しいつまずきと、
そこから「できた」に至るまでの具体的な解決策を、
余すところなく書き残します。
無用な苛立ちで貴重な作業時間を溶かさないための、
道具の比較で消耗するのは、もう終わりにしませんか?
コピペを繰り返す毎日にサヨナラしましょう。
仕事ですぐ使えるコピペOKの実践教材を、今すぐ手元へ差し出します。迷わずガツガツ動かす側へ回るのである。
実践的な記録である。

いつもの作業場に「別の頭脳」を呼べる価値
本題の設定に入る前に、
なぜこの仕組みが現場の実務家にとって
魅力的な選択肢になり得るのか、
その構造を冷静に整理しておきましょう。
日々の業務でCodexを使い込んでいる人ほど、
ローカルのファイルを自在に読み書きさせ、
ターミナルを叩かせながら進める作業環境のありがたさを
骨の髄まで実感しているはずです。
しかし、作業の内容によっては、
「ChatGPTのWeb側で使い慣れているあのモデルの出力や、
あちらのアカウント枠を、この作業場のまま使えたら便利なのに、、」
と感じる場面も少なくありません。
普段ならどうするか?
ブラウザを立ち上げ、
ChatGPTのタブを開き、
手元のエディタからプロンプトをコピペして投げ、
返ってきた文章をまたエディタ側へ慎重にペタペタ貼り直す。。
、、この往復運動、ぶっちゃけ面倒くさすぎませんか?
画面を行ったり来たりしているうちに集中力は途切れ、
作業のリズムはガタガタに崩れてしまいます。
思考のスピードを落とさずに成果物を組み立てたい現場にとって、
ツール間の往復による摩擦は、
地味ながら確実に作業効率を削り取る元凶なのです。

作者の解説によれば、この「codex-chatgpt-web」は、
ブラウザと実行環境を同梱した独立ランチャーを起動し、
ログインしたChatGPTアカウントのセッションを介して、
Codexのモデル選択肢にWebモデルを追加してくれる仕組みです。

最大のポイントは、
Codexの作業場を維持したまま、ChatGPT側の利用枠を使える
という選択肢が手に入ること。
これによって作業場の分断を解消し、
手元の画面で作業を一括管理できる環境が手に入るのである。
まさに日々の執筆や調査の進め方を根本から変えうる、
斬新なアプローチだと感じたわけです。
ただし、ここで絶対に誤解してはならない
重要な前提があります。
このツールは、「誰でもProを無料で使える」とか、
「利用制限を何でも無制限に突破できる」といった
都合のいい裏技ではありません。
あくまで、自分がログインしたChatGPTアカウントの枠内で、
そのアカウントに提供されているモデルを呼び出す仕組みです。

過度な幻想を抱くのではなく、
「自分の作業場に、使えるモデルの選択肢をひとつ増やす」。
その現実的な価値を理解してこそ、
この道具は真価を発揮するのです。
「あれ?反映されない」「まだ?」——最初の壁とCodexの再起動
導入の大まかな道筋は、次の通りです。
公式のリリースページからインストーラーを入手
Windows環境へインストールしてランチャーを起動
ランチャー内の内蔵ブラウザで自分のChatGPTアカウントにログイン
ブラウザーテストで正常な応答を確認
Codexの設定へモデルを追加
Codex全体を完全に終了させ、再起動する
モデル名の末尾に「(Web)」と付いたモデルを選んで短く試す

手順そのものは、こうして並べると
至極シンプルに見えます。
ランチャーを立ち上げて内蔵ブラウザでChatGPTにログインし、
ブラウザーテストの応答も無事に確認できました。
「よし、これで繋がったはずだ」
そう確信して、Codexのモデル選択画面を開きました。
、、あれ?
ない。
いくら探しても、追加したはずのモデルが見当たらないのです。
「あれ?反映されない」
設定の反映を待ちながら、
Codexとのやり取りでも思わず焦りが出ました。
「まだ?」
設定ファイルには確かにモデルの情報が書き込まれているのに、
画面のドロップダウンには何の変化も起きない。
ローカルの常駐プロセスがおかしいのか、
それとも連携の設定を根本的に見落としているのか、、?
画面を前にして、モヤモヤとした苛立ちが膨らんでいきます。
手応えがあった直後だけに、
ピタッと足止めを食らうと精神的なダメージが大きい。
しかし、、原因はあまりにも身近な盲点でした。
Codex全体の完全な終了と再起動。
これが必要だったのです。
ウィンドウを閉じるだけではなく、
Codexのプロセス全体を一度完全に終了させてから立ち上げ直します。
すると、、。
カチッ。
モデル選択のリストの中に、
モデル名の末尾に誇らしげに「(Web)」と添えられた項目が、
しっかりと表示されたではありませんか。
今回の連携でモデルを追加した際は、
あれこれ悩む前にまずCodex全体を完全に再起動する必要があります。
知っていれば単純ですが、最初につまずきやすい落とし穴である。

「MCPって接続する必要あるの?」——会話とファイル操作の境界線
モデルが表示された安堵も束の間、
次なる疑問が湧き上がってきました。
「MCPって接続する必要あるの?」
設定のドキュメントを読み進めると、
「Full harness」だの「MCP」だの「トンネル」だのという
難解な専門用語が目に飛び込んできます。
「トンネルの名前と説明、オーガ内ゼーション、ワークスペースはどう設定する?」
画面に並ぶ設定項目を見ながら、
実務で使いたいだけの身としては、
「なぜそこまで大がかりな設定が必要なのか?」と
立ち止まってしまったのです。
ここ、非常に重要な分岐点です。
自分がこのツールに何を求めているのかによって、
選ぶべき動作モードがまったく異なります。
このツールには、大きく分けて2つの形態が存在します。
ひとつは、「Browser-only(会話のみ)」。
もうひとつは、「Full harness(完全連携)」。

この2つの違いを正しく理解していないと、
不要な設定に振り回されたり、
逆に「思った通りの作業ができない!」と混乱することになります。
まず「Browser-only」は、非常に身軽な構成です。
MCPの接続もトンネルの設定も一切不要。
Codexの画面からChatGPT Webに向けてプロンプトを投げ、
その返答をテキストとして受け取るだけなら、
これだけで十分に機能します。
文章の壁打ちやリサーチの要約など、
会話だけで完結するタスクなら、MCPを繋ぐ必要は全くありません。

ですが、、!
Codexの最大の強みである
「手元のファイルを直接読み込ませて編集させる」
「ローカルのターミナルでコマンドを実行させる」といった、
ファイル操作や作業ツールの実行をWebモデルに任せたい場合は、
Browser-onlyでは手も足も出ません。
ツールを使えない状態だからです。
そこで登場するのが、「Full harness」。
Full harnessでは、MCP(Model Context Protocol)と
OpenAIのトンネルクライアントを経由して、
現在のCodexタスクが扱っているファイルやターミナルなどのツールへ、
Codex側の権限や承認ルールの範囲内で接続します。
つまり、Web側の頭脳に、
手元のタスクをこなすための道具を正しく渡す仕組みなのです。

なお、このFull設定を成立させるには、
トンネルの設定に加えて通常のAPIキーや
ChatGPT側のコネクタ設定が必要になります。
「APIキーが完全に不要になる」わけではない点も、
正しく押さえておくべき事実です。

会話の相談相手として使いたいだけなら、Browser-onlyで十分です。
ローカルのファイルを読み書きさせ、実務タスクを任せたいなら、Full harnessを組みます。
この境界線が腹に落ちてから、
Codexの支援を借りつつ、Tunnelの名前や説明、
Organization、Workspaceの設定をひとつずつ完了させました。
手元のhealthチェックを実行すると、
version: 6.1.3 / mode: full / status: ok
という手応えのある診断結果が返ってきました。
「できた」
「全部完了した」
これで準備万端、すべてが整った、、。
そう胸を撫で下ろしたのも束の間、
最大の修羅場がその直後に待ち構えていたのです。
突如立ちはだかる絶望のエラー——モデルの選択に失敗する
ブラウザーテストの応答も確認し、
いざCodexの入力欄から本番のメッセージを送信しました。
しかし、、画面は沈黙したまま応答を返さず、
次のエラーログが突き刺さったのです。
stream disconnected before completion: ChatGPT model 6 could not be selected and verified. The pending message was not sent.
、、なんだこれはっ!!!
「完了前にストリームが切断されました。
ChatGPT model 6 を選択・検証できませんでした。
保留中のメッセージは送信されませんでした。」

さっきのヘルスチェックで「status: ok」と出ていたのに、
実際にメッセージを投げた瞬間に、
モデルの選択そのものに失敗して通信が途絶したというのです。
ブラウザーテストで簡単な疎通が通ったからといって、
本番のモデル選択やメッセージ送信がすべて検証できたとは限らない。
この事実を、痛烈なエラーメッセージによって突きつけられました。

「モデル選択の検証に失敗した、、?」
「アカウントの設定がおかしいのか?」
「それともツール側の内部で何か致命的な崩壊が起きているのか、、?」
目の前が真っ暗になるような感覚でした。
せっかくここまで手順を踏んできたのに、
肝心の送信部分で弾かれてしまう。
原因が分からないまま画面を見つめる時間は、
誰にとっても胃が痛むようなストレスです。
解決の突破口は「表示言語」——拍子抜けするほどの具体策
しかし、ここで放り出すわけにはいきません。
Codexと一緒に作者の公式トラブルシューティング資料を突き合わせ、
エラーの痕跡をひとつずつ洗い直していきました。
すると、、トラブルシューティングの中に、
まさにこの現象に直結する重要な記述が見つかったのです。
作者の資料によれば、ツールの画面操作処理の一部に
英語のUIラベルを前提としている箇所があり、
モデルの選択や検証がうまくいかない場合の対処法として、
明確に次の手順が案内されていました。
ランチャー内のChatGPTの表示言語を「English」に明示設定し、再読み込みして再試行する。
今回確認した内蔵ChatGPTは、自動検出で日本語表示になっていました。
そこで作者資料の案内に従い、表示言語をEnglishに固定する対処を試してみたのです。
まさにここが、暗闇を切り裂く具体的な突破口でした。
解決策は、驚くほど具体的でした。
起動しているランチャー内のChatGPT画面を開く
アカウントメニューから Settings(設定)を選択
General(一般)の中にある Language(言語)を開く
言語設定で 「English」 を明示的に選択する
ランチャー内のChatGPT画面を 再読み込み(Reload) する
再びCodexからメッセージを再送する

ここで強調しておきたいのは、
ランチャー本体の表示言語まで英語にする必要はない
ということです。
あくまで内蔵ブラウザ内の「ChatGPTサイト側の言語」をEnglishに固定するだけ。
そして何より、
私たちがCodexで入力する指示や質問文を、英語にする必要は一切ありません。
Englishに変えるのは内蔵ブラウザの表示設定だけであり、
こちらから送る質問や執筆の依頼文は、日本語のままで構いません。

Codexの支援を受けながらこの言語設定をEnglishに変更し、
画面を再読み込みした上で、
改めてメッセージの送信を試みました。
そして、、。
画面の応答を確認した私は、思わずCodexへこう返信していました。
「できた」
画面の向こうで保留されていたメッセージが無事に送信され、
Codexの作業場の中に、
求めていたChatGPT Web側の応答がしっかりと返ってきたのです。
あれだけ頭を抱えさせられた切断エラーが、
言語設定をひとつ切り替えただけで嘘のように解消した瞬間でした。

導入後に迷う「設定項目」の選び方
無事に動作を確認できた後、
次に直面するのが「どの設定をONにして運用すべきか?」という
実用上の判断です。
設定画面には魅力的な機能がいくつか並んでいますが、
手当たり次第にONにするのではなく、
目的とトレードオフを理解して選ぶ必要があります。
私が確認した範囲で、現場目線のおすすめ基準をまとめました。

1. 「ログイン時に起動」&「閉じてもサーバーを実行」
→ 常用するなら、迷わずON推奨
日常的にこのツールを活用するなら、ONにしておくのが自然です。
この連携は、裏側でランチャーのサーバーが立ち上がっていなければ
Codexから呼び出すことができません。
ウィンドウを閉じるたびにサーバーまで終了してしまうと、
作業のたびに起動し直す手間が生じます。
バックグラウンドで待機させておくのが、最もストレスのない運用法です。

2. 「Bigger Context(コンテキスト拡張)」
→ 長い履歴が必要になった時に試す(常用で無理にONにしない)
これは試験的な機能として提供されている設定です。
コンテキストの予算と、自動要約が入るまでのしきい値を通常の3倍に引き上げ、
送信サイズが大きい場合は最大6回に分割して送信する仕組みを持っています。
注意すべきなのは、これはモデル自体の知能が3倍になる機能でも、
どんな巨大ファイルでも無条件に送り込める保証でもないということ。

分割送信が発生すれば、そのぶん追加の送信回数を消費しますし、
応答までの待ち時間も増加します。
通常時はOFFにしておき、長大なやり取りでどうしても必要な場合に
試してみる、というスタンスが堅実です。
なお、設定を変更した後はCodexの再起動が必要です。

3. 「利用上限の追跡(Limits)」
→ ローカルの消費目安を知りたいなら活用
対応プランにおいて、ランチャー内で送信された利用量を
ローカルで推計してくれる機能です。
ただし、これはあくまで「このランチャーから送られた分」を
手元で記録している目安に過ぎません。
スマホや別ブラウザで送った分まで統合されるわけではなく、
OpenAI全体の厳密な残量やリセット時刻を完全に保証するものではない、
ということは頭に入れておく必要があります。

4. 「チャットの保存(Save chats in ChatGPT)」&「毎回新しいチャット」
→ 用途とプライバシーに応じて選択
デフォルトではOFFになっています。
ChatGPT側にもやり取りの履歴を残したい場合や、
アカウント側のメモリ機能やカスタム指示を適用させたい場合は
「Save chats in ChatGPT」をONにする選択肢があります
(※メモリやカスタム指示が適用される場合がある、という仕様です)。
また、「New browser chat for each turn」は、
会話を続ける中でツールの認識が失われてしまうような問題が起きた際の
対処候補として用意されています。
毎ターン履歴を送り直すため負荷が増える側面もあり、
通常は必要に応じて切り替えるのが適切です。

実務家として、このツールとどう向き合うか
最後に、ひとりの実務家として
冷静に押さえておくべき重要な注意点に触れておきます。
この「codex-chatgpt-web」は、
日々の作業環境を快適にし、
モデルの選択肢を広げてくれる非常に刺激的な道具です。
しかし、これはOpenAIが公式に提供しているAPI連携ではなく、
ChatGPTのWeb画面を自動操作する非公式ツールです。
将来的にChatGPT側のWeb画面のデザインや仕様に変更が入れば、
これまで動いていた操作が突然動かなくなるリスクを常に抱えています。
「BANのリスクが完全にゼロ」とか「未来永劫安全」などと
無責任に保証できるものではありません。

利用にあたっては、自分自身のアカウントの利用規約や、
所属する組織のセキュリティポリシーをしっかり確認し、
自己責任の範囲内で節度を持って活用することが大前提となります。
設定の途中で何が悪いか分からなくなっても、自分を責める必要はありません。
Codexの完全再起動、MCPの用途の見極め、そして内蔵ChatGPTのEnglish設定。
この3つの急所さえ押さえれば、得体の知れないブラックボックスに怯えることなく、確実に前へ進めるのだ。
Codexの作業場に、もうひとつの選択肢を加えてみたい方は、
まずは壊れても影響のない短いタスクから、
小さく試してみてはいかがでしょうか。

現場で戦うあなたの作業が、
少しでも軽やかになることを願っています。
参考リンク
今回の導入およびトラブルシューティングにあたって参照した公式リポジトリと資料です。導入時は最新の情報を直接確認することをおすすめします。

コピペ係から抜け出し、実務直結の実践教材を無料で手に入れる。
AIの使い分けから、業務で使える画像づくり、手持ちのnoteを丸ごと動画化する手順まで、コピペOKの指示文や構成テンプレートを実践教材としてまとめました。
知識を集めるだけで終わらせず、自分の手でサクサク形にする側へ回るのである。
受け取りは簡単。下の案内ページからLINEオープンチャット「東京AIラボ」に無料参加し、中の「ノート」を開くだけで無料プレゼントを受け取れます。
codex-chatgpt-web 最新リリースページ(GitHub)
ツールの最新インストーラーの配布場所。私が試したv6.1.3以降の更新もこちらから確認できます。作者による日本語版公式ドキュメント(README.ja.md)
ツールの全体像、Browser-onlyとFull harnessの役割の違い、セキュリティ上の注意点がまとめられています。公式トラブルシューティングガイド(TROUBLESHOOTING.md)
今回のモデル選択エラーや、ランチャー終了時の挙動など、具体的な問題解決策が記載されています。アーキテクチャ解説ドキュメント(architecture.md)
Bigger Contextの分割送信の仕様や、ローカルでのLimits追跡の仕組みなど、内部動作を深く知るための資料です。