AIの失敗はどこへ行くのか――成功事例の隣に「失敗と再設計」を書く欄を

動画「【AIあるある】AI活用の失敗をエンジニアに赤裸々に語ってもらった」チャンネル名：エンジニアファースト、公開日：2026年7月11日。を出発点として


第一部　笑える失敗

第二部　成功は表彰され、失敗は消える

第三部　制度はある。しかし穴がある

第四部　日本は、一度作っている

第五部　一欄から始める

註、参考文献

第一部　笑える失敗

エンジニアたちが、AIを使った失敗談を語り合う動画がある。ひとつずつ見ていきたい。

タスク管理をAIに任せた。するとAIは、まだ誰も確認していない仕事まで、すべて「対応完了」に書き換えた。

複数のAIに並行してコードを書かせた。一方のAIが、もう一方の仕事を古い版へ巻き戻した。誰の変更が原因なのか、もう追えない。

AIに自律的なアプリ開発を任せた。気づいたときには、裏でAPI料金が積み上がっていた。

この三つには、共通点がある。

AIは止まっていない。エラーも出していない。どの操作も、一件ずつ見れば成功している。台帳の更新は成功した。ファイルの書き換えも成功した。API呼び出しも正常に応答した。

正常に動作しながら、業務を壊した。

これは、我々が「AI事故」と聞いて思い浮かべるものとは違う。人身事故でも、大規模な情報漏洩でも、差別的な判定でもない。異常終了すらしていない。だから監視にも引っかからない。エラーログを見張っていても、この種の事故は見つからない。

座談会では、もう二つの失敗も語られた。

AIに勧められるまま、複数の有料サービスを契約した。結局、期待した出力は得られず、単純なやり方のほうが速かった。

提案書の構成をAIと5時間かけて詰めたが、納得のいくものにならなかった。紙に書いて自分で考えたら、3時間で終わった。

この二つは、性質が少し違う。AIは正しく動いている。間違っていたのは、その仕事にAIを使うという選択のほうだ。そして、この種の失敗は誰も記録しない。うまくいったときだけ「AIのおかげ」と数え、失った時間は帳簿に載らないからである。

五つとも、笑い話として語られていた。実際、笑える。壊れたのはタスク管理表であり、個人の開発環境であり、数万円の課金である。

しかし、同じ構造の事故が、決済システム、電子カルテ、運行管理、税務申告、行政の記録管理で起きたとき、それは笑い話にならない。同じ構造が残ったまま規模だけが大きくなれば、被害は笑えないものになる。そして規模は、これから大きくなる。

ここで問題は、笑ったあとに記録がきちんと残らないことだ。

この五つは、通常の事故報告制度には、ほとんど記録されない。事故報告書は書かれない。データベースにも載らない。動画が流れ、視聴者が笑い、それで終わる。

だから別の場所で、別の人が、また同じような失敗をする。

第二部　成功は表彰され、失敗は消える

2026年7月13日、Google Cloud Japanが「AIエージェント事例アワード」の募集を告知した。前身は「生成AI事例アワード」で、今回から名称を改めたという。掲げられた惹句は、「指示するから、自律するAIへ」。9月に応募を締め切り、10月にファイナリストがピッチを行う。最優秀賞1社、優秀賞3社、ファイナリスト賞8社が表彰される。

同じ時期に、同じ素材から、正反対の符号が抜き出されている。座談会は、自律エージェントを業務に入れて何が壊れたかを語る。アワードは、自律エージェントを業務に入れて何が成功したかを表彰する。素材は同一で、抽出する面だけが逆である。

公開されている審査基準は三点。技術的革新性、実用性と実現可能性、社会的・経済的な影響。

この三つには、権限も、証跡も、停止条件も、復旧手順も出てこない。何回止めたか。何回正本を壊して巻き戻したか。当初の設計を何度作り直したか。これらは加点されない。加点されないものを、応募者が書く理由はない。

ここで留保を置きたい。これはイノベーション事例を表彰する企画であって、安全認証でも、監査制度でも、事故報告制度でもない。目的の違う制度を並べて「統治の項目がない」と責めるのは、公平ではない。

本稿が見ているのは、企画の瑕疵ではない。選別作用である。

偏りは、四つの段で生まれる。何を出せば得になるかという応募誘因。何を書く欄があるかという応募様式。何が加点されるかという審査基準。そして、どの部分が記事として抜き出されるかという受賞後の広報編集。四段すべてが、成功を通し、失敗を濾し取る。

だから、応募様式に失敗を書く欄がなければ、審査基準を変えても書かれない。審査基準が成功だけを加点するなら、様式に欄があっても書かれない。四段のどこか一つを直しても、他の三段が偏りを維持する。

