PR|この記事にはアフィリエイト広告(A8.net)が含まれます。
Codexにコードを書き換えてもらったら、動いていた画面が崩れてしまった。どこを変えられたのか分からず、元に戻す方法も分からない。AIにコードを任せ始めた人がよくつまずくのが、この場面です。
Codexに頼む前は、作業フォルダをGitで管理し、今の状態をコミットしておきます。コミットが1つあれば、Codexが何を変えたかを差分で確かめられ、気に入らない変更は消して元の状態に戻せます。最低限覚えるコマンドは、git init、git status、git add、git commit、git diff、git restore、git revert、git switchの8つです。
情報確認日:2026年10月8日。OpenAIのCodexドキュメントと、Gitの公式ドキュメント(Pro Git日本語版とコマンドの解説ページ)をまとめた解説です。1回の依頼の進め方は筆者の提案です。
| コマンド | 使う場面 |
|---|---|
git init | フォルダをGitで管理し始める(最初の1回だけ) |
git status | 変更されたファイル、新しく増えたファイルを一覧で見る |
git add | 次のコミットに含める変更を選ぶ |
git commit | 今の状態を戻り先として記録する |
git diff | 変わった行を確かめる |
git restore | まだコミットしていない変更を捨てる |
git revert | コミット済みの変更を打ち消す |
git switch | 試し用のブランチを作る、元のブランチへ戻る |
なぜCodexに頼む前にGitが必要なの?

