AI業務自動化入門｜定型業務をAIで自動化する流れの作り方

「この作業、AIで自動化できない？」——現場からそう相談される側に立つと、最初に詰まるのはたいてい同じ場所です。AIが便利なのは分かる。単発で聞けば、要約も下書きも返してくる。けれど、毎週くり返す業務が“勝手に回る”状態は、単発でAIに聞くのとはまるで別物です。そして多くの人が、自動化を「全部AIに丸投げして全自動」とイメージしたまま手が止まります。丸投げでもなく、全部人手でもない。その間に「どこまでをAIに任せ、どこは機械的につなぎ、どこは人が確かめるか」という線を引くこと——これがAI業務自動化の正体です。

本講座は、この「任せる線の引き方」を、定型業務“1つ”に絞って設計できるようになることだけを目指します。生成AIを業務全般にどう活かすかの全体像は生成AI業務活用まるわかりが、目標を渡すと自分で手順を分解して動く自律エージェントへの任せ方はAIエージェント入門が、コードを書かずにツールをつなぐ操作はノーコードツール入門が、それぞれの正本です。改善対象そのものの選び方は業務改善の基本へ。本講座はそれらには踏み込まず、「決まった定型業務を、AIを組み込んだ自動化の流れに落とす設計」に集中します。

この講座を終えると、次の3つができるようになります。自動化に向く定型業務の条件を挙げて向く／向かないを見分けられること、1つの業務を工程に分けて「AIに任せる／自動でつなぐ／人が確認する」に振り分けられること、そして入力・出力・人の確認ポイントを含む自動化の流れを1本設計できること。覚えて帰る型は「向く業務を1つ選ぶ → 工程に分ける → 3種に振り分ける → 流れを1本につなぐ」です。本講座では、毎週手作業でやっている「問い合わせメールの一次仕分けと、定型返信の下書き」という1つの業務を、AIで回る自動化の流れに落とす——という場面を全章で追いかけます。覚えておいてほしいひと言は、ひとつだけ。自動化とは、丸投げではなく“任せる線”を引くことです。

AIで自動化できる定型業務の見分け方

「AIで自動化」は丸投げではなく“勝手に回る流れ”をつくること

まず言葉を整えます。業務の自動化を支える技術には、大きく2つの性格があります。ひとつはRPA（ロボティック・プロセス・オートメーション）に代表される、パソコン上の定型業務をソフトウェアロボットに自動処理させる仕組みです。RPAは作業手順をあらかじめ人間が設定し、その指示どおりに動きます（出典：J-Net21「RPAツールを導入する」）。もうひとつが生成AIで、こちらは機械学習などをもとにAI自身が学習・判断し、文章の要約や分類、下書きの生成といった言葉の処理を担います（出典：J-Net21「RPAツールを導入する」）。判断基準を人が決めて機械的に動かすのがRPA寄りの「自動でつなぐ」処理、言葉の判断や生成をAIに委ねるのが「AIに任せる」処理——この2つを組み合わせて、人の確認を残しつつ業務が回るようにするのが、本講座でいう「AIで自動化する」です。全部をAIに丸投げするのではありません。

ここで一点、最初に線を引いておきます。生成AIは万能ではなく、複雑な意思決定や、学習データに含まれていない情報を使った生成は不得意です（出典：IPA「テキスト生成AIの導入・運用ガイドライン」）。だからこそ「どこを任せ、どこは人が確かめるか」を設計する必要が出てきます。

自動化に向く業務の3条件——頻度が高い・手順が安定・間違えても取り返せる

では、どんな業務が向くのか。手がかりは3つの目で点検することです。1つ目は頻度。RPAは「単純だが作業量が膨大な業務」で効果を得やすいとされます（出典：中小企業白書「先進的なIT利活用」）。たまにしか起きない業務を自動化しても、組む手間に見合いません。2つ目は手順の安定。請求書作成や経費処理、定型的なメール対応のように、入力と手順が決まっている業務はロボットに乗せやすい一方（出典：J-Net21「RPAツールを導入する」）、毎回やり方が変わる業務は乗りません。3つ目は、間違えたときの取り返しやすさです。生成AIは誤った出力を返すことがあるため（この仕組みは第3章で扱います）、誤りの影響が小さく、人が後から直せる業務ほど向きます。

共通例で確かめます。「問い合わせメールの一次仕分けと定型返信の下書き」は、毎週くり返し発生し（頻度）、仕分けの基準が決まっていて（手順の安定）、下書きは送信前に人が最終確認できます（取り返せる）。3条件をすべて満たすので、最初の1つにふさわしい業務です。反対に「重大クレームへの最終回答文を確定して送る」のような業務は、誤りの影響が大きく、AIに任せる線を引きにくい。同じメール対応でも、向く工程と向かない工程があるわけです。

