AI社員の運用｜毎週見直す5項目

はじめに

AI社員を業務へ入れると、見た目は整っているのに、古い案件や異なる金額単位が混ざることがある。担当者がその場で直せば、目の前の仕事は終わる。しかし、修正理由を残さなければ、次回も同じ確認が発生する。

翌週も、同じ確認が発生する。

AI社員の運用で厄介なのは、大きな障害より、このような小さな手戻りだ。1件なら数分で直せる。だから記録されず、いつの間にか人間がAIの後処理を抱える。導入時には速く見えた仕事が、数か月後には「確認が必要な作業」に変わってしまう。

防ぐ方法は、短い定例見直しを決めておくことだ。ここでは、導入直後の標準例として週1回・30分を使う。確認するのは、依頼、例外、品質、権限、改善の5項目。ツールを増やす前に、チームが同じ事実を見て判断できる形をつくる。

AI社員の運用は導入後から始まる

AI社員を作る段階では、役割、入力、出力、使うシステムを決める。ここまでは通常のシステム設計に近い。違いが出るのは運用開始後だ。

人間の依頼文は毎回少しずつ変わる。参照先のデータも更新される。利用するモデルや外部サービスの挙動も変わり得る。つまり、同じ指示を登録しただけでは、同じ品質が永続するとは限らない。

米国国立標準技術研究所のAI Risk Management Frameworkも、AIのリスク管理を一度きりの検査ではなく、統治、状況把握、測定、管理を続ける活動として整理している。導入後の監視計画には、利用者からの意見、上書き、停止、事故対応、復旧、変更管理まで含まれる。

日本でも、経済産業省のAI事業者ガイドラインは、AIを取り巻く変化に応じてガバナンスを継続的に見直す考え方を示す。AI社員を「設定して終わるソフト」と見るより、担当業務と判断範囲を更新する運用単位として扱うほうが実態に合う。

では、毎週何を見ればよいのか。

1. 依頼一覧で「想定した仕事」を確認する

最初に見るのは、AI社員へ届いた依頼の一覧だ。件数だけでは足りない。依頼を次の4つに分ける。

• 想定どおり完了した
• 人間の確認後に完了した
• 人間へ引き継いだ
• 途中で止まった

この分類があると、成功率の数字だけでは見えない負担が分かる。たとえば完了率が95%でも、その半分に10分の手直しが必要なら、運用は安定していない。逆に完了率が80%でも、残り20%を正しい担当者へ数秒で渡せるなら、業務としては十分に使える場合がある。

記録する最小項目は、依頼日時、依頼種別、結果、所要時間、人間の確認時間だ。依頼本文をすべて一覧に載せる必要はない。機密情報を含む場合は、参照権限を分けたうえで、週次会議には集計値と識別子だけを出す。

比較には分母も置く。人間の確認が必要だった件数を総依頼数で割れば、確認介入率になる。人間の確認時間をAI社員が完了した件数で割れば、1件あたりの後処理時間になる。この2つを前週と比べれば、処理件数の増減に引きずられず、運用負担が軽くなったかを判断しやすい。

ここで決めたいのは、AI社員の仕事を増やすことではない。想定外の依頼がどれだけ来ているかを知り、役割の境界を保つことだ。役割を先に決める方法は、AI社員の作り方は役割分担からでも詳しく整理している。

2. 例外一覧で「人へ渡す条件」を直す

次に、停止や引き継ぎが発生した案件を見る。見るべきなのは失敗の件数ではなく、止まり方だ。

良い停止には理由がある。「金額が上限を超えた」「顧客名を一意に特定できない」「外部送信が必要」のように、人間が次の判断を始められる。悪い停止は「処理できませんでした」だけで、担当者が最初から調査し直す。

例外ごとに、少なくとも次の4点を残す。

1. どの条件で止まったか
2. どこまで処理済みか
3. 判断に必要な資料は何か
4. 誰へ、いつまでに渡すか

同じ例外が3回続いたら、個別修正ではなく仕様を見直す合図だ。入力項目を追加するのか、参照データを整えるのか、人間へ渡す条件を早めるのか。原因によって対策は異なる。

例外をゼロにしようとすると、AI社員へ過剰な権限や推測を許しやすい。目標は「何でも完了する」ではなく、「曖昧なときに安全に止まり、仕事を引き継げる」ことだ。

3. 品質サンプルで「正しさの定義」を更新する

全出力を人間が確認し続けると、自動化の効果が薄れる。一方、確認をゼロにすると小さな誤りが蓄積する。そこで、週次では出力の一部を抽出して評価する。

たとえば100件の処理から10件を選び、次の観点で見る。

• 事実が参照元と一致しているか
• 指定した形式を守っているか
• 禁止した情報を含んでいないか
• 次工程の担当者がそのまま使えるか
• 人間による修正量はどの程度か

