Codex補完の使い方とIDE入力支援の違い、導入判断と確認方法

Codex補完は何を補う機能か

Codex補完という検索語には、二つの意味があります。一つはターミナルで codex と入力したあとに completion、resume、review などのサブコマンドや、利用できるフラグを候補として示すシェル補完です。もう一つは、エディタで関数の続きを提案するコード補完です。前者は入力欄の候補を整える機能、後者はソースコードの候補を作る機能で、同じ「補完」でも処理する対象が異なります。OpenAIのCLIカスタマイズ公式資料は、前者をShell completionsとして説明しています。

公式リファレンスで codex completion は、Bash、Zsh、Fish、PowerShellの補完スクリプトを生成するStableコマンドとして掲載されています。生成された内容はシェルが読み込む定型のスクリプトであり、毎回モデルへ質問して候補を考えさせるものではありません。そのため、設定が済んだあとは入力時の反応が軽く、ネット接続や利用枠の増減とは別の層で動きます。

codex completion はシェル向けのコマンド

codex completion zsh のようにシェル名を続けると、そのシェル向けの定義が標準出力へ出ます。公式資料にはZshの例として eval "$(codex completion zsh)" が示され、compdef が見つからない場合は compinit を先に初期化する手順も記載されています。重要なのは、コマンドを一度実行して終わりにせず、現在のシェルへ読み込むことです。読み込み後に codex と入力してTabを押し、候補が表示されるか確認します。

この仕組みで補われるのは、シェルが理解できるコマンドとオプションです。プロジェクトの中身を読んで関数を提案したり、エラーの原因を推測したりする機能ではありません。コードの相談やファイル変更は通常のCodexセッションで行い、ターミナルの入口だけを短くする用途として使い分けると、期待と結果がずれにくくなります。

IDEのコード補完とは目的が違う

IDEのコード補完は、カーソル位置、開いているファイル、周辺の型や文脈をもとに、入力中のコードの続きを候補として表示します。候補を受け入れるか、書き直すかをその場で決めるため、行や関数を速く書く場面に向いています。一方、Codex CLIのシェル補完は codex completion のような入口を見つけやすくするものです。両者を一つの機能だと考えると、PowerShellの設定を済ませたのにコードの候補が出ない、といった誤解が生まれます。

OpenAIのCodex IDE拡張公式資料は、開いているファイルや選択範囲を文脈として渡し、変更をコードの横で確認し、必要なら長い作業へ引き渡す使い方を中心に案内しています。これはシェル補完とは別の入口です。IDEでの変更提案が欲しい人は拡張機能の対応状況を確認し、コマンド名の入力を整えたい人はシェル補完を設定します。

なぜ今、Codex補完を見直すのか

補完は小さな設定に見えますが、1日に何度も同じコマンドを入力する開発環境では、候補が出るまでの数秒や、オプション名を調べる回数が積み上がります。特に、リポジトリを読み、修正し、結果を確認し、次の質問を続けるような作業では、コードそのものよりも操作の切り替えが負担になることがあります。シェル補完は大きな機能を増やすのではなく、既に使っているCLIを迷わず呼び出すための土台です。

OpenAIは2026年6月25日の公式レポートHow agents are transforming workで、Codexの利用が短い対話から、人間なら数十分から数時間かかる作業へ広がっていると説明しました。これは補完の新製品発表を意味しませんが、Codexを長く使うほど、入力・再開・確認といった周辺操作の整備が効くという背景になります。公式CLI資料が現在もシェル補完を明確な機能として案内しているのは、この利用場面の広がりと相性がよい動きです。

長い作業ほど入力の摩擦が効く

短い質問なら、サブコマンドを毎回手で入力しても大きな負担にはなりません。しかし、調査の途中でセッションを再開したり、変更の確認へ移ったり、ヘルプを開いたりする場面が続くと、正確な綴りを思い出すこと自体が中断になります。候補から選べれば、記憶ではなく画面を見て判断できます。これは作業を勝手に進める機能ではなく、人が次の操作を選ぶまでの手数を減らす機能です。

補完を使っても、入力したサブコマンドが自分の意図に合っているか、対象のプロジェクトが正しいか、変更後の結果を確認したかは別途判断が必要です。候補が見えたことで安心しすぎず、短いコマンドほど対象と目的を声に出して確認する習慣を残します。速さを得る場所と、正しさを確かめる場所を分けることが、補完を安全に使うポイントです。

CLIからIDEへ広げるときの境界

公式IDE資料は、現在開いているコードを文脈にして説明や編集を頼み、差分を確認し、作業が大きくなれば別の場所へ引き渡す流れを紹介しています。シェル補完が担当するのは、そのIDE拡張やCLIを呼び出す前段の入力です。CLIの候補が出ることと、IDEでコード変更をレビューできることは別の状態なので、導入後の確認項目も分けて記録します。

