Codexの変更を確認して戻す：差分・保存・やり直しの基本

Codexに文章や設定ファイルを直してもらったあと、「どこが変わったのか」「一部だけ戻せるのか」で迷うことがあります。まず変更内容を読み、残す変更と戻す変更を分けると、やり直しの範囲を小さくできます。

この記事では、Windowsでローカルの作業フォルダーを使う場面を中心に、差分の読み方、Codexへの確認依頼、Gitで管理したファイルの戻し方を整理します。導入がまだの場合はWindowsでCodexを始める手順から進めてください。

最初に「何を元に戻すか」を決める

同じ「戻す」でも、目的によって扱うものが違います。

Gitのコミットはファイルの変更履歴を記録する操作です。コミットしただけでサイトが更新されるとは限りません。反対に、公開まで続ける設定がある環境では、その後の処理も確認が必要です。

作業前の状態を残す依頼例

このフォルダーの guide.md を読みやすく直してください。
変更前にGitの状態を確認し、すでにある編集を区別してください。
Gitで管理していない場合は、変更前のファイルを別名で残してください。
今回は本文の見出しと段落だけを変更し、公開・送信は行わないでください。
終わったら変更した箇所と、意味が変わっていないかを報告してください。

すでにある編集を記録せずに作業を始めると、後から「今回の変更だけ」を分けにくくなります。依頼文の組み立て方も合わせて使うと、対象を絞れます。

Codexのレビュー画面で変更を読む

公式資料では、アプリのレビュー画面はGitリポジトリ内のプロジェクトを対象にしています。表示にはCodexの編集だけでなく、自分の編集やほかの未コミット変更も含まれます。表示対象にはUnstaged、Staged、Branch、Last turnなどがあり、直前の応答による変更を見たいときはLast turnが選択肢になります。OpenAI公式のレビュー説明

確認の順番を図にすると、対象・中身・結果の3段階です。

差分を開いたら、次の順で確認します。

1. ファイル名：頼んだファイル以外が含まれていないか。
2. 削除された内容：必要な手順・注意書き・リンクまで消えていないか。
3. 追加された内容：未確認の料金や機能、意味の違う説明が加わっていないか。
4. 変更後の表示：Markdownの見出し、箇条書き、リンクが意図どおりか。

たとえば「重複する表現を減らす」という依頼で、注意事項の段落まで削除されていれば、文章が短くなっていても目的を満たしていません。読みやすさと情報の保持を別々に点検します。

修正せずに点検だけ頼む

いまはファイルを変更せず、今回の差分だけを確認してください。
対象は guide.md です。
削除された重要情報、意味が変わった箇所、リンク切れの可能性を挙げてください。
問題がなければ、何を確認したかを簡潔に報告してください。

Gitプロジェクトでは/reviewから未コミット変更などの範囲を選んでレビューする方法も案内されています。指摘が出た場合は、直す対象を決めてから修正を依頼します。レビュー結果だけで正確さが保証されるわけではなく、記事なら参照元、プログラムなら適切なテストでも確かめます。OpenAI公式資料

ターミナルで差分を確かめる基本コマンド

以下はGitで管理されているフォルダー内で使います。ターミナルの場所が分からない場合は、先にCodexへ「この作業フォルダーがGit管理されているか、変更せずに確認して」と依頼してください。

git status --short
git diff -- guide.md
git diff --cached -- guide.md

ステージは「次のコミットへ入れる内容を選んだ状態」です。同じファイルでも、その後さらに編集すればステージ済み・未ステージの両方に差分ができます。また、新規で未追跡のファイルは通常のgit diffだけでは本文が表示されません。git statusで??が付いたファイルを見つけたら、そのファイル自体を開いて確認します。git status、git diff

--の後ろは対象ファイル名です。例のguide.mdを実際のファイルに置き換えます。読み取りコマンドで範囲を確かめてから、戻す操作へ進みましょう。

一部だけ戻すときの依頼例

最初から「全部戻して」と頼むより、残したい変更も指定します。

guide.md の「準備」節に追加した説明だけを取り消してください。
「使い方」節の見出し変更は残してください。
私が作業前から編集していた箇所は変更しないでください。
戻す対象を差分で確認し、区別できない箇所があれば実行前に知らせてください。
修正後は残った差分とリンクを確認してください。

アプリにもファイルや変更のまとまり単位でステージ・取り消しを行う操作があります。ただし、対象に残したい編集が含まれていないかを先に読みます。画面の「全体を戻す」操作は、小さな修正の代わりに選ぶものではありません。

git restoreを使う前に知ること

git restore -- guide.md

このコマンドは、指定した追跡済みファイルの作業中の内容を、標準ではステージの内容に戻します。そのファイルの未ステージ変更が失われます。 作業前のコピーや、残したい変更の退避ができているときだけ使います。「Codexが追加した部分だけ」を自動的に判別するコマンドではありません。git restore公式資料

git restore --staged -- guide.md

こちらは通常、ステージを直前のコミットに戻し、作業中のファイルの内容はそのまま残します。ファイルの編集を消す操作とは区別してください。意図が分からない場合は実行せず、Codexに現在の状態とコマンドの対象を説明させます。

コミット後・公開後は別の確認が必要

すでにコミットした変更を打ち消す場合、git revertは対象コミットを打ち消す変更を新しいコミットとして記録する方法です。対象の選択や競合対応が必要になるため、初心者が履歴全体を戻すコマンドを試す前に、どの変更を取り消すかを整理してください。git revert公式資料

さらに、記事を公開した後は手元のファイルを戻すだけでは十分ではありません。公開に使う仕組みで修正版を反映し、実際のURLを開いて本文・画像・リンクを確認します。メール送信や外部サービスへの書き込みは、Gitの復元では取り消せません。

ブログで続ける場合は、原稿・確認・公開を一つの作業場所で管理する方法に沿って、変更前の控え、公開したURL、確認結果を一緒に残すと、次回も判断しやすくなります。

最後の確認リスト

• 頼んだファイルと実際の変更ファイルが一致している。
• 残す変更と戻す変更を区別した。
• 戻す前の内容を必要に応じて退避した。
• 修正後の差分だけでなく、表示とリンクも確認した。
• 手元で修正済みか、公開先まで反映済みかを区別した。

確認日：2026年9月11日。アプリの操作説明は同日の公式資料に基づきます。Git 2.53.0.windows.1の検証用フォルダーで、差分・未追跡ファイルの表示とrestoreの対象を確認しました。アプリ画面の全操作や外部サービスの復旧まで検証したものではありません。

権限の確認で迷ったら、対象フォルダー・変更・外部送信を分けて判断する方法を確認してください。

確認が途中で終わる場合は、作業の再開と引き継ぎメモの形で、確認済み・未確認・次の一手を残しておくと、同じ変更を重複して調べずに続きを始められます。