AIにサイトを直してもらうとき、一番困るのはコードを書けないことではありません。「いま本番に出ている最新版はどれか」が分からなくなることです。

PCで少し修正し、別の日にCodexへ続きを頼み、スマホから管理画面も触る。こうなると、変更そのものより、複数の場所にある状態を合わせる作業の方が難しくなります。

そこで私は、コードの正本をGitHubに固定する運用が分かりやすいと考えています。AIはGitHubの最新版を読み、そこへ変更を戻す。人間も同じ場所を基準にする。この一本化だけで、「昨日のチャットで直したはずなのに戻っている」といった事故をかなり減らせます。

作業を始める前に、会話ではなくGitHubを読む

AIとの会話には、以前の設計や修正内容が残っています。ただし、それを最新版のコードだと思ってはいけません。

会話のあとに別の端末から変更したかもしれないし、別のAIが先にコミットしたかもしれない。デプロイに失敗して、途中の差分だけ残っている場合もあります。

だから、編集を始めるときの最初の手順を固定します。

「GitHub上の対象ブランチを確認し、現在のファイルを読んでから変更する」。

これを毎回守るだけで、AIが古いコードを前提にファイル全体を書き戻す危険が減ります。特に、レイアウトや設定ファイルのように他の変更とぶつかりやすい場所ほど、編集前の確認が重要です。

一回の依頼でサイト全体を触らせない

AIは、指示した範囲が広いほど「ついでに直しておく」変更を増やしやすくなります。トップページの余白を直したかっただけなのに、共通CSSまで整理され、別ページの見た目まで変わる。個人開発ではよく起きるパターンです。

作業は、目的ごとに小さく分けた方が追いやすくなります。

たとえば「記事カードの高さをそろえる」「検索欄の挙動を直す」「AIカテゴリの記事ページを作り込む」は別の変更として扱います。コミットも同じ単位にしておけば、あとから問題が起きたときに戻す範囲が明確です。

小さく分けるのは慎重すぎる運用ではありません。AIを速く使うための準備です。失敗したときに一つ前へ戻れるなら、変更そのものは大胆に試せます。

「動いた」と「本番に出た」は別なので、最後まで確認する

ローカルで表示できても、本番サイトで同じように動くとは限りません。ビルド環境、環境変数、ルーティング、キャッシュなど、公開時にだけ表面化する問題があります。

GitHubへのコミットを自動デプロイにつないでいる場合は、流れを最後まで一つの作業として扱います。

コードを変更する。ビルドが通る。本番へ反映される。実際のURLを開いて確認する。ここまで終わって、ようやく「修正できた」と言えます。

逆に、GitHubへ書き込んだだけで完了扱いにすると、本番では壊れたままということが起こります。AIへ実装を頼むときも、「ファイルを変更する」ではなく「公開後の表示まで確認する」を完了条件にしておく方が安全です。

mainを正本にするなら、別経路の編集も最後はmainへ戻す

管理画面からデザインを変えられるようにすると、運用は少し複雑になります。

管理画面の設定がデータベースだけに保存され、GitHubには古い値が残る。すると次にAIがGitHubを読んで修正したとき、管理画面の変更を知らずに上書きする可能性があります。

この問題を避けるには、「何を正本にするか」を項目ごとに決めます。

コードや固定レイアウトはGitHub。記事本文もGitHubのMarkdown。ユーザーが頻繁に変える設定だけ別の保存先に置く、といった分け方です。もし管理画面からコード相当の設定を変更するなら、その変更が最終的にGitHubへ戻る仕組みにすると一本化できます。

大事なのは、すべてをGitHubに置くことではありません。同じ種類の情報に正本を二つ作らないことです。

TOFU BASEでは、管理画面の変更も同じ場所へ戻す

このサイトでは、管理画面から変えるデザイン設定もGitHubに保存します。文章や設定を会話の履歴から復元しなくても、次の作業者が同じファイルを読めるようにするためです。

変更するもの正本変更後の確認
ページと共通パーツリポジトリの src/pages と src/components関係するページの表示と操作
記事本文src/content/articles のMarkdown本文・見出し・目次・公開日
GUIのデザイン設定src/data/design-settings.jsonプレビューと公開後の表示が一致するか
デザインの判断理由DESIGN.md実装と説明が食い違っていないか

管理画面で「公開」を押すと、まずGitHubへの保存が行われます。そのあとCloudflare Pagesがビルドし、成功した成果物が配信されます。保存成功は、配信の完了とは別です。

確認は三段階に分けると混同しません。手元のビルドでページを生成できるか、Cloudflare側で対象コミットのデプロイが成功したか、最後に公開URLが新しい内容を返すか。途中で止まったら、どこまでは終わっているかを残します。

AGENTS.mdには「次のAIが迷うこと」を書く

コードだけを見ても分からないルールがあります。

たとえば、mainへの変更が自動で本番へ出ること。特定のデザインを残したいこと。記事はどのディレクトリに追加するか。画像はどこへ置くか。サイトの記事を書くときに参考にする文体ルール。こうした情報は、次の作業者が知らなければ簡単に壊れます。

そのため、リポジトリにはAI向けの運用ルールを残しておきます。AGENTS.mdのようなファイルに、毎回守ってほしい前提を短く書きます。

ここで長大なマニュアルを作る必要はありません。むしろ「正本はmain」「編集前に最新版を読む」「既存URLを壊さない」「記事はこの文体方針で書く」のように、判断を変えるルールだけを残した方が使われます。

差分が大きいときは、見た目より先に変更範囲を確認する

AIが出した結果がきれいでも、意図しないファイルまで変わっていれば、その変更はまだ安心して採用できません。

特にサイトの大規模なデザイン変更では、共通スタイル、レイアウト、記事ページ、設定ファイルが一度に変わることがあります。まず「どのファイルを変えたか」を確認し、そのあとに表示を見る方が原因を追いやすくなります。

変更範囲が説明できない状態で本番へ出すと、数日後に別ページで崩れを見つけたとき、どの修正が原因か分からなくなります。

戻せる状態を作ると、AIに大胆な変更を頼みやすい

AI開発で慎重になりすぎる原因の一つは、「壊したら元に戻せないかもしれない」という不安です。

GitHubでコミットが残っていれば、以前の状態との差分を確認できます。目的ごとにコミットを分けていれば、問題のある変更だけを戻すこともできます。

つまり、GitHubは保存場所であると同時に、AIへ試行錯誤を任せるための安全装置でもあります。

私は、AIを使うほど履歴を残す価値が上がると思っています。人間だけで開発しているときより変更速度が速いからこそ、「どこからどこまでを誰が変えたか」が分かる状態にしておく必要があります。

実際の運用は、この5段階で十分

普段のサイト更新なら、複雑なフローにしなくても次の順番で回せます。

  1. GitHubの最新版と運用ルールを読む
  2. 今回触る範囲を決める
  3. 変更し、必要なチェックを行う
  4. 意図が分かる単位でGitHubへ反映する
  5. デプロイ後の本番URLを確認する

この流れを毎回守ると、チャットが変わっても、使うAIが変わっても、同じ場所から作業を再開できます。

AIを正本にしない。ローカルPCも正本にしない。コードの現在地はGitHubに置き、AIはそこを読んで働く。この役割分担が、AIと長くサイトを育てるときの土台になります。