小さなチームでAIエージェントを安全に始める設計：読み取り専用から段階的に自動化する

はじめに

AIエージェントを業務に入れるとき、最初から「メール送信」「顧客情報の更新」「請求処理」まで自動化したくなります。しかし、小さなチームでは、便利さより先に「間違えたときに戻せるか」を設計したほうが安全です。

この記事では、1〜50人程度のチームがAIエージェントを導入するときの、最小で実務的な進め方をまとめます。

最初は読み取り専用にする

最初のエージェントには、次のような権限だけを与えます。

• FAQ、社内規程、商品情報を検索する
• 問い合わせ内容を分類し、下書きを作る
• 日報や議事録を要約する
• 判断に使った文書と不確かな点を表示する

この段階では、外部へ送信したり、データを変更したりしません。人が最終確認するため、誤りの発見と業務への適合性を同時に確認できます。

先に状態遷移表を作る

プロンプトを書く前に、業務の状態を表にします。

現在の状態	イベント	次の状態	副作用	人へ戻す条件
未確認	問い合わせ受信	下書き作成済み	下書きを保存	顧客情報が不足
下書き作成済み	担当者が承認	送信待ち	送信キューへ登録	金額・契約が含まれる
送信待ち	送信成功	完了	送信履歴を保存	外部APIが失敗

AIの役割は「状態を勝手に変えること」ではなく、決められたイベントに対して候補を作ることです。状態、イベント、権限、例外が曖昧なままでは、モデルを高性能にしても安定しません。

人の承認を境界に置く

次の処理は、最初から人の承認を必須にします。

• 顧客へのメールやSNS投稿
• 金額、契約、返金、在庫に関する変更
• 個人情報の表示・転送
• 権限やサーバー設定の変更

承認画面には、AIの出力だけでなく「参照したデータ」「変更点」「不確かな箇所」「実行すると起きること」を表示します。承認者が内容を理解できない画面は、承認が形だけになってしまいます。

失敗しても二重実行しない

外部APIやWebhookは、タイムアウトしても処理自体は成功していることがあります。再試行すると、メールの二重送信や二重請求が起きるため、次を保存します。

1. リクエストIDまたはイベントID
2. 実行前後の状態
3. 外部サービスへ送った操作の結果
4. 再実行できるかどうか

同じIDを受け取ったら副作用をもう一度実行しない、という冪等性を用意します。失敗時は「自動で何度も試す」のではなく、回数を制限し、最後は人へ戻します。

まず測る数字

導入効果は、モデルの賢さだけで評価しません。

• 1件あたりの手作業時間
• 人が修正した割合
• 承認から完了までの時間
• 二重実行や誤送信の件数
• エラーから復旧するまでの時間

読み取り専用の小さなフローでこの数字を測り、改善が確認できたら「下書き保存」「承認後の送信」の順に権限を広げます。

段階導入のチェックリスト

• 入力データと正本が決まっている
• 状態遷移と例外条件を表にした
• AIが参照した根拠を確認できる
• 書き込み・送信には承認が必要
• リクエストIDと実行ログを保存する
• 失敗時の手動復旧手順がある
• 効果を測る数字を導入前に記録した

まとめ

AIエージェントは、いきなり仕事を任せるものではなく、まず判断材料を整理する補助者として始めると安全です。読み取り専用、下書き、人の承認、限定的な自動実行という順番なら、小さなチームでも学びながら広げられます。

忙しくても、最初の状態遷移表と復旧手順だけは自分たちで作ってみてください。そこができれば、どの業務をAIに任せるべきかを落ち着いて判断できます。