ツールよりタスクが先である理由
失敗するエージェントプロジェクトの多くは、技術ではなく業務設定でつまずきます。範囲が広すぎる(「営業をサポートする」)、頻度が低すぎる(年に12件)、あるいは失敗時のコストが高すぎる(管理のない顧客対応)のです。最初のエージェントとして良いのは、明確な成果があり、人が数秒で確認できる、範囲の狭い繰り返し業務です。
このプレイブックでは、選定から本番運用までを5つのステップで案内します。コスト削減やコンプライアンス上の承認を約束するものではありません。どちらもご自身のプロセス、データ、法的状況によって決まります。事前に答えておくべき問いを提供します。
1. 意味のある3つのパイロット
- CRM のメモを下書きとして構造化
- 入力:会話メモまたは文字起こし。出力:必須項目(きっかけ、決裁者、次のステップ、日付、懸念)の構造化された下書き。人が確認して保存する。適している理由:量が多く、目標の構造が明確で、誤りが見えやすく安価に済む。
- 受信した問い合わせを事前に振り分ける
- 入力:フォームまたはメールでの問い合わせ。出力:カテゴリー(適合/不明/不適合)、欠けている情報、担当者の提案。顧客への返信ではなく、下書きとして。適している理由:ルールに沿っており、後の見極め結果で測定でき、外部とのやり取りがない。
- 出典付きの社内ナレッジ検索
- 入力:従業員からの質問。出力:根拠となった具体的な社内文書を参照した回答の下書き。出典がなければ回答しない。適している理由:どの質問にもメリットがあり、出典の確認で誤りがわかり、文書の範囲を適切に選べば顧客データは不要。
2. 選定基準
各候補を4つの観点で評価します。パイロットには、最初の3つで高いスコア、4つ目で低いスコアが必要です。
| 基準 | 質問 | 良いパイロット |
|---|---|---|
| ボリューム | その案件は週に何回発生しますか? | 設定と運用が元を取れるほど頻繁に発生する |
| ルール性 | 良い結果とは何かを文章で説明できますか? | はい、わずかな例外を除いて |
| データ品質 | 入力データは完全で、構造化され、アクセス可能ですか? | おおむねそう。不足点は把握済み |
| エラーのコスト | 結果が間違っていて、誰も気づかなかったらどうなるか? | 低:社内のみ、修正可能、外部への影響なし |
3. 受け付けから運用までの流れ
プロセスの把握
現在のプロセスを、入力、出力、所要時間、担当者とともにステップごとに記述します。判断が必要なステップを記録してください。エージェントはルールに基づくステップを引き受け、判断は人が担います。
権限と最小限のアクセス
エージェントには、そのタスクに必要なアクセス権だけを付与します。読み取りで足りるなら読み取りのみ、対象は意味のある最小限のデータに限定します。開始前に、どのデータを、どこで処理し、誰が責任を持つのかを明確にしてください。あなたのケースでそれがデータ保護やコンプライアンスに適合するかは、本プレイブックではなく、担当部署とともに行う確認によって決まります。
テストセット
最初の実行の前に、実際のケースを匿名化したもの、または再現したもので、テストセットを用意します。通常ケース(日常的なもの)、境界ケース(不完全、曖昧、異常に長いもの)、失敗ケース(言語違い、空の入力、矛盾した情報)です。各ケースについて、エージェントの結果を見る前に、何が正しい結果かを定義しておきます。
人による承認
パイロットでは、エージェントが下書きを作成します。人が承認、修正、または破棄します。修正はすべてカウントされ、種類ごとに分類されます。このリストが、エージェントを継続するかどうかを判断するための最も重要なデータ源になります。
モニタリング
- 週あたりの処理件数と、修正不要だった割合。
- 修正の種類と頻度。
- 1件あたりの前後の処理時間(推定ではなく実測)。
- 障害、タイムアウト、空の結果。
4. 開始前に運用コストを計算する
エージェントのコストは3つの項目から成ります。一回限りの構築(プロセスの把握、セットアップ、テストセット)、継続的な運用(利用料、保守、人による承認の時間)、そして失敗のコスト(修正、手戻り)です。始める前に3つすべてを計算し、承認の時間も正直に含めてください。下書きの40%を修正する必要があるエージェントでは、ほとんど時間は節約できません。
判断には簡単な計算式で十分です。月間の件数 ×(導入前の分数 − 導入後の分数)÷ 60 で、解放される工数が時間単位で出ます。これに想定時間単価を掛けると計算上のメリットになり、そこから月々の運用コストを差し引きます。この純額がプラスになって初めて、一度きりの構築費用を何か月で回収できるかが計算できます。なお「導入後」の分数には、エージェントの処理時間だけでなく、人による承認の時間も含めます。
- パイロット開始前に、少なくとも10件の実際の案件で導入前の所要時間を測りましょう。
- 利用料は、テスト時の量ではなく、想定される量で発生する金額を入力してください。
- 時間単価は前提として記録し、結果を取り繕うために後から変更しないでください。
5. 中止基準
パイロットをいつ終了するかは、成功・失敗の両方について開始前に決めておきましょう。4週間経ってから基準を決めると、データではなく雰囲気で結果を評価することになります。
- 中止
- 4週間後の修正率が事前に定めた値を上回る、外部に影響するミスが発生する、運用コストが計画を超える、チームがエージェントを使わずに回避している。
- 運用への移行
- 修正率が少なくとも4週間、目標値を安定して下回る。処理時間が測定可能なほど短縮。継続運用の責任者が決まっている。権限とデータフローが文書化されている。
- 拡張
- 最初のエージェントが稼働してからです。2つ目のパイロットを最初のものと並行して始めることはありません。
下のオートメーション概要シートは、このプレイブックのすべてのポイントを1ページにまとめたものです:タスク、基準、権限、テストセット、承認、モニタリング、コスト、中止基準。最初のツールを選ぶ前に記入しましょう。
ダウンロード
持ち帰り用
Markdown はどのテキストエディタやメモツールでも開けます。CSV ファイルはセミコロン区切りで、Excel、Numbers、LibreOffice で直接開けます。

