AIとルールベースの使い分け

AI機能を検討する場面で、「この処理もAIでできますか」という質問をよくいただきます。多くの場合できますが、できることと、そうすべきことは別です。条件がはっきりしている処理をAIに任せると、費用が余計にかかり、結果が毎回わずかに揺れ、失敗の原因も追いにくくなります。従来どおりのプログラムで書けば、速くて安くて確実です。本記事では、ひとつの業務のなかで、どの工程をAIに任せ、どの工程をルールで書くかを振り分ける手順を整理します。

それぞれの得意・不得意

先に前提を揃えます。ここで言うルールベースとは、条件分岐や計算式など、人が書いた手順どおりに動く従来のプログラムのことです。

表の最後の行が、AIを選ぶ実務上の利点です。条件が頻繁に変わる、または列挙しきれない処理では、ルールで書くと修正が終わらなくなります。逆に条件が安定していて列挙できるなら、ルールのほうがあらゆる面で優れます。

「想定外の入力」の行にも注意してください。ルールベースは想定外の入力で止まるため異常に気づけますが、AIは何らかの出力を返すため、誤りに気づかないまま業務が進むことがあります。

手順1: 業務を工程に分解する

振り分けは、業務全体ではなく工程ごとに行います。まず、対象の業務を工程に分けて書き出してください。

分解の粒度は、「一つの工程で一つのことをする」程度が目安です。たとえば「問い合わせに回答する」は粗すぎるので、受信、分類、過去事例の検索、回答の下書き、社内確認、送信、記録、というところまで分けます。この段階ではまだAIを使うかどうかを考えず、現在どう処理されているか、誰がやっているか、月にどのくらいの件数があるかを書き添えておきます。

手順2: 条件が文章で書けるか判定する

各工程について、「どうなったらどうする」を文章で書けるかを確かめます。書けるなら、ルールベースの候補です。金額が一定を超えたら承認に回す、特定の記載があれば別の担当に振る、日付が過ぎていれば無効にする、といったものが該当します。条件を書き出す作業は手間ですが、一度書けば結果は毎回同じになります。

書けない例は、文章の意味を理解して要点を取り出す、問い合わせの内容から利用者の意図を推測する、書き方が統一されていない文書から情報を拾う、といったものです。条件を列挙しようとすると例外が無限に出てくる場合、AIの候補になります。

判断に迷うのは「書けるが条件が多すぎる」工程です。数十の条件で済むならルール、今後も増え続けるならAI、というのが実務的な線引きです。

手順3: 誤ったときに気づけるかを判定する

AIの候補になった工程について、出力が誤っていた場合に気づけるかを確かめます。

気づける工程なら、AIに任せてよい可能性が高くなります。人が目を通す前提の下書き、候補の提示、分類の提案などがこれに当たります。誤っていても次の工程で人が直せます。

気づけない工程は慎重に扱ってください。処理された結果がそのまま外部に出る、金銭が動く、記録が更新されて後から戻せない、といった工程です。これらはAIを使うとしても、出力をルールで検証する仕組みを組み合わせる必要があります。

この判定は業務の責任を持つ人が行うべきものです。開発側には、誤りが業務に与える影響の大きさが分かりません。

手順4: AIの出力をルールで受け止める

AIに任せる工程を決めたら、その出力を次の工程にそのまま流さず、ルールで検証する層を挟みます。これが実務上、最も効果のある設計です。

• 出力の形式が想定どおりか（項目が揃っているか、型が正しいか）
• 値が取りうる範囲に収まっているか（存在しない分類名、異常な金額を返していないか）
• 元の入力に存在しない情報を含んでいないか
• 必須の条件を満たしているか

検証に通らなかった場合の挙動も決めます。回数の上限付きでもう一度依頼する、人の確認に回す、ルールベースの既定値で処理する、といった選択肢があります。この層があると、AIの揺れが業務に漏れ出す範囲を限定できます。AIの出力を「そのまま信じる入力」ではなく「検証すべき候補」として扱う設計が基本です。

手順5: 全体の費用と速度を確認する

振り分けが決まったら、全体としての費用と応答速度を確認します。AIに任せた工程が多いほど、1件あたりの費用と処理時間が増え、件数の多い工程ほど影響が大きくなります。月に数件の例外処理にAIを使う費用は誤差ですが、全件が通る工程なら費用は件数に比例して積み上がります。件数の多い工程は、多少条件が複雑でもルールで書いたほうが結果的に安く済むことがあります。

費用が料金モデルに与える影響についてはAI機能と料金モデルの関係で詳しく扱っています。

手順6: 実際の入力で試し、振り分けを見直す

最後に、実際の業務で使われている入力で試します。机上の振り分けは、実データを通すと変わることが多いためです。よくある発見は二つ。AIに任せるつもりだった工程の入力が実は数パターンしかなくルールで十分だった、というもの。そして、ルールで書けるつもりだった工程に、書き出していなかった例外が大量にあった、というものです。

想定例として、請求書の内容を読み取って社内システムに登録する業務を考えます。当初は全工程をAIで処理する構想でしたが、実データを見ると、取引先の多くが決まった書式を使っていることが分かりました。そこで、書式が既知の取引先はルールで読み取り、書式が不定の残りだけをAIに回す構成に変えます。結果として費用は下がり、大半の処理は結果が毎回同じになり、AIの誤りを確認する対象も少数に絞れます。全部をAIにしていたら得られなかった安定性です。

振り分けは一度決めて終わりではありません。運用しながら、AIに回している処理のうち頻度の高いパターンをルールに移していくと、費用と安定性が改善していきます。この移行の計画を最初に立てておいてください。

二択ではなく、工程ごとの振り分け

AIかルールベースかは、どちらが優れているかという問いではありません。条件が文章で書ける工程はルールで書き、書けない工程だけAIに任せ、AIの出力はルールで検証する。この組み合わせが、費用と安定性の両面で現実的です。

弊社は既製のAIサービスをWebシステムに組み込む立場ですが、ご相談の結果「この処理はAIを使わないほうがよい」とお伝えすることは珍しくありません。AI活用開発でも、まずこの振り分けから入ります。振り分けを整理したい方は、お問い合わせからご相談ください。オンラインで状況を伺います。ご相談・お見積りは無料です。