Copicode 日本語トップ

AIエージェントの作業ログ・差分確認・ロールバック術

AIエージェントやCodexにサイト修正を頼むと、短時間で複数のファイルが変わることがあります。便利な一方で、作業ログがない、差分を見ていない、戻し方が決まっていない状態で本番へ反映すると、エラーが出た時に何を戻せばよいか分からなくなります。

この記事では、非エンジニアや小規模サイト運営者向けに、AI作業後のログ、差分確認、公開後確認、ロールバックを1つの流れとして整理します。AIエージェントは万能ではありません。作業後に人間が確認し、問題があれば追加修正を重ねる前に戻せる状態を作ることが大切です。

特に、DB変更、送信、決済、公開設定、.htaccess、canonical、noindex、リダイレクトが絡む時は、AIの判断だけで戻さないでください。まずログ、差分、影響範囲、復旧担当、戻す条件を分けます。

この記事で整理できること

  • AIエージェント作業前後に残すログの項目
  • 差分確認で見るべき追加、削除、危険操作
  • 公開後にURL、表示、フォーム、sitemap.phpを確認する流れ
  • エラーが増えた時に、追加修正より先に戻す判断
  • DB変更が絡む時に自動実行させない判断
  • GitHub PRレビューで見るチェック項目
  • revert率、想定外変更率、承認時間、復旧時間を残すKPI
  • そのまま使える作業ログ表、差分確認表、ロールバック確認表、PRレビュー表、KPI表

作業ログ、差分確認、戻し方を1つの流れにする

AIに作業を頼む前から、戻す時までを1つの流れで見ます。ログがあると、公開後に問題が出ても原因候補を絞りやすくなります。

AIエージェント作業を作業前メモ、AI作業、差分確認、公開確認、ロールバック判断、KPI記録で整理する図解

先に結論

AIエージェントに作業を任せる時は、次の順番で止まりながら進めます。

  1. 作業前に、目的、対象URL、触らないファイル、戻し方をメモする
  2. AI作業後に、変更ファイル一覧を確認する
  3. 差分で、追加行、削除行、秘密情報、危険操作を見る
  4. ローカルまたはテスト環境で確認してから本番へ反映する
  5. 公開後に、URL、スマホ表示、フォーム、内部リンク、sitemap.phpを確認する
  6. 悪化したら追加修正を重ねず、直前の差分とバックアップから戻す
  7. 作業後に、想定外変更、戻した回数、承認までの時間、復旧までの時間を記録する

大事なのは、AIに作業させたことではなく、あとから「何が変わったか」「どこまで戻せるか」を説明できる状態にすることです。

作業ログは報告書ではなく、戻すためのメモ

作業ログというと、きれいな報告書を想像するかもしれません。しかし小規模サイト運営では、まず「問題が出た時に戻せるメモ」で十分です。

ログ項目書く内容なぜ必要か
作業目的 何を直したいか、何を改善したいか AIが余計な範囲まで触らないようにする
対象URL 確認する公開ページや管理外の通常ページ 公開後に同じURLで確認できるようにする
変更ファイル AIが変更したPHP、CSS、JS、画像、設定ファイル 問題が出た時に戻す候補を絞る
触らない範囲 DB、秘密情報、.htaccess、送信処理、削除、公開設定など 危険操作をAIの判断だけで進めない
確認結果 構文、表示、スマホ、フォーム、Search Consoleなど 「直った気がする」で終わらせない
戻し方 バックアップ、Git、FTP、元ファイルの場所 悪化時に追加修正を重ねる前に戻す

AI作業を3つの段階に分ける

AIエージェントの作業は、作業前、作業後、公開後で確認するものが変わります。全部を一度に見ようとすると漏れます。

段階見ること止まる条件
作業前 目的、対象ファイル、触らない範囲、バックアップ 戻し方を説明できない
作業後 変更ファイル、差分、削除行、秘密情報、危険操作 関係ないファイルや危険操作が混ざっている
公開後 公開URL、スマホ表示、フォーム、リンク、sitemap.php、エラー 500、真っ白、フォーム不具合、意図しない表示崩れがある
記録後 想定外変更、戻した回数、承認時間、復旧時間 同じ種類の事故が続いている

