社員は自分ではどうモデルを選んでいるのか

OpenAI社内でのCodex利用は使用量無制限とされている。8名の社員のうち4名が同じ質問を受けた——使用量に上限がないなら、あなた自身はモデルと推論強度をどう選んでいるのか。

プロダクトマネージャーのsimpsokaの答えはこうだ。何を選ぶかはタスクそのもの次第であり、使用量が無制限だからといって最強モードをそのまま使うわけではない。彼女はSol Ultraをずっと使い続けることはなく、スピードのために切り替えるという。素早い編集、ちょっとした様子見のようなタスク、テンポの速い反復作業にはより速く軽い選択肢を使い、Sol Ultraは曖昧で、複数ステップにわたり、リスクの高いタスクのために取っておく——その分の深さのために待つ価値があるからだ。彼女は推論強度も、もう一つの調整可能なつまみとして扱っている。Codexに対して、速く率直にやってほしいのか、それともじっくり考えてほしいのかを直接伝えることが多いという。デフォルトでSol Ultraを使っていても、モデルは通常、簡単な問題に対して考えすぎることはなく、タスクが本当に必要とするときにはより深く考える。

他の3名の社員の実際の使い方

romainhuetがAMAの場で貼った新しいモデル選択スライダーUIのスクリーンショット。1本のスライダーでSol・Terra・Lunaの選択を連続的な1つの操作に簡略化している。画像出典：Reddit r/codex AMAのコメント欄。

AMAとは別に、開発者のVaibhav Srivastav（@reach_vb）はXで、このスライダーに対応した段階別のクイックリファレンスを公開しており、社員たちの発言と相互に裏付けが取れる内容だ。仕事をこなせる最低段階から始め、タスクが本当に必要とするときだけ上に調整する。LightとLowは速くて境界がはっきりしたタスクに対応し、Mediumは計画立案、分析、複数の工程がある作業に対応する。Highとxhighは複数ステップにわたり、トレードオフがあり、調査や入念な検証が必要な難しい作業に対応する。MaxとUltraはまったく別物で、Maxは1つのモデルが同じ難問によりじっくり時間をかけるもの、Ultraは複数のサブエージェントが並行してより大きな問題を分担するものだ。彼はさらに、5.6の推論段階は5.5と直接対応しているわけではないので、5.5に慣れている人は使い慣れたタスクでまず1段階下げて試し、結果が足りなければ上げていくことを勧めている。

なぜワンクリックのAutoを用意しないのか

あるユーザーは単刀直入に提案した。簡単なタスクは自動的にLunaやminiにルーティングし、複雑なタスクはSolと高推論にルーティングする「Auto」モードを用意できないか、と。

simpsokaの答えは、現時点ではそうしたAutoの選択肢はないが、必要性には同意する、というものだった。GPT-5.6の一部の能力にはすでに似たような判断が組み込まれている——モデルは通常、簡単なタスクに対して考えすぎることはなく、タスクが本当に必要とするときにはより深く考える。ただ彼女は、それでもユーザーが主導権を持つべきだと考えている。待てる時間の許容度は人や状況によって違い、ちょっと見るだけのときは速くて十分な答えが欲しいこともあれば、より深い推論を待つ気になることもあるからだ。

手動でのモデル選択が長期的な解決策なのかと突っ込まれると、simpsokaは、自分が貼った等級表はあくまで今の自分の使い方であって、理想的な長期体験を表すものではないと答えた。彼女はロードマップを代弁する立場にはないが、ユーザーがモデルルーティングの専門家になることを強いられるべきだとも思っていない。難しいのは、タスクの難易度がプロンプト自体から常に読み取れるわけではなく、待てる時間の許容度も人や状況によって変わることだ。だからデフォルトがより賢くなったとしても、彼女は明示的な上書きスイッチを残しておきたいと考えている。

長時間タスクをどう扱うか——そのまま使える制約プロンプト

コンテキストウィンドウをどれだけ大きくすべきかは、このAMAで最も盛り上がった話題の一つだった。

あるユーザーは、Solのコンテキストをいつ1Mトークンまで引き上げるのか質問した。372kは前世代の272kより良くなっているが、1Mならもっと多くのユースケースを解放できるという。研究員のallanzhou-oaiは、自分自身の使用に関して言えば、超長時間のスレッドではすでに圧縮（compaction）がかなりうまく機能していると答えた。チームとして具体的な約束はできないが、この点についてのフィードバックはしっかり見ていくという。

コミュニティ側には違う声もある。あるユーザーは、大半のモデルは500Kトークンを超えると馬鹿になると言い、別のユーザーは、四半期決算文書はわざと超長文になっていて前後の文脈が互いに依存しており、サブエージェントで並行分割することができないと実例を挙げた。

