この記事は Claude Code でブログ執筆をしている方を対象にしています。 Claude Code のマルチエージェント構成（CEO・writer・reviewer 等）を用いた執筆ワークフローを前提にしており、構成の詳細は以下の記事を参照してください。

Claude Code でAIチームを組織した — CEO・DevOps・Writer・Researcher の役割分担と運用設計

Claude Code のエージェントに /todo を持たせたら、1日で記事3本+実装3件が回った話

複数プラットフォームに記事を投稿していると、どこかで必ず迷子になる。

Zenn で published: true にしたはずなのに公開されていない。Qiita に投稿したはずの記事が 404 になっている。ドラフトが2か所に分散していて、どちらが最新か分からない。

「ブログ記事の管理が難しくなっている」——そう感じたのをきっかけに、記事ファイル自体に状態を持たせて管理するシステムを作った。この記事では、その設計思想と実装を紹介する。

1. 何が混乱していたか

Claude Code でブログを書き始めて2〜3週間が経ったとき、管理の綻びが出始めた。

ドラフトの分散。記事の下書きが content/writing/articles/（作業ディレクトリ）と ~/Documents/blog-drafts/（旧ディレクトリ）の2か所に散らばっていた。移行漏れが原因だ。どちらが最新版か、都度確認しなければならない状態になっていた。

Zenn のサイレントブロック。published: true に変えて push したのに、翌日確認すると記事が公開されていない。エラーメッセージも通知もない。Zenn には24時間に1記事しか公開できない制限があり、それに引っかかるとエラーなしで 404 になる。これを踏んで初めて制限の存在を知った。

Qiita の謎 404。クロスポスト済みのはずの記事が Qiita で 404 になっているケースがある。原因は調査中（[要確認]）。投稿制限に引っかかっている可能性が高いが、現時点では特定できていない。

こういった問題が1か所で把握できない状態が続いていた。

2. 設計思想：「記事はオブジェクト」

このシステムの中心にある考え方は単純だ。

記事ファイル自体が、その記事の状態を知っている。

オブジェクト指向で言えば、frontmatter が属性（プロパティ）、本文がコンテンツ、スクリプトがメソッドに相当する。記事の「今どういう状態か」は、記事ファイルを見れば分かる。外部のスプレッドシートや Notion を参照する必要はない。

「Notion で良くない？」と思った方へ。Notion 管理には大きな制約がある。Git 管理できない、AI エージェントがファイルとして直接読み書きできない、CI/CD に乗せられない。この3点が今の運用では致命的だった。Claude Code のエージェントが記事ファイルを直接読んで frontmatter を更新する、という操作が自然にできることが前提にある。

Claude Code を使った AI 駆動の開発・運用に興味がある方には、Claude CodeによるAI駆動開発入門（平川知秀著）が参考になる。Kindle で読めるので手軽に確認できる。

3. 記事ファイルの構造：2層の状態管理

記事ファイルは2層の状態管理を持っている。

---
title: "記事タイトル"
emoji: "🤖"
type: "tech"
topics: ["claudecode"]
published: false
---
<!-- from: writer | to: reviewer | status: draft | source_netacho: netacho-xxx.md -->

本文...

frontmatter 層（--- で囲まれた部分）は Zenn の標準フォーマットそのままだ。published フィールドが Zenn での公開状態を直接制御する。プラットフォームと共有する情報をここに置く。

HTML コメント層は、ワークフロー管理のためだけに存在する。エージェント間の引き継ぎ（from / to）、記事の制作状態（status）、出典ネタ帳との紐付け（source_netacho）を記録する。本文に混入しても表示には出ないが、スクリプトや AI エージェントは読み取れる。

クロスポスト後は crosspost.sh が自動で crosspost_at: 2026-04-19 のようなフィールドを追記する。

4. article-status.sh の使い方

このシステムはプロジェクトの scripts/ ディレクトリに置いてあるシェルスクリプトだ（リポジトリは非公開）。以降ではスクリプトの設計と使い方を紹介するので、同じ構成を自分のリポジトリで再現してほしい。

bash scripts/article-status.sh              # content/article-status.md を更新
bash scripts/article-status.sh --dry-run    # stdout のみ（ファイル書き込みなし）
bash scripts/article-status.sh --check-urls # 公開失敗（404/Zenn未反映）を検知