派手だが滅多に起きない業務を選ぶ、というつまずき

ここでのつまずきは2つです。ひとつは、目立つけれど滅多に起きない業務に手を出すこと。インパクトは大きく見えても、頻度が低ければ効果は出ません。もうひとつは「全部AIに任せれば速い」と、丸投げ前提で業務まるごとを対象にしてしまうこと。自動化は特定の業務プロセスを効率化するものなので、どの業務に導入するかを慎重に決め、ボトルネックや効率化の余地を評価して、効果が最大化する業務を選ぶことが重要だとされています（出典：J-Net21「RPAツールを導入する」）。最初の一歩は、広げるのではなく1つに絞ること。なお、自動化による削減効果は事例によって大きく異なり、ある事例では1件あたり平均10分かかっていた抽出作業が自動化されたと報告されています（出典：中小企業白書「先進的なIT利活用」）。これは特定企業の実績であって、あなたの業務にそのまま当てはまる数字ではありません。効果は自分の業務で測るものだと考えてください。

なお、改善する業務そのものをムダ・ムラ・ムリの観点で洗い出す型は業務改善の基本が正本です。本章は「すでに決まった定型業務の中から、自動化に向く1つを選ぶ」ところに絞ります。

この章の確認（演習）

自分の部門でくり返し発生している定型業務を3つ書き出してください。それぞれを「①どのくらいの頻度で起きるか」「②手順や入力はどの程度決まっているか」「③間違えても後から取り返せるか」の3つの目で点検し、3条件を最もよく満たすものを「最初に自動化する1つ」として選びます。最後に、その業務が「これができたら成功」と言えるゴールを1文で書いてみましょう。

業務を工程に分けて「任せる線」を引く

自動化は業務を「工程（ステップ）」に分けて初めて設計できる

向く業務を1つ選んだら、次は中身を分解します。業務をひとかたまりのまま眺めても、どこを任せられるかは見えません。業務プロセスを見直すとき、最初にやるべきは作業工程を「見える化」することだとされています。見える化によって作業工程のムダが浮かび上がり、具体的な手を打てるようになるからです（出典：J-Net21「業務プロセスの見直しによる生産性向上」）。実際、ある企業では現場から管理職までを巻き込んで半年かけて業務を洗い出し、業務フロー図を全社で共有しています（出典：中小企業白書「先進的なIT利活用」）。自動化の設計も同じで、まず工程に分けて並べることから始まります。

共通例を分けてみます。「問い合わせメールの一次仕分けと定型返信の下書き」は、たとえば（例）次の5工程に分解できます。①メールを受信する → ②内容を問い合わせ種別に分類する → ③種別に応じた定型返信の下書きを作る → ④人が下書きを確認する → ⑤返信を送信する。粒度は5〜7工程くらいが扱いやすいでしょう。

各工程を3種に振り分ける——AIに任せる／自動でつなぐ／人が確認する

工程に分けたら、各工程を3つのラベルに振り分けます。この3分類は、本講座が設計をしやすくするために用意した整理の枠で、公的な定義ではありません。土台になっているのは、公的資料が示す3つの事実です。すなわち「①業務は工程に分けて見える化する」「②自動化に乗せる前に業務プロセスを正しく定型化する」（出典：J-Net21「RPAツールを導入する」）「③AIに単独で判断させず、適切なタイミングで人間の判断を介在させる」（出典：総務省・経済産業省のAI事業者ガイドライン）。この3点を実務の手順に落としたものが、次の3ラベルです。

ひとつ目は「AIに任せる」。文章の分類や要約、下書きの生成など、言葉の判断や生成をAI（生成AI）に委ねる工程です。共通例では、②内容の分類と③下書きの作成がこれにあたります。ふたつ目は「自動でつなぐ」。受信する、記録する、決まった宛先へ送るといった、判断を伴わず決まったとおりに動かす機械的な処理で、共通例では①受信と⑤送信が当たります。みっつ目は「人が確認する」。送信前のチェックや例外の判断など、人間の判断を残す工程で、共通例では④がそれです。なお、業務プロセスが属人化していたり非効率なまま自動化に乗せると運用効率が下がるため、3種に振り分ける前に、その業務を誰がやっても同じ手順になるよう定型化しておくことが効きます（出典：J-Net21「RPAツールを導入する」）。

工程を分けず「業務まるごとAIに」と任せ過ぎるつまずき

