業務自動化にAIを使う進め方｜ルール型自動化との違いと「判断が混ざる業務」の任せ方

業務自動化という言葉は新しいものではありません。マクロや RPA といった道具で、伝票の転記や定型のデータ入力を自動にしてきた会社は少なくないはずです。そこに AI が加わって、いま何が変わったのか──検索して出てくるのは華やかな事例やツールの一覧ばかりで、「結局、うちの業務のどこに効くのか」が一番分かりにくいところだと思います。私たちの答えはシンプルです。AI が変えたのは、「判断が混ざる業務」が自動化の射程に入ったこと──これに尽きます。従来の自動化は、手順を完全に決められる作業しか扱えませんでした。文章を読む、内容で振り分ける、下書きを書くといった「少し考える」作業は、人が残業で抱えるしかなかった領域です。AI はここを任せられるようにしました。だからこそ、業務自動化の検討で最初にやるべきことは、ツールの比較ではなく、自社の業務を「手順どおりの部分」と「判断が混ざる部分」に分解することに変わっています。この記事では、ルール型自動化と AI 型自動化の違いから、業務の切り分け方、道具の割り当てと確認の設計まで、業務自動化に AI を組み込む実務の手順を順番に整理します。

業務自動化にAIが加わって何が変わったか ── ルール型自動化との違い

最初に、道具の地図を整理します。業務自動化の道具は、大きく 2 つの系統に分けて考えると見通しがよくなります。1 つはルール型──マクロや RPA のように、人が決めた手順をそのまま正確に繰り返す道具です。もう 1 つはAI 型──生成 AI のように、指示と文脈を読んで、その場その場で出力を作る道具です。この 2 つは「古い・新しい」の関係ではなく、得意な仕事の種類がまったく違います。ルール型は、入力の形が完全に決まっていて、分岐がすべて書き出せる作業なら、疲れず・間違えず・何万回でも同じ品質で実行します。一方で、想定していなかった形の入力が来ると止まるか、誤った処理をそのまま続けます。表記ゆれ、フリーフォーマットの文章、例外だらけの依頼──こうした「きれいに決まらない入力」の前では、ルールを書き切ること自体が現実的でなくなります。

AI 型はこの弱点を逆から埋めます。文章を読んで内容を掴む、雑多な情報を決まった形に整理する、たたき台を書く──ルールに書き切れなかった「判断が混ざる作業」を扱えます。その代わり、出力は毎回同じではなく、もっともらしい誤りが混ざることがある。つまりルール型の弱点と AI 型の弱点は綺麗に食い違っているのです。ここから導かれる実務の結論は、「どちらを選ぶか」ではありません。1 つの業務の中でも、手順で片づく部分はルール型や普通のシステムに、判断が混ざる部分は AI に、責任が乗る部分は人に──と受け持ちを分けて組み合わせるのが、業務自動化に AI を使うときの基本形になります。次の章から、その分け方を具体的に見ていきます。

どの業務がAI自動化に向くか ── 「手順」と「判断」で切り分ける

「この業務は AI で自動化できますか」という問いには、実はそのままでは答えられません。業務というのは 1 つの塊ではなく、小さな作業の列だからです。たとえば「問い合わせ対応」という業務は、受け付ける → 内容を読む → 種類を見分ける → 回答を作る → 送る → 記録する、という作業の連なりでできています。自動化の検討で最初にやるべき分解がこれで、業務を作業の列にほどき、1 つずつ「手順」か「判断」かの札を貼っていく──これだけで、どこに何を割り当てるかはほとんど機械的に決まります。「手順」の札が付いた作業(受け付ける・送る・記録する)は、ルール型や既存システムの領分です。問題は「判断」の札が付いた作業で、ここはさらに 3 種類に分けると精度が上がります。

この 3 分類を通すと、「AI で何ができるか」という漠然とした問いが、「うちの業務のこの作業とこの作業が 01 と 02 に当たる」という具体的な地図に変わります。そして地図ができれば、次はどこから手を付けるかです。

業務自動化にAIを組み込む5つのステップ

ここからは進め方です。冒頭のロードマップのとおり 5 つのステップで進めます。特別な IT の専門知識よりも、自社の業務を言葉にする力が主役になる手順です。

ステップ 1 ── 業務を作業の列に分解する

まず、対象にしたい業務を作業の列にほどきます。やり方は難しくありません。その業務を実際にやっている人に、「最初に何をして、次に何をしますか」と順番に聞いて書き出すだけです。このとき、1 つの作業が「〜を見て、〜を判断して、〜する」のように複数の動きを含んでいたら、さらに割ってください。分解が細かいほど、あとの割り当てが正確になります。書き出したら、前の章の要領で各作業に「手順」「判断(振り分け/読み書き/責任)」の札を貼ります。この 1 枚が、以降のすべての判断の土台になります。経験上、この分解をやること自体に副産物があります──誰も全体を把握していなかった業務の形が、初めて 1 枚の紙になるのです。自動化に進まなかったとしても、この紙には価値が残ります。

ステップ 2 ── 最初の 1 業務を選ぶ