スクリプトは792行（実測）。Zenn リポジトリ・Qiita リポジトリ・はてなコンテンツディレクトリの3か所を走査して、記事ごとの公開状態を自動的に集計する。

生成される content/article-status.md の構造はこうなっている。

セクション	内容
🎯 クロスポスト済	はてな + Zenn + Qiita の全プラットフォームで公開完了
🌐 公開済・クロスポスト残り	はてな公開済、Zenn/Qiita のどちらかが未公開
🌐 公開済・はてな未投稿	Zenn のみ公開、はてなが未公開
📝 はてな Draft 登録済み	blogsync で下書き送付済み、本番公開前
🔧 ドラフト作成中	`content/writing/articles/` 配下で執筆中
📰 はてなオリジナル	Zenn 対応なし（はてな専用記事）
公開履歴（月別）	はてな公開日昇順の全件一覧
EDITABLE_NOTES	エージェントが書いた注釈（スクリプト再生成後も保持）

実際の出力例（--dry-run で確認した抜粋）：

## 🎯 クロスポスト済（10本）

| タイトル | はてな | Zenn | Qiita | 出典 |
|---|---|---|---|---|
| Claude Code GTDスキルにPro機能を実装した話 | [2026-04-07](...) | [Zenn](...) | [Qiita](...) |  |
...

## 🔧 ドラフト作成中（4本）

| タイトル | スラッグ/場所 | ステータス | 出典 |
|---|---|---|---|
| Claude Code 実用TIPS集 | ローカル | draft |  |
...

--check-urls オプションを使うと curl で各 URL の HTTP ステータスを確認し、404 の記事に ⚠Qiita 404 のようなフラグを付ける。Zenn については RSS フィードを取得して published: true なのに RSS に存在しない記事を ⚠Zenn未反映 として検知する。冒頭で触れた「公開されていない謎」の多くはこれで見つかった。

EDITABLE_NOTES セクションはスクリプトが保護する特別な領域だ。スクリプトを何度実行しても、このセクション以降の内容は上書きされない。エージェントが書いた注釈（「Qiita 404 → 2026-04-20 に再投稿予定」など）が消えないように設計してある。

5. ネタ帳（netacho）の管理

ネタ帳ファイルは content/writing/netacho/ 配下に置く Markdown ファイルだ。記事に育てる前のアイデアをここで管理する。

---
from: CEO
to: writer
status: ready
maturity: ready      # raw → thin → ready の3段階
spawned_slugs:       # 記事化したら slug を追記
  - claude-code-xxx
---

maturity フィールドが3段階の熟成度を表す。raw は思いついたばかりのメモ、thin は骨格が見えてきた状態、ready は執筆着手できる状態だ。CEO エージェントが定期的にネタ帳を見て、maturity: ready になったものを writer に回す。

spawned_slugs には記事化した Zenn スラッグを書く。article-status.sh がこのフィールドを読んで、記事一覧の「出典」カラムにネタ帳ファイル名を表示する。記事がどのアイデアから生まれたか、後から辿れるようになる（一方向のリンク）。

6. Playbook の全体像

システムの運用は3つのファイルで定義されている。

ops/playbooks/article/
├── update-conventions.md   # 誰が・いつ・何を更新するか の一覧
├── netacho-management.md   # ネタ収集〜記事化の運用手順
└── quality-gate.md         # 各フェーズへのリンクハブ

読み順は update-conventions.md → netacho-management.md → quality-gate.md の順を推奨する。

update-conventions.md は全フェーズの更新規約をテーブルにまとめたリファレンスだ。「ネタ帳の status は誰が変えるのか」「はてな下書き登録後に何を更新するか」が一覧で確認できる。

netacho-management.md はネタ収集から記事化までの具体的な操作手順を書いた Playbook だ。maturity の昇格基準、writer への引き継ぎ方法、spawned_slugs の更新タイミングを定義している。

quality-gate.md は各フェーズ（執筆・ファクトチェック・リーダーレビュー・公開）へのリンクハブだ。記事制作の全体像を把握したいときの起点になる。

7. まとめ：まだ導入直後の正直な評価

このシステムを作ったのは 2026-04-19 の今日だ。定量的な効果（「週何時間短縮できた」）はまだ測れない。