ここでの典型的なつまずきは2つです。ひとつは、工程に分けずに「この業務、まるごとAIで」と任せ過ぎること。判断を伴わない処理までAIに委ねると不安定になり、AIに任せるべき言葉の判断まで人が抱え込むと自動化が進みません。役割をラベルで分けるからこそ、各工程に合った任せ方ができます。もうひとつは、人の確認をどこにも置かないこと。AIの出力には誤りが混じりうるので（第3章）、「間違うと困る出力」の直後には必ず人の確認を1か所は置きます。共通例なら、③で作った下書きをそのまま⑤送信に流さず、間に④人の確認をはさむ——この一手が、誤った返信が顧客に届くのを防ぎます。任せる線を引くとは、つまり「人の確認をどこに残すか」を決めることでもあります。

工程の一部を、目標を渡せば自分で手順を分解して実行する自律エージェントへ広げる任せ方はAIエージェント入門で扱います。本講座は、人が工程と順序を決め、その各ステップにAIや自動連携をはめ込む側に立ちます。

この章の確認（演習）

第1章で選んだ業務を5〜7の工程に分け、順番に並べてください。次に、各工程に「AIに任せる／自動でつなぐ／人が確認する」のいずれかのラベルを貼ります。そのうえで、「間違うと困る出力」が出る工程を見つけ、その直後に「人が確認する」工程が入っているかを確かめましょう。入っていなければ、人の確認を最低1か所、追加してください。

AIに任せる工程の指示と、誤りへの備え

毎回同じ品質で回すには“定型の指示”を用意する

「AIに任せる」とラベルを貼った工程を、毎回同じ品質で回すには、その都度思いつきで聞くのをやめる必要があります。AIへの質問や指示はプロンプトと呼ばれます（出典：IPA「テキスト生成AIの導入・運用ガイドライン」）。毎回ちがうプロンプトを打てば、出力もばらつきます。そこで、任せる工程ごとに指示を一度きちんと組み立て、固定して使い回します。本講座では、その指示を「役割・入力・出力形式・禁止事項」の4つの要素で組み立てることを勧めます。これは決まりきった公式ではなく、ばらつきを抑えるための実務上の整理ですが、要素をそろえておくと指示が安定します。

共通例の「定型返信の下書き作成」工程なら、（例）こう組みます。役割は「あなたは問い合わせ対応の担当」。入力は「顧客から届いたメール本文」。出力形式は「指定テンプレートに沿った返信案」。禁止事項は「在庫・価格・納期など事実に関わる点は断定せず、必ず“要確認”と印を付ける」。こうして指示を文書として残しておくことには根拠があります。導入にあたっては達成目標を定め、設定の内容とその経緯を文書化して記録しておくと、その後の判断が円滑になるとされ（出典：IPA「テキスト生成AIの導入・運用ガイドライン」）、RPAの導入でも、目的や期待する効果という明確な目標を最初に定めることが重要だとされています（出典：J-Net21「RPAツールを導入する」）。思いつきの一回ではなく、文書化した定型の指示にすること。それが「同じ品質で回る」状態の土台です。

AIは事実でないことを自信ありげに出す——ハルシネーションへの備え

任せる工程には、もうひとつ必ずセットで設計するものがあります。誤りへの備えです。生成AIは、事実に基づかない誤った情報をもっともらしく生成することがあります。これをハルシネーション（幻覚）と呼びます。技術的な対策は検討されているものの完全に抑え込めるものではないため、利用する側は、出力した答えが正しいかどうかを確認することが望ましいとされています（出典：総務省 令和6年版情報通信白書「生成AIが抱える課題」）。IPAのガイドラインも、ハルシネーションを「AIが事実に基づかない情報を生成する現象」と定義したうえで、完全には解消できないと明記し、生成AIは万能ではないので「利用には人間の判断と組み合わせることが重要」「出力内容を単純に鵜呑みにせず、常に批判的に検証した上で利用すべき」だとしています（出典：IPA「テキスト生成AIの導入・運用ガイドライン」）。

つまり、AIに任せる工程を設計するときは、「うまくいく前提」ではなく「誤りが混じる前提」で組みます。具体策はシンプルです。第一に、事実に関わる出力には、先ほどの禁止事項のように“要確認”の印を出させる。第二に、その直後の「人が確認する」工程で、何を見れば誤りに気づけるかを1〜2点に絞っておく。共通例なら、④の人の確認で「“要確認”印の付いた箇所（在庫・価格・納期など）だけを重点的に見る」と決めておけば、確認の負担を増やさずに誤りを止められます。確認ポイントを絞ることが、人の確認を形だけにしないコツです。

出力をうのみにして事実確認の工程を入れ忘れるつまずき

