AIにサイト修正を頼むときは「一度に一つ」――変更範囲と戻し方を先に決める

AIと話しながら、Webサイトの文章や見せ方を直していく。自社サイトの改善でも、「ここを分かりやすくしたい」という言葉から作業を進められる場面が増えました。

僕は音楽制作やギターの仕事をしながら、授業や会社の仕事もしています。コードを最初から全部書けなくても、やりたいことを言葉にして試せるのは面白いです。ただ、既に使っているサイトを直すときは、作れる速さと同じくらい、どこを変え、何を残すかが大切だと感じます。

今回は、完成後の確認より一つ前の話です。AIへサイト修正を頼む前に、変更範囲と戻し方を決める工夫を整理します。

「いい感じに」の前に、今回変える一つを決める

例えば、相談ボタンの言葉を分かりやすくしたい場合。「サイト全体をいい感じにして」と頼むと、文章、色、配置など、直す対象が広がります。出来上がりを見ても、どの変更が良かったのか判断しにくくなります。

まずは「相談ボタンの文言だけ」と、今回の対象を一つに絞ります。リンク先やフォームの送信処理は別の変更として扱う。小さく分けると、自分が決めることも、AIへ任せることも具体的になります。

これは説明用の例です。このボタン変更を実施して効果を測定した、という成功事例ではありません。

文章を直すなら、元の本文を残す。リンクを変えるなら、変更前のリンク先を控える。コードや仕組みを直すなら、使っている環境に合った履歴やバックアップを確認する。残すものは、変更内容によって違います。

画面のスクリーンショットは、見た目を比べる資料になります。ただし、それだけでサイトの仕組みまで元に戻せるわけではありません。

WordPressの公式バックアップ資料でも、通常のサイトを完全に復元するにはデータベースとファイルの両方が必要だと説明されています。本文のコピー、画面の記録、サイト全体のバックアップは、それぞれ役割が違います。

バックアップについては「ある」だけでなく、いつのものか、何が含まれるか、どう戻すかまで確認しておきます。作業記録にログイン情報や顧客情報が入る場合は、そのまま公開用の資料に使わないようにします。

先ほどのボタンなら、例えば次のように頼めます。

このページの相談ボタンの文言だけを、相談内容が伝わる表現に変える案を出してください。リンク先、送信処理、料金、他のページは変更しないでください。現在の文言と変更案を並べ、確認できていない点も教えてください。まずは案の作成までお願いします。

案が決まったら、適用する範囲をもう一度伝えます。試作できることと、公開中のページへ反映してよいことも分けます。これは特定製品の操作手順ではなく、依頼を整理するための例です。

Google Cloudのバイブコーディング解説は、目的を伝え、生成し、実行して確かめ、直す流れを紹介しています。その繰り返しを、既存サイトでも自分が判断できる大きさにする、という考え方です。

一つ直したら、変更前と比べて読む。意図した場所だけが変わったか、リンク先は合っているか、普段使う端末で読みやすいかを見る。その結果を受けて、次に直す場所を決めます。

「文字を大きくしたら読みやすくなった。でもボタンが画面からはみ出した」という場合も、一度に多くを変えていなければ、原因を整理しやすくなります。表示が良くなったことから、問い合わせ数などの成果まで自動的に証明できるわけではありません。目的に応じて、別の確認が必要です。

保存・表示・実際に使える状態の区別は、AIに頼んだ仕事の完了を確認する記事でも整理しています。今回は、その確認をしやすくするために、変更自体を小さくする話です。

思ったとおりにならなければ、戻す判断も必要です。ただし、サイト全体を過去のバックアップへ戻すと、その後に追加された記事や申し込みなどへ影響する場合があります。何でも一括で戻せば安心、とは考えないようにしたいです。

戻す対象、残すべき新しいデータ、作業の影響を整理し、分からなければ管理者や制作担当者へ確認する。元に戻す操作も、一つの変更として扱います。

「ここだけ分かりやすくしたい」を、実際に試せる依頼にする。バイブコーディングやAIエージェントを仕事へ取り入れる入口は、そういう小さな改善からでもよいと思います。

リブトゥウィンでは、やりたいことの整理から、小さなWebサイトや仕事の仕組みづくり、使い方の相談を受けています。

情報確認日：2026年11月4日。本文のボタン修正は説明用の架空例です。特定の変更による成果、全環境での動作や復元を保証するものではありません。公式資料の内容や利用できる機能は、製品・環境・権限によって異なります。