AIで作ったWebページを確認する：原稿・事実・操作の照合

生成された映画会の案内に、原稿にはなかった「毎回満席」や予約ボタンが加わっていた。見た目が整っていても、開催条件が違えば公開できません。AIで作ったWebページを確認するときは、元の原稿と案を並べ、残す文と直す文を決めます。

架空の地域映画会を題材にした編集部の練習です。以下の誤り入りの案も説明用に作ったもので、特定のAI製品の実測出力ではありません。文章の点検から始められるため、AIサービスの契約は不要です。

生成する前に、案が満たす条件を固定する

練習用の条件を「開催日時を伝える」「会場の入口を案内する」「予約は受け付けない」と決め、短い原稿にします。架空の案内であることも明記します。この原稿を、後から出力と照合する基準にします。

次を練習用の元原稿として固定します。日時と会場も架空です。

地域映画会は2026年11月14日14時から、交流室で開催します。入口は建物の北側です。短編映画を上映します。予約は不要です。

これに対して、誤り入りの案を「毎回満席の地域映画会。11月14日15時から交流室で開催。今すぐ予約してください」とします。二つを並べると、開始時刻、実績の表現、予約の扱いが違い、入口の情報も抜けています。文章の流暢さを採点する前に、この差を拾います。

「魅力的なページを作って」だけでは、完成した見た目に合わせて評価の基準まで変わりがちです。今回必要な情報と、追加しない機能を最初に書けば、提案された案に何が足りないかを指摘する材料になります。

条件の書き方は、確認できる完成条件を作る記事で練習できます。ここでは同じ条件を、人が書いた案にもAIが生成した案にも当てて読みます。

文章の主張を、元の原稿へ一つずつ戻す

仮に生成案に「毎回満席の人気イベント」と書かれていたら、提供した原稿に根拠があるかを調べます。これは確認用に作った失敗例で、実際のサービスから得た出力ではありません。

根拠のない実績なら削除し、「短編映画を上映する会です」のように、元の条件で確かめられる説明へ戻します。日時や会場名も、自然な文章だから正しいと判断せず原稿と照合してください。

AIにもう一度「正しいですか」と尋ねるだけで確認を終えず、主張と根拠を対にします。確認できない主張は未確認として扱い、公開する文章へ混ぜないという練習です。

修正後の案は「2026年11月14日14時から、交流室で短編映画を上映します。入口は建物の北側です。予約は不要です」となります。元原稿の情報を並べ替えただけで、人気や参加実績は補っていません。

案にあった内容	根拠と判断
15時から	元原稿は14時。14時へ修正する。
毎回満席	実績の資料がないため削除する。
今すぐ予約	予約不要の条件に反するため削除する。
北側の入口がない	元原稿にある来場情報なので補う。

書き直した後にも、時刻と入口を元原稿へ戻って照合します。修正を頼むだけで済ませると、別の箇所が変わっていても見落とすためです。

見た目の完成と、操作の確認を別の欄にする

予約不要の案内に予約ボタンがあれば、目立つ配色かどうかより先に、条件に合わない操作として見直します。削除するか、必要な行き先を案内するリンクへ変えるかを、ページの目的から決めます。

ページの実装も作った場合は、リンクを開く、狭い画面で読む、キーボードで操作するという確認項目を残します。「生成できた」「開けた」「必要な操作を確かめた」を同じ完了欄にしないことが大切です。

コードの意味を説明できない箇所があれば、まずその箇所を小さく切り分け、入力と結果を予想する練習へ戻ります。大量のコードを追加して解決したように見せる前に、変更理由を一つ言える状態を目指します。

確認の記録を、生成案と一緒に残す

NISTのAIリスク管理フレームワークの案内は、AIの設計、利用、評価などに信頼性の考慮を組み込むための任意利用の枠組みを紹介しています。Web制作の雇用予測を示す資料ではありません。

ここで提案する記録は、その公式な適合判定ではなく、学習用の簡単なメモです。今回の条件表を埋めても、NISTの枠組みへの適合を示すことにはなりません。「提案された内容」「照合した条件」「採用または修正の理由」を三欄に書きます。確認した人、日付、まだ試していない操作も添えておけば、出力しただけの状態と区別できます。

条件そのものが曖昧な場合は、案を直す前に確認へ戻ります。例えば原稿が「午後開催」だけなら、14時という具体的な時刻を生成案から採用しません。実案件なら担当者へ尋ね、返事が来るまでは未確定のまま管理します。自分だけで決められる模擬課題とは、判断する人が違います。

修正後の案を、最初の条件に戻って読み直す

自作の架空原稿だけを材料に短い案を一つ用意し、日時、根拠のない実績、不要な操作の三点を確認します。AIを利用しない場合も、自分で作った誤り入りの案で同じ練習ができます。

上の修正例は、次の四条件で照合できます。

• 開始時刻が元原稿と同じ14時で、案内の別の箇所に15時が残っていない。
• 「毎回満席」が消え、代わりに根拠のない「大好評」などが加わっていない。
• 予約を促す文言や操作がなく、予約不要と読める。
• 会場名だけでなく、北側の入口という来場情報も残っている。

文章の四条件がそろっても、リンクやキーボード操作を試していなければ、操作欄は未確認です。文面の修正で公開確認のすべてを済ませたことにはしません。

修正前後を残し、「原稿にない実績を削除した」のように理由を一文で書きます。実装の確認項目を増やしたい場合は、無料のHTMLレッスンで構造と操作の見方を確かめてください。次の課題は、今回説明できなかった一項目から選びましょう。