AI導入する業務はどう選ぶ？優先順位の決め方

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO CREATREE合同会社の代表社員。生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。

著者

藤村 隼人

CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。

AI導入の対象業務は、ツールを先に決めず、業務を棚卸しして「効果」「実現性」「リスク」の3軸で比較します。本記事では、候補業務の分解方法、優先・条件付き・対象外への分類、AIを使わない判断、PoCの範囲と判断条件まで、自社で業務選定を進めるための実務手順を解説します。

なぜ「ツール選定」より先に「業務選定」なのか

AI導入は「AIで何ができるか」ではなく、「どの業務課題を解決すべきか」から始めます。業務の手順、例外、責任分界が曖昧なままツールを導入すると、適用範囲を決められず、現場で利用されない状態になりかねません。

最初に定義するのは、導入するAIの種類ではなく、削減したい作業や改善したい品質です。「業務を効率化する」といった抽象的な表現ではなく、「問い合わせ回答に必要な情報検索の時間を減らす」「報告書の初稿作成を標準化する」など、対象とする課題を業務用語で表します。

そのうえで、AI以外の改善方法も比較します。手順の廃止や統合、テンプレート化、既存システムの設定変更、ルールベース自動化で解決できるなら、AIを採用しない方が運用しやすい場合があります。

1. 経営・部門課題を絞る：売上、処理能力、品質、リードタイム、属人化など、改善したい課題を具体化します。
2. 課題に関係する業務を挙げる：課題が発生している部門、工程、担当者を特定します。
3. AI以外の手段と比較する：業務廃止、手順変更、標準化、システム設定変更、ルールベース自動化で解決できないかを確認します。

ステップ1：候補業務を棚卸しし、タスク単位まで分解する

候補業務は「営業」「経理」「問い合わせ対応」といった大きな業務名ではなく、入力、処理、判断、出力、確認からなるタスク単位まで分解します。タスクを分けることで、AIに任せる範囲と人が担う範囲を切り分けられます。

棚卸しの粒度と分解の順序

最初から全社の全業務を詳細に調べると、棚卸しだけで現場の負担が膨らみます。まず経営課題との関係が強い部門や、改善要望が多い業務領域に範囲を限定し、同じ粒度で比較できる一覧を作ります。

各業務は、次の順序で分解します。

1. 業務の開始条件と終了条件を決める：何を受け取ったら始まり、何を完了したら終わるかを明確にします。
2. 工程をタスクへ分ける：受付、情報収集、入力、照合、作成、承認、送付などに分けます。
3. 各タスクの入出力を記録する：入力データ、処理内容、判断条件、出力物、確認者を整理します。
4. 通常処理と例外処理を分ける：標準手順から外れるケースと、対応する担当者を記録します。

たとえば「問い合わせ対応」であれば、問い合わせの受付、内容分類、顧客情報の検索、回答案の作成、担当者の確認、返信、対応履歴の登録まで分けます。業務全体を一度に自動化するのではなく、回答案の作成や履歴登録など、限定したタスクから評価することが重要です。

現状値として記録する項目

導入効果を判断するには、AI導入前の状態を比較基準として残す必要があります。正確な数値がすぐに取れない場合でも、取得方法と測定期間を決め、候補を絞る前に最低限の現状値を集めます。

記録項目	確認内容	選定での使い方
頻度・件数	日次、週次、月次の実施回数や処理件数	改善効果が継続的に発生するかを見る
所要時間	1件あたりの時間、月間の総工数	削減対象となる作業を特定する

記録項目	確認内容	選定での使い方
担当者・対象人数	実施者、確認者、承認者	影響範囲と運用体制を確認する
品質	誤り、手戻り、差し戻し、回答のばらつき	時間以外の改善効果を評価する

記録項目	確認内容	選定での使い方
例外	標準手順から外れるケースと発生状況	自動処理できる範囲を見極める
入出力データ	システム、表計算、PDF、紙、画像、音声、口頭	データ利用と連携の実現性を判断する

低頻度の業務でも、特定担当者しか処理できず、不在時に業務が止まる場合は候補から外さないでください。削減時間だけでなく、属人化の緩和、品質の安定、引き継ぎのしやすさも効果として検討します。

現場の負担を抑えて棚卸しを進める方法

棚卸しを現場任せにすると、粒度がそろわず、本来業務との両立も難しくなります。推進担当が共通フォーマットを用意し、既存の業務マニュアル、申請書、システムログ、担当表を先に確認してから、現場への質問を絞ります。

ステップ2：効果・実現性・リスクの3軸で候補業務を評価する

