人工知能（AI）からWebサイトの変更を提案されたら、まず対象ページと現在のサービス内容を確認します。提案のどの部分を採用し、何を確かめる必要があるかを決めてから、変更する文章と確認方法を実装担当者へ渡してください。ページに変更が反映されたことと、問い合わせが増えたことは、分けて確かめます。
ここからは、倉庫の冷凍・冷蔵設備をメンテナンスする会社を舞台にした架空の例です。会社、担当者、フォーム、社内資料、AIの提案文、修正案、テスト手順は説明のために作ったものです。Supasaitoや実在する顧客の経験、特定のAIが実際に出力した回答ではありません。
この会社のフォームには、名前、メールアドレス、相談内容を入力する欄があり、届いた問い合わせは営業チームの共有メールボックスで確認する設定です。マーケティング担当者がAIからフォームの修正を提案され、サービス責任者と開発担当者に相談しながら進めることにしました。
1. 現在のフォームと、提案の理由を読み比べる
担当者は、まずフォームを開いて、AIの提案と並べます。現在の表示は次のとおりです。
**見出し：**訪問作業を依頼する
**入力欄：**お名前・メールアドレス・メッセージ
**メッセージ欄に何も入力していないときの表示：**こちらに入力
営業担当者からは、次のメモが届いていました。
依頼に対応できるかを判断するには、設備の種類と必要なメンテナンスの内容を知る必要があります。最初のメッセージを受け取った後で、これらの情報を尋ねることがあります。
一方、説明のために作ったAIの提案はこうです。
入力してほしい情報を説明し、「24時間以内に返信します」と加えましょう。このフォームからの問い合わせが増えます。
担当者は、営業メモにある「設備の種類」と「必要なメンテナンス」が、メッセージ欄の案内に含まれていないことに気づきます。ここを説明する案には、検討する理由があります。
ただし、営業メモからは、問い合わせが何件増えるかも、入力途中でやめた人がいるかも分かりません。「24時間以内に返信できる」と確認できる資料もありません。
そこで、担当者はサービス責任者に尋ねます。「このフォームで、どのような相談を受け付けていますか。送信すると訪問作業が予約されるのですか。それとも、まず内容を確認するのでしょうか」。この答えを確かめてから、ページに書く文章を選びます。
2. サービス責任者の確認をもとに、文章を作り直す
サービス責任者が確認した案内には、次の内容がありました。これも架空の資料です。
このフォームでは、定期メンテナンスについての問い合わせを受け付けます。担当者が対応可能かを確認し、メールでやり取りを続けます。送信した時点で訪問作業が予約されるわけではありません。Webサイトで約束できる返信時間は、まだ確認していません。
担当者は、この案内とAIの提案を読み比べます。フォームが受け付けるのは定期メンテナンスの相談なので、「訪問作業を依頼する」という見出しを、相談の受付だと分かる表現へ変えることにしました。実際に利用者が予約だと誤解したと確認できたわけではありませんが、提供内容に合わせて説明を具体化する判断です。
メッセージ欄には、営業が確認に使う設備とメンテナンスの情報を案内します。名前とメールアドレスの欄はそのまま残します。一方、返信時間が確認できていないため、AIが提案した「24時間以内」は使いません。
W3Cのフォーム入力の案内も、必要な情報や入力方法を説明し、未入力の欄に表示される案内文をラベルの代わりにしないよう勧めています。担当者はこの考え方を参考に、メッセージ欄のラベルを残したまま、近くに説明を置く案を作ります。
担当者がサービス責任者へ確認を依頼する文章案は、次のとおりです。
**見出し：**定期メンテナンスについて相談する
**そのまま残す入力欄：**お名前・メールアドレス
**メッセージ欄のラベル：**ご相談内容
**メッセージ欄の近くの説明：**設備の種類と、必要なメンテナンスの内容をお知らせください。型番が分からない場合は、分かる範囲でご説明ください。
**送信前の説明：**担当者が内容を確認し、対応可能かをメールでご相談します。このフォームの送信だけでは、訪問作業は予約されません。
これはAIの提案をそのまま採用した文章ではありません。担当者が、確認できたサービス内容をもとに書き直した候補です。型番が不明でも相談できる形にし、新しい必須項目や返信時間の約束は加えていません。
サービス責任者には、相談内容と送信後の流れが実際の提供内容に合うかを確認してもらいます。もし「送信後に誰が何をするのか」がまだ決まっていなければ、担当者はその説明を書く前に確認を続けます。今回はそこが確認できたので、文章案を実装の依頼へまとめられます。
会社の資料を選び、文章の依頼へまとめる手順は、AIに自社の記事を依頼する前の準備でも扱っています。
3. 開発担当者へ、変更箇所と確認してほしい内容を渡す
担当者はサービス責任者の確認を受けた文章を承認し、現在の表示、上の文章案、サービス案内を同じ作業依頼に添えます。依頼には、今回決めたことをそのまま書きます。
- **残すもの：**名前とメールアドレスの入力欄。
- **変えるもの：**見出し、メッセージ欄のラベルと説明、送信前の説明。上の確認済みの文章を使う。
- **加えないもの：**訪問作業の予約や24時間以内の返信を約束する文言。
- **最初に見せてほしいもの：**修正を反映した確認用ページ。マーケティング担当者が、承認した文章と読み比べる。
これなら、開発担当者は変更する箇所と残す箇所を確認できます。担当者も、「フォームを改善する」という曖昧な依頼ではなく、自分が承認した文章を基準に確認できます。
次に、開発担当者と営業チームへ、確認用ページからテスト送信をしてよいか、どのメールボックスに届くかを確かめます。テストでは、テスト用の名前と会社が管理するメールアドレスを使い、メッセージの先頭に「テスト：フォームの送信確認。作業の依頼ではありません」と入れることにしました。営業にもその文面を知らせ、実際の相談と区別できるようにします。
文章を確認した時点では、開発担当者に確認用ページを用意してもらう段階です。担当者は、次の表示・送信の確認も終えてから、公開を依頼する流れにしました。
4. 画面と受信内容を確かめ、結果を依頼に残す
確認用ページができたら、担当者は承認済みの文章を横に置き、見出し、ラベル、メッセージ欄の説明、送信前の説明を順に読み比べます。予約や24時間以内の返信が、別の箇所に加わっていないかも確認します。
続いてスマートフォンでページを開きます。「設備の種類と、必要なメンテナンスの内容を」という説明から、訪問作業の予約にはならないという案内まで、文章を最後まで読めるかを確かめます。入力欄へ文字を入れた後も、名前、メールアドレス、相談内容のどの欄かが分かるかを見ます。文章が途中で切れていたり、欄の説明が分からなくなったりしたら、その画面を開発担当者に示して修正を依頼します。
送信の確認では、先ほど合意したテスト情報を入力します。送信後、画面に成功の案内が出たら、それを確認結果として記録します。そのうえで営業担当者に共有メールボックスを開いてもらい、「テスト：フォームの送信確認」で始まるメッセージを探してもらいます。入力した名前、返信先のメールアドレス、メッセージが届いているかを確かめて、初めて受信の確認も記録できます。
また、開発担当者に入力エラー時の表示を見せてもらいます。たとえば、メールアドレスの入力が受け付けられない場合に、どの欄をどう直せばよいかが分かるかを確認します。W3Cのフォームの結果通知に関するガイドも、送信の成否を伝え、入力ミスを修正できる案内を勧めています。
もし営業から受信の確認が取れなければ、依頼には「画面では成功の案内を確認。営業のメールボックスへの到着は未確認」と残します。画面に表示されたことと、営業が受け取ったことを、同じ確認済みの事実にはしません。
担当者は、このように確認する項目を依頼の時点で決めておきます。承認した文章が表示され、入力と送信について合意した確認ができたら、依頼した作業を完了と判断するための受け入れ基準になります。フォーム全体のアクセシビリティ適合を認定するものではありません。
確認が終わったら、担当者は開発担当者へ公開を依頼します。公開後にも実際のページを開き、承認した文章が反映されているかを読み比べ、そのページの参照先と確認結果を同じ依頼に残します。
ここまで終えても、「今回の文章に変えたので問い合わせが増えた」とはまだ言えません。担当者が後から調べたいなら、まず何を見たいかを決めます。たとえば、営業に届いた相談に設備とメンテナンスの情報が含まれていたか、その情報を尋ね直す必要があったかです。GOV.UKのデータを使った設計のガイドも、変更する行動、期待する影響、その測り方を整理するよう勧めています。
担当者と営業は、記録する期間と数え方を決め、受信した相談と追加確認の有無を残せます。ただし、情報の揃った問い合わせ、サービスに合う商談、契約した顧客は別の結果です。AIでの言及と顧客増加の関係を確かめる記事では、このような記録の違いを説明しています。
さらに、文言変更が結果を引き起こしたと判断するには、他の説明と区別できる根拠が必要です。英国Cabinet Officeのテストと改善のガイドは、影響を評価する段階で比較できる情報を計画する考え方を示しています。担当者は、承認した文章が公開され、ページの表示と送信について合意した確認が済んだら、実装の依頼を完了にできます。その後、営業に届く問い合わせの情報が以前より揃うようになったかどうかは、別に調べる必要があります。
このケースで担当者がAIの提案から採用したのは、相談に必要な情報と受付内容を分かりやすくする部分です。未確認の返信時間と問い合わせ増加の約束は採用していません。その判断を文章案、実装の依頼、画面と受信の確認まで引き継ぐことで、何を変え、何を確かめた仕事なのかを残せます。
よくあるご質問
- 01 効果を示す数値がないと、変更できませんか？
-
この例では、サービス責任者が確認した受付内容に合わせて見出しを具体化できます。その修正と、問い合わせ増加を示すことは別です。数値がなければ、増加まで実証したとは報告しません。
- 02 返信時間が分からない場合、フォーム全体の修正を止める必要がありますか？
-
今回は返信時間を約束しなくても、定期メンテナンスの相談を受け付け、メールで確認する流れを説明できます。もし受付内容そのものが分からなければ、担当者はサービス責任者への確認を続けます。
- 03 送信成功の画面が出れば、受信まで確認できたことになりますか？
-
この例では、営業に共有メールボックスを開いてもらい、テスト用の名前、メールアドレス、メッセージが届いたかを確かめます。そこまで確認できなければ、画面の表示と受信の未確認を分けて記録します。
- 04 変更しないと決めてもよいのでしょうか？
-
担当者が現在の表示とサービス案内を読み比べ、すでに正確で必要な説明も揃っていると分かれば、変更しない判断もできます。その場合は、確認した内容と採用しなかった理由を依頼や判断メモに残します。
