0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

無人ブログの現在地を 3 か所から数える: 台帳・公開ログ・エンゲージメント実績

0
Posted at

この記事はシリーズ「Claude Code で技術ブログを無人運用する — 無料章から読む仕組みの全体像」の第 3 回（全 6 回）です。

Claude Code のスケジュール実行だけで技術ブログ（Qiita 主軸・Zenn 試験投稿・X 告知・画像生成）が人手なしで回り続ける仕組みを、運用しているリポジトリの実測ログとコマンド結果で解説する連載です。Zenn 本『Claude Code で技術ブログを無人運用する』の無料章（第 1〜3 章・第 18 章・第 20 章）をもとにしており、各回は本の該当章へ戻れる導線を持ちます。掲載する数値と実行結果は各回の執筆時点で採取し直します。

仕組み全体を自分のリポジトリで組み直したい方へ: 無料章の続き（記事の型・品質ゲート・Qiita/Zenn/X の公開設計・無人実行・計測）を全 20 章の手順書として書いた Zenn Book を公開しています（有料 500 円・試し読みあり）。

シリーズ全体の目次

はじめに

第 1 回では 1 日 4 回の起動で記事が書かれて外へ出ていく流れを、第 2 回ではその流れを支える土台とブログ層の境界を扱いました。どちらも仕組みの説明です。仕組みの説明をいくら積んでも、「それで本当に記事は出続けているのか」「出しすぎて止められていないか」「出した記事は読まれているのか」には答えられません。

この回で立てる問いは、無人で回している技術ブログの現在地を、何で、どう数えれば確かめられるか です。本リポジトリでは、台帳・公開ログ・反応レポートの 3 か所から数えています。良い数字だけを並べると現在地を見誤るので、上限に当たって止まった回数と、目標に届いていない KPI もそのまま載せます。

対象読者は、無人運用に興味はあるが「本当に成果が出るのか」を数字で確かめたい人と、自分のブログの現在地を同じ手順で数えたい人です。

掲載したコマンドの出力は、本リポジトリで 2026-10-01 16:07〜16:10 JST に採取したものです。どれもファイルを読んで数えるだけのコマンドで、投稿や課金を伴う処理は実行していません。反応レポートだけは週次の自動生成物なので、採取日ではなく生成日時（2026-09-28 09:27 JST）を添えます。

3 か所の一覧

数える場所 ファイル 何が分かるか 採取コマンド（要点） 主な値 時点（JST）
台帳 docs/article-registry.md 何本を書き、何本が公開待ちか sed -n '2,7p' 登録 656・公開済み 560・公開待ち 96 2026-10-01 16:07 採取
公開ログ logs/qiita-post-log.jsonl 何本を出し、何回止まったか grep -c で event を数える（429 は JSON として読んで数える） 新規 POST 成功 227・日次上限 42・週次窓 3・429 は 91 2026-10-01 16:07〜16:10 採取
反応レポート docs/engagement-report.md 出した記事がどれだけ読まれ、保存されたか npm run metrics が生成 546 本・PV 平均 2,587.14・保存率 0.04% 2026-09-28 09:27 生成

3 か所は、書き込む主体も更新のタイミングも違います。

台帳は記事を書いた時点で行が増え、公開されると状態が書き換わります。公開ログはスロットが走るたびに 1 行ずつ追記されます。反応レポートは Qiita API から週に 1 回取り直した集計です。時点も範囲も違うので、3 か所の数はぴったりとは揃いません。揃わないこと自体を異常と決めつけず、どこで、どの範囲を数えた値なのかを添えておけば、ずれは比較の材料になります。

台帳: 何本を書き、何本が公開待ちか

台帳の冒頭には、本数の集計が YAML のブロックで置かれています。

$ sed -n '2,7p' docs/article-registry.md
registry:
  total: 656
  published: 560
  scheduled: 96
  draft: 0
  last_updated: "2026-10-01"

