CodexをVS Codeで使う方法｜CLI版との違いと安全な始め方

CodexをVS Codeでも使ってみたい。
でも、何から始めればいいのか分からない。
CLI版やGitHub連携との違いもよく分からない。

いきなりファイルを触らせて大丈夫なのか。
非エンジニアでも扱えるのか。
CLI版やGitHub連携とは何が違うのか。

CodexをVS Codeで使ってみたいと思っても、最初に整理することが多すぎて、そこで止まってしまう人は少なくないと思います。

どうも、AI Work Hack管理人のLONです。

結論からお伝えすると、CodexをVS Codeで使うときに大事なのは、設定方法そのものよりも、何を任せるか、どこまで触らせるかを先に決めることです。

私自身も、Codexにいきなり丸投げするのではなく、まずChatGPTで要件や禁止事項を整理し、それを指示書としてCodexに渡す形で使うことが多いです。

CodexをVS Codeで使いたいときに迷いやすいのは、設定手順だけではありません。CLI版との違い、安全な始め方、最初に任せやすい作業まで分けておくと、かなり進めやすくなります。

CodexをVS Codeで使う前に知っておきたいこと

まずは、CodexをVS Codeで使う前に分けておきたい前提から見ていきます。

設定方法より先に、Codexに任せる範囲を決める

CodexをVS Codeで使う話は、導入手順、拡張機能、CLI、コード生成、修正依頼の説明に寄りがちです。もちろん設定方法も欠かせません。

ただ、非エンジニアや小規模事業者が業務で使うなら、最初に見るべきなのは「設定できるか」よりも「どの作業に入れるか」です。

たとえば、既存ファイルの確認、簡単な修正案の作成、READMEやdocsの整理、テスト実行の補助は比較的任せやすい作業です。

一方で、本番環境への反映、重要ファイルの削除、外部APIの実行、認証情報に触れる作業は、最初から任せきるべきではありません。

VS CodeでCodexを使う前に決めるべきなのは、設定手順だけではありません。
作業範囲、禁止事項、確認方法、失敗したときの戻し方まで含めて、先に整理しておくことが大切です。

VS Code版・CLI版・GitHub連携は役割が違う

Codexまわりの情報を調べると、VS Code、CLI、GitHub連携の話が混ざって出てきます。

ここで混乱しやすいのは、それぞれが同じ入口ではないことです。
最初は、目的ごとに役割を分けて見た方が判断しやすくなります。

もちろん、CLIの細かいコマンドやMCP、AGENTS.md、config.tomlまで分かると、できることは広がります。

ただ、最初からそこまで追うと、たぶん重いです。まずはVS CodeでCodexを小さく試し、安全に使う感覚をつかむところからで十分だと思います。

非エンジニアほど、使う前の指示整理が大事

非エンジニアが最初からコードを完璧に理解する必要はありません。Codexに渡す前に、作業を言葉で区切ることです。指示が曖昧なままだと、Codexがどこまで触ってよいか判断できず、意図しないファイルに手を入れてしまう可能性があります。

この整理があるだけで、Codexはかなり使いやすくなります。逆に、この整理なしで本番環境や重要ファイルを触らせると、便利さよりリスクが前に出ます。

LONの実録：ChatGPTで指示書を作ってからCodexに渡す

CodexのVS Codeでの基本的な使い方

ここからは、CodexをVS Codeで使うときの考え方を、実務に入れる流れで見ていきます。細かいUIや拡張機能名、料金、対応OSなどは変わる可能性があるため、実際に使う前には最新の公式情報で確認してください。

まず確認すべき前提環境

最初に確認したいのは、自分の作業環境で安全に試せる状態になっているかです。VS Codeを開けること、対象フォルダが分かること、変更してよいファイルと触らないファイルを分けられること。このあたりが曖昧なまま始めると、Codex以前に作業の前提が崩れます。

おすすめは、いきなり本番のフォルダで試さないことです。検証用のフォルダ、下書き、コピーしたファイル、小さなサンプルから始める方が安全です。WebサイトやWordPress関連の作業であれば、公開中の本番データを直接触るのではなく、下書きやローカルファイルで確認できる範囲から始めるのが現実的です。

1. 対象フォルダを決める
2. 触ってよいファイルを決める
3. 禁止事項を決める
4. 実行してよいコマンドを決める
5. 確認方法を決める
6. 最後に人間が見るポイントを決める

VS Code上でCodexにできること

VS CodeでCodexを使う強みは、作業対象のファイルを見ながら相談しやすいことです。ファイル構成、既存コード、README、設定ファイル、記事下書きなどを前提にしながら、具体的な作業を進めやすくなります。