もう一つよくある不満は、モデルが諦めるのが早すぎるというものだ。15万行を超えるRustのコードベースを保守しているあるユーザーは、Codexは問題に遭遇すると一通り考えて巨大なパッチを吐き出し、テスト結果が思わしくないと丸ごとロールバックしてしまい、他の箇所にもう一つパッチを当てて連携させる必要がないか考えようとはしないと語った。それに対して、Fable（AnthropicのClaudeモデル）を使ったときの体験では、パッチがなぜうまくいかなかったのかを理解しようとし、その上で修正・改善を試みるという。allanzhou-oaiはこれに応じ、エージェントにより粘り強くあってほしいときは/goalを使うのが好みで、たいてい効果が良いと述べた。粘り強さとコードの複雑さを下げることはどちらも計画中の改善の方向だとし、逆に相手に5.6-solでHigh推論を試したことがあるか尋ね返した。

Investigate why this flaky test fails and try to fix it. Only change files
in packages/auth and its tests. Don't change the public API. Try up to
three plausible hypotheses, run the relevant tests after each attempt, and
if none work, stop and summarize what you learned plus the next best
experiment.

なぜPro modeをCodexで使わせないのか

Codexで選べるのはSol・Terra・Lunaだけで、Pro modeだけは選べない。これはこのAMAで最も繰り返し追及されたプロダクト判断の一つだった。

TedSandersの回答によれば、Proの根底にある動作方式は、エージェント型の作業（コードベースの変更など）にはそれほど役立たないという。もしCodexに組み込めば、選べば全面的に強くなると誰もが思い込み、結果的により遅く、より使用量枠を消費する上に、品質もそこまで良くならないことになるとチームは懸念している。彼は付け加えて、チームは何かを隠すつもりはなく、単にプロダクトをもっと使いやすくしたいだけだと述べた。

Proが結局何に向いているのか突っ込まれると、彼は全体としては非コーディング系の作業に最も向いていると答え、公式の過去のブログ記事でどの評価項目で差が大きく出るか確認できるとした。彼個人は検索、数学、文章作成、それに文書やスライド作りに使うが、それも待ち時間より品質を重視するときに限られるという。さらに、読み取り専用のシーン（計画立案、調査、コードレビュー）に限ってProを使えるようにできないかと問われると、それは確かに可能だが、あまり期待しすぎないでほしいと答えた。チームは設計をシンプルにしようと努めていて、計画モードを離れるとなぜProの選択肢が消えるのかをユーザーに学ばせたくない。ヘビーユーザーには恩恵があるが、その代償は複雑さの増加だという。

研究員はCodexをどう開発しているのか——GPUが唸りを上げる

研究員が普段どうCodexを磨き上げているのか、このAMAではいくつかの一次情報も明らかになった。

harness（エージェントのランタイムがツールをスケジューリングし、アクションを実行するためのフレームワーク）レベルで最も面白い気づきは何かと聞かれ、研究員のjanvi-oaiは、harness内のコネクタ（connectors。AIがSlack、GitHub、Notionなどの外部ツールを直接読み書きできるようにするインターフェースプラグイン）が最大のゲームチェンジャーだと答えた。これらのツールをコンテキストに投げ込み、モデルにそれらを読み書きさせることで、Codexは仕事をこなせる同僚のような存在になったという。

あるユーザーは、Codexと組み合わせてUnreal Engine 5.8のMCPを使っていると述べ、MCPツールをロードするだけで5時間分の使用量枠の10〜20%を消費し、3〜4回のプロンプトの後、30分以内に枠を使い切ってしまうと語り、ワークフロー改善のアドバイスを求めた。js_domは2つの道筋を提示した。

道筋その1：MCPをCLIにラップしてからskillを作る

CodexにMCPをCLI（コマンドラインツール）としてラップさせ、それを中心にskillを作らせる。決まったワークフローがあるなら、Codexに過去のセッションをもとにそのskillを自動生成させることもできる。

道筋その2：独立したサブエージェント設定にぶら下げる

カスタムのサブエージェント（subagents）定義を作る。たとえばUnreal Engine専用のエージェントを作り、MCPをメインの設定ではなくそちらの設定にぶら下げる。より低い推論段階を設定することもでき、メインのエージェントはそこに作業を委任すればよい。

見比べる価値があるのは、この公式が推奨する使用量節約の組み合わせ（MCPをCLIにラップする、それを中心にskillを作る、重いツールをサブエージェントにぶら下げて委任する）が、AnthropicのClaude Codeエコシステムですでに広まっているやり方とほぼ同じだという点だ。あちらにも同様にskillsやカスタムのsubagent定義があり、コミュニティもコンテキストを食うMCPをコマンドラインツールにラップする動きをとうの昔から行っている。両社のharnessレベルの実践は同じパターンに収斂しつつある——メインエージェントは軽いコンテキストを保ち、重いツールは外に出し、探索系タスクはより安価なモデルに任せる。