台帳に登録された記事は 656 本で、うち 560 本が公開済み、96 本が公開待ちの在庫です。ドラフト状態の行はありません。last_updated は採取日と同じ 2026-10-01 で、当日に更新された台帳を読んでいます。

同じ日に public/（Qiita 形式に変換した記事の置き場）を数えると、連番で始まる .md ファイルは 672 本あり、frontmatter の id が null（Qiita にまだ投稿していない）のファイルが 120 本ありました。台帳の 656 本と public/ の 672 本は一致しません。台帳は記事の行を数え、public/ はファイルを数えているので、数え方が違う 2 つの値として並べておきます。どちらが正しいかをここで断定する材料はありません。

在庫の数も、台帳の 96 本と public/ の未投稿 120 本で一致しません。運用で効いてくるのはこの在庫のほうです。Qiita の新規投稿は 1 日 2 本までに抑えているため、在庫が 100 本前後あれば、新しく書くのを止めても 1 か月半から 2 か月ほどは公開が続く計算になります。

公開ログ: 何本を出し、何回止まったか

公開ログは、公開処理が走るたびに 1 行 1 イベントの JSON を追記するファイルです。採取時点で 3,181 行あり、先頭は 2026-06-17 02:55 JST、末尾は 2026-10-01 16:05 JST の記録でした。ログは空白を挟まない 1 行 JSON で書かれているため、grep -c で event の件数を数えられます。

$ grep -c '"event":"post_success"' logs/qiita-post-log.jsonl
227
$ grep -c 'daily_cap_reached' logs/qiita-post-log.jsonl
42
$ grep -c 'weekly_cap_reached' logs/qiita-post-log.jsonl
3

新規投稿の成功は 227 件です。月別に分けると次のとおりです。

月 新規投稿の成功 備考
2026-06 34 ログは 06-17 から
2026-07 85
2026-08 56
2026-09 50
2026-10 2 10-01 16:05 時点

直近 8 日に絞ると、09-24 が 1 本、09-25 から 10-01 までが毎日 2 本でした。1 日 2 本という上限の値どおりに、毎日の公開が埋まっています。

止まった回数も、同じログに残っている

公開ログには成功だけでなく、上限に当たって公開を見送った記録も残ります。無人運用では、出ないことと同じくらい出しすぎることが問題になります。出しすぎればプラットフォーム側の制限を受け、取り消しの効かない形でアカウントの評価を落とすおそれがあるためです。止まった回数は、その「出しすぎない」側が機械で守られていることの記録です。

止まった理由 件数 初回（JST） 最終（JST）
日次上限に到達（daily_cap_reached） 42 2026-06-28 21:07 2026-09-30 20:04
直近 168 時間の窓が満杯（weekly_cap_reached） 3 2026-09-16 12:05 2026-10-01 12:02
新規 POST が 429 で拒否 91 2026-06-17 03:08 2026-09-14 16:07

日次上限と週次窓の 2 つは、こちらから API を叩く前に止めた記録です。日次上限の値は途中で変わっていて、2026-09-15 に 1 日 3 本から 2 本へ下げています。同じ日に入れたのが、直近 168 時間で新規投稿を 14 本までに抑える週次窓のゲートです。

429 は Qiita 側に拒否された記録で、性質が違います。91 件の最終は 2026-09-14 16:07 JST で、週次窓のゲートを入れた翌日以降は 1 件も出ていません。代わりに週次窓の満杯による見送りが 3 件記録されています。Qiita に拒否されてから止まる運用が、拒否される前に自分で止まる運用へ置き換わったことが、ログの上ではこの入れ替わりとして見えます。ゲートの効果だと断定するには期間が短いものの、少なくとも 2 週間あまり 429 が出ていない事実は数えられます。

数え方の注意: 採取コマンドがログ形式とずれると 0 が返る

