最近、問い合わせ分類や社内向けの業務ツールを作る中で、「ここはAIに任せたい」と言われる場面が増えました。
ただ、実際に中身を見てみると、AIを使わなくても十分な処理もかなりあります。むしろ、条件がはっきりしている業務にAIを入れると、コストも増えますし、結果の揺れに悩むことがあります。
この記事では、業務自動化で「AIを使うべきところ」と「普通のルール処理で足りるところ」をどう見分けるかを整理します。
まずはAIありきで考えない
AI導入の相談では、最初から「どのAIを使うか」に話が寄りがちです。
ただ、業務ツールとして見ると、先に考えるべきなのは「この判断は毎回同じ答えでよいのか」です。
たとえば、金額が10万円以上なら上長承認に回す、ステータスが未入金ならリマインド対象にする、といった処理はAIである必要がありません。条件が決まっていて、毎回同じ結果がほしいからです。
一方で、問い合わせ文を読んで「解約相談っぽい」「不具合報告っぽい」「温度感が高そう」と判断する処理は、ルールだけだとつらくなることがあります。
この違いを最初に分けておくと、設計がかなり楽になると思います。
ルール処理で足りる業務
ルール処理に向いているのは、入力と出力の関係がはっきりしている業務です。
具体的には、次のようなものです。
| 業務 | ルール化しやすい理由 |
|---|---|
| 金額による承認フロー分岐 | 閾値が明確 |
| CSVやExcelの形式変換 | 入出力形式が決まっている |
| ステータス更新 | 条件が固定されている |
| 締切日のリマインド | 日付計算で判断できる |
| API連携時の項目マッピング | 対応表を作れる |
こういう処理は、AIを入れるよりも、普通にif文や設定ファイルで管理した方が安定します。
たとえば、問い合わせ種別がフォームの選択肢として入っているなら、AIで分類する必要はありません。
if (form.category === "billing") {
assignTo = "経理担当";
} else if (form.category === "bug") {
assignTo = "開発担当";
}
このくらいで済む処理にAIを使うと、逆に「なぜその担当になったのか」を説明しづらくなることがあります。
業務では、賢そうに見えることよりも、あとから追えることの方が大事な場面が多いです。
AIが向いている業務
AIが向いているのは、入力が自然文で、判断基準に少し幅がある業務です。
たとえば、問い合わせ本文の分類、長いメモの要約、社内ナレッジから回答案を作る、自由記述のアンケートを整理する、といった処理です。
こういう業務は、人間が読むと何となく判断できます。ただ、それを完全なルールに落とそうとすると、キーワードが増えすぎます。
「キャンセル」という単語があっても、解約希望とは限りません。「キャンセルできますか？」かもしれませんし、「キャンセルされたので困っています」かもしれません。
実際にやってみると、キーワード一致だけで分類する処理は、最初は動いているように見えても、例外対応がどんどん増えることがあります。
その場合は、AIに「文章全体の意味を見て分類してもらう」方が自然です。
判断の目安
自分が切り分けるときは、だいたい次の表で考えています。
| 観点 | ルール処理向き | AI向き |
|---|---|---|
| 入力 | 数値、日付、選択肢、固定項目 | 自由記述、文章、会話ログ |
| 判断基準 | 明文化できる | 人によって少し揺れる |
| 結果 | 毎回同じであるべき | 多少の揺れを許容できる |
| 説明責任 | 強く求められる | 補助判断として使う |
| 変更頻度 | 条件変更が少ない | 表現や内容が日々変わる |
ポイントは、AIを「判断の中心」に置くか、「人間やルールの補助」に置くかです。
個人的には、業務の最初の導入ではAIを補助に置く方が失敗しにくいと感じています。
問い合わせ分類の例
たとえば、問い合わせを「請求」「不具合」「解約」「その他」に分類する場合を考えます。
まず、フォームにカテゴリ選択があるなら、それを優先します。これはルール処理です。
if (input.selectedCategory) {
return input.selectedCategory;
}
選択肢が空だったり、自由記述だけだったりする場合にAIを使います。
次の問い合わせを分類してください。
分類は「請求」「不具合」「解約」「その他」のいずれかです。
確信度も0〜1で返してください。
本文:
「先月から二重に引き落とされているようです。確認できますか？」
この場合、AIには分類と確信度を返してもらいます。
ただし、確信度が低い場合は自動で担当者に割り振らず、人間確認に回します。
if (result.confidence < 0.8) {
return "human_review";
}
return result.category;
ここが地味に重要です。AIを使う場合でも、全部を自動処理にしないだけで運用しやすくなります。
AIに渡してはいけない情報
業務でAIを使うときに一番注意したいのは、渡すデータです。
問い合わせ本文や顧客情報には、氏名、電話番号、メールアドレス、住所、契約情報などが含まれることがあります。AI APIを使う場合、どのサービスに何を送るのかを確認しないまま実装するのは危ないです。
少なくとも、次のような情報は扱いを決めておいた方がよいと思います。
| 情報 | 対応例 |
|---|---|
| 氏名 | マスクしてから送る |
| 電話番号 | 削除または伏せ字にする |
| メールアドレス | ドメインだけ残すなど検討 |
| 契約番号 | 内部IDに置き換える |
| 決済情報 | AIに渡さない |
たとえば、分類だけが目的なら、個人名は不要なことが多いです。
山田太郎です。先月の請求について確認したいです。
これをそのまま渡すのではなく、次のようにしても分類には十分です。
[氏名]です。先月の請求について確認したいです。
AIに渡す前に、目的に不要な情報を削る。これは実装前に決めておきたい部分です。
人間の確認を残す設計
AIを業務に入れるとき、「どこまで自動化するか」はかなり大事です。
全部を自動化しようとすると、1件の誤分類がそのまま顧客対応ミスにつながることがあります。だからこそ、最初は人間の確認を残す設計にした方がよいです。
たとえば、次のような運用です。
| AIの結果 | 処理 |
|---|---|
| 確信度が高い | 自動分類する |
| 確信度が低い | 人間確認に回す |
| 重要顧客っぽい | 必ず人間確認 |
| 解約やクレーム | 担当者に通知して確認 |
この形だと、AIは作業を減らす役割にできます。
一方で、最終責任は人間が持てます。業務ツールでは、このバランスが現実的だと思います。
最小版で試す進め方
最初から全社展開を考えるより、1つの業務で小さく試す方が判断しやすいです。
自分なら、次の順番で進めます。
- 対象業務を1つに絞る
- 入力データと出力結果を整理する
- ルールで処理できる部分を先に作る
- ルールで難しい部分だけAIに渡す
- AIの結果を人間が確認する
- ログを見て、精度と工数削減を判断する
ここで大事なのは、AIの精度だけを見ないことです。
分類精度が高くても、確認画面が使いにくければ現場では使われません。逆に、AIの精度が完璧でなくても、下書きや一次分類として役に立つことがあります。
実際にやってみると、「AIで全部やる」より「ルールで8割、AIで残りの曖昧な部分を見る」くらいがちょうどよい場面が多いです。
失敗しやすい点
よくある失敗は、AIに渡す範囲を広げすぎることです。
「問い合わせ対応をAI化したい」と言っても、その中には分類、担当者割り振り、返信文作成、履歴保存、通知、承認など、いくつもの処理があります。
この全部をAIに任せる必要はありません。
分類はAI、担当者割り振りはルール、返信文はAIの下書き、人間が承認して送信、というように分けられます。
もう1つの失敗は、例外時の動きを決めていないことです。
AI APIが失敗したとき、返答が空だったとき、分類が想定外だったときにどうするか。ここを決めずに作ると、運用中に止まりやすくなります。
最低限、AIが失敗したら人間確認に回す、ログを残す、再実行できるようにする、くらいは入れておきたいです。
まとめ
AIを使うべき業務かどうかは、「AIでできるか」ではなく「ルールで十分か」から考えると整理しやすいです。
数値、日付、選択肢、固定条件で判断できるものは、ルール処理の方が安定します。
一方で、自由記述の分類、要約、意味の読み取り、回答案の作成のように、文章の幅を扱う業務はAIが向いています。
ただ、AIに渡す情報は絞る必要がありますし、人間確認を残す設計も大事です。特に最初は、AIを主役にしすぎず、ルール処理の足りない部分を補うくらいが現実的だと感じています。
同じように、AI機能を入れるべきか、ルール処理で足りるか迷う業務があれば、名古屋業務ツール工房で無料相談できます。今ある入力データと、最終的にほしい出力を整理するところから確認できます。