候補業務は、効果だけでなく、実装・運用できるか、リスクを管理できるかまで同時に評価します。ここで示す3軸は、CREATREE編集部が業務選定のために統合した実務上の整理であり、一律の配点や合格点を設けるものではありません。

効果軸：削減対象・影響範囲・測定可能性

効果軸では、AIによって何が変わり、その変化をどのように確認するかを評価します。単に「工数が減りそう」と判断せず、削減対象となる工程、利用者、測定指標を明確にします。

• 削減または改善したい作業が特定されているか
• 業務の頻度、処理件数、対象人数を把握できるか
• 処理時間、手戻り、誤り、回答品質などの現状値を取れるか
• 導入後に同じ方法で測定できるか
• 属人化の緩和や対応速度など、時間以外の効果があるか

効果は、直接的か副次的か、定量的か定性的かを分けて記録すると整理しやすくなります。ただし、定性的な効果だけで導入判断を行う場合は、担当者アンケートや品質レビューなど、変化を確認する方法を先に決めておきます。

実現性軸：手順・データ・連携・運用体制

実現性は、モデルやツールの機能だけでは決まりません。業務手順を説明できること、利用可能なデータがあること、既存システムと接続または受け渡しできること、導入後の担当者を置けることが必要です。

• 通常手順と例外処理を文書化できるか
• 必要なデータが存在し、利用目的に合った品質か
• 紙や口頭だけでなく、処理可能な形式でデータを用意できるか
• 既存システムとの連携方法や、代替となる受け渡し方法があるか
• 出力の確認、修正、問い合わせ対応を担う担当者を置けるか
• AIの仕様や業務変更に合わせて改善する責任者が決まっているか

必要なデータが不足している場合は、ツールの性能評価へ進む前に、データの収集・整備を行います。定型業務であっても、利用権限がない、形式が統一されていない、更新されていないといった状態では、実現性を「可」とは判断できません。

リスク軸：誤出力・情報管理・確認手順・代替手段

リスク軸では、AIが誤った場合の影響と、その影響を抑える仕組みを確認します。生成AIを利用する場合は、事実と異なる出力、機密情報の漏えい、不適切または悪意のある入力による想定外の動作なども検討対象です。

• 誤出力が顧客、取引先、契約、法令、安全へ与える影響
• 個人情報、営業秘密、顧客機密などの取り扱い可否
• 入力データと出力結果へのアクセス権限
• 人が確認または承認すべき範囲
• 入力、出力、修正、承認の履歴を残す方法
• AIや外部サービスが停止した場合の代替手順

3軸を1枚の比較表にまとめる

候補タスクを縦軸、評価項目を横軸に置き、各項目を「可・条件付き・不可」で記録します。点数の合計だけで順位を決めず、不可となった理由と、その条件を解消できるかを確認します。

評価軸	主な確認項目	「条件付き」となる例	致命的な「不可」の例
効果	対象作業、頻度、影響範囲、測定指標	現状値を追加測定すれば比較できる	改善対象と成果指標を定義できない
実現性	手順、データ、連携、例外、運用担当	データ整備や担当者の確保が必要	必要データを利用できず、代替もない

評価軸	主な確認項目	「条件付き」となる例	致命的な「不可」の例
リスク	誤出力の影響、機密度、確認、代替手段	人の承認やアクセス制御を追加すれば管理できる	重大な影響を検知・回復できない

1. 候補タスクごとに3軸の評価項目を記入します。
2. 各項目を「可・条件付き・不可」に分け、根拠と確認者を残します。
3. 条件付きと不可について、解消策、担当者、再評価時期を整理します。
4. 3軸すべてに致命的な不可がない候補を、次の分類へ進めます。

判断ポイント：効果が最大の業務ではなく、効果を測定でき、実装と運用が可能で、リスクを許容範囲に抑えられる業務を最初の候補にします。

ステップ3：候補を「優先・条件付き・対象外」に分類する

評価結果は単なる順位ではなく、「優先」「条件付き」「対象外」の3分類に落とします。条件付きの候補に解消条件と再評価時期を設定すれば、現在できない業務と、準備後に検討できる業務を区別できます。

優先：3軸が成立し、小さく始められる業務

優先候補には、効果を測定でき、必要なデータを用意でき、誤りの影響を人の確認などで吸収できる業務を置きます。さらに、業務全体ではなく、限定したタスク、担当者、データで検証できることが必要です。

初回の検証候補を増やしすぎると、担当者と予算が分散します。複数候補が残った場合は、経営課題との関係、検証準備の少なさ、ほかの業務へ展開できる知見の大きさを見て、着手対象を絞ります。

条件付き：準備が整えば着手できる業務