Codexはファイル確認、差分作成、スクリプト作成、ドキュメント整理、テスト実行の補助などに向いています。一方で、削除、公開、外部API実行、認証情報に触れる作業は、必ず人間の確認を挟むべきです。

最初に任せやすい作業

非エンジニアが最初にCodexへ任せるなら、いきなり大きな実装よりも、確認・整理・下書きの作業が向いています。成果物を人間が確認しやすく、必要ならやり直しもしやすいからです。

最初の練習としては、壊れて困るものを直接触らない作業がちょうどいいです。Codexの便利さを感じつつ、リスクを抑えられます。

いきなり任せない方がいい作業

最初から任せない方がいい作業もあります。特に、削除、公開、上書き、外部API実行、本番環境への反映は慎重に扱うべきです。できるかどうかではなく、確認せずに実行してよいかで判断してください。

Codexを使うほど任せられることは増えていきます。

ただ、最初から全部を任せる必要はありません。任せないことを決めておく方が、長く安全に使えます。

Codex VS Code版とCLI版の違い

Codexを調べていると、VS Codeで使う話とCLIで使う話が混ざりやすくなります。
どちらが優れているかではなく、入口としての役割が違うと考える方が分かりやすいです。

VS Code版はファイルを見ながら進めやすい

VS Codeで使うメリットは、作業対象のファイルやフォルダを視覚的に確認しながら進めやすいことです。非エンジニアにとって、ターミナルだけで作業するより、ファイル一覧や編集画面が見えている方が安心しやすい場面があります。

記事下書き、README、設定ファイル、スクリプトなど、実際のファイルを見ながら「この範囲だけ直して」「このファイルは触らないで」と指示しやすいのも利点です。最初の導入としては、VS Code版は作業の見通しを持ちやすい入口になりやすいです。

CLI版は作業範囲が広く、慣れると強い

CLI版は、ターミナル操作やコマンド実行に慣れている人ほど強力に使いやすい領域です。スクリプト実行、テスト、ビルド、複数ファイルの処理など、作業範囲を広げやすいからです。

ただし、CLIの細かい設定やコマンド、MCP、AGENTS.md、config.tomlまで一気に追いかけると、これから始める人にはかなり重くなります。まずはVS Code上で目の前のファイルを安全に扱い、慣れてきたらCLI側へ広げる流れで十分です。

最初はVS Code版、深掘りはCLI版という考え方

非エンジニアが最初に考えるなら、まずVS Codeで小さく試し、慣れてきたらCLIで深掘りする順番が現実的です。入口を分けると、必要以上に怖くなりません。

VS Codeでは、対象ファイルを見ながら小さな修正や整理を依頼する。CLIでは、より広い作業、コマンド実行、検証、開発フローに踏み込む。このように役割を分けると、混乱しにくくなります。

GitHub連携は別の導線として整理する

GitHub連携は、リポジトリ、Issue、Pull Request、チーム開発などと関わるため、VS Codeで小さく試す話とは少し導線が違います。便利な領域ではありますが、最初からここまで混ぜると読者の負担が増えます。

GitHub連携は、チーム開発やリポジトリ運用まで広げたい段階で考えれば十分です。最初はVS Code上で、目の前のファイルを安全に扱うところから始める方が迷いません。

Codexを業務で安全に使うための注意点

Codexは便利ですが、業務で使うなら最初に安全側へ寄せておきたいところです。特に非エンジニアが使う場合は、何を頼むかより先に、何を頼まないかを決めておく方が安心です。

AIに任せる前に作業範囲を決める

まず、作業範囲を狭くします。「このフォルダだけ」「このファイルだけ」「この見出しだけ」「このCSVだけ」のように対象を限定すると、Codexの出力を確認しやすくなります。

私がCodexに指示を渡すときも、この安全柵を細かく書きます。対象フォルダ、作成してほしいファイル、触らないでほしいもの、実行してよいコマンド、最終報告でほしいことまで書く。これだけで、Codexの作業はかなり安定します。

変更内容を人間が確認する

Codexが作ったものは、そのまま反映するのではなく、人間が確認します。コード、設定、記事本文、メタ情報、公開状態、画像、内部リンクなどは、人間が見る前提にした方が安全です。

確認ポイントは、技術的な正しさだけではありません。意図と合っているか、読者に誤解を与えないか、不要な断定がないか、秘密情報が入っていないか、公開してよい状態か。こうした判断は人間側に残すべきです。

AIに任せるところと、人間が判断するところを分ける。ここは、AI Work Hackでずっと大事にしている考え方です。

