『定期実行にすれば直る』は直らなかった。AIの自動化の提案を承認する前に、中身を開く

課題

自分には、複数の事業をまとめて見ている別の作業の場がある。ブログとは別に、事業ごとに作業の場が分かれていて、それらを横断して眺めるための場所。

そこに、いくつかのデータ源の中身を1画面に並べるダッシュボード（管理画面）を、AIと一緒に作った。2026年10月4日のこと。

6日後の10月10日、データ源ごとに「いつの中身か」を数えてみると、5つのうち3つが古いままになっていた。

こういうとき、「取り込みを定期的に自動で走らせればいい」と考えたくなる。実際、AIもそう提案して、自分も承認した。

ところが、取り込みのScript（決まった処理をまとめた小さなプログラム）を開いてみたら、その提案は成り立たなかった。

解決できるようにすること

AIと一緒に、自分用のダッシュボードや管理画面を作っている人が、次の3つを自分でできるようにする。

1. 取り込みの自動化を提案する前、または承認する前に、今ある取り込みの中身を開いて、定期実行で何が変わるかを確かめる
2. データの古さを、「実行した時刻」ではなく「中身がいつの時点か」で測る形にする
3. わざと古いデータを足すことと、実際のデータの更新の両方で、古さの表示が正しく動くかを確かめる

先に結論

• 古くなっていたデータ源のうち2つは、Scriptで入れていた。AIは、この2つは手でScriptを再実行して取り込んでいる、と説明し、取り込みの自動化を提案した。自分はそれを承認した
• 承認のあとで開くと、Scriptは元の記録を読んでいなかった。値はScriptの中に直接書かれていて、冒頭には「元の記録が変わったら、この値を書き換えてから手で再実行する」という趣旨の注意書きがあった。定期で走らせても、10月4日の同じ値を書き直すだけになる
• このScriptは、6日前にダッシュボードを作ったとき、AIが書いたものだった。記録には「承認を求める前にScriptを開けば分かった」と残っている
• 取り込みの自動化はやめて、「中身がいつの時点か」を画面に出し、古いことが見える形にした
• 作る途中で、実行した時刻を古さの基準にすると、走らせ直しただけで新しく見えることに気づいた。中身の時点を別の値として持たせ、古さはそちらで判定するようにした
• 60日前の合成した行を足すと、知らせが出て行が強調された。同じ日に、別の作業の場の予定のデータが更新されて件数が34件から38件になったときも、中身の時点は向こうが更新した時点へ動き、実行した時刻とは別に残った

この記事でわかること

• 「定期で走らせれば直る」が成り立たない取り込みの見分け方
• 自動化を提案・承認する前に、今ある取り込みの何を開いて見るか
• 古さを「実行した時刻」で測ると、なぜ間違えるのか（図あり）
• 古さの表示を、合成したデータと実際のデータの2通りで確かめた方法

こう思う人もいるかもしれない。

「データが古いなら、取り込みを定期実行にすれば片付くのでは？」

今回は片付かなかった。取り込みのScriptが、元の記録を読み直す作りになっていなかったから。定期実行は「同じ処理を決まった時間に走らせる」だけで、その処理が何を読んでいるかは変えてくれない。走らせる回数を増やす前に、走らせている中身を開く必要があった。

5つのうち3つが、古いままだった

10月4日にダッシュボードを作ったとき、いくつか「しばらく使ってみてから確かめる」ことを残していた。

取り込みを自動にするかどうかも、そのひとつ。この時点では「使ってみてから決める」として見送っていた。そのとき記録に書いた一番の心配は、手間ではなく「ダッシュボードが古い数字を黙って表示すること」だった。

10月10日、その確かめと同じ日に、データ源ごとの中身の時点も数えた。

• 5つのデータ源のうち、3つが古いままだった
• そのうち2つは、10月4日に入れた値のままだった。この2つが、Scriptで入れていたもの
• 新しかった2つのうち、1つは自動で記録される仕組みだった
• もう1つ（別の作業の場の予定のデータ）は、取り込みは手作業。ただ、向こうが「更新した」と知らせてくるので、そのつど取り込まれていた

記録には、こうまとめてある。差は「自動かどうか」ではなく、「誰かが気づけるかどうか」だった。

手作業でも、知らせが来るものは新しいまま。知らせが来ないものは、誰も気づかないまま古くなる。ここ、地味に大事なところだと思う。

AIが自動化を提案し、自分が承認した

古かった2つについて、AIは自分に、手でScriptを再実行して取り込んでいる、と説明した。そのうえで、古さを画面に出すことと、取り込みを自動で走らせることを提案した。

