この記事の対象: AIで記事や原稿を書き始めた制作者・発注担当者
読了時間: 約15分
AIに原稿を書かせると、下書きが数分で出てきます。ところが公開してしばらく経ってから、書いていない事実が混ざっていた、同じことを3回言っていた、途中から急に別の会社の文章みたいになっていた——そういう事故が起きます。
厄介なのは、AIの原稿はパッと見の完成度が高いことです。日本語として整っていて、見出しも揃っていて、それらしい。だから読み流すとチェックを通ってしまう。人間のライターの初稿なら「ここ雑だな」と目が止まるところが、AI原稿では止まりません。
この記事では、Web制作の現場でAIライティングを扱うときに実際に起きる破綻を種類ごとに分解し、公開前に何を、誰が、どの順で見るかをチェックリストにします。ツールの紹介はしません。Web記事の品質を担保する運用の設計の話だけです。
AI原稿が壊れる4つのパターン
現場でAI原稿を校正していると、崩れ方はだいたい決まった形に落ちます。まずこの分類を持っておくと、チェックの手順が組めます。
パターン1: 事実の捏造（ハルシネーション）
一番危険で、一番見つけにくいものです。「〜という調査によると」「◯◯社の事例では」といった、出典があるように見えて存在しない記述が混ざります。
たちが悪いのは、AIは自信のない箇所ほど自然に書くことです。人間なら「たしか〜だったと思います」と濁す場面で、AIは断定します。だから文章のトーンからは危険箇所が判別できません。
Web制作の文脈で実際に混入しやすいのは次のあたりです。
| 混入しやすい記述 | なぜ危ないか |
|---|---|
| ツール・サービスの料金プラン | 改定が頻繁で、学習時点の古い金額が出る |
| APIの引数名・関数名 | 存在しないメソッドをそれらしく書く |
| 統計・シェア・調査結果 | 出典名まで作られる場合がある |
| 法令・ガイドラインの条文番号 | 番号だけズレることがあり、気づきにくい |
| 実在企業の導入事例 | 当事者に迷惑がかかる。最悪、事実誤認の指摘を受ける |
| 特定の会社名と制作費・単価の組み合わせ | 契約条件で変わるものを断定すると、当事者にも読者にも実害が出る |
制作会社の立場でこれをやると、単に恥ずかしいでは済みません。クライアントのサイトに載せた原稿に嘘の統計が入っていた場合、責任を負うのは発注した企業です。「AIが書いたので」は通りません。
とくに費用の話は、社名と金額を結びつけて書かないのが原則です。制作費は要件・ページ数・支給素材の量・保守の範囲で変わるもので、同じ会社でも案件ごとに桁が違います。書くなら「この条件ならこの範囲に収まりやすい」という条件つきの一般論に留め、固有名と価格を並べないでください。
パターン2: 冗長と同語反復
AIは指定した文字数に届かせようとして、同じ内容を言い換えて増やします。よく出る型が3つあります。
- 前置きの反復: 「ここまで見てきたように」「重要なのは」で毎段落を始める
- 要素の水増し: 本来3つで足りるメリットを、意味が重なる5つに割る
- 抽象語の連打: 「効果的」「最適化」「重要」だけで一段落が終わり、何も情報が増えていない
見分け方は単純で、その段落を丸ごと消しても記事が成立するかを試すことです。成立するなら消していい段落です。
もう一つ効く見方があります。見出しだけを縦に読んで、同じことを言っている見出しがないか探す。冗長は文単位より見出し単位で起きているほうが被害が大きく、しかも見つけやすい。「〜のメリット」と「〜が有効な理由」が両方あったら、片方は中身が重複しています。
パターン3: トーンのぶれ
長い原稿ほど起きます。前半は「です・ます」の柔らかい語り口だったのに、後半が箇条書きだらけの説明書調になる。あるいは急に「私たちは」と一人称が現れる。
原因は、AIが直前の数百字を強く参照するためです。表を挟んだり、コードを挟んだりすると文脈が切り替わり、そこからトーンが変わります。表や図の直後の段落は、経験上いちばん崩れやすい場所です。
直し方は、修正時に前後を読み比べるのではなく、表・図・コードの直後の段落だけを先に全部拾って読むことです。崩れる場所が決まっているなら、そこだけ集中的に見るほうが早い。
パターン4: 検索意図とのズレ
キーワードは全部入っているのに、読者が知りたいことに答えていない原稿です。たとえば「Web制作 費用」で書かせると、費用の話ではなく「Web制作の重要性」から始まる原稿が出てくることがあります。
これはAIの責任というより指示の設計の問題です。ただし公開前チェックでは必ず引っかける必要があります。判定は「検索した人が最初のスクロールで答えを得られるか」の一点で足ります。
事実層（公開したら取り返しがつかない）
- 捏造された数字・出典
- 存在しない機能・関数
- 古い料金・仕様
構成層（読まれずに離脱する）
- 検索意図とのズレ
- 結論が後ろにある
文体層（信頼を少しずつ削る）
- 冗長・同語反復
- トーンのぶれ
上の層ほど修正コストが高く、下の層ほど発生頻度が高い。
この3層は、直す担当も直すタイミングも変えたほうが早く回ります。事実層は書いた本人以外が見る、構成層は書く前に潰す、文体層は最後にまとめて直す、という分け方です。
逆に言うと、この3つを一度に見ようとするから破綻します。同じ原稿を「事実は合っているか」「構成は正しいか」「文章は読みやすいか」の3つの目で同時に読むのは、人間には無理です。読む回数を分けたほうが、合計時間は短くなります。
チェックを「人の根性」に置かない
多くの現場でAI原稿の品質管理が失敗するのは、「よく読んで確認する」という運用にしているからです。これは必ず崩れます。理由は3つあります。
- 原稿が増えるほど1本あたりの集中力が落ちる
- 見る人によって基準が違い、指摘が属人化する
- 忙しい週は「今回は大丈夫だろう」で飛ばされる
代わりに置くべきなのは、判定が○×で答えられる項目の並びです。「読みやすいか」ではなく「同じ主張が2回出ていないか」。「正確か」ではなく「数字が入っている文を全部リストアップして、出典を1つずつ当てたか」。
判断を求めるチェックは飛ばされますが、作業に落ちたチェックは残ります。
誰が見るかを分ける
同じ人が書いて同じ人が確認すると、事実層の誤りは通過します。書いた直後は自分の原稿を「知っている内容」として読むので、目が滑るためです。
最低限の分担はこうなります。
| 工程 | 担当 | 見るもの |
|---|---|---|
| 構成の確定 | 発注者・編集 | 検索意図、見出し構成、結論の位置 |
| 執筆 | AI＋書き手 | 本文生成、事実の一次確認 |
| 事実確認 | 書き手以外 | 数字・固有名詞・仕様の裏取り |
| 文体調整 | 書き手 | 冗長削除、トーン統一 |
| 最終確認 | 責任者 | 公開可否の一点だけ判断 |
小規模なチームで人が足りない場合でも、事実確認だけは別の人に回してください。ここを分けないなら、AIを使う意味の半分は消えます。
最終確認を「読む工程」にしない
表の最下段にある責任者の最終確認は、原稿を読み直す工程ではありません。ここで読み直すと、前工程が形骸化します。「どうせ最後に見てもらえる」と全員が思うためです。
責任者が見るのは、前の工程が実際に通ったかどうかです。事実確認の担当者が確認先URLを一覧で出しているか。文体チェックの項目に空欄がないか。埋まっていない工程があれば差し戻す。中身の良し悪しは判断しない。
この形にすると、最終確認は1本あたり数分で終わります。読む工程にすると30分かかり、しかも見落とします。
公開前チェックリスト
実際に使う形で並べます。上から順に、飛ばさずに通します。
A. 事実（最優先・全項目必須）
- 数字が入っている文を全部抜き出したか
- 抜き出した数字それぞれに、確認した一次情報があるか
- 「〜によると」「〜の調査では」と書かれた出典を、実際に開いて確認したか
- 実在する企業名・サービス名・製品名が、正しい表記で書かれているか
- 実在する企業名・サイト名と、金額や価格帯を結びつけた記述がないか（契約条件で変わるものを断定すると当事者に実害が出る。費用は条件ベースの一般論で書く）
- ツールの料金・プラン名・上限値を、公式ページで今日の値として確認したか
- コード例・関数名・引数を、実際に動かすか公式ドキュメントで確認したか
- 法令・ガイドラインを引いた箇所の、条文番号と施行状況を確認したか
この8項目のうち1つでも「していない」があるなら、公開しないでください。事実層のミスは、公開後に直しても引用やスクリーンショットで残ります。
B. 構成
- タイトルと最初の300字で、検索者の問いに答え始めているか
- 見出しだけを拾い読みして、記事の主張が分かるか
- 見出しの中に、内容が重複しているものがないか
- 結論が記事の後半に隠れていないか
- 見出しの粒度が揃っているか（H2の下に1つだけH3がある、などになっていないか）
- 読者が次にとる行動が、記事内のどこかに書いてあるか
C. 文体
- 段落を丸ごと消しても成立する段落がないか
- 同じ接続詞（「また」「さらに」「そして」）が3回以上連続していないか
- 「〜と言えるでしょう」「〜ではないでしょうか」で終わる文が複数ないか
- 表や図の直後の段落で、語り口が変わっていないか
- 専門用語に、初出時の説明があるか
- 一人称・二人称の扱いが、記事の頭から最後まで同じか
D. 公開まわり
- 内部リンクが、文脈に合う位置に置かれているか（数だけ合わせて末尾に列挙していないか）
- リンク先URLが実際に開くか
- 画像のalt属性が入っているか
- メタディスクリプションが、記事の内容と一致しているか
- 構造化データ（FAQなど）を入れた場合、質問文と回答の対応が崩れていないか
現場でやってみて分かったこと
チェック体制を運用に入れると、机上の想定と違うところが出てきます。実務で効いた調整を挙げます。
「AIに書かせる範囲」を先に決めるほうが早い
最初は全文をAIに書かせて、あとから直していました。これは効率が悪い。修正で結局全部読み直すことになり、思ったほど時間が浮きません。
範囲を分けたほうが速く回ります。
AIに任せて速い
- 構成案の複数パターン出し
- 一般論・前提の説明パート
- 用語解説・定義の下書き
- 冗長箇所の指摘（自己添削させる）
- タイトル・見出しの案出し
人が書いたほうが速い
- 金額・相場・数字が入る箇所
- 実案件の事例・失敗談
- 結論と判断基準
- 読者への呼びかけ・締め
- 他社サービスへの言及
右側は、AIに書かせても結局ゼロから確認するので、時間が浮きません。左側だけを任せるのが結論です。
一度に長く書かせない
長文を一気に生成させると、後半のトーン崩れと重複が出ます。H2ごとに区切って生成し、あとで人がつなぐほうが、修正時間まで含めると短くなりました。
つなぐときには「前の節の終わりと次の節の始まりが同じことを言っていないか」だけ見れば済みます。
AIに自分の原稿をチェックさせるのは有効、ただし条件つき
「この原稿の冗長な箇所を指摘して」「同じ主張が繰り返されている箇所を挙げて」は、かなり精度よく返ってきます。文体層のチェックは自動化できる領域です。
一方で「事実誤りを指摘して」は機能しません。生成したのと同じ仕組みで検証しているので、捏造した箇所を捏造だと認識できないからです。事実確認だけは、外部の一次情報に当てる作業を人がやる——この線は動かさないほうがいい。
指示の出し方にもコツがあります。「チェックして」と丸ごと投げると当たり障りのない指摘しか返りません。「この記事の中で、消しても意味が変わらない段落を3つ挙げて」のように、出力の形と個数を指定すると使える答えが返ってきます。件数を指定されると、AIは順位をつけて返すためです。
発注側が見るべきポイントは1つに絞れる
制作会社に記事制作を発注している立場なら、納品物の全項目を自分で検品するのは現実的ではありません。見るべきは1つです。
「この記事に出てくる数字は、どこで確認しましたか」と聞く。
これに即答できない制作会社は、事実確認の工程を持っていません。逆に、確認先のURLを一覧で出せる相手なら、他の工程も設計されている可能性が高い。発注前の見極めにも使える質問です。
同じ考え方は、記事以外の発注物でも使えます。予算の立て方から工程を逆算する手順は、こちらで整理しています。
AI原稿と検索評価の関係を誤解しない
「AIで書くと検索順位が下がる」と心配する声をよく聞きますが、話が少しずれています。
問題にされるのは制作手段ではなく、内容が薄いことです。人が書いても中身がなければ評価されませんし、AIが下書きしても検証と加筆が入っていれば問題になりません。
ただし、AI原稿を無検証で量産すると、結果的に次の状態になりやすい。
- どこにでも書いてある一般論しか入っていない
- 一次情報（実測値・自社の事例・実際に触った所感）がゼロ
- 似た記事が自サイト内に複数でき、内部で食い合う
3つ目は見落とされがちです。AIに関連キーワードで記事を量産させると、内容が大きく重なる記事が並びます。読者がどれを読んでも同じで、サイト全体の評価が薄まります。新しい記事を作る前に、既存記事の中身を厚くできないか確認する——これを工程に入れるだけで、無駄な量産は止まります。
一次情報をどう作るか
「一次情報を入れろ」と言われても、調査データを持っている会社ばかりではありません。制作の現場で作れる一次情報は、もっと手前にあります。
- 実際に触った所感: ツールを使ってみて、どこで詰まったか
- やってみて外れた予想: 効くと思った施策が効かなかった記録
- 判断の基準: どういう条件のときにどちらを選んでいるか
- 失敗の記録: 起きた事故と、その後に変えた運用
どれも調査費用がかかりません。しかも、他社が同じ文章を書けないという点で、統計データより差がつきます。AIが絶対に書けないのは、書き手が実際に体験したことだけです。
記事を増やす前に既存記事を見る
新規記事を1本作るコストで、既存記事を3本厚くできることがよくあります。判断の順番はこうです。
- 狙っているキーワードで、自サイトに既存記事があるか探す
- あれば、その記事に追記して意図を満たせないか検討する
- 満たせないほど別の話なら、新規で作る
2で足りるケースが想像より多い。すでに評価が付いている記事に加筆するほうが、ゼロから作るより結果が出るのも早くなります。
流入の変化をどう見るかは、こちらで整理しています。
チェック体制を実際に組む手順
いきなり完全な体制は作れません。段階を踏みます。
順番が大事で、4から始めると失敗します。どんな誤りが起きるかを知らないまま完璧な指示文は書けません。まず出してみて、壊れ方を集めてから設計するのが早い。
記録するときの粒度
「事実誤りがあった」ではチェック項目に変換できません。次の形で残します。
| 記録する項目 | 例 |
|---|---|
| どこで | 第3見出しの表の中 |
| 何が | ツールの月額プラン名が存在しないものだった |
| なぜ気づいたか | 公式サイトを開いたら該当プランがなかった |
| チェック項目にすると | 「プラン名・料金は公式ページで当日確認したか」 |
10件ほど溜まると、自分たちの現場で起きやすい誤りの偏りが見えてきます。全業種共通のチェックリストより、自社で実際に起きた事故から作ったリストのほうが効きます。
指示文に戻すときは「禁止」より「書き方の指定」
4段階目で指示文に組み込むとき、「嘘を書くな」と書いても効きません。禁止だけでは、代わりに何を書けばいいかが決まらないためです。
効くのは書き方の指定です。
| 効かない指示 | 効く指示 |
|---|---|
| 事実を捏造しないこと | 数字を書くときは、出典URLを併記すること。出典が出せない数字は書かない |
| 冗長にしないこと | 1つの主張につき1段落。同じ主張を別の見出しで繰り返さない |
| 具体的に書くこと | 各H2に、実際の場面が分かる例を1つ以上入れる |
| 企業名を出すときは注意すること | 実在する社名やサイト名に、金額・価格帯を結びつけて書かない |
出力の形を指定すると、そもそも壊れた原稿が出てこなくなります。チェックで拾うより、出さないほうが安い。
更新の頻度
チェックリストは半年で古くなります。AIモデルが変わると壊れ方も変わるためです。以前は日本語の不自然さが主な問題でしたが、いまはそこはほぼ壊れず、代わりに「もっともらしい嘘」の比率が相対的に上がっています。
四半期に一度、直近の修正履歴を見返して、もう起きなくなった項目を落とし、新しく出た項目を足す。項目数を増やし続けると誰も通さなくなるので、足したら落とすを守ります。
よくある質問
AIで書いた記事だと検索エンジンに評価されませんか？
制作手段そのものが評価を下げるわけではありません。問題になるのは、内容が薄い記事や、既存の情報を並べ替えただけの記事が量産されることです。一次情報と検証が入っていれば、下書きにAIを使っていること自体は障害になりません。
AIが書いた原稿だと明記する必要はありますか？
法的な義務が一律にあるわけではありませんが、読者や取引先との信頼関係で判断してください。医療・金融・法務など、内容の正確さが直接不利益につながる分野では、誰が事実確認したかを示せる体制のほうが重要です。表示の有無より、確認工程を持っているかが本質です。
事実確認はどこまでやれば十分ですか？
数字・固有名詞・仕様・料金・法令の5種類が入っている文を全部抜き出し、それぞれに一次情報を当てられれば十分です。一般論や考え方の記述まで裏取りする必要はありません。抜き出す作業を省略して「読みながら確認する」形にすると、必ず漏れます。
AIに自分でチェックさせるのは意味がありますか？
冗長箇所の検出、同じ主張の重複、トーンのぶれといった文体層のチェックには有効です。事実誤りの検出には使えません。生成したのと同じ仕組みで見るため、捏造した箇所を捏造として認識できないからです。用途を分けて使ってください。
制作費や相場をAI原稿で扱うときの注意点は？
実在する会社名やサイト名と、金額を結びつけて書かないことです。制作費は要件・ページ数・支給素材・保守範囲で大きく変わるため、固有名と価格を並べると当事者にも読者にも実害が出ます。書くなら「この条件ならこの範囲に収まりやすい」という条件つきの記述にし、根拠にした条件を必ず併記してください。
少人数のチームでも分担できますか？
書いた人以外が事実確認だけ担当する、という1点だけ分ければ機能します。全工程を分ける必要はありません。1人しかいない場合は、執筆した日と別の日に確認するだけでも検出率は上がります。時間を空けると自分の原稿を他人の文章として読めるためです。
まとめ
AIライティングでWeb記事の品質を担保できるかは、書かせ方より公開前の工程設計で決まります。押さえるところを整理します。
- 破綻は事実層・構成層・文体層の3つに分かれる。直す人とタイミングを分ける
- 事実確認だけは書き手以外がやる。ここを分けないとAIを使う効果が半減する
- 実在する社名・サイト名に金額を結びつけない。費用は条件つきの一般論で書く
- チェックは判断ではなく作業に落とす。「読みやすいか」ではなく「数字を全部抜き出したか」
- 全文を任せず、一般論・構成案・用語解説だけをAIに書かせる
- 一次情報は調査データでなくていい。触った所感・外れた予想・判断の基準で足りる
- チェックリストは実際に起きた事故から作る。半年ごとに足して落とす
- 発注側が見るべきは1点。「この数字はどこで確認しましたか」に即答できるか
AIを使うこと自体は、もう議論する段階ではありません。決めるべきは、出てきた原稿をどう検品するかです。その工程を持っているかどうかが、そのままアウトプットの差になります。
