AI記事制作の工程設計｜5工程の分業表と人の承認点【図解】

「AIで記事を書かせています」と話すと、たいてい次に聞かれるのは「品質はどう担保しているんですか」です。ここで使っているツールの名前を並べても、相手はほとんど納得しません。知りたいのは道具ではなく、どの作業を誰が確かめているのかだからです。

この記事では、AI MARKETING JOURNAL自身が回している記事制作の工程設計を、そのまま開きます。工程は構成設計・執筆・図解生成・ファクトチェック・入稿ゲートの5つです。それぞれの主担当と、人が最後に判断する内容まで書きます。

先に結論をお伝えします。品質を支えているのは、特定のAIツールの性能ではありません。工程の境目に置いた、人の承認ポイントです。ここが決まっていない体制では、どの道具を選んでも同じ場所で事故が起きます。そういう体制の作り方を探している方に向けて書きました。

この記事には3人が登場します。入社して日の浅い若葉さん、制作の工数と体制を預かる高梨課長、そして質問に答える鈴木さんです。3人の問いの層が違うので、自分に近い問いから読んでも構いません。

01生成AIで記事制作をするとき、工程設計から決めるのはなぜですか？

若葉さん

若葉さんの発言

AIで記事を作るとき、いちばん最初に決めるのはプロンプトでしょうか。

鈴木さん

鈴木さんの発言

順番としては工程が先です。誰がどこで確かめるかが決まっていないと、指示文をどれだけ磨いても、同じ場所で同じ事故が起きます。

AIで記事を作るときに本当に問われているのは、AIに書かせるかどうかではありません。どの工程を誰が最終判断するかという設計です。ここを決めずに走り出すと、書き上がった原稿を前にして「これ、誰が確認したことになっているんだろう」という宙ぶらりんが生まれます。

理由は単純です。1人がすべてを担当すると、書いた本人がそのまま検証も行うことになります。自分が書いた文章は、書いた瞬間から「正しいはず」の前提で読んでしまいます。見落としに気づく役が、その体制にはいません。

工程ごとに担当を分けると、構造が変わります。前の工程の判断を、次の工程が検証する形になるからです。本誌では構成・執筆・図解までは同じ執筆担当が続けて作りますが、ファクトチェックと入稿ゲートの判断は、別の担当と別の仕組みへ移しています。

02Googleは、生成AIで書いた記事をどう見ているんですか？

体制の話に入る前に、前提を確認します。ここを誤解したまま工程を組むと、必要のない遠回りをします。

Googleは公式ガイダンスで、生成AIによる作成それ自体はガイドライン違反ではないと明言しています（出典: Google Search Central・2025-12-10更新）。問題視されるのは、ユーザーへの価値を伴わない大量のページ生成です。Googleはこれを「scaled content abuse」というスパムポリシー用語で扱っています。

判定の基準も、ページ数の多さそのものではありません。Googleのスパムポリシーは、この判定基準を品質評価ガイドラインの4.6.5節に置いています。各ページが読者に新しい情報を加えているかどうかで見る設計です。同じキーワードで似た構成の記事をどれだけ並べても、読者への追加情報が無ければ評価は上がりません。

高梨課長

高梨課長の発言

つまり、量を出すこと自体が悪いわけではない、と。

鈴木さん

鈴木さんの発言

そうです。ただ、量が増えるほど「価値を確認する関門」を工程の中に置いておかないと、追いつかなくなります。

書き方の側にも、余計な作業は要りません。Googleは、生成AI検索向けの専用最適化は基本的に不要だとも述べています（出典: Google Search Central「AI最適化ガイド」・2026-07-10更新）。AI専用のテキストファイルや特別なマークアップを新設する必要はない、という立場です。評価の軸になるのは、独自性・専門性のあるコンテンツと明確なサイト構造という、基本的なSEOそのものになります。

AIによる概要への表示にも、追加の要件は無いと明記されています（出典: Google Search Central「AI機能とウェブサイト」・2025-12-31更新）。SEOスターターガイドが掲げる「有益なサイトにする」という基準も、同じ方向を向いています（出典: Google Search Central「SEOスターターガイド」・2025-12-18更新）。

03AI活用の記事制作は、どの5工程に分かれるんですか？

本誌の記事制作は、構成設計・執筆・図解生成・ファクトチェック・入稿ゲートという5つの工程に分かれています。工程は一列に並んでいて、前の工程の出力がそのまま次の工程の入力になります。

各工程の主担当と、人が最終判断する内容は次のとおりです。

