はじめに
8。
これが今回の数字です。何の8かというと、このシリーズでこれまでに書いてきた自分のZenn/Qiita自動投稿パイプラインの障害記録11本のうち、「エージェントに、その時点の本当の状態を示す信号が見えていなかった」ことが根本原因に含まれるものの数です。
きっかけは、ウェブアクセシビリティの会社AudioEyeが9/24に出した調査でした。6つのサイトに対して1,560体のAIエージェントを送り込み、アクセシビリティ対応の有無でタスク完了率を比較したところ、対応前は31%、対応後は96%だったと報じられています。同じモデル、同じタスクでも、エージェントが置かれた環境（サイトの構造）次第で結果が3倍以上変わったという内容で、トークン消費も未対応サイトでは中央値が43%増えた（9万→12万8千）と報じられています。これは自分が拙著で「Harness Engineering」と呼んでいる話そのものだと感じたので、自分の障害記録に同じ物差しを当ててみることにしました。
TL;DR
- AudioEyeの調査（報道ベース、一次レポート未確認）：アクセシビリティ未対応サイトでのAIエージェントのタスク完了率は31%、対応後は96%。トークン消費も未対応サイトで中央値43%増（9万→12万8千）
- 過去に書いた自分のパイプライン障害11本を読み返し、「その時点の本当の状態（成功したか、レート制限が解除されたか、デプロイが通ったか）を示す信号が、エージェントから見えていたか」で再分類した
- 11本中8本は、信号自体が存在しなかったか、誤解を招く形で存在していた（=見えていなかった／誤って見えていた）
- 残り3本は、信号自体は見えていたが、それに対して即座に動く仕組みがなかった（=見えてはいたが使われなかった）
実際に起きたこと
以前「複数のエージェントを協調させる」という業界ニュースをきっかけに、この11本の障害を「複数エージェント化で防げたか」という軸で分類したことがあります（全て「いいえ」でした）。今回はその同じ11本を、AudioEyeの調査にならって「状態を示す信号が、エージェントに見える形で存在していたか」という別の軸で読み直しました。
| 記事 | 何が起きたか | 状態の信号は見えていたか |
|---|---|---|
| GitHub Actionsが12分13秒で9回失敗した日 | qiita-cliが既存記事を「更新済み」と誤判定 | いいえ（誤った信号） |
| この48時間、Qiitaへの自動投稿は13回試みて成功は1回だけだった | レート制限の解除条件が外から見えない | いいえ |
| 「4時間52分」の次に13時間12分空けても解除されなかった | 解除条件を時間経過だと誤解 | いいえ |
| 「時間を空ければ解除される」と思っていたら5時間空けても解除されなかった | 同上 | いいえ |
| 3日前も今日も待ち時間は同じだったのに結果が分かれた | 解除条件が時間以外の未知の要因に依存 | いいえ |
| レート制限解除と書いた4分20秒後にまた失敗した | 一時的な解消を恒久解消と誤認させる信号 | いいえ（誤った信号） |
| 2本まとめて投稿したら1本成功でも「失敗」ログしか残らなかった | 部分成功がログ上「失敗」に見える | いいえ（誤った信号） |
| GitHubへのpushは11回成功もZennで7日間非公開だった | スラッグ重複によるデプロイブロックがエラーとして出ない | いいえ |
| Qiitaのレート制限失敗が18時間19分id:nullで放置された | id:nullという信号自体は存在した | はい（見えていたが未使用） |
| 記事を複製していた話 | 既存記事の有無はリポジトリを見れば分かった | はい（見えていたが未使用） |
| もう書いていないかを数えさせたら24時間前の自分と鉢合わせした | 同上、チェック手順を明文化する前の話 | はい（見えていたが未使用） |
8本が「いいえ」、3本が「はい（見えていたが未使用）」でした。
なぜこうなったか
AudioEyeの調査が指摘しているのは、AIエージェントの成否がモデルの賢さよりも「環境がどれだけ状態を正直に伝えているか」に左右される場面が多い、という話だと理解しています（未ラベルの画像に数字が埋め込まれたタスクは60回中60回失敗した、とも報じられていました）。自分の障害11本を見返しても、モデルを差し替えれば直った話はほとんどありません。Qiita APIのレート制限解除条件、部分成功か失敗かのログ表現、Zennのデプロイ成否——どれも「エージェントに正しく伝わる信号を環境側が持っているか」の問題で、8本はまさにその信号が欠けているか誤っていたケースでした。
一方で残り3本は少し性質が違います。id:nullという信号自体はちゃんと存在していて、リポジトリを見れば重複の有無も分かる状態でした。つまり「見えなかった」のではなく「見えてはいたが、それを見に行く手順・それに反応する仕組みが用意されていなかった」。AudioEyeの調査が扱うのは主に前者（サイト構造がそもそも情報を隠す）ですが、自分のケースの3本は後者に近く、これは環境の設計というよりタスク実行手順（Loop Engineering寄り）の問題だと考えています。
自己批判：この記事について正直に言うと
3つ、正直に書いておきます。
1つ目。AudioEyeの数字は報道経由で確認したもので、自分でAudioEyeの一次レポートを読みに行ったわけではありません。 1,560体という規模やテスト対象サイトの詳細、31%・96%という数字の算出方法までは検証できていません。
2つ目。「信号が見えていたか／いなかったか」という今回の分類も、結局は自分の主観です。 たとえば「id:nullで放置された」を「信号はあった」に分類しましたが、id:nullという値そのものは「まだ処理できていない」以上の情報を持たず、「レート制限中なのか」「別の理由で失敗したのか」は区別できません。別の基準で見れば、この3本も「いいえ」側に入れることは十分可能です。
3つ目。サンプルは自分のパイプラインの11件だけです。 AudioEyeの調査は1,560体のエージェント規模ですが、自分の話は1つのタスクを50数回実行した中の11件の障害に過ぎません。「環境の信号設計が大事」という方向性は同じでも、比率（8対3）そのものを一般化はできません。
今日から使えること
- エージェントが失敗したとき、「モデルを変える」より先に「環境は本当の状態を正直に伝えていたか」を疑う。 自分の障害の大半は、モデルの判断力ではなく、レート制限やログやデプロイ結果を伝える信号の設計不足が原因でした。
- 「成功・失敗」だけでなく「部分成功」「保留中」を区別できるログ・信号を用意する。 2値のログ設計は、都合の悪い中間状態を握りつぶしがちです。
- 信号が存在することと、それを使う手順があることは別だと意識する。 id:nullのように状態が可視化されていても、それを見に行って動く仕組みがなければ、見えていないのと同じ結果になります。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』でも、エージェントの性能はモデル単体では決まらず、周囲の環境が何を・どう見せるかという「Harness Engineering」に大きく左右される、という話を1章分使って扱っています。