たとえば「Tabで codex review を候補に出したい」はシェル補完の確認です。「開いているテストファイルをCodexに読ませ、変更差分を確認したい」はIDE拡張の確認です。この二つを同じ設定の問題として扱わないだけで、原因調査の範囲が狭くなります。まずターミナルの候補、次にコードの文脈、最後に変更の確認という順序で試すと、どこで詰まったかを説明しやすくなります。

対応シェルと出力の考え方

公式のCLIカスタマイズ資料が挙げる対象は、Bash、Zsh、Fish、PowerShellです。シェルごとに生成するコマンドは同じ形ですが、読み込み方と保存先は異なります。LinuxやmacOSだけの機能ではなく、WindowsのPowerShellでも同じ入口を用意できるため、チーム内で端末が分かれていても「どのシェルの定義を読み込んだか」を記録すれば比較できます。まず自分が今開いているシェルを確認し、別のシェル向けの設定を誤って保存しないことが大切です。

表の読み込み例は現在のセッションだけに効かせる確認用です。毎回の起動で有効にするには、それぞれの設定ファイルやPowerShellプロファイルから生成物を読み込みます。公式資料が示しているのはスクリプトの生成と読み込みの考え方なので、実際のプロファイルの場所、組織で管理されている端末の制限、シェルのバージョンは自分の環境で確かめてください。

BashとZshで設定する場合

Bashでは、生成した内容を現在のシェルへ eval で渡す方法が手軽です。Zshでは、公式資料の例どおり autoload -Uz compinit && compinit を先に実行し、その後で eval "$(codex completion zsh)" を読み込みます。確認用の一時設定と、.bashrc や .zshrc へ残す設定を分けると、誤ったシェル用の定義を消しやすくなります。Zshで command not found: compdef が出る場合は、補完システムの初期化が抜けている可能性が高いです。

保存する前に、生成された出力が想定したシェルの構文になっているかを目視します。複数の端末から設定を持ち込んだ場合、同じコマンドの定義が二重に読み込まれて候補が重なったり、古い定義が残ったりすることがあります。まず現在のセッションで一度だけ試し、表示が正しいと分かってから設定ファイルへ移すのが扱いやすい手順です。

FishとPowerShellで設定する場合

Fishはパイプで source へ渡す書き方が使えます。PowerShellは、生成された出力を文字列として受け取り、現在のセッションで評価する形にします。PowerShellの例は次のとおりです。

codex completion powershell | Out-String | Invoke-Expression

この一行で候補が表示されるかを確認したあと、PowerShellプロファイルから同じスクリプトを読み込む形へ整理します。プロファイルの内容を直接増やす前に、保存したファイルをテキストとして開いて、Codex以外の定義を壊していないか確認してください。会社の端末などでプロファイルの変更が制限されている場合は、端末の管理担当者が定めた方法を優先し、個人設定だけで解決しようとしないことが重要です。

初回導入の手順

シェル補完は、生成、読み込み、Tabでの確認という三段階に分けると、どこで問題が起きたかを追いやすくなります。いきなり設定ファイルへ追記するのではなく、現在の端末で一時的に読み込み、候補の内容を確かめてから常用設定へ移します。以下はPowerShellを例にしていますが、Bash、Zsh、Fishでも順番は同じです。

1. 今使っているシェルとCodexの場所を確認する。 PowerShellなら Get-Command codex、BashやZshなら command -v codex を実行し、意図した実行ファイルが呼ばれているか確認します。複数の導入方法を試した端末では、別の版が先に見つかることがあります。

2. 対象シェルのスクリプトを生成する。 PowerShellなら codex completion powershell、Zshなら codex completion zsh のように実行します。画面に出た内容が空でないこと、エラーメッセージが混ざっていないこと、指定したシェルの定義として読めそうなことを確認します。

3. 現在のセッションだけへ読み込む。 PowerShellでは codex completion powershell | Out-String | Invoke-Expression を使い、BashやZshでは eval "$(codex completion bash)" または eval "$(codex completion zsh)" を使います。まず一時的な読み込みで挙動を確認すれば、設定ファイルを戻す作業を避けられます。

4. 候補の表示を確認する。 codex と入力してTabを押し、サブコマンドが表示されるかを見ます。続けて codex re のように入力してTabを押し、resume などの候補へ絞り込めるか確認します。候補の名前が出ても、実行はEnterを押すまで行わない点を意識します。

5. 常用する場合だけプロファイルへ保存する。 一時設定で問題がなければ、使っているシェルの設定ファイルやPowerShellプロファイルから生成スクリプトを読み込む行を追加します。保存後に新しいシェルを開き、もう一度 codex とTabを試します。更新でコマンドが増減したときは、古い定義を残したまま重ねず、生成元を確認して置き換えます。

