約90本の取り込みを、見に行かずに見張る

この記事は、自社の業務アプリ DataParade Core の事例の一部です。全体は 特設ページ にまとめています。

この記事が満たす要求: 「数字より先に「信じてよいか」」（特設ページ /00 の一覧）

毎晩、約90本の取り込みが動いています。メール、チャット、議事録、会計、カレンダー、体調の記録、取引先のサイトの更新。どれか1本が止まっても、翌朝の台帳は黙って古くなります。

止まっているかどうかを、私は見に行きません。見に行く代わりに、止まったら知らせる側を作りました。何を測って、何を鳴らさないと決めたかを書きます。

数字より先に「信じてよいか」

経営管理の画面の一番上は、金額ではなく「信じてよい」の3文字です。着地の見込みに使う材料が6つあり、全部揃っていて、いちばん古い材料が何日前のものかが添えてあります。材料が欠けていれば「一部が欠けている」、記録が古ければ「数字が古い」と出て、金額はその下です。

きっかけは、経費の取り込みが3か月半止まっていたことに、数字を見ながら気づけなかった経験です。数字は毎朝更新され、盤は緑のままでした。止まっていたのは材料の1つで、その材料が要る数字だけが古かったのです。

「普段の間隔」を測ってから鳴らします

止まっているかどうかを、最初は一律「3日来なければ」で決めていました。これは誤報ばかりでした。毎日届く情報源もあれば、月に1回しか動かないものもあります。

いまは情報源ごとに「普段どれくらい空くか」を実測で持っています。その情報源自身の直近の記録から、普段空く最大の日数を測り、その1.5倍で「要確認」、3倍で「止まっている」とします。学習の範囲を絞らないと何年も前の使い方が混ざるので、直近1年だけを見ます。

緩めたあとには必ず、過去に本当に止まっていた例が今も鳴るかを確かめます。鳴らなくなった検査は、直したのではなく壊したのです。

「来ていない」と「壊れている」は別です

チャットの1つが6日間、0件でした。監視は「取り込みが止まっている」と鳴らしました。実際には、取り込みは毎晩動いていて、相手が黙っていただけでした。

同じ顔で鳴らすと、人はどちらも同じように扱います。そこで、取り込みが動いた記録と、取り込めた件数を分けて持つようにしました。動いていて0件なら「来ていない」。動いた記録が無ければ「壊れている」。鳴らすのは後者だけです。前者は画面に「相手が黙っている」と出るだけで、通知はしません。

ただし、この6日間には別の落とし穴もありました。そのチャットは「今日の分だけ日付が付かない」形式で、目印の形が変わると黙って捨てていたのです。「来ていない」と判断する前に、実物の画面と取り込みの結果を突き合わせる。これは、人がやる確認として残しています。

0件は、平和なのか、壊れているのか

取り込みの結果が0件のとき、それは正常なのか異常なのか。この問いには、情報源ごとに答えが要ります。

休業日のある店の売上が0件なのは正常で、営業日に0件なら異常です。「休んでいる」を知らないと、壊れた日と見分けが付きません。休業の予定を台帳に持ち、0件の判定に使うようにしました。

逆に、0件を「静かな回」として記録しない作りになっていた取り込みもありました。記録が無いと、動いたのか止まったのかが分かりません。0件でも「動いて、0件だった」と残す。これを、同じ形の取り込み全部に適用しました。1日に3回、同じ穴を別の場所で見つけた日があります。

止まっても気づけない21本

取り込みは、動いた記録を台帳に残す決まりです。ところが、決まりができる前に作った取り込みが、記録を残さずに動いていました。数えると21本ありました。記録が無い取り込みは、止まっても誰も気づけません。

全部に記録を付け、記録の無い取り込みが増えないよう、書き込むエンドポイントを持つプログラムは必ず記録の仕組みを通る、という検査を足しました。検査には段階導入のための「まだ通っていない一覧」があり、その残数を毎回出します。減らし忘れないためです。

失敗の理由は、朝に読む人の目で残します

失敗の記録に「_Failed」とだけ残っていて、朝に原因が読めなかったことがありました。

例外の生の文字列は残しません。取引先の本文が混ざることがあるからです。代わりに、プログラムが書いた安全な説明を残します。「終了コード1」「パスワードが無い」「相手が黙っている」。夜の仕事が途中で終わった日は、その説明だけで次の一手が決まります。

ある夜、退役させた1行の結果を読む行が残っていて、毎日の仕事が丸1日「失敗」になりました。1行外すときは、その行が決めた変数を使う行を全部たどる。これは検査にしました。

外の道具が返したエラーを捨てません

取引先のデータ基盤にある集計の定義を、毎朝見に行く監視があります。定義が変わったら知らせるためです。ある朝から失敗し、記録には道具の名前しか残っていませんでした。

道具が返した返事を読むと、「存在しないか、操作できない」でした。前日に、こちらから接続する利用者を絞った権限のものに切り替えていて、その利用者にはその定義を読む権限がありませんでした。定義が消えたのではなく、こちらから見えなくなっただけです。

「存在しない」の返事は、「消えた」ではなく「この利用者から見えない」かもしれない。失敗の前日に何を変えたかを先に見る。そして、道具の返事の中身（符号と文）を記録と通知にそのまま残す。この3つを決めごとにしました。

毎晩3時30分に、全部を流します

監視とは別に、毎晩3時30分に検査を流しています。書き方の型を見る静的チェックが138本（2026年9月時点）、本番のAPIを叩くE2Eテストが291項目、台帳が守るべき決まりが30本。どれかが落ちたら、朝いちばんの通知に出ます。

流す前に台帳のCPUクレジットを見ます。小さな台帳は、試験を連打すると使い切ってAPIが止まります。CPUクレジットが足りない夜は、E2Eテストだけ翌日に送ります。

まとめ

• 数字より先に「信じてよいか」。材料の欠けと古さを金額の上に出す
• 止まったかは、情報源ごとの「普段の間隔」を測ってから決める
• 「来ていない」と「壊れている」は別の顔で出す。0件でも「動いた」は残す
• 失敗の理由は安全な説明で残し、外の道具の返事は捨てない

見に行かなくなった分、朝の通知が「何が止まったか」を言ってくれます。言ってこない朝は、動いています。

自社の業務アプリの全体像は 特設ページ に。次の記事: 手を動かした時間とAIの作業を、同じ時間軸に置く

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。