本文へ移動する

INSIGHT / 生成AIの設計

生成AIとルールエンジンを、なぜ分けるのか

「業務を生成AIに任せる」と聞くと、書類を渡したら判断まで返ってくる絵を思い浮かべます。実際に業務判断支援AIを作ってみると、そこは分けたほうが素直に動きました。

生成AIは、書式の揃っていない文章を読んで項目に整える仕事に強い。一方で、金額の条件、必須の条件、受けてはいけない条件、承認が必要になる条件のように、毎回まったく同じ答えが出なければならないものもあります。前者と後者を1つのAIにまとめて任せると、答えは返ってくるのに、その答えがどこから来たのかが分からなくなります。

この記事は「生成AIは信用できないから使わない」という話ではありません。逆です。得意なところに集中させるほど、業務AI全体が安定するという設計の話です。

ここで紹介する仕組みは、YURAIの実装として動かし、デモ環境で検証したものです。特定のお客様の本番業務での稼働実績を示すものではありません。この分け方でも解けないことは、記事の後半にまとめてあります。

生成AIに「読む」と「判断する」を同時に任せると、何が起きるか

試しに、1つの生成AIへ書類をそのまま渡し、読み取りから承認の可否まで一度に答えさせてみます。答えは返ってきます。文章としても筋が通っています。それでも、業務のしくみとして使おうとすると2つのことで困ります。

1つめは、同じ書類をもう一度渡したときに、同じ答えが返る保証がないことです。言い回しを少し変えただけで、判断の結論まで変わることがあります。読み取りの揺れなら人が気づけますが、結論の揺れは気づけません。

2つめは、その結論がどの条件から出たのかが、答えの文章の中に溶けていることです。「この内容であれば問題ないと考えられます」と返ってきたとき、どの基準に照らしたのか、どこを見なかったのかは分かりません。あとで「なぜこれを通したのか」と問われても、たどれるものが残っていません。

図1|全部を1つに任せた場合と、役割を分けた場合

1つの生成AIに全部を任せる

生成AI

  • 読む
  • 数える
  • 基準に照らす
  • 可否を決める

「この内容であれば問題ないと考えられます」

答えは返る。ただしどの段で何が決まったのかが、答えの中に溶けている

  • 同じ書類を明日渡して、同じ答えが返るとは限らない
  • どの基準に照らし、どこを見なかったのかが残らない
  • 直したいとき、どこを直せばよいのかが分からない

役割を分ける

生成AIが読む

  • 書かれていることを項目に整える

決まった処理が計算する

  • 数える・照合する・日付を比べる

御社の基準で確かめる

  • 決まりごとに照らして、確認事項を出す

人が決める

  • 根拠を見て、直して、確定する

段ごとに、何をしたかを言える。直す場所も、確かめる場所も1つに決まる

図の右と左で、賢さは変わりません。変わるのは結論の出どころが残るかどうかです。業務で使うしくみとしては、こちらのほうがずっと効きます。

曖昧な文章を扱う仕事は、生成AIが得意

業務で扱う書類は、思っているより書式が揃っていません。全角と半角が混ざり、品名が略され、単位の書き方が取引先ごとに違い、大事な条件が備考欄や余白の注記に書かれています。同じ会社から届く書類でも、担当者が変わると形が変わります。

ここを人の手で吸収しようとすると、決まった位置から文字を切り出す作りになり、書式が1つ増えるたびに作業が増えます。生成AIが本当に効くのはこの部分です。「何が書かれているか」を読み取って項目に整えるところは、これまで自動化しにくかった仕事のうち、いちばん人の時間を使っていた部分でもあります。

だからYURAIでも、読むところは生成AIに任せています。ただし条件を1つ付けています。自由な文章では返させず、あらかじめ決めた項目の形で返させる。形が決まっていれば、後ろの処理がそのまま受け取れます。形が守られていないときは、そこで止めて先へ進めません。読めなかったものを、それらしい値で埋めたまま通さないためです。

