AIに任せる業務の選び方。候補を4つの軸でふるいにかけ、外す3条件を決める

AI 導入の相談で最も多い入口は、「AI で何かできませんか」である。悪い入口ではない。ただ、この状態のまま開発会社に声をかけると、提案の中身がその会社の得意分野で決まる。チャットボットが得意な会社からはチャットボットの提案が来て、画像認識が得意な会社からは画像認識の提案が来る。どちらが自社に効くのかは、比べても分からない。

順番が逆になっている。先に決めるのは「どの業務を AI に任せるか」であって、「どの技術を使うか」ではない。 業務が決まれば技術はほぼ自動的に絞られ、費用の目安も出せるようになる。

この記事では、社内の業務から候補を出し、4 つの軸でふるいにかけて 1〜2 件まで絞る手順と、当てはまったら今回は見送る 3 条件を示す。開発会社に声をかける前の、発注側だけで進められる作業である。

ふるいの上に4つの部品が残り、下の受け皿に小さな部品がたまっている机

なぜ業務選定で費用が決まるのか

同じ予算・同じ開発会社でも、対象の業務が違えば結果は変わる。理由は 3 つある。

必要なデータの整備量が業務ごとにまったく違う。 すでに電子で溜まっている業務と、紙とベテランの頭の中にしかない業務では、開発の前段にかかる工数が桁で変わる
合格の判定にかかる手間が違う。 「正解が 1 つに決まる業務」と「人によって正解が違う業務」では、精度評価の往復回数が変わる
効果の総量が違う。 月に 3 件しか発生しない業務をどれだけうまく自動化しても、固定費を回収できない

つまり、業務選定は技術選定の前工程ではなく、費用が決まる工程そのものである。ここを飛ばして見積もりを取ると、金額の高低は見えても、その金額を払う価値があるかが判断できない。

手順 1：候補を 10〜15 件、粗く出す

まず数を出す。この段階で良し悪しは考えない。

集め方は、部署ごとに「時間を食っている作業」を 3 つずつ挙げてもらうのが早い。新しい業務を想像してもらうのではなく、すでに毎日・毎週やっていることに限定するのがこつである。想像上の業務は、後の 4 軸で必ず判定不能になる。

出すときは、1 件を次の粒度まで具体的に書く。

誰が、何を受け取って、何を作っているか（例：経理担当が、届いた請求書 PDF を見て、会計システムに 8 項目を入力している）
1 件あたり何分かかるか
月に何件あるか

この 3 つが書けない業務は、この時点で候補から外してよい。書けないということは、現状が測れていないということで、AI を入れても効果を測れない。

手順 2：4 つの軸でふるいにかける

候補が出たら、各軸を 3 段階（2 点 / 1 点 / 0 点）で機械的に付ける。議論で決めず、先に基準を書いてから当てはめる。

軸 1：量（件数 × 1 件あたりの時間）

年間で何時間ぶんの作業かを出す。月の件数 × 1 件あたりの分数 × 12 ÷ 60 でよい。

点	目安
2 点	年間で数百時間規模の作業がある
1 点	年間で数十時間規模
0 点	それ未満、または件数が数えられない

AI 開発には、使う量に関係なくかかる費用がある（要件定義・環境構築・検収・保守の固定部分）。量が小さい業務は、この固定部分を回収できない。ROI の出し方は AI投資のROI計算にまとめている。

軸 2：正解を文章で定義できるか

「この出力なら合格」と着手前に書けるかを見る。

点	目安
2 点	正解が 1 つに決まる（請求書の金額を読み取る、在庫数を予測する）
1 点	正解の幅はあるが、合格ラインは書ける（要約が 3 つの論点を含んでいれば可）
0 点	人によって正解が違い、合意できない（「良い企画かどうか」）

ここが 0 点の業務は、検収の基準が作れない。作れないまま進むと、「なんとなく物足りない」という理由で受け入れが止まり、追加改修が無限に続く。精度の測り方は AIの精度をどう評価するかを参照してほしい。

軸 3：入力データが、すでに電子で揃っているか

AI に渡す材料が今どこにあるかを見る。

