Codex の変更を元に戻す方法と注意点

Codex の変更を元に戻す方法と注意点

OpenAI Codex は自然言語の指示でファイルを読み書きする AI コーディングエージェントで、v0.142 系の安定版以降は複数タスクを並行して走らせる使い方も広がっている。任せられる作業が増えるほど避けて通れないのが「思った通りに直してくれなかったとき、どうやって元に戻すか」という問題だ。Codex の変更はあなたのワーキングツリーに直接反映されるため、取り消しの考え方を先に押さえておけば、意図しない編集に出くわしても落ち着いて巻き戻せる。本記事では、変更を防ぐ設定と、適用後に取り消す具体的な手順を順に整理する。

結論powered by Claude

Codex が加えた変更を元に戻す経路は、大きく「適用前に止める」と「適用後に取り消す」の 2 つに分かれる。適用前で言えば、Codex CLI は編集やコマンド実行の前に差分を提示して承認を求める仕組みを持ち、承認モードとサンドボックスの設定次第で、勝手に書き換えられる範囲を最初から制限できる。つまり「戻す」より前に「そもそも適用させない」選択肢があることを知っておくと安全だ。

すでにファイルへ反映されてしまった変更については、git による取り消しが最も確実な復旧手段になる。Codex は変更をワーキングツリーに残すため、`git status` と `git diff` で範囲を把握し、未コミットなら `git restore`、コミット済みなら `git revert` などで戻せる。OpenAI 自身も Codex をバージョン管理されたリポジトリ上で使うことを前提に案内しており、git が事実上の安全網となる。

運用面では、戻せる状態を保つ設計が要になる。作業前にコミットして区切りを作る、重要な変更には承認を挟む、サンドボックスで書き込み範囲を絞るといった備えをしておけば、Codex に大きな差分を任せても被害を局所化できる。本記事では予防と取り消しの両輪を、実際のコマンドと合わせて具体的に示す。

目次 (10)

Codex の変更はどこに適用されるのか — 元に戻す前提を押さえる

Codex を「元に戻す」前に、変更がどこに、どのように反映されるのかを理解しておく必要がある。Codex CLI は対話セッションのなかで、依頼に応じてファイルの編集案(差分)を作り、それをあなたのプロジェクトのワーキングツリーへ適用する。チャットの履歴だけが書き換わるのではなく、実際のソースファイルそのものが更新される点が、エディタ上の操作と決定的に違うところだ。つまり Codex の出力を取り消すという行為は、文章を消すことではなく、ファイルシステム上の変更を巻き戻すことを意味する。

ここで効いてくるのがバージョン管理だ。OpenAI は Codex を git で管理されたリポジトリ上で使うことを基本に据えており、変更の確認やレビューを git の差分として扱う前提で設計されている(出典: OpenAI Codex ドキュメント)。Codex が編集を適用しても、コミットしない限りそれは「未コミットの変更」としてワーキングツリーに留まる。この性質こそが取り消しを容易にする鍵で、git の履歴とワーキングツリーの状態を押さえておけば、どの段階の変更でも対応する戻し方を選べるようになる。逆に言えば、git の外で Codex を使うと安全網が一枚なくなるため、リポジトリ内で使うことを強く勧めたい。

変更を防ぐ:承認モードとサンドボックスで適用前に止める

最も確実な「元に戻す」は、そもそも望まない変更を適用させないことだ。Codex CLI には、編集やコマンド実行の前に内容を提示して承認を求める仕組みがあり、ここで拒否すれば変更はワーキングツリーに反映されない。差分が画面に出た段階で意図と違うと感じたら、承認せずに却下し、指示を出し直すのが最初の防衛線になる。取り消しに手間をかけるより、適用前に止めるほうが速くて安全な場面は多い。

この挙動は承認モードとサンドボックスの設定で調整できる。承認に関わる方針は ~/.codex/config.toml の設定や起動時のオプションで指定でき、読み取り中心で動かすか、ワークスペース内の書き込みまで許すか、といった範囲を選べる。サンドボックスを読み取り専用や作業ディレクトリ内に限定する設定にしておけば、Codex が触れられる範囲そのものが絞られ、想定外のファイルが書き換わる事故を構造的に防げる。設定値の正確な名前や既定の挙動は更新されることがあるため、運用前に OpenAI Codex ドキュメント で最新の承認・サンドボックス設定を確認しておくとよい。重要なリポジトリでは、まず承認を挟む構成から始め、慣れてから書き込みの自由度を上げていく進め方が現実的だ。

適用済みの変更を元に戻す具体的な手順

承認を通してしまった、あるいは承認を省く設定で動かしていて、変更がすでにファイルへ反映されている——このときの主役は git だ。Codex の変更は基本的にワーキングツリーに残るため、git の標準的な取り消し操作でそのまま巻き戻せる。以下では未コミットの段階からコミット済みの段階まで、状況に応じた手順を順に示す。作業に入る前に必ず変更範囲を確認し、戻しすぎを避けるのが安全な進め方になる。

Step 1: git status / git diff で変更範囲を確認する

