AI記事制作の分業体制｜6工程の分け方と人が決める2箇所

「この記事、AIが書いたんですか」。本誌に届く質問で、いちばん多いのがこれです。

答えは「はい」です。ただ、それだけでは何も伝わりません。誰が構成を決め、誰が原稿を書き、誰が数字の裏を取り、誰が出してよいと言ったのか。そこまで開かないかぎり、「AIが書きました」は言い訳の一文にしかならないと考えています。

この記事は、本誌の記事1本ができるまでの分け方を、そのまま公開したものです。素材は本誌自身の制作記録で、うまくいった話だけでなく、実際に起きた誤りも同じ場所に置いてあります。

案内役は3人です。若葉さんがそもそもの疑問を、大森部長が体制と責任の側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントに記事制作を任せる分業体制は、どこをどう分けているんですか？

若葉さん

若葉さんの発言

分業と言われても、AIには全部まとめてお願いするイメージがありました。

鈴木さん

鈴木さんの発言

本づくりに置き換えると近いと思います。企画を立てる人、書く人、裏を取る人、出すと決める人。ひとりで全部やった本より、手が入ったほうが読めるものになりますよね。

本誌の記事は、次の順で工程を通ります。前の工程の条件を満たさないかぎり、次へは進みません。

④と⑤でCONDITIONALまたはREJECTの判定が出た記事は、②の執筆へ戻ります。戻ることを減点として扱っていません。この分け方が設計どおり働いた証拠として記録します。

02記事制作の分業体制で、AI社員が6工程に分かれているのはなぜですか？

理由は1つです。書いた本人は、自分の誤りに気づきにくいからです。これはAIに限った話ではなく、人が書いた原稿でも同じことが起こります。

本誌のパイロット記事AGIM-701では、1回目の改稿を終えたあとに、批評だけを担当するワーカーが公式ドキュメントと自社の実測データへ当たり直しました。そこで出た指摘は15件です。うち4件は重大と判定されました。

• 稼働していない自社事例を「動いている」と現在形で書いた誤り
• 公式仕様の誤記
• 社内規約からの、申告のない逸脱
• 存在しない記事への参照

この4件は、書いた本人にあたるAIには見えていませんでした。読み返しの回数を増やしても出てこなかった種類の誤りです。見つけたのは、通す理由ではなく落とす理由を探すよう指示された、別の担当でした。

03構成を決めるAIエージェントは、記事制作で何を執筆側へ渡すんですか？

構成を担当するFableは、Anthropicが「オーケストレーター・ワーカー」と呼ぶ設計に沿っています。中央のLLMが複雑な仕事を動的に分解し、ワーカーのLLMへ委ね、返ってきたものを統合する形です（出典: Anthropic公式）。

Fable自身は記事を1文字も書きません。分解・レビュー・統合だけを担当し、実際の執筆はjp-writer（Sonnet）を並列で走らせます。構成側が執筆側へ渡すのは、次の4点です。

• 記事の型（A〜G）と本文字数の下限
• 図解の予定点数と、1枚目が表す主題
• 参照する既存記事の有無（重複＝カニバリの回避）
• 「何を書くか」ではなく「何を満たせば合格か」という条件

構成側は、書く内容そのものを指定しません。満たすべき条件だけを渡し、表現は執筆側の裁量に委ねます。この境界がないと、構成側が実質的に執筆を兼ねてしまい、分けた意味が薄れます。

雑務を担う担当も別にいます。記事マップの棚卸しや、frontmatterの形式チェックのような機械的な作業は、bulk-processor（Haiku、軽量モデル）が引き受けます。重い判断はSonnet、繰り返しは軽量モデル、という分け方も体制の一部です。

04書いた本人と別のAI社員が原典を照合するのは、何を防ぐためですか？

若葉さん

若葉さんの発言

出典のURLが並んでいれば、それで裏は取れているのでは、と思ってしまいます。

鈴木さん

鈴木さんの発言

URLが並んでいることと、その中身が本文と合っていることは別ですね。だから、書いた人ではない担当が、実際に開いて確かめる工程を置いています。