自分は、その案を承認した。

説明どおりなら筋は通っている。再実行で取り込めるなら、その再実行を定期にすれば、元の記録の変更が自動で入るはず。

ただ、この時点では、AIはScriptの中身を開いていなかった。記録には「Scriptの中身を読まずに仕組みを説明した」とある。

承認のあとでScriptを開いたら、成り立たなかった

取りかかってScriptを開くと、説明とは違う作りだった。

• Scriptは、元の記録（Markdownで書いたメモ）を読んでいなかった
• データは、Scriptの中に配列（値を並べたもの）として直接書かれていた
• 冒頭には「元の記録が変わったら、下の配列を書き換えてから、手で再実行する」という趣旨の注意書きがあった

つまり、「手で再実行」の前に「手で値を書き換える」が要る作りだった。定期で走らせても、10月4日の同じ値を何度も書き直すだけになる。

しかもこのScriptは、6日前にダッシュボードを作ったとき、AIが書いたものだった。冒頭の注意書きも、そのときからある。

自分たちで作ったものでも、6日たつと、中身と説明がずれることがある。説明を聞いて承認する側としては、「それ、開いて確かめた説明？」と一度聞けばよかったのかもしれない（ここは記録をもとにした、あとからの整理）。

記録には、AI自身の振り返りとして「承認を求める前に、Scriptを開けば分かった」と残っている。抜けていたのは、提案の前に今ある仕組みの中身を開く、という手順だったことになる（ここもAIと整理した見立て）。

自動化をやめて、古いことが見えるようにした

そこで方針を変えた。

• やめたこと: 取り込みの自動化
• 残したこと: 古さを画面に出して、古いことが見えるようにする

記録には、この方針の考え方も書いてある。防ぐのではなく、気づけるようにする。自動化だけだと、取り込みが失敗したときに、画面は静かに古いままになるから。

もう1つ、画面には古いときの「直し方」も出すことにした。古いときにやることが、データ源によって違うから。

• 取り込み直せば直るもの（元の記録を読んで取り込むもの）
• 元の値を書き換えないと直らないもの（今回のScriptのように、値を中に持っているもの）

前者は走らせ直せばいい。後者は、走らせ直しても直らない。ここを画面で分けておけば、古いと出たときに迷わずに済む。

実行した時刻で測ると、走らせ直しただけで新しく見える

作る途中で、もう1つ間違いがあった。

最初は、Scriptを走らせた時刻だけを記録して、それを古さの基準にした。すると、Scriptを走らせ直しただけで「今日」になり、中身は10月4日のままなのに新しく見えた。

手で値を持っているデータで意味があるのは、「いつ走らせたか」ではなく「中身をいつ書き換えたか」。そこで、次のように直した。

• 中身の時点を、実行した時刻とは別の値として持つ
• 古いかどうかの判定は、中身の時点で行う
• 値を中に持っているScriptには、中身の時点を書く場所を置き、値を書き換えたらそこも更新する

複数の元から集めるデータは、いちばん古い元の時点を、全体の中身の時点にした。1つでも古ければ、全体として古いとみなす考え方になる。

この間違いは、AIが実装して動かした直後に、数字がおかしいと気づいて直している。

2つのやり方で、古さの表示を確かめた

作ったあと、AIが画面の表示を確かめた。

まず、今あるデータでは、10月4日の値のものは「6日前」、予定のデータは「今日」と出た。

わざと古い行を足した

中身の時点が60日前の行を、合成して足した。

• 「古くなっています」という知らせが出た
• その行が強調された
• ★の印も付いた（背景の色だけに頼らない作り）

確かめたあと、合成した行は消している。

実際のデータで、中身の時点が動くかを見た

同じ日、別の作業の場が予定のデータを更新した。AIがそれを取り込むと、件数は34件から38件になった。

• 中身の時点は、向こうがデータを更新した時点へ動いた
• 実行した時刻は、それとは別の値として記録された

中身の時点と実行した時刻が、ちゃんと別々に残っている。合成したデータでは作った直後に確かめていたけれど、実際のデータで動くのを確かめたのは、これが初めてだった。

見張りの前に今あるものを読む、の続きとして

以前に、WordPressの見張りを作る前に、今ある自動更新を確かめた話を書いた。そのときは、新しい仕組みを足す前に今あるものを読み、穴を既存の設定で埋めた。

今回も、核は同じ。新しい自動化を作る前に、今ある仕組みの中身を読む。ただ、違うところが2つある。

