AI監視の通知設計：重大度ではなく手を打てるかで即時を決める
即時に人を呼ぶ事象は、重大度ではなく、受け取った人がその場で手を打てるかで選びます。
この記事の要点
- 即時に人を呼ぶのは、受け取った人が手を打てる事象だけ
- 手を打てない事象は、日次と月次の束に落とす
- 手を打てなくても即時に残す事象を、例外として先に書き出す
- 三段の振り分けを、納品前に検収条件として表に書く
全体像図を準備中
目次
即時に人を呼ぶのは手を打てる事象だけ
A&Aの考え方
段とは、通知を読む時刻で分けたまとまりのことです。即時の通知は、受け取った人がその場で打てる手のある事象だけを流す段です。手があるとは、受け取った時点で何をするかが決まっている状態を指します。
A&Aの考え方
重大度で選ぶと、しきい値を上下させるだけになります。重い順に流せば、受け取った側は「重いが今は何もできない」通知を読み続けます。読み飛ばす習慣がつくと、手を打てる通知も同じように流れていきます。
出典に基づく事実
米国で業務の自動化サービスを売っている Gumloop は、2026年2月17日に自社のサポート運用を記事で公開しました。その記事には、同社のサポート担当は2人だけだと書かれています。
出典に基づく事実
その記事によると、サービスの状態を見るエージェントは、見つけたことに手が打てる場合に限って人に知らせます。常時の監視は、雑音を増やさずにチームが状況を把握し続けるためだとも書かれています。
A&Aの考え方
この記事を書いている Automate & Augment（A&A）は、この条件の置き方を、通知の量を減らす工夫だとは読みません。即時という段に入る資格の定義だと読みます。量の話なら、しきい値を動かせば済みます。どの事象を即時に流すかという話なら、動かすのは即時に流す条件そのものです。
A&Aの考え方
受託でAIを納めている場合は、手前にもう一段の問いが要る、とA&Aは考えます。手を打てるのは誰か、という問いです。顧客のシステムを監視しているとき、設定を変えられるのは顧客で、こちらは報告しかできないことがあります。
仮想例
たとえば、納品したAIが外部サービスの応答待ちで失敗した場面を考えます。再実行すれば直るなら、手があるのは受託側です。顧客の契約が上限に達したことが原因なら、手があるのは顧客です。同じ失敗でも、即時に呼ぶ相手が変わります。
手を打てない事象は日次と月次の束に落とす
A&Aの考え方
即時に呼ばないことと、見なかったことにすることは別です。手を打てない事象は、捨てるのではなく、読む時刻を決めた束に移します。
出典に基づく事実
先の自動化サービスの会社の記事には、即時の通知とは別の段も書かれています。24時間ごとに、エージェントが直近24時間の問い合わせを集め、要約にまとめて社内チャットに投稿します。
出典に基づく事実
月ごとには、別のエージェントが過去30本の日次の要約を読み直します。そこから、最も多い誤りの型を取り出します。取り出した報告を、まだ手を付けていない課題の一覧と突き合わせると、作るべき課題の候補が示されると書かれています。
A&Aの考え方
A&Aは、この並びを通知の強弱ではなく、読む時刻の違う三段だと読みます。即時は1件に手を打つための段です。日次はその日の全体をつかむ段です。月次は1件では見えない型を見つける段です。
A&Aの考え方
段が分かれていると、1件の落とし先が決まります。手を打てない失敗は、日次の要約の中で件数として出ます。件数が増え続けていれば、月次の読み直しで型として見えます。どの段にも入らない事象は、そもそも記録する理由がない事象です。
仮想例
たとえば、月に数回出る応答の遅れを即時に流すと、受け取った人は毎回「様子を見る」と判断します。日次の要約で件数として見れば、前の月より大きく増えた月に、初めて手が要ると分かります。
A&Aの考え方
日次の束に入れる1件には、件名のほかに欄を足しておく、とA&Aは考えます。どの利用者で起きたかの欄を足します。同じ原因で何回目かの欄も足します。この欄が無いと、日次の要約は件数の一覧にとどまり、月次で型を取り出せません。
A&Aの考え方
ただし、この運用を公開した会社は、自社の製品を自社で監視しています。受託で顧客のシステムを監視する場合は、日次の要約を顧客にも渡すかどうかが別の論点になります。渡すなら、顧客が読む時刻も検収条件の一部になります。
手を打てなくても即時に残す例外を先に書く
A&Aの考え方
手を打てるかという基準には、例外が要ります。見落としたときの損失が、時間とともに増える事象です。
A&Aの考え方
安全に関わる停止は、その場で手を打てなくても、即時に記録と通知を残す対象になるとA&Aは考えます。法令の届出の期限も同じ扱いにします。金銭が外に出ていく処理も同じです。手を打てるようになるまでの時間が、そのまま損失の大きさになるためです。
A&Aの考え方
この例外は、出典にある条件ではありません。手を打てるかどうかだけで絞ると、気づくのが遅れた分だけ損が増える事象が、日次の束に落ちてしまいます。
出典に基づく事実
AIを開発する米国の会社 Anthropic は、2024年12月19日にエージェントの作り方を開発者向けに解説しています。エージェントは、あらかじめ決めた場所で処理を止めて、人の判断を待てると書かれています。行き詰まったところでも待てるとされています。
出典に基づく事実
同じ解説には、制御を保つために停止条件を置くことが多いとも書かれています。繰り返しの回数に上限を設ける形が、例として挙げられています。ただし同じページには、ここで触れている開発ツールの事情は公開後に変わった、という注記があります。
A&Aの考え方
A&Aは、待つ場所を先に決めるのと同じように、例外も先に列挙しておくものだと読みます。運用が始まってから「これは即時にすべきだった」と足していくと、足した理由が残らず、次の納品に引き継げません。
仮想例
たとえば、返金の処理が二重に走った疑いは、その場で止める手がなくても即時に残す対象になります。1日待てば、二重になった返金の件数はその分だけ増えます。
A&Aの考え方
A&Aが例外を選ぶときに使う問いは、次のとおりです。気づくのが1日遅れたら、損は増えるか。増えるとして、増え方は時間に比例するか。手を打てる人が現れるまでの時間を、こちらで短くできるか。
三段の振り分けは納品前に検収条件へ書く
A&Aの考え方
三段の分け方は、運用に入ってから決めるものではありません。納品前に、検収条件の一部として書きます。書いていないと、見落としが起きたときに誰の持ち分かが決まりません。
A&Aの考え方
A&Aが使う表には、列が5つあります。事象の名前、入れる段、知らせる宛先、即時の行だけに付ける応答の期限、期限を外れたときの扱いです。この5列で、通知の約束が一枚に収まります。
仮想例
たとえば、納品した請求処理のAIなら、こう書きます。外部サービスの応答待ちで失敗した件は、即時の段に入れます。宛先は受託側の当番で、応答の期限は営業時間内で30分とします。
仮想例
利用者が入力を間違えて止まった件は、日次の段に入れます。宛先は顧客の担当者とします。これは仮の例で、実際の期限は顧客の業務時間に合わせて決めます。
出典に基づく事実
先のエージェントの解説は、エージェントが向く用途の条件をいくつか挙げています。成功の条件がはっきりしていることが挙げられています。うまくいったかどうかの結果をエージェントに返して、次の動きに反映できることも条件とされています。意味のある人の監督が入ることも、条件として挙げられています。
A&Aの考え方
A&Aは、この「意味のある人の監督」を、通知の表そのものだと読みます。誰がいつ何を見て、何をするのかが書かれていない監督は、監督の形だけが残ります。
A&Aの考え方
表があると、通知を減らすことと、見落としを許すことが別の話になります。即時の行を減らす提案は、その事象に手が無いことを示す提案です。手があるのに外したいなら、それは見落としを許す提案で、顧客の同意が要ります。
A&Aの考え方
なお、A&Aはこの表の有無と見落としの率の関係を測っていません。これは通知の段をどう決めるかについての設計の話で、効果の予測ではありません。
まとめ
A&Aの考え方
即時に人を呼ぶのは、受け取った人がその場で手を打てる事象だけにします。手を打てない事象は、日次の要約と月次の読み直しという束に落とします。
A&Aの考え方
手を打てなくても損が時間で増える事象は、例外として先に書き出します。この三段と例外を、納品前に検収条件の表として残します。
即時に人を呼ぶ事象は、重大度ではなく、受け取った人がその場で手を打てるかで選びます。手を打てない事象は日次と月次の束に落とし、時間で損が増える事象だけを例外にして、三段の振り分けを納品前の検収条件として残します。
よくある質問
即時の通知を減らすと、見落としが増えませんか。
即時から外した事象も、日次の要約と月次の読み直しで必ず読みます。読む時刻が変わるだけで、記録から消えるわけではありません。消えてよいのは、どの段にも入れる理由がない事象だけです。
顧客が「異常は全部すぐ知らせてほしい」と言う場合はどうしますか。
全部を即時にすると、顧客の側で読まれなくなります。そこで、即時の行に応答の期限を付けて見せます。期限を守れる件数には限りがあると示せば、絞る話が品質の話として通ります。
しきい値の数値は決めなくてよいのですか。
数値は要ります。ただ、先に決めるのは段のほうです。段が決まれば、その事象を即時に出す数値は、手を打てる状態になる水準として決まります。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Supporting the world's most AI-native companies with a 2-person team
Gumloop · 2026-02-17
確認日 2026-10-24 - Building effective agents
Anthropic · 2024-12-19
確認日 2026-10-24