この記事でいちばん言いたいこと

生成AIに任せるのは「何が書かれているか」まで。「それを受けてよいか」は、御社の決まりごとの側で確かめる。この線を引くだけで、AIの賢さに頼らずに動くしくみになります。

会社の基準は、毎回同じ答えが出なければならない

読み取った内容を業務として受けてよいかは、書類の中だけを見ても決まりません。いくらから承認が必要か、どの項目が空欄なら差し戻すのか、どの条件は受けてはいけないのか。これらは会社が決めたことで、AIが推し量ることではありません。

会社が決めたことを扱うしくみには、3つの性質が要ります。

  • 同じ入力に同じ答えが出る 同じ書類を明日渡しても、結論が変わらない
  • 答えの理由が言える どの決まりごとに当たったのかを、後から示せる
  • 1か所を直せば変わる 基準が変わったとき、直す場所が1つに決まる

生成AIに基準の判定まで任せると、この3つがどれも弱くなります。逆に、決まりごとを決まりごととして書いておけば、3つはそのまま手に入ります。特別な技術の話ではなく、置き場所を分けるだけの話です。

計算と照合を、生成AIにやらせる必要はない

数える。足す。日付を比べる。マスタと突き合わせる。単位を換算する。こうした処理は、決まった手順で確実にできます。生成AIにやらせても答えは出ますが、確実ではありません。

やりにくいのは、その間違いが自然な文章で返ってくるところです。読み取りの誤字なら人が気づけますが、突き合わせの結果が入れ替わっているとき、答えは文章として何も不自然ではありません。確認の網をすり抜けやすい種類の誤りです。

私たちの実装でも、突き合わせや集計をAIの外へ出しました。マスタとの照合、候補の絞り込み、条件との比較は、同じ入力に対して必ず同じ結果を返す処理として書いています。開発の中で分かったのは、この部分を外へ出すと後ろの設計が一気に楽になることです。確かめる側が確実な事実だけを受け取るようになるので、「たぶん合っている値」を前提にした場合分けが要らなくなります。

分けると、判断の理由を説明できる

役割を分けたことの効き目が、いちばん分かりやすく出るのがここです。「なぜ確認が必要だと出たのか」に、その場で答えられるようになります。

YURAIの実装では、指摘には必ず根拠を添える形にしています。どの決まりごとに当たったのか、書類のどこを見たのかを一緒に返します。そして根拠のない指摘は出しません。指摘に添えられた根拠が確かめられないときは、その指摘をそのまま通さない作りにしています。文章としてもっともらしい指摘が、根拠のないまま業務へ流れることを防ぐためです。

現場に受け入れられるかどうかは、当たった件数よりも説明できるかどうかで決まります。「AIがそう言っています」で人は動けません。「この決まりごとに当たったので、ここを見てください」なら動けます。

基準が変わっても、AI全体を作り直さなくてよい

分けておくことの利点は、作ったあとに出てきます。会社の基準は変わります。承認が必要になる金額が変わる。受けてよい条件が増える。書式のほうも変わります。取引先が新しい様式を使い始める。

図2|承認の条件が変わったとき、直すのはどこか

承認が必要になる条件が変わった

  • 生成AIが読む書かれていることを項目に整える変更なし
  • 決まった処理が計算する数える・照合する・日付を比べる変更なし
  • 御社の基準で確かめる決まりごとに照らして確認事項を出すここだけ直す
  • 人が決める根拠を見て確定する変更なし

基準が変わったとき、読み取りの部分は変えなくてよい。逆に、読み取りの品質を上げたときに基準を書き直さなくてよい。変わるものと変わらないものが、別の場所に置かれているからです。

分けていないと、ここが逆になります。基準を1つ変えるために、読み取りへの指示を書き換えることになり、書き換えた影響が読み取りの結果にも出ます。すると、変えたつもりのない場所まで確かめ直す必要が出てきます。運用が始まってからのこの差は、作っているときに想像するより大きく出ます。

