Codex Highの使い方｜複雑な不具合調査と推論設定の判断

CodexのHighは何を変える設定か

Highは、Codexに求める推論の深さを表します。OpenAI公式のモデル資料では、HighとExtra Highを、複数の段階や参照情報、判断の兼ね合いを含む難しい作業に向く設定として説明しています。不具合調査なら、一つの関数だけでは説明できない挙動を、入力、保存処理、表示処理などの関係から調べる場面が一例です。

ただし、Highを選ぶことと、正しい答えが出ることは別です。対象外のファイルを見落としたり、古い仕様を前提にしたりすれば、丁寧に分析しても結論を誤る可能性があります。判断材料をそろえる作業は、推論設定を上げるだけでは代替できません。読み取れる事実と推測を分けてもらうことが、結果を確認する入口になります。

モデル名も別に確かめます。GPT-6.1 Solなどのモデルと、Highという推論設定は、それぞれ異なる選択です。公式資料はモデル世代間で推論の段階が厳密に対応するわけではないと説明しています。以前のモデルでHighが適していたとしても、新しいモデルで同じ設定を固定する根拠にはなりません。慣れた小さな課題で、必要な深さを確かめ直すとよいでしょう。

いま確認したいモデル提供の変更

2026年10月15日時点では、GPT-5.5を指定したままになっていないかの確認が必要です。OpenAI公式変更履歴の10月14日付の案内によると、ChatGPTでサインインして使うCodexでは、GPT-5.5の提供が終了しました。終了時刻の表記は10月14日19:00 UTCです。OpenAI APIと、APIキーで認証するCodexのセッションは、この変更の対象外とされています。

移行では、利用中のプランと画面に表示される選択肢を優先します。公式モデル資料は、対象プランで利用可能な場合の移行先を案内していますが、名前を指定するだけで利用権が付くわけではありません。組織の設定や利用する画面によっても選択肢が異なります。Highを調整する前に、実際に使っているモデルが意図したものかを確認してください。

この変更を不具合調査に結びつけると、比較条件の扱いが大切になります。以前の結果と今回の結果でモデルも推論設定も変わっていれば、違いがHighによるものか切り分けられません。記録にはモデル名と推論設定を併記し、旧モデルの印象だけで新モデルの設定を決めないようにします。以下の使い方は、特定モデルの性能を測定した報告ではなく、調査を組み立てる実務上の提案です。

Highを選ぶ理由を不具合の性質から考える

Highを試す理由になるのは、調査対象が大きいことだけではありません。再現条件が複数あり、一つの説明だけでは観察結果を説明しきれないときや、修正がほかの処理へ与える影響を比べる必要があるときに、深い検討を求める意味があります。反対に、単純な書き間違いのように原因と直し方が明確な場合は、設定を上げる前に小さく直して検証できます。

次の表は設定選びの例です。公式の性能保証や、必ずこの設定にすべきという分類ではありません。チームのコードや検証方法に合わせ、判断の出発点として使ってください。

情報が足りないために答えが出ない状態も区別します。失敗した入力値が分からない、期待する仕様が決まっていない、対象のコードを参照できないという問題は、Highにしても残ります。まず不足している材料を確認し、それがそろった後も判断が難しいなら推論を深める、という順で考えると、長く待つだけの調査を減らせます。

不具合調査でHighを使う手順

ここでは「保存できたように見えるのに、画面を開き直すと変更前の値に戻る」という仮の不具合を例にします。実際の原因を断定する例ではありません。保存処理、読み込み処理、画面表示のどこに問題があるか分からない段階で、調査と変更を段階的に進めるための依頼方法です。各段階で得られた根拠を確認し、材料が不足していれば前の段階へ戻ります。

調査中に得た説明は、確認済みの記録と照合できる形で残します。担当者が途中で交代しても、何を調べ、どこから先が未確認なのかを追える状態にしておくと便利です。

Step 1: 再現条件と成功条件をそろえる

不具合が起きた操作、入力値、期待する結果、実際の結果を一つの依頼にまとめます。「保存がおかしい」だけでは、どの処理を追うべきか定まりません。例では、保存直後の表示と、開き直した後の表示を分けて記載します。毎回起きるのか、特定の条件で起きるのか、分かっている範囲も示してください。成功条件は、保存後に開き直しても正しい値が表示され、ほかの入力項目を壊さないこと、と具体化できます。

Step 2: モデルとHighの選択を確認する

利用している画面でモデルと推論設定を確認し、Highが選べる場合に指定します。CLIの対話セッションでは、公式モデル資料が案内する /model からモデルや推論の深さを調整できます。画面ごとの選択肢を確認し、見つからない項目を無理に指定しないでください。比較用の記録には、モデル名、High、利用する画面、確認した日を残します。モデルを切り替えた直後なら、古いモデル名が残っていないかも見直します。

