AIエージェントを記事制作に取り入れても、下書きをCMSへ送るだけでは、企画から公開後の改善までを一つの流れにはできません。一件の記事を誰から誰へ渡すのか、そのとき何がそろっていれば次へ進めるのかを決める必要があります。

この記事で示す運用では、AIは資料探しや初稿づくりを補助します。ただし、記事が答える問いをAIの出力だけで確定しません。どの情報を根拠として採用し、原稿を公開するかは、人が責任を持って判断します。

現在AdRegionで使っているCMSの役割は、その判断を終えた原稿を読み取り、公開情報として表示することです。この三者をひとまとめの制作担当と考えず、受け渡す内容から役割を分けると流れを組み立てやすくなります。

担当者を決める前に受け渡す内容をそろえる

「企画担当」「調査担当」といった名前だけを決めても、作業の境目は曖昧なままです。先に考えたいのは、次の担当が迷わず作業を始められる状態です。まず、各工程で受け取るものと次へ渡すものを対応させます。あわせて、先へ進めない条件も決めておきます。

たとえば、調査担当へ「SEOの記事を調べてください」とだけ伝えても、何を根拠として探せばよいのか判断できません。企画の段階で記事の問いと説明する範囲を決め、既存ページとの境界も伝えます。ここまで分かれば、調査担当は主張を支える資料に絞って探せます。必要な根拠が見つからなければ、文章で埋めずに企画へ戻せます。

この考え方は、執筆を終えた後も同じです。読みづらさや説明不足は執筆へ戻し、根拠が足りなければ調査へ戻します。記事の問いそのものが変わった場合は、企画から見直します。問題に応じた戻り先を決めておけば、理由が曖昧なまま原稿全体を書き直さずに済みます。

一件の記事が企画から改善へ進む流れを確認する

次の表は、AdRegionで一件の記事を受け渡すために採用している運用設計です。GoogleやCMS全般が定めた共通仕様ではありません。まず縦に工程の順序を追い、次に横へ見て、AIの補助と人の判断が混ざっていないかを確かめます。受け取るものが足りないときに、どこへ戻すかを確認するためにも使えます。

工程受け取るものAIの補助人が決めること次へ渡すもの先へ進めないとき保存先次の担当
企画読者の困りごとと既存ページの役割重複候補を探し、回答案を比べる記事の問いと代表URLを決め、説明する範囲を定める記事の問いへ答えた文章を含む制作計画ページの境界や必要な証拠が決まらなければ、企画を見直す一記事ごとの制作計画調査
調査制作計画と確認したい主張一次情報を探し、資料同士を照合する採用する根拠と適用範囲を決め、未確認事項を残す確認日と使えない主張を含む証拠記事固有の価値を支えられなければ、企画へ戻す一記事ごとの制作計画執筆
執筆記事の問いへの回答と確認済みの証拠構成案や初稿を作る説明の順序と深さを決め、断定できる範囲を守るMarkdownの初稿根拠不足は調査へ、問いの変更は企画へ戻す記事ファイルと制作計画文体校閲
文体校閲初稿と記事の問いへの回答不自然な表現や重複を見つける読みやすい流れに整え、見出しと語調を決める文脈を整えた原稿説明不足や不自然な要約があれば、執筆へ戻す記事ファイル事実確認
事実確認校閲済み原稿と証拠名称やリンクを照合し、数値の候補を探す情報が現行かを確かめ、主張へ適用できるかを決める確認結果と残る不明点根拠の誤りは調査へ、表現の問題は執筆へ戻す一記事ごとの制作計画公開判定
公開判定確認済み原稿と確認結果評価項目を採点し、不足候補を見つける公開、修正、保留、統合のいずれかを決める承認した原稿と判定理由説明不足は執筆へ、証拠不足は調査へ、重複は企画へ戻す制作計画と品質評価の記録CMSへの配置
CMSへの配置と形式確認承認済みMarkdownと記事情報形式検査を行い、サイト内の整合を確認する警告への対応と公開状態を決める表示できる記事と検査結果原稿形式は執筆へ戻し、登録内容は配置時に直す記事ファイルと検査結果公開後の確認
公開後の改善判断確認期間とデータ元が分かる観測結果変化を集計し、改善候補を整理する同じ記事を直すか、新しい問いとして企画するかを決める変更理由と次の確認条件判断材料が足りなければ、観測を続ける制作計画や改善候補の記録該当工程または企画

この運用へ当てはめるときは、AIの出力がそのまま人の決定になっている工程がないかを確かめてください。AIが根拠の候補を探しても、どこまで採用できるかは調査担当が確認します。公開前の採点を補助しても、公開する責任は人に残ります。

保存先も、一つにまとめる必要はありません。読者へ見せる本文と公開情報はCMSへ渡します。誰が何を判断したかは、未確認の内容とともに制作記録へ残します。CMSが扱える情報と制作上残したい経緯を分ければ、実装されていない承認機能を前提にせず運用できます。

AIが補助できる作業と人が決める範囲を分ける

ここで示すAdRegionの運用では、AIエージェントを候補探しや資料の照合に使います。既存ページと重複している箇所を見つける場面や、証拠と原稿の食い違いを確かめる場面でも補助を任せます。確認済みの材料があれば、初稿づくりにも使えます。

ただし、候補が見つかることと、その内容を採用できることは別です。記事の問いを決めるときは、サイト内のどのURLで答えるかを人が判断します。調査で見つけた資料も、主張の根拠として使える条件を人が確かめます。事実確認と公開判定は、AIの出力だけで終わらせません。

Googleの生成AIコンテンツに関するガイダンスでは、生成AIはトピックの調査などに役立ち得ると説明されています。AIの利用自体が違反になるわけではありません。Googleウェブ検索のスパムに関するポリシーで問題になるのは、利用者へ価値を加えずにページを大量生成し、検索順位の操作を主な目的とする行為です。