すぐ戻すべき条件を先に決める

問題が出てから「戻すか、直すか」を考えると、追加修正を重ねて原因が分かりにくくなります。次の状態になったら、まず直前の差分を止めて、戻す判断をしてください。

症状まずすることAIに任せる範囲
500エラー、PHP真っ白 直前に変えたPHP、include、設定ファイルを戻す候補にする 原因候補と確認順の整理まで
秘密情報が混入した 公開停止、該当差分の削除、キー再発行や影響範囲確認を検討する 混入箇所の特定補助まで。秘密値は貼らない
対象外ファイルが変わった そのファイルの変更理由が説明できるまで反映しない 対象外変更の一覧化まで
送信、決済、DBに影響した 自動復旧せず、ログ、バックアップ、影響範囲を確認する 復旧手順案、確認項目、質問文の作成まで
canonical、noindex、redirectが変わった 検索流入とURL影響を確認し、必要なら直前状態へ戻す 差分説明と確認項目の整理まで

すぐ戻す時もDBは自動で触らない

表示ファイルは戻せても、DBのUPDATE、DELETE、DROP、投稿データ、注文データ、問い合わせ履歴は同じ感覚で戻せません。DBが絡む時は、AIに実行させず、バックアップ、対象テーブル、対象行、復旧担当を確認してください。

作業ログ表テンプレート

AIに作業を頼む前後で、次のログを残します。空欄が多い時は、まだ本番へ反映しない方が安全です。

AIエージェント作業ログ

作業日:
作業者:
使ったAI:
対象サイト:
対象URL:

作業目的:

AIに依頼した内容:

触ってよい範囲:

触らない範囲:
例: config.php / .env / DB / .htaccess / メール送信 / 決済 / canonical / noindex / リダイレクト / 削除

変更されたファイル:
- 

追加された主な内容:

削除された主な内容:

危険操作の有無:
- DB変更:
- DB変更の対象テーブル:
- DB変更の対象件数:
- 削除:
- 送信:
- 決済:
- 公開設定:
- 秘密情報:
- canonical / noindex / redirect:

確認したこと:
- PHP構文:
- ローカル表示:
- スマホ表示:
- フォーム:
- 内部リンク:
- sitemap.php:
- 公開URL:
- GitHub PR / 差分URL:
- 承認者:

問題が出た時の戻し方:

すぐ戻す条件:
- 500 / 真っ白 / 秘密情報混入 / 対象外ファイル変更 / 送信・決済・DB影響

残っている不安:

次にやること:

差分確認表テンプレート

差分確認では、追加された便利そうなコードだけを見ないでください。削除された行、関係ないファイル、秘密情報、公開設定の変更を見ます。

AI作業後の差分確認表

対象作業:
変更ファイル:

1. 変更ファイル一覧
- 想定内:
- 想定外:

2. 追加された内容
- 必要な追加:
- 不明な追加:

3. 削除された内容
- 意図した削除:
- 意図しない削除:

4. 危険な変更
- パスワード、APIキー、DB情報が含まれていない:
- .htaccess全文差し替えがない:
- DB更新、削除、初期化がない:
- DB変更がある場合、対象テーブルと対象件数を説明できる:
- メール送信、決済、本番公開の自動実行がない:
- canonical、noindex、リダイレクト変更がない:
- 対象外ファイルの変更がない:

5. 表示確認
- PC:
- スマホ:
- 対象URL:
- 関連URL:

6. 戻し方
- 変更前ファイルがある:
- Gitやバックアップで戻せる:
- FTPで戻す対象ファイルが分かる:

判断:
- 反映してよい:
- 修正してから反映:
- 反映しない:
- 先に戻す:
- 人間承認待ち:

DB変更が絡む時は別枠で扱う

ファイルの差分とDBの変更は、戻し方が違います。ファイルなら差分やバックアップで戻せることがありますが、本番DBの更新、削除、初期化、注文や問い合わせのデータは、簡単に巻き戻せない場合があります。

