技術資料

VS Codeでの編集支援、コード調査・修正、指示の再利用という観点から、GitHub CopilotとCodexの使い方を整理します。

今回の比較対象

• GitHub CopilotのVS Codeでの利用。拡張の配布ページはGitHub Copilot Chat
• OpenAIのCodex拡張（拡張の識別子はopenai.chatgpt）
• 仕様の確認日：2026年10月7日

なお、VS Codeの共通チャット画面からCodexを選ぶAgent Host連携もありますが、ここでのCodexはOpenAIの拡張を対象とします。CopilotでOpenAIのモデルを選ぶことと、Codex拡張を使うことも別です。モデルを切り替えても、ツールや設定の仕組みまでCodexへ切り替わるわけではありません。詳しくはVS Code公式のエージェントとモデルの選び方を参照してください。

入力中の補助と、作業の依頼を分けて考える

まずは、AIにどのように手伝ってほしいかを分けると比較しやすくなります。

Copilotの入力中の支援には、薄い文字で候補を表示する補完と、次の編集を予測するNext Edit Suggestionsがあります。自分でコードを書き進めながら候補を受け取りたいなら、まずCopilotを試す理由になるかと思います。候補は通常Tabで採用できます。仕組みと操作はVS Code公式のCopilotインライン候補の説明にまとまっています。

一方、「この処理を調べて、必要な修正をして、テストまで実行してほしい」という依頼は両者の比較対象になります。Copilot拡張の説明でも、複数ファイルの編集やコマンド実行、失敗したテストを見て修正する流れが案内されています。CodexもIDE拡張の公式資料で、コードの説明、変更、デバッグ、差分確認を扱っています。

ここでは、エージェント機能があるかどうかより、自分が対象コードを渡しやすいか、調査の根拠や変更内容を追いやすいかを見る方が選びやすいです。

モデルを変えることと、ツールを変えることは別

Copilot Chatでは利用可能なモデルを選択でき、複数の提供元のモデルも扱えます。ただし、選べるモデルはプランやクライアント、管理設定によって異なります。また、チャットのモデルを変更しても、入力中の補完に使われるモデルは変わりません。GitHub公式のチャットモデル変更の説明で確認できます。

Codex側では、モデルや推論の設定、権限などをCodexの設定で管理します。拡張の画面に関するVS Code設定と、エージェントの動作に関するconfig.tomlは別の設定です。詳しくはOpenAI公式の開発設定を参照してください。

同じ名前のモデルを使っても、渡される情報や利用できるツール、指示の適用方法が異なれば結果は変わり得ます。モデルの評判だけでツール全体の使いやすさを決めない方がよいでしょう。

コード調査と修正は、依頼を分けて試す

両者を試すなら、最初から大きな機能を作らせるより、答えを確認できる小さな作業から始めると違いを見やすいです。

例えば、検証用のLaravelプロジェクトに注文検索APIがあり、statusパラメーターで検索条件を変える場面を考えます。以下は架空の題材です。

まずは処理の流れを調べてもらう

Copilotではチャットへ関連ファイルなどを追加し、Codexでは開いているファイルや選択範囲を渡して依頼します。Copilotのコンテキスト追加はVS Code公式のチャット操作、Codex側は前述のIDE拡張の資料で案内されています。

注文検索APIで、statusパラメーターが検索条件になるまでの処理を調べてください。
まだファイルを変更せず、調査結果だけを説明してください。

- ルートと処理の入口
- 入力値の検証と検索条件の組み立て
- 関連する呼び出し元・呼び出し先
- DBへの書き込みや外部通信などの副作用
- 根拠となるファイルと行番号
- 未確認の点と、次に確認すべきこと

依存追加、DB操作、外部サービスへのアクセスは行わないでください。

回答の長さより、実際に該当するコードを示しているかを確認します。「空の値を無視します」と説明されたら、空文字列、未指定、0がどう扱われるかまでコードを追ってみると、見落としを確認しやすいです。

ただし、「変更しないで」と書くことと、編集を禁止する権限設定は別です。Copilot側はツール・ターミナルの承認設定、Codex側は権限とサンドボックスの設定も確認します。設定の説明はVS Codeの承認・権限とCodexのサンドボックスを参照してください。承認を求める設定でも、既に許可された編集まで毎回止まるとは限りません。

修正は、守ってほしい仕様を先に伝える

次に修正を頼むなら、原因と変更範囲を確認したうえで、期待する動作を具体的に書きます。

注文検索APIのstatus条件を修正してください。

期待する動作：
- status未指定の場合は、statusによる絞り込みを行わない
- status=0の場合は、状態が0の注文だけを取得する
- 空文字列や未定義の状態値は、入力エラーにする

まず原因と変更するファイルを説明し、私が方針を確認するまで編集しないでください。
方針の確認後は、必要な範囲だけを修正し、既存のテスト手順で検証してください。
テストの期待値を変更して通すのではなく、上記仕様を確認できるケースを追加してください。
実行したコマンド、結果、未確認の点を報告してください。
Gitのcommitとpushは行わないでください。

これは仕様の例なので、実際のプロジェクトでは既存の入力ルールに合わせてください。

修正後は、次のような点を比較します。