この二つのGoogle公式文書は、ここで示す人による公開判断を必須工程として定めたものではありません。人が判断する流れは、記事の問いと根拠を確かめ、読者へ出す責任を曖昧にしないためのAdRegionの品質管理です。AIを使ったかどうかだけで判断せず、誰に役立つ記事なのかを確認します。そのうえで、説明を支える根拠も確かめます。

CMSへ保存する公開情報と制作の経緯を分ける

現在、AdRegionで使っているCMSは、配置されたMarkdownを読み取って記事を表示する仕組みです。記事のタイトルと説明は、Markdownの冒頭にある設定欄のfront matterから読み取ります。日付のほか、カテゴリやタグも同じ場所に記載します。

draft は公開条件の一つです。一覧とサイトマップでは、draft がfalseであることが必要です。タイトルも必要で、日付は有効かつ未来日ではないものに限ります。個別のHTML記事では、draft がfalseで日付が有効かつ未来日でなければ表示されます。

related_links は関連記事の表示に使われます。記事URLの末尾に使うslugはfront matterではなく、Markdownのファイル名から決まります。個別の記事ページには、正規URLを示すcanonicalとArticle形式の構造化データも出力します。

形式検査のlintでは、見出し直下に文章があるか、タイトルに使えない記号が含まれていないかを確認します。公開記事の検査では、関連記事のリンク先が存在するかを確かめます。通常公開記事数と、二つのサイトマップに含まれる通常記事URL数の一致も確認します。ただし、これらの検査に通っても、本文の正確さや検索成果が保証されるわけではありません。

今回確認したAdRegionのローカルコードは、配置済みのMarkdownを読み取る側の実装です。この範囲では、ブラウザから原稿を書き込む管理画面や、工程ごとの担当割り当てと承認状態を保存する機能は確認できません。通知や差し戻し理由に加え、版ごとの変更理由や公開後データの自動還流を保存する処理も確認できません。ローカルコード外のデプロイ基盤や外部サービスは確認に含めていないため、公開用のMarkdownとは別に制作記録を持ち、人が決めた内容までCMSが管理しているようには扱いません。

実際の記事制作で分業できた範囲を確認する

ここまでの流れを自社の制作へ当てはめる材料として、実際に完成した記事の記録を見てみます。対象は「サイトマップ送信後もインデックスされないときの確認手順」です。ここで示せるのは、一記事ごとの制作計画と品質評価の記録に残っている範囲だけです。

  • 対象記事 sitemap-indexing-basics を2026年7月22日に再編集した記録です。
  • 担当 企画はLinnaeus the 2nd、調査はHypatia the 2ndが担当しました。執筆はErdos the 2nd、文体校閲はTesla the 2ndです。事実確認はNewton the 2nd、公開判定はGodel the 2ndが担当し、Codexが工程を調整しています。
  • 制作記録に残ったもの 企画からは、記事の問いへ見出しなしで答えた文章と、既存ページとの役割分担が渡されました。調査ではGoogleの一次情報が加わり、本文に使える主張と未確認事項も残っています。その後にMarkdown初稿が作られ、文体校閲と事実確認を経ました。公開判定の内容まで、同じ記事別計画に記録されています。
  • 公開前の評価 品質台帳では合計95点で、公開可と記録されています。この点数が示すのは、定めていた公開前の品質基準を通過したことです。検索順位や問い合わせへの効果を示す評価ではありません。
  • この記録では分からないこと 工程ごとの所要時間や費用、差し戻し回数は確認できません。担当間の通知方法やCMSへ配置した時刻も記録されていません。公開後の検索実績と事業成果も、この記録からは判断できません。

この記録から確認できるのは、六つの制作工程を別の担当へ渡し、その成果を一つの記事別計画に残せたことです。CMSが担当の割り当てや承認を自動化した事例ではありません。自社の流れを作るときも、記録で確かめられる事実と期待する効果は分けて考える必要があります。

工程ごとの詳しい判断は別の記事で確認する

ここまで扱ったのは、企画から改善まで一件の記事を受け渡す流れです。各工程の詳しい基準まで同時に詰め込むと、誰から誰へ渡すのかが見えにくくなります。自社で決め切れていない工程が見つかったら、次の記事で詳しく確認できます。

記事を書く前の企画処遇は、記事を量産せず公開・統合・FAQ・保留を決める方法で扱います。そこで決めた問いと直接回答が、この記事で調査へ渡す最初の材料になります。

原稿が完成した後の判定基準は、AIエージェントで記事を校閲し公開可否を決める品質管理フローで確認できます。社内で誰が公開を決めるか、例外が起きたときに誰が止めるかは、コンテンツガバナンスで公開責任と例外対応を決めるの役割です。

内容確認を終えたMarkdownと公開版の対応は、Markdown記事を安全に公開するワークフローで説明しています。ここでは、承認済み原稿をCMSへ配置する位置と、形式に問題があった場合の戻り先までに範囲を絞りました。

最初の一記事で受け渡し方法を決める

自社の制作フローへ取り入れるときは、まず公開予定の記事を一件選びます。表の各行をその記事に置き換え、各工程で受け取るものを決めてください。次に、誰が判断し、何を次へ渡すのかを確認します。先へ進めないときの戻り先や保存先を決められない工程があれば、そこから整える必要があります。

最初からAIエージェントの数を増やす必要はありません。企画の問いと調査の根拠がそろい、人が公開を判断できる流れを先に作ります。そのうえで、繰り返し負担になっている作業を一つ選び、AIへ任せる範囲を広げるとよいでしょう。