現時点では実施できなくても、データ整備、規程確認、担当者確保、システム連携などによって不可要因を解消できるなら、条件付きに分類します。条件だけを記録して放置せず、責任者と再評価時期を決めます。

• 不足データの収集方法と管理責任者
• 情報管理や契約条件を確認する部門
• 人の確認を追加した場合の業務フロー
• 連携方法と必要なシステム改修
• 条件を満たしたか再評価する時期

対象外：現時点でAIを使わない業務

次のような業務は、効果が見込まれても現時点の対象外とします。対象外の理由を残すことで、担当者が変わった後に同じ検討を繰り返すことを防げます。

• 既存システムの設定変更やルールベース自動化で十分に解決できる
• 例外処理が多く、通常手順を標準化できない
• 必要なデータを適法かつ安全に利用できない
• 誤出力の重大な影響を人の確認でも抑えられない
• 停止時の代替手順を用意できない
• 運用責任者や改善担当者を確保できない

「AIを採用しない」ことも正式な意思決定です。ルールベース自動化を選ぶ場合は、将来再検討する条件として、入力形式の多様化、例外の増加、処理件数の変化などを記録しておきます。

1. 各候補の「条件付き・不可」の理由を一覧化します。
2. その理由が社内準備によって解消可能かを確認します。
3. 解消済み、または致命的な不可がない候補を「優先」にします。
4. 解消可能な候補を「条件付き」にし、担当者と期限を設定します。
5. 解消できない候補やAIが不要な候補を「対象外」にし、理由を残します。

ステップ4：PoCへ進む前に範囲・指標・撤退条件を決める

PoCでは、技術的に動くかだけでなく、業務上の価値と運用可能性まで確認します。開始前に対象範囲、比較する現状値、判断者、判断時期、条件変更や見送りの基準を文書化します。

検証範囲は1つのタスクから切り出す

最初から部門全体や業務全体を対象にすると、失敗した原因を特定しにくくなります。優先候補の中から、1つのタスク、限定した利用者、管理可能なデータ範囲を選び、本番に近い条件で小さく検証します。

たとえば問い合わせ対応なら、受付から返信までをすべて自動化するのではなく、「社内情報を検索して回答案を作る」部分に限定し、担当者が確認してから送信する設計にします。

ベースラインと検証指標を決める

PoC前に、導入後と同じ方法で現状値を測ります。時間削減だけでなく、品質、安全性、利用状況、運用負荷も確認しなければ、本格導入後の業務価値を判断できません。

観点	指標例	確認したいこと
業務効率	処理時間、処理件数、待ち時間	対象工程の負担が実際に減ったか
品質	誤り、手戻り、差し戻し、回答のばらつき	速さと引き換えに品質が低下していないか

観点	指標例	確認したいこと
安全性	不適切出力、権限外アクセス、要確認件数	想定した管理策が機能したか
運用	利用件数、停止件数、人による修正量	現場で継続利用できるか

観点	指標例	確認したいこと
費用	初期費用、利用料、保守・確認工数	導入後の総負担に見合うか

継続・条件変更・見送りの基準を決める

PoCの結果は、成功か失敗かの二択ではありません。目標を満たせば継続し、一部の課題を解消できるなら条件を変更し、重大な問題が残るなら見送ります。

• 継続：必要な効果が確認でき、実運用上のリスクと負担を管理できる
• 条件変更：対象範囲、データ、確認手順、技術構成を変えれば再検証する価値がある
• 見送り：必要な品質を得られない、費用や運用負担が効果に見合わない、重大なリスクを抑えられない

よい結果が出るまで期限なく延長することは避けます。ネガティブな結果も、対象外の判断や次の候補業務を評価する材料として記録します。

外部事業者と進める場合の取り決め

外部事業者とPoCを行う場合は、技術要件だけでなく、データと成果物の取り扱いを開始前に定めます。AIに関するPoC契約の公的なモデルでも、対象データの項目・量・形式、個人情報の取り扱い、役割分担、報告書、次段階へ移る判断などが契約上の論点として整理されています。

• 提供するデータの範囲、形式、品質、提供時期
• 個人情報や機密情報を含む場合の処理方法
• データ不足や遅延が発生した場合の責任分担
• 検証結果、報告書、モデル、ソースコードなど成果物の扱い
• 検証終了後のデータ削除・返却方法
• 本格導入または次段階へ進む判断者と判断時期

1. 優先候補から検証対象タスクを1つ選びます。
2. 導入前の処理時間、品質、件数、運用負荷を測定します。
3. 利用者、データ、機能、確認者を限定して検証します。
4. 事前に決めた指標を同じ条件で比較します。
5. 継続、条件変更、見送りを判断し、理由を記録します。
6. 結果を次の候補業務の評価へ反映します。