感覚として変わったのは管理ミスへの不安が減ったことだ。以前は記事36本（本記事を除く）の公開状態を確認するのに、1日あたり体感で15分ほどかかっていた。「あの記事 Zenn に上げたっけ？」「Qiita の投稿ミスしてないか？」という確認がそれだけの時間を取っていた。article-status.sh を実行すれば全記事の状態が一覧で出てくるので、その時間がほぼゼロになった。

未解決の課題は2つある。

ひとつは Qiita 404 問題。いくつかの記事が Qiita で 404 になっている。原因は調査中（[要確認]）。--check-urls で検知はできるが、再投稿フローが手動なのでここは改善の余地がある。

もうひとつは Zenn の制限。Zenn には24時間に1記事の制限があり、エラーなしで 404 になる。記事を分散して push するしかなく、連続投稿した日は必ず翌日の確認が必要になる。

定量効果が出たら続編で報告する。

このシステムは Private リポジトリで運用しているが、リクエストがあれば公開するつもりだ。ぜひコメントをいただきたい。

おまけ：この記事はこのワークフローで書かれた

この記事自体が、今日（2026-04-19）紹介したワークフローで制作されている。制作の様子を会話ログから抜粋して紹介する。

15:07 — ネタ帳選択

CEOが「どのネタ帳を記事にするか」を提示し、ユーザーが選択した。

CEO: 「ネタ帳が2本あります。A（リファクタリングした話）かB（完成システム解説）か、どちらで試しますか？おすすめはA」
ユーザー: 「B」

15:09 — researcher・reader を並行起動

CEOが市場調査（researcher）と構成レビュー（reader）をバックグラウンドで同時に走らせた。

2 background agents launched
├── researcher（市場調査）
└── reader（構成レビュー）

readerは「4章でスクリプトの入手方法が不明だと離脱リスク高」「5章のネタ帳概念が固有すぎる」という構成上の弱点を企画段階で指摘した。

15:11 — 事実確認を1問ずつ

CEOがネタ帳のエピソードを1問ずつユーザーに確認した。

Q: 「Zennで published: true なのに公開されていない記事があった——実際に経験しましたか？」
A: 「はい。ZennはAIで作った記事が嫌いみたいｗｗｗ」

Q: 「まとめ章に入れる定量的な変化——数字で語れることはありますか？」
A: 「定量的効果はこれから、これが1本目です」

15:15 — writerの矛盾を発見

writerが初稿を書いたあと、CEOが矛盾を発見した。

CEO: 「4章で『クローンすれば手元で使える』と書いてあるのに、まとめで『非公開リポジトリ』と書いています。このリポジトリは公開する予定ですか？」

「クローンできない」という当然の指摘だった。

15:17 — ユーザーが6点の修正を指示

通読したユーザーが具体的な修正を次々と出した。

Zennの制限ロジックは非公開なので推測を排除する
Qiita 404 の原因は「投稿制限の可能性が高いが原因不明」にする
「792行の」という表現は不要
「エージェントが手書きした」→「エージェントが書いた」
5章の「読み飛ばし可」案内は不要（私のシステムを紹介するだけ）
末尾に「リクエストがあれば公開するつもり」を追加

15:21 — reader の批判的レビュー

全章完成後、readerが「500円払って後悔する理由を5つ」挙げた。

スクリプト本体が非公開で実質再現不可
マルチエージェント構成の説明がない
ROIの答えがない
想定読者と実際の前提がズレている
参照先がすべて非公開

15:25 — ユーザーの回答が記事を変えた

CEOが構造問題をユーザーに確認した。

Q: 「想定読者は『マルチエージェント運用者向け』に絞り込みますか？」
A: 「もはやマルチエージェント構成は特別ではないと思うので、『Claude CodeでBLOG執筆したい方向け』としたい」

Q: 「管理確認作業、月どのくらいかかっていましたか？」
A: 「1日あたり15分はかかっていたと思う」

この回答が7章のROI記述（「体感で15分がほぼゼロに」）になった。

15:33 — 最終レビューで🔴ゼロ、公開

最終reviewer・readerともに必須修正ゼロ。はてなブログに下書き投稿完了。

セッション開始から公開まで、1時間未満。

Claude Code を使った開発全般の体系的な解説書として、実践Claude Code入門（西見公宏他著）も参考になる。AI をチームに組み込んだ運用を試みている方に向けた内容だ。

この記事ははてなブログからのクロスポストです。

はてなブログ版: https://saitoko.hatenablog.com/entry/2026/04/19/095934