生成AIに何でも判断させていい？AIと業務ロジックを使い分けるシステム設計

いつも当社のブログを読んでいただいてありがとうございます。 florbital小林です。

生成AIを業務システムに組み込むことが、かなり現実的になってきました。

文章を読ませて分類する。
問い合わせ内容から優先度を判断する。
申請内容を確認する。
大量のデータから必要な情報を抽出する。

今まで人間が見て判断していたことも、AIならかなりできるようになっています。

そうなると、「だったら、もう全部AIに判断させればいいんじゃない？」と思いますよね。

私も最初は、これからはそういう方向に進むのかなと思っていました。

でも最近、実際にAIを使った業務システムを考えていると、少し違うのではないかと思うようになりました。

結論から言うと、AIに任せるべき仕事と、従来のプログラムでロジック化した方がいい仕事は違います。

さらに面白いのが、AIが進化したことで、今まで人間では考えきれなかった複雑な業務ロジックそのものを、AIと一緒に作れるようになってきたということです。

つまり今後は、「どれだけAIを使うか」だけではなく、「どこはAIを使わず、プログラムに戻すか」まで考えることが重要になるのではないでしょうか。

今回は、AIと業務ロジックの使い分けについて、最近考えていることを書いてみたいと思います。

生成AIに何でも判断させればいいのか？

例えば、お客様から届いたメールを自動的に分類するとします。

分類したい内容は、

• 通常の問い合わせ
• クレーム
• 営業
• 緊急対応

などです。

これを従来のプログラムだけで作ろうとすると、結構大変ですよね。

「至急」と書いてあったら緊急。

「困っています」と書いてあったらクレーム。

そんな単純な話ではありません。

「至急ではありません」と書いてある場合もありますし、文章全体を読まなければ意味が分からないこともあります。

言葉だけではなく、その前後の文脈も含めて判断する必要があります。

ここはまさにAIが得意な部分です。

メール本文をAIに渡して、「この問い合わせが、通常問い合わせ・クレーム・営業・緊急対応のどれに該当するか判断してください」とお願いすれば、かなりの精度で分類できます。

これまで人間が読んで判断していた仕事を、AIに任せられるわけです。

これは本当にすごいことだと思います。

でも、本当に毎回AIに聞く必要があるのか？

ここで最近思うのが、「これ、毎回AIに判断させ続ける必要があるのかな？」ということです。

例えば1万件の問い合わせをAIに分類させたとします。

その結果を分析してみると、

• 「至急」「早急」という言葉が含まれている
• 同じ顧客から一定期間に複数回問い合わせがある
• 一定日数以上回答されていない
• 特定の商品や契約に関する問い合わせである
• 特定のステータスになっている

といった条件の組み合わせで、かなりの割合を判定できることが分かったとします。

だったら、その部分はもうプログラムでいいんじゃない？と思うわけです。

毎回AIに、「これは緊急ですか？」と聞かなくても、条件が決まってしまえば、

text 問い合わせ回数が3回以上 かつ 最終回答から3日以上経過 → 緊急対応

のような処理にできます。

こうなればAIは必要ありません。

AIに任せるべき処理と、ロジックにすべき処理は何が違う？

分かりやすく整理すると、私は今のところこんな風に考えています。

もちろん、これは絶対ではありません。

業務によって違いますし、今後AIの性能が上がれば境界も変わると思います。

ただ、答えが決まっているものを毎回AIに考えさせる必要はないという考え方は、かなり重要だと思っています。

ロジックなら、人間の確認を外せる

もう一つ、業務システムでは大きな違いがあります。

それが、結果を人間が確認する必要があるかどうかです。

AIは非常に優秀になりました。

ただし、基本的には毎回推論しています。

そのため同じような入力でも、結果が少し変わる可能性があります。

これはAIが悪いということではなく、生成AIとはそういう仕組みです。

一方、「10万円以上なら部長承認」というプログラムならどうでしょう。

10万円以上なら、何回実行しても部長承認です。

そこに判断の揺らぎはありません。

もちろん最初に、

• 条件そのものが正しいか
• 入力データが正しいか
• 例外ケースはないか
• テストが十分か

を確認する必要はあります。

でも、一度正しいロジックとして確認できれば、通常処理について毎回人が結果を確認する必要はありません。

これは自動化ではかなり大きいですよね。