業務選定でつまずきやすい論点と、AIを使わない判断

業務選定は、一度決めて終わる作業ではありません。人の確認を残す範囲、AI以外の手段との役割分担、運用開始後の見直し条件まで設計することで、対象業務を安全に広げられます。

人の確認を残す業務の見分け方

誤りが顧客、取引先、契約、法令、安全に影響する業務では、効果が大きくても完全自動化を前提にしません。AIは情報の抽出、分類、下書き、候補提示を担い、最終判断や承認は権限を持つ人が行う設計を検討します。

役割分担	判断の目安	例
自動化を検討しやすい	誤りの影響が限定的で、容易に検知・修正できる	社内用データの形式変換、下書き保存
人が確認する	AIの出力を使えるが、誤りを見逃せない	対外文書の案、問い合わせ回答案

役割分担	判断の目安	例
人が判断する	説明責任、権限、倫理的判断が必要	契約判断、採否、重要な承認

生成AI・ルールベース自動化・既存システム改修の使い分け

技術は業務特性に合わせて選びます。文章、画像、音声など非定型の入力を扱うからといって、必ず生成AIが最適とは限りません。

• 生成AI：文章の要約、分類、下書き、情報検索など、入力や表現にゆらぎがあるタスク
• ルールベース自動化・RPA：条件と手順が固定され、同じ操作を繰り返すタスク
• ワークフロー：担当者、承認、期限、分岐を統制したいプロセス
• 既存システム改修：二重入力や使いにくい画面など、根本原因が現在のシステム設計にある業務
• 業務廃止・標準化：処理自体が不要、または部署ごとの差をなくせば解決する業務

ルールで処理できる定型部分は自動化し、非定型の分類や候補提示にAIを使い、重要な例外は人へ戻すなど、複数の手段を組み合わせることも検討します。

選定結果を運用しながら見直す

AIの出力品質や業務条件は変化する可能性があります。導入後も、品質、利用件数、人による修正、例外、停止状況を定期的に確認し、適用範囲を拡大するか、確認を増やすか、利用を止めるかを判断します。

まとめ

AI導入の業務選定では、課題を起点に業務をタスクへ分解し、「効果」「実現性」「リスク」の3軸で比較します。最初の対象には、効果を測定でき、データと運用体制を用意でき、誤りや情報管理上のリスクを制御できる業務を選びます。

実務では、次の順序で進めてください。

1. 解決する経営・部門課題を定義する
2. 業務をタスク単位で棚卸しし、現状値を記録する
3. AI以外の改善方法も比較する
4. 効果・実現性・リスクで評価する
5. 優先・条件付き・対象外へ分類する
6. 対象範囲、指標、撤退条件を決めて小さく検証する
7. 本格導入、条件変更、見送りを判断する

評価表を作っても、業務の分解、データやシステムの実現性、リスク管理を社内だけで判断できない場合は、外部支援の活用も選択肢です。その際はツール導入だけでなく、対象業務の整理と優先順位付けから相談できるかを確認しましょう。

よくある質問

AI導入の候補業務は、どの粒度で棚卸しすればよいですか？

「入力、処理、判断、出力、確認」を説明でき、AIと人の担当範囲を分けられるタスク単位まで分解します。「営業業務」や「請求業務」のような業務名だけでは、必要なデータや例外処理を評価できません。

効果が大きい一方でリスクも高い業務は、どのように判断しますか？

完全自動化を前提にせず、AIの対象を抽出、分類、下書きなどに限定し、人の確認や承認を残します。それでも重大な誤りを検知・回復できない場合は、条件付きまたは対象外と判断します。

工数や品質の現状値が分からない場合でも業務選定できますか？

候補の仮置きはできますが、優先順位の確定前に現状値を測定してください。まず限定した期間で処理件数、1件あたりの時間、手戻り、例外を記録し、その値をPoCの比較基準にします。

生成AI、RPA、既存システム改修のどれを選ぶべきですか？

文章などの非定型情報を扱うなら生成AI、固定ルールと反復操作ならRPA、問題の原因が既存システムの仕様なら改修を優先して検討します。複数の特性がある業務では、定型処理をRPA、候補提示をAI、承認を人が担う構成も選択肢です。

PoC前に現場・情報システム・経営層で何を合意すべきですか？

対象タスク、利用データ、現状値、検証指標、確認手順、責任者、予算、判断時期、撤退条件を合意します。情報システム部門とは権限や連携、安全管理を確認し、経営層とは業務価値と本格導入の判断条件を共有します。

参考情報・出典

著者プロフィール

この著者の記事一覧へ

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。