AI導入は待てる。データ整備は待てない。 確率的なAIと、決定論的な業務システムをどう分離するか

AI導入の相談を受けると、たいてい「全部AIに任せられないか」という話から始まります。私の考えは逆で、AIは定型業務の実行経路には極力置かないほうがいい。置く場所は、人が触る対話的なUIと、業務の仕組みを作る開発の場面です。

先に、この記事の主張を一文にしておきます。

AI導入で考えるべきなのは「どの仕事をAIにやらせるか」ではなく、「確率的な処理をどこまで許し、どこから先を決定論的な仕組みに固定するか」である。

そのうえでの結論は次の通りです。

• 確率的な処理を実行時に持ち込まない：計算も、入力の取り込みも、テスト可能で再現可能な仕組みでやる
• AIの不安定さは開発時に一度だけ引き受ける：AIにパーサーやスクリプトを書かせ、レビューしてコードに固定する
• 業務システムへの組み込みは待つ：各社の成功事例は準備工数が隠れており、まだ見極めの段階
• 個人の道具としての配布は今すぐ：全員にアカウントを配り、最低限のルールとセットで試してもらう
• データ整備は今すぐ：AIがどう転んでも必要な投資で、後回しにする理由がない

避けたいのはAIではなく、確率的な挙動の実行時への持ち込み

最初に定義しておきます。私が避けたいのはAIそのものではなく、AIの確率的な挙動を、監査対象となる業務処理の実行時に持ち込むことです。本番で動く処理は、テスト可能で、再現可能で、失敗を検知できるものであるべきだ、という原則です。

まず計算について。アルゴリズムや数式で明確に答えが出るものをAIに計算させると、はっきりしたデメリットがあります。再現性がなく、監査ができず、桁を間違えることもある。原価計算や積算そのものをAIにやらせるべきではありません。ここは多くの人が同意すると思います。

次に入力の取り込みについて。現場からは「散らばったPDFやメール、Excelから数字を拾って表に揃える作業をAIにやらせたい」という要望がよく出ます。AIは非構造データの構造化が得意なので、一見これはAI向きの仕事に見えます。しかし、私はここにもAIを置くべきではないと考えています。理由は二つあります。

一つ目は、ごちゃごちゃは正しくない状態だということです。整理する余地がある業務は整理すべきであって、ごちゃごちゃのままAIに吸収させると、そのごちゃごちゃが仕様になり、業務がロックインします。「ムダを自動化するな」という昔からの原則と同じですが、AIの場合はさらに厄介で、中身がブラックボックスなので、後から「なぜこういう整理になっているのか」を誰も説明できず、剥がせなくなります。

二つ目は、業務の入力を分解すると、AIでしか処理できないものがほとんどないことです。

• 繰り返し来る定型：量が多いので自動化の価値は高いが、形式が固定なので、入力形式・変換ルール・エラー条件を明示できる仕組みに落とせる。内部でOCRや機械学習を使っているかどうかは問題ではなく、出力仕様と検証方法が固定されていることが重要
• たまに来る非定型：量が少ないので人がやればいい。しかも「たまに」ということは検証もテストも積み上がっていないので、AIが一番間違えやすく、一番間違いに気づきにくい領域。AIは危険
• 大量に来る非定型：ここだけがAIの出番になりうる。ただし、その前に「本当に非定型である必要があるか」を疑うべき。フォーム化や標準化で減らせる非定型をAIで吸収するのは、業務改善を先送りしているだけ

それでも残る非定型はあります。取引先からの自由記述メール、契約書、図面、問い合わせなどです。ただ、これらをよく見ると、処理経路で確定させるものではなく、人が判断する材料をAIに出させる、つまり後述する「人が触る層」で扱うものがほとんどです。入口にAIを置きたくなる状況は、AIで解くべき問題ではなく、業務を直すか、扱う層を間違えているかのどちらかです。

不安定さは開発時に一度だけ引き受ける

では、AIの使い道はどこにあるのか。実行時ではなく、開発時です。

取引先の様式を見せてパーサーを書かせる。OCRの後処理ルールを作らせる。テストデータを作らせる。本番で動くのは決定論的なコードで、AIはそれを書く手伝いをするだけ、という形です。

これの何がいいかというと、AIの不安定さを引き受けるタイミングが変わります。AIの不確実性をなくすことはできない。できるのは、不確実性を引き受ける場所を選ぶことだけです。

実行時にAIを置くと、毎回の処理ごとに不安定さが乗り、毎回の出力を誰かが確認しなければならない。開発時に置くと、不安定さは一度きりで、その一度の出力であるコードを人がレビューしてテストを通せば、あとは決定論的に何万回でも同じ結果が返ります。確認のコストが「毎回」から「一回」になります。

しかも確認の対象がコードなので、確認しやすい。AIが出した数字が正しいかは元の伝票と突き合わせないと分かりませんが、AIが書いたパーサーが正しいかは、テストデータを通せば分かるし、差分も追えるし、直したければ人が直せます。相手の様式が変わったら、またAIに書き直させて、またレビューする。不安定さを一度コードに固定して、その固定物だけを管理する。

言い換えると、AIは「答えを出す係」ではなく「答えを出す仕組みを作る手伝いをする係」です。この原則で整理すると、業務の構成は次の5層になります。