OpenAIのドキュメントは、Codexがバージョン管理(Git)と組み合わせたときに最もうまく働くと書いています。具体的には、作業用のブランチで進めること、依頼する前にgit statusで未保存の変更がない状態にしておくこと、こまめにコミットして小さな単位で戻せるようにすることを勧めています。こうしておけば、Codexの変更を切り分けて取り消しやすくなるという理由です。
Codexの動き方も、フォルダがGitで管理されているかどうかで変わります。Codexは起動時にフォルダがバージョン管理されているかを調べ、管理されていれば「Auto」を、管理されていなければ「読み取り専用(read-only)」を勧めます。設定によっては、Gitで管理しているフォルダでも、作業フォルダを信頼すると答えるまで読み取り専用で始まることがあります。Autoは、作業フォルダ内のファイルの編集とコマンドの実行を自動で行い、フォルダの外への書き込みやネット接続の前には承認を求める設定です。Gitで管理していないフォルダでは、Codexがファイルを書き換えない設定が勧められるということです。
ChatGPTのデスクトップアプリでは、変更を確かめるレビュー画面もGitを前提にしています。公式ドキュメントには、レビュー画面を使うにはGitリポジトリの中のプロジェクトが必要で、Gitで管理していないフォルダではリポジトリを作るよう促されると書かれています。
Codexに頼む前に、何を準備すればいい?
準備は、Gitで管理を始める、今の状態をコミットする、試し用のブランチを作る、の3つです。Gitが入っていない場合は、先にGit公式サイトからインストールしておきます。ここではターミナルで操作する例を書きます。
1. フォルダをGitで管理し始める
最初の操作は、作業フォルダに移動してgit initを実行することです。Pro Gitによると、このコマンドでフォルダの中に.gitというフォルダが作られ、Gitが履歴を管理するためのファイルがそこに入ります。ただし、実行しただけの段階では、まだどのファイルも記録されていない状態です。すでにGitで管理しているフォルダなら、この手順は飛ばしてかまいません。
cd 作業フォルダ
git init
パスワードやAPIキーを書いた設定ファイルなど、記録したくないファイルがある場合は、次の手順の前に.gitignoreというファイルにその名前を書いておきます。.gitignoreに書いたファイルは、Gitが自動で追加しない対象になります。
2. 今の状態をコミットして戻り先を作る
次は、今のファイルをすべてコミットする手順です。git add .でフォルダ内の変更をまとめて次のコミットに含め、git commit -mで説明を付けて記録します。最後にgit statusを実行し、コミットしていない変更が残っていないことを確かめます。
git add .
git commit -m "Codexに頼む前の状態"
git status
このコミットが、うまくいかなかったときに戻る地点になります。Pro Gitはgit statusを「どのファイルがどの状態にあるのか」を知るためのコマンドと説明しています。Codexに頼む前と後に1回ずつ実行する習慣をつけておくと、変わったファイルを見落としにくくなるはずです。
3. 試し用のブランチを作る
ブランチは、開発の本流から分かれて、本流を邪魔せずに作業を続けるための仕組みです。git switch -cに新しいブランチの名前を付けて実行すると、ブランチを作ってそこへ切り替えるまでを1回で行えます。
git switch -c codex-try
試し用のブランチでCodexに作業してもらえば、元のブランチには手を付けずに済みます。結果がよくなかったときは、元のブランチに戻れば頼む前の状態から考え直せます。ブランチの名前は自由に決めてかまいません。
Codexが変えた内容は、どうやって確かめる?
Codexが作業を終えたら、まずgit statusでどのファイルが変わったかを見ます。次にgit diffで、変わった行を確かめます。Pro Gitによると、引数を付けないgit diffは作業中のファイルとステージ(git addで選んだ変更)を比べるコマンドで、git add済みの変更はgit diff --stagedで直前のコミットと比べて表示する、という使い分けです。
注意したいのは、Codexが新しく作ったファイルです。まだGitが追跡していないファイルはgit diffには出てこないので、git statusの「Untracked files」の欄で確かめます。
Codexの側にも、変更を確かめる機能があります。使っている画面ごとにまとめると次のとおりです。
| 使う画面 | 確かめ方 | 公式ドキュメントの説明 |
|---|---|---|
| Codex CLI(ターミナル) | /diff | Gitの差分を表示する。Gitがまだ追跡していないファイルも含まれる |
| Codex CLI(ターミナル) | /review | 作業ツリーの変更をCodexにレビューさせる。コミットしていない変更(未追跡ファイルを含む)、ブランチの差分、特定のコミットから範囲を選ぶと、作業ツリーを変えずに優先度を付けた指摘を返す |
| ChatGPTのデスクトップアプリ | レビュー画面 | 未ステージ、ステージ済み、コミット、ブランチ、直前の依頼(Last turn)の範囲を切り替えて差分を見られる |
デスクトップアプリのレビュー画面について、公式ドキュメントはGitリポジトリの状態をそのまま映すと説明しています。Codexの変更だけでなく、自分で加えた変更やほかのコミットしていない変更も一緒に表示されます。Codexに頼む前にコミットしておけば、画面に出る変更はほぼCodexの作業分になるので、読み分けが楽です。
差分の記号の読み方や、1回の変更で確かめる項目は、AIにコードを書かせながら基礎を身につける方法の記事で、作例を使って説明しています。差分を読む練習を続けたい方は、あわせて読んでいただくと進め方が分かります。
気に入らない変更は、どうやって元に戻す?
戻し方を分けるのは、変更をコミットする前か後かです。コミットする前ならgit restoreで変更を捨て、コミットした後ならgit revertで打ち消します。状況ごとのコマンドは次の表のとおりです。
| 戻したい状況 | コマンド | 何が起きるか |
|---|---|---|
| コミット前の変更を、1つのファイルだけ捨てる | git restore ファイル名 | そのファイルをステージの内容に戻す。git addしていなければ直前のコミットの状態になる |
| コミット前の変更を、今いるフォルダの中ですべて捨てる | git restore . | 今いるフォルダ内の追跡中のファイルをすべて戻す |
git addした変更を、ステージから外す | git restore --staged ファイル名 | ステージだけを直前のコミットの状態に戻す。ファイルの中身は変わらない |
| Codexが新しく作ったファイルを消す | git clean -nで確かめてから削除 | -nは消す対象を表示するだけ。実際に消すには-fが必要。フォルダごと消すには-dも必要 |
| コミットした変更を打ち消す | git revert HEAD | 最新のコミットの変更を打ち消す新しいコミットを作る。履歴は消えない |
git restoreは、追跡中のファイルを戻すコマンドです。Codexが新しく作ったファイルは対象にならず、そのまま残ります。新しいファイルはgit statusで名前を確かめ、エディタやFinderで1つずつ消すのが安全です。git cleanはGitが追跡していないファイルを削除するコマンドで、-nを付けると実際には消さずに対象だけを表示します。Codexが新しいフォルダごと作った場合は、-dを付けないとそのフォルダの中は対象に入りません。まとめて消すときも、先に-nで対象を確かめてください。
コミットした後の変更はgit revertで打ち消します。Gitの公式ドキュメントによると、git revertは指定したコミットの変更を打ち消す内容を、新しいコミットとして記録します。古いコミットを消すわけではないので、何を取り消したかが履歴に残るのが特徴です。実行するときは、コミットしていない変更がない状態にしておく必要があります。
git restoreでコミットしていない変更を捨てると、その変更はGitの履歴に残っていないため取り戻せません。Pro Gitも、同じ働きをする古いコマンド(git checkout -- ファイル名)について、ファイルに加えた変更がすべて消える危険なコマンドだと注意しています。Codexの変更の一部だけ残したいときは、捨てる前にgit diffで中身を確かめてください。迷ったときは、試し用のブランチでいったんコミットしておくと、あとから見返せます。
ChatGPTのデスクトップアプリを使っている場合は、レビュー画面からも変更を戻せます。公式ドキュメントによると、差分全体(Revert all)、ファイルごと、変更のまとまり(hunk)ごとに、ステージや取り消しを選べます。残したい変更はステージし、要らない変更は取り消すという分け方を、公式ドキュメントは示しています。
2026年10月8日時点で、Codex CLIの公式リファレンス(Developer commandsページ)に載っているコマンドとスラッシュコマンドの一覧には、依頼前の状態へファイルを戻す専用のコマンドは見当たりませんでした。入力欄が空のときにEscを2回押すと前のメッセージから会話をやり直せますが、公式の説明は会話の編集と分岐で、ファイルを戻す機能とは書かれていません。CLIで戻すときは、ここまでのGitのコマンドを使います。
1回の依頼は、どんな流れで進めればいい?
ここまでのコマンドを、Codexへの1回の依頼の流れに並べると次のようになります。順番は筆者の提案です。
git statusで、コミットしていない変更がないことを確かめるgit switch -cで試し用のブランチを作る(同じ作業の続きなら不要)- Codexに、変更の範囲を絞った依頼を1つだけ出す
git statusとgit diff(CLIなら/diff)で、変わったファイルと行を確かめる- ブラウザで開く、テストを実行するなど、自分で動きを確かめる
- よければ
git addとgit commitで記録し、だめならgit restoreで捨てる
1回の依頼を小さくするのは、差分を読み切れる量に収めるためです。OpenAIのドキュメントも、Codexの提案をほかの人の変更と同じように扱い、確認の作業を実行して差分をレビューするよう勧めています。依頼のたびにコミットしておけば、うまくいかなかったときに戻る距離が短くて済みます。
なお、標準のAuto設定では、作業フォルダの中でも.gitフォルダは読み取り専用として保護されると公式ドキュメントに書かれています。履歴の記録やブランチの操作は、ここで紹介したコマンドで自分で行うのが、何が記録されたかを把握しやすい進め方だと筆者は考えています。
Codexの初期設定や利用枠の考え方は、Codexの使い方を初心者向けに解説した記事を読んでいただくと分かります。
Claude Codeを使う場合も、Gitは必要?
Claude Codeを使う場合も、戻り先の基本はGitのコミットです。Claude Codeには、依頼のたびにファイルの状態を自動で保存するチェックポイントがあり、入力欄が空のときにEscを2回押すか/rewindを実行すると、以前の状態に戻せます。
ただし、Anthropicの公式ドキュメントによると、チェックポイントが記録するのはClaudeのファイル編集ツールによる変更だけです。rmやmvなどのBashコマンドで変わったファイルは戻せず、Claude Codeの外で自分が編集したファイルも原則として対象外です。公式ドキュメントも、チェックポイントは作業中にすぐ戻るための機能で、長く残す履歴にはGitを使い続けるよう案内しています。Claude Codeでできることと料金は、Claude Codeとは?の記事を読んでいただくと分かります。
CodexとClaude Code、GitHub Copilotのどれを使うか迷っている方は、次の比較記事で無料で使える範囲と料金を確認できます。