本番環境や重要ファイルは慎重に扱う

本番環境、公開中のサイト、重要な設定ファイル、顧客情報、認証情報、サーバー接続情報などは、最初からCodexに自由に触らせる対象ではありません。扱う場合でも、作業範囲、権限、確認手順を先に決めて、人間が最後に判断する流れにしておきます。

おすすめは、下書き、検証環境、ローカルファイル、コピーしたファイルで試すことです。WordPressなら公開ではなく下書き。APIなら実行ではなくdry-run。削除ではなく削除候補のリストアップ。こうして一段階挟むだけで、事故のリスクを下げられます。

失敗しやすいポイントを先に知る

CodexをVS Codeで使うときに失敗しやすいのは、技術力の不足だけではありません。むしろ、指示の曖昧さが原因になることが多いです。

この曖昧さを減らすために、ChatGPTで指示書を作ってからCodexに渡す流れが役立ちます。頭の中にある「なんとなくこうしてほしい」を、作業指示として見える形にする。これが、非エンジニアがCodexを使うときの一番大きなコツです。

CodexをVS Codeで使う前のチェックリスト

最後に、CodexをVS Codeで使う前に見ておきたいことをまとめます。実際に触る前に、このチェックリストを見ながら、作業範囲と安全条件を決めておくと進めやすくなります。

環境準備チェック

AIに任せる作業のチェック

最初に任せる作業は、確認しやすく、戻しやすいものから選びます。ファイル構成の確認、READMEやdocsの整理、記事構成や下書きの作成、CSVの集計、小さな修正案、dry-run前提のスクリプト作成、変更内容の要約などが入り口として扱いやすいです。

人間が確認する作業のチェック

人間が確認すべき作業は、最後まで人間側に残します。ここを曖昧にしないことが、Codexを業務で使うときの安全性につながります。

よくある質問

Q. CodexはVS Codeだけで使えますか？

Codexの提供形態や対応環境は変わる可能性があるため、実際に使う前には最新の公式案内を確認してください。最初は、VS CodeでCodexを使い始めるときの考え方と、安全な進め方が分かれば十分です。

Q. Codex CLIとVS Code版はどちらから始めるべきですか？

非エンジニアやVS Codeに慣れていない人は、まずVS Code上で小さなファイル確認や修正から始める方が入りやすいです。CLIは慣れると強力ですが、コマンドや設定の理解が必要になるため、深掘りは慣れてから進めても遅くありません。

Q. 非エンジニアでもCodexを使えますか？

使えます。ただし、重要なのはコードを完璧に読めることではなく、Codexに渡す作業を整理することです。何をしてほしいのか、どこまで触ってよいのか、何をしてはいけないのかを言葉にできれば、Codexは実務補助として使いやすくなります。

Q. 本番環境のファイルをCodexに触らせても大丈夫ですか？

最初から本番環境を直接触らせるのはおすすめしません。検証環境、下書き、コピーしたファイル、dry-runを挟んで、人間が確認してから反映する流れにした方が安全です。

Q. ChatGPTとCodexはどう使い分けるとよいですか？

私の運用では、ChatGPTは整理、設計、指示書作成に使い、Codexは実装、ファイル操作、検証に使うことが多いです。ChatGPTで作業の地図を作り、Codexで実際に手を動かす。この分担にすると、非エンジニアでも作業をコントロールしやすくなります。

あわせて読みたい

【2026年も使える】ChatGPTの天才的な使い方9選！仕事が劇的に速くなるプロンプト集

あわせて読みたい

PHP未経験がAIで「保守管理プラグイン」を1時間で自作。クライアント継続率を高めた開発実録

CodexのVS Codeでの使い方まとめ

CodexをVS Codeで使うと、実際のファイルを見ながらAIに作業を頼みやすくなります。ただし、大事なのはCodexを開くことではありません。Codexに渡す前に、作業範囲、禁止事項、確認方法を整理することです。

最初は小さくて構いません。
READMEを整理する。ファイル構成を確認する。下書きを作る。dry-run付きのスクリプトを作る。そこから始めれば十分です。

AIに使われるのではなく、AIを使う側になるために、まずはCodexに何を任せ、何を人間が判断するのかを分けてみてください。

LON | AI Work Hacker

非エンジニア実装家 / AI業務委託

XYouTubeContact

「コードは書かない。AIを操る。」

普段は業務委託のプロとして、AI企業のLINE運用や自動化システム構築を担当。

エンジニア経験ゼロから、AIだけを武器にツールを自作する「実務ハック」を研究中。