「パーサーやスクリプトを書くのはエンジニアの仕事では」と思われるかもしれません。今はそうですが、この前提はすぐに消えると思っています。「この伝票からこの項目を取り出して、この形式で出したい。それを毎回同じように呼べるようにしてほしい」とAIに頼めば、コードを読めない人でも再利用できる道具が作れる。コードを書く能力そのものの重要性は下がっていくと思います。その代わり、「何を入力し、何を出力し、どんなケースで失敗とみなすか」を定義して検証する能力が重要になります。プログラミング能力から、仕様化と検証の能力へ重心が移る、ということです。

つまり前提がゼロになるのではなく、別のものに置き換わります。一つは今述べた検証です。作った道具が正しいかは、テストデータを通して自分の目で確かめる必要があります。これはコードが読めなくてもできるし、むしろ業務を知っている人のほうが向いています。もう一つは置き場所です。各自がAIに道具を作らせ始めると、Excelマクロが各自のPCに乱立したのと同じことが起きます。作った道具は共有の場所に置き、みんなが同じものを呼ぶ形にしないといけません。この点は後述する「中央化されるのはAIではなく、AIが参照するデータとルール」という話に、道具も含まれる、ということです。

「AI導入」には二種類ある

ここから先は「今、何をするか」の話です。その前に、言葉を分けておきます。

「AI導入」という言葉には二つあります。一つは、業務フローそのものにAIを組み込む導入。もう一つは、Excelや検索エンジンのように、社員個人の道具として配る導入です。前者はまだ慎重でよく、後者は今始めてよい、というのが私の考えです。以下、それぞれについて書きます。

個人の道具としてのAIは、中央に置くものか、パーソナルなものか

個人の道具としてのAIがどんな形になるのか、実はまだ答えが出ていません。ERPのように中央に設置してみんなで使うものになるのか、ExcelやPC本体のようにパーソナルな道具になるのか、はっきりしていないからです。

いまのところ、パーソナルな道具になる可能性が高いと見ています。ただ、ここでExcelの歴史を思い出す必要があります。Excelも最初はパーソナルな道具として広がり、各自のシートが乱立してマスタが壊れ、結局DBやERPに戻す動きが起きました。

AIもおそらく同じ経路をたどります。入口はパーソナルで、しばらくすると「みんなが同じ社内規程や単価表を参照したい」「出力を揃えたい」となる。そのとき中央化されるのはAIそのものではなく、AIが参照するデータとルールの部分だと思います。

現状、ERP的な中央集権のやり方で成功しているのが、膨大なナレッジの検索やお問い合わせ対応など、かなり限定的な領域に留まっているのも、それらが「共有データへの参照」だからです。この見立てと整合しています。

「配って自由に使わせる」戦略と、セットにすべき3点

こうした事情から、現時点では、使い方を最初から細かく決めるより、とりあえず広くアカウントを付与して自由に試してもらう、という戦略もよく見られます。実態としては、ほとんどの人は使わないけれど、一部の人がめちゃくちゃ使いこなす、という分布になります。

ただ、配って放置すると3つのことが起きます。

1. 機密データが外に流れる
2. 使いこなしている人のやり方が組織に残らない
3. 使わない人が使わないまま

なので、最低限この3点はセットにしたほうがいいです。

1. 入力してよいデータの線引き：顧客名・単価・図面など、外部サービスに入れてよい範囲を明文化する
2. 月1回程度の事例共有の場：使いこなしている人のプロンプトや手順を見せてもらう
3. 社内データを安全に参照できる仕組みの検討：権限付きの社内検索や、社内文書を参照して回答する仕組み（いわゆるRAG）など

業務システムへの組み込みは「見極めるタイミング」

一方、業務フローへの組み込みについては、いまは各社が試している段階で、積算をAIにやらせたり、伝票発行をAIにやらせたり、いろいろな取り組みがあります。ただ過大広告の部分もあり、「効果が出た」と謳っている裏で、膨大な工数をかけて準備していたりします。全面導入するタイミングではなく、見極めるタイミングだと思います。

とはいえ、これは「やるかやらないか」の様子見ではありません。AIが業務で使われる道具になっていくこと自体は、私は疑っていません。もう少しベストプラクティスが集まってから挑戦するか、あるいは前述のとおり全員にアカウントを配って各自に試してもらうか、そのどちらか（または両方）がいいと思います。

待っていても解決しないのがデータ整備

その上で、待っていても解決しないものが一つあります。データ整備です。

成功事例の裏にある「膨大な準備工数」の中身は、要するにマスタ整備、単価表の一元化、帳票のデジタル化です。言い換えれば、社内のごちゃごちゃをなくす作業です。これはAIがどう転んでも必要な投資なので、ここだけは今から着手して損はありません。

逆に、これをやらないままAIを入れると、ごちゃごちゃごとロックインします。そしてこれが済んでいれば、ベストプラクティスが出た瞬間に乗れる状態になります。

この構造はAI自身が向かっている方向でもある

最後に、この記事の主張が「AIに慎重な人の守りの話」ではないことを書いておきます。

AIが高度になるほど、AI自身もすべてを言語モデルで処理するのではなく、コードを書き、検索し、計算機やAPIを呼び、決定論的な道具に処理を委譲する方向へ進んでいます。つまり「AIに答えを出させる」のではなく「AIに答えを出す仕組みを作らせる」という構造は、AIの進化と逆行するどころか、その延長線上にあります。

そうなったとき、人の役割は処理そのものではなく、AIが固定しきれていない部分、つまりテストが通っていない、前提が曖昧、根拠が説明できない、といった不完全な部分を見つけて整理することに変わります。

だから人間側が今やるべきことも、AIに仕事を渡すことではなく、AIが使える道具・データ・ルールを整えることです。

AI導入は待てる。データ整備は待てない。