AIとの対話ログが消えると、保存済みの稼働時間が小さい値で上書きされた

本記事の概要

AIとの開発で作業した時間と休んだ時間を数値にする、自作のデスクトップツールの記録です。このツールを可視化ツールと呼びます。可視化ツールは、AIとの対話の記録とGitHubのコミットの履歴を読み、日ごとの値を、日ごとの表に保存します。対話の記録は、既定の設定では、30日ほどで古いものから消えます。記録の一部が消えた後に取り込むと、可視化ツールは、保存済みの値より小さい値を計算する場合があります。

可視化ツールは、時刻を5分ごとに区切った区間の単位で、時間を数えます。この区間を時間枠と呼びます。可視化ツールは、時間枠を取り込みの処理の中だけで使い、保存しません。活動の時間は、人とAIが一緒に作業している時間として、可視化ツールが数える時間です。定時のジョブのような自動の処理が起こしたと、可視化ツールが分類した対話のセッションを、自動のセッションと呼びます。自動の時間は、自動のセッションの時間のうち、活動の時間と重ならない時間です。

日ごとの表を修正したAIエージェントは、2026-08-03に、日ごとの表の上書きの判定を2度修正しました。上書きの判定は、今回の取り込みの値で保存済みの値を上書きするかを決める条件です。1度目の修正の直前の版では、自動の時間を上書きするかも、活動の時間の比較で決まっていました。この比較は、今回の活動の時間が、保存済みの活動の時間以上かを調べます。人の活動が無く、自動のセッションだけが動いた日は、今回の活動の時間と保存済みの活動の時間が、どちらも0になります。0は0以上なので、比較が必ず通りました。1度目の修正のコミットの記録によると、保存済みの自動の時間は、不完全な取り込みで計算した小さい値で、上書きされていました。本物のデータで上書きが起きた日と回数は、記録にありません。日ごとの表を修正したAIエージェントは、1度目の修正で、自動の時間の列と人の発言の時間の列を、それぞれの列の保存済みの値と比べる形に変えました。2度目の欠陥では、列ごとに保存済みの値と比べたために、別々の取り込みで計算した値が1つの行に混ざりました。2度目の修正は1度目の修正の11分後です。

最後の版は、活動の時間と自動の時間の合計を、行ごとに1回だけ比べます。今回の合計が保存済みの合計以上の場合にだけ、時間枠から計算する列をまとめて上書きします。件数の列は毎回上書きします。最後の版でも、取り込み元の記録が欠けた場合と、対話のセッションの分類が変わった場合を区別できません。仕様の文書には、この判定に残る近似が3つ書いてあります。近似は、判定が正しくない値を残す場面があると分かっていて、仕様に書いて受け入れた場面です。

本文では、最初に、保存済みの値を上書きする判定が必要な理由と、判定の最後の形を説明します。次に、上書きの判定の5つの版と、敵対的なレビューで採用しなかった3つの候補を、表で比べます。続けて、SQLiteのUPSERTで、件数の列だけを毎回上書きする書き方を、実行したコード例で示します。そのうえで、自動のセッションだけの日に、自動の時間が減った1度目の欠陥を説明します。さらに、別々の取り込みの値が1つの行に混ざった2度目の欠陥を説明します。その後に、時刻を保存しない設計で残る3つの近似を説明します。最後に、修正の前の実装で落ちるテストと、保存済みの値を失わないための4つの規則を書きます。

記事から得られること

取り込み元の記録が消えていく集計で、保存済みの値を守る仕組みを作っている方に向けた記事です。次の4つが分かります。

• 保存済みの値を上書きしてよいかを決める判定の5つの版と、版ごとに判定を変えた理由
• 比較の両辺がどちらも初期値になる入力で、判定が必ず通る仕組み
• SQLiteのUPSERTで、一部の列だけに保存済みの値を残す書き方
• 修正の前の実装で落ちるテストを先に確かめる進め方と、外部の資料にある、この進め方の呼び名と、テストの呼び名

この記事は、自作のツールを開発した記録に基づく、設計の考察です。