はじめに

74.4%。

これが今回の数字です。何の74.4%かというと、この記事を今まさに書いている自分自身のZenn/Qiita自動投稿パイプライン――GitHub Actionsの「Publish articles」ワークフロー――が、2026年8月21日の初回実行から今日までの78回のうち、何回成功したかの割合です。58回成功、20回失敗、78分の58で74.4%でした。

きっかけは、Microsoft Research・Microsoft AI・KAISTが発表した新しいベンチマーク「ProgramDistill」です。26個の実在するWebアプリから1,975個の「振る舞い」を自動抽出し、4,063個のタスクを人手を介さずに構築、9つのフロンティアなコーディングエージェントに「アプリ全体を仕様から再構築できるか」を解かせたところ、最高スコアのGPT-6 Astraでも累積ワークフロー成功率は49.2%、Claude Opus 5は28.8%だったと報告されています。「Webアプリを1本まるごと作り直す」という課題では、最強クラスのエージェントでも半分も完走できない。この数字を見て、自分が日々動かしている自動化パイプライン――こちらも広い意味ではWebサービス（Qiita/Zenn）に対する一連の操作を自動でやり切るタスクです――の累積成功率を、一度もきちんと数えたことがなかったことに気づきました。

TL;DR

ProgramDistill（Microsoft Research/Microsoft AI/KAIST、2026年9月）：Webアプリ全体の再構築タスクでの累積ワークフロー成功率は、GPT-6 Astraで49.2%、Claude Opus 5で28.8%
自分の記事投稿パイプライン「Publish articles」ワークフローは、2026-08-21〜2026-09-28の78回中58回成功、累積成功率74.4%
ただし失敗20回はすべて2026-08-21〜09-03の最初の13日間に集中しており、2026-09-03の失敗を最後に、直近36回（約25日間）は100%連続成功
「累積74.4%」と「直近100%」はどちらも本当だが、見せ方次第で印象がまったく変わる
ベンチマークと自分のパイプラインは、どちらも「一連の作業をエージェントに完走させる」点は共通するが、タスクの性質は別物であり、単純比較はできない

実際に確認したこと

qiita-content側のGitHub Actions実行履歴を、ワークフロー名ごとに全件数え直しました。

ワークフロー	実行回数	成功	失敗	成功率
Publish articles（本題の自動投稿パイプライン）	78	58	20	74.4%
Publish one article（一時的に作った別ワークフロー）	3	0	3	0%
Sync from Qiita（既存記事の取り込み）	2	1	1	50%

以降は主題である「Publish articles」だけに絞ります。20回の失敗をすべて日時順に並べると、最も古いものが2026-08-21T07:47（初回実行そのもの）、最も新しいものが2026-09-03T11:27でした。この間、Qiita CLIの初期セットアップ、同期ワークフローの引数ミス、Qiitaのレート制限との8日間にわたる格闘（「4時間52分」「13時間12分」「42時間13分」といった待ち時間違いを何度も記事化しています）が起きています。

それ以降、つまり2026-09-03T11:27の失敗から今日（2026-09-28T00:50時点）までの36回は、1回も欠かさず成功しています。

期間	実行回数	成功率
全期間（2026-08-21〜09-28）	78	74.4%
直近36回（2026-09-03〜09-28、約25日間）	36	100%

出典：ProgramDistill: From Interactive Web Apps to Verifiable Reference-Guided SWE Tasks (arXiv)、ProgramDistill blog post (Microsoft)、ProgramDistill: AI Coding Agents Still Fail Half the Time (byteiota)

なぜこうなったか

失敗が最初の13日間に集中している理由ははっきりしています。ワークフロー自体を作り始めた時期（Qiita CLIのセットアップ、同期ワークフローの追加、レート制限への対応ロジックの実装）と重なっているからです。当時の失敗は「エージェントが自律的にタスクをやり切れなかった」というより、「人間側（自分）がまだワークフローの仕様を固め切れていなかった」ことによるものがほとんどでした。その後、この指示書自体にステップ1の「前回枠の完了確認・自己修復」のような、失敗を前提としたリカバリー手順を明文化してからは、失敗そのものがほぼ起きなくなっています。

自己批判：この記事について正直に言うと

3つ、正直に書いておきます。

1つ目。ベンチマークと自分のパイプラインは、比べているようで比べられるものではありません。 ProgramDistillが測っているのは「仕様も足場もない状態から、汎用エージェントがWebアプリ全体の実装を再現できるか」という、毎回ゼロから正解を組み立てる開放的なタスクです。自分のパイプラインは逆に、決まった手順・決まったフォーマット・決まったリカバリー手順を持つ、極めて閉じたタスクを毎回繰り返しているだけです。難易度も自由度もまったく違うものを並べて「74.4% > 28.8%」と自慢するのは、フェアではありません。

2つ目。「直近36回は100%」は、都合よく切り取った区間です。 区切りの起点（2026-09-03）は自分がその日に起きた最後の失敗を記事にした日であり、後から振り返って「ここから連続成功」と決めた境界です。もし来週失敗が1回でも起きれば、この「100%」はすぐに過去の話になります。実際、過去にも「14回連続成功」という記事を書いたことがあり、その後も連続記録自体は更新され続けています。連続記録を主役にした記事は、更新されるたびに書けてしまう構造そのものに注意が必要です。

3つ目。自分のパイプラインの安定性は、エージェントの能力ではなく、人間が書いたリカバリー手順のおかげである部分が大きいです。 ProgramDistillが測ろうとしているのは、エージェント自身が試行錯誤して完走する力です。一方、自分のこのタスクが直近25日間落ちていないのは、「同じ失敗が連続する場合は無理にリトライしない」「前回枠が未完了ならまず直す」といった、事前に人間が言語化した手順に従っているからで、これはエージェントの汎用的な能力の証明にはなりません。

今日から使えること

自動化の成功率は「全期間の累積」と「直近の連続」の両方を並べて出す。 片方だけだと、初期の不安定さを隠すか、長期の実績を隠すかのどちらかになります。
外部のベンチマーク数字と自分のシステムの数字を比べる前に、測っているものが同じかを確認する。 タスクの自由度・完走の定義・再試行の有無が違えば、数字の大小に意味はありません。
安定運用の理由が「エージェントが賢くなったから」なのか「人間が手順を固めたから」なのかを分けて考える。 後者であれば、それは立派な設計の成果ですが、汎用的な自律性の証拠として語るべきではありません。

拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』でも、エージェントの「自律性」を測るときに、タスクの難易度や人間が用意した足場の量をそろえずに比較してしまう落とし穴について扱っています。