先日、ある会社の担当者から「見積書の作成、問い合わせ対応、議事録、営業日報のどれから自動化すべきでしょうか」と聞かれました。どれもAIを使えそうに見えます。ただ、技術的に可能かどうかだけで決めると、完成後に使われないことがあります。
最初に見るべきなのは、AIの性能よりも業務の形です。私たちは候補を整理するとき、次の5項目を確認します。
優先順位を決める5つの質問
1. 週に何回発生するか
月に一度の大仕事より、毎日20分かかる作業のほうが改善効果を積み上げやすいことがあります。件数と1件あたりの時間を掛けるだけでも、おおよその削減余地が見えます。
2. 入力と出力を説明できるか
「このメールと顧客情報を読んで、この形式の返信案を作る」のように、材料と成果物が言葉にできる業務は設計しやすいです。一方、「担当者の勘でいい感じに対応する」状態では、先に判断基準を整理する必要があります。
3. 正解を人が確認できるか
初期段階では、AIに任せきるより、人が短時間で確認できる工程が安全です。誤りを見つけにくい業務や、一度の誤りが大きな損失になる業務は最初の対象に向きません。
4. 例外はどれくらいあるか
基本手順が8割、例外が2割なら、基本部分だけを支援する設計ができます。例外処理まで一気に自動化しようとすると、費用も期間も急に膨らみます。
5. 必要なデータは使える状態か
情報が紙、個人のPC、古い基幹システムに分散している場合、AI以前に接続や整理が必要です。ここを見積もらずに始めると「デモは動くが実務では使えない」状態になります。
実際に候補を並べると、優先順位はどう変わるか
仮に、従業員30名の会社で「議事録」「問い合わせ返信」「月次レポート」「見積書作成」の4業務が候補になったとします。議事録は週15回、1回30分。問い合わせ返信は週80件、1件10分。月次レポートは月1回、丸1日。見積書は週10件、1件40分です。
単純な時間だけなら問い合わせ返信が最有力です。しかし、商品の在庫や契約条件によって回答が変わり、誤返信の影響も大きい場合、いきなり送信まで自動化するのは危険です。そこで「関連する過去回答を3件提示し、返信案を作る。送信は担当者が行う」と範囲を区切ります。これなら確認責任を残したまま、検索と下書きの時間を減らせます。
一方、月次レポートは作業時間が長くても月1回です。仕様変更や改善のコストを回収するまで時間がかかります。最初の案件では、年間の削減時間だけでなく、短期間に何度改善サイクルを回せるかも見ます。発生頻度が高い業務は、利用者の反応を早く集められる点でも有利です。
点数より、対話の材料として使う
各項目を5点満点で採点し、「頻度が高い」「手順を説明できる」「人が確認できる」「例外が少ない」「データが揃う」業務から並べます。ただし合計点だけで機械的に決めません。現場の負担感と経営上の意味を並べて、対象を1つに絞ります。
例えば問い合わせ返信は件数が多くても、内容の半分が個別判断なら完全自動化には向きません。それでも、過去回答の検索と返信の下書きまでに限定すれば、短期間で効果を確かめられます。「全部を自動化する」から「どこまでなら安心して任せられるか」へ問いを変えるのがコツです。
費用対効果は「人件費削減」だけで考えない
自動化の効果を、削減時間×人件費だけで計算すると判断を誤ることがあります。例えば営業担当者の提案準備が1時間短くなっても、その1時間がそのまま人件費削減になるわけではありません。代わりに顧客訪問や案件の振り返りへ使えるなら、売上機会や提案品質への効果として捉えるべきです。
私たちは、効果を「時間」「品質」「機会損失」「属人性」の4つに分けます。回答時間が2日から当日になる、記載漏れが減る、担当者不在でも一次対応できる、新人がベテランの過去事例を参照できる。こうした変化は、単純な時間換算には出にくいものの、導入判断には欠かせません。
ざっくりした試算例
週80件の返信作成が1件10分から6分になれば、週320分、月に約21時間の余力が生まれます。月額の運用費だけでなく、初期開発費を何か月で回収したいかを決めると、投資可能額の目安が見えてきます。ただし、確認時間、例外対応、システム維持の時間も差し引いて計算します。
最初から自動化しないほうがよい業務
人事評価、採用の合否、与信、医療・法務判断など、人への影響が大きく説明責任を伴う業務は、効率だけで対象にしません。また、手順が毎週変わる業務、入力データの所在が分からない業務、現場がそもそも困っていない業務も後回しにします。
この場合でもAIを全く使えないわけではありません。意思決定そのものではなく、資料収集、論点整理、記録の抜け漏れ確認など、人の判断を支える範囲に限定できます。どこに人を残すかを決めることも、自動化設計の一部です。
相談前に用意すると話が早いもの
- 対象業務の手順を箇条書きにしたもの
- 1週間の件数と、1件にかかる時間
- 実際に使っている入力資料と成果物の例
- 間違えた場合に起きること
- 利用者と最終確認者
立派な要件定義書は必要ありません。実物を2、3件見られるだけで、実現性と小さく始める範囲をかなり具体的に話せます。
導入後30日で確認すること
公開直後の利用回数だけで成功を判断しません。1週目は操作上のつまずき、2週目は出力の修正理由、3週目は例外ケース、4週目は継続利用と削減時間を確認します。「使われなかった」場合も、精度が悪いのか、入力が面倒なのか、存在を忘れているのかで打ち手は変わります。
利用者には「便利でしたか」ではなく、「どの出力を直したか」「従来の手順に戻ったのはどんなときか」と聞きます。具体的な行動を集めると、次に直すべき箇所が見えます。
最初の成功は「派手さ」より「継続して使われること」
初回の開発で大切なのは、社内向けの大きなデモではなく、翌週も現場が使っていることです。SPACE GLEAMでは、業務の棚卸しから対象範囲の切り分け、短期間の試作、本番運用まで一緒に設計しています。候補が複数あって決めきれない段階でもご相談いただけます。