オウンドメディアの運用をAIに任せるとき人が判断する場面 自社メディア2本の記録から
更新
AIが進めた作業と人が決めたこと
Rootpublishの記録では、記事づくりの工程の多くをAIが進めました。一方で、記事に使う一次情報を承認することと、記事を公開するかどうかを決めることは、運営者が判断しました。
2026年9月、rootpublish.comの自社メディアでは、記事2本（記事2と記事3）をPC上のWordPressで作りました。Claude Codeが進めた工程は次のとおりです。テーマの選定、依頼文の作成、原稿の生成、生成とは別の呼び出しによる照合、英語・中国語・韓国語への翻訳と訳の照合、サイトへの配信、公開後の確認です。
記事2では、運営者が一次情報を承認し、本文を直さずに公開しました。記事3では、運営者の指示を受けて、Claudeが管理画面で一次情報の承認ボタンと公開ボタンを押しました。ボタンを押したのはAIですが、押すかどうかは運営者が指示しています。
この運用は、運営者が同じPCで指示と承認をできる状態で行いました。無人で定期的に回した運用ではありません。Rootpublishでも、AIが生成した結果は承認待ちに保存されます。公開権限を持つ人が本文と出典を確認し、公開するかを決める仕組みです。
生成と照合にかかった時間
記事3では、承認済みの一次情報31件を含む依頼から7段落の原稿を生成するのに約1分かかりました。生成とは別の呼び出しで、その原稿を一次情報と照合するのには約15秒かかりました。
どちらも、PCのClaude Codeを既存のClaudeサブスクリプションで使った結果です。記事1本あたりの費用は計測していません。運営者が原稿を読んで承認するまでの時間も計測していません。この数字から、人の作業時間がどれだけ減るかを見積もることはできません。
照合で見つかった言い過ぎと直し方
生成とは別の呼び出し（Claude Opus）で照合したところ、記事3の原稿に言い過ぎが1件見つかりました。
Rootpublishの仕様で、公開後に同じページを7日間観察して実測で判断するのは、検索改善の機能だけです。ところが原稿は、公開後全般の方針であるかのように書いていました。この文は、WordPressへ取り込む前に、対象と条件を明記した文に直しました。
記事2の照合では指摘はありませんでした。それより前に作った試運転の記事3本では、照合で2件が見つかっています。自動更新の対象範囲を根拠なく定義した文と、検査の時点を「公開時」と誤った文です。どちらもWordPressで直してから公開しました。
記事3で見つかった言い過ぎは、数字の誤りではなく、機能の対象と条件を広げる書き方でした。照合の結果をどう直すかは、元の一次情報と読み比べて決める必要があります。
訳の照合で見えた限界
訳の確認では、翻訳とは別のClaude Opusの呼び出しで原文と訳を比べました。抜け、付け足し、意味の違い、用語、不自然さを指摘させています。
記事3の英語・中国語・韓国語訳では、指摘10件のうち8件を採用しました。採用しなかった2件は、照合のために本文を抜き出す処理が付けた記号を、訳の誤りと取り違えた指摘でした。訳の確認全体でも、タグを除いた本文で照合したために、番号付きリストの番号やリンク先のURLが抜けているという誤った指摘が繰り返し出ています。
指摘の採否はClaudeが原文と照らして決めました。人や母語話者による確認は、まだしていません。韓国語で「公開」を「공개」から「발행」にするという指摘については、公開済みの記事と用語をそろえる必要があるため、母語話者の判断を待つことにしました。AIの照合だけでは決められない判断が残ったということです。
公開の操作で止まった場面
記事2の公開は、数回やり直しになりました。原因は2つあります。1つ目は、ページ内の公開の確認欄がボタンの下の画面外に開き、見落とされたことです。2つ目は、確認欄を開いたブラウザの画面が非表示になっていて、公開のクリックが届かなかったことです。対策として、確認欄をボタンの位置に出し、確認のボタンへフォーカスが移るように直しました。
それより前にも問題がありました。ブラウザの確認ダイアログを表示しない画面では、「承認して公開」を押しても何も起きないことがあったのです。そこで、公開の確認をページ内に移しました。
記録では、公開の確認欄の位置や画面の表示状態によって、公開の操作が届かないことがありました。公開の操作が実際に完了したかは、画面で確かめる必要があります。
運用しながら管理画面を作り直した
2026年9月25日の1日で、Rootpublishのプラグインを3回更新しました（0.1.14〜0.1.16）。自社の運用中に、運営者から声が出たためです。何をすればよいか分かりにくい、企画や確認をどこから始めるのか分からない、という声でした。
途中の版では画面ごとの説明を増やしましたが、かえって画面が重くなりました。最終的には、管理画面の行き先を「やること」「記事」「会社情報」「設定」の4つにまとめ、各画面にいつ何のために使うかを1行で示しました。
さらに、記事ごとの段階（企画・AIに依頼・原稿の確認・公開・効果を見る）と次の操作を、1つの一覧にまとめました。下書きの一次情報は、画面内で確認したうえでまとめて承認できるようにしています。自社の運用では、次に何をすればよいか分かりにくいという声が出たことが、管理画面を作り直すきっかけになりました。
公開後にGoogleに登録されたページ
2026年9月25日に、Search Consoleへサイトマップを送信しました。9月27日早朝に確認したところ、サイトマップの36ページのうち29ページがインデックス済みでした。
未登録の7ページの内訳は、韓国語版の記事4本、英語と中国語の記事一覧、日本語の記事1本です。Search Consoleの検索データは数日遅れて集計されます。そのため、検索での表示回数とクリックはまだ確認できていません。
Googleは、AI OverviewsやAI Modeについて、表示の要件を満たしてもクロール・インデックス・表示は保証されないと説明しています。Rootpublishも、検索順位やAIからの引用を保証していません。インデックスされたことは、成果が出たことを意味しません。
この記録から言えないこと
この記録は、自社メディアの記事2本とその翻訳という小さな標本です。人の作業時間も、記事1本あたりの費用も計測していません。検索順位やAIからの引用という成果も、まだ分かりません。
そのため、AIに任せれば運用が自動で回るとは言えません。作業時間が減るとも、検索での成果が上がるとも言えません。この記録から言えるのは、AIが進められた工程があったことと、照合や公開の場面で人の判断や画面の修正が必要になったことまでです。
人が判断する場面を決める手順
ここからは、上の記録とRootpublishの編集ガイドの提案をもとにした手順案です。検索順位の改善を実測で確かめた方法ではありません。
1つ目に、企画から公開後の確認までの工程を書き出します。そのうえで、AIに進めさせる作業と、人が判断する作業を分けます。記録では、一次情報の承認と公開の判断を人に残しました。
2つ目に、記事の根拠にする一次情報を決め、承認した情報だけを使うようにします。編集ガイドでは、時点・条件・出典・公開範囲を記録し、未確認の項目を推測で埋めないことを勧めています。Rootpublishでは、確認前の情報と非公開の情報は記事の根拠に使いません。原稿の段落ごとに、参照した情報のIDと版を記録します。ただし、版の検査は文章と根拠の意味が一致していることまでは保証しません。
3つ目に、生成とは別の照合を置き、指摘の採否を誰が決めるかを決めます。訳の用語のように、公開済みの記事との整合や母語での判断が必要なものは、人に回す基準を作っておくと迷いにくくなります。
4つ目に、公開前の確認項目を決めます。編集ガイドでは、主張ごとの根拠との対応、数字と条件、公開範囲、読者の次の行動を確認するよう提案しています。記録で見つかった言い過ぎも、機能の対象と条件を広げる書き方でした。
5つ目に、公開ボタンを誰が押すかと、公開が完了したことをどう確かめるかを決めます。記事3のように操作をAIに任せる場合でも、押すかどうかの指示は人が出すようにします。
最後に、公開後に何をいつ確認するかを決め、確認した時点を記録します。Googleは、生成AIを使う場合も正確性・品質・関連性を重視するよう案内しています。利用者への価値を加えない大量生成は、スパムポリシーに抵触する可能性があるとも説明しています。記事の本数を増やすことより、確認できる根拠のある記事を出すことを優先するのが、この手順の前提です。