AIに判断させても、最後に人間が毎回、「これ合ってるかな？」と確認していたら、完全な自動化にはなりません。

だから、人の確認をなくせる処理なら、ロジック化する価値は大きいと思っています。

AIを使えば使うほどコストも発生する

もう一つ無視できないのが費用です。

AIを使う場合、

• 入力トークン
• 出力トークン
• 推論処理
• API利用料

などが発生します。

1件ならほとんど気にならない金額かもしれません。

100件でも問題ないかもしれません。

でも、1万件、10万件、100万件となれば当然違ってきます。

一方、

text if A and B: C

で終わるような処理なら、普通のプログラムの実行コストは非常に小さいです。

しかも速い。

毎回結果も同じです。

そう考えると、AIで実現できるからAIを使うという考え方ではなく、本当にAIを使う必要がある処理なのかを見ることが大切になります。

実はAIによって、業務ロジックを作ること自体が簡単になった

そして、ここが最近一番面白いと思っているところです。

今までは複雑な業務をロジック化する場合、人間が条件を全部考えなければなりませんでした。

これが結構大変でした。

条件が10個。

例外が20個。

さらに、「この場合だけ違います」なんて話が出てくる。

そうなると、「もう人が判断した方が早くない？」となってしまいます。

でも今はAIがあります。

例えば大量の過去データと判断結果をAIに見せて、「この判断結果になる共通条件を探してください」とお願いできます。

さらに、

「その条件をプログラムの条件式にしてください」

「TypeScriptで書いてください」

「例外条件を整理してください」

「テストケースも作ってください」

といったこともできます。

つまりAIは、業務を判断するためだけに使うものではなく、業務ロジックを作るためにも使えるということです。

これは結構大きな変化だと思います。

以前、Claude Coworkを使ってタイムカードのPDFからExcelの勤怠データを作る実験をしました。

そのときにも、「判断はAI、計算はExcelマクロ」という役割分担をしました。

例えばタイムカードを見て、

「この時刻が出勤時間だな」

「これは有給だな」

と判断するのはAIが得意です。

一方、8時間30分から休憩1時間を引いて、労働時間は7時間30分。

これは普通の計算です。

わざわざAIに毎回考えてもらう必要はありません。

プログラムなら確実に計算できます。

当時は、AIが得意な判断と、プログラムが得意な計算を分けるという感覚でした。

でも最近は、もう一段進んで、AIが判断していたものの中から、プログラムに戻せるものを探すという考え方も必要なのではないかと思っています。

AIが進化すると、逆にAIを使わない部分も増える？

普通、AIが進化すると、「これからどんどんAIが仕事をするようになる」と考えますよね。

もちろん、それは間違っていないと思います。

AIに任せる業務は、今後確実に増えるでしょう。

でも一方で、AIが進化すると、AIを使わなくてもよい部分も増えるのではないかと思っています。

ちょっと変な話ですよね。

でも、AIによって、

• 業務を分析する
• 過去データを見る
• 共通する条件を探す
• 条件式を考える
• プログラムを書く
• テストケースを作る

ところまでできるようになっています。

今まで人間が、「条件が複雑すぎるからプログラムにできない」と思っていたものでも、AIと一緒ならロジック化できる可能性があります。

つまり、AIがプログラムをなくすのではなく、AIによってプログラム化できる範囲が広がるとも考えられるわけです。

私はここがとても面白いと思っています。

AIとロジックの境界は、一度決めて終わりではない

では、「AIとプログラムをどう使い分ければ正解なの？」という話になります。

これは正直、完全な正解はないと思います。

AIの性能も変わります。

AIの料金も変わります。

プログラムを開発するコストも、AIによってどんどん下がっています。

だから、今の正解が、1年後も正解とは限りません。

例えば最初は、

text AIに判断させる

でもいいと思います。

そして運用しながら判断結果を蓄積する。

ある程度データが溜まったら分析する。

すると、「この80％は明確な条件で処理できるね」と分かるかもしれません。

そうなったら、

text 80％ → プログラム 20％ → AI

に変更する。

さらにAIが進化して安くなったら、「この複雑なロジックを保守するよりAIの方が安いよね」となって、またAIに戻すこともあるかもしれません。

だから私は、AIと業務ロジックの境界も、継続的に見直す必要があると思っています。

ソフトウェアでは、コードを整理して改善することを「リファクタリング」と呼びます。

