この記事の要点
- AI自動化とRPAの違いは「ルールを人が書くか、事例から判断を作らせるか」の一点にあります
- 向くかどうかは業務名ではなく、判断基準が言語化できる／誤りが後から検知できる／件数が多い、の3条件で決まります
- 例外処理が業務の大半を占める、誤りが即損害になる、判断根拠の説明義務がある業務は一次候補から外します
- 条件を一部しか満たさない業務も、人が最終確認する半自動化なら成立します
- この記事の5つの質問で、自社業務を「すぐ自動化／半自動化／今は見送り」の3つに仕分けできます
「AIで何か自動化できないか」と考えたとき、最初にぶつかる壁はツール選びではありません。自社のどの業務が対象になるのか分からない、という点です。ネット上には「AIで自動化できる業務100選」のような記事があふれていますが、その一覧を眺めても、自社の請求処理や問い合わせ対応が該当するのかは判断できません。業務名が同じでも、中身の構造が違えば結果はまったく変わるからです。
この記事が渡すのは、できること一覧ではありません。自社業務がAI自動化に向いているかを、その場で判定するための基準です。読み終えたときに、対象業務を1つ選んで仕分けできる状態を目指します。
目次
AI自動化とは？RPAとの違いは「ルールを人が書くか、事例から作らせるか」
AI自動化とは、これまで人の判断が必要だった処理をAIに任せ、業務フローを最後まで通すことです。RPAとの決定的な違いは、RPAが人の書いた手順どおりにしか動かないのに対し、AI自動化は過去の事例やデータから判断のしかたを作らせる点にあります。この違いは用語の話にとどまらず、そのまま「自社に向くか」の判断基準になります。
AI自動化が扱えるのは「判断が入る作業」
AI自動化の対象は、手順は決まっているが毎回同じとは限らず、人が一度読んで判断してから処理する作業です。逆に、判断が一切入らない完全定型作業にAIを使う必要はありません。ボタンを押す順番が決まっているだけの処理なら、従来型の自動化のほうが安く、速く、確実です。
「判断が1回挟まる作業」とは、たとえばこういうものです。問い合わせメールの文面を読んで、営業か技術サポートか経理かに振り分ける。取引先ごとにレイアウトの違う請求書から、金額と支払期日を拾う。申請書の記載内容を見て、不備があるかどうかを見分ける。どれも手順自体は毎回同じですが、入ってくるものが毎回違うため、人が読んで解釈する工程が必要になります。
この「読んで解釈する」部分こそが、これまで自動化を止めていたボトルネックでした。AIが扱えるようになったのは、まさにここです。
RPAとAI自動化の使い分け：判断のルールを書き切れるか
使い分けの軸は一本です。判断のルールを人が漏れなく書き切れるならRPA、書き切れず例外が多いならAI。これだけで大半のケースは判断できます。書き切れるものにAIを使うと、開発費も運用コストも無駄に高くなります。
具体的には、次の3点を確認してください。
| 確認する点 | RPAが適する | AI自動化が適する |
|---|---|---|
| 条件分岐 | 「AならB」を文章で全部列挙できる | 列挙しきれない／例外が次々出る |
| 入力データの形式 | 固定（同じ画面・同じ帳票） | 可変（送り主ごとに形式が違う） |
| 例外が出たときの直し方 | 人がプログラムを改修する | 事例を追加して学習させ直す |
| 初期コストの傾向 | 相対的に低い | データ準備を含むぶん高くなりやすい |
| 精度の考え方 | ルール通りなら100% | 一定割合で必ず誤る前提 |
両者は排他ではありません。実務でよく成立するのは、AIが判断し、その結果を受けてRPAや既存システムが処理を実行する組み合わせです。メールの内容をAIが分類し、分類結果に応じてRPAが基幹システムに登録する、といった形になります。どちらか一方を選ぶ問題として考えると、かえって設計を誤ります。
生成AIの登場で自動化できる範囲はどう広がったか
生成AIによって、文章の要約・分類・下書き作成など、これまで形式が定まらず自動化を諦めていた非定型作業が対象に入りました。以前は「この業務は文章を扱うから無理」で終わっていた領域が、検討のテーブルに乗るようになったのです。
広がったのは、自然言語の入出力と、フォーマットが不定の文書処理です。学習用データを一から大量に集めなくても、ある程度の精度が出せるようになった点も大きい変化でしょう。総務省「情報通信白書」でも、生成AIの利用が企業活動へ広がっている状況が報告されています※1。
一方で、広がっていない範囲もはっきりしています。正確性の保証、責任の所在、そして社内固有の暗黙知。生成AIは自信のある口調で誤った内容を出力しますし、その出力に法的責任を負ってはくれません。「うちの会社ではこの取引先だけ例外扱い」といった、どこにも書かれていないルールも学習できません。期待値を過剰にも過小にも持たない姿勢が、発注の判断では効いてきます。
※1 総務省「情報通信白書」リンク
AI自動化に向く業務の3条件・向かない業務の3条件
AI自動化に向くかどうかは、業務名では決まりません。向く条件は「判断基準が言語化できる」「誤りが後から検知できる」「件数が多い」の3つ。向かない条件は「例外処理が多い」「誤りが即損害になる」「判断根拠の説明が要る」の3つです。同じ「請求書処理」でも、この条件の当てはまり方次第で結論は逆になります。
向く条件①判断基準が言語化できる／②誤りが後から検知できる／③件数が多い
3条件は、それぞれ別の理由で必要になります。順に、なぜその条件が要るのかを見ていきます。
①判断基準が言語化できる。ベテランの頭の中だけにある基準は、AIにも学習データにも落とせません。「なんとなくこの案件は怪しい」という感覚は、それ自体は正しくても、AIに渡す形になっていないのです。判断基準を言語化できるかどうかは、担当者以外の人が読んで同じ判断ができる文章にできるか、で確かめられます。ここができていない状態で発注すると、要件定義の途中で必ず止まります。
②誤りが後から検知できる。AIは一定割合で必ず間違えます。ここは動かせない前提です。だとすれば、間違いが後工程や数値チェックで拾える構造になっているかが決定的に重要になります。抽出した金額が合計と合わない、振り分け先の部署から差し戻しが来る、といった形で誤りが浮かび上がる業務は安全です。逆に、間違えたまま誰も気づかず流れていく業務は、精度がどれだけ高くても運用に乗せられません。
③件数が多い。開発費を回収するには、月あたりの処理件数が効きます。1件あたり5分の作業を9割自動化しても、月30件なら削減できるのは月2時間ちょっと。開発費に見合いません。目安として、月数十件規模では投資回収しにくく、月数百件から数千件のレンジに入ると検討価値が出てきます。ただしこれは1件あたりの作業時間にもよるので、件数×時間の総工数で見てください。
3条件は全部満たすのが理想ですが、必須なのは①と②です。③の件数が足りない場合でも、同じ仕組みを複数の業務や複数拠点に横展開できるなら、合計の処理件数で採算が合うケースはあります。逆に①②のどちらかが欠けていると、件数がいくら多くても運用に乗りません。
向かない条件①例外処理が多い／②誤りが即損害になる／③判断根拠の説明が要る
例外が業務の大半を占める、1件のミスが即座に金銭や信用の損害になる、なぜその判断をしたか対外的に説明する義務がある。この3つのいずれかに当てはまる業務は、AI自動化の一次候補から外してください。無理に進めても、精度検証と例外対応に工数が吸われ、PoCで止まる典型パターンになります。
例外処理が多いとは、感覚的には「イレギュラー対応が処理全体の3割を超える」あたりが目安です。AIは多数派のパターンは学びますが、1件ずつ事情が違う例外は苦手です。結果として、自動化できた7割の裏で、例外3割の対応に人が張り付き続ける構造になります。
誤りが即損害になる業務の代表は、与信判断、出荷指示、価格決定です。誤った与信で貸し倒れが出る、誤った出荷指示で欠品や誤配送が起きる、誤った価格で受注してしまう。どれも後から気づいても取り返せません。
判断根拠の説明が要る業務には、人事評価、与信否決の理由説明、行政や顧客への回答根拠などがあります。「AIがそう判断したので」では説明になりません。AIの利用にあたって透明性や説明可能性への配慮が求められることは、経済産業省・総務省「AI事業者ガイドライン」でも示されています※2。
ただし「向かない＝永久に不可能」ではありません。正確には「全自動が向かない」だけです。人の確認を挟む形なら成立するケースは多く、その設計の話が次になります。
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
グレーゾーンは「人が最終確認する半自動化」で成立させる
条件を一部しか満たさない業務は、AIに下書きや一次判断までさせ、人が承認する形にすれば導入できます。全自動にこだわると成立しない業務が、半自動化なら十分に採算に乗ります。ここを分けて考えられるかが、発注検討の分かれ目です。
全自動と半自動では、コスト・効果・リスクの構造が変わります。
| 全自動 | 人が最終確認する半自動化 | |
|---|---|---|
| 要求精度 | 非常に高い水準が必要 | 人が直せる水準でよい |
| 開発コスト | 精度を詰めるぶん高くなる | 相対的に抑えやすい |
| 誤りのリスク | そのまま外部へ流出する | 確認工程で止まる |
| 削減できる工数 | 作業時間のほぼ全部 | 「ゼロから作る時間－確認・修正する時間」の差分 |
| 導入までの期間 | 長くなりやすい | 短く始めやすい |
実務で使いやすいのが、閾値による振り分けです。AIが出力と同時に「確からしさ」のスコアを返す設計にして、スコアが高い分をそのまま流し、低い分だけを人に回します。全体の8割を自動処理し、残り2割を人が見る、という運用が組めます。
数字のイメージを置きます。1件5分の判断作業が月500件あるとします。総工数は約42時間。うち8割をAIが処理し、残り2割（100件）を人が5分かけて処理、さらにAI処理分400件を1件30秒でざっと確認するとします。人の作業は100件×5分＋400件×0.5分＝約11.7時間。差し引き約30時間の削減です。全自動でなくても、これだけの幅が出ます。
自社業務がAI自動化に向くか判定する5つの質問
次の5つの質問にYes/Noで答えるだけで、対象業務は「すぐ自動化を検討」「人が最終確認する半自動化」「今は見送り」の3つに仕分けできます。質問は前のセクションで挙げた6条件に対応しています。まず対象業務を1つに絞ってから答えてください。複数業務をまとめて考えると、必ず判定がぼやけます。
判定チェックリスト（Yes/Noで答える5問）
5問はそれぞれ、向く条件・向かない条件のどれかに対応しています。対応関係を併記するので、Noが付いた項目がそのまま課題になります。
| # | 質問 | 対応する条件 |
|---|---|---|
| Q1 | その業務の判断基準を、担当者以外が読んで同じ判断ができる文章にできますか | 向く条件①言語化できる |
| Q2 | AIが間違えた場合、後工程や数値チェックで気づけますか | 向く条件②誤りが検知できる／向かない条件②即損害 |
| Q3 | 月に何件処理していますか（100件未満／100〜1000件／1000件以上） | 向く条件③件数 |
| Q4 | 処理のうち例外・イレギュラーは何割ですか（1割未満／1〜3割／3割超） | 向かない条件①例外が多い |
| Q5 | その判断の根拠を社外や第三者に説明する必要がありますか | 向かない条件③説明義務 |
判定の読み方はこうです。
- Q1がNo → まず言語化から。この状態では発注しても要件が固まりません
- Q2がNo → 全自動は不可。確認工程を必ず設ける前提で考えます
- Q3が100件未満 → 単独では投資回収が難しい。横展開の可能性を確認します
- Q4が3割超 → 例外の中身を分解し、多数派になる部分だけを切り出せないか検討します
- Q5がYes → 判断そのものではなく、判断材料の収集・整理を自動化の対象にします
判定結果別の次のアクション（すぐ自動化／半自動化／見送り）
Q1・Q2がYesで、Q3が100件以上、Q4が3割以下、Q5がNoなら「すぐ自動化を検討」。Q2かQ5に引っかかるが他は満たすなら「人が最終確認する半自動化」。Q1がNo、またはQ3が100件未満かつ横展開の見込みもないなら「今は見送り」です。それぞれ次にやることが違います。
すぐ自動化を検討の場合。PoC（試作検証）だけを切り出して発注するのは避けたほうが無難です。試作で「精度が出ました」と確認して終わり、本番運用の設計は別途、という進め方は、PoC止まりの典型パターン。最初から小さく本番運用まで届く範囲で設計し、対象を絞って発注してください。
半自動化の場合。開発の相談より先に、社内で決めることがあります。誰が確認するのか、確認にどれだけ時間をかけられるのか、承認フローはどうするのか。ここが決まっていないと、AIを作っても運用が回りません。確認担当が既存業務で手一杯なら、そもそも導入の前提が崩れます。
見送りの場合。将来の候補に変えるための準備を進めます。判断基準の言語化（ベテランへのヒアリングを文章化する）、業務データの蓄積（過去の処理結果を、入力と出力がひも付いた形で残す）、この2つです。特にデータは、後からさかのぼって作れません。紙やメールで処理していて記録が残っていない業務は、記録の残し方を変えるところが第一歩になります。
判定でよくある3つの間違い
判定でよく起きる間違いは3つ。一番大変な業務から手を付ける、精度100%を前提に設計する、現場の暗黙知を言語化せずに発注する。どれも善意から起きるだけに、社内で止まりにくいのが厄介なところです。
一番大変な業務から手を付ける。効果が大きいから、という理由で最も複雑な業務を選ぶと、例外が多く判断基準も言語化されていない確率が高くなります。結果、要件定義が長引き、精度も出ません。最初に選ぶべきは「効果が中くらいで、条件を明確に満たす業務」です。1件目で運用の型を作れば、2件目以降の判断が速くなります。
精度100%を前提に設計する。これが一番多い失敗です。AIは必ず間違えます。設計の本質は精度を上げることではなく、間違いを吸収する業務フローを作ることにあります。「99%の精度が出たら導入」という決め方をすると、残り1%をどう扱うかの議論が抜け落ち、本番で事故が起きます。
現場の暗黙知を言語化せずに発注する。発注側が「業務のことは説明したつもり」でも、開発側には見えていないルールが必ずあります。この取引先だけ処理が違う、この期間だけ例外運用がある、といった話。これらは開発の後半でテストデータを流したときに初めて発覚し、手戻りになります。発注前に、現場担当者と一緒に例外パターンを洗い出しておいてください。
AI自動化の事例は「業務名」ではなく4つの型で見る
AI自動化の事例は、業種や業務名で覚えても自社に応用できません。「小売業の需要予測」と聞いても、自社の在庫管理に当てはまるかは判断できないからです。処理の型で見ると、分類・振り分け型／抽出・転記型／下書き生成型／チェック・異常検知型の4つにほぼ収まります。自社業務がどの型かを特定すれば、必要な準備も見積もりの見方も決まります。
分類・振り分け型：問い合わせや申請を仕分ける
入力は自由記述のテキストや書類、出力はカテゴリや担当先。4つの型の中で最も導入しやすいのがこの型です。誤りが後工程で気づきやすく（振り分け先から差し戻される）、件数も多くなりやすいため、向く条件の②と③を自然に満たします。
問い合わせメールを部署別に振り分ける、申請書を種類別に仕分ける、社内チケットを緊急度で分ける、といった処理が該当します。いずれも1件あたりの作業時間は数分ですが、件数が積み上がると総工数は無視できません。効果の計算は「1件あたりの仕分け時間×月間件数×自動化率」で単純に見積もれます。
準備として要るのは、過去の振り分け結果です。どんな内容のメールがどの部署に行ったか、という組み合わせが数百件分あれば検討が始められます。ただし件数以上に重要なのが偏りの少なさ。9割が1カテゴリに集中していると、少数カテゴリの判定精度は上がりません。
抽出・転記型：帳票やメールから項目を取り出す
入力はフォーマットが取引先ごとに異なる帳票やメール、出力はシステムに入れる構造化データ。RPAだけでは対応できず、AIが効く典型です。レイアウトが固定ならRPAやOCRのルール設定で済みますが、取引先ごとに項目の位置も呼び方も違う場合、ルールを書き切れません。
この型で外せないのが、数値項目の突合チェックです。抽出した明細金額の合計が、記載された総額と一致するか。日付が発注日より前になっていないか。こうした検算を組み込んでおけば、AIの誤りをその場で検知できます。突合の設計がない抽出システムは、誤りが黙って流れていくため、運用に乗せられません。
逆に言えば、突合の仕組みが作れるかどうかが、この型の適否を分けます。発注前に「抽出結果の正しさを機械的に確かめる方法があるか」を確認してください。
下書き生成型：回答文・報告書・提案書のたたき台を作る
入力は過去事例や社内文書、出力は人が手直しする前提の下書き。この型は全自動ではなく、半自動化が基本です。生成された文章をそのまま外部に出す運用は、内容の誤りが直接リスクになるため避けるべきでしょう。
効果の測り方が他の型と異なります。「ゼロから書く時間」と「下書きを直す時間」の差分が削減効果です。ゼロから60分かかっていた報告書が、下書きの修正なら25分で済むなら、1件あたり35分の削減。ここで注意したいのが、下書きの品質が低いと修正時間が伸び、場合によってはゼロから書くより遅くなる点。効果が出るかどうかは、下書きの水準に強く依存します。
品質のばらつきは前提として受け入れる必要があります。毎回同じ水準の文章が出るわけではありません。だからこそ、確認する人のスキルと時間をあらかじめ確保しておくことが、導入の条件になります。なお、顧客情報や機密文書を社外のAIサービスに入力する場合は、利用規約とデータの取り扱いを事前に確認してください。個人情報を含む場合は、個人情報保護法上の第三者提供や委託の整理も必要になります※3。
チェック・異常検知型：見落としを拾う
入力は処理済みのデータ、出力は「要確認」のフラグ。人の作業を置き換えるのではなく、人の後ろに置く型です。4つの型の中で導入リスクが最も低いのが特徴といえます。
理由は単純で、誤検知が多くても損害になりにくいからです。本当は問題ない伝票にフラグが立っても、確認して問題なしと判断すればそれで終わりです。逆に見落としを1件でも拾えれば、それが価値になります。「間違えたら困る」という理由でAI導入をためらっている組織でも、この型なら始めやすいはずです。
この型が示すのは、自動化の効果は人員削減だけではないという点です。品質の向上、見落としの削減、監査対応の負荷軽減。こうした効果は工数削減の数字には出にくいものの、経営上の意味は小さくありません。人を減らすKPIが置けない業務でも、この型なら導入の理由が立ちます。
※3 個人情報保護委員会「個人情報保護法」リンク
AI自動化を外注する前に決めておく3つのこと
発注前に決めるべきは3つ。どの精度なら業務として成立するか、AIが間違えたとき誰がどう気づき誰が責任を持つか、どこまで自動化してどこから人が見るか。これが決まっていない状態で相談すると、各社から前提の違う見積もりが返ってきて、比較そのものができなくなります。
精度目標を「業務が回る水準」で決める
精度は100%を目指すのではなく、現在の人の精度と、誤りを拾う仕組みのコストから逆算して決めます。「できるだけ高く」という要求は、見積もりを膨らませるだけで判断の役に立ちません。
精度を1%上げるためのコストは、水準が上がるほど跳ね上がります。80%から90%に上げるのと、95%から96%に上げるのでは、後者のほうが手間がかかることも珍しくありません。学習データの追加、例外パターンの個別対応、チューニングの反復。どこまでコストをかける価値があるかは、業務側の許容水準がないと決められません。
そこで先にやるべきなのが、現状の人の作業精度を測ることです。実は人も間違えています。目視チェックの見落とし率、入力ミスの発生率。これを実データで把握すると、「人が98%なら、AIも98%あれば運用は変わらない」という現実的な目標が立てられます。ここを測らずに「AIだから100%であるべき」と考えると、永久に導入判断ができません。
誤りの検知方法と責任分界を先に決める
AIの出力を誰がいつ確認し、間違いが社外に流出したときに誰の責任にするか。これを契約前に文章にしておいてください。トラブルが起きてから決めようとすると、必ずもめます。
検知の手段は主に3つです。数値の突合（合計が合うかを機械的に確かめる）、サンプリング確認（一定割合を人が抜き取り検査する）、閾値による自動エスカレーション（AIの確からしさが低い分を自動で人に回す）。業務の性質に応じて組み合わせます。件数が多く1件の重みが軽いならサンプリング、1件の重みが重いなら全件確認か閾値運用、という選び方になるでしょう。
責任分界については、発注側と受注側で分けるべき範囲の考え方を整理しておきます。受注側が持つのは、仕様どおりに動くこと、指定された精度検証を実施すること。発注側が持つのは、判断基準の提供、学習データの内容に関する責任、そして運用時の確認体制です。AIの出力が業務に与える最終的な影響は、確認工程を持つ発注側が引き受ける形が一般的です。この線引きを曖昧にしたまま契約すると、精度が出なかったときに議論が長引きます。
責任分界の決め方、判定結果を見ながら整理します。hikeに相談する
費用と期間はどう見積もられるか（発注側が見るべき変動要因）
AI自動化の費用は、機能の数ではなく、扱うデータの汚さ・例外の多さ・既存システムとの接続点の数で大きく変わります。同じ「請求書の自動読み取り」でも、条件次第で費用は数倍の開きが出ます。金額の絶対値より、その見積もりが何を前提にしているかを読むほうが重要です。
見積もりが膨らむ要因は、おおむね次のとおりです。
- 学習に使えるデータが整理されていない（紙、フォルダ散在、入力と結果がひも付いていない）
- 判断基準が言語化されておらず、ヒアリングと整理から始まる
- 例外パターンが多く、個別対応の実装が必要になる
- 接続する既存システムが複数ある、またはAPIが用意されていない
- 要求精度が高く、検証と改善の反復回数が増える
- 対象業務が絞れておらず、要件定義の範囲が広い
逆に安く収まるのは、対象業務が1つに絞れていて、過去の処理結果がデータとして残っており、接続先が1〜2システムで、半自動化を前提にしている場合です。同じ会社に頼んでも、この条件が揃っているかどうかで見積もりは変わります。
ソフトウェア開発全般の工数と規模の関係については、IPA「ソフトウェア開発分析データ集」に実績値がまとまっています※4。AI自動化に固有の部分（データ整備、精度検証）は別枠で見る必要がありますが、システム開発部分の妥当性を判断する材料にはなります。
相見積もりを取るなら、揃えて渡すべき情報があります。対象業務の説明、月間処理件数、例外の割合、過去データの有無と形式、接続先システム、許容できる精度水準、確認体制。これらを同じ内容で各社に渡せば、返ってきた見積もりの差が「どこの見方が違うのか」として読めるようになります。渡す情報がバラバラだと、金額だけを比べることになり、判断を誤ります。
※4 IPA「ソフトウェア開発分析データ集」リンク
まとめ：AI自動化は「できること探し」ではなく「向く業務の判定」から始める
AI自動化の検討は、できること一覧を眺めることからではなく、自社業務の適否判定から始まります。ここまでの要点を整理します。
- AI自動化とRPAの違いは、ルールを人が書くか、事例から判断を作らせるか。書き切れるならRPAのほうが安く速い
- 向く条件は「判断基準が言語化できる」「誤りが後から検知できる」「件数が多い」。向かない条件は「例外処理が多い」「誤りが即損害になる」「判断根拠の説明が要る」
- 条件を一部しか満たさないグレーゾーンは、人が最終確認する半自動化にすれば成立する
- 事例は業務名ではなく、分類・振り分け型／抽出・転記型／下書き生成型／チェック・異常検知型の4つの型で自社に当てはめる
- 発注前に、精度目標・誤りの検知方法と責任分界・自動化する範囲の3つを決めておく
次にやることは1つです。自社の業務を1つ選び、この記事の5つの質問で判定してみてください。Yes/Noを付けるだけで、「すぐ自動化を検討」「半自動化」「今は見送り」のどれかに落ちます。ここまで整理できていれば、外部に相談したときの話の進み方が変わります。判定結果と、その根拠になった数字（月間件数、例外の割合、現状の人の精度）を持っていけば、初回の打ち合わせで見積もりの前提まで詰められるはずです。
よくある質問
AI自動化とRPAはどちらから導入すべきですか？
判断のルールを人が書き切れるかで決まります。条件分岐を文章で全部列挙でき、入力データの形式も固定されているならRPAのほうが安く、速く、精度も安定します。ルールが書き切れない、入力の形式が相手ごとに違う、といった場合にAIの出番です。順序として、まず対象業務のルールを書き出してみるのが確実です。
AI自動化に必要なデータ量はどれくらいですか？
型と要求精度によって変わります。分類・振り分け型なら、数百件規模の過去事例から検討を始められるケースがあります。ただし件数以上に重要なのが偏りの少なさです。カテゴリごとにある程度の件数が揃っていないと、少数カテゴリの精度が上がりません。また、入力と結果がひも付いた形で残っていることが前提になります。
社内にAI人材がいなくても導入できますか？
開発そのものは外注できます。ただし、判断基準の言語化と運用時の確認は社内でしかできません。業務のルールも例外パターンも、外部の開発会社には見えないからです。AIの技術者である必要はありませんが、対象業務を理解していて、社内の関係者に確認を取れる担当者を1人立てる必要があります。ここが空席だと、プロジェクトは要件定義の段階で止まります。
小さく試すにはどのくらいの期間がかかりますか？
対象業務が1つに絞れていて、過去データも揃っている場合は数週間から数ヶ月のレンジ感です。絞れていない場合は、業務の棚卸しと判定の整理から始まるため、その分の期間が上乗せされます。期間を短くする最大の要因は、発注側が「どの業務を、どの精度で、誰が確認する形で」を決めているかどうかです。
AIが間違えて損害が出たら責任は誰にありますか？
契約内容と業務フローの設計次第です。仕様どおり動いているAIの出力を確認せずに流した結果の損害と、仕様を満たしていない不具合による損害では、扱いが変わります。だからこそ、発注前に「誰がいつ確認するか」「どこからが受注側の瑕疵か」を文章にしておく必要があります。曖昧なまま進めると、問題が起きてから交渉することになります。
AI自動化で人員は減らせますか？
全自動が成立する業務は限られるため、実際に得られるのは工数の削減と品質の向上が中心です。人員削減を前提としたKPIを置くと、半自動化という現実的な選択肢が「効果不十分」と評価されてしまい、導入自体が進まなくなります。削減した工数を何に振り向けるかまで設計しておくと、社内の合意も取りやすくなります。
一度作ったAIは作りっぱなしでいいですか？
入力データの傾向や業務ルールが変われば、精度は徐々に落ちます。取引先が増えて帳票の形式が変わる、問い合わせの内容が季節で変動する、といった変化が影響します。精度をモニタリングする仕組みと、誤った事例を追加して調整する運用が必要です。発注時点で、この運用を誰がどの頻度で行うか、費用にどう含まれるかを確認しておいてください。