Codexチャットの使い方と入力候補の条件・送信前の確認方法

Codexチャットの入力候補は何を提案するのか

Composer predictionsは、回答のあとにユーザーが続けて送りそうなメッセージを提案します。コードの行をエディタ内で補完する機能とは、入力する場所と対象が異なります。補う対象はチャットへ送る依頼文です。例えば修正結果を受け取ったあとに、結果を確認するための次の質問を考える場面で役立ちます。ただし、ここで挙げる使い方は編集上の例であり、特定の候補が必ず表示されるという意味ではありません。

OpenAIの公式変更履歴には、2026年10月9日の項目としてこの機能が掲載されています。11月4日に確認したComposer Predictionsの公式説明でも、現在の会話を基に、応答後の入力欄へ次のメッセージ案を出す仕組みが示されています。最近の機能を試す際は、発表時点の紹介だけで判断せず、現在の説明で対象モデルや条件を確認すると取り違えを減らせます。

実務では「次の文章を考える負担が少し減る」と捉えると扱いやすくなります。候補が出ることは、依頼した修正が正しい証拠にはなりません。直前の回答に確認していない点が残っていれば、その点を質問する文章へ書き換えて構いません。入力欄に出た案を、自分の作業判断を支える下書きとして利用します。

利用条件はプラン・会話の場所・モデルを合わせて確認する

11月4日に確認した公式説明では、Composer predictionsは対応地域の18歳以上の個人向けChatGPT Proユーザーに提供されるベータ機能です。利用する場所はCodexデスクトップアプリ内のローカルまたはSSHの会話です。ChatGPT Proという契約名だけを見て、ブラウザ版やすべての入力欄でも同じ候補が出ると考えると、確認対象を間違えやすくなります。

対応モデルとして現在の説明に挙がっているのはGPT-6 Astra、GPT-6.1 Sol、GPT-6.1 Terraです。10月9日の告知ではAstraとSolが案内されており、現在の機能説明にはTerraも含まれています。記事や紹介画像と自分の画面が違う場合は、このように掲載時点と現在の対象条件を分けて読みます。ここから、別のモデルでも動くはずだと推測して設定を変える必要はありません。

確認は次の順番にすると、原因を絞りやすくなります。これは公式説明を基にした本記事の確認順です。

1. Codexデスクトップアプリを更新し、個人向けChatGPT Proのアカウントでサインインしているか確認します。
2. 現在の会話がローカルまたはSSHの対象となる会話か確認します。
3. 使用中のモデル名を確認し、公式説明の対応モデルと照合します。
4. 設定画面のGeneral、ComposerにあるShow predictionsが有効か確認します。

対象条件を満たしていても、公式説明だけでは個々の地域やアカウントにおける表示を保証できません。候補が見えないことだけを理由に有料プランを変更するより、まず現在の契約と画面の条件を整理してください。通常の文章入力はそのまま続けられるので、確認作業とコードの相談を分けて進められます。

Tabで候補を採用し、編集してから送信する手順

入力候補を使う基本操作は短いものですが、Tabを押した時点で何が起きるかを理解しておく必要があります。公式説明では、Tabで候補を採用すると、編集できる下書きとして入力欄に入ります。その操作だけではメッセージは送信されません。目的や対象ファイルが合っているかを読み直す時間を取れるため、候補の文面をそのまま仕事の指示にしてしまうことを防げます。

1. 対象の会話で、調べたい内容や修正したい内容をメッセージとして送ります。
2. Codexが回答したら、入力欄に次のメッセージ候補が出ているか確認します。
3. 使いたい候補ならTabを押し、入力欄に下書きとして取り込みます。
4. 作業対象、変更してよい範囲、確認したい結果を読み、必要に応じて編集します。
5. 自分の意図に合う内容になったことを確認してから送信します。

別の内容を伝えたい場合は、自分の文章を入力します。公式説明では候補を待たずに入力を続けられるため、提案が出るまで手を止める必要はありません。毎回候補を採用する習慣を作るより、次に何を確認するかがすでに決まっているときは、その目的を直接書くほうが短く済みます。

例えば画面の表示崩れを直したあとなら、「次も修正して」だけでは対象が広がります。「幅の狭い画面で、今回変更した見出しとボタンの重なりを確認してください。問題があれば該当箇所だけを直してください」と直すと、次の依頼が具体的になります。候補に存在しないファイル名や未確認の結果が含まれていれば、確かな情報に置き換えてから送ります。

現在の会話にある情報と、候補が参照しない情報

公式説明では、候補は現在の会話の内容を使います。過去の作業や接続済みアプリの情報がすでにその会話に含まれていれば、提案へ反映される場合があります。一方、候補を作るために記憶を新しく探したり、接続済みアプリから情報を取得したりすることはありません。入力欄の文章が具体的であっても、必要な情報を別の場所から調査し終えたことにはなりません。

この違いは、複数の案件を扱うときに効いてきます。同じ会話で対象のアプリや目的が途中から変わった場合、候補に前の案件の前提が残る可能性を考えて読みます。これは機能固有の不具合を断定する話ではなく、会話に基づく下書きを採用するときの確認点です。修正対象のファイル、期待する動作、今回触れない部分を明示すると、送信する指示を自分で確かめやすくなります。

