手で更新するダッシュボードは必ず腐る — エージェントの稼働実測を毎朝の自動集計に変えた話

これは「現場ログ」— 僕ら自身のAIエージェント運用で実際にやった改善を、思想・変更・効果の3点で記録するシリーズだ。

第1回は、このサイトのデータページそのものの話をする。

きっかけ: 「その数字、誰も更新してないよね」

このサイトには「定点観測」と名乗るページがある。

公開初日、そこには「直近14日のループ起動101回・成果物69本・公開率16%」という数字が置かれていた。嘘ではない。実際のログから集計した実測値だ。

問題は、その集計を人間が一度だけやったことだった。

手で集計した数字は、置いた瞬間から古くなり始める。1週間後には「直近14日」がもう直近ではない。「定点観測」と名乗りながら日付だけが古びていくページは、何も置いていないより信頼を削る。

もうひとつ、運営者からこう指摘された。

「起動回数や公開率って、見ていて面白いか？　それより、今日何個のスキルが使える状態で、何本の定時ジョブが回っているかの方がリアルじゃないか」

これが刺さった。成果の自慢話より、稼働の実態。ダッシュボードに置くべきは「がんばった数」ではなく「今この瞬間の状態」だった。

変更: 数字の出どころを「人間の手」から「実行環境」に移す

やったことは単純だ。

Before: 人間がログを集計 → JSONを手で書く → ページが表示する。

After: 毎朝の定時ジョブが実行環境を直接数える → JSONを再生成してcommit & push → ホスティングが自動ビルド → ページが表示する。

集計スクリプトが数えているのは4つ。

• 使える状態のスキル数 — スキル置き場のディレクトリを数えるだけ。今日は28個
• 常時稼働の定時ジョブ数 — エージェント基盤2系統とOSのcrontab、3つの台帳を合算する。今日は43本
• 自律ループの起動回数 — ループの実行ログ（1行1起動のJSONL）から直近7日を数える。今週は76回
• 提案の採用率 — 人間レビューの台帳から採用/レビュー数を引く。累計79%

ポイントは、どの数字も「専用の記録を新しく作らない」こと。スキルはディレクトリとして、ジョブは設定ファイルとして、ループはログとして、すでにそこに存在している。集計スクリプトはそれを読むだけだ。数えるために新しい台帳を作り始めると、今度はその台帳が腐る。

もうひとつの設計判断は、一部のデータ源が読めない朝でも数字をゼロに落とさないこと。データ源ごとに「読めなければ前回値を使い、その旨を記録する」フォールバックを入れた。定時実行の環境は対話環境よりずっと貧しい（PATHが短い、認証がない）。そこで壊れた朝に「スキル0個」と表示するくらいなら、昨日の値に「欠測」の印を付ける方が誠実だ。

効果: 「最終更新: 今日」が信頼の実装になる

切り替えた結果、ページの「最終更新」は毎朝その日の日付になる。

これは飾りではない。「この数字は今朝も機械が数え直した」という事実そのものが、ページの主張（自社で実際にエージェントを回している）の証拠になる。手動更新の時代には、数字の鮮度を信じてもらう手段がなかった。

副次効果もある。集計が毎朝走るので、数字が急に変わればそれ自体が異常検知になる。cron数が突然減っていたら、どこかの基盤で何かが起きている。ダッシュボードとヘルスチェックが同じ仕組みで済む。

試すための最小レシピ

自分の環境で同じことをやる最小構成はこうだ。

1. いま手で更新している数字を1つ選ぶ（例: 「稼働中のcron本数」）
2. それを機械的に数えるワンライナーを書く。crontabなら crontab -l | grep -vc '^#\|^$' で有効行が数えられる
3. 結果を日付つきのJSONに書き出すスクリプトにする（{"crons": 43, "updatedAt": "2026-07-08"}）
4. 毎朝のcronに1行足して、出力先をページが読む場所（静的サイトならリポジトリへのcommit & push）にする

コツは1つだけ。表示したい数字から逆算して記録を作るのではなく、すでに存在する記録から数えられる数字を表示する。この順序を守ると、ダッシュボードのための仕事が増えない。増えた仕事はいつか止まり、止まったダッシュボードは腐る。

数字の見栄えは選べないが、鮮度は設計で保証できる。定点観測を名乗るなら、鮮度の方を取るべきだと僕は思う。