執筆を終えた記事は、書いた本人とは別のワーカーであるvault-researcherが照合します。primary_sourcesに挙げた原典を実際に開き、数値・主体・日付が本文と合っているかを1件ずつ見る工程です。

この工程が働いた実例があります。2026-07-28、社内のAIエージェントが、台帳に残っていた古い表記「blocked」だけを根拠に、姉妹メディアAIO Journalを「1本も公開されていない」と報告しました。実際には251本が公開済みで、原典照合の工程がこの誤りを訂正しています。

同じ日に、公開本数そのものでも取り違えがありました。最初は本番トップページの要約に出た「189本」をそのまま報告し、確かめていませんでした。実測はsitemap.xmlを数えた251本です。要約ツールが返した値を一次情報として扱わない、というルールはこの失敗から加わりました。

05機械検証は、生成AIの原稿のどこを数えて止めているんですか？

原典照合のあとに、機械検証が入ります。build.pyとqa/verify_site.pyが、本文の実字数・表の数・図解の要素数・primary_sourcesの件数などをPASSとFAILで判定します。項目数はおよそ9個です。人が読んで感覚で決めていた部分を、できるかぎり数値のしきい値へ置き換えています。

次のいずれかに当てはまる記事は、この時点で止まります。

• 本文の実字数が、型別の下限（全型共通で2,200字）を下回っている
• 表・リスト・図解・primary_sources・本文中の出典明示・具体数値・本文H2のいずれかが下限を割っている
• 90字を超える文、または5文以上の段落が1件でもある
• 図解SVGが機械検品の基準（最小フォント14px以上・文字行34以内・図形34以内・role="img"と<title>と<desc>の完備・縦横比1.3以上）のいずれかを満たしていない
• frontmatterのdiagramsの宣言数と、本文中の図解プレースホルダの実数が食い違っている

原典照合と機械検証は、見ているものが違います。前者は「事実として合っているか」、後者は「形の下限を満たしているか」です。両方を1つの担当に任せると、自分が置いた前提を疑わないまま通してしまいます。

06批評だけを担当するAIエージェントは、記事制作の何を落とすんですか？

大森部長

大森部長の発言

機械の検査を通ったあとに、さらに否定する係を置く。工数として見合うんでしょうか。

鈴木さん

鈴木さんの発言

見合うと考えています。落ちるのは、たいてい機械が数えられない側です。ここを外すと、形の整った危ない原稿が、そのまま外へ出ていきます。

機械検証を通った記事は、devils-advocateという別人格の批評ワーカーへ渡ります。この工程の役割は「通す理由」ではなく「落とす理由」を探すことです。判定はPASS・CONDITIONAL・REJECTの3段階で出します。

社内では、記事が一見仕上がって見えても「100点でも120点」という言い方をしています。機械検証をすべて通った記事に対しても、批評ワーカーは次の改善点を最低1つ残すよう求められます。基準を満たした瞬間に考えるのをやめないための決めごとです。

次のいずれかに当てはまる記事は、この工程で即REJECTと判定します。

• ロゴが公式のものと違う、またはロゴがずれている
• 文字が画像やレイアウトで欠けている・重なっている
• 参照すべき素材・原本を確認せずに書いている
• 決められた保存場所と違う場所に置かれている
• 未確認の数字を言い切りで書いている
• 誇大な言い切りの表現が残っている

07AI活用で人が決める2箇所は、記事制作の分業体制のどこに残っているんですか？

大森部長

大森部長の発言

最後は人が見る、という説明はよく聞きます。実際にはどこを見ているんですか。

鈴木さん

鈴木さんの発言

2箇所です。出してよいかと、その事実で合っているか。この2つは、機械のほうが得意な仕事ではないので残しています。

ここまでの工程はすべてAI側が担当します。残る判断は、次だけを人に残しています。

この線引きは、技術の側にも置いてあります。Claude Codeの公式ドキュメントは、ツール実行の直前に発火するPreToolUseフックを定義しています。判定はallow（通す）・deny（止める）・ask（人に聞く）の3値で返します（出典: Claude Code公式ドキュメント）。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "公開・送信は人間の承認が必要です"
  }
}