記憶の機能を無効にしていても、Composer predictionsは利用できます。記憶が有効で、その情報が現在の会話にすでに入っている場合は、候補に影響することがあります。候補機能を使いたいからといって、記憶の設定を必ず有効にする必要はありません。候補表示の設定と、会話へどの情報が入っているかを別々に確認してください。

コードの修正依頼では、候補の自然さよりも前提の正確さを優先します。「テストが通ったので次へ進む」という下書きが出たとしても、実際の結果を確認できていなければ、その前提を採用しません。結果が未確認なら「今回の変更に関係するテスト結果を確認し、未実施なら理由を説明してください」と書けます。候補を読んだ人が責任を持って送信する点は、通常のチャット入力と同じです。

コードの修正依頼で送信前に確認したい三つの観点

候補の文章を読むときは、目的、変更範囲、完了条件をそれぞれ確かめると判断しやすくなります。この三つは本記事が提案する依頼文の点検方法です。公式が定める必須形式ではありません。短い依頼でも、何を解決したいか、どこまで作業してよいか、どの結果を報告してほしいかが伝わっていれば、次のやり取りで前提を補う手間を減らせます。

目的の点検では、候補が直前の問題を引き継いでいるかを見ます。ボタンの反応を直しているのに、見た目全体の変更へ話が移っていれば、元の目的へ戻します。変更範囲の点検では、対象画面やファイルを広げすぎていないかを見ます。改善案として魅力的でも、今の依頼で必要ない変更なら、別の相談に分けるほうが結果を確認しやすくなります。

完了条件の点検では、「よくなった」「直した」といった評価だけで終わらないよう、具体的な観察結果を求めます。例えば「空欄を送ったときにエラーが表示され、正常な入力では保存できることを確認して報告してください」とすれば、確認する動作が明確です。候補が短すぎる場合は、この条件を追記するだけでも依頼の質が変わります。

相談だけを続けたいときは、その意図も文章にします。「まず原因を説明してください。修正は説明を読んでから依頼します」と書けば、今ほしい返答が伝わります。候補が修正へ進む内容でも、採用後にこうした文を加えられます。入力の手間を減らす機能と、作業の進め方を決める判断を組み合わせることで、会話が意図しない方向へ広がるのを抑えられます。

候補が出ないときと、表示を止めたいときの確認方法

候補が見えない場合は、最初に利用条件を確認します。対象プラン、年齢と地域、デスクトップアプリ、会話の場所、モデル、表示設定という順番で分けると、単なる入力の問題と提供条件の違いを混同しにくくなります。候補が出ないという現象だけでは、サービス全体の障害とも、アカウントの異常とも判断できません。通常のメッセージが送れるかどうかも別の状態として記録します。

1. アプリが更新されているかと、サインインしているアカウントの契約を確認します。
2. 公式説明に載っている会話の場所とモデルの組み合わせかを確認します。
3. General、ComposerのShow predictionsを確認します。
4. 応答後の入力欄で表示を確かめ、出ない場合も必要な依頼は自分で入力します。

候補表示が気になる場合は、同じShow predictionsでオンとオフを切り替えられます。公式説明では利用対象者は既定で有効とされています。機能を使わない時間帯や、自分で文章を組み立てたい作業では無効にして構いません。作業が速くなるかどうかは人によって異なるため、候補を編集する時間と、最初から書く時間を実際の依頼で比べて判断します。

問い合わせのために状態を整理するなら、確認日、アプリの版、プラン、モデル名、会話の場所、表示設定、どの応答のあとに出なかったかを残します。候補を出すために同じ依頼を何度も送ると、送信した分の通常利用が増えます。原因が分からないときは条件の記録を先に整え、必要なメッセージだけを送るほうが確認しやすくなります。

候補生成と送信後の利用枠を分けて考える

料金や利用上限については、候補を作る処理と、メッセージを送ったあとの処理を分けます。公式説明の利用条件では、候補の生成はCodexの利用枠に数えず、クレジットも消費しないとされています。一方、採用した候補を含め、実際に送ったメッセージには通常の利用制限と課金条件が適用されます。候補を使えば以後の作業も無料になる、という意味ではありません。

この違いを踏まえると、候補を読んで編集すること自体をためらう必要はありませんが、次の作業が必要かどうかは送信前に判断するのが自然です。すでに目的を満たしていれば、提案された追加作業を依頼しなくても構いません。直前の結果に不足があれば、その不足へ絞って文章を直します。長い追加依頼を何度も重ねる前に、今回得たい結果を一文で確認すると、会話の目的を保ちやすくなります。

導入時には、同じ種類の小さな修正相談で試してみてください。候補が役立ったのは次の確認項目を思い出す場面だったのか、文章を短く入力できる場面だったのかを振り返ると、自分の使いどころが分かります。Codexチャットの入力候補は、正しい作業を保証する判定機能ではありません。現在の会話を基にした下書きを読み、必要な範囲へ直し、送信するという基本を押さえて使います。