AI導入の費用｜内訳と工程別の見方・抑える方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI導入の費用は、どこにかかるのか

AI導入の費用は、初期費用と使い続けるあいだ発生し続ける運用費用の2つに分かれます。相場表を見る前に、この2つを分けて考えてください。

	中身	特徴
初期費用	企画、検証、開発、データ整備、導入作業	一度きり。見積書に載る
運用費用	利用料、インフラ、再学習、保守、サポート	毎月かかる。見積書に載りにくい

初期費用だけで比較すると、2年目にずれます。判断に使うなら、「初期＋運用×想定年数」で並べてください。

工程ごとにかかる費用

工程	やること	省くとどうなるか
企画・要件定義	何を解くか、何をもって成功とするかを決める	後の工程が全部ぶれる
PoC（実現可能性の検証）	小さく試して、できるかを確かめる	本開発に入ってから「できない」が分かる
データ整備	学習・参照させる資料を集め、形をそろえる	精度が上がらない原因になる
開発・実装	モデルと周辺の仕組みを作る	—
既存システムとの連携	社内の仕組みに繋ぐ	本数がそのまま費用と期間になる
運用・保守	監視、再学習、問い合わせ対応	使われなくなる

見積書の分量がいちばん多いのは開発ですが、総額を動かすのは前後の工程です。とくにデータ整備と連携は、着手してから量が分かることが多く、ここに「一式」と書かれた見積書は、後から増えます。

費用の内訳（何にお金が出ていくか）

• 人件費 — 設計、実装、データの整備、社内側の担当者の時間
• データ関連 — 収集、クレンジング、タグ付け（アノテーション）
• インフラ・クラウド — 計算資源（GPU）、保存、通信
• ツール・API利用料 — 処理量に応じた従量課金
• ライセンス・SaaSの月額
• 教育・定着の支援 — 現場が使えるようにする作業

生成AIを使う場合、4つ目の性質が他と違います。使うほど増える従量課金なので、利用が広がると費用も比例して増えます。固定費の感覚で見積もると、成功して使われるほど予算を超えるという形になります。

導入のしかたで、費用の桁が変わる

形	中身	向いているとき
既製のSaaS・ツールを契約する	契約して使う。作らない	まず試す。定型の業務
既製品を業務に合わせて調整する	設定・連携・伴走支援	自社の手順に寄せたい
作る（カスタム開発）	要件に合わせて構築	差別化の核になる部分

3つは順番に試せます。既製品で確かめてから作ると、作る範囲そのものが小さくなります。いきなり3段目から始めると、1段目で分かったはずのことに費用をかけることになります。

AIの種類・用途で費用が変わる

同じ「AI導入」でも、何を作るかで桁が変わります。費用の大小を決めるのは、データの集めやすさと、間違いの許容度です。

• チャットボット・社内問い合わせ — 既製品が多く、始めやすい
• 文書の要約・作成支援 — 既製のAPIで組みやすい
• 需要予測 — 過去データの質と量で決まる
• 画像認識・外観検査 — 教師データの作成（タグ付け）が重い
• 音声認識 — 現場の環境音や専門用語で精度が変わる
• RAG（社内資料の検索と回答） — 資料の整理が費用の中心

間違えたときの影響が大きい用途ほど、確認の仕組みに費用がかかります。検査や与信のように誤りが直接損失になる用途では、モデルより検査と記録の作り込みが重くなります。

費用に差が出る5つの要因

要因	効き方
目的と用途	既製品で足りるか、作る必要があるか
データの量と質	整っていないほど、整備の費用が膨らむ
求める精度	最後の数％を詰めるほど費用は跳ね上がる
連携するシステムの本数	本数がそのまま期間になる
体制（外注・自社・併用）	社内の工数をどこまで見込むか

3つ目の扱いを先に決めてください。「精度をできるだけ高く」は要件になりません。何％で運用に乗せるか、足りない分を人がどう埋めるかまで決めて、はじめて見積もれます。

運用にかかり続ける費用

• クラウド・計算資源の利用料
• API・ツールの従量課金 — 利用が増えると増える
• データの更新と再学習 — 精度は放っておくと落ちる
• 保守とセキュリティ対応
• 問い合わせ対応と社内教育
• 出力を確認する人の時間

最後の項目が、見積書に載らないまま発生する費用です。AIの出力をそのまま使える業務は多くありません。誰が、どのくらいの頻度で確認するのかを、導入前に決めておいてください。

AI導入の費用を抑える方法

方法	効き方
スモールスタートする	1業務・一部の人から始める。もっとも効く
PoCで見極めてから広げる	作る前に、できるかを確かめる
既製のSaaS・APIを使う	作らずに済ませる範囲を増やす
オープンソースを活用する	ライセンス費を下げる
段階的に進める	一度に全部を決めず、確かめながら足す
一部を自社で持つ	運用と改善を内側に置き、継続費用を下げる
補助金・助成金を使う	自己負担を下げる

順番があります。まず対象の業務を絞り、次に作らずに済ませられないかを見て、最後に単価と体制を見ます。順番を逆にすると、安く作ったものが使われないまま残ります。

