この記事は Claude Code でブログ執筆をしている方を対象にしています。 Claude Code のマルチエージェント構成（CEO・writer・reviewer 等）を用いた執筆ワークフローを前提にしており、構成の詳細は以下の記事を参照してください。
複数プラットフォームに記事を投稿していると、どこかで必ず迷子になる。
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 をチームに組み込んだ運用を試みている方に向けた内容だ。
この記事のテーマを深掘りした本
コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで ネタの自動収集から公開まで、書き続ける仕組みの育て方（序章無料）
シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム
