AIを業務に入れたいが何から始めればいいか分からないときの進め方

経営から「AIで何かできないか検討して」と言われた。調べるほど事例は出てくるが、自社のどの業務に当てはまるのかが分からない。数社に相談してみたが、話が噛み合わないまま止まっている。

この状態から抜けるには、順番を変える必要がある。AIから入ると当てはまる業務を探すことになり、業務から入ると使う技術が決まる。

「AI導入」を目的にすると失敗する

社内の稟議には「AI導入」と書かれる。それは手段であって、達成したいことではない。

実際に求められているのは、処理にかかる時間を減らす、人手不足を補う、判断の品質を揃える、といった業務側の結果である。ここを先に決めておかないと、「精度85%が出ました」という報告に対して、それが良いのか悪いのか誰も判断できない。

順番を逆にする。時間がかかっている業務を先に並べ、そのうちどれがAIで扱えるかを見る。並べてみると、AIを使うまでもない業務が混ざっていることが多い。入力フォーマットを揃える、SQLで集計する、ルールベースの条件分岐を書く。これで済むものにLLMを使うと、コストも増えるし結果も不安定になる。

向いている業務の見分け方

AIに向く業務には共通点が3つある。

繰り返し起きる。 月に数回しか発生しない業務を自動化しても、構築と運用の手間が回収できない。目安として、月に数十回以上、または1回あたり数十分以上かかっている業務が対象になる。

判断基準を言語化できる。 ベテランが頭の中でやっている判断を、文章で説明できるか。「この条件のときはこう分類する」を書き出せるなら、その説明はそのままプロンプトや評価基準になる。書き出せない業務は、AIに渡す前に業務側の整理が必要になる。

間違えても致命的でない、または人が確認する工程を挟める。 AIは確率的に動くので、必ず一定の割合で誤る。誤りが即座に損害になる業務は、人が確認する工程を必ず入れる。入れられないなら対象から外す。

逆に向かないのは、法的責任が直接発生する判断、発生頻度が低い業務、正解が一つに定まらないのに一つの答えを求められる業務である。

最初にどこから手をつけるか

業務を棚卸しして、「発生頻度 × 1回あたりの所要時間」で並べる。上から順に、先ほどの3条件に当てはまるかを見る。

ここで一番大きいものを選ばない。最も時間を食っている業務はたいてい基幹業務で、止まると事業が止まる。最初の対象は2番目か3番目、うまくいかなくても業務が回るものを選ぶ。

問い合わせメールの一次分類、社内文書からの情報抽出、定型レポートの下書き作成、議事録の要約と項目抽出。このあたりは条件を満たしやすく、失敗しても人がやり直せる。

PoCで終わる理由

PoCをやったが何も残らなかった、という話は多い。原因はだいたい3つに絞れる。

評価基準を決めずに始めている。 デモを見て「思ったより賢い」で判断すると、本番データを流したときに崩れる。デモは通りやすい例で作られている。

比較対象が無い。 「精度80%」だけでは判断できない。今その業務を人がやったときの正確さがどのくらいなのかを知らないと、80%が導入に値するのか分からない。

業務フローに載せる話を後回しにしている。 動くものができても、誰がいつ使うのか、結果を誰が確認するのか、間違っていたらどう直すのかが決まっていないと、そのまま止まる。

回避策は、評価データを先に作ること

技術の検証より前に、判断材料を用意する。

1. 過去の実データを50〜100件集める。 きれいなサンプルではなく、実際に処理した中から無作為に選ぶ。例外的なケースも含める
2. 正解を人が付ける。 その業務の担当者が、本来こうあるべきという結果を書く。ここで担当者ごとに答えが割れるなら、業務の判断基準がまだ曖昧だと分かる。この時点で見つかるほうが安い
3. 合格ラインを先に決める。 「この業務では、100件中何件正しければ人の確認工数が見合うか」を業務側の言葉で決める
4. 現状の数字を測る。 今の人手での所要時間とエラー率

ここまで用意してから、最も簡単な方法で試す。プロンプトを書くだけで合格ラインを超えることもある。超えなければ、社内文書を検索して渡す構成（RAG）を足す。それでも足りないときにファインチューニングを検討する。この順番を飛ばすと、必要のない構築費用がかかる。

精度は保証できない

「精度99%を保証します」と言う相手は疑ったほうがいい。LLMは同じ入力に対して同じ出力を返すとは限らないし、入力データの傾向が変われば結果も変わる。100%にはならない。

現実的な設計は、誤りが出る前提で業務を組むことになる。

• 結果に信頼度を持たせ、低いものは人に回す

• 全件ではなく一定の割合を抜き取って人が確認する

• 入力と出力のログを残し、後から誤りの傾向を追えるようにする

• 誤ったときに誰がどう直すかを、運用開始前に決めておく

導入後に精度が落ちることもある。扱う文書の書式が変わった、新しい商品カテゴリが増えた、といった業務側の変化が原因になる。測り続ける仕組みが無いと、落ちたことに気づけない。

コストの考え方

費用は4つに分かれる。初期構築、API利用料、評価と改善の運用、人の確認工数。

見落とされやすいのは後半2つである。作って終わりではなく、月次で結果を見て、プロンプトや検索対象を直し続ける作業が発生する。その担当者を決めていないプロジェクトは、半年後に誰も見ていない状態になる。

API利用料は入力の長さでほぼ決まる。社内文書を丸ごと渡す構成にすると1件あたりの単価が跳ね上がるので、必要な部分だけを渡す設計がそのままコスト削減になる。ここは初期の作り方で数倍変わる。

このほかに、データ整備、アクセス権限の設計、ログの保管が要る。機密文書を扱うなら、どのデータがどこへ送信されるかの整理も必要になる。

見積もりを取る前に、業務側で1つ出しておくと話が早い。「この業務が1件処理されるとき、いくらまでなら合うか」。現状の人件費から逆算できる。この数字があると、実現方法の選択肢を金額で絞り込める。

進め方の順番

1. 業務を1つに絞る（頻度 × 時間で並べ、2〜3番目を選ぶ）
2. 評価データを作る（実データ50〜100件 + 正解 + 合格ライン）
3. 最も簡単な方法で試す（プロンプト → RAG → ファインチューニング）
4. 合格ラインと現状の数字で比較する
5. 業務フローに載せる（人の確認工程を含めて設計する）
6. ログを取り、月次で見直す

2を飛ばして3から始めると、PoCで止まる。順番としてはここが一番効く。

相談について

どの業務から始めるか、という判断だけでも社内で決めきれないことがあります。私たちは、評価データの作り方と合格ラインの決め方から入るご相談を受けています。技術の選定はその後の話になります。

まだ社内で方針が固まっていない段階でも構いません。

→ 相談する