はじめに

27回中8回。そのあと14回連続。

これが何の数字か、先に種明かしはしません。まずこの記事を書くまでの経緯から話させてください。

この技術記事シリーズは、テーマ選定・執筆・フォーマット整形・コミット・pushをAIエージェントに任せ、GitHub Actions経由でZennとQiitaに自動公開するパイプラインで運用しています。以前の記事「GitHub Actionsが12分13秒で9回失敗した日」では、このパイプラインの土台となるワークフローが、ある日12分13秒の間に9回失敗した記録を書きました。あの記事は失敗の実況ログでしたが、書き終えたあとも私はずっと「同じ場所でまた壊れるかもしれない」と身構えていました。

今回、その後のGitHub Actions実行履歴を実際に数えてみました。この記事は、その数え直しの記録です。

TL;DR

Qiita側の「Publish articles」ワークフローの全実行履歴（27回）をGitHub APIで数え直した
修正前（2026-08-21〜08-24の一部）は13回中8回が失敗していた。これは以前の記事で書いた9回失敗の日を含む
修正後（updated_atを更新した2026-08-24 07:26のコミット以降）は14回連続ですべて成功している。期間にして6日間、投稿頻度を1日1回程度から1日3回に上げた実験もこの期間に含まれる
ただし「連続成功」は「CIが緑」を数えているだけで、記事の中身が正しいかどうかは別問題。実際、この期間中には別の記事（重複記事事件）で内容面のミスが起きており、それはこの緑の数字には出てこない
結論：直した箇所が同じ形で壊れ続けることはなかった。ただしこれは「もう安心していい」という意味ではなく、「この特定の失敗パターンは今のところ再発していない」という、範囲の狭い事実として扱うべき数字

背景：なぜ「また壊れるはず」と身構えていたか

12分13秒で9回失敗した日の記事では、原因を2つに切り分けました。(1)qiita publishがローカルの内容を「Qiita上の記事より古い」と判定してブロックする現象、(2)自作ワークフローが、qiita-cliによってすでにリネームされ存在しなくなったファイル名を指定していた設計ミスです。どちらも対症療法的に、frontmatterのupdated_at更新と、実験用ワークフローの削除で収束させました。

あの記事の自己批判セクションにも書いた通り、(1)の根本原因(なぜQiita側が「新しい」と判定されたのか)は特定できていません。原因が分からないまま対症療法で収束させた以上、「同じ現象がまた起きるのでは」という不安が残るのは自然なことでした。加えてこのパイプラインは、その後投稿頻度を1日1回程度から1日3回に上げる実験にも入っています。頻度を上げれば、同じ場所で同じ失敗が再発する確率も単純に上がるはずだと考えていました。

この不安は、これまで具体的な数字で検証したことがありませんでした。今回、GitHub Actionsの実行履歴を実際に数えてみることにしました。

実際に数えてみた

Publish articlesワークフローの全実行履歴をGitHub APIで取得し、時系列順に成功・失敗を数えました。

期間	実行回数	失敗	成功
2026-08-21 07:47 〜 08-24 07:21（修正前）	13回	8回	5回
2026-08-24 07:26 〜 08-30 10:47（修正後、現在まで）	14回	0回	14回

修正前の13回のうち8回の失敗には、以前の記事で書いた「12分13秒で9回失敗した日」のうち8回分（同日にもう1回、別ワークフローの失敗が別枠である）が含まれています。つまりあの日の失敗の大半が、この修正前グループに集中しています。

一方、updated_atの更新で収束させた2026-08-24 07:26:52のコミット以降は、今日（2026-08-30）この記事を書いている時点までの6日間、14回のワークフロー実行がすべて成功しています。この14回には、投稿頻度を1日3回に上げてからの実行も含まれています。「また壊れるはず」と思っていた場所は、少なくとも今のところ、同じ形では壊れていませんでした。

「直った」と「壊れなくなった」は違う

ここで注意したいのは、この14回連続成功が証明しているものの範囲です。

GitHub Actionsの「成功」は、qiita publish --all --root .が終了コード0で終わったことしか意味しません。記事の中身が正しいか、タイトルが重複していないかは、このステータスとは無関係です。実際、このパイプラインでは以前「AIエージェントに記事投稿を任せたら、自分自身の記事を複製していた話」という別の事件が起きています。既存記事とほぼ同じタイトルの記事を新規公開してしまった件ですが、あれはワークフロー自体は正常に完走しており、GitHub Actions上は「成功」として記録されているはずの回です。

つまり今回数えた「14回連続成功」というきれいな数字と、実際に人間が手で気づいて直した重複記事事件は、矛盾なく同時に存在します。CIが緑であることと、パイプラインが健全であることは、重なってはいますが同じではありません。

自己批判：この数字が証明していないこと

正直に書いておきたいことが3つあります。

1つ目は、この14回連続成功は「原因1（内容が古いと判定される現象）の根本原因が分かった」ことを意味しません。以前の記事でも書いた通り、根本原因はいまだに特定できていません。単に、修正後にその現象を再発させるような操作（Qiita側での直接編集など）が、たまたまこの6日間になかっただけという可能性は否定できません。

2つ目は、投稿頻度を1日3回に上げた実験の検証期間として、14回・6日間はまだ短いことです。今日はその実験の3回目にあたりますが、頻度を上げてからの実行回数はこの14回のうち一部に限られます。もっと長い期間、もっと多くの回数を見てからでないと、「頻度を上げても大丈夫」とは言い切れません。

3つ目は、この記事自体がパイプラインを通ってGitHub Actionsで公開される予定だということです。この記事を書いている時点では、この記事のpushが15回目の連続成功になるのか、それとも新しい失敗として記録されるのかは分かりません。数字を良く見せるために都合よく書いている記事ではないことは、この一文で担保しておきます。

今日から使えること

自動化パイプラインのGitHub Actions運用で、同じような「また壊れるはず」という不安を抱えている方向けに、今回の経験から言えることを3つにまとめます。

不安は数えて検証する。 「また壊れるかもしれない」という感覚は、ghコマンドやGitHub APIで実行履歴を取得すれば、数分で検証できます。今回の確認も、ワークフローの実行一覧を取得して時系列に並べ直しただけです。感覚のまま放置せず、実際の数字に一度落とし込む価値があります。
「CIが緑」と「成果物が正しい」は別々に確認する。 今回のように、ワークフローが正常終了していても内容面のミスは起こり得ます。定期的に、CIのステータスだけでなく、実際に公開された記事一覧を人間の目で確認する工程を別に持っておくべきです。
負荷や頻度を上げた直後の安定期間を、過去の安定実績と混同しない。 「直してから壊れていない」という実績は、直した時と同じ条件下でのものです。頻度を上げるなど条件を変えたときは、そこからの実行回数を別カウントとして扱い、十分な回数が積み上がるまでは楽観視しないようにしています。

拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、こうした失敗からの回復をどう検証し、どこまでを「直った」と呼んでいいかを見極める考え方を全16章で体系立てて整理しています。