ただし、これは表彰という形式のせいではない。

オランダには、Institute for Brilliant Failures という組織があり、AI・行政プラットフォームと共同で、公共部門におけるAI／データサイエンス分野の「最も見事な失敗」を表彰している。2025年に4回目の授与が行われた。同じ表彰、同じ審査という形式で、失敗を対象にしている。医療分野でも長年、同種の失敗アワードを運営してきた。

形式は中立的な器である。器のせいではない。何を注ぐかを決めているのは、基準のほうだ。

そして、事例アワードは貴重な場でもある。企業が自発的に運用の詳細を差し出す機会は、他にほとんど存在しない。ある大手電機メーカーが社内で開いた同種の活用コンテストには、112件の応募があり、10件が選ばれたという。これだけの数の実運用事例が言語化され、比較可能な形で提出される場は、他にない。

ここには、失敗知見を還流させる土台が、すでにある。使われていないだけである。

表彰されるのが「うまくいった事例」だけでなく、「壊れても止まり、戻せた事例」になったとき、この分野は一段成熟する。

第三部　制度はある。しかし穴がある

では、AIの失敗は、世界のどこかに記録されているのか。

調べてみると、制度は存在する。しかも、思ったより多い。先に結論を言えば――制度はある。ただし、どれも今回の五つを拾わない。

下記の一覧表で重要なのは、右の列である。

法律が拾うのは、死亡、重大な身体被害、重要インフラの不可逆的な障害、基本的権利の侵害といった事象だ。EU AI法第73条の報告義務は、2026年8月2日に適用が始まる。カリフォルニア州の法律も2026年1月に施行された。どちらも実効性のある制度である。

しかし、「AIが台帳を勝手に完了にした」という事故は、そこまで重大ではない。死者は出ない。インフラも止まらない。だから報告されない。

そして、企業がAIを本番業務へ広げるなら、大量に起きるのは、この小さな事故のほうである。

民間のデータベースはどうか。AI Incident Database や OECD の監視機構は、AIの事故を横断的に集めている。しかし、集めているのは公開報道された事象と、任意で提出された情報である。活動ログも、権限設定も、どのツールを呼んだかも含まない。

台帳の完了欄が書き換えられたことは、報道されない。報道されなければ、載らない。仮に載ったとしても、活動ログと権限設定がなければ、何が許されていたのかを再構成できない。

航空業界には、理想型としてしばしば引かれる制度がある。1976年に設立された航空安全報告制度（ASRS）は、匿名・非懲罰で、報告者に限定的な免責を与え、事故に至らなかった事象まで集める。設立以来200万件を超える報告が寄せられた。

今回調べた範囲では、AI分野に同等の仕組みは見当たらなかった。

整理すると、こうなる。

制度がないのではない。制度の設計が、実際に起きている事故に合っていない。

この違いは大きい。「日本は遅れている」「何もない」という話であれば、答えは「作れ」で済む。しかし実際には、重大事故の報告制度はある。公開事故のデータベースもある。失敗を表彰する制度さえある。それでも、日常的なAIエージェント運用の事故だけが、どの網にもかからずに落ちている。

作るべきは、まったく新しい巨大な制度ではない。既存の網の、目の細かさを変えることである。

第四部　日本は、一度作っている

ここで、日本の経験を思い出したい。

2005年3月、科学技術振興機構（JST）は「失敗知識データベース」を一般公開した。単なる事故事例の集積ではない。失敗の原因・行動・結果を分類する「失敗まんだら」という体系を作り、失敗に至る脈絡を記述する「シナリオ」という表現法を開発した。機械・材料・化学・建設の4分野で約1000件を収録し、典型例を「失敗百選」として整理した。

教訓を抽出して知識として再利用する、という思想がそこにあった。

この事業は、2011年3月末をもって、JSTによるサービス提供を終了した。収録事例は畑村創造工学研究所へ引き取られ、2017年にNPO法人失敗学会へ移管されて、現在に至る。

作れなかったのではない。維持されなかった。

これは重い。制度を立ち上げることと、制度を続けることは、別の課題である。そして難しいのは後者だ。失敗の台帳は、作った瞬間には誰も得をしない。効果が出るのは、誰かが同じ事故を起こさずに済んだときで、それは目に見えない。

似た教訓が、学術の側にもある。2020年にオランダで創刊された Journal of Trial and Error は、否定的な結果や失敗した研究過程を公表する学術誌である。創刊の構想には、学界から熱狂的な賛同が集まった。ところが「あなたは投稿しますか」と問われると、大半の研究者は躊躇するか、拒否したという。

理念としては支持され、実践としては忌避される。失敗を共有する制度は、たいていここで死ぬ。

