AIエージェントのKPI｜導入前に決める5指標
目次
はじめに
月次報告に「AIエージェントが1,200件動きました」と書く。数字は大きい。ところが、経営会議で「で、仕事はどれだけ良くなったのか」と聞かれると答えられない。
実行回数やトークン数は、利用量の説明にはなる。しかし、成果の説明にはならない。AIエージェントのKPIは「どれだけ動いたか」ではなく、仕事の完了、人の修正、安全な停止、所要時間、業務成果の5つで見る。
この5指標は、導入後にダッシュボードへ追加するものではない。何を1件と数え、どこからを失敗とするか。実装前に決める仕様である。
ここで作る成果物は、運用監視のログ一覧ではない。発注者と開発側が検収前に合意するKPI定義書だ。計測イベント、判定主体、検収閾値、例外時の責任者まで書く。「動いたか」ではなく、「契約上、何を満たせば受け入れるか」へ変換する。
AIエージェントにおけるKPIは3層で読む
Google CloudのAIエージェントのKPIガイドは、信頼性と運用効率、定着率と利用パターン、ビジネス価値を分けて測る構成を示している。この考え方を実装仕様へ渡しやすいように、ここでは次の3層へ整理する。
- システム層：正しく完了し、危険な場面で止まったか
- 業務フロー層：人の修正や待ち時間を含め、仕事が速くなったか
- 事業層：売上、応答時間、手戻り、顧客体験が変わったか
これらを1つの「自動化率」に押し込むと、問題の場所が見えなくなる。例えば、タスクは完了しているが、担当者が毎回全文を書き直しているかもしれない。完了率だけなら100%でも、業務としては成功と言いにくい。
AIエージェントのKPIを測る5指標
1. タスク完了率は「成果物」で数える
タスク完了率は、最も分かりやすい指標だ。式は「受け入れ条件を満たした件数 ÷ 依頼件数」とする。
ポイントは、エージェントが「完了」と返した回数を数えないことだ。商談後のフォロー支援なら、議事録の要約があるだけでは足りない。顧客名、宿題、担当者、期限、送信文の下書きがそろって初めて完了とする。
受け入れ条件は3〜5個に絞る。条件が抽象的だと、評価者ごとに判定が変わる。「分かりやすい」ではなく、「社名と日付が原文と一致」のように検査できる形へ落とす。OpenAIのEvals APIのように、テスト基準とデータ源の構造を分けて持つと、モデルや指示を変更しても同じ基準で比較できる。
2. 人の修正率で隠れた作業を見つける
出力が採用されても、そのまま使えたとは限らない。人の修正率は「意味の変わる修正が入った件数 ÷ 出力件数」で見る。誤字の修正と、金額・日付・判断の修正は分ける。
ここでは「人が触ったか」より、何を直したかが重要だ。修正理由を次の4種類に分けると、改善策が見える。
- 入力不足：必要な資料や項目が渡っていない
- 検索失敗：参照すべき根拠を拾えていない
- 判断失敗：ルールの優先順位や例外を誤った
- 表現不適合：形式、トーン、長さが用途に合わない
修正率が上がったとき、すぐにモデルを変えるのは早い。入力不足が原因なら、依頼フォームや参照元を直すべきだ。分類なしの平均値は、調査の入口にしかならない。
3. 安全停止は2つの率で見る
AIエージェントは、完了だけを追うと止まらなくなる。送信先が曖昧、契約金額が原文と合わない、個人情報を外部へ渡す可能性がある。こんな場面では、処理の停止が正解だ。
安全停止は2つの率を対で見る。必要停止率は「停止すべきテストケースで、人へ戻せた件数 ÷ 停止すべきテストケース数」。不要停止率は「通常ケースを誤って止めた件数 ÷ 通常ケース数」とする。片方だけなら、すべて人へ返すエージェントが高得点になってしまう。
その上で、個人情報の誤送信や無承認の契約確定は、平均値で相殺しない。重大な見逃しが1件でもあれば検収不合格とする。権限不足、数値不一致、根拠不足、禁止操作のテストケースを、検収仕様として先に作る。
NIST AI RMFのMEASURE機能も、配備前のテストと運用中の継続的な測定、利用文脈に近い条件での評価を求めている。安全性を「事故がなかった」で測るのは難しい。意図的に危険な条件を作り、止まれたかを確かめる。
4. リードタイムは人の待ち時間まで含める
モデルの応答が20秒でも、成果物の確認が翌日なら業務は速くなっていない。リードタイムは「依頼受付から、受け入れ済みの成果物が次の工程へ渡るまで」で測る。
エージェントの処理時間、人の確認待ち、差し戻し、外部システムの待ちを分けて記録する。すると、速いモデルへの交換より、承認先を一人に決める方が効くことがある。
基準値は、導入前の同じ業務から取る。件数は業務量とばらつきに応じて決める。少数のうちは中央値、最大値、個票の確認を併用する。90パーセンタイルは、十分な件数が蓄積してから見る。
5. 業務成果はAIの外側に置く
最後のKPIは、AIの出力ではなく業務の変化だ。商談後支援なら「24時間以内に次の行動が確定した案件率」。社内問い合わせなら「再オープンなしで解決した割合」。経理なら「締め処理までの所要日数」とする。
AWSの生成AI成功ガイドも、生産性、顧客エンゲージメント、運用効率、市場投入までの時間など、事業目標に合わせたKPIを事前に決める考え方を示す。ROIだけに寄せず、業務ごとの価値を記録することが大切だ。
公的な実証にも具体例がある。こども家庭庁の生成AI実践ハンドブック実証結果では、作業時間だけでなく、満足度、利便性、業務負荷も評価している。技術指標と現場の体感は、どちらか一方では足りない。
導入前にKPIシート1枚を作る
5つのKPIを決めたら、1指標ごとに次の7項目を1枚にまとめる。
- 指標名と、その指標を見る理由
- 分子と分母、または開始時点と終了時点
- ログ、チケット、CRMなどのデータ取得元
- 導入前の基準値と測定件数
- 30日後の目標値と停止基準
- 数値を毎週確認する所有者
- 数値が悪化したときに戻す設定と連絡先
ログ仕様には、`task_received`、`agent_completed`、`human_revised`、`approved`、`stopped`のような計測イベントを定義する。発生時刻、タスクID、判定者、修正理由、参照根拠を持たせる。KPIの数字から個別案件へ戻れて、初めて発注者は検収できる。
特に忘れやすいのが停止基準だ。例えば「重大な数値誤りが1件でも出たら、外部送信を停める」と決める。平均スコアが良くても、破ってはいけない条件は別枠で扱う。
基準値なしに「30%改善」と置かない。削減前の作業時間を測っていなければ、後から効果は証明できない。どうしても測れない項目は「不明」と書き、最初の2週間を基準値の収集期間にする。
30日は拡大ではなく比較に使う
稼働直後は、1業務、1チーム、同じ難易度に絞る。比較対象が毎週変わると、KPIが良くなったのか、簡単な仕事が増えたのか分からない。
- 1週目：ログ欠損と安全停止を確認する
- 2週目：修正理由の上位2種類を直す
- 3週目：リードタイムの待ち時間を減らす
- 4週目：業務成果と基準値を比較し、継続、改修、停止を決める
改善は毎週1点に絞る。モデル、指示、参照元、権限を同時に変えると、何が数値に影響したか追えない。「AI社員」の週次運用で見直す5項目でも、依頼、例外、品質、権限、改善を分けて確認する進め方を整理している。その前提となる役割と成果物は、AI社員の作り方を業務定義から整理した記事もあわせて確認してほしい。
AtsumellはKPIを実装前の仕様と考える
AIエージェントの評価は、後付けの分析機能ではない。完了の定義、修正の分類、停止すべき条件、時間の計測点、業務成果への接続を実装前に決める。これがなければ、ログは残っても判断材料にならない。
最初に作るのは大きなダッシュボードではなく、KPIシート1枚でよい。タスク完了率、人の修正率、安全停止率、リードタイム、業務成果。それぞれの分母と基準値が書ければ、何を作り、何を記録するかも具体的になる。
自社の業務に合わせて評価条件と停止基準を設計したい場合は、Atsumellにご相談ください。業務フローの可視化から権限設計、評価データの取得、運用の見直しまで、実装に渡せる形に整える。