表の右端の列が、この記事でいちばん見ていただきたい部分です。ここが空欄の工程は、実質的に誰も確認していない工程になります。

姉妹誌AIO Journalは2026-07-28時点で251本を公開しています（sitemap.xml実測）。本数が増えるほど、どの工程で何を確認するかを明文化した設計が効いてきます。工程を曖昧にしたまま量産すると、確認したつもりの箇所が、いつのまにか誰の担当でもなくなるためです。

04記事制作の構成設計は、どこまで生成AIに任せていいんですか？

構成設計は、キーワードと想定読者からH2の骨格を作る工程です。ここはAIが下書きを作れますが、採否の決定はディレクターが持ちます。流れは次の2ステップです。

1. ディレクターが記事マップの該当行（カテゴリ・型・target_kw・図解点数）を渡す。執筆者はその型のテンプレートに沿って見出し案を作る
2. 執筆者が一次ソースまたは自社の実測台帳を確認する。事実が確認できない見出しは、確認できるまで立てない

若葉さん

若葉さんの発言

見出し案を先に作ってから、根拠を探すことが多いです。それだと逆ですか。

鈴木さん

鈴木さんの発言

逆です。書けそうな見出しを立ててから根拠を探すのは、調べ物ではなく辻褄合わせになりやすいところです。

この2ステップの要点は、構成案の出来栄えではなく順番にあります。逆にすると、見出しが先に決まり、事実があとから見出しに合わせて選ばれてしまいます。

本記事もB型（徹底ガイド型）というテンプレートに沿っています。結論・本題・つまずきやすい点・チェックリスト・FAQという構成があらかじめ決まっており、書き手ごとに構成の質がばらつくのを防いでいます。型が固定されているからこそ、AIが下書きを作っても、読者が知りたい情報の抜けを人が見つけやすくなります。

ディレクター役が見ているのは、1本の記事の出来だけではありません。本誌は18カテゴリ・3デスクという全体設計を持っており、その記事が全体のどこに置かれるかも確認します。同じキーワードで重複した記事を作らないことも、構成の段階で人が判断する項目です。

05執筆とファクトチェックを分けると、AI活用の記事制作で何が変わるんですか？

執筆した本人がそのまま事実確認まで行うと、自分が書いた内容を無意識に「正しいはず」と見なしてしまいます。姉妹誌AGI Journalでは、パイロット記事で「常駐実行で動いている」と現在形で断定したことがありました。執筆者とは別人格の批評ワーカーがlaunchctlで稼働状況を確認し、実際には動いていないことを突き止めた例です。

この教訓から、本誌は執筆担当（jp-writer）と原典照合担当（vault-researcher）を分けています。ファクトチェックを執筆の内部工程に置かず、独立した関門として設計している、ということです。

高梨課長

高梨課長の発言

担当を分けると、単純に手数は増えますよね。そこはどう見ればいいですか。

鈴木さん

鈴木さんの発言

増えます。ただ増えるのは確認の手数で、書き直しの手数は減ります。公開後に気づいて直すほうが、たいてい高くつきます。

同じ発想は、執筆そのものの重複にも当てはまります。複数の担当が同じ記事IDに気づかず同時着手すると、一方の作業がもう一方を上書きしてしまう恐れがあります。防ぐ手順は次の2つです。

1. 着手前に、担当する記事IDを宣言するファイルを置く（入力：担当する記事ID）。他の担当が同じ記事IDへの着手に気づける
2. 宣言の無い記事IDには着手しない（入力：着手前の宣言ファイル一覧）。宣言が無ければ、先に確認してから着手する

06入稿前の機械検証は、生成AIの記事制作で何を止めているんですか？

入稿ゲートでは、複数のQAスクリプトが記事mdを機械的に検査します。実行例は次のとおりです。

python3 qa/check_sources.py 02_記事/AIMJ-0201_ai-content-production-workflow.md
python3 qa/verify_diagrams.py

check_sources.pyは、本文中の数値主張に出典（外部リンクまたは「実測」＋日付）が対応しているかを検査し、対応が無ければエラーで止めます。verify_diagrams.pyは、図解SVGの最小フォントサイズや文字行数・図形数を検査し、スマホで潰れる図を通しません。verify_prepublish.pyは、禁止表現や効果の断定、実測台帳と突き合わせた未実測の自社数値を一覧化し、最終判断の材料を人へ渡します。

07AI活用で記事制作を回すとき、機械検証はどう動かすんですか？