PowerShellで安全に常用設定へ移す

PowerShellでは、出力を別ファイルに保存し、プロファイルからそのファイルを読み込む形にすると、生成物を目視しやすくなります。次の例では保存先を一時変数に入れています。

$completionPath = Join-Path $HOME "codex-completion.ps1"
codex completion powershell | Set-Content -Path $completionPath -Encoding utf8
Get-Content -Path $completionPath -TotalCount 12

内容を確認してから、PowerShellプロファイルへそのファイルを読み込む行を追加します。プロファイルがまだ存在しない端末では、先に現在のPowerShellで $PROFILE の場所を確認してください。管理対象PCではプロファイル実行が制限される場合があるため、エラーが出たときに実行ポリシーを無理に変更せず、まず管理方針とプロファイルの読み込み状態を確認します。

IDEの入力支援や他ツールとの違い

「Codex補完」を選ぶときは、何を候補にしたいのかを一文で言えるようにします。ターミナルのコマンド名ならCodex CLIのシェル補完、関数や行の続きを書きたいならIDEのコード補完、複数ファイルを調べて変更案を確認したいならエージェント型の編集支援が候補です。製品名だけで比較すると、同じ画面に見えるTabキーの意味まで混ざるため、入力対象と確認方法の二つで比べます。

GitHub Copilotについては、公式のIDEコード提案資料が、入力中に表示するGhost textと、次の編集箇所を提案する機能を説明しています。Cursorは公式のドキュメントで、コードを理解し、機能を作り、バグを直し、変更をレビューするコーディングエージェントとして案内されています。両者ともコードを書く画面の支援が中心で、codex completion が扱うシェルの候補とは役割が違います。

コマンドを思い出したい人はCLI補完

codex resume や codex review のように、使うコマンドは覚えていても細かな綴りやフラグが曖昧になる人にはCLI補完が合います。候補を見ながら入力できるため、公式リファレンスを毎回開く回数を減らせます。ただし、候補の中から何を選ぶかは利用者が判断します。対象リポジトリ、読み取りだけにするか編集まで許可するか、確認後に実行するかを、コマンドごとに意識してください。

CLI補完は利用枠やモデルを選ぶ機能ではありません。モデルを切り替える、作業対象を変える、ファイルを編集する、といった判断は通常のCodexの設定とセッションで行います。補完の導入で変わるのは入力のしやすさだけなので、導入前後の成果物の品質を同じ条件で比べたい場合にも、比較対象を切り分けやすい利点があります。

コードの続きを書きたい人はIDE支援

カーソル位置から関数の本体やテストの雛形を提案してほしいなら、シェル補完ではなくIDEのコード支援を検討します。GitHub Copilotの公式資料は、Ghost textの候補をTabで受け入れる例や、複数行にわたる次の編集候補を案内しています。Cursorの公式資料も、Tabによる候補とInline Edit、Agentを分けて紹介しています。ここで出る候補はソースコードなので、受け入れたあとにテスト、差分、依存関係を確認します。

Codex IDE拡張を選ぶ場合は、開いているファイルや選択範囲をそのまま文脈として使えるか、変更の要約と差分を同じ画面で確認できるかを見ます。公式資料では、焦点を絞った編集、コードの理解、変更のレビュー、長い作業への引き渡しが案内されています。シェル補完と同時に導入しても構いませんが、候補コードの品質は別の確認項目として扱います。

補完が出ないときの切り分け

候補が表示されないときは、Codex本体の問題だと決めつけず、シェル、実行ファイル、読み込み、候補の定義の順で確認します。シェル補完は現在のセッションへ読み込まれて初めて有効になるため、設定ファイルへ追記しただけでは、既に開いている端末には反映されないことがあります。新しいシェルを開くか、現在のセッションで読み込みをやり直してください。

また、候補の表示はシェルの状態に左右されるため、IDE側の拡張機能やCodexのモデル設定を先に変更する必要はありません。問題を再現できる最小のコマンドを決め、同じ端末で一つずつ確かめると、設定を増やして原因を見失うことを防げます。

codex 自体が見つからない場合

Get-Command codex や command -v codex で何も返らない場合、補完以前に実行ファイルの場所がシェルの検索対象へ入っていません。まず codex --version が単独で動くかを確かめ、動かなければ導入方法とPATHを確認します。別の端末で動く設定をそのままコピーするのではなく、現在のシェルから見える場所を基準にします。Codexの公式CLIクイックスタートも、導入後に最初のタスクを始めるまでの確認手順を案内しています。

codex --version は動くのに候補だけが出ない場合は、対象シェルを間違えている可能性があります。PowerShellでZsh向けの出力を評価しても、PowerShellの補完定義にはなりません。生成コマンドの最後に指定したシェル名と、現在の端末のシェルを同じにします。

