「一覧が古い」と AI に言うだけで原因まで戻れる── 目に見えた古さを直し方を混ぜずに書けば、AI は表示ではなく写しの持ち方という原因に戻り、連動する仕組みまで作れる

01「一覧が古い」という一言から、AI は写しの構造まで戻った

2026 年 9 月、運営者はサイトのトップに並ぶ「直近 10 回」のニュースの一覧が、実際の更新に追いついていないことに気づいた。伝えたのは症状だけである。どこを直せ、とは書いていない。

AI が返したのは、表示の話ではなかった。その一覧は、ページを開くたびに読み込まれるものではなく、サイトの全ページの中に同じ内容が写しとして書き込まれていた。ニュースを作る処理は毎日動いていたが、その写しを書き替える処理は自動の予定表に登録されておらず、手で動かすしかなかった。だから数日前から止まっていた。

読者が見た古さは、遅れではなく、同じ情報が何重にも写されている作りから来ていた。この回で取り出す型は一つである。症状を正確に言えば、AI は原因の層まで戻れる。ただし戻らせるには、直すことと、原因を言うことと、二度起きない仕組みを作ることを、別々に頼む必要がある。

02古い表示の多くは、同じ内容が二か所以上にある印である

情報が古く見える原因は、大きく二つに分かれる。一つは伝わるのが遅いだけで、待てば直るもの。もう一つは、同じ内容の写しが別の場所にあり、片方だけが新しくなっているものである。

後者は待っても直らない。写しを書き替える手が動かない限り、古い側は古いままである。今回の一覧は後者だった。

ここが、使う人が押さえておく分かれ目になる。「更新されない」と感じたとき、それが待てば直る話なのか、写しが取り残されている話なのかを、AI に判別させる。判別の言葉は難しくない。元の情報はもう新しくなっているか、と尋ねればよい。

03写しは静かに古くなり、気づくのはいつも読者のほうである

写しが取り残されても、画面は壊れない。文字は整っているし、日付も並んでいる。ただ、中身だけが古い。

この静かさが厄介である。壊れたものは自分で知らせてくれるが、古いものは何も知らせない。今回も、気づいたのは運営者が自分のサイトを読んだときだった。仕組みの側からは何の合図も出ていない。

だから、古さは早く見つかるほど得になる。そして早く見つけるには、誰かの目に頼るのをやめて、更新のたびに写しが連動する形に変えるしかない。

04正しい置き場を一つに決め、残りはそこを指す形にする

ソフトウェアの世界では、同じ内容を二度書かないという考え方が古くから知られている。Hunt と Thomas は『The Pragmatic Programmer』で、ある知識は一つの、曖昧でない、権威のある形で置かれるべきだと書いた。データの側では、一つの要素を編集できる場所を一か所に限る作りを「単一の正しい置き場」と呼ぶ。理想は写しを作らず、参照だけを置くことである。

ただし現実は、写しをすべて消せない。表示を速くするために写しを持つことは、どの現場でも行われている。だから境界を引く。写しを持つなら、書き替えられるのは元の一か所だけにし、写しは読むだけにする。そして、元が変わったら写しも必ず作り直す手順を、人の記憶ではなく仕組みの側に置く。

05資材の改訂で起きるずれも、写しの数だけ起きる

この形は、資材審査の現場では毎日起きている。添付文書が改訂される。用法の一文が変わる。その一文は、説明資材、スライド、比較の表、社内の想定問答、案内の冊子に、それぞれ写しとして入っている。

元が新しくなっても、写しは自分で変わらない。だから改訂のたびに、どの資材にその一文が入っているかを数え、全部を追う作業が生まれる。追い切れなかった一つが、承認された内容と違う資材として残る。

ここで効くのは、審査の腕ではなく持ち方である。改訂されうる記載を、資材ごとに書き写すのをやめ、どの資材が元のどの記載を使っているかを一覧にしておく。そうすれば、改訂の連絡が来たときに追う先が機械的に決まる。AI に頼めるのはこの一覧の作成と、改訂前後の記載の突き合わせである。判断は人が持つ。

06止まっていたのは作る処理ではなく、配る処理だった

原因をもう一段下げる。今回、毎日の記事を作る処理は動いていた。止まっていたのは、作った結果を全ページの一覧に配る処理である。二つは別の処理で、自動の予定表に入っていたのは前者だけだった。

Unix 系の計算機では、時刻で処理を起こす仕組みを cron と呼び、動かす処理は表に一行ずつ書いて登録する。表に書かれていない処理は、どれほど重要でも、決して自分では動かない。今回の穴はここにあった。

この種の穴は、作る側と配る側が別々に足されたときに生まれる。最初に一覧を埋め込んだ時点では、一覧は手で作り直すもので足りていた。後で記事の生成が自動になったとき、配る側を一緒に自動へ移す作業が抜けた。誰も間違った判断をしていない。それでも穴は空く。

AI の返答には、もう一つ見ておくべき点があった。AI は、一覧が最新になったことと、生成の処理が空の環境でも正しく動くことは自分で動かして確かめたと書き、決まった時刻に二つの処理が続けて走るところは確かめていないと書いた。外の仕組みを呼ぶ日次の処理を自分の判断で動かすのは避けた、という理由も添えてあった。確かめたことと、そうなるはずのことを、AI に分けて書かせる。これは仕組みの穴を扱うときの守りになる。

07明日からは、症状・原因・再発防止・未確認の四つを分けて頼む

手順は四つある。

Anthropic は Claude Code の手引きで、不具合を渡すときは症状、見当のつく場所、直った状態を示すこと、そして症状を抑え込むのではなく原因に当たることを勧めている。同じ手引きは、作業が終わったと見なす前に、モデル自身が走らせられる確かめ方を与えることも勧めている。今回の一覧のように読者の目でしか気づけないものは、まさにその確かめ方を作るべき対象である。