はじめに
60%。
これが今回の数字です。何の60%かというと、このZenn/Qiita自動投稿パイプラインを動かし始めてから今日までの、GitHub Actions全50回の実行のうち、実際に成功で終わった回数の割合です。
先に種明かしをしてしまいましたが、ここに至った経緯から話させてください。
今週、McKinseyの「State of AI 2026」を紹介する複数の海外メディア記事を目にしました。要旨は、「調査対象企業の32%が、AIコーディングエージェントで自前構築できることを理由に、既製ソフトウェアの購入を見送った」というものです。同じ記事群の中で、MIT NANDAの調査結果として「社内で内製されたエージェント型システムの成功率はおよそ33%にとどまる一方、外部ベンダーから購入したツールの成功率は約67%に達する」という、対照的な数字も紹介されていました（いずれも海外メディア経由の二次情報で、McKinsey・MIT NANDA本体のレポートまでは自分で読みに行けていません。これは後述の自己批判で触れます）。
この「内製33%・購入67%」という数字を見て真っ先に思ったのは、「自分のこの自動投稿パイプラインも、既製のSaaS（自動投稿ツールやIFTTT的な連携サービス）を検討すらせず、最初からAIエージェント（Claude Code）で内製した"build"側の実例そのものだ」ということでした。だったら自分の実際の成功率は何%なのか、感覚ではなく実際に数え直してみることにしました。
TL;DR
- 海外メディア経由で、McKinsey「State of AI 2026」の「企業の32%がAIコーディングエージェントによる内製を理由に既製ソフトの購入を見送った」という報道と、MIT NANDAの「内製エージェント型システムの成功率は約33%、購入ツールは約67%」という報道を確認（一次レポート未確認）
- 自分のZenn/Qiita自動投稿パイプラインを動かし始めてからのGitHub Actions実行を全件（50回）数え直した結果、通算の成功率は60%（30回成功／20回失敗）だった
- 失敗20回の内訳を見ると、12回はQiita側のレート制限という外部要因（2026年9月1〜3日に集中）、残る8回は自分の設計ミス（qiita-cliの誤判定や実行前チェック欠如など、初期の2026年8月21〜24日に集中）
- 外部要因のレート制限期間を除いて数え直すと、37回中29回成功で成功率78.4%まで上がる。つまり「60%」という数字の低さの大半は、自分の設計品質そのものではなく、特定期間に集中した外部APIの制約が占めている
- とはいえ、MIT NANDAが報告する「内製33%」よりは自分の数字はかなり高く、「購入67%」にはまだ届いていない、という位置関係だった
実際に数えた結果
GitHub Actionsの実行履歴を、このパイプライン用のワークフロー（Publish articles）に絞って全件取得し、時期ごとに区切って集計しました。
| 期間 | 実行回数 | 成功 | 失敗 | 成功率 | 主な内訳 |
|---|---|---|---|---|---|
| 8/21〜8/23（稼働初期） | 8 | 5 | 3 | 62.5% | 個別の設計ミスが散発 |
| 8/24（バースト障害） | 6 | 1 | 5 | 16.7% | qiita-cliの誤判定など、自分の設計ミスに起因する短時間の連続失敗 |
| 8/26〜8/31（安定期） | 15 | 15 | 0 | 100% | 障害なし |
| 9/1〜9/3（レート制限期） | 13 | 1 | 12 | 7.7% | Qiita側のレート制限という外部要因 |
| 9/4〜9/11（安定期） | 8 | 8 | 0 | 100% | 障害なし |
| 通算（全期間） | 50 | 30 | 20 | 60.0% | — |
| 通算（レート制限期を除く） | 37 | 29 | 8 | 78.4% | — |
数え直して意外だったのは、失敗20回のうち12回（60%）が、たった3日間（9/1〜9/3）に集中したQiita側のレート制限という単一の外部要因に起因していたことです。逆に言えば、自分自身の設計に起因する失敗は、稼働初期の8回に、その後はほぼ発生していません。「通算60%」という数字だけを見ると内製ソフトとしての品質が低いように見えますが、内訳を見ると評価はかなり変わります。
なぜこうなったか
MIT NANDAが報告しているという「内製33%」という数字が何を測ったものかは分かりません（後述の通り一次情報を確認できていません）。ただ、自分の場合で言えば、失敗の大半（20回中12回）が「一度診断されて原因が特定済みの、外部API側の制約」に集中している点が重要だと感じています。ソフトウェアの品質を「実行してエラーが起きた回数」だけで測ると、こうした外部要因由来の失敗と、自分のコードやワークフロー設計に起因する失敗が同じ1件としてカウントされ、内製そのものの品質評価としては歪みが生じます。
もう一つ、この数字には見えていない歪みがあります。GitHub Actionsの「成功」は、あくまでワークフローがエラーなく完走したことを意味するだけで、記事が実際にZenn・Qiita双方の読者に正しく届いたかどうかとは別です。以前の記事（「GitHubへのpushは11回とも成功していたのに、Zennでは7日間、記事が1本も公開されていなかった」「2本まとめて投稿したら、1本は成功していたのに『失敗』のログしか残らなかった」）で書いた通り、CI上の成功・失敗という1ビットの記録と、実際の公開結果は一致しないことがあります。つまり今回の「60%」は、あくまでCIレベルの成功率であって、読者に届いた記事の割合を正確に表す数字ではありません。
自己批判：この記事について正直に言うと
4つ、正直に書いておきます。
1つ目。McKinsey「State of AI 2026」とMIT NANDAの数字は、いずれも海外メディアの紹介記事経由で確認したものです。 調査対象企業の定義、「内製」「成功」の定義、サンプルサイズといった、数字を正しく解釈する上で欠かせない前提条件を、自分は一次レポートで確認できていません。ここで紹介した「32%」「33%」「67%」という数字は、報道をそのまま引用したものとして扱ってください。
2つ目。自分は最初から既製のSaaSを比較検討した上で「内製を選んだ」わけではありません。 そもそも自動投稿SaaSの選定プロセスを経ておらず、最初からAIエージェントに書かせる前提で始めています。「既製ソフトの購入を見送った32%」の企業とは意思決定のプロセスがまったく違うので、自分をそのグループの一員のように語るのは正確ではありません。
3つ目。N=50、しかも「決まった手順を毎回同じように繰り返すだけの単一タスク」という、条件がかなり良いサンプルです。 MIT NANDAが調べたとされる「内製エージェント型システム」が、業務要件が複雑で変化し続けるような、もっと難しいシステムを含んでいるなら、自分の60%〜78%という数字と単純比較すること自体が適切ではない可能性があります。
4つ目。「レート制限期間を除けば78.4%」という数字は、自分に都合よく外れ値を除外しているようにも読めます。 実際の運用では、外部APIのレート制限も含めて「動かしたら何%成功するか」がすべてであり、原因別に除外して見せる数字は、内訳を理解するための補助であって、運用上の実感としては通算60%の方を基準に考えるべきだと思っています。
今日から使えること
- 「内製か購入か」を業界の平均値（32%、33%、67%など）だけで判断しない。 自分の場合のように、実際にログを数え直すと、失敗の大半が特定の原因に集中していることが多く、平均値では見えない実態がある。
- 成功率を集計するときは、必ず失敗の原因別に内訳を分ける。 「外部要因」と「自分の設計ミス」を混ぜたまま1つの成功率で語ると、内製の品質を過小評価も過大評価もしてしまう。
- CIレベルの成功率と、実際に利用者・読者に届いた結果は別物として扱う。 「ワークフローが成功した」ことと「意図した結果が実現した」ことの間にギャップがないか、定期的に別の角度から確認する仕組みを持っておく。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』でも、AIエージェントに何を任せ、その結果をどう計測するかという観点でHarness EngineeringとObservabilityの章を分けて扱っています。「内製か購入か」を考えるときも、まず自分の実績を正しく計測することが最初の一歩だと考えています。