設計の原則

変わる頻度が違うものを、同じ場所に書かない。書式は現場の都合で変わり、基準は会社の判断で変わる。片方を直すために、もう片方を触らなければならない作りにしない。

「分からない」を人へ返す

分けた設計のもう1つの効き目は、安全側に倒しやすくなることです。

読めなかった。候補を1つに絞り込めなかった。根拠を確かめられなかった。業務では必ず起きます。このとき、それらしい値で埋めてしまうと、間違いが「正常な結果」の姿で次の工程へ流れます。受け取った人は、それが確認されていない値だと知る手がかりを持ちません。

だから、分からないものは分からないまま人へ返します。役割を分けておくと、これが素直に書けます。読む段では「読めなかった」と言えばよく、確かめる段では「確かめられなかった」と言えばよい。1つのAIに全部を任せていると、この2つが同じ1つの答えに混ざってしまい、どちらだったのかが分かりません。

止まりすぎるのは、あとから調整できます。間違って通ったものは、戻ってきません。どちらの失敗を選ぶかという問題なので、設計の段階で決めておく必要があります。

YURAIでは、役割をどう分けているか

ここまでの話を、YURAIの役割分担として整理します。YURAIはこの4段で動きます。AIが読み、御社の基準で確かめ、判断材料を出し、人が決める。それぞれが何をして、何をしないのかは次のようになります。

することと、しないこと
01 / READAIが読む 書かれている内容を読み、決めた項目の形に整える。書かれていないことは補わない。可否は決めない
02 / RULE御社の基準で確かめる 計算と照合で事実を確かめ、御社の決まりごとに照らす。同じ入力なら同じ結果を返す。文章の言い回しで結論を変えない
03 / OPTIONS判断材料を出す 確認事項を、根拠と候補を添えて並べる。絞り込めなかったものは絞り込めないまま出す
04 / HUMAN人が決める 材料を見て、内容を直し、業務としての結論を確定する

この分け方は業務ごとに変えていません。受注の書類でも、図面の検図でも、文書の審査でも同じ4段で組んでいます。分け方が業務で変わらないのは、業務の性質ではなくAIに任せられることの性質に沿って分けているからです。

この分け方でも解けないこと

御社の基準が言葉になっていないと、書けません。どの金額から承認が要るか、どの差なら通してよいかが決まっていない状態では、確かめる段に書くものがありません。ここは実装より前の作業です。

読み取りそのものは完全になりません。手書きの注記、かすれた印字、写真として撮られた書類は読めないことがあります。読めなかったことを言える設計にしていますが、読めるようにはなりません。

分けたぶん、決めることが増えます。どこまでを事実として確かめ、どこから人に返すのか。この線引きは会社ごとに違うので、汎用の答えを持ってくることはできません。

ここまでの内容は、YURAIの実装として動かし、デモ環境で検証したものです。特定のお客様の本番業務での稼働実績を示すものではありません。

まとめ:賢いAIより、役割が分かれたAI

生成AIは、業務書類を扱ううえで欠かせない部品になりました。読めなかったものが読めるようになり、揃っていなかった書式が揃うようになりました。それでも、読めることと業務が終わることは別です。

業務のしくみとして必要なのは、結論の出どころが残ること同じ入力に同じ答えが出ること、そして基準が変わったときに直す場所が分かることです。この3つは、AIを賢くすることでは手に入りません。役割を分けることで手に入ります。

だから私たちは、生成AIに読むことを任せ、確かめることは御社の決まりごとに置き、決めることは人に残しています。AIに業務を合わせるのではなく、業務にAIを合わせるための線引きだと考えています。

YURAI Insights の記事一覧へ

NEXT

御社の基準は、どこに置くのがよいか。

何を読ませ、何を決まりごとに書き、どこから人が判断するか。YURAIの考え方と対象業務は、公式サービスガイドにまとめています。

YURAI公式サービスガイドを見る 自社の業務で使えるか相談する