つまずきは2つです。ひとつは、毎回ちがう聞き方をして出力が安定しないこと。これは定型の指示を文書化することで防げます。もうひとつは、出力をうのみにして、事実確認の工程そのものを設計に入れ忘れること。ハルシネーションは「起こりうる」前提なので、確認工程は“あれば安心”ではなく“無いと設計が成立しない”要素です。指示文（プロンプト）そのものの作り込みや、安全な使い方をさらに深めたい場合は生成AI業務活用まるわかりへ。本章は、プロンプトを「流れに組み込む形」に絞って扱いました。なお、特定の生成AIサービス名はあえて挙げていません。サービスは複数あり移り変わるため、製品の比較は送客先に譲り、本講座はどのサービスでも通用する“組み込み方”に集中します。

この章の確認（演習）

第2章で「AIに任せる」とラベルを貼った工程を1つ選び、その工程の指示を「役割・入力・出力形式・禁止事項」の4要素で書き出してください。禁止事項には、事実に関わる出力に“要確認”の印を付けさせる一文を必ず入れます。そのうえで、直後の「人が確認する」工程で重点的に見るポイントを1〜2点に絞り、メモしておきましょう。

工程をつないで自動化の流れを1本に組む

工程を1本の流れ（フロー）につなぐ——入力・受け渡し・確認・出力を明記する

最後の仕上げは、ここまで整えた工程を1本の流れにつなぐことです。流れに書き込むのは4つ。最初の入力（何で始まるか）、各工程の受け渡し（前の工程の出力が次の工程の入力になること）、人の確認ポイント、そして最後の出力（何で終わるか）です。共通例なら、（例）「受信メール（入力）→ 分類 → 下書き生成 → 人の確認（“要確認”印を点検）→ 送信（出力）」という1本の線になります。各工程には、第2章で貼った3種のラベルと、第3章で決めた指示や確認ポイントを書き添えます。これで、1枚のフロー図が「この範囲をAIで回す」という設計図になります。

このとき、複数の処理やシステムを1本につないで自動化することは、特別なことではありません。ある事例では、RPAで複数システムを連携させ、条件に合う相手の抽出から一斉送信までの一連の業務を自動化し、さらに営業支援・顧客管理システムと会計システムの連携にも広げる構想が示されています（出典：中小企業白書「先進的なIT利活用」）。受信から送信までを点ではなく線でつなぐ——この発想が自動化の流れの核です。

“流れの設計図”が描けていることが「自動化できる状態」の核

ここで強調したいのは、ツールでどう実装するかの前に、この「流れの設計図」が描けていることが、自動化できる状態の本体だということです。実際、業務フローの見える化はIT導入の前提とされ、ボトルネックを見極めて効果が最大化する業務を選ぶことが重要だとされています（出典：J-Net21「RPAツールを導入する」）。図にできていれば、それをノーコードや自動連携ツールでどう実装するかは次の段階の話です。実装の具体的な手順やツールの選び方はノーコードツール入門が正本なので、本章では立ち入りません。逆に言えば、図が描けていないままツールに触ると、何を作りたいのかが定まらず手戻りします。設計図が先、実装は後です。

受け渡しが曖昧／例外時に人へ戻る道がないつまずき

つなぐ段階のつまずきは2つです。ひとつは、工程は並んでいるのに受け渡しが曖昧で、流れがつながらないこと。「前の工程の出力が、次の工程の入力としてそのまま使える形になっているか」を、矢印ごとに確かめます。下書きの形式が確認工程で見にくければ、出力形式を直す——受け渡しの不整合は、たいてい第3章の出力形式で吸収できます。もうひとつは、想定外のこと（例外）が起きたときに、人へ戻る道がないことです。これは本講座からの設計上の推奨で、公的資料に「こう作れ」と書かれた手順ではありませんが、AIに単独で判断させず人間の判断を介在させるという原則（第2章・AI事業者ガイドライン）を流れに組み込むなら、自然な備えになります。具体的には、分類できないメールや“要確認”が多すぎる下書きが出たときに、自動で先へ進めず人の判断へ戻す道（エスカレーション）を1本足しておきます。止まったときに放置されず人に戻る——この1本があるかどうかで、流れの安全性が変わります。

この章の確認（演習）

第1〜3章の成果を1枚にまとめてください。工程を矢印で順につなぎ、両端に最初の入力と最後の出力を書きます。各工程には3種のラベルと、第3章で決めた指示・確認ポイントを書き添えます。最後に、想定外のことが起きたときに人へ戻る道（エスカレーション）を1本書き足し、全体を見て「この範囲をAIで回します」と一言で説明できる状態になっているかを確かめましょう。