あなたに残る仕事は、監視だけになる。
前回、ステップ4の風景を見た。ループがClaudeを起動し、あなたは意図で舵を取る。ただし、舵を取るという言葉は、何もしなくていいという意味ではない。
数百から数千のエージェントが動く場所では、あなたに残された仕事はただ一つ、監視だ。ここでいう監視は、全部の出力を目で追うことではない。目で追うことは、数の桁が変わった瞬間に不可能になる。物理的に無理な話を、気合いで乗り切ろうとする必要はない。
必要なのは、全部見ないための仕組みを先に設計することだ。何を異常として拾い上げ、誰にどう届けるか。これを決めずに規模だけ増やすと、ステップ4は静かな事故が同時多発する場所になる。
なぜ「全部見る」が破綻するのか
「全部見る」は、規模が変わった瞬間に破綻する。第10回で扱った「許可疲れ」を覚えているだろうか。10回目の承認では、もう本当にはレビューしていない。ただクリックしているだけになる、という話だった。
数百〜数千体の規模では、この構造がそのまま、しかも桁違いに立ち上がる。
視点
承認疲れとアラーム疲れは同じ構造
第10回 許可を設計するで見た「10回目の承認はもう見ていない」という話と、ここで扱う監視の話は、同じ現象の別の規模に過ぎない。人間の注意力には上限があり、その上限を超えた瞬間、チェックは形だけのものになる。対処法も同じだ。注意力に頼るのをやめて、仕組みに変える。
監視の現場に学ぶ
この構造に、運用監視の現場はとっくに答えを持っている。アラームは、閾値でできている。
サーバー監視ダッシュボードや工場の設備監視盤は、CPU使用率も稼働温度も、24時間ずっと数値を出し続けている。だが、担当者はその数値を四六時中見つめているわけではない。ダッシュボードには閾値が設定されていて、その範囲を外れたときだけアラームが鳴る。見ているのは数値そのものではなく、閾値という境界線だ。
そしてこの仕組みには、よく知られた弱点がある。アラーム疲れだ。閾値が甘すぎれば何も鳴らず、厳しすぎれば鳴りすぎて、現場は次第にアラームを聞き流すようになる。鳴りすぎたアラームは、本当に危険な1件を、他の99件のノイズに埋もれさせる。
エージェントの監視も、まったく同じ罠を持っている。通知が多すぎれば無視され、少なすぎれば見逃す。閾値の設計は、飾りではなく、監視の成否そのものを決める。
異常とは何か
「異常」を定義する前に、まず何を測るかを決めておく必要がある。ここで使えるのが、第7回で作った検証ループだ。
視点
検証ループが監視の土台になる
テスト、ビルド、スクリーンショット比較。第7回で「あなた自身が検証ループにならないため」に作ったこの仕組みは、ステップ4ではそのまま自動化された感知器になる。検証ループがない仕事には、そもそも「何を異常とするか」の判定材料がない。監視は、検証の上にしか積み上がらない。
そのうえで、異常には段階をつける。すべてを同じ重みで扱うと、結局また「全部見る」に逆戻りする。
視点
検証はデーモンに一本化する
Anthropicが公開した大規模コード移行の事例でも、似た発想が使われていたと紹介されている。多数の修正エージェントがそれぞれパッチを書き進める一方、実際にビルドを実行する権限を持つのは1つのビルドデーモンだけに絞られていたという。デーモンは届いたパッチをまとめてバッチ化し、一度だけ再ビルドして、影響を受けたテストだけを再実行し、結果を修正エージェント側へ返す。全員が好きなタイミングで再ビルドを走らせていたら、結果同士が競合し、何が原因で何が壊れたのか誰も追えなくなる。収集の窓口を1つに絞ることは、規模が大きくなるほど利いてくる。
一般的な監視の運用でも、異常の逸脱度に応じて「記録のみ」「担当者へ通知」「即時対応」と対応を変える考え方があり、この3段階は同じ発想でできている。段階を分けることは、手抜きではなく設計だ。
この段階分けが機能するのは、実際のデータの形とも合っている。Anthropicが自社のClaude Code利用状況を分析した自律性の実測調査によると、エージェントが自律的に作業を続けて停止するまでの時間（ターン継続時間）は、中央値では2025年10月から2026年1月まで約45秒（40〜55秒のレンジ）で安定していた一方、99.9パーセンタイルは25分未満からほぼ倍増して45分超へと伸びていたという。大半のタスクは短く安定して終わり、伸びているのはごく一部の長時間タスクだけだ。全部を均等に見張る必要がないというこの回の前提は、思い込みではなく、実測が示す構造でもある。
通知の設計は、まず「疑う」を仕組みに埋め込む
アラームが鳴ったら、まずモデルではなく自分が設計した仕組みを疑う。
“When Claude makes mistakes, debug your workflow, not the model.”
筆者訳Claudeが間違えたときは、モデルではなくワークフローをデバッグせよ。
閾値が悪いのか、通知の経路が詰まっているのか、そもそも測っている指標がずれているのか。ここを取り違えると、原因不明のまま閾値をさらに甘くする、という悪循環に入る。
注意
よくある誤解と罠
- 閾値を甘くしすぎる。何も引っかからない静けさを、うまくいっている証拠だと錯覚する
- 閾値を厳しくしすぎる。結局アラーム疲れを起こし、全部見る状態に逆戻りする
- 通知だけ作って、受け取る側を決めていない。重大アラームが鳴っても、誰が対応するかのエスカレーション経路が空欄のままでは、鳴らしていないのと同じ
Cat Wuは、この先の変化についてこう述べている。
“the next step is that Claude understands what you work on, and just sets up some of these automations for you.”
筆者訳次の段階は、Claudeがあなたの仕事を理解し、こうした自動化の一部を勝手に用意してくれるようになることだ。
監視の仕組みそのものすら、いずれClaudeが提案するようになるかもしれない。それでも、何を異常とみなすかという最初の判断基準は、当分のあいだ人間が持ち込むしかない。次の終章で扱うのは、まさにこの「人間に最後まで残るもの」の話だ。
今日のまとめ
- 数百体規模では「全部見る」は物理的に不可能。全部見ないための仕組みを先に設計する
- アラームは閾値でできていて、甘すぎても厳しすぎても機能しない。アラート疲れと同じ罠がここにもある
- 異常が起きたら、まずモデルではなく自分が設計したワークフローを疑う
明日のアクション
第19回で書き出した3つのタスクのうち1つを選んでください。
そのタスクについて、「情報」「警告」「重大」の3段階でアラームの閾値を設計してください。それぞれ、何を基準に段階を分けるか、誰にどの手段（ログ・非同期通知・即時連絡）で届けるかまで決めてください。
閾値が決まらないタスクは、まだ監視を任せられる状態ではありません。
次は、この5段階の旅を締めくくる終章です。人間に最後まで残るものは何かを、正面から見ます。