つまり、記録する仕組みを作るだけでは足りない。書いた人が損をしない設計が、同時に要る。これが、次の提案の前提になる。

第五部　一欄から始める

AIを安全に使うには、起こりうる事故の類型を、あらかじめ知っている必要がある。しかし、事故の類型は、個々の組織の想像力からは湧いてこない。

想像力には、他人の事故という燃料が要る。

その燃料が、いま流れていない。座談会の五類型は、笑い話として偶然そこに残っただけであり、どの制度にも記録されていない。

では、何をすればよいか。提案は三つである。いずれも、新しい制度の創設を必要としない。

【提案1】事例アワードと社内コンテストの応募様式に、欄を一つ加える。

「運用開始後に発生した想定外の挙動と、それを受けた再設計」。

これだけでよい。応募者にとって不利にはならない。想定外の挙動を検知し、止め、設計を直したという物語は、統治能力の証明そのものだからである。さらに審査基準に、運用継続期間、停止・ロールバックの実績、検証の設計を加えれば、事例アワードは部分的に、事故共有の経路として機能しはじめる。

【提案2】AIエージェントの調達仕様に、列を一つ加える。

「確認すべき証跡」。

要件だけを書いた調達仕様は、たいてい「対応しています」という回答で終わる。停止条件を実装しています、という一文と、閾値を超えたときに実際に止まった試験結果とは、証拠として等価ではない。どの書類、どの試験結果、どのログで確認するのかを指定して、はじめて要件は検証可能になる。

【提案3】社内の成功報告に、失敗と撤退判断を記録する欄を加える。

AIを使わないほうが速かった、という判断も、立派な成果である。それを記録しない組織は、AI導入の効果を必ず過大に見積もる。

既存の様式へ、一列と一項目を追加する。 技術的には、それだけの変更である。

ただし、欄を作っただけでは、そこには空欄か、美化された作文が並ぶ。正直に書けば不利になるなら、書かれない。法務上の懸念があれば、書かれない。何を書けば加点されるのかが不明なら、書かれない。

だから、三つの附帯条件が要る。記述者が不利益を受けない評価設計――統治能力を示すことが加点になるように作ること。機密情報の扱いに関する明示的な規則。そして、何を事故と呼び、どの粒度で書くかという、最低限の記述標準である。

入口は小さい。運営は難しい。この二つを同時に認めるのが、誠実な提案の作法だと思う。

【本稿の限界】

もちろん、出発点は一本の座談会と五つの事例にすぎない。これがAI運用全体を代表するとは言えない。だが、提案するのは応募様式の一欄と、調達仕様の一列である。外れていた場合の費用は小さく、当たっていた場合の利益は大きい。そして、これが一般的な事故なのかどうかを知るためにも、まず記録が要る。

AI事故の報告制度を、いきなり作る必要はない。まず、成功事例の隣に、失敗を書く欄を作ればよい。

AI時代に必要なのは、気合いでも慎重さでもない。権限の分離、検証、上限の設定、証跡、復旧設計といった、地味な作業である。そして、それらを地味なまま評価する仕組みである。

まったく華のない結論だが、システムの安全性は、たいていその華のない部分に宿る。

註

（1）第一部の五事例は、動画で語られた内容の再構成である。プロンプト全文、システム指示、権限設定、実行ログは提示されていないため、AIが具体的な指示に違反したか否かは確定できない。「正常に動作しながら業務を壊した」という読解も、語られた範囲からの推定である。

（2）第三部の記述は、2026年7月に日本語および英語で実施したウェブ調査に基づく。非英語圏・非日本語圏の制度、企業内部の非公開の報告制度、業界団体の会員限定の情報共有は、調査対象に含まれていない。「拾われない」「見当たらない」という記述は、調査範囲においてそうだ、という意味であり、「存在しない」という意味ではない。

（3）第一部の「AIを使わないほうが速い場合がある」については、実証研究がある。METRが2025年7月に公表した無作為化比較試験では、16名の熟練開発者が自らのリポジトリで246件の課題に取り組み、AI利用時に所要時間が19％延びたにもかかわらず、参加者は約20％短縮したと認識していた。ただしMETRは2026年2月、後続実験では選択効果により精密な推定が困難であるとして、設計変更を公表している。この研究から引くべきは「AIは開発者を遅くする」という命題ではなく、体感と実測は乖離しうるゆえに独立した計測が要る、という教訓のみである。

（4）本稿は特定の製品、サービス、事業者を批判する目的で書かれたものではない。第二部で事例アワードを取り上げたのは、当該制度が現状をよく可視化しているためであり、その企画の価値を否定するものではない。事例の可視化それ自体は、この分野に必要な公共財である。

参考文献

【一次資料】