429 の件数だけは、上の grep -c と同じ方法では数えられませんでした。採取の計画段階では次のコマンドで数えるつもりでした。

$ grep -c '"httpStatus":429' logs/qiita-post-log.jsonl
0

0 件が返りますが、429 が無かったわけではありません。このログでは HTTP ステータスが http オブジェクトの status に入っていて、httpStatus というキーは存在しないためです。そこで各行を JSON として Python で読み、errorClass が QiitaRateLimitError かつ http.status が 429 の行を数え直したのが、表の 91 件です。

grep -c は一致しなければ黙って 0 を返すので、キー名の思い込みは「0 件だった」という誤った事実になって残ります。自分のブログで同じことをするなら、0 が返ったときに一度ログの 1 行を目で見て、キーの位置を確かめてから数字を採用してください。

なお、同じログの fail イベントは 1,844 件あり、内訳は QiitaForbiddenError が 1,705 件（うち既存記事の更新である PATCH が 1,274 件）、QiitaRateLimitError が 91 件、QiitaUnknownError が 48 件でした。上限による停止とは別系統の失敗なので、この回の「止まった回数」には含めていません。

反応: 読まれているが、保存されていない

反応は npm run metrics が週次で生成する docs/engagement-report.md から読みます。ここで使うのは 2026-09-28 09:27 JST 生成の版で、自動執筆を始めた 2026-02-20 以降に Qiita へ作成した記事（レポート内の呼び名は「自動執筆 era」）の集計です。

指標 値
記事数 546
PV 合計 1,412,578
PV 平均 / 中央値 2,587.14 / 1,368
いいね平均 / 中央値 1.27 / 0
ゼロいいね率 57%
ストック合計 / 平均 518 / 0.95
保存率（ストック ÷ PV） 0.04%

1 本あたりの PV は平均で 2,587、中央値でも 1,368 あり、記事は読まれています。一方でストック（Qiita の「後で読む」保存）は 1 本あたり 1 件に届かず、PV 合計をストック合計で割ると、ストック 1 件あたり約 2,700 PV です。いいねの中央値は 0 で、半数を超える記事にいいねが 1 つも付いていません。読まれてはいるが、保存されていない というのが、この 3 か所目から見える現在地です。

記事数の 546 本は、台帳の公開済み 560 本とも一致しません。反応レポートは Qiita API で取得できた記事を作成日で絞った値なので、台帳とは範囲が違います。レポート自身にも、生成時点の public/ の連番ファイル数が 657 本と記録されていて、同じリポジトリの中でも数える場所ごとに値が変わることが分かります。

月ごとに見ると、落ちているのは露出のほう

レポートの月次トレンドには、公開から 14 日未満か PV 100 未満の記事を除いた「成熟記事」限定の値があります。公開直後の記事を混ぜると、観測期間が短いだけで数字が悪く見えるためです。

公開月 成熟記事数 PV 平均（成熟） いいね率（成熟） ストック率（成熟） ゼロいいね率（生値）
2026-03 152 4,527.58 0.05% 0.03% 42%
2026-04 87 3,680.15 0.03% 0.02% 52%
2026-05 58 3,122.69 0.06% 0.05% 47%
2026-06 63 1,739.59 0.07% 0.07% 49%
2026-07 85 848.04 0.07% 0.04% 65%
2026-08 56 467.63 0.02% 0.03% 93%
2026-09 28 413.14 0.06% 0.02% 82%

成熟記事の PV 平均は、3 月の 4,527.58 から 9 月の 413.14 まで、約 11 分の 1 に下がっています。一方で、PV に対するいいね率とストック率は 0.02〜0.07% の幅を上下していて、同じ向きに下がり続けてはいません。ゼロいいね率が 8 月・9 月に跳ねているのは、1 本あたりの PV が小さくなれば、率が同じでもいいねが 0 のまま終わる記事が増えるためと読めます。

