生成AIを業務で使い始めるなら、「どのツールを契約するか」より先に、減らしたい作業と、残すべき人の判断を決めます。最初の目標は全自動化ではなく、一つの業務で時間を減らしながら品質を落とさないことです。ここでは候補選びから試験、運用判断までを具体例で説明します。
01最初の候補は「繰り返し」と「確認しやすさ」で選ぶ
会議メモの整理、問い合わせの分類、提案書の下書き、社内資料の要約は候補です。入力形式がある程度そろい、結果を担当者が原資料と照合できる業務から始めます。一方、契約の確定、支払い、顧客への無承認の送信など、誤りを戻しにくい処理は初回の対象にしません。
候補を三つ挙げ、それぞれについて「月の件数」「一件にかかる時間」「誤りが起きたときの影響」「確認できる担当者」を書き出してください。件数が多くても、例外が多すぎる業務は最初の実証に向かない場合があります。
02一つの業務を四つに分解する
例として問い合わせの一次整理を考えます。入力は問い合わせ本文、判断は用件と緊急度の分類、出力は担当部署と返信案、確認者は窓口担当者です。ここでAIに任せるのは分類と下書きまでで、正式な回答は人が確認します。
この四項目に加え、「根拠として使う資料」「情報が足りないときの対応」「AIを使わず人に渡す条件」を記録します。資料の版や閲覧権限が曖昧なまま試作すると、流暢な文章でも誤案内になり得ます。
03個人情報を除いた例で試作する
まずは実在の顧客名や機密事項を含まない例文を用意します。普通の問い合わせだけでなく、複数の用件が混ざる文章、資料に答えがない質問、対象外の依頼も入れます。AIに望む出力形式を固定し、分類、根拠、不足情報、返信案を別々に出させると、担当者が確認しやすくなります。
使用するサービスの入力データの扱い、保存、権限、学習への利用条件はプランや設定で異なります。社内で許可された環境かを確認してから実データへ進みます。
04効果は「AIの速さ」ではなく総工数で測る
試作前に同じ種類の案件を人が処理した時間と、修正・差し戻し件数を記録します。試作後は、入力準備、AI処理、担当者の確認、修正、再処理までを含めて比べます。たとえば下書きが速くても、根拠確認に時間がかかれば改善とは言えません。
合格基準は業務ごとに決めます。問い合わせなら、誤った担当部署への振り分け、存在しない根拠の提示、未承認の送信は重大な失敗です。平均の時短だけで判断せず、重大な失敗が増えていないことを必須条件にします。
05試験結果から次の打ち手を決める
品質が安定し、確認負荷も減ったら対象を少し広げます。うまくいかなければ、入力資料、業務手順、出力形式、モデルのどこに問題があるかを分けて見直します。単純な分岐は通常のプログラム、曖昧な文章の解釈は生成AIと役割を分ける方が安定することもあります。
最初の一枚として「対象業務／現行時間／AIの担当範囲／人の承認点／重大な失敗／試験結果」を埋めてみてください。この一枚が埋まらない業務は、導入前の整理がまだ必要です。
06具体例：問い合わせの振り分けを2週間だけ試す
架空の窓口で月100件の問い合わせがあり、担当者が一件あたり分類に3分、返信案作成に7分、確認に2分使っているとします。最初は個人情報を除いた過去20件を用意し、AIに「営業・技術・その他の分類、判断根拠、不足情報、返信案」を出させます。送信先の決定と実際の送信は担当者の仕事として残します。分類が曖昧な依頼や二つの用件を含む依頼は「要確認」と出せるかも試します。
試験表の一行には、元の依頼、正しい分類、AIの分類、修正内容、処理時間を記録します。仮にAIで返信案が2分になっても、根拠の確認が7分必要なら、元の12分に対して合計がどう変わるかを計算します。「20件中18件正解」だけでは不十分で、残る2件が別部署への誤振り分けなのか、顧客へ誤った契約条件を伝える危険な案なのかを区別します。
同じ試験セットで人だけの処理と比較し、品質が同等以上で総工数が減る場合にのみ対象件数を広げます。入力の機密区分や利用サービスの設定が決まらない場合は、実データの試験へ進めません。数字は判断方法を示す仮例であり、実際の合格基準は業務側が先に決めてください。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。