「誰が書いたか」を出すこと自体にも根拠があります。Googleは、コンテンツの信頼性を判断する材料として、著者が誰かが訪問者にとって自明かどうかを重く見ると述べています（出典: Google Search Central）。AIの利用が自明かどうかも、同じ文脈で問われています。この記事は、その求めへの直接の返答にあたります。

08同じ範囲にAIエージェントが同時に着手する事故は、どう防いでいるんですか？

大森部長

大森部長の発言

並列で走らせるという話がありましたが、ぶつかることはないんですか。

鈴木さん

鈴木さんの発言

実際にぶつかりました。姉妹メディアの制作で、見張り役の処理と本体のセッションが同じ記事へ同時に手を入れて、記事3本が上書きされています。

原因は、複数の実行が同じ範囲へ同時に着手したことでした。どちらも仕様どおりに動いており、動作そのものは誤っていません。誤っていたのは、範囲の取り合いを誰も見ていなかったことです。

本誌では、執筆に着手する前に、担当範囲を宣言するファイル（WRITER_CLAIM_<範囲>_<日時>.md）を先に置きます。宣言のない範囲には、他のワーカーが着手しません。担当が重なる箇所をなくし、上書きそのものを起こさない形にしています。

分業体制というと役割の一覧を思い浮かべますが、実務で効くのはこの手の地味な取り決めです。誰が何をするかより、同時に触らないための手順のほうが、事故の数を左右します。

09パイロット記事の記録から、AI導入の分業体制は何が見えるんですか？

設計図だけでは、動いたかどうかは分かりません。第1弾のパイロット記事AGIM-701で、実際に何が起きたかを記録しています。

読み取れるのは、1回書いて終わりではない、という一点です。AGIM-701は改稿2回・批評2回を通り、この記録の時点でもまだ公開前の状態でした。

未確認のところは、埋めずに残してあります。2回目の指摘内訳は未公開で、※要確認のまま置いています。分からないことを分かったように書くと、ここまでの工程が全部むだになります。

10記事制作をAIエージェントに任せる現場で、つまずきやすいのはどこですか？

体制を作っても、次の4点でつまずきます。いずれも本誌で実際に起きたものです。

実測ではなく記憶で数字を書く。姉妹メディアの公開本数を「189本」と報告し、後の実測で251本と判明した例があります。要約の結果を一次情報として扱ったのが原因でした。以後、数値はsitemap.xmlなど原典を直接数える形へ変えています。

台帳の古い表記を鵜呑みにする。台帳に残っていた「blocked」という表記だけを根拠に、「1本も公開されていない」と報告した例があります。台帳の記述と本番の実測は、別々に確かめる必要があります。

型テンプレートの見出しをそのまま使う。記事型のテンプレート文言をそのまま見出しにすると、狙う語が目次から消えます。テンプレートはスロットの説明であって、見出し文そのものではありません。

図解を表の描き直しで済ませる。直上の表や箇条書きをそのまま絵にしただけの図は、情報量がないものとして扱います。図には、本文にない軸（時間軸・分岐・権限の区分など）を最低1本足します。

11公開の前に、AI社員へ渡した記事制作の何を見直すんですか？

最後に、体制そのものが守られているかを確かめます。原稿の出来ではなく、決めた手順どおりに通ったかを見る項目です。ここで引っかかると、内容が良くても差し戻しになります。

• frontmatterのauthorに「AGI Journal 編集部」が入っている
• primary_sourcesの原典と、書いた数値・主体・日付が合っている
• 自社の稼働実績は、実測台帳に記録された数値だけを使っている
• 未確認の数字・固有名詞にその旨の注記を付けている
• 批評の判定（PASS・CONDITIONAL・REJECT）に対応している
• 公開可否の最終承認を経ている
• 記事フッターの制作パイプライン表示が、実際に担当したAI・人と合っている

12よくある質問

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

分けているのは作業ではなく視点でした。落とす係を別に置き、人の判断は出してよいかと事実で合っているかの2箇所に絞る。順番はこの3つです。