DBに関わる作業AIに頼んでよい範囲人間が止まる範囲
SELECTで状態確認 確認用SQL案、見る列、対象条件の整理 本番接続情報、個人情報、実行結果の扱い
UPDATE 事前SELECT、WHERE確認、バックアップ確認リスト 本番実行、対象件数が不明な更新
DELETE / DROP / 初期化 危険性の説明、代替案、復旧手順の確認表 AIによる自動実行、コピペ実行、まとめて削除
問い合わせ、注文、決済ログ 確認項目、伏せ字、サーバー会社へ聞く文面 データ削除、返金、再送信、Webhook再実行

DBが絡む時は、AI SQL安全確認メモメーカーSQLでデータを安全に削除する前の確認 も合わせて使ってください。

GitHub PRレビュー版のチェック欄

GitHubのPull RequestやAI coding agentのPRで確認する場合は、ローカル差分だけでなく、PR上の説明、テスト結果、想定外ファイル、レビュー待ちを残します。

AIエージェント PRレビュー確認表

PR URL:
対象ブランチ:
対象ページ:

変更理由:
-

変更ファイル:
- 想定内:
- 想定外:

差分確認:
- 追加された処理:
- 削除された処理:
- 秘密情報混入:
- DB / 送信 / 決済 / .htaccess / canonical / noindex / redirect:

テスト結果:
- 自動テスト:
- PHP構文:
- ローカル表示:
- 公開前確認:

レビュー判断:
- レビュー待ち:
- 修正依頼:
- mergeしてよい:
- mergeしない:
- 先に戻す:

公開後確認:
- 公開URL:
- スマホ表示:
- フォーム:
- 内部リンク:
- sitemap.php:

戻し方:
- revertするPR:
- 戻すファイル:
- DBは触らない / 別途復旧手順:

戻す前の確認表テンプレート

ロールバックは「全部なかったことにする」ではありません。どの変更で悪化したかを分け、戻す範囲を小さくします。

AI修正を戻す前の確認表

起きた問題:
例: 500エラー / PHP真っ白 / 表示崩れ / フォーム送信不可 / Googleに出ない / リンク切れ

問題が出たURL:

直前に変えたファイル:
- 

変えた時刻:

本番へアップロードしたファイル:
- 

戻す候補:
- 変更前バックアップ:
- Gitの直前コミット:
- FTPで退避したファイル:
- サーバー会社のバックアップ:

戻す前に確認すること:
- どのファイルだけ戻すか:
- DBや投稿データは触らないでよいか:
- DB変更がある場合、対象テーブルと対象件数:
- DBは自動で戻さず、別途復旧手順にするか:
- .htaccessを戻す必要があるか:
- フォームや決済など外部送信への影響はあるか:
- 戻した後に確認するURL:
- すぐ戻す条件に当てはまるか:

AIに追加修正を頼む前の判断:
- まず戻す:
- 原因候補だけ聞く:
- 追加修正してよい:
- 人に確認する:

Codexに差分確認を頼む依頼文

CodexやAI coding agentに差分確認を頼む時は、実行や公開ではなく「確認だけ」を依頼します。

AI作業後の差分確認だけをお願いします。
実行、公開、削除、DB更新、送信、設定変更はしないでください。

確認してほしいこと:
1. 変更ファイル一覧
2. 追加された処理
3. 削除された処理
4. 頼んでいない変更
5. 秘密情報が混ざっていないか
6. .htaccess、DB、メール送信、決済、canonical、noindex、リダイレクトの変更があるか
7. 対象外ファイルの変更があるか
8. GitHub PRなら、レビュー待ち、テスト結果、merge可否
9. 公開前に確認すべきURLと操作
10. 問題が出た時の戻し方
11. 記録すべきKPI

出力は次の形式にしてください。
- 安全そうな変更
- 人間が確認すべき変更
- 反映前に止める変更
- 戻し方
- すぐ戻す条件
- PRレビューで確認すること
- 追加で質問すべきこと

前提が足りない場合は、推測で進めず質問してください。

作業後のKPIを残す