まず何が変わったのかを把握する。git status で変更・追加されたファイルの一覧を確認し、git diff で具体的な差分を読む。Codex が複数ファイルにまたがる変更を行っている場合もあるため、戻す前に全体像をつかんでおくと、必要な変更まで巻き戻してしまう事故を防げる。意図した変更と意図しない変更が混在しているなら、この段階でどのファイルを戻すかを決めておく。

Step 2: 未コミットの変更を git restore で戻す

まだコミットしていない変更なら、git restore <ファイル> で対象ファイルを直近のコミット時点の状態へ戻せる。すべての変更をまとめて破棄したい場合は git restore . を使う。Codex が新規に作成したファイルは追跡対象外(untracked)として残るため、git clean -n で削除対象を確認したうえで git clean -f を実行すると、生成された不要なファイルも取り除ける。git clean は復元できない削除になるので、必ず先にドライランの -n で対象を確かめてから実行する。

Step 3: コミット済みなら git revert / git reset を使い分ける

Codex にコミットまで任せていた場合は、コミット単位で戻す。共有ブランチなど履歴を保ちたい場面では git revert <コミット> を使い、打ち消すための新しいコミットを積む形で安全に取り消す。手元のまだ共有していない作業であれば、git reset --hard <戻したいコミット> で履歴ごと巻き戻す方法もあるが、これはワーキングツリーの変更も消えるため影響範囲を確認してから実行する。どちらを使うかは「履歴を残して打ち消すか、なかったことにするか」で判断すると整理しやすい。

セッション内の操作を取り消す・やり直す

ファイルへの適用とは別に、Codex とのやり取りそのものを軌道修正したい場面もある。たとえば、与えた指示が曖昧で見当違いの差分が提案されたときは、その差分を承認せずに却下し、条件を補って指示し直すのが基本だ。Codex は直前の文脈を踏まえて応答するため、「さっきの変更は破棄して、代わりにこうしてほしい」と明示すれば、方針を切り替えて作り直してくれる。差分を適用する前にこの軌道修正を挟めば、git に頼らずともワーキングツリーを汚さずに済む。

すでにいくつかの編集が積み重なって状況が分かりにくくなったときは、いったんセッションを区切り、git でワーキングツリーをきれいな状態へ戻してから新しい指示を始めるのが堅実だ。中途半端な差分が残ったまま追加の依頼を重ねると、Codex が現状を正しく把握できず、戻すべき範囲も曖昧になる。「一区切りごとに git の状態を整える」というリズムを持っておくと、セッション内の試行錯誤と、確定した変更の管理を分けて扱えるようになる。Codex CLI のバージョンによって利用できる操作は更新されるため、手元のクライアントで使えるコマンドは OpenAI Codex ドキュメント で確認しておくとよい。

元に戻せない事態を避ける運用のコツ

取り消しの手順を知っておくことと同じくらい、「いつでも戻せる状態を保つ」備えが重要になる。最大のコツは、Codex に大きな作業を任せる前にコミットして区切りを作っておくことだ。クリーンなコミットがあれば、その後 Codex がどれだけ編集しても git restoregit reset で確実にその地点へ戻せる。逆に、長時間の作業を一度もコミットせずに進めると、戻したい地点が定まらず、必要な変更まで巻き込んで失う危険が高まる。

あわせて、前述の承認モードとサンドボックスを状況に応じて使い分けたい。慣れない大規模リファクタリングや、影響範囲の読みにくい変更を任せるときほど、承認を挟む構成にして差分を一つずつ確認するのが安全だ。Codex CLI は 2026 年 6 月の v0.142 系で安定版となり、並行してタスクを動かす使い方も現実的になっている(出典: openai/codex リリース)。複数の変更が同時並行で進むほど、どの変更がどのコミットに対応するのかを見失いやすくなるため、こまめにコミットして区切ること、書き込み範囲をサンドボックスで絞ること、重要な操作には承認を挟むことの 3 点を習慣にしておくと、万一の取り消しも局所的な巻き戻しで済む。

まとめ

Codex の変更を元に戻す要点は、「適用前に止める」と「適用後に取り消す」を分けて考えることだ。適用前なら、承認モードで差分を確認して却下する、サンドボックスで書き込み範囲を絞る、といった設定でそもそも望まない変更を防げる。すでにファイルへ反映された変更については、git statusgit diff で範囲を確認し、未コミットなら git restore、新規ファイルなら git clean、コミット済みなら git revertgit reset を状況に応じて使い分ければ確実に戻せる。

Codex はワーキングツリーへ直接編集を適用するからこそ、git によるバージョン管理がそのまま安全網になる。作業前にコミットして区切りを作り、重要な変更には承認を挟み、書き込み範囲をサンドボックスで制限しておけば、エージェントに大きな差分を任せても被害を局所化できる。元に戻す手順を理解したうえで「戻せる状態を保つ」運用を組み合わせることが、Codex を安心して使い込むための現実的な土台になる。設定や利用できる操作は更新が続くため、最終的な挙動は OpenAI Codex 公式 で確認してほしい。

出典

参考になったら ♡
Codexer Navi 編集部
@codexer_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。