AI-Ready実装シリーズ
AIにデータを渡すだけでは、業務は変わりません。AIの結果を業務システムに取り込んで、はじめて日々の仕事に活かせます。本記事は、シリーズ全体の考え方の土台にあたります。全体像はシリーズの地図をご覧ください。
生成AIは、社内文書の要約も、請求書の読み取りも、実用になる水準でこなします。それでも、その出力を会計システムや販売管理システムにそのまま登録してよいのでしょうか。うまくいっているからといって、そのまま任せてよいわけではありません。それには、はっきりした理由があります。精度がまだ足りないから、ではありません。AIの出力が間違いを含みうるのに対し、業務システムは受け取った値を訂正せず、正として扱うからです。
目次
生成AIの出力は確率論的です。確率論的とは、同じ入力に対しても、結果が一回ごとに揺れうる性質、つまり再現性の確証がない性質を指します。生成AIは、与えられた入力に対して統計的にもっともらしい続きを選びながら文章を組み立てる仕組みなので、同じ問いでも表現がぶれ、ときには誤った値を、正しい値と見分けのつかない体裁で返します。これは欠陥ではなく、この仕組みが本来持っている性質です。
確率論的であることの帰結は、どれほど精度が上がっても「この出力は間違っているかもしれない」という可能性が仕組みとして消えないことです。その一方で、請求書を読み取る、問い合わせを分類する、文書を要約する、返信文の下書きを作るといった仕事で、生成AIは十分に力を発揮しますし、モデルの精度が上がれば読み違いの頻度も下がっていきます。それでも「間違えることがある前提で、どう受け止めるか」という設計の問題は残り続けます。問題が起きるのは、この間違いうる出力を、誤りが訂正されないまま先へ伝わる場所へ直接渡したときです。
一方、業務システムでの伝票の登録、金額の計算、在庫の引き当ては、ルールで一意に決まり、何度実行しても同じ答えになります。この性質を決定論的と呼びます。ただし、決定論的であることが保証するのは再現性であって、正しさではありません。決定論的な処理は入力を訂正せず、誤った値を受け取れば、同じ誤った結果を正確に繰り返します。業務システムは登録された値を正として後続の処理を動かすので、単価が1桁違えば発注金額が狂い、その金額のまま支払いまで進みます。
もっとも、多くの業務システムは登録時に入力チェックを持っています。しかしそれが弾けるのは、形式の崩れや実在しないコードのような、システム自身の整合性を壊す値までです。形式が整い、実在するコードを持ち、それでいて原本と食い違っている値、つまりAIの読み違いが生む「もっともらしく間違った」値は、このチェックを素通りします。
つまり、間違いうるAIの出力を、訂正の機会がないまま業務システムへ流し込むところに、そもそもの無理があります。これは相性の問題であって、どちらかが劣っているという話ではありません。
この無理を解くには、AIと業務システムのあいだに、決定論的な検証を一枚挟みます。このとき、同じAIにもう一度確認させるわけにはいきません。同じモデルは同じ読み違いを繰り返しやすいため、確認を重ねても正しさの根拠がほとんど増えないからです。有効な確かめ方には二つの種類があります。一つは、正として管理しているデータとの決定論的な照合です。もう一つは、独立した別の手段で読み取った結果どうしを突き合わせる方法で、決定論的な照合だけでは捕まえられない意味の誤りに使います（後述します）。まず一つ目を見ます。
一つ目は、会社が正として管理しているデータ（正データ）との突き合わせです。取引先マスター、商品マスター、契約単価、登録済みの伝票。AIの出力をこれらと照合すれば、形式の崩れや実在しないコードのように業務システムの入力チェックでも弾かれる誤りを、登録の手前で先に検出できます。それだけでなく、契約と食い違う単価、計算の矛盾、重複といった、形式は整っていて入力チェックでは判定できない誤りも、ルールとして書き出せる範囲で機械的に検出できます。
この検証自体は決定論的です。同じ出力には必ず同じ判定を返すので、挙動を事前にテストで確かめられ、なぜ通したか、なぜ弾いたかを説明できます。これは特別なAIの機能ではなく、一般的なシステム処理で実現できます。本シリーズが「確かめてから取り込む」と呼んでいるのは、この検証を指します。
この設計でAIが受け持つのは、読み取った値や分類の結果を候補として出すところまでです。業務システムへ実際に書き込むのは、AIではなく、あらかじめ動作をテストで確かめた、同じ入力なら同じ結果になるフロー処理です。どのデータを読み、検証を通った値をどの処理で書き込むかは、AIがその場で決めるのではなく、フローの設計として先に決めておきます。AIが作り出した値を、確かめないまま書き込むことはしません。同じ伝票を二度登録すれば二重計上になるといった、繰り返しの許されない書き込みもあるため、いつ、何回動かすかも、あらかじめ設計として決めておきます。
決定論的な検証も、万能ではありません。捕まえられるのは「ルールとして書き出せて、照らし合わせれば白黒がつく」誤りに限られます。形式は正しいのに意味が誤っている読み取り結果、たとえば明細の1行の見落としは、単純な照合だけではすり抜けることがあります。
だから、先に触れたもう一つの確かめ方、独立した別の手段で読み取った結果どうしの照合を重ねます。原本の合計値との突き合わせ、人による確認、抜き取りでの点検も、この考え方に基づく層です。別の手段による読み取りは、同じAIによる再確認と違って誤りが重なりにくいため、結果を突き合わせれば正しさの根拠が増えます。どの層も単独では完全ではありませんが、穴の位置が層ごとに違うため、重ねるほどすり抜けは減ります。安全工学では、この発想をスイスチーズモデルと呼びます。実務で目指すのは「間違いゼロの自動化」ではなく、疑わしいデータを自動で通さず、人の確認へ回して止められる設計です。
「間違いうる出力を、決定論的な検証で受ける」という考え方は、何で読み取ったかに左右されません。生成AIのAPIで読んでも、専用のAI-OCR製品で読んでも、読み違いの可能性が残る以上、業務システムに入れる前に確かめる工程は同じように必要です。本シリーズが読み取り技術の優劣を論じないのはこのためです。扱うのは、どの手段で読んだ場合にも共通する、出力を業務システムへ安全に渡すフローの組み方です。
本シリーズは「整える」「確かめてから取り込む」「調べて答える」の順で、具体的な実装を紹介します。その全体を貫くのが、「間違いうるAIの出力と、登録された値を正として動く業務システムのあいだに、検証を挟む」という考え方です。
では、その検証はどこに置くのか。読み取りに使うAIも、登録先の業務システムも、今後入れ替わる可能性があります。検証を特定のAIにも特定の業務システムにも作り込まず、両者のあいだでデータを受け渡す場所に置けば、どちらを入れ替えても検証は残ります。検証を置くその場所で、AIによる読み取りから、正データとの照合、業務システムへの登録までをひとつのフローとして組み立てます。この受け渡しを担うのがデータ連携基盤であり、ASTERIA Warpはその一つです。
次の実装記事では、この考え方を実際のフローに落とします。それまでに、照合の基準にできるデータ（取引先マスター、契約単価、過去の伝票）が自社のどこにあるかを洗い出しておくと、実装記事をそのまま設計の下書きとして読めます。
Q1. 業務システム側にも入力チェックがあります。手前の検証と何が違うのですか。
守る対象とタイミングが違います。登録時の入力チェックは、形式の崩れや実在しないコードのような、システムの整合性を壊す値をエラーとして弾くためのもので、形式が整っていて原本と食い違う値は判定できません。手前の検証は、契約単価やマスターとの突き合わせでこの「もっともらしい間違い」を捕まえ、人の確認へ回します。入力チェックで弾かれる値についても、登録時にエラーで止まるのを待たず、手前で検出できます。なお、明細の見落としのように単純な照合だけではすり抜ける誤りには、原本の合計値との突き合わせなど、複数の確かめ方を重ねて対応します。
Q2. 照合に使うマスターや契約データが整っていない場合はどうすればよいですか。
すべてを揃えてから始める必要はありません。取引先コードの実在確認や合計値の検算のように、いま正として管理できているデータで書ける照合から着手します。照合の失敗が多い箇所は、マスターの整備が手薄な場所を見つける手掛かりになりますが、失敗のたびにマスターを直せばよいわけではありません。マスターの不足なのか、AIの読み違いなのか、原本側の誤りなのか、原因を人が確認したうえで、マスターの追加・修正は通常のデータ管理の手続きに沿って行います。なお、マスター自体の誤りはこの検証では捕まらないため、正データの管理は検証と並行して続ける前提です。
Q3. 確率論的だということは、生成AIは業務に使えないのですか。
使えます。間違いうることと、役に立たないことは別です。読み取りや分類のように候補を出す仕事はAIに任せ、その候補を業務システムへ入れる前に正データで確かめる。この分担にすれば、AIの得意な部分だけを安全に業務へ組み込めます。
PM・SE・マーケティングなど多彩なバックグラウンドを持つ「データ連携」のプロフェッショナルが、専門領域を超えたチームワークで「データ活用」や「業務の自動化・効率化」をテーマにノウハウやWarp活用法などのお役立ち情報を発信していきます。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
