01結論：AI社員の分業と、人が最後に握る判断

AI MARKETING JOURNALの記事は、AI社員が本文の大半を書き、人がその工程を設計します。執筆・原典照合・機械検証・批評までは、あらかじめ決めた基準に沿ってAI社員の分業で進みます。ただし一般公開の可否やCTAリンク先の確定など、基準そのものを動かす判断は、必ず鈴木晋介（監修者）が行います。

この記事では、実際の役割分担と機械検証の中身を、2026-08-07時点でリポジトリを直接確認した実測で示します。

02AIMJ編集部の分業体制｜誰が何を担当するか

本誌の制作体制は、単一のAIがすべてを書くのではなく、役割ごとに独立したAIを割り当てる設計です。Anthropicの公式ドキュメントは、こうした役割単位のAI（サブエージェント）が専用のシステムプロンプトとツール権限を持つと説明しています。独立した文脈で動作する設計です（出典: Anthropicの公式ドキュメント）。Anthropicの調査システムでも、役割ごとに独立したツールを持たせる設計が採用されています（出典: Anthropic「マルチエージェント調査システム」）。

本誌の実際の割り当ては次のとおりです。

  • Fable（ディレクター）：記事の設計・タスク分解・全体レビューを担当します。本文は執筆しません。
  • jp-writer（Sonnet・並列投入）：記事本文を執筆します。複数記事を同時並行で担当することがあります。
  • vault-researcher：一次情報源への照合、原典確認を担当します。
  • bulk-processor（Haiku）：棚卸しや機械的な整形など、判断を伴わない定型作業を担当します。
  • devils-advocate：執筆担当とは別人格として、提出前の記事を批評します。
  • 鈴木晋介（監修者・代表取締役）：全記事を監修し、公開可否を最終判断します。

執筆と評価を同じAIに両方任せない理由もあります。評価者と実行者を分離した構成は、単一モデルに両方任せるより高い性能を示すと言われています。Anthropicのエンジニアリング解説はこの点を述べています（出典: Anthropic Engineering）。devils-advocateがjp-writerと別人格である設計は、この考え方に沿っています。

分業体制の全体像、AI社員6工程と人が担う工程 設計・執筆・原典照合・機械検証・批評・監修の6工程を横一列に並べたフロー図。設計はFable、執筆はjp-writer、原典照合はvault-researcher、機械検証はQAスクリプト、批評はdevils-advocateが担当し、いずれも緑色でAIが担う工程として示される。最後の監修だけは鈴木晋介が担当し、橙色で人が担う工程として区別される。 分業体制の全体像 設計→執筆→原典照合→機械検証→批評→監修の6工程、AIと人の分担 ①設計 Fable ②執筆 jp-writer ③原典照合 vault- researcher ④機械検証 QAスクリプト ⑤批評 devils- advocate ⑥監修 鈴木晋介 AIが担当(5工程) 人が担当(1工程) AI社員5工程を経て、最後は鈴木晋介が公開可否を判断する 出典: Anthropic公式ドキュメント(sub-agents)・Anthropic Engineering解説
分業体制の全体像｜設計→執筆→原典照合→機械検証→批評→監修の6工程、AI社員5工程と鈴木晋介の監修1工程

03AI社員の分業と品質ラインの流れ

記事フォーマット標準は、記事が公開判断に届くまでの流れを次の順で定めています。

段階主体何を確認するか
執筆jp-writer構成・見出しのKW反映・出典記法
独立ファクトチェックvault-researcherprimary_sourcesの原典と数値・主体・日付の一致
機械検証QAスクリプト（次章）frontmatter必須項目・出典対応・図解仕様など
批評devils-advocate「甘くないか・日本最高レベルか」
reviewedへの昇格鈴木晋介上記すべてを通過したか

どこか一段階でも通らなければ、記事は前の段階へ差し戻されます。status: reviewedに上がるのは、この流れをすべて通過した記事だけです。