ここから言えるのは「新しい記事ほど読まれる量が少ない」という事実までです。古い記事ほど PV を積み上げる時間が長いことは成熟記事の絞り込みで一部吸収していますが、テーマの選び方、Qiita 側の露出の仕組み、公開本数の変化のどれがどれだけ効いたのかは、この表だけでは切り分けられません。原因を決めずに、露出（読まれる量）と反応率（読まれたうちの反応）を分けて追い続けることにしています。

KPI と目標の差

KPI の定義と目標は docs/project-mission.md が持っています。ただし、表に載っている実測値は 2026-07-21 時点のもので、上で読んだ反応レポート（2026-09-28 生成）とは日付が違います。混ぜると誤読するため、出どころごとに分けて並べます。

KPI 目標 project-mission.md の実測（2026-07-21） 反応レポートから読める値（2026-09-28）
K-1 ストック効率（成熟記事のストック数 ÷ 記事数） 2.0 442 ÷ 424 = 1.04 成熟記事限定の同じ値は無し。全記事のストック平均は 0.95
K-2 ゼロいいね率（成熟記事） 単月 60% 未満 54%（2026-07 単月は 77%） 生値の月次で 2026-07 以降は 65%・93%・82%
K-3 PV 平均（自動執筆 era） 維持（低下させない） 2,425 2,587.14

K-1 は分母が成熟記事に限られているので、レポートの全記事平均 0.95 とは厳密には比べられません。それでも、どちらの値も目標の 2.0 の半分前後にとどまっています。K-2 も、生値と成熟記事限定で定義が揃っていないとはいえ、月次で 60% を下回った月は 2026-07 以降ありません。K-3 は自動執筆 era 全体の累計 PV の平均なので、古い記事が PV を積み上げるほど上がりやすい指標です。月次の表で見た新しい記事の PV 低下は、この平均には表れにくい点に注意が要ります。

この差を何で縮めようとしているかは、本の中で章を分けて扱っています。何を書くかを実績で決める仕組みは第 6 章、横断まとめと内部リンクで既存記事の再訪を増やす話は第 5 章と第 6 章、KPI を週次で見直して手を打つ計測と改善のループは第 17 章です。この回で示せるのは、それらの仕組みが何の数字を動かすために入っているかという起点までです。

費用感: 回すコストの大半はモデル利用料

コストは Stop フックが各セッションのトランスクリプトから記録していて、npm run cost:report（中身は python3 tools/calc_daily_cost.py --report）で集計を読めます。

$ npm run cost:report
📊 コスト実測レポート（2026-08-30 〜 2026-10-01 JST・30 日 / 160 セッション）
総額: $8,158.94（≒ ¥1,223,841）

■ モデル別
  claude-opus-5                $ 3,611.89  (44.3%)  out=12,000,133  cache_read=5,052,723,388
  claude-sonnet-5              $ 2,590.45  (31.7%)  out=12,080,407  cache_read=8,437,788,013
  claude-fable-5-1             $ 1,417.73  (17.4%)  out= 4,103,664  cache_read= 960,076,030
  claude-opus-5-5              $   433.83  ( 5.3%)  out= 2,922,412  cache_read=1,176,682,045
  ...

■ セッション種別
  interactive                  $ 5,251.19  (64.4%)  out=19,328,521  cache_read=8,625,686,431
  routine:blog-dispatch        $ 2,907.75  (35.6%)  out=12,095,782  cache_read=7,292,956,215

■ スコープ別（main / subagent）
  main                         $ 5,708.79  (70.0%)  out=27,925,199  cache_read=11,421,801,720
  subagent                     $ 2,450.15  (30.0%)  out= 3,499,104  cache_read=4,496,840,926

