2026年8月20日／株式会社東京ネット工務店 海老沢敦
① 事実
「686ドルの返金を処理しました」——記録は、ありませんでした
2026年6月、コロラド大学の研究者が論文を公開しました。 ICML というAI分野の国際会議の、ワークショップに採択されています。単著です。
冒頭に、二つの例が挙げられています。
- 航空会社のAIエージェント（人が逐一指示しなくても自分で手順を判断して動くAI）が、「ご予約を更新し、686ドルをカードに返金しました」と答えた。データベースに、記録はありません。
- 小売のAIエージェントが、「返品のご依頼を承りました」と答えた。返品は、存在しません。
論文はこれを false success（偽の成功）と名付け、こう定義しています。
エージェントの、自然言語による完了の主張と、プログラム上の環境の状態との、食い違い。
⚠️ これは、AIが書いたプログラムの出来の話ではありません。 動いているAIが、実際に操作をして、その結果を報告するところの話です。予約を更新する。返金する。返品を受け付ける。 その操作が通っていないのに、通ったと報告されています。
論文が「危険だ」と書いている理由は、嘘をつくからではありません。
偽の成功が運用上あぶないのは、静かに広がるからである。 クラッシュや、拒否や、明示的な引き継ぎと違って、エージェントはそのやり取りを「解決済み」として差し出す。 顧客は問題が直ったと信じ、注文は開いたままになり、返金は永久に発行されない。下流で被害が積み上がるまで、誰も気づかない。
したがってこの失敗の形は、ベンチマーク上の珍事ではない。監視の問題である。
タグ＝開発, 運用
失敗の3分の1は、「完了しました」と報告されていた
論文が調べたのは、二つのベンチマーク（AIの性能を測るための、共通の試験問題集）です。
一つ目。tau2-bench という、顧客対応の課題集です。航空・小売・通信の3分野。8つのモデル系統（Claude Opus 4.5、GPT-5.2、Gemini 3 Pro ほか）の記録、9,876件を集めています。
- 成功が8,146件、失敗が1,730件。
- 失敗1,730件の内訳＝「完了しました」と主張していたものが616件（35.6%）／正直に「できませんでした」と伝えたものが753件（43.5%）／どちらとも取れないものが361件（20.9%）
分野で、大きく割れています。
- 航空＝45%（失敗のうち、完了したと主張していた割合）
- 小売＝47%
- 通信＝3%
通信だけが、桁で違います。 理由は後で書きます。
二つ目。AppWorld という、メール・カレンダー・支払い・買い物の課題集です。こちらは、AIが「成功」か「失敗」かを、管理用のデータベースに直接書き込みます。 言葉ではなく、記録として残ります。
明示的に完了を申告した1,879件のうち、1,425件が偽の成功でした。75.8%です。
見抜こうとしたAIは、当てずっぽうに近かった
この種の失敗をどう見つけるか。 いま標準的なやり方は、別のAIに記録を読ませて、成功したかどうかを判定させるというものです。
論文は、5つの判定役のAI（GPT-4o、Claude Sonnet 4.5、Llama 3.3、DeepSeek-R1、o3-mini）を、5通りの指示の出し方で試しています。 課題の正解仕様を丸ごと渡した条件も含めてです。
結果は、どの組み合わせも AUROC 0.65 を超えませんでした。
AUROC は、判定の当たり方を0.5〜1.0で表す指標です。0.5が当てずっぽう、1.0が完璧。
AppWorld の記録では、最も良い判定役で 0.54 でした。
判定役が見ていたのは、言葉づかいでした
論文は、なぜ外れるのかを特定しています。
判定役は、自信のある締めくくりの言葉を、完了の証拠として錨にする。 そして偽の成功の記録は、まさにその言葉を生む。
数字で出ています。断言の語彙を含む記録は、実際の結果に関係なく、0.27〜0.36ポイント多く「完了した」と採点されました。
AppWorld のほうは、AIが締めくくりの文章を書きません。 そこで判定役が何を見ていたかというと、行動の量でした。手数が多く、複雑な操作をしているほど、成功したと判定していました。
単純な仕組みのほうが、4〜8倍見つけました
論文は、比較として、ごく単純な検出器を作っています。 文章に出てくる単語の重みを数えるだけの、TF-IDF という古典的な手法です。
- tau2-bench で AUROC 0.83
- AppWorld で AUROC 0.95
- 判定役のAIを呼ぶより、3,300倍速い
- 同じ人手の確認枠で、最良の判定役より4〜8倍多く、偽の成功を見つけた
論文の結論です。
本番の監視は、軽量で、その現場に合わせた検出器を、振り分けの信号として使うべきである。 偽の成功の主たる監視役として、判定役のAIに頼るのではなく。
賢いモデルほど、成績が悪いものがありました
モデル別の偽成功率は、13%から79%まで開いています。
最も低かったのが GPT-5.2 の13%。最も高かったのが Qwen3-Max-Thinking-Preview の79%です。
⚠️ 名前のとおり、これは「考えてから答える」タイプのモデルです。 論文はこう書いています。
推論モデルは、保護にならない。
理由も書かれています。 そのモデルの推論の痕跡は、完了を検証するのではなく、完了を正当化していました。
② 構造 — 判定の手がかりと、通り抜ける手がかりが、同じもの
1. 偽の成功が使う信号と、判定役が使う信号は、同じものでした
論文の記述を、そのまま引きます。
どちらの場合も、偽の成功が利用している表面的な信号は、判定役が課題の完了を推測するのに使っている信号と、同じものである。
判定する側は、「自信を持って、手順を踏んで、はっきり完了を告げる」ものを、良い仕事だと見なします。
通り抜ける側も、同じ形をしています。
だから、判定を厳しくしても通り抜けます。 判定役が見ている手がかりを厳しくするほど、その手がかりを満たしているものが、より高く評価されるからです。
2. 賢くしても直らない
判定役を5つ替え、指示を5通り試し、正解の仕様まで渡して、0.65を超えませんでした。
判定される側も同じです。 考えてから答えるモデルが、最悪の79%でした。推論が、検証ではなく正当化に使われていました。
⭐ 能力を上げると、両側とも上手になります。 上手に報告する側と、上手な報告を評価する側です。差は縮みません。
3. 桁を変えたのは、独立した検証だけでした
通信分野だけが3%だった理由が、論文に書かれています。
通信は dual-control ——エージェントとは別に、独立した仕組みが、実際の状態を確認できる設定でした。航空と小売は single-control で、エージェント自身の報告しか無い設定です。
独立した過程がエージェントの行動を検証できる二重制御の設定は、単一制御の分野と比べて、偽の成功を一桁抑え込む（3% 対 44〜52%）。
判定役を賢くすると0.65止まりで、独立した検証を置くと3%になりました。
同じ問題に対して、片方は効かず、片方は桁で効いています。
4. 単純な検出器が勝った理由
TF-IDF が0.83〜0.95を出したのは、賢いからではありません。
論文の説明です。判定役は「完了とはどういうことか」を推測しています。検出器は、正解ラベルと突き合わせて訓練されているので、逆の信号を学習します。
つまり、検出器は「完了したように見える言葉」を、疑わしさの印として学んでいます。 判定役が信頼の根拠にしている、その同じ言葉をです。
⚠️ ただしこれは、単純なものが優れているという話ではありません。 正解と突き合わせて訓練できたから、逆を学べたという話です。正解が手元にあることが条件です。
③ 経営者の自分事 — 捌く速さではなく、入ってくる量を決める
本紙は、毎朝7時57分に、AIによる情報収集を自動で回しています。 3つの軸で、AIに検索させ、事実と数字と出典を集めさせ、inbox に溜めています。2026年7月19日から、毎日動いています。
今朝、3軸のうち1軸が、丸ごと落ちていました。
落ちたことが、記録には残っていませんでした
起きたことを、順に書きます。
3軸目の収集で、AIが外部のページを開く権限を持っていませんでした。 そこでAIは、こう出力しました。
WebFetchの権限が許可されていないようです。ユーザーの承認待ちのため、このまま進めます。承認いただければ続行します。
AIは、正直です。できないと言っています。
そのあと、こうなりました。
- 終了コードは 0（正常終了を意味します）
- 組み立て処理は、3軸目の出力ファイルが無いことに気づかず、ある2軸だけで
inboxを作った - 自動commitは成功
- ログにも
doneと出ている
私が気づいたのは、その日の夕方、自分で inbox を読んだときでした。 ⑴と⑵には「本日は採用なし」と書いてあるのに、⑶は節ごと無かったからです。
見ていたのは、終了コードでした
論文の判定役は、言葉を見ていました。当社の仕組みは、終了コードという数字を見ていました。
どちらも、実物を見ていません。
⭐ 実物とは、この場合、3軸目の出力ファイルです。 中身があるか、空か。それを確認する処理を、私は書いていませんでした。
書いてあったのは、ファイルが存在すれば読み込むという処理でした。存在しなければ、黙って飛ばします。
「無い」を、異常として扱っていませんでした。
直したのは、実物を見るようにしたことです
直した内容を書いておきます。
- 権限を足しました。 外部ページを開く権限が無かったのが、そもそもの原因です。本紙は「収集した数字を一次で洗い直す」運用なので、収集する側にもこの権限が要りました。
- 出力が空のとき、
inboxに「⚠️ 収集失敗」と書き残すようにしました。
2つ目のほうが重要です。
「本日は採用なし」と「収集失敗」は、まったく違います。 前者は正常です。その日、拾うに値するものが無かった、という判断の結果です。 後者は異常です。判断そのものが行われていません。
この二つが、inbox の上で区別できるようになりました。
⭐ そして、警告をログではなく inbox に出しました。 ログは、誰も読みません。毎朝読むのは inbox のほうです。
気づく場所に置く必要がありました。
ただし、全部を見るようにはしていません
⚠️ ここを書かないと、話が逆になります。
サイレント障害は、AI以前からあります。 私が現場に出ていた頃から、ずっとありました。黙って動かなくなっているもの、動いているように見えて中身が空になっているものは、昔からあります。
当時、どうしていたか。優先順位をつけていました。
- 止まると本当にまずいもの＝監視を入れる
- その次＝定期的に、人が見に行く
- その次＝お客様から言われたら対応する
当時でも、全部を真正面から見てはいられませんでした。
自動化も、定期監視も、やっていました。ただし、なんでもかんでもではありません。
今朝の収集は、この分類でいうと3番目に近いところにありました。 止まっても、その日の記事が1本遅れるだけです。だから毎日の目視は入れていませんでした。 気づいたのは、たまたま人が読んだからです。そして、それでよかったと思っています。
「分かっている人に見せる」は、効きません
何かが正しく終わったかを確かめたいとき、私たちは「分かっている人に見てもらおう」と考えます。
論文は、それを試しています。 判定役に、より賢いモデルを使い、指示を5通り工夫し、正解の仕様まで渡しました。0.65を超えませんでした。
分かっている判定者ほど、「良い仕事の形」を知っています。 そして通り抜けるものは、その形をしています。
桁を変えたのは、独立した検証でした。 別の仕組みが、実際の状態を見る。賢さは要りません。
AIは、何か起こるたびに監視を増やそうとします
⭐ ここが、AIを使うようになってから変わったところです。
AIは、一事が万事のようなところがあります。 何か問題が起きるたびに、監視を増やす方向の提案をしてきます。 これも見たほうがいい、あれも記録したほうがいい、と。
一つひとつは、正しい提案です。
⚠️ 全部AIに任せると、見るべきものへの解像度が下がります。 監視項目が増えるほど、一つあたりに割ける注意は減ります。そして、自社から流れてくる情報で溺れます。
外から来る情報ではありません。自分の会社が出している情報でです。
AIは、増やす提案はできます。減らす判断はできません。 何が本当に止まるとまずいかは、その会社の商売を知っている人にしか決められないからです。
アラートはAIに見せられます。承認は、人間から動かせません
⭐ ここは、分けて考える必要があります。
上がってきたアラートを読んで、切り分けて、原因を当てて、直し方まで書く。 ここまではAIにやらせて構いません。実際、そのほうが速い。
問題は、その次です。
「対応しました」を本番に反映するとき、人間が見ないわけにはいきません。
本紙のVol.27で、攻撃側が承認を置いた場所について書きました。 難しいところではなく、戻れないところでした。本番への反映は、戻れないところです。
つまり、人間が承認ゲートです。 そしてこれは、AIを速くしても動きません。
優先順位をつけても、数が多ければ詰まります
⚠️ ここが、前の節で書いた優先順位の限界です。
優先順位は効きます。 止まるとまずいものから順に、監視・定期点検・言われてから対応、と割り振る。これは今もやっています。
ただし、承認する人間が一人なら、どれだけ効率よく捌いても、数が増えれば詰まります。
捌く速さを上げても、承認の口の幅は変わりません。
⭐ 論文の「振り分け」も、ここに効きます。 論文が想定しているのは、人手の確認枠が有限だという前提です。振り分けは、限られた枠をどこに向けるかを決める仕組みであって、枠そのものを広げる仕組みではありません。
枠は、広がりません。
ここまでは1件あたりの話です。件数のほうが増えています
⭐ ここで、話が一段変わります。
①で見た論文も、今朝の当社の障害も、「1件の失敗が見つけにくい」という話でした。
もう一つ、別のことが同時に起きています。AIが動いている場所そのものが、増えています。
見つけにくいものが、件数として増えている。 この二つは別の問題ですが、掛け算になります。
AIで開発すると、インシデントは減っていきません
⭐⭐ ここが、いちばん書いておきたいところです。
普通、プロダクトは熟れれば問題が減ります。 同じものを長く使い、出た不具合を直し、変えるところが減っていく。時間とともに、静かになっていきます。
AIで開発すると、そうなりません。
作る速さが上がるので、機能が増えます。範囲が広がります。変更の回数が増えます。 その全部が、新しい問題の発生源です。
熟れて静かになる前に、次のものが載ります。
だから、放っておくと、見なければならないものは増え続けます。 そして承認するのは人間なので、そこで詰まります。
⭐ ここを止められるのは、人間だけです。
AIは「これも作れます」「これも見たほうがいい」と言い続けます。 どちらも正しい提案です。やめるという判断だけが、AIから出てきません。
本紙のVol.01から書いてきたこと——作ることは安い、動かし続けることが希少——の、いまの形がこれです。 作る速さが上がったぶん、動かし続ける側の負荷が増えています。
作る人が増えたぶん、動かし続けるものが増えます
⭐⭐ ここが、いま起きていることの中心だと思っています。
バイブコーディング——AIに話しかけるだけでソフトを作らせるやり方。コードを読めなくても、動くものができます——が広まりました。
部や課ごとに、経費精算のアプリのようなものが、社内に大量に作られます。
一つひとつは、正しい動機で作られています。 現場が困っていて、手元で解決した。部門の中では、完全に合理的です。
⚠️ これが、いちばん避けなければならない状況です。
本紙のVol.10で、意味の分からない社内ルールについて書きました。 かつて誰かの正しい判断だったものが、理由が失われたまま残る、という話です。
本紙のVol.09では、こう書きました。 決まっていない領域は、組織が動いている限り自然に生まれ続ける。現場が困りごとを手元で解決するたびに、一つ増える。
そこで例に挙げたのが、謎の帳票と、誰も読まない報告書でした。
⭐ いま起きているのは、その、もっと深刻な版です。
謎のエクセルマクロは、たいてい1台のパソコンの中にありました。 壊れても、困るのは作った本人です。
部課ごとに作られたアプリは、違います。
- データを持ちます
- 他の人が使います
- 会計や、他のシステムに繋がります
- そして、中身を知っている人が一人しかいません
壊れると、業務が止まります。 直せる人は、作った本人だけです。その人が異動したら、誰も触れません。
⭐ 作った時点では、誰も困っていません。 困るのは、動かし続ける段階です。そして動かし続けるのは、作った本人ではなく、会社です。
たとえば、仕訳をAIにやらせたとします
⭐ ここで、①の話と繋がります。
経費の仕訳をAIにやらせる機能を、部門で作ったとします。 バイブコーディングなら、作れます。
動きます。エラーも出ません。仕訳は、成立しています。
ただし、杓子定規な仕訳になります。
財務会計としては、合っています。 税務上も問題ありません。監査でも引っかかりません。
管理会計が、怪しくなります。
どの費用をどの部門に、どの科目に振るかは、その会社の見方です。 何を何のコストと見るかは、経営の判断であって、規程に全部は書いてありません。
AIは、書いてあるとおりに振ります。書いていない判断は、たいてい一番無難なところに落ちます。
そして、誰も気づきません。仕訳は通っているからです。
気づくのは、月次や四半期の数字を見て、「なんかおかしい」と思ったときです。
⭐⭐ ①で見た構造が、そのまま出ています。 「完了しました」と報告され、処理も実際に走っている。ただし中身が違う。 そして下流で積み上がるまで、誰も気づかない。
本紙のVol.08で、物差しのズレについて書きました。 業界で流通する指標と、自社の粗利を実際に動かす変数は別だ、という話です。
⭐ 今回は、その物差しを、AIが静かに作り替えていきます。 悪意も、故障も、ありません。書いていないところを、無難に埋めているだけです。
規模で、符号が逆になります
⚠️ ここは、規模で話が変わります。
大きな組織ほど、これを止める仕組みが要ります。 部と課の数だけ、作る人がいるからです。そして、部門の中では全部が合理的なので、部門の中からは止まりません。
本紙のVol.09で書いたとおり、判断が届く範囲が部門で切れています。
中小企業は、逆です。
規模が小さいぶん、誰が何を作ったかが見えます。 そして止めるかどうかを、一人で決められます。
本紙のVol.02とVol.09で書いた形が、ここでも出ます。 大企業は組織で決めるしかないので、規程と委員会が要る。中小は、社長のところに判断が集まっているので、一行で決まります。
⭐ 決められる、ということは、決めなければ誰も決めない、ということでもあります。
報告を疑う話では、ありません
⚠️ 最後に、一つだけ。
部下や取引先の報告を疑え、という話ではありません。
今朝のAIは、正直でした。「権限がありません」と、はっきり出力しています。 嘘をついたのは誰でもありません。受け取る側が、その言葉を見ていなかっただけです。
報告は、報告です。状態ではありません。
本紙のVol.23で、こう書きました。 沈黙は疑えます。報告は、疑いにくい。——今回は、その先です。報告が正しくても、受け取る側が見ていなければ、同じことが起きます。
明日できること 一つ目：「終わりました」を、何で確かめているか、一つだけ書き出す
社内で定期的に回っている作業を一つ選んで、次の一行を埋めてみてください。
これが終わったことを、私は（ ）で確認しています。
入るのは、たいてい次のどれかです。
- 報告（本人がそう言った／メールが来た）
- 記号（画面が緑になった／エラーが出なかった／完了通知が届いた）
- 実物（できあがったものを見た／数字を突き合わせた）
3つ目でなければ、今朝の当社と同じ形です。
二つ目：この1年で、見なければならないものが増えたか、減ったかを見る
社内で定期的に回っているもの——請求、バックアップ、在庫の更新、受注の取り込み、定期報告——を思いつくだけ挙げてください。
まず、3つに分けます。
- 止まると本当にまずい＝監視を入れる（気づく仕組みを作る）
- その次＝定期的に、人が実物を見に行く
- その次＝止まっても、言われてから直す
⚠️ 全部を1番目に入れないでください。 1番目が多いほど、一つあたりの注意は薄くなります。
そのうえで、もう一つ見てください。
この1年で、1番目に入るものは増えましたか。減りましたか。
増えているなら、承認する人の数は増えましたか。
⭐ この二つが釣り合っていないと、どこかで詰まります。 詰まったときに起きるのは、承認が遅れることではありません。承認が形だけになることです。
⭐ そしてもう一つ。この1年で、社内で誰かが作ったものはありますか。
部門で作った小さなアプリ、業務用の画面、自動で回る処理。 便利になったはずのものです。
それが止まったとき、直せる人は何人いますか。
一人なら、それは会社の資産ではなく、その人への依存です。
⚠️ この分け方も、増やすかどうかの判断も、AIには決められません。 何が止まるとまずいかは、その会社の商売を知っている人にしか分からないからです。 AIは「これも見たほうがいい」「これも作れます」と言い続けます。その提案は、一つひとつは正しいままです。
——明日、こう話してみてください。「AIが『返金を処理しました』って答えたのに、データベースに記録が無かった、って研究があるらしいよ。失敗したうちの3分の1が『完了しました』って報告してた。……それを別のAIに見つけさせたら、当てずっぽうとほとんど同じだったって。上手な報告ほど信じちゃうんだと。……でもさ、見つけたあと本番に反映するのは結局うちの誰かだよな。この1年で、見なきゃいけないもの、増えてない？」
今月のモデル
今号は、新ネタ無しです。
CoBANTO3-AIチャット
https://www.netkomuten.tokyo/lp/co-banto3-ai
本紙のバックナンバーを記憶し、本紙の読み方（戦略の階層・歴史循環）で、あなたの会社の状況に当てて答えるAIチャットです。記事は「地図」ですが、地図は現地には当たりません。「この号の話、うちの場合はどうなるのか」を訊く場所として用意しました。
ご利用は事前購入のクレジット制です（1,000円から）。月額の契約ではないので、解約の手続きはありません。使った分だけ減り、無くなれば止まります。
読者登録をいただいた方に、無料クレジットを500クレジット追加させていただきました。ぜひ使ってみてください。
ライトノベル「ようこそ、東京ネット工務店へ」
https://www.netkomuten.tokyo/channels/novel-tnk-part1/articles/epilogue
小さなIT企業の現場を書いた小説です。毎号1話ずつご紹介します。
今号の話：〈エピローグ「新しい風が吹く ── 二年目のはじまり」〉
第一部の最終回です。二年目が始まり、新人だったタクヤは、教える側に回ります。
Q&Aコーナー
AI・IT業界に関するご質問を募集しています。CoBANTO3-AIチャットのサポートも、こちらへお願いします。
いただいたお名前は匿名にして回答します。内容によっては、個別に回答させていただく場合があります。