「AIが100%正確になったら導入します」。導入検討の場で、この言葉を何度も聞いてきました。一見すると慎重で合理的な態度に見えます。しかしこれは判断の保留ではなく、事実上の「導入しない」という決定です。AIの誤りがゼロになる日は来ません。そして人の作業もまた、無誤りではありません。問うべきは「どこまで正確になるか」という上限ではなく、「この業務では、どれだけの誤りなら許せるか」という許容量です。その量を先に決めた組織だけが、AIを実際の業務に組み込めます。
「100%になったら」は判断の先送りです
この言葉が厄介なのは、間違っているからではなく、誰も反対できないからです。完全になってから使うという方針に、正面から異を唱える人はいません。その結果、検討は静かに棚上げされ、決めなかった責任も誰にも残りません。しかしAIは確率的に動く道具であり、誤りをゼロにする仕組みではありません。100%を条件にすることは、満たされない条件を掲げて検討を終わらせることと同じです。
さらに悪いことに、待っている間も判断の材料は増えません。AIがどこでどう誤るかは、自社の業務で動かして初めて分かります。先送りを選んだ組織は、精度の向上を待っているつもりで、実際には自社に固有の知見が貯まらない状態を選び続けています。
グーグルは先に「誤りの予算」を決めました
ここで参照したいのが、グーグルが2016年に公開した書籍『Site Reliability Engineering』（O'Reilly）です。同社でサービス運用部門を築いたベンジャミン・トレイナー・スロスは、「100%は、ほぼすべてのものにとって誤った信頼性目標だ」と述べています。利用者は、システムが100%動いている状態と99.999%動いている状態を、そもそも区別できないからです。
そこでグーグルは発想を逆転させました。まず「このサービスは99.9%動けばよい」と目標を決めます。残りの0.1%が、許容する誤りの量、すなわち「エラーバジェット（誤りの予算）」です。開発チームはこの予算の範囲内で、新機能の投入という危険を伴う変更を行えます。予算を使い切ったら、新しい変更を止めて安定化に専念します。誤りを先に予算化したことで、「速く変えたい開発」と「壊したくない運用」の終わりのない対立が、数字の上の合意に変わりました。
ただし射程には限定があります。これは大規模なネットサービスの稼働率の話であり、数値をそのまま一般の業務に移植できるわけではありません。それでも「許す誤りの量を先に合意してから運用する」という意思決定の構造は、一社単位のAI導入でもそのまま成り立ちます。
誤りの置き場所を決めたら、次に量を決めます
本稿の議論は、「AIはどの仕事で誤りやすいか」という能力の見極めとは別の話です。どの業務にAIを置くかは境界の問題であり、置いたあとに何件まで許すかは量の問題です。置き場所の決め方は別稿に譲り、本稿は量の合意に絞ります。また、誤りが実際に起きたときに誰がそれを引き受けるかという役割の割当は既存記事「AI導入の最初の仕事は、誤りの『持ち主』を決めることです」の主題であり、本稿が扱うのはその手前にある「どれだけの誤りなら許すか」という量の合意です。
量の合意を阻んでいるのは、人とAIに対する奇妙な非対称です。人の作業も無誤りではありません。転記の間違いや確認漏れは、どの現場でも日常的に起きています。それでも人の誤りは「仕方がない」と暗黙のうちに吸収され、AIの誤りだけが「一件でもあれば中止」と扱われがちです。この非対称を放置する限り、精度がどれだけ上がっても導入は進みません。
誤りの許容度は三つの問いで決められます
許容度は感覚ではなく、業務ごとに次の三つの問いで判定できます。第一の問いは頻度です。「十件に一件誤ったら業務は破綻しますか。百件に一件ならどうですか」。破綻しない割合の見当がつけば、それが予算の上限になります。第二の問いは痛みです。「その誤りは謝罪と修正で済みますか。それとも契約や安全やお金の流れに関わりますか」。取り返しのつく誤りと、つかない誤りをここで分けます。第三の問いは検知です。「誤りは出た瞬間に見つかりますか。それとも数か月後に発覚しますか」。すぐ見つかる誤りは直せますが、遅れて見つかる誤りは被害が膨らみます。
三つの答えを組み合わせると、予算の厚みが決まります。問い合わせメールの一次仕分けのように、痛みが小さく検知も速い業務は、予算を厚く取れます。与信の判断や契約条項の確認のように、痛みが大きく発覚も遅い業務は、予算をほぼゼロに置き、人の確認を残します。「うちには一件も誤れない業務がある」という声は正しいのです。この枠組みの価値は、まさにその予算ゼロの業務を名指しで定義できることにあります。全業務を暗黙のうちにゼロ扱いするから、どこにも導入できなくなるのです。
誤り予算は五つの手順で業務に置けます
手順は次の通りです。①対象業務を一つ選びます。②三つの問いに答え、許容水準を一文にします。「月に数件までの仕分け間違いは許容し、当日中に人が直す」といった書き方です。③検知の仕組みを先に用意します。抜き取り確認、金額の突き合わせ、顧客からの指摘窓口など、誤りが必ず視界に入る経路を作ります。④予算を超えたら止めるルールを決めます。グーグルが予算超過で新規リリースを凍結するのと同じ型です。⑤その業務の誤りに答える責任者を一人決めます。
経理の仕訳候補の提示、見積書の下書き作成、採用応募書類の一次整理といった業務に、業種を問わず、この五つの手順はそのまま使えます。導入の現場で繰り返し見てきたのは、精度の議論より先に「誤りが出たら誰がどう直すか」を決めた組織ほど、定着が速いという事実です。
誤りを許すと決めても品質は落ちません
ここで当然の反論があります。「誤りを許容すると宣言したら、現場の品質意識が緩むのではないか」。実際は逆です。予算とは「気にしなくてよい」という免罪符ではなく、「数えて、超えたら止める」という規律です。誤りを予算として数える組織では、誤りが表に出ます。一方、建前としてゼロを掲げる組織では、誤りは報告されずに隠れます。どちらの品質が管理されているかは明らかでしょう。
グーグルの仕組みでも、予算の超過には新規変更の停止という強い歯止めが付いています。許容と放任は別物です。むしろ許容量を明文化した瞬間から、誤りは「あってはならないもの」から「管理すべき対象」に変わります。
まず三十分でここまで進められます
最初の十分で、経営者か担当役員が、AI導入候補の業務を一つ選び、三つの問いに口頭で答えてください。次の十分で、その業務の責任者と一緒に、許容水準を一文に書き下ろします。最後の十分で、検知の方法と「超えたら止める」条件を決め、その一枚を導入検討資料の先頭に置いてください。
ベンダーへの質問も変わります。「精度は何%ですか」ではなく、「誤りはどう検知でき、どう直せますか」と問うてください。前者への答えはどこまで行っても導入の根拠になりませんが、後者への答えはそのまま予算の設計図になります。
次の導入会議で「100%になったら」という言葉が出たら、こう問い直してください。「では、この業務では何件までなら許せますか」。その一言が、待ち続ける組織と、使いながら学ぶ組織の分かれ道になります。誤りの予算を先に決めてください。導入の可否は、そのあとに自然と決まります。
（本文のエラーバジェットに関する記述は、Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy 編『Site Reliability Engineering: How Google Runs Production Systems』（O'Reilly Media、2016年）に基づきます。グーグルの運用部門を築いたBenjamin Treynor Slossらは、100%を信頼性目標とすることはほぼすべての場合に誤りだと指摘し、許容する障害の量を「エラーバジェット」として先に定義することで、変更の速度と信頼性を数字の上で両立させる運用手法を示しました。）