もう一つ、check_internal_refs.pyという検査もあります。記事本文で他記事に触れるときは、既に執筆済みの記事タイトルだけを参照する決まりです。参照先がまだ書かれていない記事だと、リンクにならない死にリンクが残ります。この検査は、参照可能なタイトルの一覧と本文中の表記を突き合わせ、一致しないものをエラーにします。

高梨課長

高梨課長の発言

検査を毎回全部回すと時間がかかりませんか。手を止めたくないのですが。

鈴木さん

鈴木さんの発言

全部は回しません。書いている最中は決まった2つだけを繰り返します。全部を通すのは、次の担当へ渡す直前でよいと考えています。

機械検証を最短で回す手順は次の2つです。

1. check_sources.pyとcheck_density.pyを対象記事1本に実行する（入力：記事ファイルパス）。エラーがあれば違反箇所が具体的に表示される
2. 表示されたエラー箇所を修正し、同じスクリプトを再実行する（入力：修正後の記事ファイル）。エラーが無くなるまで繰り返す

これらのスクリプトは1本ずつ独立して動きますが、どれか1つでもエラーを返すと、その記事は次工程に進めません。

08AI活用が進んでも、記事制作の工程設計で人が残る一手はどこですか？

AIが担当できる範囲が広がっても、人が最終判断を下す一手は残ります。

本誌が人の承認を必須にしているのは、次の項目です。

• 記事をreviewedへ進めるかどうかの最終承認
• 実測台帳に無い自社の数値を、新たに実測して追記してよいかどうかの判断
• 記事の一般公開・送信・削除・pushという、後戻りしにくい操作の実行
• 案件の起票やナレッジへの内部昇格といった、案件管理そのものの判断

並べてみると、共通点が見えます。やり直しがきかない操作と、根拠そのものを増やす判断の2種類です。この2つは、速さより取り返しのつかなさで選ぶべきところなので、人が握ります。

自社でAIによる記事制作の体制を作る場合も、まずこの「どの一手を人が最終承認するか」を先に決めることをおすすめします。執筆・ファクトチェック・公開判断を1人が兼ねる体制では、確認したつもりのまま公開される箇所が残りやすいためです。境界を曖昧にしたまま量産だけを進めると、Googleが問題視する「価値を伴わない大量生成」に近づいてしまいます。

09生成AIの記事制作でつまずくのは、工程設計のどこですか？

工程を分けても、境目の運用が甘いとすり抜けが起きます。本誌が実際に注意している点は次のとおりです。

• 自社実績の数値を、実測台帳の記録を確認せずに書いてしまう。本誌はverify_prepublish.pyで未実測の自社数値を一覧化し、公開前に人が確認する設計にしている
• 未執筆の記事タイトルを『』で参照し、死にリンクを作ってしまう。参照可能なタイトルは実ファイルから機械生成し、手で書き足さない運用にしている
• 出典の無い数値をそのまま通してしまう。check_sources.pyが同一文または同一H2内の出典記法を機械検査し、対応が無ければエラーにする
• 複数の担当が同じ記事IDに同時着手し、片方の作業を上書きしてしまう。着手前に範囲を宣言するファイルを置いてから執筆を始める運用にしている
• 型（AからGの7種）を無視して自由な構成で書いてしまう。型ごとに必須要素と字数の下限を定め、外れた記事は機械検証で差し戻す運用にしている

5つに共通するのは、どれも工程の中ではなく、工程と工程のあいだで起きていることです。工程の担当を決めただけで安心せず、受け渡しの瞬間に何を確かめるかまで決めてください。

10自社でAI活用の記事制作の工程設計を作るなら、何から始めますか？

まず、いまの制作フローを段階に割ってみてください。本誌の品質ラインは次の5段階で進みます。

自社の工程を同じ形で書き出すと、どの段が抜けているかがすぐ見えます。多くの場合、抜けているのは独立ファクトチェックの段です。次のチェックリストで確認してみてください。

• 構成案は一次情報または自社の実測台帳の範囲内で組んだか
• 執筆担当とファクトチェック担当を分けたか
• 数値主張ごとに出典（外部リンクまたは「実測」＋日付）を同じ文かH2内に置いたか
• 自社の実績・数値は実測台帳に記録があるものだけを使ったか
• 図解は最小フォント14px以上・スマホで潰れない要素数で作ったか
• 未執筆の記事タイトルを『』で参照していないか
• 出典検査・図解検査・公開前検査をすべて通したか
• 公開の最終判断を人（監修者）に委ねているか

11よくある質問

12まとめ｜今日やる3つのこと