AIで記事を作る工程設計｜構成から入稿までの分業表

01結論：AI記事制作は「工程ごとの責任分担」で決まる

AIで記事を作るときに問われているのは、AIに書かせるかどうかではありません。どの工程を誰が最終判断するかという設計です。この記事では、AI MARKETING JOURNAL自身が運用している5つの工程の分業表を公開します。工程は構成・執筆・図解・ファクトチェック・入稿です。

実際の担当と機械検証の仕組みもあわせて示します。品質を担保しているのは特定のAIツールの性能ではなく、工程ごとに置かれた人の承認ポイントです。分業表と機械検証の内容は、このあと順に説明します。

02なぜ記事制作の工程を分業表にして公開するのか

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

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更新）。本誌が構成から入稿までの分業表を公開するのは、この「どこで価値を担保しているか」を読者に開示するためです。

Googleのスパムポリシーは、この判定基準を品質評価ガイドラインの4.6.5節に置いています。ページ数の多さそのものではなく、各ページが読者に新しい情報を加えているかどうかで判定する設計です。同じキーワードで似た構成の記事を大量に並べても、読者への追加情報が無ければ評価は上がりません。だからこそ、量産の工程そのものに「価値を確認する関門」を組み込む必要があります。

03AI記事制作の5つの工程と分業表

本誌の記事制作は、構成設計・執筆・図解生成・ファクトチェック・入稿ゲートという5つの工程に分かれています。各工程の主担当と、人が最終判断する内容は次の通りです。

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

5つの工程を分けている理由は単純です。1人がすべてを担当すると、書いた本人がそのまま検証も行うことになり、見落としに気づきにくくなります。工程ごとに担当を分けることで、前の工程の判断を次の工程が検証する構造になります。構成・執筆・図解は同じ執筆担当が続けて作りますが、ファクトチェックと入稿ゲートの判断は別の担当・別の仕組みに移します。

04記事制作の構成設計はどこまでAIに任せられるか

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

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

この2ステップの要点は、構成案そのものではなく「事実を確認してから見出しを立てる」という順番にあります。順番を逆にすると、見出しが先に決まり、事実がそれに合わせて選ばれてしまいます。

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

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

05執筆とファクトチェックを別人格に分ける理由

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

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

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

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

06入稿前に記事制作の機械検証が止めているもの

入稿ゲートでは、複数の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は、禁止表現や効果の断定、実測台帳と突き合わせた未実測の自社数値を一覧化し、最終判断の材料を人へ渡します。

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

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

もう一つ、check_internal_refs.pyという検査もあります。記事本文で他記事に触れる際は、既に執筆済みの記事タイトルだけを参照する決まりです。参照先がまだ執筆されていない記事だと、リンクにならない死にリンクが残ります。

この検査は、参照可能なタイトルの一覧と本文中の表記を突き合わせ、一致しないものをエラーにします。本記事では、まだ執筆されていない子記事のタイトルを本文に書いていません。

これらのスクリプトは1本ずつ独立して動きますが、どれか1つでもエラーを返すと、その記事は次工程に進めません。人が読んで直すのではなく、機械が先に止める設計にしているのは、量が増えるほど人による見落としが起きやすくなるためです。品質ラインは次の5段階で進みます。

07人が最終判断を下すのはどの一手か

AIが担当できる工程が増えても、人が最終判断を下す一手は残ります。次は、本誌が人の承認を必須にしている項目です。

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

自社でAIによる記事制作の体制を作る場合も、まずこの「どの一手を人が最終承認するか」を先に決めることをおすすめします。執筆・ファクトチェック・公開判断を1人がすべて兼ねる体制では、確認したつもりのまま公開されてしまう箇所が残りやすいためです。

この境界を曖昧にしたまま量産だけを進めると、Googleが問題視する「価値を伴わない大量生成」に近づいてしまいます。人の承認ポイントを明確にしておくことは、量を増やすためではなく、量を増やしても価値を落とさないための設計です。

08AI記事制作でつまずきやすい点

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

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

09AI記事制作の分業チェックリスト

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

10FAQ