---
title: "通知Botを作ったら問い合わせ窓口になってしまった"
description: "小さな通知Botが便利になるほど、出力の正しさや誤通知時の責任が曖昧になっていくことについてのメモ。"
lang: "ja"
canonical: "https://llm-lab.dev/posts/notification-bot-owner-note/"
source: "https://llm-lab.dev/posts/notification-bot-owner-note.md"
publishedAt: "2024-05-14"
updatedAt: "2024-05-14"
category: "技術メモ"
tags:
  - "bot"
  - "operations"
  - "automation"
---

# 通知Botを作ったら問い合わせ窓口になってしまった

> [!NOTE]
> この記事で確認したこと
>
> 小さな通知Botでも、使われ始めると出力は「参考情報」ではなく業務判断の材料になります。通知がないことを「問題なし」と受け取られるなら、誤通知や通知漏れには、責任の所在、元データ、通知条件を一緒に示す必要があります。
>
> 通知内容だけを出すのではなく、集計対象、集計時刻、元データへのリンク、異常時の連絡先、通知条件を添えると、受け取った人が根拠を確認しやすくなります。

通知Botは、小さく作ると便利です。毎朝の件数、未処理の一覧、期限切れのタスクをSlackへ流すだけでも、画面を見に行く手間は減ります。

ただ、便利になるほどBotの出力は「参考情報」ではなくなります。担当者はBotの通知を見て動きます。通知がなければ問題なしと判断します。そこで誤通知や通知漏れが起きると、急に責任の所在が曖昧になります。

作った側は、入力データが正しければ正しい通知になると考えがちです。一方で使う側は、Botが出したものだから正しいと受け取ります。この認識のズレがあると、Botは小さいのに運用上の影響は大きくなります。

最近は、通知に次の情報を入れるようにしています。

```text
集計対象
集計時刻
元データへのリンク
異常時の連絡先
通知条件の簡単な説明
```

これだけでも、通知を見た人が「何を根拠に出ているのか」を確認しやすくなります。

AIエージェントの出力も同じだと思います。使われ始めると、ただの提案ではなく業務判断の一部になります。だからこそ、出力内容だけでなく、根拠、対象範囲、失敗時の戻り先を一緒に見せる設計が必要になります。