結論：AIに任せる範囲は「誤ったときに何が起きるか」で決める
AI、とくに生成AIを使った業務自動化は、これまでルールで書けなかった作業、たとえば文章を読んで分類する、要点をまとめる、下書きを作るといった作業を対象にできる点が特徴です。一方で、出力が毎回同じとは限らず、もっともらしい誤りを含むことがあります。
このため、進め方の軸は「AIに何ができるか」ではなく、「誤ったときに何が起きるか」に置きます。誤りに人が気づけて、すぐ直せて、外部に影響が出ない業務から始め、人の確認工程を残したまま運用し、記録を見ながら任せる範囲を調整していきます。最初から人を外した完全な自動化を目指すと、誤りの発見が遅れ、信頼を失って取り組み全体が止まることがあります。
AIでの自動化に向く業務、向かない業務
向くかどうかは、業務の種類よりも、次の条件で見分けます。
向きやすい条件は次のとおりです。
- 入力が文章や書類など、形式のそろっていない情報である
- 出力が下書き、候補、分類、要約など、人が見て採否を決められる形である
- 正解が一つに決まらず、一定の品質であれば役に立つ
- 誤りがあっても、後の工程で人が気づける
- 判断の材料となる資料や過去の例が、社内に文書として残っている
向きにくい条件は次のとおりです。
- 金額の計算や在庫の引き当てなど、常に同じ結果が求められる処理。これはAIではなく、通常のプログラムで書くほうが確実です
- 誤りがそのまま顧客への送信、支払い、契約に直結し、取り消しが難しい
- 判断の根拠を後から説明する責任があり、説明できる形で記録を残せない
- 判断に必要な情報が担当者の頭の中にしかなく、AIに渡せる資料がない
- 機密性が高く、外部のAIサービスに送ることが社内の規程で認められていない
実際の業務は、この両方が混ざっています。たとえば、問い合わせ対応を自動化したい場合、問い合わせ内容の分類と回答の下書きはAIに向きますが、返金の可否の判断や顧客への送信は、ルールに基づく処理と人の確認に分けたほうが安全です。業務を一つの塊で見ず、工程に分けてから、工程ごとにAI、通常のプログラム、人のどれが担うかを決めます。
進め方の手順
生成AIを使った業務の自動化は、次の順序で進めると手戻りが少なくなります。
- 対象の業務を工程に分け、各工程の入力、判断、出力、誤ったときの影響を書き出す。
- AIに任せる工程を一つか二つに絞る。最初から全工程を対象にしない。
- 過去の実例から、評価用の入力と、望ましい出力の組を集める。よくある例だけでなく、判断が難しい例、めったにないが誤ると困る例を含める。
- 小さく試作し、評価用の入力で出力を確かめる。業務を知る担当者が良し悪しを判定する。
- 人の確認工程を入れた形で、限られた範囲の実業務に使う。担当者を限定する、対象の種類を限定する、といった絞り方をする。
- 出力、人による修正の内容、誤りの報告を記録し、定期的に見直す。
- 記録をもとに、確認を軽くしてよい工程、逆に確認を厚くすべき工程を判断する。
評価の基準と終了時の判断を先に決める考え方は、PoCの評価設計と共通です。効果を語るには、導入前の状態の記録が必要です。担当者の作業時間や処理の待ち時間など、比べたい項目を先に決めて記録しておきます。
人の確認工程をどう設計するか
「人が確認する」と決めるだけでは、確認は形だけになりがちです。AIの出力が続けて正しいと、確認する人が内容を十分に見ずに承認してしまうおそれがあります。確認工程が機能するように、次の点を設計します。
- 確認する人が、何を見て、何と照らし合わせるのかを決める。出力と一緒に、根拠となる元の資料を並べて表示すると、確認しやすくなります。
- 確認の量が現実的かを見る。一件あたりの確認に手作業と同じ時間がかかるなら、自動化の意味が薄れます。
- 確認の濃淡をつける。影響の大きいもの、出力がルールによる検査に通らなかったもの、新しい種類の入力は必ず人が見る、といった分け方をします。
- 修正の内容を記録する。人がどこを直したかは、指示文や参照資料を改善する材料になります。
- 確認者が判断に迷ったときの相談先を決める。
外部の利用者に向けたサービスにAIを組み込む場合の設計は、生成AIのMVPで失敗時の仕事まで設計する考え方で扱っています。
API連携と、誤ったときの戻し方
AIを業務に組み込むには、既存の業務システムやファイルとの間でデータを受け渡すAPI連携が必要になることがあります。連携の設計では、AIに与える権限の範囲が重要です。
- 読み取りと書き込みを分ける。最初は読み取りと下書きの作成までにとどめ、既存システムへの書き込みは人の操作で行う構成から始めると安全です。
- 書き込みを任せる場合は、対象と件数に上限を設け、想定外の大量処理が起きない作りにする。
- AIが行った操作を、人の操作と区別して記録する。いつ、どの入力に対し、何を出力し、何を実行したかを後から追えるようにする。
- 外部のAIサービスが応答しない、遅い、仕様が変わった場合の動作を決める。止まったときは人の作業に切り替えられるよう、手順を残しておく。
- 個人情報や機密情報を外部に送る場合の取り決めを、事前に確認する。個人情報の設計は入力フォームから削除までをつなげる考え方が参考になります。法的な扱いは個別の判断になるため、専門家に確認してください。
誤ったときの戻し方は、導入の前に決めておきます。誤りが見つかったとき、同じ原因で影響を受けた範囲を記録から特定できるか、その範囲のデータを元に戻せるか、顧客に影響した場合に誰が連絡するかを確認します。戻し方を用意できない工程は、まだAIに任せる段階にないと判断します。機能を一時的に止める手段と、止める権限を持つ人も決めておきます。
よくある質問
Q. ルールで書ける作業も、AIに任せたほうがよいですか。
条件を文章で明確に書ける作業は、通常のプログラムで自動化するほうが、結果が安定し、費用も読みやすくなります。AIは、ルールで書ききれない部分に限って使うのが基本です。両者を組み合わせ、AIの出力をプログラムのルールで検査する構成も有効です。
Q. 社内にAIに詳しい人がいません。何から始めればよいですか。
対象業務を工程に分け、誤ったときの影響を書き出すところまでは、AIの知識がなくても進められます。むしろ業務を知る人にしかできない作業です。その一覧があれば、外部に相談するときも、提案が自社の業務に合っているかを判断しやすくなります。
Q. 確認する人を、いずれ外すことはできますか。
記録から誤りの傾向が把握でき、誤りの影響が小さく、戻し方が用意されている工程については、確認を抜き取りに変えるなど軽くしていく判断はありえます。ただし、モデルや指示文を変えたとき、入力の傾向が変わったときは、確認を一時的に厚くする運用を残してください。
Otsumuに相談できること
Otsumuは、自社サービス運用の自動化コンサルティングと、AIを活用したMVPシステム開発を、ひとつのチームで行っています。戦略と開発を分断せず、構想から運用まで支援します。対象工程を絞って仕組みをつくり、効果を確かめる段階では、PoC / MVP Sprintが対応します。成果物は、検証目的・機能範囲の合意、主要画面と利用シナリオ、検証用PoC / MVPシステム、効果測定の項目・計測設計、公開・運用に向けた引き継ぎ、検証結果と次フェーズの改善方針です。参考価格は300万円〜（税別）、6週間を目安に設計し、300〜800万円程度を検討の目安として、機能数・外部連携・セキュリティ要件で変動します。クラウド利用料等は別途で、正式な見積もりは相談後になります。
工程の洗い出しと小さな試作を社内で進められる場合は、相談は必要ありません。どの工程から始めるか、確認工程や戻し方をどう設計するかで迷う場合は、30分の無料診断で状況を伺います。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21