「良い文章だった」のような感想では改善につながらない。請求書の下書きなら、取引先、対象月、金額、税区分、支払期日を別々に判定する。商談要約なら、決定事項、未決事項、担当者、期限、根拠発言を確認する。仕事ごとに採点項目を固定する。

さらに、毎週同じ簡単な案件だけを選ばない。通常案件、境界に近い案件、前週に失敗した条件を混ぜる。AI社員が得意な範囲だけを測っても、運用上の弱点は見えない。

AIエージェントの監視で残す5つのログでは、追跡に必要な記録を扱った。週次レビューでは、そのログを「直すか、止めるか、任せる範囲を変えるか」という判断へつなげる。

4. 権限一覧で「できること」を増やしすぎない

AI社員は、参照だけできる状態と、更新や送信までできる状態でリスクが大きく変わる。便利だからと権限を足していくと、誰が何を承認したのか分からなくなる。

週次では、実際に使った権限を確認する。

権限は「使えるか」ではなく、「失敗したとき戻せるか」で決める。変更履歴が残らない操作、広い範囲への一括更新、取り消せない送信は、狭い試行段階では人間側に残す。

デジタル庁の生成AIシステム利活用ルールひな形も、利用前に環境、条件、相談先、事故時の対応を理解することを求めている。社内ルールを長文化する前に、AI社員ごとの権限表と相談先を1枚で示すと現場で使いやすい。

5. 改善一覧で「次週に変える1点」を決める

最後に、見つかった課題を改善一覧へ移す。ここで欲張らない。1体のAI社員につき、次週に変える項目は原則1つに絞る。

複数の指示、参照先、モデル、権限を同時に変えると、何が品質に効いたのか分からない。変更前の値、変更内容、期待する効果、評価日を残す。うまくいかなかったときに戻す条件も決める。

改善一覧には、次のように書く。

> 変更前：顧客名が部分一致でも案件へ紐づける

> 変更後：正式名またはメールドメインの完全一致だけを採用する

> 期待：誤った案件への紐づけを週2件から0件へ減らす

> 評価日：次回の週次レビュー

> 戻す条件：未処理が20件を超え、担当者確認が追いつかない

この形式なら、改善が「プロンプトを工夫する」という曖昧な宿題にならない。仕様、データ、権限、運用のどこを変えたかが分かる。

30分の週次レビューを回す順番

会議を長くすると続かない。参加者は、業務責任者、実際の利用者、運用担当の3役で十分だ。兼任でもよい。以下の30分は導入直後の小さな業務を想定した配分であり、法務判断、採用、決済、外部送信など影響の大きい仕事へそのまま当てはめるものではない。

判断できない項目は、その場で推測して埋めない。担当者と期限を決め、AI社員の対象範囲を広げずに保留する。30分で結論が出ない課題は、運用会議ではなく設計課題として切り出す。

見直し頻度もリスクで変える。下書き作成のように人間が必ず確認し、誤りを公開前に回収できる業務は、安定後に隔週へ延ばせる。一方、顧客データの更新や外部送信に触れる業務は、週次会議だけに頼らず、実行ごとの承認と異常時の即時停止を組み合わせる。件数が少ないことは、影響が小さいことを意味しない。

最初の4週間は拡大より安定を優先する

導入直後は、使える機能を増やしたくなる。だが、最初の4週間で確かめたいのは機能数ではない。

• 同じ種類の依頼を同じ基準で処理できる
• 迷ったときに安全に止まれる
• 人間が途中から作業を再開できる
• 誰が変更を承認したか追える
• 改善前後を同じ指標で比較できる

この5点が揃えば、2つ目の業務を追加しやすい。揃わないまま対象を広げると、例外と確認作業も一緒に増える。

AI社員の費用を見るときも、利用料だけでは足りない。AIエージェントの費用を分ける5つの内訳で扱ったように、評価、監視、改善、引き継ぎにも工数がかかる。週次レビューで人間の確認時間を測れば、その費用を曖昧にせず判断できる。

AI社員は、導入日に完成しない。仕事を渡し、例外を見つけ、合格基準と権限を直す。その繰り返しで、担当できる範囲が明確になる。

最初の一歩はシンプルだ。来週の予定に30分を確保し、依頼、例外、品質、権限、改善の5つを同じ表に置く。実装を増やす判断は、その表を見てからで遅くない。

自社業務に合うAI社員の役割、停止条件、評価基準を整理したい場合は、Atsumellへ相談してほしい。業務フローの可視化から要件定義、運用設計、AIエージェントの構築まで一緒に組み立てる。

関連記事

• AI社員の作り方は役割分担から
• AIエージェントの監視｜残す5つのログ
• AIエージェントの費用｜5つの内訳