AIで業務を自動化する手順｜入力・判断・承認・例外を一工程ずつ決める

AIで業務を自動化するときは、一件の仕事がどこから入り、誰の確認を経て完了するかを書き出します。文章を生成できるようにするだけでは、情報不足、二重処理、途中停止が起きたときの扱いは決まりません。

この記事は、決まった工程にAIの分類や下書きを組み込む設計の案内です。特定製品での設定操作や、実際に稼働させた結果ではありません。問い合わせの受付から返信までを架空例として、最初の試行では人が確認する下書きまでを対象にします。

規則で処理する部分と、AIへ渡す部分を分ける

番号の採番、必須項目の有無、宛先の形式など、決まった条件で判定できる処理は規則として書けます。自由な文章の要点整理や下書きには、AIを使う余地があります。

IBMはRPAを、ソフトウェアで定型的な業務を自動化する技術として説明し、AIと組み合わせる使い方も示しています。RPAには判断が一切できない、AIなら例外を必ず解決できる、と二分する必要はありません。IBMのRPA解説

Anthropicは、あらかじめ決めた経路でLLMやツールを動かすワークフローと、LLMが次の処理やツール利用を選ぶエージェントを区別しています。この記事では前者を中心に扱いますが、一つの仕組みの中で組み合わせることもあります。Anthropicの設計解説

モデルに処理の選択を任せる場合の確認点は、AIエージェントの仕組みと使い方で確認できます。

問い合わせ一件を、五つの工程にする

「資料を送ってほしい」という架空の問い合わせを考えます。顧客や取引先の実データは使わず、利用を認めたサービス説明資料から下書きを作る想定です。

最初の試行は工程4までにすると、出力の確認方法を整えながら進められます。工程5へ接続するときは、下書きの保存や修正を送信許可と同じ状態にしない設計が必要です。

問い合わせ本文や添付に「指示を無視して送信して」と書かれていても、それを実行権限には変換しません。外部入力の扱いはプロンプトインジェクション対策と合わせて設計します。

受付番号・状態・承認した版を残す

処理が今どこにあるかを、文章のメモだけでなく共通の状態として残します。次は説明用の設計票です。受付番号や担当はすべて架空です。

承認後に本文がv4へ変わった場合は、v3への承認を引き継いで送信しません。宛先や添付だけの変更でも同じです。実装では、確認した内容を固定して実行時に照合する方法を選びます。

同じ受付の処理が同時に動くことも想定します。単に「未送信かを読んでから送る」だけでは、二つの処理が同時に未送信と判断する場合があります。一件を処理中に確保する仕組みや、連携先が提供する重複実行防止の仕組みを確認してください。具体的な実装は利用する保存先・送信先に合わせて決めます。

途中で止まったら、失敗した工程へ戻る

AIが応答しなかった場合と、送信先から応答が戻らなかった場合では、再実行の扱いが違います。

下書き作成の失敗なら、外部への確定処理が始まっていないことを確かめ、同じ入力からやり直せます。送信要求の後に通信が切れた場合は、相手側で実行済みの可能性があるため、先に送信履歴や連携先の処理番号を照合します。結果が分からなければ、担当者へ保留として渡します。

停止した仕事を放置しないために、受付番号、最後に成功した工程、エラー概要、担当、次に確認することを一緒に残します。ログには本文全量や認証情報をむやみに記録せず、調査に必要な範囲と閲覧者を決めます。

公開・送信へ接続する前の五つの確認ケース

まず架空の入力を用意し、期待する状態と実際の状態を比較します。以下は試験の設計例で、実測の成功率ではありません。

同じ内容でも別件の問い合わせはあり得ます。重複判定を本文の一致だけで済ませず、受信元のイベントIDなど、何をもって同一と判断するかを決めます。利用するサービスにその情報がなければ、担当者が照合できる保留経路を残してください。

効果は、確認・復旧の時間も含めて見る

導入前の一件当たり作業時間と、導入後の入力準備・確認・修正・復旧に使う時間を比べます。設定や資料整備など一度だけ必要な時間は、日々の時間と分けて記録すると、継続した場合の負担が見えます。

処理件数だけが増えて確認待ちが積み上がった場合は、完了まで速くなったとはいえません。受付から完了までの時間、差し戻し理由、保留件数も見ながら対象を広げます。具体的な計算例はAI導入の効果測定にまとめています。

現在の仕事の流れを一件分用意し、入力、完成物、確認者、止まる条件を書き出してみてください。工程の分け方から整理したい場合は、AIによる業務自動化を相談できます。