AIを組み込むときに難しいのは、動かすことではなく「どれくらい当たっているか」を測ることと、外れたときの手当てを決めることです。
1. AIに任せる部分を切り分ける
一つの業務をまるごとAIに任せようとすると、うまくいかなかったときに原因が分からなくなります。業務を手順に分解し、その中で「判断のばらつきが許される部分」「下書きがあれば人が直せる部分」を探してください。分類する、要約する、下書きを作る、候補を並べる、といった作業は任せやすい部類です。逆に、金額の計算や本人確認のように、間違いが許されず答えが一つに決まる処理は、通常のプログラムで書くほうが確実です。
- 対象の業務を、手順ごとに書き出す
- 各手順について、間違いが起きたときの影響の大きさを書く
- 人が最終確認をする手順と、自動のまま通す手順を分ける
- 通常のプログラムで書けるところを、AIに任せていないか見直す
2. 正解の例を先に集める
精度を測るには、比べる相手が必要です。実際の業務から30件から100件程度の事例を集め、それぞれについて「本来どういう結果であるべきか」を人の手で書いておいてください。この作業は地味ですが、ここを省くとPoCの結果を数字で語れなくなります。事例を集めるときは、典型的なものだけでなく、判断に迷ったもの、過去に間違いが起きたものを意図的に混ぜます。うまくいく例ばかりで測った精度は、実際の業務では再現しません。
- 典型的な事例(多数を占めるパターン)
- 判断に迷った事例(担当者によって結果が割れるもの)
- 過去に間違いが起きた事例
- 想定外の入力(空欄、書式違い、極端に長い・短いもの)
3. 精度の測り方を決める
「精度が高い」という言い方は、測り方を決めないと意味を持ちません。分類なら、正しく当てられた割合だけでなく、見逃しと誤検出のどちらが困るのかを決める必要があります。見逃しが困る業務(不正の検出など)と、誤検出が困る業務(顧客への自動通知など)では、目指す方向が逆になります。文章を作る用途のように、正解が一つに決まらない場合は、人が基準を決めて採点する方法を用意してください。
4. 合格ラインを、人がやった場合と比べて決める
合格ラインを決めるときの目安は、完璧さではなく「今のやり方より良いか」です。今は人が手作業でやっているなら、その人の正確さと所要時間を測っておくと比較ができます。人でも判断が割れる業務なら、AIに100%を求めるのは現実的ではありません。あわせて、合格ラインに届かなかった場合に、人の確認を挟めば使えるのか、それとも使えないのかも決めておきます。「AIが下書きを作り、人が直す」形なら、低めの精度でも業務が回ることがあります。
- 今のやり方での正確さと、一件あたりの所要時間
- この用途で許容できる間違いの割合と、その根拠
- 人の確認を挟む場合、確認にかかる時間を含めて割に合うか
5. 外れたときに何が起きるかを決める
AIを使う機能では、間違いが必ず起きる前提で設計します。重要なのは、間違いが起きたときに誰がどう気づき、どう直すかです。利用者が結果をその場で直せるようにするのか、社内の担当者が後からまとめて確認するのか。そして、直した内容がどこかに記録されて、改善の材料になるかどうか。ここが設計されていないと、間違いが静かに積み上がっていきます。
- 利用者が「これは違う」と伝える手段があるか
- 間違いに社内で気づく仕組みがあるか(抜き取り確認、件数の監視)
- 直した内容が記録され、後から見返せるか
- 重大な間違いが起きたときに、機能を止める手段があるか
6. 利用者への見せ方を決める
AIが出した結果であることを利用者に伝えるかどうかは、信頼に関わります。一般に、AIが生成した内容であることを示し、確認を促す表示を添えるほうが、後のトラブルを減らせます。また、結果に自信の度合いを添えられる場合は、低いものだけ人が確認する運用が組めます。医療や法律、金融など、助言が利用者の判断に直接影響する分野では、表示の要件が業界のルールで定められていることがあるため、事前の確認が必要です。
- AIによる出力であることを画面上で示すか
- 利用者に確認や修正を促す文言を添えるか
- 自信の度合いを出せるか。出せる場合、低いものをどう扱うか
- 扱う分野に、表示や説明に関する業界のルールがないか
7. 情報の扱いと費用の見通し
外部のAIサービスに送るデータに、個人情報や取引先の機密情報が含まれるかを確認してください。含まれる場合は、利用規約でそのデータがどう扱われるか(学習に使われるか、どこに保存されるか、いつ消えるか)を読み、必要なら送る前に伏せる処理を入れます。費用は、処理する量に応じて増える形が一般的です。PoCの段階で一件あたりのおおよその量を測っておくと、本番の規模に掛け算して見通しが立てられます。金額そのものは案件により異なるため、ここでは「量を測っておく」ことが要点です。
- 送るデータに個人情報・機密情報が含まれるか
- 利用規約上、送ったデータが学習に使われるか・保存されるか
- 伏せる処理(氏名や連絡先の置き換え)が必要か
- 一件あたりの処理量を測り、想定件数を掛けた見通しを作る
8. 結果を記録して持ち寄る
PoCの結果は、数字と実例の両方で持ち寄ってください。数字だけだと改善の手がかりが分からず、実例だけだと全体の傾向が分かりません。特に外れた事例は、どういう入力で外れたかを分類しておくと、次に何を直せばよいかが見えます。以下の表を埋めて、判断の場に持ち込んでください。なお、本資料は一般的な情報をまとめたものであり、扱う情報の種類や業界のルールに関わる個別の事案は、専門家にご確認ください。
関連するインサイト
- 生成AIを開発工程に組み込む — 品質を落とさず速く安く作る実務設計書の下書き、コード生成とレビュー、テスト生成、既存コードの解析、ドキュメント整備での生成AIの使いどころと、人がレビューする原則、顧客データや秘密情報の扱い、向く作業と向かない作業を整理します。
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開