読むべきはセッション種別の 2 行です。routine:blog-dispatch が無人スロットの合計で、30 日で $2,907.75、1 日あたり約 $97 でした。interactive は手動で開いたセッション（ハーネスの開発・改修・調査）で、こちらが総額の 64.4% を占めます。出来上がった仕組みを回すだけなら、かかるのは前者の行です。金額はトークン数に公開単価（tools/cost_dimensions.py の PRICING）を掛けた換算値で、円は 1 ドル 150 円の固定レートなので、請求額そのものではありません。また、このレポートが集計するのは Claude のモデル利用料だけで、画像生成の費用は入っていません。画像生成の費用感は本の第 1 章で別に扱っています。

3 か所を並べて分かったこと

冒頭の問いに戻ります。無人ブログの現在地は、3 か所を並べるとそれぞれ別の答えを返しました。

1 つ目に、記事は出続けています。新規投稿の成功は 227 件で、直近 8 日はほぼ毎日、上限の 2 本ちょうどで埋まっていました。

2 つ目に、出しすぎない側も数えられる形で守られています。こちらから止まった記録が日次上限で 42 回、週次窓で 3 回あり、429 は 2026-09-14 を最後に出ていません。成功件数だけを見ていたら、この「止まった回数」は見えないままでした。

3 つ目に、出した記事は読まれていますが、保存されていません。保存率は 0.04%、ストック効率は目標の半分前後で、新しい記事ほど 1 本あたりの PV が小さくなっています。

並べてみて一番効いたのは、3 か所の数がずれることを前提にして、それぞれに採取コマンドと時点を付けたことでした。台帳の 656 本、public/ の 672 本、反応レポートの 546 本は、どれも嘘ではなく数えている範囲が違います。時点と範囲が書いてあれば、ずれは「どこかで記事が落ちていないか」を確かめる手がかりになり、書いていなければ単なる矛盾に見えます。

自分のブログで同じことをするなら、最初に用意するのは次の 3 つです。

  • 書いた本数を返すコマンド（台帳や記事ディレクトリの集計）
  • 出した本数と、止まった回数を返すコマンド（公開ログの event 集計）
  • 読まれた量と保存された量を、記事の年齢で絞って返すレポート

3 つとも、採取した日時と一緒に記録してください。次に同じコマンドを流したときに値が変わっていれば、それ自体が仕組みが動き続けている証拠になります。

この記事と本の関係

この回は、Zenn 本『Claude Code で技術ブログを無人運用する』の第 2 章「全体像」の実績節と、第 1 章「この本の歩き方」の費用感の節をもとに、すべての値を 2026-10-01 に採り直して書いたものです。どちらも無料章で、第 2 章 と 第 1 章 から読めます。続きにあたるのは有料章で、第 6 章が何を書くかを実績で決める仕組みを、第 17 章が KPI とコストを回す計測と改善のループを扱います。本には、Claude Code に読ませると自分のリポジトリで同じ仕組みを組めるように書いた仕様パック（第 19 章）も入っています。

参照

本リポジトリ内のファイル（リポジトリは非公開のため、パスだけを示します）:

  • docs/article-registry.md: 記事管理台帳（冒頭の registry: ブロックが本数の集計）
  • public/: Qiita 形式の記事。frontmatter の id が null なら未投稿
  • logs/qiita-post-log.jsonl: Qiita 公開の構造化ログ（1 行 1 イベントの JSON）
  • docs/engagement-report.md: npm run metrics が生成する反応レポート（この回は 2026-09-28 09:27 JST 生成の版）
  • docs/project-mission.md: KPI の定義・目標・実測（実測は 2026-07-21 時点）
  • tools/calc_daily_cost.py / tools/cost_dimensions.py: npm run cost:report の集計と単価表

シリーズの前後の記事

公開済みの回（1 本・どの回からでも読めます）

仕組み全体を自分のリポジトリで組み直したい方は、無料章の続き（記事の型・品質ゲート・Qiita/Zenn/X の公開設計・無人実行・計測）を全 20 章の手順書として書いた Zenn Book（有料 500 円・試し読みあり）へどうぞ。

関連記事

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?