品質ラインの流れ、FAILは執筆へ差し戻し 執筆・独立ファクトチェック・機械検証・批評・reviewedの5段階を左から右へ実線の矢印で結んだ工程図。機械検証と批評の2段階でFAILした場合は、点線の矢印で執筆へ差し戻されることを示す。status: reviewedへ上がるのは、この5段階すべてを通過した記事だけである。 品質ラインの流れ 執筆→独立FC→機械検証→批評→reviewed、FAILは執筆へ差し戻し ①執筆 jp-writer ②独立FC vault- researcher ③機械検証 QAスクリプト ④批評 devils- advocate ⑤reviewed 全工程通過 ③④でNGが出ると①執筆へ差し戻す（点線矢印） 通過（合格） 差し戻し（不合格） status: reviewedに上がるのは、5段階を全通過した記事だけ
品質ラインの流れ｜執筆→独立FC→機械検証→批評→reviewed、機械検証・批評でFAILすると執筆へ差し戻し

04機械検証は今どこまで動いているか

品質ラインの「機械検証」で実際に何が動いているかは、申告ではなくリポジトリを見れば数えられます。2026-08-07時点でqa/配下に置かれている検証スクリプトは6本です（実測）。

スクリプト検証内容
verify_site.pyビルド全体の整合性・禁止表現の残留検知
verify_diagrams.py図解SVGの描画要素数・text要素数
check_internal_refs.py記事間参照『』の死にリンク検知
check_sources.py出典記法の機械強制（primary_sourcesとの対応など）
verify_quote_rendering.py引用ブロックの本文テキストが消えていないかの退行検知
verify_prepublish.py公開前検査（禁止表現・未実測の自社数値の突合など）

一方で、字数・要素数の型別下限を検証するcheck_density.pyは、2026-08-07時点でまだ実装されていません。この記事を含め、現時点の字数チェックは執筆者自身が規約と照合して行っています。実装済みと書かない理由は、この一点に尽きます。

設計文書の一つには、記事タイプの表示名に姉妹誌からの引き継ぎミスが残っていると記録されていました。本記事の執筆にあたって該当ファイル（lib/config.py）を直接確認したところ、その表示名は既に修正済みでした。記録と実装がずれていた一例です。

自分で確認したい場合は、次のように記事単体を検査できます。

$ python3 qa/check_sources.py 02_記事/AIMJ-1701_ai-staff-division-human-judgment.md

05人の判断が必ず入る5つの場面

機械検証と批評をすべて通過しても、次の判断は人に残ります。

判断ポイント内容
公開の実行ドメイン設定・本番デプロイの実行
一般公開の可否第1弾100本（記事マップ.csvに100件採番済み・2026-08-08実測）が完成した時点での公開判断
公開範囲の線引き顧客名・売上・restricted情報など、出す/出さないの最終判断
CTAリンク先の確定法人向け支援・講座の申込導線URLの確定
ブランド素材の支給監修者写真・ロゴなど公式素材の提供

これらに共通するのは、AIの判断だけでは後戻りできないという性質です。送信・公開・削除・決済・契約は、AI社員がどれだけ工程を回しても、常に人が最後に握ります。

境界図、AI社員の分業で進む範囲と人の判断が必ず入る範囲 縦の区切り線で左右2列に分けた図。左列はAI社員の分業で進む範囲で、設計・執筆・原典照合・機械検証・批評の5工程が入る。右列は人の判断が必ず入る範囲で、公開の実行・一般公開の可否・公開範囲の線引き・CTAリンク先の確定・ブランド素材の支給の5つの判断ポイントが入る。共通するのは、AIの判断だけでは後戻りできないという性質である。 境界図｜AIの分業と人の判断 後戻りできない操作は、常に人が最後に握る AI社員の分業で進む範囲 ①設計 ②執筆 ③原典照合 ④機械検証 ⑤批評 人の判断が必ず入る範囲 ①公開の実行 ②一般公開の可否 ③公開範囲の線引き ④CTAリンク先の確定 ⑤ブランド素材の支給 共通するのは、AIの判断だけでは後戻りできないという性質
境界図｜AI社員の分業で進む範囲（設計〜批評）と、人の判断が必ず入る5つの範囲（公開実行〜ブランド素材支給）

