AIエージェントとCMSをつなぐときは、原稿を作る作業と、会社として公開してよいと判断する役割を分けます。AIは資料の整理や執筆を助けられますが、自社が提供していないサービスまで約束することはできません。事業側が回答の根拠を渡し、確認を通った版をCMSへ届ける流れが必要です。
受け渡すのは本文だけではありません。記事が答える問いと、その根拠も引き継ぎます。公開対象の版まで伝われば、確認した原稿と違う内容が出るのを防ぎやすくなります。このサイトでは、公開用の記事ファイルと、それを支える企画や確認の記録を分けて管理しています。
企画では、会社として答えられる範囲を決める
AIに見出しを作ってもらう前に、その記事で何を答えられるかを決めます。検索されそうなテーマでも、自社の対応範囲や判断の根拠がなければ、一般論を並べた原稿になってしまいます。人が顧客の疑問と事業上の条件を提供し、AIが問いを整理する、という分担です。
たとえば、保守サービスの対象機器を説明する記事を仮定します。読者が知りたいのは、機器の一般的な性能よりも、自分が使っている機器をその会社へ依頼できるかです。製品資料は性能の根拠にはなりますが、自社の保守対象を証明する資料にはなりません。企画を進めるには、現行の対象一覧や契約条件を知る担当者の情報が必要になります。
対象一覧がそろっていれば、AIは対応条件を整理し、既存のサービスページで足りない説明を探せます。短い追記で疑問を解けるなら、そのページを直す方が自然です。独立した記事にする場合は、サービスページとの違いが分かる問いを担当させます。対象機器を説明する記事なら、依頼前の見分け方まで扱う、といった違いです。
根拠と原稿を一緒に渡すと、条件の脱落を見つけられる
調査から執筆への受け渡しでは、資料のURLを集めるだけでは不十分です。どの資料が何を支えているのかが分からないと、AIも確認担当も、製品の仕様と会社の約束を取り違えるおそれがあります。資料の確認日とともに、本文へ使える範囲を残す意味はここにあります。
先ほどの仮定例で、対象一覧には「Aシリーズのうち、保守部品の供給が続いている機種」と書かれているとします。「Aシリーズに対応」という原稿では、条件が落ちています。執筆担当へは対象一覧と該当箇所を渡し、次のような説明を作ります。
Aシリーズは、保守部品の供給が続いている機種を対象としています。同じシリーズでも機種によって対象が異なるため、機種名をもとに対応可否を確認します。
この文が正しいかを判断する担当は、表現の滑らかさよりも、対象一覧との対応を見ます。一方、文章を校閲する担当は「同じシリーズなら全部対応する」と読めないかを確かめます。同じ原稿でも、事実確認と読みやすさの確認では見る対象が異なります。
タイトルや説明文にも、その条件が必要になる場合があります。本文を限定したのに、記事一覧の紹介文で「Aシリーズをすべて保守」と書けば、読者へ伝わる約束が変わるためです。Googleも生成AIコンテンツのガイダンスで、本文だけでなくタイトルや説明文などの正確性に注意を向けています。
確認した原稿と公開する原稿を一致させる
AI自身に読み直させることは、確認候補を探す補助になります。ただ、同じ資料の誤読を繰り返す可能性もあります。このサイトの制作では、企画・執筆・公開判定を別の担当へ渡し、原稿を書いた担当だけで公開可否を決めない運用にしています。
別の担当が読むだけでも、十分とはいえません。前の例なら、事業側が示した対象一覧へ戻って照合する必要があります。文章の印象だけで承認すると、複数の担当が同じ条件の抜けを見落とすことになるためです。英国教育省のコンテンツ品質確認の運用も、専門家による事実確認と、公開前に別の目で最終版を見る工程を区別しています。
公開の判断は、記事という題材全体への承認ではなく、内容を確認した特定の版に対して行います。その後に対応条件を書き換えたなら、変更箇所を事実確認へ戻します。誤字の修正とサービス範囲の変更を同じ扱いにせず、判断に影響する差分が残っていない状態で公開担当へ渡す流れです。
CMSの下書き状態は、公開承認の記録の代わりにはならない
このサイトのKnowledgeは、Markdownの本文と、ファイルの先頭にあるfront matterをPHPで読み取って表示します。front matterにはタイトルや説明文を持たせ、記事の日付や関連リンクなども指定します。下書き指定の記事を公開表示から除外する仕組みもあります。
ただし、それらは表示に使う情報です。誰が対象機器の条件を確認したか、なぜその原稿を採用したかまで、下書き指定の項目で管理しているわけではありません。企画や出典確認の記録は公開ファイルの外に保管し、対象の記事と結び付けています。下書き指定を外したことだけでは、内容が承認された証拠にはなりません。
公開担当は、確認済みの版を公開先へ反映した後、記事のURLで表示を確かめます。ファイル上では正しくても、見出しの表示やリンク先に問題が残ることがあるためです。ここで分かるのはサイトへの反映結果であり、検索エンジンへの登録や順位まで確定したわけではありません。
CMSに承認画面や履歴機能がある場合は、その仕組みで受け渡しを管理できます。ファイルを直接更新する場合も、承認した版と反映した版が対応する記録があれば、運用を組み立てられます。どちらでも、原稿の採否を決める役割と、公開先へ反映する役割を曖昧にしないことが大切です。
公開後の変化は、原因に応じた工程へ戻す
公開後に対象機器の一覧が変わった場合は、文章表現の改善よりも、根拠と本文の更新が先になります。制作記録から対象一覧を参照している記事を探せれば、何を見直す必要があるかが分かります。公開前に根拠を残すことは、次の更新にも役立ちます。
一方、対応条件は変わっていなくても、問い合わせで「Aシリーズなら全機種対応だと思った」という誤解が見つかる場合があります。この場合は、条件の位置や説明の分かりやすさへ戻る判断です。検索流入が少ないだけなら、検索で表示されているかなどを調べるところからです。本文の書き換えが必要かどうかは、その状況によって変わります。
AIへ渡せる材料が「記事を改善して」だけなら、文章を整えるところから再出発しがちです。「保守条件は変わっていないが、対象外の機種でも対応すると読まれている」と伝えられれば、修正すべき問題が具体的になります。企画時の問いと公開時の根拠が残っていることで、更新のたびに回答全体を作り直さずに済みます。