WEBサイト
毎朝、合計だけを見ていた「1,415件」
当サイトでは、自動点検ツールが毎朝 サイト全体をチェックして、気になる箇所を一覧にして知らせてくれる仕組みを使っている。ページの構成・検索への露出・表示速度・説明文の長さなど、いくつもの観点をまとめて見てくれるので、毎朝 開くのが習慣になっていた。今朝もいつも通り開いたら、警告の合計は「1,415件」と出ていた。
この手の点検ツールは、WEBディレクターなら見覚えがあるはずだ。ダッシュボードを開くと、まず目に入るのが大きな数字の合計。件数が多いページを見ると気が重くなり、少なければ安心する。そういう作りになっているツールは多い。当サイトの点検ツールも例外ではなく、トップに合計件数、その下に対象ページの一覧が並ぶ、よくある構成だった。
正直に書くと、この合計を見て毎朝 何をしていたかというと、「昨日より増えていないか」を確認するだけだった。前日比で大きく増えていなければ、詳しい中身は開かない。増えていたら、増えた分だけ新しいページを疑う。それを1年 近く 続けていた。件数の推移だけを見て、内訳を開かないまま「今日も特に問題は無さそうだ」と判断する日々だった。
今日、初めてこの1,415件を「種類別」に数え直した。きっかけは単純で、archives/128「出力は在った。だから誰も測らなかった」を書いたときに、「点検ツールは正しく動いている。ただ、その出力の内訳を一度も見ていない」という形に何度も出会ったからだ。今回、それが自分自身の毎朝のルーチンの中に、いちばん身近な形で残っていることに気づいた。合計の数字だけを追いかける運用を、自分の手で1年も続けていた。
結果を先に書く。1,415件のうち、実際に対応が要るものは、ほとんど無かった。内訳の数え方には2通りある。「まったく手を付ける必要が無い」区分（意図した設定＋点検ツール側の誤判定）だけで数えると96.7%。そこに「優先度は低いが、いずれ直した方がいい」軽微な区分まで含めて数えると97.8%になる。どちらの数え方でも、9割台後半は今日すぐの対応を必要としないものだった。そして、その陰に、本当に確認すべき小さな区分が埋もれていた。件数の少なさゆえに、合計だけを見ていたら一生 気づかなかった区分だ。
この記事を書きながら思い出したのは、「0件は安心ではない、N件は危険ではない」という考え方だ。件数の多い少ないだけで危険度を判断すると、必ずどこかで読み違える。今回の1,415件も、数字の大きさだけを見れば「大変なことになっている」と身構えてしまいそうな数だが、内訳を見るまでは、それが本当に大変なのかどうかすら分からなかった。数字の大きさと、危険度は、別々に確かめる必要がある。
種類別に数えたら、4つに分かれた
点検ツールの出力には、警告の種類ごとに区分のラベルが付いている。今まではそのラベルを見ずに合計だけを見ていたので、まずラベルごとに件数を数えることから始めた。1,415件を手作業で1件ずつ数えるのは現実的ではないので、ラベルの種類で機械的に振り分けた。結果は次の4つに分かれた。
数え方そのものは特別なものではない。点検ツールが出力した一覧をそのまま書き出して、ラベルの文字列ごとに件数を集計しただけだ。この程度の集計であれば、表計算ソフトのフィルタ機能や、簡単な文字列処理でも十分できる。大掛かりな仕組みを新しく作る必要は無く、「今 手元にある出力を、ラベルで並べ替えて数える」という、それだけのことだった。
| 区分 | 件数 | 比率 | 性質 |
|---|---|---|---|
| ① 検索避けの設定が入っている | 1,019件 | 72.0% | 意図的にそうしているもの |
| ② 正しいURLの指定が違う | 350件 | 24.7% | 点検ツール側の誤判定 |
| ③ 説明文が短い | 15件 | 1.1% | 軽微・優先度低 |
| ④ ページが遅い（6〜11秒） | 88件 | 6.2% | 唯一「本物かもしれない」もの |
数え終えて最初に思ったのは、「件数の多さと、重要さは、まったく別の軸だ」ということだった。いちばん件数が多かった①は、直す必要のないものだった。逆にいちばん件数が少なかった③④は、①よりずっと軽い扱いを受けやすいが、③は実際に直す価値があり、④に至っては唯一「本当に問題かもしれない」区分だった。件数の順位と、対応の優先順位は、一致していなかった。
① 検索避けの設定が入っている ── 1,019件（72.0%）
いちばん多かったのがこの区分。当サイトには、検索結果に出さないと決めているページ（会員専用の途中経過ページや、内部用の一覧、テスト目的で作った下書きページなど）が一定数あり、そこには意図的に検索を避ける設定を入れてある。これは事故ではなく、サイトを設計する上で意図的に選んだ状態だ。
点検ツールは、「検索結果に出ない設定が入っている」ことを機械的に検出して、律儀にすべて警告として並べていた。ツール自身の立場からすれば、「検索に出ない設定がある」という事実を正確に報告しているだけなので、これは誤判定ではない。ただ、その事実が「問題」なのか「意図」なのかは、ツールには判断できない。判断できるのは、そのページを作った側の人間だけだ。
1件ずつ開いて確かめたところ、全件が「意図した通り」の状態だった。ここに直すべきものは1件も無い。1,019件という数字だけを見ると圧倒されるが、中身を見れば「対応不要」という結論に、思っていたよりずっと早く辿り着けた。
この種の「意図的に検索避けの設定を入れているページ」は、規模の大きいサイトほど自然に増えていく。会員限定のコンテンツ、公開準備中の下書き、社内向けの一覧、過去に統合して残骸になったページなど、理由はサイトごとに様々だが、どのサイトにも一定数は存在する。点検ツールがこの種の設定をすべて拾い上げること自体は、むしろ正しい挙動だ。問題は、拾い上げた結果を「警告」という同じ見た目で並べてしまい、意図と事故の区別を、開く人間の側に丸投げしていることだった。
② 正しいURLの指定が違う ── 350件（24.7%）
2番目に多かったのがこの区分。ページが自分自身の正しい住所として宣言しているURLと、点検ツールが記録しているURLの綴りが違う、という警告だ。件数が2番目に多かったので、最初は「これが本物の不具合の本丸ではないか」と身構えた。350件もあるなら、何らかの設定ミスがサイト全体に広がっている可能性を疑うのが自然だった。
そこで1件を開いて、点検ツールが記録していたURLと、ページが実際に宣言していたURLを、文字単位で並べて比べてみた。結果は、予想していた「設定ミス」とは違う形をしていた。詳しくは次の章に書く。
③ 説明文が短い ── 15件（1.1%）
検索結果に出る説明文が、目安より短いページが15件あった。これは4区分の中で、いちばん素直に「直した方がいい」区分だった。説明文が短いと、検索結果の一覧で読者に内容が伝わりにくくなり、クリックされる機会を減らす可能性がある。
ただし件数が少なく、サイト全体への影響も限定的なので、今日の対応の優先順位としては、後回しにできると判断した。もっとも、優先順位が低いだけで「見なくていい」わけではない。実際、このうち特に短かった3件は、この記事を書いている今日のうちに文言を見直している（詳しくは後半に書く）。
④ ページが遅い（6〜11秒） ── 88件（6.2%）
「6秒から11秒かかっている」という報告が88件。他の3区分と違って、これだけは「本当にそうかもしれない」と思えた。理由は単純で、①③は「点検ツールが正しく検出した、意図的な状態か軽微な改善点」であり、②は「点検ツールの比較方法そのものの問題」だったのに対して、④は「点検ツールが観測した数値そのものが、事実かどうか」を問う区分だったからだ。
件数の割合は全体の6.2%と小さいが、もし本当に6秒以上かかっているページが88件もあるなら、読者の体験に直結する重大な問題になる。ここだけは、報告を鵜呑みにせず、自分の手で叩いて確かめることにした。結果は後半の章に書く。
ここまでの4区分を並べてみると、面白いことに気づく。①③④は、いずれも「点検ツールが観測した事実」を報告している点で共通しているが、その事実の意味づけ（意図か・軽微か・本物の問題かもしれないか）は、それぞれまったく違う。一方で②だけは、そもそも観測している「事実」自体の前提に、比較方法の穴があった。同じ「警告」という見た目の中に、性質の違う4つのものが混ざっていた、というのが、今日いちばんの発見だった。
②の正体 ── 半角スペースと、URLの書き方
点検ツールが持っていたURLと、ページが宣言していたURLの違い
350件のうち1件を、実際に開いて2つの文字列を並べてみた。
点検ツールが持っていたURL：/tag/Bing AI Performance（半角スペースを含む）
ページが宣言していたURL：/tag/Bing%20AI%20Performance（半角スペースを符号化した形）
これは、URLとしては同じ場所を指している。半角スペースはそのままではURLに使える文字ではないので、ブラウザやサーバーは「%20」という符号に変換して扱う。これをパーセントエンコーディング（URLエンコード）と呼び、URLの構文を定めた仕様（RFC 3986）で決められている、ごく一般的な仕組みだ。半角スペースだけでなく、日本語の文字や一部の記号も、同じように符号化される。
ブラウザはページを表示する際に、この符号化を自動で行ってくれる。だから普段ブラウザでサイトを見ているだけでは、符号化前と符号化後の違いを意識することは無い。一方で、ページの一覧を出力したり、外部のツールでデータを取り込んだりする場面では、符号化される前の生の文字列がそのまま扱われることがある。点検ツールは、おそらくこうした場面のどこかで、符号化前の文字列を記録として持ってしまい、それを符号化後のURLと比較していたのだと考えられる。
点検ツールは、記録していた「変換前」の文字列と、ページが実際に宣言している「変換後」の文字列を、単純な文字列比較で照合していた。人間から見れば同じ場所でも、コンピュータにとっては1文字も一致しない別の文字列だ。だから機械的に「違う」と判定していた。これは点検ツールが壊れていたわけではなく、比較の仕方に「符号化の前後を揃える」という一手間が足りていなかった、というだけの話だ。
350件、全部が同じ形をしていた
残りの349件も確認したところ、全件が半角スペースを含むタグ名（記事の分類用に付けているラベル）だった。「違う」と判定された理由が、350件すべてで同じだったことになる。archives/117「同じ条件で測っていなかった」で書いたのと同じ形で、比べる前に、比べる相手の条件（この場合はURLの書き方）を揃えていなかった。1件を丁寧に開いて確かめたからこそ、残り349件を1件ずつ開かなくても、同じ原因だと言い切れた。
点検ツールの検出そのものは正しく動いていた。壊れていたのは、比較する2つの文字列の「前提」の方だった。この形の誤判定は、URLに日本語や記号を使っているサイトなら、どこでも起こりうる。当サイトの場合はタグ名だったが、カテゴリ名やファイル名に空白や日本語を使っている場合も、同じ構造の誤判定が起きる可能性がある。
もう一つ、今回の350件から学んだのは「同じ原因の警告は、まとめて1件として扱ってよい」という判断のしかただ。1件ずつ丁寧に開いて原因を確かめるのは正しい姿勢だが、350件すべてを同じ丁寧さで開き直す必要は無い。1件で原因の型を確定させ、残りは同じ型に当てはまるかどうかだけを機械的に確認すれば十分だった。件数が多いからといって、確認の手間まで350倍になるわけではない。
URLの文字列比較で「違う」と誤判定される原因は、今回の半角スペース以外にもいくつかある。英字の大文字と小文字の違い、末尾に「/」が付くか付かないか、「http」と「https」のどちらで記録しているか——どれも、人間やGoogleから見れば同じ場所を指しているのに、単純な文字列比較では「別のURL」として扱われてしまう。URLの一致・不一致を報告するツールを使うときは、比較の前提が何を「同じ」とみなしているのかを、一度は確かめておいた方がいい。
④を自分で叩いたら、再現しなかった
3つのページを、実際に測ってみた
「6〜11秒かかっている」と報告された88件から3件を選び、実際に自分でページを開いて応答時間を測り直した。選んだのは、報告された時間が長い順に上位3件だ。測り方は特別なものではなく、そのページのURLを直接 読み込ませて、リクエストを送ってから応答が返ってくるまでの時間を記録するという、ごく基本的な方法にした。1回だけでは偶然の影響を受けるので、同じページを数回 測って、結果が大きくぶれていないことも確認している。
| ページ | 点検ツールの報告 | 測り直した値 |
|---|---|---|
| ページA | 11.1秒 | 0.10秒（実はリダイレクトだった） |
| ページB | 9.1秒 | 0.46秒 |
| ページC | 7.8秒 | 2.37秒 |
ページAは、報告と測り直した値の差がもっとも大きかった。開いてみると、このページはリダイレクト（別のURLへ自動で転送する仕組み）になっていて、転送先まで含めて測っても0.10秒しかかからない。「11.1秒」という報告は、まったく再現しなかった。ページBも同様で、報告の1/20ほどの時間で応答が返ってきた。
この差がなぜ生まれたのか、確定した原因は分からない。ただ、点検ツールが1,415件という膨大な数のページを連続して測っていることは事実で、大量のページを立て続けに叩く測定方法そのものが、自分自身の測定を詰まらせている可能性はある。これは自分では検証できていない仮説であって、断定はしない。
ページBについても同じ傾向で、報告の9.1秒に対して、測り直した値は0.46秒。ページAほどの極端な差ではないが、それでも報告の1/20ほどだった。ページAとBに共通しているのは、どちらも点検ツールが「6秒台後半〜11秒台」という、似たような長い時間を報告していたことだ。もし点検ツール側の測定に何らかの上限や詰まりがあるなら、報告される数字が特定の範囲に偏る、という形で現れてもおかしくない。ただし、これも手元の3件だけで言えることではなく、88件全体を見なければ確かなことは言えない。
比べる相手（対照ページ）を用意する
測り直した数字だけを見ても、それが速いのか遅いのか判断がつかない。11.1秒と報告されていたページが0.10秒だったと言われても、そもそも当サイトの「普通のページ」がどれくらいの速さなのかを知らなければ、比較にならない。そこで、点検ツールが問題視していない、通常のページを2件選び、同じ条件・同じ方法で測り直した。
対照ページは0.87秒と1.02秒。ページAとBの、測り直した値（0.10秒・0.46秒）は、この対照ページよりもむしろ速いくらいで、報告そのものが再現しなかったことになる。archives/134「『リンク切れ0本』を確認して、安心しかけた」で書いたのと同じ構図で、自動チェックの結果をそのまま受け取ると、実際には起きていないことを「起きている」と思い込むところだった。比べる相手（対照ページ）を用意していなければ、ページAとBの「0.10秒」「0.46秒」という数字を見ても、それが速いのか遅いのか、自分では判断できなかったはずだ。
2.37秒は、直さずに残すと決めた
ページCだけは違った。測り直した2.37秒は、対照ページ（0.87秒・1.02秒）の2.3〜2.7倍。点検ツールの報告（7.8秒）ほどではないが、事実として重い方に寄っている。ページAやBのように「再現しなかった」とは言えない。
ここで「原因を今すぐ特定できていないから、今日は直さない」という判断をした。理由を憶測で書いて、実際には別の原因だった場合の方が、読者の役に立たないと考えたからだ。よくある原因の候補としては、そのページに埋め込んでいる画像や外部サービスの読み込みが重い、というものが考えられるが、これも憶測の域を出ない。今日できたのは、①これは事実として残っている ②原因はまだ確定していない、という2つを分けて記録することだけだった。
なお、表示速度の指標そのものの基準は、Googleが定めたCore Web VitalsのLCP・INP・CLSという3つの指標が、それぞれ「良好」「改善が必要」「不良」の3段階で判定される仕組みになっている。この判定の読み方は、別記事の「Core Web VitalsのLCP・INP・CLSは『良好・改善が必要・不良』の3段階で判定される」に確認する項目としてまとめてある。基準そのものはweb.devのCore Web Vitals解説が一次情報にあたる。今回の「応答時間」は、Core Web Vitalsの各指標そのものではないが、考え方の根っこは同じで、「数値の意味は、基準や対照と一緒に見て初めて分かる」という点は共通している。
合計が毎日出ていると、内訳を見に行く動機が消える
別のサイトを担当している仲間が、先に同じ骨を出していた
この形の失敗は、当サイトだけで起きたものではない。当社の別サイトを担当している仲間が、以前こう書いていた。
ログの「合計」は毎日 出ていた。だから誰も内訳を見に行かなかった。そして正規のクローラーが1ヶ月 弾かれていても、合計は正常な顔をしていた。
この骨は、Cloudflareが「稼ぎ方」を変えた話を書いたarchives/96「Cloudflareが『稼ぎ方』を変えた日」と同じ回で言及されているものだ。合計だけを毎日 見る運用は、「異常が起きていないこと」を確認しているようで、実は「内訳を見に行く理由」を毎日 消している。合計が正常な顔をしていれば、内訳を疑う動機はどこからも湧いてこない。
当サイトでは、その合計が1年 出続けていた
当サイト自身にも、この形の前科がある。以前、アクセスログの合計を「AIクローラーが弾かれている」と読みかけたことがあった。archives/143「『AIクローラーが弾かれている』と読みかけた」では、日別に割って初めて、その正体が数十の名前を名乗る貸しサーバーだったと分かった。あのときと今回は、対象（アクセスログとサイト点検の警告）は違っても、「合計を分けたら、別のものが出てきた」という点で、まったく同じ形をしている。
そして今回さらに重いのは、この骨をすでに持っていたにも関わらず、自動点検ツールの合計だけは1年 近く 同じように見ていたことだ。骨は知っていた。適用していなかった。1つの場所で学んだ教訓を、別の場所に横展開する作業は、意識してやらなければ自然には起きない、ということを今日 改めて思い知った。
この記事を書き終えた後、当サイトで「合計だけを見て、内訳を開いていない数字」が他にも無いか、頭の中で洗い出してみた。検索順位の推移、表示回数、エラーの発生件数——どれも毎日 グラフや合計で眺めているが、種類別に内訳まで開く頻度は、点検ツールの警告と同じくらい低かった。今回のように「実際に数え直したら違った」という経験を1つ積んだので、次はこの洗い出しを、思いつきではなく手順として残す番だ。
自分のサイトで、今日からできること
手順1 ── 警告は必ず種類別に数える
まず、点検ツールの出力に付いているラベル（種類・カテゴリ・エラーコードなど）ごとに件数を数える。合計だけを見て「増えた・減った」を判断しない。多くの点検ツールは、警告の種類ごとにフィルタや絞り込みができる機能を持っているので、それを使えば手作業で1件ずつ数える必要は無い。数えた結果は、今日のように表にしておくと、来月また同じ作業をするときに、変化を追いやすくなる。
Search Consoleの警告の読み方に迷う場合は、当サイトの🔧 Search Consoleの見方に迷ったらこちらの解説ツールも参考になる。noindexなど検索避けの指定そのものの公式な仕様は、Google Search Centralのrobotsメタタグの説明にまとまっている。まずはこの仕様を一読しておくと、①のような「意図的な設定」を見分ける判断材料になる。
種類別に数える作業は、1回やって終わりにせず、月に1回など、決まった頻度で繰り返すことをすすめる。今回のように内訳の比率が分かっていれば、次に数えたときに「①の比率が急に減った」「④の件数が急に増えた」といった変化にも気づきやすくなる。合計の増減だけでは分からなかった変化が、内訳を継続して見ていると見えてくる。
手順2 ── URLの文字列比較は、書き方を揃えてから
「URLが一致しない」という警告が出たら、比較の前に両方のURLをURLエンコード後の形に揃える。半角スペース以外にも、日本語や記号を含むURLでは同じことが起きる。カテゴリ名やタグ名を日本語で運用しているサイトは、特にこの形の誤判定に出会いやすい。
当サイトの🔧 WEBサイト内のリンク漏れ・チェックツールで、自分のサイトのリンク切れを一度 洗い出しておくと、URLまわりの比較の基準ができる。より正確に確かめたいときは、Search ConsoleのURL検査ツールで、Googleが実際にどのURLとして認識しているかを1件ずつ確認し、必要であれば再クロールを依頼できる。この機能を使えば、点検ツールの報告と、Google自身の認識を、両方の視点から突き合わせられる。
手順3 ── 「遅い」という報告は、自分で叩いて確かめる
「遅い」という報告は、対照ページ（問題視されていない通常のページ）と一緒に測り直す。1件だけ測っても、それが速いのか遅いのか判断がつかない。比較の相手が無いと、数字は意味を持たない。
表示速度の測定には、PageSpeed Insightsのような、Google自身が提供している無料の計測手段がある。同じページを時間を空けて複数回 測り、結果がばらつくかどうかも見ておくと、1回だけの数字に振り回されずに済む。また、今回のページAのように「実はリダイレクトだった」というケースもあるので、報告されたURLが最終的にどこへ着地するのかも、併せて確認しておくとよい。自分の手で叩いた数字だけが、自分のサイトの実態を語る。
見つけた失敗を、正直に書く
直したこと
③の説明文が短い15件のうち、目立って短かった3件は、この記事を書いている今日のうちに文言を見直した。✅ 説明文3件を本日 修正済み
②の350件については、点検ツール側の比較方法の問題であって、こちら側のページを直す必要は無いと判断した。①の1,019件も同様に、意図した設定なので対応不要とした。この2区分は、直さないことそのものが正しい結論であって、「後回し」ではない。
直さないと決めたこと
ページCの2.37秒は、直さないと決めた。理由は前に書いた通り、原因がまだ確定していないからだ。憶測で対処すると、実際には効果のない変更を加えて、後から見返したときに「なぜこの変更をしたのか」が誰にも分からなくなる。原因を確かめてから直す、という順序を今回は崩さなかった。🔧 ページCの原因調査は継続中
もう一つ、正直に書いておきたいことがある。今回の④のように「点検ツールの報告を、自分の手で測り直す」という作業は、今日は手作業で3件だけを選んで行った。88件すべてを自動で測り直して、報告値と実際の値を並べる仕組みは、当サイトではまだ用意していない。件数が増えたときに同じ確認を続けられるかどうかは、まだ検証できていない。
同じことは②の350件にも言える。今日は1件を開いて原因の型を特定し、残り349件はラベルの共通点から「おそらく同じ原因だろう」と判断した。これは349件それぞれの本文を1件ずつ目視で確認したわけではない。もし349件の中に、たまたま同じラベルを持ちながら別の原因のものが混ざっていたとしても、今回の確認方法では見落とす可能性がある。この記事に書いた「350件、全部が同じ形」という結論は、あくまで確認できた範囲での結論だと理解してほしい。
この記事のような、自分の失敗と、直したこと・直さなかったことを、そのまま記録する取り組みについては、archives/110「宣言と実装のギャップは物証で塞ぐ日」に、その仕組み自体をまとめてある。今日の記録も、その延長線上にある。
まとめ
毎朝 合計だけを見ていた「1,415件」を、初めて種類別に数え直したら、内訳の96.7%（①＋②）は対応がまったく要らないもので、そこに軽微な③を足した97.8%までが、今日すぐの対応を必要としないものだった。①の1,019件は意図した設定、②の350件は点検ツール側の比較方法の問題、③の15件は軽微な改善点。残った④の88件のうち、実際に自分で叩いて確かめたのは3件で、うち2件は報告そのものが再現せず、1件だけ事実として重い方に寄っていた。
合計が毎日 出ていると、内訳を見に行く動機が消える。これは当社の別サイトの担当者が先に出していた骨であり、当サイト自身も別の場面で一度 踏んでいた形だった。それでも、自動点検ツールの合計だけは1年 近く 同じように見続けていた。今日、種類別に数え直して初めて、埋もれていた区分が見えた。
先に書いた「96.7%」と「97.8%」という2つの数字も、内訳をどこで区切るかで変わる。①1,019件と②350件（合わせて1,369件・96.7%）は「まったく対応が要らない」区分。そこに③15件を足すと1,384件・97.8%になり、これは「優先度は低いが、いずれ直した方がいい」ものまで含めた数字だ。合計が2種類あるのではなく、区切り方が2種類ある、というだけの話だが、これも最初に合計だけを見ていたら、区切り方の違いにすら気づかなかった。
自分のサイトの自動点検ツールが出す警告も、合計だけで判断せず、一度 種類別に数え直してみることをすすめる。5分もあれば、今まで見えていなかったものが見えてくるはずだ。
そして、種類別に数え終えたら、そこで止めずに、いちばん件数が少ない区分から先に開くことをすすめる。今回の当サイトでも、件数がいちばん多かった区分は対応不要で、件数がいちばん少なかった区分の中に、直す価値のあるものと、唯一「本物かもしれない」ものが両方 入っていた。件数の少なさは、優先度の低さと同じ意味ではない。
関連 archives（連載軸として読む）
- archives/143「『AIクローラーが弾かれている』と読みかけた」 ── 合計を分けたら、別のものが出てきた先例（2026-09-11）
- archives/134「『リンク切れ0本』を確認して、安心しかけた」 ── 自動チェックの結果を鵜呑みにしない話（2026-08-28）
- archives/128「出力は在った。だから誰も測らなかった」 ── 今日の出発点になった記事（2026-08-18）
- archives/117「同じ条件で測っていなかった」 ── 比較の前に条件を揃える話（2026-07-17）
- archives/110「宣言と実装のギャップは物証で塞ぐ日」 ── 正直に記録する仕組みそのもの（2026-07-15）