06なぜ「誰が書いたか」を公開するのか

Googleは検索セントラルの公式見解として、AI生成コンテンツそのものは違反ではなく、問題は価値を伴わない大量生成だと明言しています。同時に、コンテンツがどう作られたかを読者に伝えることは、読者の文脈理解に役立つとしています。これは開示の推奨にあたります（出典: Google Search Central・2025-12-10更新）。

本誌がこの記事を書いているのは、この推奨に沿うためです。「AIに書かせた記事」への警戒がある読者に対して、どこをAI社員の分業に任せ、どこから人が判断するのかを、抽象的な方針ではなく実際の役割名とスクリプト名で示します。

なお、記事ページの末尾には執筆者と監修者のクレジットが表示されます。ただしjp-writerやvault-researcherといった個別の役割名までは、2026-08-07時点でまだ読者向けには表示されていません。設計文書には役割名を出す構想が記されていますが、実装はまだ「編集部」「監修者」の2枠にとどまっています。この記事は、その差分を埋めるための最初の開示です。

07AI社員の分業でつまずきやすい点

  • 実測なしに「動いている」と書いてしまう：姉妹誌AGI Journalには、止まっていた自動化を「動いている」と書いた記事が、批評工程でlaunchctlの実測により差し戻された記録があります。本誌が実測を徹底するのは、同じ失敗を避けるためです。
  • 条文番号を確認せずに指摘してしまう：実在しない見出し番号を根拠にした指摘は、grepで実在確認できないため却下する運用にしています。
  • 未執筆の記事を『』で参照してしまう：本文中の『』参照はビルド時に自動でリンク化されますが、未執筆のタイトルはリンクにならず、読者には意味不明な括弧書きだけが残ります。
  • 機械検証を通過した図解でも、文字が重なっていることがある：要素数や文字サイズの検査を通っても、レイアウトの重なりは別途、目視で確認する必要があります。

08AI社員の分業チェックリスト

自社でAIに記事を書かせる場合も、次の項目は点検できます。

  • 誰が執筆し、誰が原典を照合したかを役割ごとに言えるか
  • 執筆と評価（批評）を同じAIに両方やらせていないか
  • 未実装の検証を「実装済み」と説明していないか
  • 数値の主張に出典（一次情報URLまたは自社実測＋日付）が付いているか
  • 公開・送信・削除など後戻りできない操作を、最終的に人が握っているか
  • AIが生成した記事に、誰が監修したかを明記しているか
  • 機械検証が通った成果物を、人が目視でも確認しているか

09FAQ

AI社員の分業とは具体的に何を指しますか？

本誌ではFable（設計）・jp-writer（執筆）・vault-researcher（原典照合）が工程を担当します。そのほかbulk-processor（定型作業）・devils-advocate（批評）という役割ごとのAIも工程を担当します。それぞれが独立した権限で工程を担当することを指します。

人が関与しない記事はありますか？

ありません。機械検証と批評を通過した記事も、最終的にreviewedへ上げるかどうかは鈴木晋介（監修者）の判断です。

機械検証をすべて通れば、人の判断なしで公開されますか？

されません。2026-08-07時点で6本のQA検証スクリプトが動いています（実測）が、公開の実行や公開範囲の線引きは、検証結果にかかわらず人が行います。

批評（devils-advocate）は何を見ているのですか？

正しいかどうかではなく、甘くないか・日本最高レベルかを見ます。事実関係の正しさは独立ファクトチェックの担当で、役割が重なりません。

誤りがあった場合、誰が責任を持ちますか？

監修者の鈴木晋介です。機械検証と批評は誤りを事前に減らす仕組みであり、誤りをゼロにする保証ではありません。

分業体制は今後変わりますか？

変わり得ます。check_density.pyのように設計はあっても未実装の検証があり、実装が進むにつれて機械検証が担う範囲は広がる見込みです。