KPIは大げさな分析ではなく、同じ事故を減らすための簡単な記録です。1回ごとのAI作業で、戻したか、想定外変更があったか、承認や復旧にどれくらい時間がかかったかを残します。

KPI見ること悪化のサイン
revert率 AI作業のうち、戻した作業の割合 同じ種類の作業で戻しが続く
想定外変更率 頼んでいないファイルや設定が変わった割合 AGENTS.mdや依頼文の範囲指定が弱い
承認までの時間 AI出力から人間が採用判断するまでの時間 確認項目が多すぎる、危険変更が混ざる
復旧までの時間 問題発生から通常状態へ戻るまでの時間 戻し方、バックアップ、担当者が決まっていない
AIエージェント運用KPIメモ

期間:
作業件数:

revert率:
- 戻した作業数:
- 全作業数:
- 割合:
- 主な理由:

想定外変更率:
- 想定外ファイル変更:
- 想定外設定変更:
- 全作業数:
- 割合:
- 防止策:

承認までの時間:
- 平均:
- 最長:
- 承認が遅れた理由:

復旧までの時間:
- 問題件数:
- 平均復旧時間:
- 最長復旧時間:
- 次回の改善:

次に直すルール:
- AGENTS.md:
- 依頼文:
- チェックリスト:
- バックアップ:
- 人間承認:

Gitがある時に見る安全な確認コマンド

Gitを使っている場合は、戻す前に状態と差分を見ます。ここでは確認用のコマンドだけを扱います。意味が分からないまま、変更を消すコマンドを実行しないでください。

git status
git diff --stat
git diff
git log --oneline -5

git reset --hard のように未保存の変更を消す可能性がある操作は、最初の選択肢にしないでください。必要な時でも、どの変更が消えるかを確認し、バックアップを取ってから判断します。

FTPだけで運用している時の戻し方

Gitを使っていないサイトでも、戻し方は作れます。最低限、変更前ファイルを別名で保存し、アップロードしたファイル名と時刻をメモします。

公開前のチェックは、AIに直してもらったコードをアップロードする前の確認チェックリスト も合わせて使えます。

公開後に見る確認項目

公開後は「エラーが出ていないか」だけでなく、読者が普通に使えるかを見ます。

確認項目見る場所問題があった時
公開URL 対象ページを通常ブラウザで開く 404、500、真っ白なら追加修正前に差分を見る
スマホ表示 見出し、表、ボタン、画像 CSS差分やHTML構造を確認する
フォーム 入力、確認、送信、メール受信 送信処理や宛先の差分を見る
内部リンク 次に読む記事、ハブ、サイトマップ 存在しないURLや古いURLを直す
sitemap.php 重要ページが出ているか カテゴリコメント、page_title、登録状態を確認する
Search Console URL検査、canonical、noindex 待つ状態か、技術修正が必要かを分ける
作業KPI 戻した回数、想定外変更、承認時間、復旧時間 同じ失敗が続くなら、依頼文や権限を見直す

戻す時に避けること

追加修正を重ねる前に止まる

  • 原因が分からないまま、AIに何度も上書き修正を頼む
  • 関係ないファイルまでまとめて戻す
  • DBや投稿データまで触ってしまう
  • PRをレビューせずにmergeする
  • revert率や想定外変更率を記録せず、同じ依頼を繰り返す
  • バックアップ元と本番ファイルを取り違える
  • エラーが出たURLを確認せず、別ページだけ見て直ったと判断する

悪化した時の具体的な戻し方は、AI回答でエラーが増えた時の戻し方AI修正ロールバックメモメーカー も確認してください。

次に読む記事

作業ログ、差分、戻し方は、AIコード安全確認、Git、アップロード前後の確認とつながっています。

まずは作業ログだけ作る

AIエージェント運用を安全にしたい時は、最初から高度な自動化を作る必要はありません。まずは、1回の作業ごとに作業ログ、差分確認表、戻す前の確認表を残すだけで十分です。慣れてきたら、PRレビュー表とKPIメモも追加します。ログが残れば、次にAIへ頼む時も、何を任せてよいか、どこで人間が止まるべきかを判断しやすくなります。