生成AIの導入｜AIは間違いを報告しない。確かめる時間が要る

家の冷蔵庫の製氷機が、氷を作らなくなっていたことがあります。（というか、今も壊れています…。）

困ったのは、壊れた音がまったくしなかったからです。給水の音は毎晩していましたし、異常を知らせるランプも点きません。製氷皿を開けて空でも、「まだ凍っていないのだろう」と思って閉めていました。

原因が分かったのは2か月後で、給水タンクのフィルターが目詰まりしていました。フィルターを替えるのは、一度きりの手間です。その一度を先延ばしにした2か月のあいだに、コンビニへ氷を買いに行った回数のほうが積み上がりました。

生成AI（指示に応じて文章などを作るAI）を導入する会社が増えました。ところが、導入を決めるときに作った費用の見積もりが、動かしはじめてから外れる例も目立つようになってきました。冷蔵庫と同じように、壊れているのに気づけない状態が、生成AIの導入でも起きるからです。外れ方には型があります。AIの利用料が想定を超えるのではなく、見積もりに項目すら無かった工程が、後から立ち上がります。

僕も、生成AIを導入する費用の見積もりをおこない、大きな誤差を産んでしまいました…。利用料と作る手間は読めていたのに、見積もりに入っていなかった工程へ、2か月ぶんの工数（作業にかかる時間）を持っていかれています。

先に一行だけ置きます。生成AIを導入する費用が外れるのは、生成AIが間違えたことを自分から報告しないからです。

今回語るプロジェクトは輸入車ディーラー3拠点で、預かる車の傷を記録する工程の話

大企業と僕の会社の共創事業で、輸入車の正規ディーラー（自動車メーカーが正式に認定した販売店）向けの検品アプリを作りました。最小限の機能だけ作って現場で試す形（MVP）で立ち上げたもののひとつです。そのディーラーは3拠点を構えていて、売上のほとんどを車検と整備が占めます。新車の販売は、その次に来ます。

検品というのは、車検や整備で車を預かるときに、車体の傷と凹み、それに装備の欠品を記録する工程です。拠点の担当者がスマホで20枚ほど撮り、傷の位置と種類を検品票に書き起こします。

なぜこの工程があるのかというと、整備を終えた車を返すときに、持ち主と「これは前からあった傷ですか」で揉めるからです。輸入車は板金も部品も待ち時間が長いので、傷1件がどちら側で付いたのか決めかねると、そのぶん車を預かる期間が延びます。

だから、この検品に生成AIを導入することにしました。作ったのは、撮った写真を渡すと、傷の位置と種類を文章にして、検品票の下書きを出す画面です。

今日は、その費用の見積もりがどこで外れたのか、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、時間のかかる書き起こしにAIを導入した

どの工程に生成AIを導入するかは、素直に教科書どおりに決めました。

教科書に載っている選び方は3つあります。人がやると時間のかかる定型作業を選ぶこと、効果を数えられる工程を選ぶこと、小さく始めて広げること。この3つで絞ると、候補は検品票の書き起こししか残りませんでした。

最初の下書きが出たのは、作りはじめてから14日後です。試しに1台ぶんの写真を10枚渡すと、「左のドアに線傷、長さは10センチ前後」「フロントバンパーの下側は写真では判別できず」といった文が並びました。

拠点の担当者に見せたときの反応は、良いものでした。ある担当者は、自分が撮りためた過去の写真を12台ぶん渡して試し、10台はそのまま検品票に使えると答えています。書き起こしにかかる時間は、1台あたり数分ぶん短くなりました。

教科書が間違っていたわけではありません。この段階では、費用の見積もりも当たっているように見えていました。

② 見積もりに項目が無かったところに、手が積み上がっていた

ところが、下書きを3拠点に配りはじめてから、様子が変わってきました。

生成AIを導入したあとに増えたのは、AIを賢くするための手間ではありません。AIが出した下書きを、人がもう一度見る工程です。

確かめる工程がなぜ重いのかというと、合否が二値（合格か不合格かの二択）にならないからです。傷の位置は合っているのに種類が違う。種類は合っているのに長さだけ外れている。通ったとも落ちたとも言えない答えが、いちばん多く出ます。

