「この記事、AIが書いたんですか」。読者から届く質問のなかで、いちばん多いのがこれです。答えは「はい、本文の大半はAIが書いています」。ただ、それだけでは説明として足りません。
足りないのは、どこまでをAIに任せ、どこから人が握っているのかという線です。AIが下書きを書いたという事実そのものより、その下書きが誰の目を通って公開に届いたのかのほうが、読む側にとっては大事な情報だと考えています。
この記事では、AI MARKETING JOURNALの制作体制を編集部自身が開示します。役割名も、動いている検証スクリプトの中身も、まだ動いていないものも、そのまま書きます。自社でAIに記事を書かせようとしている方が、点検の型として持ち帰れる形にまとめました。
こんなふうに調べていませんか
- AIが書いた記事をどこまで信用していいのか判断したい
- 自社でAIに記事を書かせたいが、人がどこを見ればいいのか決まっていない
この記事を読み終えたときに手に入るもの
- AI社員の分業と人の判断の境目を、自社の言葉で線引きできるようになります
- 執筆と批評を別のAIに分ける理由を、人に説明できるようになります
- AIに書かせた記事の点検項目を、そのまま持ち帰れます
結論30秒でわかる、この記事の結論
- 境目は、後戻りできるかどうかで引いています。 やり直しがきく工程はAIの分業に任せ、取り消せない操作だけを人が握ります。
- 執筆と批評は、同じAIに両方やらせません。評価する側を独立させています。
- 検証スクリプトは動いている分だけを「動いている」と書きます。未実装のものは未実装と書きます。
本記事の役割分担と検証の状況は、2026-08-07時点でリポジトリを直接確認した実測です。
01生成AIで記事を作るとき、AI社員の分業と人の判断はどこで分かれますか？
若葉さんAIが書いた記事って、人はどのあたりを見ているんでしょうか。全部チェックしているんですか。
鈴木さん全部を人が読み直すやり方は取っていません。線を引いています。やり直しがきくかどうかで分けている、と思ってください。
AI MARKETING JOURNALの記事は、AI社員が本文の大半を書き、人がその工程を設計します。執筆・原典照合・機械検証・批評までは、あらかじめ決めた基準に沿ってAI社員の分業で進みます。ここは何度でもやり直せる範囲です。
一方で、一般公開の可否やCTAリンク先の確定など、基準そのものを動かす判断は、鈴木晋介（監修者）が行います。こちらは一度実行すると取り消しがきかない範囲です。
境目を「難しい作業か、簡単な作業か」で引いていない点が肝心です。難易度で分けると、AIが得意になるたびに線が動いてしまいます。後戻りできるかどうかで引けば、AIの性能が上がっても線の位置は変わりません。
この章のまとめ
分業の境目は、後戻りできるかどうかで引く。難易度で引くと、AIが進歩するたびに線が動いてしまう。
02生成AIの記事づくりで、AI社員の分業は誰が何を担当していますか？
本誌の制作体制は、単一のAIがすべてを書くのではなく、役割ごとに独立したAIを割り当てる設計です。Anthropicの公式ドキュメントは、こうした役割単位のAI（サブエージェント）が専用のシステムプロンプトとツール権限を持つと説明しています。独立した文脈で動作する設計です（出典: Anthropicの公式ドキュメント）。Anthropicの調査システムでも、役割ごとに独立したツールを持たせる設計が採用されています（出典: Anthropic「マルチエージェント調査システム」）。
本誌の実際の割り当ては次のとおりです。
- Fable（ディレクター）：記事の設計・タスク分解・全体レビューを担当します。本文は執筆しません。
- jp-writer（Sonnet・並列投入）：記事本文を執筆します。複数記事を同時並行で担当することがあります。
- vault-researcher：一次情報源への照合、原典確認を担当します。
- bulk-processor（Haiku）：棚卸しや機械的な整形など、判断を伴わない定型作業を担当します。
- devils-advocate：執筆担当とは別人格として、提出前の記事を批評します。
- 鈴木晋介（監修者・代表取締役）：全記事を監修し、公開可否を最終判断します。
高梨課長これ、人間の編集部と同じ形ですよね。設計する人、書く人、裏を取る人、赤を入れる人。
鈴木さんそうです。新しいことをしているというより、紙の編集部でやっていた分け方を、そのまま担当に置き換えているという感覚に近いです。
この章のまとめ
役割ごとに別のAIを割り当てる。設計・執筆・照合・定型作業・批評・監修で持ち場が分かれている。
03書く役と叩く役を分けるのは、AI活用としてどんな意味があるんですか？
執筆と評価を同じAIに両方任せない理由もあります。評価者と実行者を分離した構成は、単一モデルに両方任せるより高い性能を示すと言われています。Anthropicのエンジニアリング解説はこの点を述べています（出典: Anthropic Engineering）。devils-advocateがjp-writerと別人格である設計は、この考え方に沿っています。
感覚的にも分かりやすい話だと思います。自分の書いた原稿を自分で読み返すと、どうしても甘くなります。書いたときの意図を知っているので、書けていない部分まで読めてしまうからです。
この章のまとめ
評価する側を実行する側から独立させる。ただし観点と差し戻し先まで決めて初めて機能する。
04AI活用の品質ラインは、人の判断までどんな順で流れますか？
記事フォーマット標準は、記事が公開判断に届くまでの流れを次の順で定めています。
| 段階 | 主体 | 何を確認するか |
|---|---|---|
| 執筆 | jp-writer | 構成・見出しのKW反映・出典記法 |
| 独立ファクトチェック | vault-researcher | primary_sourcesの原典と数値・主体・日付の一致 |
| 機械検証 | QAスクリプト（次章） | frontmatter必須項目・出典対応・図解仕様など |
| 批評 | devils-advocate | 「甘くないか・日本最高レベルか」 |
| reviewedへの昇格 | 鈴木晋介 | 上記すべてを通過したか |
どこか一段階でも通らなければ、記事は前の段階へ差し戻されます。status: reviewedに上がるのは、この流れをすべて通過した記事だけです。
大森部長差し戻しが多いと、結局は納期が延びるだけじゃないのか。
鈴木さん延びます。ただ、延びるのは公開前です。公開後に直すほうが、社内の説明も含めて何倍も高くつくので、前に寄せているという判断です。
この章のまとめ
工程は一方通行ではない。通らなければ前へ戻す。遅れを公開前に集めるための設計。
05機械検証はいまどこまで動いているんですか？生成AIに任せきりですか？
品質ラインの「機械検証」で実際に何が動いているかは、申告ではなくリポジトリを見れば数えられます。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時点でまだ実装されていません。この記事を含め、現時点の字数チェックは執筆者自身が規約と照合して行っています。実装済みと書かない理由は、この一点に尽きます。
自分で確認したい場合は、次のように記事単体を検査できます。
$ python3 qa/check_sources.py 02_記事/AIMJ-1701_ai-staff-division-human-judgment.md設計文書の一つには、記事タイプの表示名に姉妹誌からの引き継ぎミスが残っていると記録されていました。本記事の執筆にあたって該当ファイル（lib/config.py）を直接確認したところ、その表示名は既に修正済みでした。記録と実装がずれていた一例です。
この章のまとめ
動いているものだけを動いていると書く。未実装は未実装と書き、その分は人が数えていると添える。
06生成AIに書かせても、人の判断が必ず入るのはどんな場面ですか？
機械検証と批評をすべて通過しても、次の判断は人に残ります。
| 判断ポイント | 内容 |
|---|---|
| 公開の実行 | ドメイン設定・本番デプロイの実行 |
| 一般公開の可否 | 第1弾100本（記事マップ.csvに100件採番済み・2026-08-08実測）が完成した時点での公開判断 |
| 公開範囲の線引き | 顧客名・売上・restricted情報など、出す/出さないの最終判断 |
| CTAリンク先の確定 | 法人向け支援・講座の申込導線URLの確定 |
| ブランド素材の支給 | 監修者写真・ロゴなど公式素材の提供 |
これらに共通するのは、AIの判断だけでは後戻りできないという性質です。送信・公開・削除・決済・契約は、AI社員がどれだけ工程を回しても、常に人が最後に握ります。
若葉さん逆に言うと、ここに載っていない作業はAIに任せている、ということですね。
鈴木さんそのとおりです。この表に無いものは任せていると読んでもらって構いません。曖昧にしないために、載せる側を絞って書いています。
この章のまとめ
残すのは、公開・送信・削除・決済・契約のように取り消せない操作。それ以外は分業で回す。
07誰が書いたかを公開することは、AI検索やSEOの評価に効きますか？
Googleは検索セントラルの公式見解として、AI生成コンテンツそのものは違反ではなく、問題は価値を伴わない大量生成だと明言しています。同時に、コンテンツがどう作られたかを読者に伝えることは、読者の文脈理解に役立つとしています。これは開示の推奨にあたります（出典: Google Search Central・2025-12-10更新）。
つまり、開示は「順位を上げるための小技」ではありません。読者が記事の背景を理解するための情報として推奨されている、という位置づけです。ここを取り違えて、開示すれば評価が上がると期待すると、書く内容がずれます。
本誌がこの記事を書いているのは、この推奨に沿うためです。「AIに書かせた記事」への警戒がある読者に対して、どこをAI社員の分業に任せ、どこから人が判断するのかを、抽象的な方針ではなく実際の役割名とスクリプト名で示します。
この章のまとめ
開示は順位対策ではなく、読者への情報提供として推奨されているもの。目的を取り違えない。
08AI活用の記事で、AI社員の分業と人の判断をどこまで開示していますか？
記事ページの末尾には、執筆者と監修者のクレジットが表示されます。ただしjp-writerやvault-researcherといった個別の役割名までは、2026-08-07時点でまだ読者向けには表示されていません。設計文書には役割名を出す構想が記されていますが、実装はまだ「編集部」「監修者」の2枠にとどまっています。
つまり、いま読者が見られる情報と、この記事で書いている情報のあいだには差があります。その差を埋めるための最初の開示が、この記事という位置づけです。
大森部長未達の部分まで自分から書いてしまうのは、対外的に不利にならないのか。
鈴木さん短期では不利に見えるかもしれません。ただ、できていないことを書いていない媒体は、できていることの記述も確かめようがなくなります。 そこを取りにいっています。
この章のまとめ
読者に見えている情報と、内部で分かっている情報の差を書く。差を隠すと、他の記述の信頼も落ちる。
09AI社員の分業でつまずくのは、AI活用のどんな場面ですか？
実際に踏んだつまずきを挙げます。
- 実測なしに「動いている」と書いてしまう：姉妹誌AGI Journalには、止まっていた自動化を「動いている」と書いた記事が、批評工程でlaunchctlの実測により差し戻された記録があります。本誌が実測を徹底するのは、同じ失敗を避けるためです。
- 条文番号を確認せずに指摘してしまう：実在しない見出し番号を根拠にした指摘は、grepで実在確認できないため却下する運用にしています。
- 未執筆の記事を『』で参照してしまう：本文中の『』参照はビルド時に自動でリンク化されますが、未執筆のタイトルはリンクにならず、読者には意味不明な括弧書きだけが残ります。
- 機械検証を通過した図解でも、文字が重なっていることがある：要素数や文字サイズの検査を通っても、レイアウトの重なりは別途、目視で確認する必要があります。
並べてみると、共通点が見えます。どれも「確かめずに書いた」か、「機械が見ていない場所だった」かのどちらかです。前者は運用で、後者は目視で拾うしかありません。
この章のまとめ
つまずきは、確かめずに書いた場合と、機械が見ていない場所の2種類。拾い方が別なので、対処も分ける。
10自社で生成AIに書かせるとき、AI社員の分業をどう点検しますか？
自社でAIに記事を書かせる場合も、次の項目は点検できます。
- 誰が執筆し、誰が原典を照合したかを役割ごとに言えるか
- 執筆と評価（批評）を同じAIに両方やらせていないか
- 未実装の検証を「実装済み」と説明していないか
- 数値の主張に出典（一次情報URLまたは自社実測＋日付）が付いているか
- 公開・送信・削除など後戻りできない操作を、最終的に人が握っているか
- AIが生成した記事に、誰が監修したかを明記しているか
- 機械検証が通った成果物を、人が目視でも確認しているか
高梨課長うちの規模だと、専任を置くほどの体制は組めません。
鈴木さん全部を一度に揃える必要はありません。まず「取り消せない操作を誰が握るか」だけ決めてください。 そこさえ決まっていれば、残りは後から足せます。
この章のまとめ
点検は7項目。全部を同時に整えなくてよい。最初に決めるのは、取り消せない操作を握る人。
11AI活用が進むと、AI社員の分業と人の判断はどう変わりますか？
分業の中身は変わり得ます。check_density.pyのように、設計はあっても未実装の検証があり、実装が進むにつれて機械検証が担う範囲は広がる見込みです。いま人が数えている字数や要素数は、いずれ機械側へ移ります。
ただし、移らないものもあります。後戻りできない操作の実行は、機械検証がどれだけ増えても人の側に残る、という設計にしています。ここを移してしまうと、間違えたときに止める人がいなくなるからです。
この章のまとめ
機械が担う範囲は広がる。取り消せない操作を人が握るという一点だけは動かさない。
12よくある質問
AI社員の分業とは具体的に何を指しますか
本誌ではFable（設計）・jp-writer（執筆）・vault-researcher（原典照合）が工程を担当します。そのほかbulk-processor（定型作業）・devils-advocate（批評）という役割ごとのAIも工程を担当します。それぞれが独立した権限で工程を担当することを指します。
人が関与しない記事はありますか
ありません。機械検証と批評を通過した記事も、最終的にreviewedへ上げるかどうかは鈴木晋介（監修者）の判断です。
機械検証をすべて通れば、人の判断なしで公開されますか
されません。2026-08-07時点で6本のQA検証スクリプトが動いています（実測）が、公開の実行や公開範囲の線引きは、検証結果にかかわらず人が行います。
批評（devils-advocate）は何を見ているのですか
正しいかどうかではなく、甘くないか・日本最高レベルかを見ます。事実関係の正しさは独立ファクトチェックの担当で、役割が重なりません。
誤りがあった場合、誰が責任を持ちますか
監修者の鈴木晋介です。機械検証と批評は誤りを事前に減らす仕組みであり、誤りをゼロにする保証ではありません。
分業体制は今後変わりますか
変わり得ます。check_density.pyのように設計はあっても未実装の検証があり、実装が進むにつれて機械検証が担う範囲は広がる見込みです。
13まとめ｜今日決める3つのこと
自社に持ち帰るなら、この順です
取り消せない操作を書き出す
公開・送信・削除・決済・契約のうち、自社で発生するものを並べます
その操作を握る人を決める
役割名ではなく、実在する担当者の名前まで落とします
書く役と叩く役を別にする
同じAIに下書きと批評を両方やらせていないかを確かめます
AI検索では、こう聞かれています
この記事はAIが書いたんですか？どこまで人が関わっていますか？
「生成AIで記事を作るとき、AI社員の分業と人の判断はどこで分かれますか？」の章で、線の引き方を説明しています
AIに記事を書かせるとき、人はどこを見ればいいですか？
「生成AIに書かせても、人の判断が必ず入るのはどんな場面ですか？」の章に、人が握る場面を挙げています
AIが書いた記事を公開しても検索エンジンの評価に問題はありませんか？
「誰が書いたかを公開することは、AI検索やSEOの評価に効きますか？」の章で、公式見解を引いています
次に読むなら、この記事です