• 読んだのが、承認の後だった: 前回は作る前に読んだ。今回は、提案して承認をもらってから開いた。先に開いていれば、成り立たない案に承認を出すことは無かった
• 結果として、古さを知らせる表示は作った: 前回は新しい仕組みを作らなかった。今回は、取り込みの自動化はやめたものの、古さを画面に出す表示は作っている。見張りの一種とも言える

読んだ結果、作らないこともあれば、作るものが変わることもある。今回は後者だった（ここはAIと整理した見立て）。

確かめられていないこと

• 古いと出たあと、実際に直されるか: 古さが見えるようになっただけで、直すのは人。知らせが来ないデータ源は、表示を見た誰かが動かない限り古いまま
• 元の記録を読み取る取り込み: 古かったデータ源の1つは、元の記録の表を読み取って取り込む形にできるとしているが、まだ作っていない。もう1つは、機械で読める元の記録がそもそも無く、手で値を持つしかない
• 何日たったら「古い」とするか: 線の引き方は、この記事では扱っていない。6日前のものが「古い」と知らされたかどうかも、記録からは読み取れていない
• 承認の前に開く、を決まりにしたか: この件のあと、手順として何かを足したかは、今回読んだ記録の範囲には無い

チェックリスト

自動化を提案する前、承認する前

1. 自動にしたい処理の中身を開く。Scriptなら冒頭の注意書きと、データをどこから読んでいるか
2. 元の記録を読み直す作りか、値を中に持っている作りかを確かめる
3. 「定期で走らせたら、何が変わるか」を一文で言えるか確かめる。言えなければ、まだ開き足りていない
4. AIの説明が、開いて確かめたものか、覚えている内容かを聞く。自分たちで作ったものでも、日がたつと説明がずれることがある

古さを画面に出すなら

5. 中身の時点と、実行した時刻を別の値で持つ
6. 古いかどうかは、中身の時点で判定する
7. 古いときの直し方を添える。取り込み直せば直るものと、元の値を書き換えないと直らないもの
8. 複数の元から集めるなら、いちばん古い元の時点を全体の時点にする
9. 色だけに頼らず、印でも分かるようにする

作ったあと

10. わざと古い行を足して、知らせと強調が出るかを見る。見たあとは消す
11. 元のデータが実際に更新されたとき、中身の時点が動くか、実行した時刻と別に残るかを見る

こんな人に向いている

AIと一緒に、自分用のダッシュボードや管理画面を作っている人に向いている。特に、いくつかのデータを手作業も交えて取り込んでいて、「古くなってきたから自動にしよう」と考え始めた人。AIの提案に承認を出す立場の人にも、承認の前に何を聞くかの手がかりになると思う。

まとめ

ダッシュボードのデータ源が5つのうち3つ古くなり、AIが取り込みの自動化を提案して、自分が承認した。承認のあとでScriptを開くと、値は中に直接書かれていて、定期で走らせても同じ値を書き直すだけだった。自動化はやめて、中身がいつの時点かを画面に出す形に変えた。作る途中で、実行した時刻を基準にすると走らせ直しだけで新しく見えると気づき、中身の時点を別に持たせた。合成した古い行と、実際のデータの更新（34件→38件）で、表示が正しく動くことを確かめた。

項目	内容
結論	取り込みのScriptは値を中に持っていて、定期実行では直らなかった。自動化をやめ、中身の時点で古さを見せる形にした
教訓	自動化を提案・承認する前に、今ある仕組みの中身を開く。古さは、実行した時刻ではなく中身の時点で測る
対象読者	AIと一緒に、自分用のダッシュボードや管理画面を作って運用している個人開発者

同じ状況に陥ったときの回避策

• 自動化の提案を受けたら、承認の前に「その処理の中身を開いて確かめた？」と聞く
• 取り込みが元の記録を読み直しているか、値を中に持っているかを先に見る
• 古さの基準に、実行した時刻を使わない。中身の時点を別に持つ
• 古いときの直し方を、データ源ごとに画面に添える
• 合成した古いデータと、実際のデータの更新の両方で、表示を確かめる

次に読むなら

• WordPressの見張りを作る前に、今ある自動更新を確かめた。本体は自動、プラグインとテーマは全部オフだった — 同じ「新しい仕組みを足す前に、今あるものを読む」を、作る前にやった例。今ある自動更新の範囲を読み、穴を既存の設定で埋めて、実際に動いたかまで確かめた手順を書いている

---

この記事は、筆者が個人で複数の事業をまとめて見ている作業の場の記録（2026年10月4日〜10月10日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。