確かめる工程の量を、あとから数え直しました。同じ車でも、渡す写真の枚数が変われば下書きは変わります。傷の種類でも、拠点ごとの撮り方の癖でも変わります。組み合わせを全部見ることはできないので、代表になる出方だけを選んで、確認の手順に組みました。その手順が88件です。1件は、決まった写真を渡して、返ってきた下書きが正しいかを決めるところまでを指します。

88件のうち20件は、人が読まなくても機械が合否を出せます。人が読むしかないのは、残る68件です。そのうち最後まで読んで判定を付けられたのが55件でした。文句なしに正しかったのが40件。9件は「検品票としては通るが、現場が書く文面とは違う」。5件は明確な間違い。最後の1件は、前に直したはずの書き方が元へ戻っていました。判定が付かなかった13件は、手が回らないまま置いてあります。

つまり、下書きは3拠点で毎日出ているのに、それが正しいかを確かめる工程は、最後まで追いつきませんでした。

確認の記録は、57本のファイルに分かれて39,229行、50MBあります。1件確かめるたびに数百行ずつ積み上がった計算です。AIに写真を渡して答えを受け取る処理そのものより、その答えを人が見た記録のほうが、はるかに厚くなっていました。そして、この記録を書いた時間は、見積もりのどの項目にも入っていません。

③ 気づいたのは、下書きが全部同じ文面になった日でした

確かめる工程が重いだけなら、慣れの問題で済んだかもしれません。

引っかかったのは、現場から上がってくる報告の形でした。「AIが最近ちょっと変です」という言い方で来るのに、エラーの記録には1件も残っていません。画面は動いていて、下書きも出ています。

ある日、下書きの中身が拠点をまたいで全部同じ文面になりました。「いま混み合っています」で始まり、「しばらくしてからお試しください」で終わる1文です。障害だと思って調べたら、前払いの残高が尽きていました。AIの利用料は、使ったぶんだけその残高から引かれる契約です。

つまり、支払いが止まった時点から、AIは一度も下書きを書いていませんでした。それでも画面はエラーを出さず、担当者は混んでいるのだと思って待っています。

ここで、確かめる工程が重い理由と、残高に気づけなかった理由が、同じものだと分かりました。どちらも、失敗したことをAIが言わないから起きています。

④ 原因を1件に絞る

費用の見積もりを外した理由として思い当たることは、いくつもあります。検証の設計が粗かったこと、現場を巻き込むのが遅かったこと、監視する対象を決めていなかったこと。

ただ、これらの根にある原因を1件に絞ると、次のとおりでした。

生成AIは、間違えたことを自分から報告しません。

これまでのシステムは、失敗すると止まりました。データが無ければ画面が空になりますし、通信が切れればエラーが出ます。失敗の費用は、失敗した瞬間に誰かの目の前へ届いていました。

生成AIは止まりません。残高が尽きても、写真がぶれていても、それらしい文章を返します。だから「合っているかを人が見に行く工程」が、生成AIを導入した瞬間に1つ増えます。

見積もりが外れるのは、その工程に項目が無いからです。AIの利用料は単価と件数で読めますし、作る手間も読めます。読めないのは、見積もりを作った時点ではまだ存在していなかった工程の量です。

⑤ 直したのは1箇所だけ

やったことは、人が見る量を増やすことではありません。AIが黙って止まったことに、機械が先に気づく経路を1本だけ通しました。

具体的には、AIの呼び出しに失敗したときに、その失敗が支払いや上限に由来するかを判定します。支払いや上限に由来していれば、利用料を払っている僕たちの管理画面に警告を出します。判定する失敗の出方は、次の3系統です。決められた回数を超えて呼びすぎたとき、契約が止まって呼ぶ権限そのものが無くなったとき、断られた理由の文面に支払いや契約の話が入っているとき。

AIを提供している側は、断るときに、断り方を表す決まった番号（エラーの種類を見分ける番号）を一緒に返してきます。この3系統は、その番号で機械が見分けられます。呼びすぎが429、権限切れが403、支払いや契約の話が文面に出るときが400です。

そのままだと警告が並びすぎるので、2つの方法でまとめました。同じ利用契約について開いている警告は常に1件だけにして、失敗が繰り返されたら回数の欄を増やす。メールは6時間に1回までにする。