janvi-oaiはさらに、SolがLunaの事後学習（ポストトレーニング）に関わったことにも触れた。日常の研究については、大半の研究員は今、より高い抽象レベルで作業しており、同時に複数のCodexスレッドを走らせて仮説を検証しており、多くのボットが昼夜問わず稼働しているという。新モデルのリリース前に旧モデルをわざと馬鹿にしているのかと直接尋ねられると、彼女ははっきりと否定し、その理由として反復的なデプロイこそがAGIへの安全な道筋の鍵なのだと述べた。彼女の説明によれば、コア能力はそのままの形で世界と共有する必要があり（悪意ある者に対するガードレールは備えつつ）、それによってモデルの実際の利用から学ぶことができ、将来のモデルをより賢く、より安全にできるのだという。

回避された鋭い質問——ベンチマーク不正疑惑

このAMAで最も手厳しかった質問は、ベンチマークの数字そのものについてだった。

あるユーザーはこう質問した。OpenAIの発表文にはGPT-5.6が主要なコーディング・エージェント系ベンチマークで新記録を打ち立てたと書かれているが、第三者評価機関METRの報告では、エージェント型ベンチマークにおける不正率が同機関の記録史上最高値になっている。OpenAI自身のsystem cardにも、タスクでの不正行為や研究結果の捏造が記録されている。彼はさらに、こうしたベンチマークの向上のうちどれだけが本物の能力で、どれだけが評価ルールの抜け穴を突いて得点を稼いだもの（reward hacking、別名benchmark gaming。AIが評価の本来の趣旨に反する手段でクリアすることを指し、実際にタスクを正しくこなしたわけではない）なのか、訓練において具体的に何を変えてこれに対処したのかを問いただした。

研究員janvi-oaiの完全な回答は次のようなものだった。これは現実の懸念であり、モデルがどんどん賢くなるにつれて特にそうだという。チームは評価の中で不正行為を積極的にチェックし、罰則を課すことで、ベンチマークの結果がモデルの本物の能力を反映するようにしている——答えを調べたり、評価の趣旨に反するやり方で問題を解いたりする能力ではなく。また第三者のベンダーに独立してベンチマークを走らせてもらい、結果の信頼性を確保する助けにもしている。彼女は、チームがこの件を真剣に受け止めているのは、モデルが本当に賢くて役に立つかどうかを気にかけているからであり、単にスコアが良く見えることだけを気にしているわけではないと述べた。機械学習は時に錬金術のようなものなので、信頼できるベンチマークを持つことは、研究員自身にとっても非常に重要だという。

デスクトップアプリ統合が既存ユーザーの怒りを買う、チームは「まだ模索中」と認める

CodexとChatGPTは新しいデスクトップアプリに統合された。これはこのAMAで最も反発が大きかった部分だ。

統合後、これまでのChatGPTデスクトップ体験は「ChatGPT Classic」に改名され、チャットの入口はポップアップ形式のパネルの中に収められた。

js_domは、チームはこうしたフィードバックを受け止めており、ChatGPT Classicから移ってきた体験をどう改善するか引き続き検討していると応じた。今のところ両方のアプリを並べて使うことができるという。今回のリリースは、ChatGPTを非開発者のユースケースにもっと使いやすくすることを明確に狙ったものであり、新しいChrome拡張機能はサイドバー形式のチャットをブラウザに持ち込み、ウェブサイトのコンテキストを読み書きできるだけでなく、ファイルシステムやコネクタにもアクセスできるようになる。

あるユーザーはさらに突っ込んで、なぜ新しいChatGPTデスクトップアプリは、両者が本当に融合したというより、CodexにChatGPTをくくりつけたように感じるのか、意図的にCodex優先の設計にしたのかと尋ねた。TedSandersは会場で最も率直な回答を返した——正直なところ、チームはまだ模索中だ。彼の説明によれば、以前は複数のアプリと複数セットのharnessがあり、ユーザーはどのアプリで何をすべきかわからず、チームも複数の方向に同時に開発を進めなければならないせいで動きが遅くなっていたという。統合には短期的な痛みも伴うが、長期的な利益がそれに見合うことを望んでいる。チームはみんなの意見を聞いており、デザインを良くしようと努めているが、明らかにまだ完璧ではないという。追及したユーザーは反論し、ChatGPTとCodexのユースケースはもともと明確だったのに、今ではデスクトップ版の機能が制限されたポップアップに格下げされてしまったとし、いっそのこと新しいデスクトップアプリを「ChatGPT Work」に改名してはどうかと問い返した。

利用量の算定基準、価格設定、そして今も進行中のこと