使える補助金・助成金

AIやシステムの導入で使われるものには、IT導入補助金、ものづくり補助金、事業再構築の枠、人材開発支援助成金、業務改善助成金などがあります。

補助金は後払いです。採択されても支払いは実績報告の後になるため、立て替える資金が要ります。対象になる経費の範囲（運用費が対象外のことが多い）と、報告に必要な書類の量を、申請前に確認してください。

見積もりを取るときに確認すること

• データ整備が含まれているか — 含まれていないと自社の工数になる
• 定着の支援が含まれているか — 納品後に使われるかは別の作業
• 成果の指標が定義されているか — 何をもって完了とするか
• 運用費が別に見えているか — 初期費だけの提示に注意
• 内訳の粒度 — 「一式」が多いほど後から増える
• 契約形態 — 請負か準委任かで、変更時の扱いが変わる

複数社を比べるときは、金額ではなく内訳で並べてください。各社が違う範囲を見積もっているのが普通で、金額の差の大半は、範囲の差です。

費用対効果（ROI）の考え方

削減できた時間から、増えた時間を引いてください。増えた時間とは、出力の確認、例外の処理、AIに渡す前の準備です。

あわせて、測る単位と、導入前の数字を先に取っておきます。「1件あたり何分」なのか「1日あたり何件」なのか。導入前を測っていないと、効果を比べる相手がありません。

予算の立て方

• 初年度は投資、翌年から回収と分けて置く
• 運用費を初年度から見込む — 従量課金は利用の広がりで増える
• 社内の工数を金額に換算して入れる — 確認・教育・データ整備
• 広げるときの追加費用を先に見積もる — 部門を増やすといくら増えるか

3つ目を入れていない予算は、必ず超えます。外に払う金額だけを積むと、実際にいちばん使われている資源（自社の人の時間）が計上されません。

費用面でよくある失敗

失敗の型	何が起きるか	手前で防ぐ方法
丸投げする	納品されたが業務に載らない	社内に受け取る担当を置く
ツールを配って終わる	契約数だけ増え、使われない	対象業務を1つに絞って始める
指標を決めずに始める	続けるか止めるかを判断できない	導入前の数字を取る
精度を要件にしない	終わりが来ない	運用に乗せる水準を数字で決める
運用費を見ていない	2年目に予算が合わなくなる	初期＋運用×年数で比較する

5つとも、契約の前に防げます。AI導入で難しいのは作ることより、何をもって終わりとするかを先に決めることのほうです。

AI導入の費用についてよくある質問

Q. AI導入の費用は、何で決まりますか。
目的と用途、データの量と質、求める精度、連携するシステムの本数、体制の5つです。とくにデータが整っていないほど、整備の費用が膨らみます。

Q. できるだけ安く始めるには、どうすればよいですか。
対象の業務を1つに絞り、既製のSaaSやAPIで試してから、必要な部分だけ作るのが順番です。いきなり作ると、既製品で分かったはずのことに費用をかけることになります。

Q. 見積もりで見落とされやすい費用は何ですか。
データの整備、既存システムとの連携、出力を確認する人の時間、そして生成AIの従量課金です。従量課金は、使われるほど増えます。

Q. 複数社の見積もりが桁違いです。どう比べればよいですか。
金額ではなく内訳で並べてください。各社が違う範囲を見積もっているのが普通で、差の大半は範囲の差です。データ整備・定着支援・運用費が含まれているかを1件ずつ確認します。

Q. 費用対効果は、どう測ればよいですか。
削減できた時間から、増えた時間（確認・例外処理・下準備）を引きます。あわせて、測る単位と導入前の数字を先に取っておいてください。取っていないと、比べる相手がありません。

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

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

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

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

この段階では、費用の見積もりも当たっているように見えていました。

ここまでが、AI導入の費用の教科書どおりの整理です。初期と運用を分け、工程ごとに内訳を出し、範囲を絞ってから作る。見積もりの読み方としては、これで揃っています。

この記事の後半で扱うのは、この形で見積もって導入した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の呼び出し（APIコール）に失敗したことを機械が検知し、管理画面に警告する仕組みを1つだけ追加しました。

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

AIの提供会社は、断るときに、HTTPステータスコードと呼ばれる決まった番号（エラーの種類を見分ける番号）を一緒に返してきます。この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が最近ちょっと変です」と連絡を受けてから調べていました。いまは、支払いを理由にAIの呼び出しが1件でも失敗すると、管理画面のいちばん上に警告が立ちます。

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

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

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

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

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

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

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

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

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

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

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

⑨ この見積もり方が効き続ける理由

AIの回答を生み出すモデルが賢くなっても、この3項目は消えないと考えています。

賢くなって減るのは、間違いの件数です。「1件の間違いに気づくまでの手間」は、賢さでは変わりません。むしろ、出てくる文章がもっともらしくなるほど、人が見て気づける割合は下がります。

これまでのシステムは、失敗の費用を、失敗した瞬間に請求してくれていました。「エラーで止まるのは、費用の前払いです」。生成AIは止まらないので、費用は後払いになり、確かめる工程へ回ります。

