この記事は誰が書いたのか｜AIの分業と、人が決める2箇所

この記事を含め、AGI Journalの記事はAIと人間が工程ごとに役割を分担する分業体制で作っています。構成・執筆・原典照合・機械検証・批評・監修の6工程を分け、人間が握るのは公開可否と事実の最終確認の2箇所だけです。パイロット記事の実際の制作記録も添えて示します。

01結論：AGI Journalの分業体制を3行で

AGI Journalの記事は6工程をAIが分担し、人間は公開可否と事実確認の2箇所だけを判断します。

1. 分業：構成・執筆・原典照合・機械検証・批評・監修の6工程に分けています。
2. 人間：判断するのは「公開してよいか」と「事実は正しいか」の2箇所だけです。
3. 記録：パイロット記事（AGIM-701）は改稿2回・批評2回を経た実測記録を公開しています。

この3行は宣言ではありません。以下、工程ごとの担当と、実際に起きた誤りをそのまま示します。

02記事ができるまでの分業体制｜6つの工程と担当

1本の記事は、次の6工程を順番に通ります。前の工程を満たさない限り、次の工程には進みません。

④と⑤でCONDITIONALまたはREJECT判定が出た記事は、②執筆へ差し戻されます。差し戻しは減点ではなく、この分業体制が設計どおり動いた証拠として扱っています。

6工程に分けている理由は、書いた本人が自分の誤りに気づきにくいためです。姉妹メディアAIO Journalの制作では、番犬プロセスと本体セッションが同じ記事を同時に書き、記事3本を上書きする事故が起きました。原因は、複数の実行が同じ範囲に同時着手したことです。

AGI Journalでは、執筆着手前に担当範囲を宣言するファイル（WRITER_CLAIM_<範囲>_<日時>.md）を先に置きます。宣言のない範囲には、他のワーカーが着手しません。これも分業体制の一部です。担当が重なる箇所を無くし、上書き事故そのものを起こさない設計にしています。

03構成と執筆を担当するAI｜分業体制の起点

構成を担当するFableは、Anthropicが「オーケストレーター・ワーカー」パターンと呼ぶ設計に沿っています。中央のLLMが複雑なタスクを動的に分解し、ワーカーLLMへ委譲し、結果を統合する仕組みです（出典：Anthropic公式）。

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

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

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

雑務を担当するワーカーも別にいます。記事マップの棚卸しや、frontmatterの形式チェックのような機械的な作業は、bulk-processor（Haiku、軽量モデル）が担当します。重い判断はSonnet、繰り返し作業は軽量モデルという分け方も、この分業体制の一部です。1つのモデルにすべてを任せず、作業の性質でモデルを分けることで、コストと精度のバランスを取っています。

04原典照合と機械検証｜役割分担のなかでAIが数字と仕様を洗う工程

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

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

機械検証はその後段です。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人（1体)のAIに任せると、自分が書いた前提を疑わないまま通してしまう恐れがあるため、担当を分けています。

05悪魔の代弁者による批評｜分業体制に必ず入る「否定する工程」

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

実例として、パイロット記事AGIM-701の1回目の改稿後、批評ワーカーは公式ドキュメントと自社の実測データに当たり、15件の指摘を出しました。うち4件は重大と判定されました。

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

この4件は、書いた本人であるAIには見えていませんでした。批評を別ワーカーが担当する理由は、ここにあります。

社内では、記事が一見完成しているように見えても「100点でも120点」という基準を置いています。機械検証をすべてPASSした記事に対しても、批評ワーカーは「次の改善点を最低1つ残す」ことを求められます。基準を満たした瞬間に思考を止めないための運用です。

以下のいずれかに1つでも当てはまる記事は、批評工程で即REJECTと判定します。

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

06人間が決める2箇所｜分業体制からあえて外した2つの権限

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

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

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

「誰が書いたか」を明示すること自体にも根拠があります。Googleは、コンテンツの信頼性を判断する材料として、著者が誰かが訪問者にとって自明かどうかを重視すると述べています(出典：Google Search Central)。AI生成の利用が自明かどうかも同じ文脈で問われています。この記事の制作パイプライン表示は、その透明性要求への直接の回答です。

事実の最終確認を人間に残す理由も同じ発想です。原典照合と機械検証は機械的に再現できますが、「この数字を今回の文脈で使ってよいか」という判断は、正本データを知っている人にしか下せません。AGI Journalでは、02-company_knowledge配下の定量実績を唯一の根拠とし、監修時に改めて突合しています。公開・送信・削除・決済といった操作を自動実行しないという方針も、この2箇所の判断と表裏の関係にあります。

07パイロット記事に見る制作パイプラインの実例｜AGIM-701の記録

分業体制は設計図だけではありません。第1弾のパイロット記事であるAGIM-701（用語辞典型・ピラー記事）で、実際にどう動いたかを記録しています。

この記録からわかるのは、制作パイプラインが「1回書いて終わり」ではないという点です。AGIM-701は改稿2回・批評2回を経ており、この記事の執筆時点でもまだstatus: reviewedには達していません。

もう一つ、実測台帳が記録した誤りがあります。姉妹メディアの公開本数を確認した際、最初は本番トップページのWebFetch要約に出た「189本」という数字をそのまま報告し、検証していませんでした。実測はsitemap.xmlを数えた251本でした。要約ツールが返した数値を一次情報として扱わないことが、この失敗から加わったルールです。

08分業体制でつまずきやすい点

分業体制を作っても、次の4点でつまずくことがわかっています。

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

台帳の古い表記を鵜呑みにする：稼働状況を管理する台帳に残っていた「blocked」という古い表記だけを根拠に、「1本も公開されていない」と報告した例があります。実際は251本が公開済みでした。台帳の記述と本番環境の実測は、別々に確認する必要があります。

型テンプレートの見出しをそのまま使う：記事型のテンプレート文言（「何が起きたか」「よくある誤解」など)をそのまま見出しにすると、狙うキーワードが目次から消えます。テンプレートはスロットの説明であり、見出し文そのものではありません。

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

09チェックリスト

記事を公開ラインに乗せる前に、この分業体制が守られているかを次で確認します。

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

10FAQ