• 原因の説明と修正内容が一致しているか
• 必要のない整形やリファクタリングまで行っていないか
• 未指定・0・空文字列・不正値のテストがあるか
• 実行したテストと結果を確認できるか
• こちらから何回、追加の説明や修正指示を出したか

変更の確認では、画面上のレビュー表示に加えてGitの差分も確認します。Copilotのセッションの種類によっては、編集は確認前にファイルへ保存されています。レビュー画面があるから未適用、とは考えない方がよいです。詳しくはVS Code公式の変更レビューの説明を参照してください。

git status --short
git diff
git diff --check

git diffは通常、未追跡ファイルの内容やステージ済みの差分を表示しません。新しいファイルはgit statusで見つけて中身を開き、ステージ済みの変更があればgit diff --cachedも確認します。git diff --checkは空白などの確認であり、仕様やコードの正しさを保証するものではありません。

同条件で比較するなら、両ツールでサンプルの初期状態と依頼文を揃え、会話は別々に始めます。モデル・推論設定・権限・指示ファイル・テスト条件も記録しておきます。モデルを揃えられない場合は「そのツールとモデルの組み合わせ」の結果として読み、1回の成功や失敗で全体の性能を決めないようにします。

指示を再利用する仕組みは、対応範囲を確認する

毎回「既存の設計を優先して」「調査だけなら変更しないで」と書くのが手間になったら、指示をファイルへまとめる方法があります。

Copilotの対応範囲はGitHub公式の指示ファイル対応表、Codexの探索方法はOpenAI公式のAGENTS.mdの説明で確認できます。同じファイル名でも、階層の探索や指示の適用条件まで同じとは限りません。

リポジトリへ追加せずに指示を試したい場合

Copilotでは、コマンドパレットのChat: Open CustomizationsからInstructionsを開き、ユーザー用の指示を作る方法が案内されています。先に使うエージェントを選び、Newからユーザー用の保存先を選びます。

LocalセッションではVS Codeのプロファイル、CopilotのAgent Hostセッションでは~/.copilot/instructionsなど、保存先はセッションの種類で変わります。パスだけを覚えるより、選択中のエージェントに対応した画面で作る方が間違えにくいです。手順はVS Code公式のカスタム指示の説明を参照してください。

例えば、Copilotの.instructions.mdには次のような共通指示を書けます。

---
applyTo: '**'
---

- 調査を依頼された場合は、明示されない限りファイルを変更しない
- 修正前に原因と影響範囲を説明する
- 既存の設計と命名規則を優先し、不要なリファクタリングをしない
- 変更後は関連するテストを実行し、結果と未確認事項を報告する

CodexのAGENTS.mdには、上の箇条書き部分をMarkdownとして記述できます。CopilotのapplyToなどの設定まで、そのままCodexへ移すわけではありません。

applyToは自動適用する対象ファイルを指定するものです。調査だけの依頼では、必要な指示をチャットへ明示的に添付し、参照されたか確認します。指示一覧に表示されることと、意図どおり適用されることも別なので、小さな依頼で結果まで見ておきます。

なお、Copilotのカスタム指示は入力中のインライン候補には適用されません。チャット向けのルールが補完にも反映されるとは考えないでください。

Skillsは作業手順をまとめるときに使う

「呼び出し元を調べ、DBアクセスと副作用を確認し、根拠を示す」のような調査手順を繰り返すなら、Skillsに分ける候補です。規約を示す指示ファイルと、個別作業の手順をまとめるSkillsは役割が異なります。

公式資料では、Copilotはプロジェクトの.github/skills/や.agents/skills/、個人の~/.copilot/skills/などを扱います。Codexはリポジトリの.agents/skills/や個人の~/.agents/skills/などから読み込みます。利用場所の詳細はVS CodeのAgent SkillsとOpenAIのSkills作成資料を確認してください。

まずは通常のプロンプトで試し、共通の注意点を指示ファイルに、繰り返す手順をSkillsに移すくらいでよいかと思います。最初から設定を増やすと、結果に影響した指示を追いにくくなります。

どちらを選ぶか

公式仕様から考える選び方は、次のようになります。

• 自分でコードを書きながら補完や次の編集候補を受け取りたい：Copilotを候補にする
• Codexの指示や設定を使い、開いているコードを見ながら作業を依頼したい：Codex拡張を候補にする
• コード調査から修正・テストまで頼みたい：両者が候補。根拠、変更範囲、検証結果、追加指示の手間で比較する

利用条件も確認が必要です。Copilotの対象モデルや利用枠はCopilotの契約、Codexの利用枠はサインイン方法やプランに応じて考える必要があります。API単価だけで両ツールの実際の費用を比較することはできません。Copilotの利用条件とCodexの料金・利用枠の案内を確認し、コードやログを送る前には利用するサービスのデータの扱いも確認しましょう。

まとめ

GitHub CopilotとCodexは、コードの調査・編集・検証という用途で重なる部分があります。Copilotは補完専用、Codexだけが作業を進めるツール、と考えると、現在の機能とは合わなくなっています。

入力中の補助がほしいのか、調査や修正を会話で依頼したいのかを分けたうえで、自分が結果を確認しやすい方を選ぶのがよいかと思います。調査・修正の比較では、回答がそれらしく見えるかより、コードの根拠と差分、テスト結果を確認できるかを見ていきましょう。