AIで作ったサイトを直したい｜よくある失敗と修正を頼む前の整理
AIで作ったサイトも、使ったサービスや編集データ、必要な権限を確認できれば、今あるものを生かして修正を相談できます。
表示が崩れる、文章が自社に合わない、フォームが動かないときは、まず「どのページで何が起きているか」を分けます。
相談前に技術的な原因を言い当てる必要はありません。
ただし、公開URLや画面の画像だけでは、元のサイトを編集して再公開できるとは限りません。
使ったAI制作サービス、編集画面に残る元データや受け取ったファイル、誰が管理しているかを、分かる範囲で確かめます。
原因になりうる場所は、AIへ入力した情報、選んだテンプレート（ひな型）、公開後の設定、外部サービスとの接続などさまざまです。
この記事では、症状の記録を作り、文章・画像、デザイン・操作、コード・仕組みのどこまで直すかと、依頼先へ渡すものを整理します。
目次
1. 直したい理由を症状で書き出す
修正を始める前に、気になることを「症状」として書き出します。
ただし、個人情報の漏えいや不正な決済が疑われる場合は、記録をそろえるのを待たず、管理者や専門の技術者へ連絡して被害の拡大を止める対応を優先します。
「何となく変」「AIっぽい」「使いにくい」だけでは、修正を担当する人が同じ問題を画面上で再現できません。
技術的な原因や直し方まで自分で決めなくても、記録は書けます。
1件ずつ同じ形で記録する
気になった問題は、次の項目にそって1件ずつまとめると伝わりやすくなります。
- 対象ページ：
ページの名前とURL - 場所：
見出し、画像、ボタン、フォームなど、画面のどこで起きているか - 確認環境：
使った端末（スマートフォンかパソコン）、OS、ブラウザの種類 - 操作：
問題が起きるまでに、どこを押して何をしたか - 現在の状態：
実際に表示されている内容や、動いている状態 - 希望する状態：
どうなれば修正が終わったと判断できるか - 影響：
誰が、どの場面で困るのか - 記録：
個人情報を消したスクリーンショットや画面録画
たとえば「スマホでボタンが変です」と伝えるより、次のように書いた方が状況は伝わります。
記録例：トップページをスマートフォンで開くと、料金案内のボタンが画面の外へはみ出し、右側の文字を読めません。ボタン全体が画面内に収まり、文章を読んで押せる状態を希望します。
一つの記録に文章、画像、フォーム、色など複数の問題を詰め込まず、場所や症状ごとに分けて書きます。
症状ごとに分けておけば、修正後も同じ端末と同じ手順で結果を確かめられます。
「直したつもり」で終わることを防げます。
そのまま使える不具合記録
制作会社や技術者へ渡すときは、次の形をコピーして1件ずつ記入します。
対象ページ:
URL:
確認日時:
端末・OS:
ブラウザ:
問題が起きる場所:
再現する手順:
現在の状態:
希望する状態:
困る人・影響:
スクリーンショットや動画:
修正完了と判断する条件:スクリーンショットや動画を添えるときは、「共有用の画像・動画に、顧客情報やパスワードが残っていないことを確認した」のように、確かめた結果もメモに書き添えます。
共有する前の見落としを減らせます。
修正完了の条件は、「きれいにする」ではなく、「スマートフォンでボタン全体が表示され、文章を読んで押せる」のように、あとから確かめられる形で書きます。
秘密情報を記録へ含めない
スクリーンショットや修正資料には、問い合わせ内容、顧客情報、管理画面のURL、パスワード、APIキー（外部サービスとつなぐための合い言葉）などが写り込むことがあります。
外部へ渡す前に、社内の共有ルールや守秘義務、渡す相手を確かめ、必要のない情報は隠すか削除します。
サイトへログインしての確認を依頼するとき、普段使っている管理者アカウントをそのまま渡すと、見せなくていい場所まで開いてしまいます。
サービスが対応していれば、必要な権限だけを付けた個別の招待や作業用アカウントで、渡す範囲を絞れます。
使う期間も先に決め、作業が終わったら不要なアカウントや権限を削除・無効化します。
どの情報を渡せばいいか分からないときは、先に依頼先へ聞くのが早いです。
求められていない秘密情報は送りません。
すでにAPIキーなどが外へ漏れた場合は、画像から隠すだけで済ませず、管理者と連携してキーの無効化と再発行を進めます。
権限を必要な範囲に絞ることや、漏れたキーの無効化・再発行は、OWASPの秘密情報管理ガイドでも扱われています（2026年10月30日確認）。
2. 文章・画像の問題を分ける
文章と画像は、管理画面に編集機能があり、使い方と戻し方が分かれば、自分で直す候補になります。
ただし、見た目を整えるより先に見るのは、間違っていると読者に迷惑がかかる情報です。
文章は事実、伝わり方、表現の強さを見る
まずは、社内で正しいと確かめられる料金表、会社概要、サービス資料と、サイトの記載を照らし合わせます。
先に確かめる項目は、次のとおりです。
- 会社名、住所、電話番号、営業時間
- サービス内容、対象者、対応地域
- 料金、追加料金、納期、支払条件
- 資格、実績、受賞歴、導入件数
- 問い合わせた後の流れと、返信までの目安
- キャンセル、返品、利用条件
AIは自然な文章を作りますが、こちらが入力していない条件を勝手に補ったり、ひな型の見本用の数字や社名をそのまま残したりすることがあります。
「地域で一番」「必ず成果が出る」「誰でも簡単」のような強い表現がある場合は、そのまま公開できる根拠があるかを確かめます。
根拠を示せない場合は、実際に説明できる範囲の表現へ直します。
書かれている事実が合っていると確かめられたら、次は自社らしさと読みやすさを見ます。
- 普段の接客や資料とかけ離れた言葉遣いになっていないか
- 誰に向けたサービスかが具体的に伝わるか
- 同じ意味の文章を何度も繰り返していないか
- 専門用語に、初めて出てくる場所で短い説明があるか
- 読者が次に何をすればいいか分かるか
「AIっぽい文章」を直すときは、語尾を変えるだけでは足りません。
公開してよいと確認できたお客様の事例、よく受ける相談、対応できる範囲を具体的に書き足すと、自社らしい文章へ近づきます。
画像は不自然さと利用条件を分ける
AIで作った画像は、全体の雰囲気が合っていても、人物の手や画像内の文字、小物、商品の形などに不自然な部分が残ることがあります。
画像は、次の点を確かめます。
- 人物の手、顔、服、小物が不自然な形になっていないか
- 画像の中の文字や数字が、意味の通る内容になっているか
- 実際の商品や店舗と違う見た目の画像を、そのまま使っていないか
- 他社のロゴや商標に見える要素が入っていないか
- 自社の色、雰囲気、想定するお客様と合っているか
- AIへ読み込ませた素材と、できあがった画像の利用条件を確認できるか
その画像を使っていいかどうかは、利用したAIサービス、読み込ませた素材、できあがった内容、使い道で変わります。
「AIで作った画像だから自由に使える」と決めつけず、利用したサービスの最新の規約を確かめます。
規約上の利用条件と、他人の作品の著作権を侵害しないかは別に確認します。
文化庁の「AIと著作権に関するチェックリスト＆ガイダンス」（2024年7月31日、20ページ）も、生成物を使う前に既存の著作物との類似を確認することを挙げています（2026年10月30日確認）。
判断に迷う内容があれば、必要に応じて専門家に相談します。
問題が文章と画像に限られ、該当箇所を編集できるなら、サイト全体の作り直しより先に、内容の差し替えで対応できるかを検討します。
3. デザイン・操作の問題を分ける
デザインは、好みだけでなく、読めるか、押せるか、目的の場所へ進めるかで見ます。
パソコンできれいに見えても、スマートフォンで開くと順番や余白が変わり、急に使いにくくなることもあります。
まず主要な流れを実際に操作する
問い合わせが目的のサイトなら、次の順にたどります。
ただし送信テストは、管理者と通知を受ける人に了承を得て、使うテスト用データや送信方法を決めてから行います。
入力内容の保存や外部サービスへの通知も確かめ、予約や決済につながるフォームでは、本番の申込みを発生させないテスト方法を用意します。
影響を確認できない場合は送信前で止め、送信後の動作は未確認として記録します。
- トップページを開く
- サービス内容と料金を確認する
- 問い合わせボタンを押す
- 了承を得たテスト用データをフォームへ入力する
- 準備できた場合だけテスト送信し、完了表示と、設定した宛先への実際の通知到達を確認する
送信後の処理はサイトごとに違い、MDNのフォーム解説でも、データの保存やメール送信などが挙げられています。
完了表示だけで確認を終えず、テスト後は合意した方法でテストデータを片付け、変更した設定を元へ戻します。
途中で迷ったり進めなくなったりした場所は、直す候補として記録します。
それぞれの画面で、次の点を見ます。
- 文字が小さすぎず、行と行の間隔も詰まりすぎていないか
- 文章や画像が画面の外へはみ出していないか
- 大事な見出しやボタンが、装飾に埋もれていないか
- メニューを開いて、目的のページへ移動できるか
- ボタンが押せる場所だと見て分かり、指でも押しやすいか
- フォームの項目名と、入力を間違えたときの直し方が分かるか
- 送信した後に、次の流れが案内されるか
見た目だけを直しても、情報の順番やページの構成が合っていなければ、使いにくさは残ります。
たとえば、色やボタンの角の丸みを整えても、料金が見つからない、問い合わせボタンまでたどり着けないという問題は解決しません。
好みと不具合を分ける
修正を頼むときは、気になる点を次の3つに分けます。
見積もりの内容や、直す順番を相手と合わせやすくなります。
気になる点の種類 | 具体例 |
|---|---|
不具合 | ボタンが動かない、画像が重なる、フォームを送れない |
使いやすさの問題 | 文字が読みにくい、重要な情報が見つからない、操作に迷う |
好み・追加要望 | 色を変えたい、動きを追加したい、新しいページを増やしたい |
不具合の修正と追加の要望では、必要な作業や費用が変わります。
最初に分類しておくと、「どこまでが修正で、どこからが新しい制作か」を確かめやすくなります。
4. コード・仕組みの問題を分ける
表示や操作の問題が、文章やデザインの編集だけでは直らないこともあります。
その場合は、サイトを動かしているコードや仕組みまで見ます。
この段階では、画面に見えている症状だけで原因を決めません。
画面に見える症状と技術的な原因を分ける
コードや仕組みに関係する可能性がある症状には、次のようなものがあります。
- 特定の端末やブラウザだけで表示が崩れる
- ボタンやメニューを押しても動かない
- フォーム送信時にエラーが出る
- 管理画面で変更しても公開画面へ反映されない
- ページの読み込みが途中で止まる
- 外部の予約、決済、地図などが表示されない
- 修正するたびに別の場所が崩れる
ただし、同じ症状でも原因は一つとは限りません。
たとえばフォームを送れない原因は、入力内容の不備、使っているブラウザ、フォームの設定、メールの送信設定、外部サービスの障害など、いくつも考えられます。
依頼する側で原因を突き止めるところまでは要りません。
まずはURL、使った端末、行った操作、表示されたエラーメッセージ、起きた日時を伝え、追加で必要な情報は依頼先と確かめます。
修正後も扱える状態か確認する
AIで生成したコードが動いていても、保守しやすいとは限りません。
保守とは、公開後も安全に修正や更新を続けられる状態を保つことです。
技術者へ確かめてもらうときは、今出ているエラーだけでなく、次の点も一緒に相談します。
- 同じ役割のコードが、いくつも重複して書かれていないか
- 使っていない処理や部品が残っていないか
- どこを変えるとどこへ影響するのかが分かる構成になっているか
- 外部サービスが止まったとき、サイトのどの機能が使えなくなるか把握できるか
- 利用している部品や仕組みの更新方法が分かるか
- 修正後のテストと、バックアップを取る手順が決まっているか
- 次の担当者が内容を理解できる記録があるか
次の担当者へ引き継げるか確認する
修正した後に特定の人しか扱えない状態を残さないために、次の項目も確かめます。
- 使ったAI制作サービス、公開ページに対応する編集プロジェクトやファイルの場所、所有者と必要な編集権限が分かる
- 公開前に確認する環境、公開の手順、公開後の確認方法が記録されている
- 使っている部品やライブラリ（機能をまとめた部品集）、外部サービスと、その更新方法が分かる
- ドメイン、サーバー、CMS（管理画面から更新する仕組み）、外部サービスの契約者と管理者が分かる
- 環境変数の名前と設定場所が、秘密の実値を含めず記録されている
- 変更前のバックアップと、問題が起きたときに元へ戻す手順がある
- 対象の端末、ブラウザ、フォームなど、修正後に行うテストが決まっている
- 画像、フォント、コード、外部の部品について、利用条件を確認できる
公開URLが分かっても、別の担当者が編集・再公開できるとは限りません。
編集データやソースを取り出せるか、移管できる範囲はどこまでかを、利用サービスの公式案内と契約で確認します。
たとえばWixは、権限を選んで共同編集者を招待できますが、共同編集者がさらに人を招待するには「Invite People」の権限が必要です。
別のWixアカウントへの所有権移管と、サイトを他社サーバーで動かすことは別で、WixサイトはWixのサーバー上で動かす必要があります。
一方、LovableはGitHubへコードを書き出して同期できます。
移行に関する公式案内では、コードと、データベース・ストレージなどのデータは別の構成要素として説明されています。
コードを受け渡しただけで、実データやアップロード済みファイルまで移ったとは判断せず、必要なデータの取り出しと移行方法を別に確認します。
別の環境へ移すなら、外部サービスとの接続や秘密情報の設定も、移行先で確かめます。
Lovableのプロジェクト権限表では、編集はEditor以上、プロジェクト移管はOwnerの役割です。
公開も標準では全プランでEditor以上が可能ですが、Enterpriseでは外部公開できる担当者を、管理者と所有者、または所有者だけに制限できます（Wix・Lovableの各公式案内は2026年10月30日確認）。
サービス所定の招待方法が使える場合は必要な権限を付け、編集・公開・移管を誰が行えるかを引き継ぎ先と確認します。
管理者や元の制作担当者に連絡できない場合は、「制作会社と連絡が取れないときの引き継ぎ確認」をご覧ください。契約先や管理権限を確かめる手順を説明しています。
元のプロジェクトや編集権限が見つからない場合は、利用サービスの管理者やサポートへ、アクセスを回復できるか確認します。
回復できなければ、残っている文章・画像・機能を確認して、新しい環境で作り直す案と費用を比べることになります。
公開画面を見られることと、元の機能やデータをそのまま引き継げることは分けて考えます。
環境変数とは、接続先や外部サービスの設定などを、コードの外で管理する仕組みです。
そこへ入れれば自動的に秘密が守られるわけではないため、誰が読めるか、ログなどへ出ていないかも技術者に確かめてもらいます。
引き継ぎ資料には環境変数の名前と設定場所だけを残し、パスワードやAPIキーの実際の値は書きません。
これらの資料は、すべてを公開するものではありません。
自社と依頼先のどちらが何を保管するかを、先に決めておきます。
担当者が変わったときに誰へ聞くかも、この時点で決めておくと迷いません。
ログイン、決済、会員情報、個人情報を扱う機能は、一般的な見た目の確認だけで安全性を判断できません。
こうした機能は、同じ分野の経験がある技術者に見てもらい、必要に応じてセキュリティの専門家へも確かめてもらいます。
5. 自分で直す・診断する・修正を頼む
問題を分けたら、内容と影響の大きさに合わせて対応方法を選びます。
全部を自分で直すところまでは要りません。
かといって、原因が分からないまま、サイト全体の作り直しを頼まなければいけないわけでもありません。
三つの選択肢を使い分ける
三つの選択肢と、それぞれが向いている場面は次のとおりです。
対応方法 | 向いている内容 | 注意すること |
|---|---|---|
自分で直す | 会社情報、料金、文章、使用許可を確認した画像の差し替え | 変更前の内容を保存し、一か所ずつ確認する |
診断で整理する | 問題が複数あり、直す順番や確認範囲が分からない | 診断を受けただけでは、実際の修正までは終わらない |
修正を頼む | 表示崩れ、フォーム、コード、外部サービスとの連携 | 対象、希望する状態、見積もりの範囲、テスト方法を先に合わせる |
自分で直す場合は、公開中のページを書き換える前に、バックアップと元の文章を残し、元へ戻す方法も確かめます。
編集する場所が本番か確認用かを区別し、確認用の環境やプレビューが使える場合は、公開前にそこで変更を確かめます。
一度に多くの場所を変えると、どの変更で問題が起きたのかを追いにくくなります。
通常の調整では、小さな修正を一つやって、パソコンとスマートフォンで確かめてから次へ進むと、変更の影響を追いやすくなります。
診断を頼む場合は、対象となるURL、調べる項目、人の目による確認が入るか、実際の修正まで含むかを、申し込む前に確かめます。
サイト診断で分かる範囲は、別記事の「サイト診断で何がわかる？」で整理しています。
修正を頼む場合は、最初に作った症状の記録に、次の情報を添えます。
- 使ったAI制作サービスやツールの名前
- 編集するプロジェクト・ソースファイルが残っているか
- 編集や公開を行える管理者が分かるか
- 問い合わせ、予約、決済など、動かし続けたい機能
- 直したい時期と、いちばん優先する問題
分からない項目は「不明」で構いません。
その情報を入口に、依頼先が現状を確認し、対応できる範囲と追加で必要なものを整理します。
依頼する前に、次の内容を相手と合わせます。
- 対象のページと、直してもらう項目
- 見積もりに含まれる作業
- 追加費用が発生する条件
- 修正前にバックアップを取る方法
- 修正内容を確認する環境と、公開までの手順
- 修正後に行うテスト
- 納品後に自分で更新できる範囲
AIで作ったサイトを公開していいか、内容や操作の面から見直すときは、別記事の「AIで作ったホームページ、そのまま公開して大丈夫？」の確認ポイントも一緒に使えます。
「全部作り直す」という選択は、症状を整理した後でも選べます。被害が広がる問題への対応を先にし、そのうえで事実の誤りや利用者が進めない操作を、影響の大きさに合わせて整理すると、必要な修正の範囲が見えてきます。
まとめ
最後に、AIで作ったサイトを直す前の整理ポイントを振り返ります。
- 「AIで作ったから変」で済ませず、URL、端末、操作、現在の状態と希望する状態を記録する
- 文章と画像は、事実の誤り、自社らしさ、利用条件に分けて確認する
- デザインは好みだけで判断せず、読めるか、押せるか、目的の場所へ進めるかで見る
- コードや仕組みの原因は画面だけで決めつけず、症状を技術者へ伝える
- 自分で直す、診断で整理する、修正を頼む、の三つを使い分ける
- 秘密情報を修正資料へ含めず、渡すアカウントの権限も必要な範囲だけにする
- ファイル、公開手順、契約、バックアップ、テストを次の担当者へ引き継げる状態にする
緊急の問題がなければ、まずいちばん困っているページを開いて、「現在の状態」と「希望する状態」を一文ずつ書くところからです。
この二つが書けるだけでも、自分で直すのか、誰かへ相談するのかを判断しやすくなります。
症状を書き出しても、直す順番や範囲を自分で決めきれないときは、Studio Attraitのホームページ改善でご相談いただけます。
サイトのURL、使ったサービス名、気になっているところをお知らせください。
現在の状態と編集方法を確認して対応できる範囲を整理し、修正内容と料金をご確認いただいてから作業へ進みます（現行サービス案内を2026年10月30日に確認）。