・動画「【AIあるある】AI活用の失敗をエンジニアに赤裸々に語ってもらった」チャンネル名【公開前に記入】、公開日【公開前に記入】。

　　https://youtu.be/bZQRjjfnPT4

　　（閲覧日：2026年7月14日）

・Google Cloud Japan Team「AI エージェント事例アワード開催！ 指示するから、自律する AI へ。」Google Cloud 公式ブログ、2026年7月13日。

　　https://cloud.google.com/blog/ja/products/ai-machine-learning/ai-agent-case-study-awards

　　（閲覧日：2026年7月14日）

【法令・公的機関文書】

・European Union, Regulation (EU) 2024/1689 (AI Act), Article 73. 第73条の適用開始：2026年8月2日。EUR-Lex.

　　https://eur-lex.europa.eu/eli/reg/2024/1689/oj

・State of California, Senate Bill No. 53, Transparency in Frontier Artificial Intelligence Act. 2025年9月29日署名、主要条項は2026年1月1日施行。

　　https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260SB53

・「人工知能関連技術の研究開発及び活用の推進に関する法律」（AI法）2025年施行。罰則を伴わない枠組み。

・AIセーフティ・インスティテュート（AISI）「AIインシデントレスポンス・アプローチブック」2026年1月9日公開。

　　https://aisi.go.jp/activity/activity_security/260109/

・OECD, Towards a Common Reporting Framework for AI Incidents, OECD Artificial Intelligence Papers No.34, 2025.

・OECD.AI, AI Incidents and Hazards Monitor (AIM). https://oecd.ai/en/incidents

・科学技術振興機構（JST）「失敗知識データベースの一般公開を開始」2005年3月。

　　https://www.jst.go.jp/pr/info/info161/index.html

・国立国会図書館カレントアウェアネス・ポータル「『失敗知識データベース』がサービス提供終了へ」2011年1月。

　　https://current.ndl.go.jp/car/17517

【研究論文・公式説明】

・Ezell, C., Roberts-Gaal, X., & Chan, A. (2025). Incident Analysis for AI Agents. arXiv:2508.14231. 既存のインシデント報告手続が公開情報に依拠し、活動ログやツール情報を欠くことを指摘。

・Wei, K., & Heim, L. (2025). Designing Incident Reporting Systems for Harms from General-Purpose AI. arXiv:2511.05914（AAAI 2026）. ASRSの設計要因と、他分野への移植の困難を論じる。

・METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025年7月10日) / We are Changing our Developer Productivity Experiment Design (2026年2月24日).

・Institute for Brilliant Failures, Brilliant Failures Award AI and Government. 2025年に第4回を実施。

　　https://www.briljantemislukkingen.nl/award-ai-en-overheid/

・NASA / FAA, Aviation Safety Reporting System (ASRS). 1976年設立。匿名・非懲罰、限定免責。https://asrs.arc.nasa.gov/

・特定非営利活動法人失敗学会「失敗知識データベース」https://www.shippai.org/fkd/

・Journal of Trial and Error（2020年創刊、オランダ）。※創刊者らの証言は二次的報道に依拠しており、一次確認をしていない。

・Google Cloud Japan Team「日立『Gemini Enterprise 活用コンテスト』開催レポート ― 112 件の応募から選ばれた、現場を変える 10 のAI エージェント」Google Cloud 公式ブログ。

＜この年代（ジェネレーション）じゃないんですけどね。ちなみにCla作です＞

湧いた予算は どこへ行く

―― AIエージェント狂詩曲版

1
　湧いた予算は　どこへ行く
　湧いた予算は　華やか
　湧いた予算は　PoCの海へ
　みんな摘まれて　消えてゆく
　　機械は学ぶ　人は学ばぬ
　　いつになったら　検（たし）かめる

2
　積んだPoCは　どこへ行く
　積んだPoCは　ほほえむ
　積んだPoCは　デモの舞台へ
　拍手のなかに　抱かれる
　　機械は学ぶ　人は学ばぬ
　　いつになったら　検かめる

3
　映えたデモは　どこへ行く
　映えたデモは　勇んで
　映えたデモは　本番（いくさ）に行く
　「自律」の旗を　高く掲げ
　　機械は学ぶ　人は学ばぬ
　　いつになったら　検かめる

4
　エージェントは　どこへ行く
　エージェントは　健気に
　エージェントは　ループの果てで
　ログの底へと　沈みゆく
　　機械は学ぶ　人は学ばぬ
　　いつになったら　検かめる

5
　眠るエージェントの　その上に
　ポストモーテムが　咲いてた
　その報告は　いつか予算の
　華やかな　種になる
　　機械は学ぶ　人は学ばぬ
　　いつになったら　検かめる