AI編集部を作る① 全体像 — 月曜9時3分、無人のClaude Codeが編集会議を開く

2026年8月24日、月曜の朝9時3分。筆者のPCでは今週も、無人の Claude Code が編集部を開いた。開いた、はずだった。この日の編成会議は、レポートを1本も書かないまま静かに終わる。うまく回る週なら、ニュース候補の収集から編成会議、採用の決定、記者の下書き、校閲の検品まで人間は登場しない。この連載は、Windows のタスクスケジューラと Claude Code のヘッドレス実行で組んだ「AI編集部」の作り方を、実測値と失敗込みで公開していく。第1回は全体像と、冒頭の事故の顛末。

何を作ったか — 週次ニュース記事の工程を部署に分けた

当サイトは週3本のニュース解説記事を出している。元の工程は、候補収集・選定・執筆・校閲・配信予約のすべてが筆者とAIの対話作業だった。対話でやる限り、毎週月曜の午前が同じ判断の繰り返しで消える。候補を検索する、基準に照らして3本選ぶ、記事の角度を決める、下書きを読んで差し戻す。どれも2回目以降は判断基準が固定されている作業で、固定された判断を人間が毎週なぞるのは工数の無駄以上に、基準がその日の気分で揺れる原因にもなっていた。

判断基準を文章に固定できる工程は、エージェントの指示書に固定してしまえばいい。そう割り切って、工程を部署として切り出し、タスクスケジューラの週次ジョブに乗せた。

構成は2段になっている。前半はパイプライン8ステップで、ネタ帳の収集から自動承認までを cmd が順に起動する。8本目の自動承認が後半の「編集部」を起動し、5つの部署（記者・校閲・SEO・SNS・収益分析）のエージェントが順に走る。

部署はそれぞれ Claude Code のエージェント定義（Markdown ファイル1枚）で、持てるツールを絞ってある。記者は Write を持つが WP への投稿手段を持たない。校閲は記者と独立に読み、WebFetch で一次ソースへ当たれる。役割をファイルで分けたのは、1つの万能エージェントに全部やらせると、書いた本人が自分の記事を「問題なし」とレビューする構図になるからだ。

エージェントが動くステップ（候補収集・編成会議・編集部の5部署）は claude -p（ヘッドレス実行）で起動し、許可ツールは起動側（cmd や Python）が明示的に渡す。残りのステップ（ネタ帳収集・事実検査・事務局3本・自動承認そのもの）は素の Python スクリプトで、LLM を使わない。無人実行では対話の確認ダイアログが出せないので、許可リストに無いコマンドは自動拒否になる。この設計は安全装置として働く反面、許可リストの漏れが「確認できないまま止まる」障害に化ける。編成会議のエージェントに同時実行を確かめさせたくてプロセス一覧のコマンドを指示したとき、そのコマンド自体を許可リストに入れ忘れると、エージェントは確認ができないまま保守側に倒れ、何もせず終わる。無人システムの許可リストは、エージェントへの指示文と必ずセットで育てることになる。

もう1つ、部署の暴走に対する保険として書込範囲ガードを入れてある。各部署の実行前後でリポジトリ内ファイルの内容ハッシュを比較し、その部署が書いてよい範囲（記者なら下書きフォルダ）の外に差分が出たら、成果物ごとブロックする仕組みだ。git status の比較では足りない。実行前から未追跡だったファイルへの上書きは status の見た目が変わらないからで、内容ハッシュまで見て初めて検出できる。このガードには「実行中に人間がリポジトリを触っても全部署ブロックになる」という副作用もあって、編集部が走っている80分は筆者もリポジトリに触らないルールで運用している。詳細は記者・校閲の回で書く。

実測タイムライン — 完全無人で回った週

2026年8月17日の月曜は、人間が一度も触らずに完走した。ログの実測タイムラインはこうなっている。

週の実費はネタ帳収集の API 利用 $0.04 と、Claude Code の定額枠の消費だけ。終わると筆者のメールボックスに、承認された記事タイトルと5部署の完了報告が届いている。朝のコーヒーの間に編集部が一巡している計算になる。