それと同じように、AIとロジックの境界もリファクタリングしていくという考え方が、これから必要になるのかもしれません。

これからは「AIを使うこと」よりシステム全体の設計が重要になる

少し前までは、「生成AIを使っています」というだけでも、新しい取り組みでした。

でも、もうそこではないですよね。

これから重要になるのは、

何をAIに判断させるのか。

何をプログラムに任せるのか。

どこだけ人間が確認するのか。

この3つをきちんと設計することだと思います。

例えば、

決まった条件 → プログラム

曖昧な判断 → AI

重大な例外 → 人間

といった形です。

そして運用していく中で、AIに判断させていた処理から規則性が見つかれば、プログラムへ移す。

逆に例外が増えすぎたロジックは、AIへ戻す。

この繰り返しです。

何でもAIに投げれば、最初のシステムは簡単に作れるかもしれません。

でも、

本当にその処理にAIが必要なのか。

毎回トークンを使う必要があるのか。

人が結果を確認する必要があるのか。

プログラムならもっと安く、速く、確実に処理できないのか。

そこまで考えて初めて、本当に効率の良いAI活用になるのだと思います。

余談ですが、ローカルLLMという選択肢もある

ここまで、「AIに任せるのか、それともプログラムにするのか」という話を書いてきましたが、もう一つ選択肢があります。

それが、ローカルLLMを使うという方法です。

最近の小型モデルはかなり性能が上がってきているので、業務によっては巨大なクラウドAIを毎回呼び出さなくても、十分なケースが出てくると思います。

例えば、

• 社内文書の分類
• 定型的な文章の要約
• データのタグ付け
• 比較的単純な問い合わせ分類
• 決められた形式への変換

などです。

こういった処理であれば、「最新の巨大モデルを使わなければできないのか？」は一度考えてもいいと思います。

ローカルLLMで処理できれば、外部APIへデータを送信せずに済むため、機密情報を扱うシステムではメリットがあります。

また、処理件数が非常に多い場合には、APIを呼び出すたびに費用が発生するクラウド型のAIよりも、運用方法によってはコストを抑えられる可能性もあります。

もちろん、ローカルLLMなら無料というわけではありません。

モデルを動かすサーバーやGPUが必要になりますし、

• インフラ費用
• モデルの管理
• セキュリティ
• バージョンアップ
• 障害対応

なども自分たちで考えなければなりません。

そのため、必ずローカルLLMの方が安いという話ではありません。

ただ、プログラムか、クラウドAIかという二択だけではなく、

プログラム、クラウドAI、ローカルLLM、人間

まで含めて考えると、システム設計の選択肢はさらに広がります。

これも結局、この記事で書いてきた話と同じです。

大事なのは、AIを使うこと自体ではなく、その処理に一番合った方法を選ぶこと。なのだと思います。

まとめ

AIの進化によって、人間にしかできなかった判断をシステムに組み込めるようになりました。

これは大きな変化です。

ただ、何でもAIに判断させればいいわけではありません。

明確な条件にできるものはプログラム。

文章や文脈など、曖昧なものはAI。

大量処理や機密性などの条件によってはローカルLLM。

そして本当に重要な例外だけ人間が見る。

さらにAIを使って、

今まで作れなかった業務ロジックそのものを作る。

これがこれからの業務システムでは重要になってくるのではないでしょうか。

AIが進化すればするほど、「何をAIにやらせるか」だけではなく、「何をAIにやらせないか」も重要になる。

最近、AIを使った業務システムを考えていて、そんなことを強く感じています。

FAQ

Q. 生成AIとルールベースはどう使い分ければいいですか？
条件が明確で毎回同じ結果が必要な処理はルールベース、文章や文脈など曖昧な情報から判断する処理は生成AIが向いています。

Q. 生成AIによる業務判断は完全自動化できますか？
処理内容によります。結果の誤りが大きな影響を与える場合は、人間による確認やルールベースによる検証を組み合わせる設計が必要です。

Q. ローカルLLMは業務システムで使えますか？
文書分類、タグ付け、定型的な要約などでは選択肢になります。ただしGPUやサーバー、モデル管理などの運用コストも含めて比較する必要があります。

Q. AIで判断していた処理を後からプログラムに変更できますか？
できます。AIの判断結果を蓄積・分析し、共通条件が見つかった処理をルール化する方法が考えられます。