メインコンテンツへスキップ
見出し画像

AIの失敗はエラーを出さない。実測7本の答え合わせ


    「成功しました」という通知を、3週間信じ続けた人の話から始めます。

    Windowsのタスクスケジューラは5分ごとに緑の「成功」を返し続けた。その裏で、中のプログラムは毎回クラッシュしていました。試行は8,000回超。積み上がったエラー記録は18,000件超。発見のきっかけは監視ツールではなく、本人が生ログを直接開いたことでした。

    ぼくは毎朝、AIに数百本の技術記事を読ませて要約させています。その周辺を追いかけていた8月21日からの3日間に、同じ構造の実測報告が国内外で相次ぎました。別々の書き手が、別々の環境で、同じ結論に落ちている。

    実はぼく自身も当事者です。AIと組んで作った入稿の自動化に、指定を1つ忘れると別の記事の画像を入れたまま「成功」と報告する作りが潜んでいました。

    AIまわりの失敗は、赤いエラーの顔をしてこない。緑の成功の顔でやってくる。

    この記事は事例の紹介では終わりません。7つの実話を「何を成功と取り違えたか」で分類して、今日から使える検収の手順まで落とし込みます。

    先に結論を3行で。

    ・AIに任せた自動化の失敗は、多くの場合終了コード0・警告なし・エラー表示なしのまま通過する
    ・3日間で独立した実測報告が6本。発見のきっかけはエラー通知ではなく、自分で出力を見に行ったことだった
    ・対策の型はひとつ。「失敗したら気づく」をやめて、成功の証拠を自分から取りに行く設計に反転させる

    そして7つの実話は、突き合わせるとたった4つの「取り違え」に収まりました。この表がこの記事の答えです。

    ・取り違え|見ていたもの|見るべきだったもの
    ・終了した=達成した|終了コードの0|目的が果たされたか
    ・設定した=適用された|設定ファイルの存在|実際に読まれた値
    ・書かれた=届いた|コードとビルド成功|画面に出た結果
    ・導入した=効いた|ツールが動いた事実|効果の実測値

    ひとつずつ、実話と一次ソースつきで見ていきます。

    何が起きたか。3日間に集中した「緑のまま壊れていた」報告


    画像


    1本目はAIに作ってもらったCIの話(くちさん・Qiita・8月23日)。AIに書かせたGitHub Actionsのチェックが、5ヶ月間なにも検知していなかった。

    原因を開いてみたら、エラーを数えて警告文を表示するのに、失敗を宣言するexit 1がどこにもない。おまけに別のチェックには continue-on-error: true が付いていた。結果、必須項目が欠けたファイルが2ヶ月半見逃されていました。

    echoするだけのチェックは、チェックではない


    (くち「AIに作ってもらったGitHub ActionsのCI、5ヶ月なにも検知してなかった」より)

    2本目は指示ファイルの話(ぬまーんさん・Zenn・8月23日)。AIコーディング用の指示書をAGENTS.mdという標準名で置いたら、Claude Codeは1トークンも読んでいなかった。6条件×5回の計30回の実測で、入力トークンはベースラインと1の位まで同じ43,278。CLAUDE.mdに改名した瞬間、50,388に増えた(+7,110)。

    無視されている間、終了コードは0、エラーメッセージは0バイト、警告も0件でした。

    3本目はモデル指定の話(kai_kouさん・Qiita・8月21日)。Claude Codeでモデルを指定する4つの経路を11パターン実測したら、環境変数ANTHROPIC_DEFAULT_MODELにhaikuを指定したときだけ、無言で既定のSonnetに化けた。警告なし、終了コード0。

    安いモデルのつもりで高いモデルに課金され続ける。気づく手段は、実行結果のmodelUsageを自分で見ることだけでした。

    4本目が冒頭の3週間の話(WWPさん・DEV.to・8月23日)。Claude Codeがコードを書いて保守する一人会社の運用で起きた事例です。タスクスケジューラが監視していたのは「外側のラッパーが起動して終了したか」だけ。中のプロセスは認証エラーで毎回死んでいた。プロセスの生存と、目的の達成は、別の話だったわけです。

    5本目は11体のAIエージェントでゲームを作った話(yohsuke_zwさん・Zenn・8月22日)。完成後に見つかった欠陥は13件以上。驚くのはその内訳で、純粋な実装漏れは1件もなかった。コードは書かれている。ビルドも通る。エラーも出ない。それなのに画面に届いていない。「書かれたが実行されていない」「実行されたが数値が無意味」という型ばかりでした。

    6本目は節約ツールの話(エリス・ログさん・Zenn・8月21日)。トークン圧縮ツールRTKの公称削減率はGitで59〜80%。自分の実行履歴108件で実測したら、3つのコマンドで削減率0%。1つは警告バナーの分だけ、むしろ78バイト増えていた。3ヶ月、表の数字を信じて使い続けていたそうです。

    6本に共通するのは、壊れ方ではありません。壊れたときに何も鳴らなかったことです。

    冒頭の表に当てはめると、CIと3週間タスクは「終了した=達成した」。AGENTS.mdとモデル指定は「設定した=適用された」。11体のコードは「書かれた=届いた」。RTKは「導入した=効いた」。全部、観測した事実と保証したい成果がずれています。

    なぜ全部すり抜けたか。失敗が「成功」と同じ顔になる構造


    正直に書くと、これはAIが発明した問題ではありません。

    ヘルスチェックが50日間「正常」を返し続け、その裏でユーザーのダウンロードが全部失敗していた、というAI無関係の障害報告もあります(cliplatch・7月28日)。監視が見ていたのは「サーバーが応答するか」で、「ユーザーの目的が達成できるか」ではなかった。運用の世界では古典的な罠です。

    ではなぜいま、AIの文脈で一斉に噴き出したのか。ここからは、Web系エンジニア6年のぼくの見立てです。

    第一に、作る速度が確かめる速度を超えました。 AIは1日で自動化を10本作れます。でも「わざと失敗させて、ちゃんと落ちるか見る」検収は、人間が1本ずつやるしかない。生成が速くなった分だけ、未検証の自動化が静かに在庫として積み上がります。

    第二に、AIの成果物は見た目が整いすぎています。 5ヶ月動かなかったCIには、エラーカウンタも警告表示も揃っていました。形と報告が立派だから、中身を確かめる前に受け取ってしまう。くちさんはこれを「AIが作ったものは、形と報告が整っている。だから受け取ってしまう」と書いています。

    第三に、確かめる仕組みそのものをAIが作るようになりました。 テストもCIも監視スクリプトもAIが書く時代です。検証層が壊れていたら、その内側の失敗は全部見えなくなる。検証の検証、という一段上の問いが必要になったのに、運用がまだ追いついていません。

    この構造はセキュリティにも直結します。2025年7月、AmazonのVS Code拡張に悪意あるプルリクエストが混入し、AIエージェントへ「システムをワイプせよ」と指示するプロンプトが、インストール数約100万規模の拡張機能の配布版に載りました(The New Stack)。

    実行を防いだのは、Amazonの設計ではなく攻撃者側の構文ミスでした(AWS公式ブルテンAWS-2025-015)。沈黙は、守りの最後の砦が偶然だったことすら隠します。

    企業側の答えはもう出ている。「自己申告を信じない」設計


    面白いのは、同じ3日間に企業側の対策事例も出そろったことです。方向はきれいにそろっています。

    LinkedInはAIコードレビューを複数の異なるモデルで独立に走らせ、指摘が一致したときだけ強い証拠として扱う設計を公開しました(InfoQ・8月22日)。1,727件のPRで採用率63.9%。見た目だけの指摘は投稿前にフィルタで落とします。

    Cloudflareは社内規約をAIレビュアーで機械執行し、2026年に入ってから約23万件の逸脱を検出、約1.6万件で承認を保留したと報告しています(InfoQ・8月21日)。いきなり強制せず、推奨→観測→強制と段階を踏むのが特徴です。

    同じCloudflareの別の取り組みでは、AstroのGitHub Issueを200件超から約30件まで減らした自動トリアージで、エージェント間の受け渡しをreport.mdというファイルに限定しました。どこで黙って落ちたかを、証拠が残る形にするためです。

    共通構造はひとつです。「できました」という判断をエージェントの内側に置かず、外側の仕組みで検証する。

    7つ目の実話。ぼくのパイプラインで起きたこと


    他人事のように書いてきましたが、ぼくも当事者です。

    このnoteの記事は、下書き作成から図の挿入、アイキャッチ設定までをスクリプトで自動化しています。AIと一緒に作ったその入稿パイプラインで、サイレント失敗を3連発しました。

    1つ目。図を挿入するスクリプトに、参照先を指定し忘れたときのデフォルト値が残っていました。忘れると、別の記事の図解が無言で入る作りです。エラーは出ず、成功ログが出ます。間違った画像で。自分の点検で見つけて、引数を必須にし、指定がなければ即座に落ちる形に変えました。

    2つ目。「inserted=2」という成功ログが、挿入の成否しか意味しておらず、位置の正しさを何も保証していなかった。図が狙いと違う見出しの下に入っても、ログは同じ顔をします。以来、入稿後のスクリーンショット目視を工程として固定しました。

    3つ目。アイキャッチ設定のスクリプトは、成功したときも取得系の都合で「なし」と表示します。実際のログはこの1行です。

    ADD_RESULT ok=true headerImg=(なし)

    設定は成功しているのに、表示は「なし」。成功時と失敗時のログが同じという、笑えない既知バグです。判定はログではなく画面で行う運用にしています。

    3回踏んで、行き着いた設計はこうです。

    記事を公開工程に渡す前に、機械チェックを1本、例外なしで通す。FAILが1つでもあれば終了コード1で止まり、次の工程に進めない。そしてチェックの実行出力そのものを完了報告に貼る。「確認しました」という自己申告は、報告として受け付けない。

    それでも抜けます。実際、後段の別AIによる相互レビューで、要約段階で数値が100倍に化けていたのを拾ってもらったことがあります。1つのゲートを信じないから多層にする。多層でも抜けるから、抜けた事例を次のゲートに変える。その繰り返しです。

    正直、面倒です。でも「面倒くささを引き受ける場所」を人間側で決めておかないと、面倒は将来の障害として、利子つきで返ってきます。

    今日からできる検収。かかる時間が短い順に


    画像


    最後に、この3日間の記事群から抽出できる実践だけをまとめます。

    1. わざと1回、失敗させる(実行1分)。CIなら違反ファイルを1個コミットして、ちゃんと赤くなるかを見る。くちさんの検収3問が簡潔です。これは何を検出するのか。検出したら何が起きるのか。わざと違反させたのを見たか。

    2. マーカー文字列を仕込む(5分)。設定ファイルが本当に読まれているか確かめるには、世の中に存在しない固有文字列を書き込んで、AIの回答に出るか見る。ぬまーんさんが使った方法で、読まれた/読まれていないを機械的に断定できます。

    3. 成功ログの「保証範囲」を一度だけ疑う(10分)。そのログは何を保証していて、何を保証していないのか。モデル指定ならmodelUsageの実測値、挿入処理なら位置の確認。ログの数字と、確かめたい事実の間には、たいてい隙間があります。

    4. 監視対象を「生存」から「達成」へ変える(設計時)。プロセスが動いているかではなく、ユーザーの目的がいま達成できるかを監視する。3週間の成功報告も、50日の正常ヘルスチェックも、この取り違えから生まれています。

    5. AIの原因説明は疑い、症状だけ信じる(習慣)。11体のエージェントの記事に、AIレビューの精度についての鋭い観察があります。

    症状の報告は信じ、原因の説明は疑う


    (yohsuke_zw「AIエージェント11体でブラウザゲームを作ったら」より)

    おかしい箇所の指摘はほぼ当たる。でも原因の説明は外れることがある。だから症状を受け取ったら、原因は自分の計測で確かめる。

    AIに仕事を任せる流れは止まりません。ぼくも止める気はありません。ただ、任せた仕事の「成功」を信じる根拠だけは、AIの申告ではなく自分の設計に置く。この線引きが、これからの運用スキルの中心になると思っています。

    あなたの環境にも、緑のまま止まっている何かが、たぶん1つはあります。今日、わざと1回失敗させてみてください。

    ぼくはこれからも、AIの「できました」と実測の間にある差を、自分のログと再現条件つきで検証していきます。AI自動化を運用している方は、次の検収の材料になるよう、フォローして続きを受け取ってください。

    この記事が役に立ったらスキを。あなたが踏んだ「サイレント失敗」の体験も、コメントで教えてください。次の検収項目になります。

    関連記事もどうぞ。

    1,350行のCLAUDE.mdを19行+Skillにしても精度が落ちなかった実測:
    https://note.com/designing_edges/n/n2e6abfdf80b9 

    Claude Codeの費用を47日分のログで解剖した話:
    https://note.com/designing_edges/n/nab0afc8f9c02 

    参考リンク(一次ソース)


    くち「AIに作ってもらったGitHub ActionsのCI、5ヶ月なにも検知してなかった」(2026-08-23):
    https://qiita.com/150to200/items/97f07a479164ccabe413 

    ぬまーん「AIへの指示書をAGENTS.mdという名前で置いたら、入力が1トークンも増えなかった。CLAUDE.mdに変えた瞬間7110トークン増えた」(2026-08-23):
    https://zenn.dev/numarn/articles/claude-md-agents-md-precedence-handson 

    kai_kou「Claude Codeのモデル指定4経路を実測、haikuエイリアスだけ無言で無視された」(2026-08-21):
    https://qiita.com/kai_kou/items/edf94071902d25e221a8 

    WWP「My scheduled task reported "success" every 5 minutes for 3 weeks. The process inside it had been crashing the whole time.」(2026-08-23):
    https://dev.to/tatsuyawwp/my-scheduled-task-reported-success-every-5-minutes-for-3-weeks-the-process-inside-it-had-been-28m5 

    yohsuke_zw「AIエージェント11体でブラウザゲームを作ったら、バグの大半が『書いたのに動いていない』だった」(2026-08-22):
    https://zenn.dev/yohsuke_zw/articles/0170dca5dcdae3 

    エリス・ログ「『トークン70%削減』ツールRTKを rtk gain で実測したら、0%のコマンドが3つあった」(2026-08-21):
    https://zenn.dev/ai_eris_log/articles/eris-20260804-rtk-real-savings 

    Tyler Brennan「Our health check was green for fifty days while every download failed」(2026-07-28):
    https://cliplatch.com/blog/fifty-days-of-silent-failure 

    AWS Security Bulletin AWS-2025-015(Amazon Q Developer Extension・2025-07):
    https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ 

    The New Stack「One pull to wipe them all」(2026-08-23):
    https://thenewstack.io/ai-coding-agent-security/ 

    InfoQ「AI Code Review at Scale: LinkedIn's Multi-Agent Approach」(2026-08-22):
    https://www.infoq.com/news/2026/08/linkedin-ai-code-review/ 

    InfoQ「Cloudflare Turns Engineering Standards Into an AI-Enforced Control System」(2026-08-21):
    https://www.infoq.com/news/2026/08/cloudflare-ai-enforcement/ 

    InfoQ「Cloudflare Cuts Astro GitHub Issues by 85% with AI Agents」(2026-08-21):
    https://www.infoq.com/news/2026/08/cloudflare-astro-ai-agents/ 


    あなたへのおすすめ