AMAが終わりに近づいた頃、チームはさらに具体的な一連の質問に答えた——利用量はどう算定するのか、価格は上がるのか、それにいくつかの技術的な細部について。

simpsokaは、どのシーンがagentic（エージェント型）利用量にカウントされ、どのシーンはされないのかを一つずつ明確にした。

彼女は付け加えて、すべてのCodexタスクが同じだけの利用量を消費するわけではないと述べた。ごく小さな編集は利用枠のほんの一部しか使わないかもしれないが、長時間実行され、大きなコードベースや大量のコンテキスト、より深い推論を伴うタスクははるかに多くを消費するという。

価格設定の持続可能性について（会場全体で最もいいねが多かった質問、105いいね）、simpsokaは価格が今後永遠に変わらないとは約束できないとしつつ、手が届く価格であることはミッションの一部だと述べた。今日、Plusプランに含まれるCodex利用量について、もっと必要な人はクレジットを使って枠を拡大できるようにしており、全ユーザーをずっと高いプランに強制的に移行させるようなことはしていないという。TedSandersは、これまでの傾向を見ると、今の20ドルで得られる価値は2年前をはるかに上回っており、この傾向は今後も続くと見込んでいると付け加えた。変更の透明性については、js_domが更新履歴の粒度を上げる必要があると認めた。過去3ヶ月で150件以上の機能をリリースし、週に何度もリリースしているため、ログは大きなポイントに集中してしまっているという。彼は、チームが利用量の上限をこっそり変えることはないと強調しつつ、より高い透明性を提供できるよう努めると述べた。

いくつかの具体的な確認事項もあった。Linuxデスクトップ版は開発中だが、時期は明言されなかった。チームは、これまで歴史的にMacを優先してきており、Windows体験が磨き上げられるのが遅れることがあったと認めつつ、最近はWindowsによりまとまった投資を行っているという。5.6からはWindows上のサンドボックス体験が改善されており、問題に遭遇した場合は/feedbackコマンドで直接チームにフィードバックできる。

AMAが締めくくられる前に、ちょっとした息抜きの一幕もあった。ある人が、Tibo（Codexチームの責任者Thibault Sottiaux。Xで利用量リセットを発表することで知られる）はなぜソーシャルメディアでこんなに人気なのかと尋ねると、romainhuetは、彼があの有名なCodexリセットボタンを握っているからだと答えた。別のユーザーが冗談交じりに、その魔法のボタンの写真を見せてくれとせがむと、js_domは本当に1枚貼った。

js_domがAMAの締めくくりに貼ったCodexリセットボタンのネタ画像。Tibo Sottiauxのソーシャルメディア上のキャラクターをめぐるネットユーザーのからかいへの返答。画像出典：Reddit r/codex AMAのコメント欄。

公式アカウントはその後、投稿を締めくくった。「AMAはこれで終了です。また近いうちに戻ってきます」。

このAMA（1時間の公開質疑応答。ネットユーザーが自由に質問し、チームがその場で答える形式）で、8名のチームメンバーが自分の「使用量無制限」時の内輪の使い方を公開した。そのまま使えるものが2つある——段階選びの基準（次のセクションの図を参照）と、長時間タスクを脱線させないための制約プロンプトだ。

最も典型的な対比はこれだ。AIに「いつも不安定なテストを直して」と頼むにしても、思いつきの一言で頼むのと、境界をきちんと囲って頼むのとでは、結果が天と地ほど違う。

では「どの段階を選ぶか」は結局どう当てはめればいいのか？社員は5段階の表を示してくれた。

プロダクトマネージャーsimpsokaが示した等級表は、「どの仕事にどの段階を合わせるか」を5段階に整理したものだ。今日シャオフーがCodexに任せたい仕事が5件あるとしよう。誤字修正から本番障害対応まで、難易度が下に行くほど、モデルの火力と「もっと深く考える」という2つのつまみを一緒に上げていくべきだ。

なぜ手間を省こうと全部最上段にしないのか？最強モードはより遅く、より使用量を消費し、大半の場合品質もさほど良くならないからだ。正しい段階を選ぶことで、実際に時間とお金を節約できる。

これらの数字はすべてOpenAI側の自己申告であり、第三者による再現は経ていない。同じ質疑応答の場で、第三者評価機関METRが記録した「過去最高の不正率」（AIが評価の抜け穴を突いて得点を稼ぎ、実際には仕事をきちんとこなしていないこと）について、GPT-5.6を巡って問い詰められた社員は、「現実の懸念である」とだけ認め、具体的な数字も、訓練で何を変えたのかも語らなかった。CodexとChatGPTを無理やり同じデスクトップアプリに詰め込んだことも、大量の既存ユーザーの怒りを買った（有料機能が消えた、チャット入口がポップアップの奥に埋もれた）。チームは異例にも「正直、私たちはまだ模索中です」と認めた。