YMYL領域のメディアを毎日運用しようとすると、必ずぶつかるのが「品質を落とさずにペースを保つ」という問題です。僕は税務・FP・投資・AI活用のブログを毎日1本公開していますが、その裏側では、Claude CodeとWordPressを連携させた執筆パイプラインが動いています。この記事では、YMYLメディアを人力運用と同じ質で回すために、そのパイプラインをどう設計しているのかを整理します。
なぜYMYLメディアで執筆パイプラインの標準化が必要か
税務・FP・投資といったYMYL領域では、記事の一貫性そのものが読者の信頼につながります。ある記事では監修者情報が明記されているのに別の記事では抜けている、免責注記のパターンが記事によってバラバラといった状態は、単なる編集事故ではなくメディア全体の信頼性を削る要因になります。標準化とは装飾を揃える話ではなく、読者に対する「同じ品質を約束する」という契約そのものです。
属人化を避けるための投稿標準
執筆担当ごとに構成が違う、投稿時のSEO設定が漏れる、アイキャッチのトンマナが揃わない。属人化した運用では、書き手が変わった瞬間に品質が落ち、リライト工数がじわじわ膨らんでいきます。僕は、記事の見出し構成・字数・SEOメタ・アイキャッチのスタイル・免責文・監修署名までを投稿標準として型に落とし込み、パイプラインの各工程で自動チェックする運用にしています。標準を「文書」ではなく「コードとして実行される検査」に落とす点が重要です。
YMYLで信頼を落とさない品質担保の原則
YMYL領域では、Google側の評価軸が「誰がどのような専門性で書いたか」に強く寄っています。AIで生成した記事をそのまま公開するのではなく、企画の承認・情報の一次ソース確認・監修者による最終判断を必ずパイプラインの中に組み込む必要があります。自動化するのはあくまで工程であって、判断そのものではないという線引きが、YMYLメディアの品質担保における出発点になります。
僕が運用している執筆パイプラインの全体像
僕の執筆パイプラインは、リサーチ→企画→承認→執筆→アイキャッチ生成→予約投稿の6工程で構成されています。Claude Codeが担うのは機械的に落とせる部分で、企画の承認と公開判断は人間が握るという役割分担が全体を貫く原則です。
① リサーチエージェントがネタを収集・企画書を生成し、Supabaseにpendingで保存
② 監修者がタイトル・構成・想定読者を確認しapprovedに変更
③ 翌日の執筆エージェントが承認済みネタを1件だけ取得
④ 記事HTMLを生成し、SEOメタ・アイキャッチと合わせてWordPressへ予約投稿
⑤ 投稿後、Supabaseのステータスをreservedに更新して次サイクルへ引き渡す
各工程を担うツールと役割の分担
リサーチと企画のたたき台生成はClaude Codeが実行し、Supabaseのbroadcast_contentsテーブルにpendingステータスで保存します。監修者がタイトル・構成・想定読者を確認して承認ステータスに切り替えると、翌日の執筆エージェントがそのネタを1件だけ拾い、記事HTMLを生成してWordPressに予約投稿します。すべての状態遷移がテーブル上に残るため、いつどのネタがどの状態かを常に俯瞰できる構造になっています。ネタ帳が別ドキュメントに散らばらないという点が、日次運用では効いてきます。
自動化の境界を「判断」で切り分ける
Claude Codeに任せているのは、企画書に沿った文章構成・見出し配置・アイキャッチ生成・SEOメタ生成・予約投稿など、判断基準を明文化できる作業のみに絞っています。「このネタを世に出すか」「どこまで踏み込んで解釈するか」「制度改正の適用時期をどう表現するか」といった判断が絡む部分は必ず人間が握ります。この境界を曖昧にすると、AIが誤った制度解釈をそのまま公開してしまう事故につながるため、境界そのものを設計要件として明文化しています。
各工程で品質担保に組み込んだチェック
執筆パイプラインの中で最も重要なのは、実は各工程内の作業ではなく「工程間のチェック」です。1工程完結型ではなく、次の工程に進む前に必ず自動バリデーションを走らせ、基準未達なら公開を止める設計にしています。以下は投稿用スクリプトに組み込まれている自動検査の全項目です。
執筆後に走る自動バリデーション一覧
| 検査対象 | 基準 | 未達時の挙動 |
|---|---|---|
| SEOタイトル | 空欄なし・60字以内 | 投稿停止し記事側を修正 |
| メタディスクリプション | 空欄なし・150字以内 | 投稿停止し記事側を修正 |
| 本文構造 | H3見出し1個以上 | 投稿停止し構成を作り直す |
| 本文字数 | プレーンテキスト2,500字以上 | 投稿停止し肉付け |
| アイキャッチ | ミニマル版へ差し替え成功 | 差し替え失敗時は手動再生成 |
| 本文画像 | ストック写真の挿入枚数を確認 | 0枚なら手動で補修 |
| 状態管理 | 投稿成功後にDBステータスを予約済へ更新 | 未更新なら手動でPATCH |
基準未達なら止める、が結局いちばん早い
この検査が1つでも欠けると、翌日の公開スロットに穴が空くだけでなく、YMYLメディアとしての信頼性そのものが揺らぎます。パイプラインを止めてでも基準未達は通さないというルールがあるからこそ、毎日の運用が回る構造になっています。速度と品質のトレードオフに見えて、実際には「基準を守る運用」の方が長期的な工数は圧倒的に少なく済むという実感があります。
士業メディアがAI活用を語るときに毀損しがちな権威性
AIで記事を生成していることを読者に感じ取られると、士業メディアの権威性は一気に下がります。ここは技術的な問題というよりトーンの問題で、パイプラインの設計思想として明確に持っておく必要があります。読者にとっての価値は「誰が責任を持って書いたか」であり、生産プロセスの効率化そのものではないからです。
「AIに丸投げ」トーンが読者にどう映るか
「AIが自動で書きました」「大量に記事を量産できます」といった運営裏側の話をそのまま出すと、読者は「専門家が責任を持って書いた記事ではない」と受け取ります。士業メディアが真っ先に守るべきは、記事に対する責任の所在です。監修者が明確で、内容に責任を持っていることが読者に伝わる設計が最優先されます。パイプラインの効率化はあくまで手段であって、読者に自慢する話ではありません。
収益化・量産・自動生成の匂いを消す設計判断
僕の執筆パイプラインでは、記事本文には「AI」「自動生成」「量産」といった内部運用の言葉を出さないルールにしています。代わりに、監修者名・記事の情報源・数字の出典を明示することに紙面を割きます。パイプラインは裏方の効率化のためのものであり、読者との接点では常に一次情報と監修責任を前面に置く方針です。運用裏側を語りたくなる誘惑を工程レベルで断つことが、YMYLメディアの権威性を守るうえで意外と効きます。
まとめ
Claude Code×WordPressの執筆パイプラインは、単に記事を量産するための仕組みではなく、YMYLメディアとしての品質と信頼を毎日担保するための工程管理システムです。判断は人間が握り、機械的な工程はAIに落とし、工程間で必ずバリデーションをかける。この3点を守れば、士業メディアがAIを活用しても権威性は損なわれません。僕はこれからも、パイプラインを止めてでも基準未達は通さないという原則を、毎日の運用の軸として据え続けていきます。
※ 本記事は2026年7月時点の情報をもとに作成しています。ツール仕様やAPI仕様は変更される可能性があります。最新情報は各サービスの公式ドキュメント等でご確認ください。本記事の内容は一般的な情報提供を目的としており、個別の運用相談を提供するものではありません。
note には、仕事やキャリアの考えごとを書いています
公認会計士・税理士として実務で見ていること、キャリアで迷ったこと、お金との距離感。答えの出ていない話も含めて置いています。


コメント