Step 3: 変更前に原因候補と根拠を求める

最初は調査を依頼し、原因候補ごとに根拠と未確認の点を挙げてもらいます。例なら、保存されていない、別の値を読み込んでいる、古い表示が残っている、といった候補を、実際のコードや確認結果で絞る形です。候補を数多く並べることを目的にせず、どの確認で候補を否定できるかまで求めます。「この行が怪しい」という説明だけで変更へ進まず、その候補が再現条件を説明できるかを確かめます。

Step 4: 範囲を限定して修正と検証を依頼する

根拠がそろった候補について、直す範囲と維持すべき動作を指定します。例なら、対象項目の保存と再表示を直し、無関係な画面の書式変更は含めない、と伝えます。検証は修正前の症状を再現する確認と、修正後に期待どおりになる確認を対応させます。検証を実施できなかった場合は、その理由と残った確認を明記してもらいます。完了という返答だけで判断せず、差分と確認結果が成功条件に合っているかを読みます。

依頼文は推論の深さより先に調整する

Highへ変えても同じ誤解が続く場合は、依頼の前提を見直します。「原因を調べて直して」という短い依頼では、症状を消すことと、原因を説明することのどちらを優先するかが曖昧です。直した後に何を確認すれば十分かも分かりません。目的、対象、観察結果、維持する動作が読み取れる文章にすると、出てきた提案の良しあしを判断しやすくなります。

たとえば依頼文は、次のように組み立てられます。

設定画面で表示名を変更すると、保存直後は新しい名前になりますが、画面を開き直すと元へ戻ります。期待する動作は、開き直した後も保存した表示名が残ることです。まず関連する保存処理と読み込み処理を調べ、原因候補、根拠、未確認の点を説明してください。変更前に調査結果を示し、修正ではほかの設定項目の動作を維持してください。

この例は、Highが必要だと断言する依頼ではありません。明確な情報を渡したうえで、調査の難しさに応じて設定を選ぶための形です。再現できないなら、その事実を報告し、次に必要な情報を尋ねてもらいます。推測を事実として扱わないことは、深い推論を使う場合にも変わりません。詳しい説明が出てきたこと自体を、原因が確定した証拠にしないでください。

Highの効果は修正結果と確認時間で評価する

公式モデル資料は、推論を深くすると複雑な課題の結果が改善する可能性がある一方、時間とトークンをより多く使うと説明しています。そのため、Highの価値を返信の長さで評価するのは適切ではありません。原因の説明が観察結果と一致するか、必要な修正に収まっているか、人が確認して採用できるかを見ます。

比較するなら、同じ開始状態から同じ依頼を渡します。片方の調査で得た答えをもう片方だけに渡すと、推論設定以外の条件が変わります。モデルと速度もそろえ、違いを推論設定に限定してください。一度の結果には揺れがあるため、少数の例で製品全体の性能を断定せず、自分たちが繰り返す仕事に役立つかを判断します。

Highの返答を待つ時間が長くても、修正のやり直しが減れば役立つ場合があります。一方、同じ品質の結果が軽い設定で得られるなら、毎回Highへ上げる必要はありません。原因候補の比較が難しい局面だけHighを使い、修正内容が明確になった後は設定を見直す、という使い分けも考えられます。固定の正解を探すより、採用できた結果と確認にかかった時間を残すほうが、次の調査に生かせます。

Highでも調査が進まないときの見直し方

調査が長引いたときは、同じ依頼を繰り返す前に、何が止まっているかを確認します。候補を絞れないのか、必要なファイルを読めないのか、検証に必要な条件を用意できないのかで、次の対応は異なります。Highからさらに深い設定へ変えることは選択肢の一つですが、材料不足や確認不能な状態を解消する手段にはなりません。

見直しは、次の順で進めると状況を整理しやすくなります。

1. 現時点で確認できた事実と、推測のまま残る説明を分ける。
2. 未確認の原因候補を絞るために、必要な入力値や観察結果を特定する。
3. 一度に調べる対象を小さくし、その範囲で成功条件を置き直す。
4. 追加の材料を渡しても分析が不足する場合に、推論設定やモデルを再検討する。

保存の例であれば、まず保存先に正しい値が残っているかが分かるだけでも、次に読む処理を絞れます。大きな推測を重ねるより、一つの観察で候補を減らせることがあります。人が判断しなければならない仕様の問題が見つかった場合も、Codexに決めさせたまま進めず、期待する動作を確定してから依頼を更新します。

Highを使う目的は、難しい判断を含む不具合調査で、根拠のある修正に近づくことです。モデル提供の変更を確認し、再現条件と成功条件をそろえ、原因候補の根拠から差分と検証へ進めてください。設定名だけで成果を判断せず、実際の結果を確認することが、次の調査で適切な深さを選ぶ基準になります。