点	目安
2 点	システムや共有フォルダに電子データとして揃っていて、すぐ取り出せる
1 点	電子だが散在している、権限の整理や権利の確認が要る
0 点	紙のまま、または担当者の経験としてしか存在しない

0 点でも将来はできる。ただし今回の予算では、データを揃える工程が費用の大半を占める。何を確認すべきかは AI開発のデータ準備にある。

軸 4：間違えたときに取り返せるか

AI は必ず間違える。問題は間違いが表に出るまでに人が挟まるかである。

点	目安
2 点	出力を人が確認してから使う（下書き・候補の提示）
1 点	自動で流れるが、事後に検知・訂正できる
0 点	誤りが即座に社外や取引に反映され、取り消せない

0 点の業務は不可能ではないが、確認・監査・例外処理の作りこみが必要になり、費用が跳ね上がる。最初の 1 件には向かない。

手順 3：合計点で並べ、上位 1〜2 件に絞る

8 点満点で並べる。6 点以上が出れば、そこが最初の 1 件である。

点数が近いものが複数残った場合は、「効果が数字で説明できるか」を第 2 基準にする。社内で予算を通す段階では、点数の高さより「削減時間を誰が測るか」が問われる。

3 件以上を同時に始めたくなるが、最初の 1 件は進め方そのものを学ぶための案件でもある。1 件で体制・判断の速度・データの出し方が分かってから 2 件目を足すほうが、結果的に速い。

当てはまったら今回は見送る 3 条件

合計点に関係なく、次のどれか 1 つでも当てはまったら、今回の候補からは外す。外した理由を残しておけば、条件が変わったときに戻せる。

1. 軸 1 が 0 点。 量が小さい業務は、どれだけ技術的にうまくいっても費用を回収できない。手順の見直しや既製ツールで足りることが多い。

2. 軸 2 が 0 点。 合格条件が書けない業務は、検収できない。まずは「誰が、何をもって合格とするか」を社内で決めるところから始める。決まってから発注しても遅くない。

3. 軸 4 が 0 点で、かつ人の確認を挟む余地がない。 誤りが即座に外部へ出る業務で、運用上どうしても人を挟めない場合、必要な作りこみは最初の案件の規模を超える。

3 条件のどれも当てはまらないものが 1 件も残らなかった場合、それは「今は発注のタイミングではない」という結論である。無理に 1 件をひねり出すより、データの整備や合格条件の言語化を先に進めたほうが、次の見積もりは確実に安くなる。

絞ったあとにやること

対象業務が 1〜2 件に決まったら、次の 3 つを書いてから開発会社に声をかける。

対象業務の現状（件数・1 件あたりの時間・担当部署）
合格条件（軸 2 で書いたもの）
使えるデータの所在と形式（軸 3 で確認したもの）

この 3 つがあると、複数社の提案が同じ前提で比較できる形になる。比べられる提案を引き出す書き方は AI開発のRFPの書き方に、検証範囲の決め方は PoCの設計方法にまとめている。

費用の目安を先に把握しておきたい場合は、分野別・フェーズ別の費用相場で範囲を確認したうえで、費用診断に対象業務の条件を入れると、発注準備シートの形で整理できる。すでに見積書を受け取っている場合は、見積書チェックで相場と共通の指標に当てて確認するとよい。

まとめ

先に決めるのは技術ではなく対象業務。業務が決まれば技術は絞られ、費用の目安が出せる
候補はすでに毎日・毎週やっている業務から 10〜15 件。件数・1 件あたりの時間・担当が書けないものは外す
ふるいは 4 軸（量 / 正解を定義できるか / データが電子で揃っているか / 間違いを取り返せるか）を各 2 点で採点し、8 点満点で並べる
合計点に関係なく外す 3 条件は、量が 0 点 / 合格条件が書けない / 誤りが即座に外部へ出て人を挟めない
残らなければ「今は発注のタイミングではない」。データ整備と合格条件の言語化を先に進めるほうが、次の見積もりは安くなる
絞れたら、現状の数字・合格条件・データの所在の 3 点を書いてから声をかける。これがないと各社の提案は比較できない