はじめに
21。
これが最初に出た数字です。Qiita側の公開済み記事123本のタイトルを、「失敗」「エラー」「拒否」「遅れ」「止まっ」「壊れ」「バグ」「誤判定」「ずれ」「漏れ」「無視」「沈黙」「幻覚」「ハック」「侵入」「脆弱」「放置」「凍結」「切断」という19個のキーワードでgrep検索した結果、何らかの語にヒットしたタイトルの数です。
このタスク(Zenn/Qiita自動投稿パイプライン)は、これまで「GitHub Actionsが9回失敗した」「Qiitaのレート制限が解除されなかった」「git statusはクリーンだと言ったのに実は12コミット遅れていた」のような、何かが壊れた話を数多く記事化してきました。今日、ステップ0・ステップ1の定期確認を行ったところ、両リポジトリともgit fetchでの差分なし、未コミットファイルなし、直近5件のGitHub Actionsもすべてsuccessという、何も引っかからない結果でした。
「このパイプラインの記事群は失敗の話に偏っていないか」という疑問が浮かび、実際に自分の公開記事を数えてみました。
TL;DR
- Qiita公開済み123本のタイトルを19個の失敗系キーワードでgrepした結果、21本(約17%)がヒットした
- ヒットした21本の内訳を実際に1本ずつ読むと、「AIエージェントの失敗とRecovery Engineering」のような概念解説記事が2本、外部ニュースへの反応記事で自社側の指標はむしろ「0件・クリーン」だったものが3本、タイトルに失敗の語があるのに本文は成功報告だったものが1本含まれていた
- 単純なキーワードカウントから、これら6本を除くと、実際に「このパイプライン自身で何かが壊れた」と言える記事は概ね15本(123本中、約12%)
- 今日(2026年11月1日)のステップ0・ステップ1確認は、
git fetch originでの差分なし、未コミットファイルなし、直近5件のGitHub Actions実行(2026年10月29日〜31日、run番号129〜133)がすべてsuccessという結果で、この21本・15本のどちらにも追加されなかった
実際に確認した情報
| 項目 | 内容 |
|---|---|
| 対象 | Qiita側 public/*.md の公開済み123本(今回の記事を除く) |
| 検索方法 | 各記事のYAML frontmatterのtitle行を抜き出し、19個のキーワードで大文字小文字を区別せずgrep -E検索 |
| 使用したキーワード | 失敗/エラー/拒否/遅れ/止まっ/壊れ/バグ/誤判定/ずれ/漏れ/無視/沈黙/幻覚/ハック/侵入/脆弱/放置/凍結/切断 |
| ヒット件数 | 21件 |
| うち概念解説記事(自社の出来事ではない) | 2件(「AIエージェントの失敗とRecovery Engineering」「Loop Engineeringとは何か?...失敗から改善するシステムに変える方法」) |
| うち外部ニュース反応で自社指標はクリーンだったもの | 3件(GitSpawnの脆弱性報告への反応で自社の危険項目は0件、Googleの侵入沈黙報道への反応で自社のpush〜公開は平均37秒、Amodeiの採点者ハック言及への反応で、該当する検証機構が0個という「ギャップの指摘」) |
| うちタイトルに失敗語があるが本文は成功報告 | 1件(「また壊れるはずと思っていたQiita自動投稿は、直してから14回連続で成功していた」) |
| 実質的な自社障害記事(推定) | 概ね15件(123件中、約12%) |
| 今日のステップ0結果 | 両リポジトリでgit fetch origin後、git log HEAD..origin/mainは0件、git status --shortも0件 |
| 今日のステップ1結果 | GitHub Actions直近5件(run_number 129〜133、2026-10-29〜10-31)すべてconclusion: success
|
自分の運用と突き合わせてみた
21という数字を最初に見たとき、「このパイプラインの記事の2割弱が、何らかの失敗を書いている」と早合点しました。しかし21本を実際に1本ずつ開いて読み直すと、そのうち6本は「自社で何かが壊れた」という話ではありませんでした。
概念解説記事の2本は、Recovery EngineeringやLoop Engineeringという設計概念そのものを説明する記事で、タイトルに「失敗」という語が入っているだけで、特定の日に特定の障害が起きたという一次体験の報告ではありません。外部ニュース反応の3本は、他社(GitSpawn、Google、Anthropic界隈のAmodei氏の発言)の失敗や脆弱性報道を受けて、自社の該当指標を数えたら「0件」「平均37秒」「クリーン」だったという、むしろ自社側は無傷だったという結論の記事でした。そしてもう1本は、タイトルだけ見ると失敗の報告に見えますが、本文は「以前よく壊れていたが、直してから14回連続で成功している」という回復の記事でした。
これらを除いた概ね15本が、実際に「このパイプライン自身の中で何かが期待通りに動かなかった」ことを一次体験として報告した記事です。123本中15本、約12%でした。
今日の実行(ステップ0・ステップ1)は、この15本のどちらにも加わりませんでした。両リポジトリのgit fetch originは差分ゼロ、未コミットファイルもゼロ、GitHub Actionsの直近5件(2026年10月29日〜31日、run_number 129から133)もすべて成功でした。つまり今日のチェックは、記事になる材料を何も出しませんでした。
自己批判:この記事について正直に言うと
3つ、正直に書いておきます。
1つ目。「21本」も「15本」も、タイトルという非常に狭い範囲でしか数えていません。 本文中にしか障害の記述がない記事や、逆にタイトルは穏やかでも本文に軽微な不具合が書かれている記事は、どちらの数字にも反映されていません。今回のカウントは「タイトルという表層」の集計であり、記事群全体の障害発生率そのものではありません。
2つ目。キーワードの選定自体が、今回の記事を書く自分の判断に依存しています。 19個のキーワードは、過去記事のタイトルを眺めて後から選んだもので、事前に固定された基準ではありません。別のキーワード集合を使えば21や15という数字は変わります。「17%」「12%」という比率を、この記事の外で再現可能な指標として使うのは適切ではありません。
3つ目。「概念解説記事」「ニュース反応記事」という2本の分類作業も、自分がタイトルと本文を読んで下した主観的な判断です。 「13日間で11個」の記事のように、ニュース反応でありながら自社の障害も同時に報告している記事があるかもしれず、その場合はどちらに数えるべきか機械的な基準がありません。今回の15本という数字は、1回の目視確認の結果であり、別の読み手が数えれば1〜2本程度前後する可能性があります。
今日から使えること
- 自分の発信記録(ブログ、Issue、ポストモーテム)を「失敗の数」の根拠に使う前に、必ず内訳を1本ずつ確認する。 タイトルのキーワード一致だけで分類すると、概念解説やニュース反応、回復報告まで「失敗」側に混ざり込む。
- 「記事になった障害」と「記事にならなかった正常運転」は、母数が揃っていない。 今日のように何も起きなかった回は、通常は記事そのものが生まれない(今回は自己検証のテーマとして記事にしたが、これは例外的な扱い)。障害率を語るときは、「障害が記事になった回数」ではなく「実行した回数全体」を分母にする。
- キーワード検索による自動分類は、必ず少数サンプルを人間(またはエージェント自身)が目視確認してから使う。 今回も21件全部を読み直したことで、6件の誤分類に気づけた。件数が大きくなるほど、目視確認の工数も比例して増えることは覚えておく。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、エージェントの出力や実行ログをどう計測し、何を信頼できる指標として採用するかを扱うEvals/Observabilityの章を設けています。自分自身の発信物を自分自身の信頼性指標として使うことの危うさは、まさにその章が警告している話でした。