候補が古い、重複する場合

Codexを更新したあとに新しいサブコマンドが出ない場合は、以前に保存した補完スクリプトが読み込まれているかもしれません。現在のプロファイルやシェル設定ファイルで codex completion に関係する行を確認し、同じ定義を複数回読み込んでいないか調べます。古いファイルをすぐ消すのではなく、どの行が候補を提供しているかを確認してから、生成し直した一つの定義へ整理します。

候補が二重に表示される場合も、シェルの設定ファイルと別の保存ファイルの両方を読み込んでいる可能性があります。設定を一つにまとめ、新しいシェルで再確認します。Bash系ではコマンドの場所を再検索するために hash -r が役立つ場合があり、PowerShellでは新しいセッションを開いて Get-Command codex の結果を確認します。シェルごとの作法を混ぜず、エラーが出た行をそのまま記録すると復旧しやすくなります。

Zshで compdef が見つからない場合

Zshで command not found: compdef が表示される場合、公式資料が説明するように補完システムの初期化を先に行います。次の順で現在のセッションに読み込みます。

autoload -Uz compinit && compinit
eval "$(codex completion zsh)"

それでも出ない場合は、Zshではなく別のシェルを開いていないか、設定ファイルが読み込まれているか、Codexの実行ファイルが同じかを確認します。Zshの設定にBashの書式を貼り付けると、別のエラーになることがあります。公式CLIカスタマイズ資料の該当箇所と、現在使っているZshの設定を照合してください。

日常の使い方と更新後の確認

シェル補完を入れた後は、候補を表示できることだけでなく、普段の作業で本当に入力の中断が減ったかを見ます。よく使う resume、review、mcp などを候補から選べるか、未知のオプションが表示されたときに公式リファレンスへ戻れるかを確認します。候補が増えすぎて選びにくい場合は、すべてを覚えようとせず、先頭数文字で絞る入力を使います。

公式CLI資料は、長いプロンプトを入力するために Ctrl+G で VISUAL または EDITOR に設定したエディタを開く方法も案内しています。これはシェル補完とは別機能ですが、短いコマンドはTab、長い依頼文はエディタという役割分担を作れます。入力方法を一つに固定するより、短い操作と長い説明を適した場所へ分けたほうが、誤入力や説明不足を減らせます。

更新後は同じ三点を確認する

Codexの版が変わったときは、候補の生成、シェルへの読み込み、代表コマンドの表示という三点を同じ順番で確認します。公式リファレンスで新しいコマンドの説明が追加されていても、手元の補完スクリプトを再生成しなければ候補には反映されません。反対に、候補に見えても現在の版が対応していない場合があるため、Enterで実行する前に codex --help や公式のコマンド一覧へ戻ります。

確認結果は、使ったシェル名、codex --version の結果、補完を読み込んだ場所、Tabで表示された代表候補の四項目に分けて残します。個人のメモでも十分ですが、チームで同じ端末構成を使うなら、秘密情報や個人のパスを含めず、再現に必要な情報だけを共有します。環境が違う人が読んでも、どの設定を試したか分かる記録にすると、更新後の差分を追いやすくなります。

補完と確認を混同しない

候補が出ることは、コマンドが安全であることや、変更が正しいことを意味しません。シェル補完はあくまで入力支援であり、実行前の目的確認、対象の確認、実行後の出力確認を置き換えません。コードを提案するIDE支援でも同じで、受け入れたコードをテストし、変更範囲を見て、意図しないファイルが変わっていないかを確認します。

この切り分けを守ると、Codex CLIの候補入力、Codex IDE拡張の差分確認、GitHub CopilotやCursorのコード提案を同じ基準で見られます。便利さを測るときは入力時間、正しさを測るときはテストとレビュー、利用範囲を測るときは権限と対象を別々に記録します。補完は最初の一歩を軽くしますが、最後の判断まで代わりに行うものではありません。

まとめ

Codex補完の要点は、codex completion がコード生成機能ではなく、Bash、Zsh、Fish、PowerShellでCodex CLIのコマンドやオプションを入力しやすくする仕組みだということです。まず現在のシェルとCodexの場所を確認し、対象シェルのスクリプトを生成し、一時的に読み込んでTabで検証します。問題がなければプロファイルへ保存し、更新後は生成し直します。

IDEで関数の続きを書きたい場合は、Codex IDE拡張、GitHub Copilot、Cursorなどのコード支援を比較します。ターミナルの候補とコードの候補を分ければ、設定の場所も期待する結果も明確になります。OpenAIのCodex CLI公式資料とCLIカスタマイズ資料を基準に、手元の版とシェルに合わせて小さく確認するのが、長い開発作業を止めないための現実的な始め方です。