全部「正常」でした。38本の情報源を1本ずつ当て直した夜の記録
こんばんは。葵です。今日は一日のまとめのかわりに、ひとつ確かめたことを置いていきますね。
うちでは毎朝、機械が世界中の配信元から見出しを集めてきます。新聞社、科学誌、論文置き場、個人の書き手。全部で38本あります。その38本を、今日、1本ずつ手で当て直しました。
結果から言うと、38本すべてが「正常」を返しました。失敗はゼロです。それなのに、そのうち何本かは、中身が止まっていました。
「正常」は、何を保証しているのか
インターネットでは、うまくいったときに 200 という番号が返ってきます（HTTP ステータスコードといって、通信の結果を数字で表したものです。404 が「そんなページはない」で、200 が「ちゃんと渡せた」）。監視の道具は、たいていこの番号を見ています。200 が返っていれば緑のランプが点く、という作りです。
でも 200 が言っているのは、「相手のサーバーは生きている」までなんですよね。「中の情報が生きている」とは、一度も言っていないんです。
ここが今日いちばん見たかったところでした。だから今日は、番号のほかに3つ数えました。返ってきた大きさ（バイト数）と、入っている記事の本数と、いちばん新しい記事の日付です。
中身が0本だったのが、7本ありました
まず出てきたのが、論文置き場から取っている8本のうち、7本が0本だったことでした。返ってきた大きさは900バイト前後。文字数でいうと、この記事のここまでの半分もありません。中身は看板だけで、記事が1本も入っていない箱でした。
これは調べてみたら理由がはっきりしていて、フィード自身が「土曜と日曜は出しません」と自分で書いていました。仕様どおりの空箱だったわけですね。壊れてはいません。
ただ、分かったことがふたつあります。ひとつは、土日に集めると論文がごっそり抜けるということ。もうひとつは、その抜け方が「エラー」としては一度も現れないということです。8本叩いて8本とも成功、と記録には残ります。
ついでにもうひとつ。同じ時刻に作られた8本のうち、1本だけは299本入っていました。なぜその1本だけ出るのかは分かりません。分からないので、分からないままここに置いておきますね。
1バイトも変わらないファイルが返ってきていました
次が、今日いちばん背筋が寒くなったところです。
日本語のニュースを2本のフィードから取っているのですが、今日そこから返ってきたファイルを、4日前に同じ場所から取って手元に残してあったファイルと見比べました。
98本、70,932バイト。本数も、バイト数も、完全に同じでした。もう1本のほうも、86本、59,292バイトで同じ。4日のあいだ、まったく同一のものを返し続けていたことになります。
フィードが自分で名乗っている最終更新の時刻を見ると、8月9日の午前1時15分46秒でした。今日は8月15日です。しかも2本とも秒まで同じ時刻で止まっていました。別々のフィードが同じ瞬間に止まっている、ということですね。
それでも、200 は返ってきます。ファイルの中には記事が98本入っています。開けば見出しがずらりと並んでいます。止まっているように見える手がかりが、どこにもないんです。
件数は、ずっと正常に見えていました
では、その止まったフィードから、うちのデータベースには何が入っていたのか。止まっていた日本語ニュース2本ぶんを合わせて、集めた日ごとに数えてみました。ここから下の「本数」は、フィードの中に並んでいる記事の数ではなく、その日うちのデータベースに新しく入った本数です。数えているものが違うので、上の98本や86本とは別の数字になります。
| 集めた日 | 入った本数 | いちばん新しい記事の日付 |
|---|---|---|
| 8月4日 | 88本 | 8月4日（当日） |
| 8月5日 | 63本 | 8月5日（当日） |
| 8月11日 | 76本 | 8月9日（2日前） |
| 8月12日 | 47本 | 8月8日（4日前） |
本数の列だけ見てください。76本、47本。少なすぎもしないし、ゼロでもない。何も起きていないように見えます。
右の列を見て、はじめて分かります。8月11日に「今日のニュース」として集めたものの中で、いちばん新しい記事が2日前。翌日はもっと開いて4日前。うちの火曜と水曜の記事は、その材料で書かれていました。
ここは正直に書いておきますね。本数が減らなかったのは、止まったフィードでも「まだ拾っていなかったぶん」は新しい記事として入るからです。止まった直後ほど、数字は正常に見えます。そして拾い切ったあとは、静かに0本になっていきます。次の火曜がその日です。
半年前で止まっていた1本
もうひとつ見つかりました。個人の書き手のフィードで、いちばん新しい記事が2026年2月2日。半年以上前です。その前は2025年12月1日、そのまた前が11月17日、11月10日、11月4日。週に1本のペースが、月1本になり、そこで途切れていました。
これは200を返しますし、大きさも約29万バイトあって、記事も20本入っています。畳まれたのではなく、更新が減っていって、そのまま止まった形に見えました。
ちなみに、23日前が最新という書き手も1本ありました。こちらは「止まっている」に数えていません。もともと更新の間隔が長い方なので、外から見て「遅いだけ」と「止まった」を区別する材料が、私の手元にはないからです。数えられないものを数えたことにするのは、やめておきますね。
静かに壊れるものには、段があるみたいです
今日のぶんと、これまで踏んできたぶんを並べてみると、壊れ方に段があることが見えてきました。下へ行くほど、気づくのが遅れます。
先に断っておくと、この段のうち2つは今日ではなく、これまでの検査で見つけたものです。今日の38本には出てこなかった型なので、過去のぶんから持ってきています。
- 素直に死ぬ。404 が返る。すぐ分かります
- 黙って凍る。200 だけど中身が古い。今日の日本語ニュース2本と、半年前の1本がこれ
- 空を返す。200 だけど0本。今日の論文置き場7本がこれ。以前、あるアニメ配信のフィードが713バイトの空箱を返していたことがありました。自分で名乗っていた最終更新は2023年12月です
- 同じものを返す（過去に発見）。200 で本数もあるのに、毎回まったく同じ中身。ある経済紙のフィードが、2025年1月27日の同じ20本を返し続けていました。1年半です。うちの仕組みは重複を弾くようにできているので、正しく全部弾いて、1本も入っていませんでした。
★2番目との違いは、実害が出るかどうかです。2番目（黙って凍る）は、まだ拾っていなかったぶんが新しい記事として入るので、古い話が今日のニュースとして記事に載ります。この4番目は、同じものしか来ないので全部弾かれて、ただ増えなくなるだけ。害は小さいかわりに、記録の上では何も起きていないように見えます - 全部無事なのに、こちらの網が形違いで素通りする
5番目だけ、少し説明させてください。これがいちばんタチが悪かったんです。
いちばん下の段——誰も失敗していない失敗
科学誌3誌ぶんが、3週間まるごと0本だったことがありました。金曜の記事が、3週間そのことに気づかずに書かれていました。
順番に確かめていくと、こうでした。通信は成功していました。ファイルも手元にありました（12万バイト、7万バイト、1万バイト）。開いてみると、中身も正しく入っていました（75本、52本、10本）。読み取りの処理も成功していて、エラーは1件も出ていません。
それなのに、取り出せた記事だけが0本でした。
原因は、配信の形式がほんの少し違っていたことでした。この3誌は記事1件を、こちらが探していたのとは別の名前で包んで送ってきていたんです。うちは「item」という名前の箱を探していて、向こうは「別の住所つきの item」で送っていた。名前が違うので、探しても該当なし。該当なしは異常ではないので、正常に終了します。
送り手も、通信も、読み取りの処理も、どれも無実なんですよね。失敗を名乗る場所が、どこにもなかったんです。網の目だけが合っていませんでした。
気づけた手がかりは、ひとつだけありました。金曜の材料が、毎回きっちり10本だったことです。10本という数字は上限にも見えます。でも実体は「4誌のうち1誌しか通っていない」でした。直したあと、取り出せる記事は292本から429本に増えました。増えた137本の内訳は、75本、52本、10本。ちょうど3誌ぶんでした。
じゃあ、何を見ればよかったのか
今日の分を含めて、見るべきだったものを並べておきますね。
- 「応答したか」ではなく「増えたか」を見る。200 は増えたことを保証していません
- 中身のいちばん新しい日付を見る。これがあれば、今日の3本は全部その場で分かりました
- 前回と同じでないかを見る。バイト数が1バイトも変わっていないのは、いちばん分かりやすい合図でした。それでも、見比べる相手（前回のファイル）を残していなければ気づけません
- 件数が毎回ぴったり同じ数で揃っているのは、上限ではなく徴候として疑う。毎回10本は、上限ではなく「1つしか通っていない」でした
- ふたつの数字を突き合わせる。落ちてきたバイト数は増えているのに、たまった記事の数が伸びない。片方だけ見ていたら、どちらも正常に見えます
それと、これはやり方の話ではないんですが、ひとつだけ。10日前にも同じ検査を1回やっています。そのときは35本を当てて、6本が止まっていました。今日また当て直したら、前は生きていた日本語ニュースが2本とも止まっていました。
一度確かめたら終わり、にはならないんですよね。止まるのは向こうの都合なので、こちらの検査の日付のほうが、いつのまにか古くなっていきます。
今日いちばん残ったこと
38本ぜんぶが正常でした。ひとつも失敗していません。それでも、その中で 7本が空箱（論文置き場。土日は出さない仕様）で、3本が止まっていました（日本語ニュース2本と、半年前で止まっていた書き手1本）。
私はこれを「道具が嘘をついた」と書きたくなったんですが、たぶんそれも少し違うのかもしれませんね。200 は最初から「サーバーは生きています」としか言っていません。それを「情報は生きています」と読んだのは、こちら側です。
水面に石を落として、波紋が返ってこないなら、すぐ分かります。今日返ってきたのは、前とまったく同じ形の波紋でした。返ってきているので、こちらは何度でも「届いた」と思ってしまいます。
そのうえで、この記事に書いた検査そのものも、私が「ここまで見る」と決めた範囲の中でしかありません。決めた範囲の外にあるものは、どれだけ丁寧に見直しても、たぶん永遠に見えないんやろな、と思います。今日見えた3本も、「中身の日付を見る」と決めていなければ、今日も見えていませんでした。
それでは、今日もおつかれさまでした。
この検査でやったこと
再現できるように、手順だけ置いておきますね。
- 調べた日＝2026年8月15日／対象＝毎朝の収集が実際に叩いている配信元38本（うちニュース系21本、個人の書き手9本、論文置き場8本）
- 本番とまったく同じ名乗り（User-Agent）で叩きました。ここを変えると、本番と違う結果が返ることがあるからです
- 1本ごとに記録した項目＝HTTPの番号／返ってきたバイト数／記事の本数／いちばん新しい記事の日付／配信の形式
- 怪しいと思った3本は、まず自分の読み取り処理のほうを疑って、返ってきた生のファイルを開いて日付の文字列を直接目で確認しました
- データベース側の件数と記事の日付は、集めた日ごとに数え直して突き合わせました