だから、生成AIを導入する費用は、AIに払う額ではなく、AIが黙っていた時間の長さで決まります。

この見積もりの立て方を実際の工程に落とす話は、生成AI導入支援のページに整理しています。どの工程に生成AIを導入するか決めかねている場合は、こちらからご相談ください。

冷蔵庫のほうは、本日フィルターを替えてから普通に氷が出ています。

ただ、さっき開けたら製氷皿が空でした。まだ凍っていないのだろうと思って、閉めました。

以上です。

▶ この記事のテーマを実務で相談する: 生成AI導入支援

AI導入の費用 よくある質問

AI導入の費用は、何で決まりますか？

目的と用途、データの量と質、求める精度、連携するシステムの本数、体制（外注・自社・併用）の5つです。とくにデータが整っていないほど整備の費用が膨らみます。また「精度をできるだけ高く」は要件になりません。何％で運用に乗せるか、足りない分を人がどう埋めるかまで決めて、はじめて見積もれます。

AI導入をできるだけ安く始めるには、どうすればよいですか？

対象の業務を1つに絞り、既製のSaaSやAPIで試してから、必要な部分だけ作るのが順番です。まず対象を絞り、次に作らずに済ませられないかを見て、最後に単価と体制を見ます。いきなり作ると、既製品で分かったはずのことに費用をかけることになります。

AI導入の見積もりで、見落とされやすい費用は何ですか？

データの整備、既存システムとの連携、出力を確認する人の時間、そして生成AIの従量課金です。従量課金は固定費と性質が違い、利用が広がるほど増えるため、成功して使われるほど予算を超えるという形になります。確認の時間は見積書に載らないまま社内で発生します。

複数社の見積もりが桁違いです。どう比べればよいですか？

金額ではなく内訳で並べてください。各社が違う範囲を見積もっているのが普通で、差の大半は範囲の差です。データ整備が含まれているか、定着の支援が含まれているか、成果の指標が定義されているか、運用費が別に見えているか、「一式」が多くないか、契約形態は請負か準委任かを1件ずつ確認します。

AI導入の費用対効果は、どう測ればよいですか？

削減できた時間から、増えた時間を引いてください。増えた時間とは、出力の確認、例外の処理、AIに渡す前の準備です。あわせて、測る単位（1件あたり何分か、1日あたり何件か）と導入前の数字を先に取っておいてください。導入前を測っていないと、効果を比べる相手がありません。

生成AIの導入費用には、何を見積もるべきですか？

AIを呼ぶ費用、出力を確かめる工程、黙って止まったことに気づく仕組みの3項目を立てます。AIを呼ぶ費用は単価と件数で読めます。出力確認は、1件あたりの確認時間と件数に、二値で判定できないぶんを加えます。監視は、拾う失敗の種類を先に数え、数えた種類以外は見えないと理解しておく必要があります。

生成AIの費用見積もりは、なぜ導入後に外れるのですか？

生成AIが間違えたことを自分から報告せず、それらしい出力を返すためです。その結果、見積もり時には存在しなかった、人が出力を確かめる工程が導入後に増えます。この事例では、AIの利用料と作る手間は読めていましたが、確認記録を書く時間はどの項目にも入っていませんでした。見積もりが外れる主因は、この工程に項目がないことです。

生成AIの出力確認には、どれくらいの作業が発生しましたか？

検品票の下書きを確認する手順は88件あり、そのうち20件は機械が合否を判定できました。人が読む必要があった68件のうち、最後まで判定できたのは55件で、13件は手が回らないまま残りました。確認記録は57本のファイル、39,229行、50MBに達しました。3拠点で下書きが毎日出る一方、正しさを確かめる工程は最後まで追いつきませんでした。

生成AIが黙って止まるとは、どのような状態ですか？

システムが正しく動いていないのに、利用者もシステム自身も異常として受け取らない状態です。この事例では前払い残高が尽きたあとも、画面はエラーを出さず、混雑を伝える同じ文面を返し続けました。担当者はAIが下書きを書いていないことに気づかず、混んでいるのだと思って待っていました。Google PAIRの手引きでは、この状態に「Background errors」という名前が付いています。

生成AIの停止を検知する仕組みは、どのように作りましたか？

AIの呼び出しが落ちたとき、失敗が呼びすぎ、権限切れ、支払いや契約の問題の3系統に由来するかを判定し、管理画面へ警告を出すようにしました。判定には、呼びすぎの429、権限切れの403、支払いや契約の話が文面に出る400を使いました。同じ利用契約の警告は1件にまとめ、繰り返した回数を増やし、メールは6時間に1回までにしました。この変更は521行で、AIが動き始めた3月20日から2か月後の5月21日に追加しました。

生成AIの監視を追加すれば、人による出力確認は不要になりますか？

不要にはなりません。追加した警告が拾えるのは、AIが自分から断った呼びすぎ、権限切れ、支払いの3系統だけです。傷の種類を間違えるような内容上の誤りは、引き続き静かに通ります。そのため、止まっているのに気づかない時間は減っても、出力の中身を人が確かめる工程は残ります。