線引き — 機械に判定できることだけを自動承認する

この仕組みで一番考えたのは、どこまでを無人にするかの線引きだった。答えは「機械が確実に判定できる工程だけを自動化し、運用判断は人に残す」。具体的には3つの縛りを入れてある。

採用の書式は1つしか認めない。自動承認が読むのは編成会議レポートの「記者への指示」節にある 1. **cl-01** という厳格な番号付きリストだけで、正規表現は ^\s*\d+\.\s+\*\*([a-z]{2}-\d{2})\*\* の1本。書式が少しでも崩れた週は採用0件と解釈され、編集部は起動しない。曖昧に解釈して動くより、止まって人を呼ぶほうが安い。

承認は最大3件。配信ペース（週3本）と揃えた上限で、レポートがどれだけ推しても4本目は承認されない。

レポートの「承認待ち事項」（新企画の可否・方針変更のような運用判断）は自動承認の対象外にした。ここを機械に任せると、編集部が自分の権限を自分で広げていける構図になる。判断したい週は、手元の承認UI（ローカルの office.html）から人間が承認する経路を残してある。

初回から事故った — 編集会議が自分のログに怯えて何も書かなかった

冒頭の8月24日に戻る。この日の朝の運転は、編成会議のステップが1本のレポートも書かないまま正常終了した。

ログを読むと、会議を担当したエージェントはジョブのログファイルを開き、末尾の agenda start という行を見て「別の無人ジョブがいま走っている。ここで書くと二重書き込みになる」と推論し、遠慮して何もせず終わっていた。その agenda start 行は、自分自身を起動したステップがつい数十秒前に書いたものだ。鏡に映った自分を侵入者だと思って、家に入らなかったことになる。

被害は限定的だった。続く事実検査が「レポートが無い」を exit 1 で検出し、自動承認もレポートを読めないまま安全側に倒れて、「未起動」のメール通知だけを出して終了した。編集部は起動していない。上流が失敗した週は自動承認を丸ごとスキップする仕組みも別にあるが、この週は編成会議が exit 0 で正常終了を装ったため働かなかった。いまは編成会議の成果物ファイルを更新時刻で裏取りし、書かれていなければステップ自体が非ゼロで終わる対策を入れてある。午後に筆者が手動で復旧し、編成会議のやり直しに約24分、編集部の実行に80分42秒。5部署は完走し、書込範囲の逸脱も0件だった（実行台帳の実測値）。

対策はログの側に入れた。いまの agenda start 行には「この行を読んでいるエージェントは、このステップ自身である。別プロセスではない」という但し書きが書き込まれる。同時実行を本当に疑う場合の確認手段（プロセス一覧の実測）も、エージェントへの指示に足した。無人システムの障害対応は、コードを直すより「エージェントが何をどう誤読したか」を突き止めて説明を直す作業になることが多い。この事故はその典型だった。

この連載で書いていくこと

第2回以降は、部署を1つずつ実装の詳細に降りていく。予定している範囲は、候補収集と実体験基準の自動選定、編成会議レポートの設計と事実検査、記者・校閲と書込範囲ガード（部署が想定外のファイルを書いたら止める仕組み）、配信予約と公開後検証、そして運用1か月の事故カタログ。すべて実際に動いているコードとログを根拠に書く。

ヘッドレス実行の公式仕様は Claude Code の headless mode ドキュメント が一次情報になる。複数エージェントを1画面で扱うアプリの作り方は「Claude Mission Control 開発記」、ジョブから呼ぶ処理の MCP サーバー化は「ローカルMCPサーバーのジョブ実行パターン」で書いている。

まとめ

週次のニュース工程は、収集から校閲まで無人で回るところまで来た。成立させた要点は自動化の技術よりも線引きで、機械が確実に判定できる工程（書式の一致・件数の照合・完了の検出）だけを自動承認し、運用判断は人の承認経路に残す。初回の事故が示したとおり、この線引きは安全装置としても働く。書式が崩れた週・上流が失敗した週に、編集部は動かず止まって人を待つ。無人化の設計は「どう動かすか」より「どう止まるか」から決めると壊れにくい、というのが第1回の結論だ。