Claude CodeでWordPressのテーマを作る・直すときに、ローカルで作ってから本番に反映する進め方とバックアップの確認は、次の記事で確認できます。

Gitの次は、何を学べばいい?
この記事の8つのコマンドを覚えれば、Codexの変更を確かめて取り消すところまでは自分で対応できるはずです。次の段階は、差分を読んで変更の意味を理解し、自分の判断で採るかどうか決められるようになることです。ブランチで試した結果を本流に取り込む操作(マージ)も、慣れてきたら覚えておきましょう。Pro Git日本語版の「Git のブランチ機能」の章で、ブランチの仕組みから順に解説されています。
Codexを使った制作を、決まった順番に沿って体系的に学びたい方には、スクールという選択肢もあります。例として、DMM 生成AI CAMP 学び放題には、OpenAIのCodexを使ってホームページやアプリを作る「Codexマスターコース」(全36レッスン)があり、料金は月額14,800円(税込16,280円)です。コースの内容や向いている人・向かない人は、DMM 生成AI CAMP 学び放題の解説記事を読んでいただくと分かります。
Codexで作ったサイトを公開したい人へ
Gitで管理しながらCodexで作ったページは、次にどこかへ置いて公開する段階に進めます。無料の置き場所とレンタルサーバーの違いや、公開までの手順をまとめたのが次の記事です。

参考にした公式資料
- OpenAI:Agent approvals & security(Codexの承認とサンドボックス、バージョン管理の推奨)
- OpenAI:Code review(デスクトップアプリのレビュー画面)
- OpenAI:Developer commands(Codex CLIのコマンドとスラッシュコマンド)
- Pro Git日本語版:Git リポジトリの取得
- Pro Git日本語版:変更内容のリポジトリへの記録
- Pro Git日本語版:作業のやり直し
- Pro Git日本語版:ブランチとは
- Git公式:git-restore、git-revert、git-switch、git-clean
- Anthropic:Claude Code Checkpointing