分解の練習を兼ねて複数の業務を眺めたら、最初に自動化する業務を 1 つに絞ります。全部を一度にやらないのは、少人数で試して直すサイクルを速く回すためと、最初の 1 業務の成功が次に広げるときの何よりの説得材料になるためです。選ぶ目安は、①繰り返し発生している ②やり方を言葉で説明できる ③誤りに気づけばやり直せる、の 3 つ。この選び方の詳しい手順──社内業務の棚卸しから最初の 1 業務を決めるまで──は「AIに任せる業務の選び方」で 1 本の記事として書いているので、絞り込みで迷う場合はそちらを参照してください。

ステップ 3 ── 作業ごとに道具を割り当てる

選んだ業務の分解表に沿って、作業ごとに受け持ちを割り当てます。原則は前の章で見たとおりです──「手順」はルール型・既存システムへ、「振り分け」「読み書き」の判断は AI へ、「責任」の判断は人へ。ここで大事な注意が 1 つあります。すべての作業を自動化しようとしないことです。10 の作業のうち 7 つが自動になれば、業務は十分に軽くなります。残り 3 つを無理に自動化しようとすると、設計は複雑になり、確認の負担が増え、かえって回らなくなります。「全自動」ではなく「人の受け持ちが確定の一手だけになる」を目指す──この目標設定が、業務自動化を現実的な計画にします。

ステップ 4 ── AI への手順書と、確認の場所を決める

AI に判断を任せるには、人に仕事を引き継ぐときと同じように、任せ方を文章にする必要があります。何を入力として渡すか、どういう基準で判断するか、迷ったらどうするか、出力はどの形式か──これを書いたものが AI への手順書です。書き方には型があり、「AIに渡す手順書の書き方」で判断基準・禁止事項・出力形式の落とし込み方を詳しく解説しています。あわせて、このステップで人の確認をどこに置くかも決めてしまいます。確認の設計は事故を防ぐ要になるので、次の章で独立して扱います。

ステップ 5 ── 小さく試し、記録で広げる

設計ができたら、数週間を試運転と位置づけて回します。記録するのは 3 つで十分です──①どの作業が任せられたか ②時間がどう変わったか ③うまくいかなかった場面はどこか。広げるかどうかを感覚ではなく記録で判断できる状態を作ることが、この期間の目的です。うまくいかない場面は必ず見つかりますが、その多くは手順書の書き方や確認の置き場所の調整で解消します。1 業務目が安定したら、そこで作った型──分解表・手順書・確認の設計・記録の取り方──をそのまま 2 業務目に持ち込みます。ゼロからやり直さないので、2 つ目以降は目に見えて速くなります。

自動化を「事故」にしない設計 ── 人の確認をどこに残すか

AI 型の自動化を業務に入れるうえで、避けて通れない事実を正面から書いておきます。AI の出力には、もっともらしい誤りが混ざることがあります。これは現在の技術の性質であり、運用の工夫でゼロにはなりません。ただし、これは「業務に使えない」という意味ではありません。人間の作業にもミスが混ざる前提で、私たちはダブルチェックや承認フローを組んできました。AI にも同じ発想で、誤りが混ざっても業務の外に出ない場所に、確認の関所を置くのです。関所の置き方には原則があります。それは、社外への送信・お金の処理・お客様への約束など、「取り返しのつきにくい一線」を越える直前に置くことです。逆に、社内で完結する下書きや整理の段階では、確認を薄くして速度を優先できます。

もう 1 つ、確認の設計でつまずきやすいのが「全部見ていたら自動化の意味がない」という問題です。これには、確認のやり方を変えることで答えます。1 件ずつその場で見るのではなく、まとめて一覧で見る。全文を読み直すのではなく、AI に判断の理由や根拠を出力させておき、そこだけを見る。運用の初期は全件、慣れてきたら抜き取り──と頻度を段階的に下げる。確認は「する・しない」の二択ではなく、置き場所・見る範囲・頻度の 3 つで濃淡を設計するものです。なお、確認が要るのは AI 側だけではありません。ルール型の自動化にも「止まっていたことに誰も気づかなかった」という古典的な事故があります。自動化した作業には、動いていること自体を確かめる仕組み──処理件数の記録や、失敗時の通知──をセットで持たせてください。任せることと、見えなくなることは、別の話です。

事例を自社に引き写すときの注意 ── 派手さより「分解の仕方」を見る

業務自動化を調べると、多くの事例記事に出会います。事例は有用ですが、読み方にコツがあります。成果の派手さや会社の規模ではなく、「その会社は業務をどう分解し、どこを AI に任せ、どこに人を残したか」を読むことです。業務の構造が自社と似ていれば、業種が違っても引き写せます。逆に、構造の説明がなく成果だけが書かれた事例は、自社の計画の参考にはしにくいと考えてください。そして、作業単位の自動化が回り始めた先には、次の段階があります。1 つ 1 つの作業ではなく、一連の業務の流れごと AI に受け持たせる──いわゆる AI エージェントの領域です。この段階の進め方は「AIエージェント導入の進め方」で詳しく書いています。本記事の分解と切り分けは、そのまま次の段階の土台になるので、遠回りにはなりません。

Livune は、「作業を AI に任せる仕組み」を構築している会社です。この記事に書いた進め方──業務の分解、手順と判断の切り分け、手順書と確認の設計──は、教科書からの引き写しではなく、私たち自身が自社の日常業務で毎日実践し、お客様の導入支援で繰り返し使っている手順そのものです。

よくある質問