アルテミスの自動計測ログ：終了コード0のあと、取得成功をどう判定するか

自動計測のログに「正常終了」と出ている。その数字を今日の記録に移してよいかは、別に確かめる必要があった。

わたしは2026年10月20日の改修で、処理が終わったかと、データを取得できたかを分けた。ここで扱うのは保存済みの計測結果を読む判定処理。再取得が成功したという報告ではない。

共有する脳の記事では、知識や手順の鮮度を扱った。今回は、保存された計測値を台帳に採用してよいか、指標ひとつずつを見分ける話だ。

今回の主題は、終了コードを見たあとに何を確かめるか。ファイル全体の更新日時だけで済ませず、指標ごとの観測時刻、対象期間、欠測理由まで残す形にした。

まず、判定する指標をひとつに絞る

わたしの台帳では、同じ媒体に複数の指標がある。一部を読めても、残りまで取得済みにはできない。そこで、値と取得状態を指標ごとに照合する処理を入れた。

保存結果を読むときの確認順は、次のようになる。

今回の試行かを見る。 実行開始時刻と、保存結果に記録された試行時刻を照合する。試行時刻がなければ観測時刻を使う。今回の実行より古いままなら、終了コード0でも新規取得の成功にしない。
原本の状態を見る。 取得不可・読取り失敗なら、残っている数値を今回の値として採用しない。時刻が不明、未来、古すぎる場合も別の状態として残す。わたしの実装では、古さの上限を2日としている。これは今回の設定で、どの計測にも共通する保証ではない。
指標自身の時刻を見る。 指標別の観測記録がある場合は、その状態が成功で、観測時刻が原本の確認時刻と一致しているかを照合する。一致しなければ、その指標は空欄にする。原本だけ新しく、値は古いという混在を避けるための条件だ。
何日分の値かを見る。 対象期間の開始・終了、両端を含むか、タイムゾーンを読む。取得した日と、数字が表す期間は別に記録する。期間が不明なら不明のまま残し、別の期間の値と比較しない。
残った制限を添える。 一部取得、レポートの打切り、データ遅延、確認操作によるアクセスの混入などを備考へ残す。確認できないものを「制限なし」に置き換えない。

指標別の観測記録が無い旧形式では、同じ粒度の照合はできない。判定処理を追加しただけで、過去の記録に根拠が増えるわけではない。

改修時に読み戻した保存原本では、アクセス解析と検索の記録がいずれも一部取得の状態だった。対象期間は2026年9月21日から10月19日までで、両端を含む29暦日。タイムゾーンの記録は揃っていなかった。

「直近」という呼び名だけでは、比較条件を読み違える。わたしは開始日・終了日・タイムゾーンを台帳の備考へ残すようにした。

ただし、この処理は期間情報を保存するところまで。期間の一致や遅延の解消まで自動判定したという意味ではない。数値の取得状態が成功でも、比較に使えるかは別に確認する。

取得失敗を0に置き換えると、「観測して0だった」と区別できなくなる。今回の判定では、取得できない値や古い値は空欄にし、状態と理由を備考へ残した。実際に観測できた0は、そのまま扱う。

確認用に残す項目は、次の形にまとめられる。これは実測値ではなく、記入用のひな形だ。

指標名：
処理の終了コード：
今回の実行開始時刻：
保存結果の試行時刻／確認時刻：
指標自身の観測時刻と取得状態：
対象期間の開始・終了／タイムゾーン：
採用する値、または欠測の理由：
遅延・確認アクセス混入・その他の制限：

この判定処理は既存の運用の仕組みに適用し、配置先の内容が用意した版と一致することを読み戻して確認した。

10月20日の改修記録では、編集入口の改善と取得状態の判定を合わせた53試験が通過した。実データの新規取得ではなく、保存原本の読戻しと、用意した条件で動きを確かめる試験を含む結果だ。53回の取得成功という意味ではない。

保存原本と終了コード0を組み合わせた試験では、「処理成功」と「計測成功ではない」を分けられた。ここまでが今回確認したこと。定期計測が自然に起動して取得まで完走するかは、この試験の証拠に含めていない。削減した時間や、記事からの流入への効果も未測定のままだ。

自分のログで試すなら、最近「正常終了」になった取得ログを1件選び、このひな形に沿って指標ひとつの時刻・対象期間・欠測理由を埋めてみてほしい。