デモで印象的な回答が得られても、日常業務でAI機能がどう振る舞うかは分かりません。有意義な試行には、具体的な仕事、代表的な入力、結果を判断できる人が必要です。サポート業務を例に考えます。応対後、担当者が次の担当者に向けて引き継ぎ要約を作成するという作業です。入力と読み手が明確な一方で、正確さ、文脈の欠落、確認の手間について、実務上の問いが残ります。
このページの内容
AIを選ぶ前に現在の作業を説明する
担当者が現在どのように引き継ぎを準備しているかを観察します。どの情報を探し、次の担当者は要約をどう使うのでしょうか。次の行動に役立つ出力を定義してください。例えば、顧客の問題、すでに試した対応、未解決の質問、合意したフォローアップです。プロジェクトで解決したい難しさも記録します。根本の問題が元情報の不統一なら、フォームや業務フローの改善も解決策の一部になり得ます。同じ種類の作業を使い、AIの下書きを従来の方法や、より簡単な代替手段と比較しましょう。
- 誰が出力を作り、誰が使うかを明記します。
- 完成に必要な情報を記録します。
- 試行で調べるべき問題を特定します。
AIの役割に境界を設ける
この例では、担当者が確認・編集するための社内向け要約をAIが下書きする役割に限定します。顧客へのメッセージ送信や案件の完了は別の機能であり、個別の判断が必要です。機能が参照できる会話やアカウントの情報と、そのアクセスを利用者の権限に従わせる方法を定めます。元情報が不足している場合や機能を利用できない場合の対応も決めてください。手作業に戻る経路を分かりやすく用意すれば、業務を続けやすくなり、試行の対象外のケースにも対応できます。
文書化した基準で具体例を評価する
通常の会話、曖昧な依頼、意向の変更、情報不足を含む評価用データを作成します。一部の例は、機能調整に使うものとは分けておきます。ある会話の例で、顧客は返金を求めているものの、担当者は調査するとしか約束していないとします。役立つ要約はこの違いを保つ必要があり、「返金を承認した」と書けば、存在しない約束を作ったことになります。確認者には全体の印象だけでなく、正しい点、抜けている点、根拠のない点を記録してもらいましょう。
- 必要な事実：問題と、実際に決まった次の対応が保持されていますか。
- 根拠のない記述：行動、約束、顧客情報を作り上げていませんか。
- 作業全体の負担：担当者による確認と書き直しはどの程度必要ですか。
- 不完全な入力：推測で埋めずに、不足を示していますか。
公開条件とフィードバックの仕組みを定める
どの誤りが公開を妨げるか、残る制約のうち何を利用者に理解してもらう必要があるか、誰が評価結果を確認するかを合意します。サポートの例なら、要約を保存する前に、フォローアップの約束を一つずつ人が確認するルールを設けるかもしれません。これは業務ルールの提案であって、すべての誤りがなくなった証明ではありません。下書きと元情報を比較しやすくし、編集や却下も簡単に行えるようにします。公開後は修正内容を確認し、機能を変える際に合意した例で再評価します。人による確認で増える作業も含め、業務全体を評価してください。