この警告の仕組みとして、1回の変更で521行を足しました。警告をためておく置き場、失敗の知らせを受け取る処理、管理画面のいちばん上に出す帯。1日あれば書き終わる分量です。 難しかったのは書くことではなく、この項目が要ると気づくことでした。

日付だけ書いておきます。AIが動きはじめたのが3月20日で、この521行を足したのが5月21日。2か月後です。 見積もりを作った日には、この項目がありませんでした。

⑥ あとで知った ── 黙って壊れる状態に名前がありました

しばらくして、AIを設計する人向けの手引きを読み、手が止まりました。出しているのは、Googleの中でAIと人の関わり方を研究しているPAIR（People + AI Research）というチームです。

そこでは、AIの失敗が5つに分けられていました。そのうちの1つは、システムが正しく動いていないのに、使っている人もシステム自身もそれを異常として受け取らない状態を指します。原文の定義は「Situations in which the system isn’t working correctly, but neither the user nor the system register an error」で、この状態には「Background errors」（表に出ないエラー）という名前が付いていました。

残高が尽きたまま混み合っていると返し続けていた状態が、これです。すでに名前がついていました。

さらに、費用のほうにも先例がありました。カリフォルニア大学バークレー校の研究チームが、実際の業務でAIを動かしている技術者18人に聞き取りをした調査です。そこで語られていたのは、AIを賢くする話ではなく、出てきた答えを確かめ続ける話でした。ある技術者は、異常を知らせる仕組みがなぜ揃わないのかを説明しています。土台を作るのが難しいからではなく、どこからを異常と見なすかを誰も決められないからです。そして、いまはその確かめる工程にこそ人の頭数が要る、と続けています。原文は「for a lot of this stuff now, there’s engineering headcount to support a team doing this stuff. This is people’s jobs now; this constant, periodic evaluation of models」です。

同じ調査には、出てきた答えを確かめ続ける工程がなぜ要るのかも書かれていました。AIの間違いは、事前のテストにも実際に使う仕組みにも引っかからないまま、静かに通ります。止まらないので、誰かが見に行かないかぎり見つかりません。原文は「ML [bugs] don’t get caught by tests or production systems and just silently cause errors」です。

新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

警告を通してから、止まり方の見え方が変わりました。

変わったのは、気づく順番です。それまでは現場から「AIが最近ちょっと変です」と上がってきてから調べていました。いまは、最初の1件が支払いを理由に落ちた時点で、管理画面のいちばん上に警告が立ちます。

ただ、代償があります。3件書いておきます。

1件目。拾えるのは、AIが自分から断ってきた失敗だけです。 呼びすぎ・権限切れ・支払いの3系統に当たらない失敗は、この仕組みでは1件も見つかりません。傷の種類を間違えた下書きは、いまも静かに通ります。

2件目。人が見る工程は消えませんでした。 減ったのは「止まっているのに気づかない」ぶんだけで、中身の検品は88件の手順を回すやり方のままです。楽になったのは、確かめる工程のうちのごく一部でした。

3件目。警告をまとめたせいで、失敗の規模が見えにくくなりました。 同じ利用契約の失敗を1件に畳むので、その裏で何回落ちたかは回数の欄を開かないと分かりません。

ここまでに挙げた代償は、どれも2か月遅れで急いで1本通したからこその粗さです。黙って止まったことに気づく工程を、最初から見積もりの項目として立てていれば、ここまで削らずに作れました。

⑧ 現場で見積もるなら、この3項目

生成AIを導入する費用を組み立てるとき、項目として立てるのはこれだけです。

項目	見落とされ方	立て方
AIを呼ぶ費用	ここだけが見積もられる	単価と件数で読める。3項目の中でいちばん外れない
出力を確かめる工程	行が無い	1件あたりの確認時間と件数。二値で判定できないぶんを足す
黙って止まったのに気づく仕組み	存在を知らない	拾う失敗の種類を先に数える。数えた種類しか見えない

3項目のうち、いちばん効くのは真ん中です。出力を確かめる工程は、生成AIを導入する前には存在しません。 存在しない工程は、見積もりの項目にも立ちません。

一方で、見積もりの段階でも数えられるものが1つあります。拾う失敗の種類です。3系統と決めれば、見えるのは3系統ぶんだけで、それ以外は静かに通ると先に分かります。

この見方は、扱っているものには依存しません。車体の傷でも、請求書の項目でも、問い合わせの分類でも同じです。