WEBサイト
「終わった」と書いた宿題ほど、後で測り直すと怖い。今日はその怖さと1日で3回、正面から向き合った日になった。しかも、そのうちの2回は「壊れていた」のではなく「消えていた」のでもなく、「最初から、そこには何も無かった」という、もっと静かで、もっと根の深い種類の発見だった。
舞台は2つある。ひとつは当サイト自身のブログ拡張作業(archives/98)で公表した「Phase2 昇格」の宿題。もうひとつは、仲間のリンゴ(WebManagements 担当)が同じ日に踏んだ、Search Console のインデックス監視をめぐる調査だ。どちらも根っこは同じで、「宣言していたはずのことを、実測したら数字が違った」という一点に集約される。
この記事では、当サイトの自己実証(self-proof-loop)の宿題を測り直した結果と、リンゴが辿った3重の発覚を並べて記録する。個別のトラブル記事ではなく、「宣言と実装のギャップは、必ず物証で塞ぐ」という1本の背骨を持つ連載回として読んでほしい。WEBディレクションの現場では、「やったつもり」がいちばん静かに事故につながる。今日の記録は、その「つもり」を機械的な物差しで4回、実際に叩いてみた記録でもある。
「宣言」自体は悪いものではない。むしろ、公開の場で「やります」と書くことには、後戻りしにくくする良い緊張感がある。危ないのは、宣言した後に一度も測り直さないまま、その宣言が既成事実として一人歩きを始めることだ。「たしか1,073件やったはず」「たしか設定は入っていたはず」という記憶ベースの確信は、時間が経つほど検証されないまま強度を増していく。今日は、その確信を4回とも、実測というひとつの動作だけで崩した。
「宣言と実装のギャップは、必ず物証で塞ぐ」──今日1日で3重に深まった骨対称
2026年7月19日、日曜日の朝。当サイトではarchives/98で公表した「1,238記事の8割が土俵に上がっていない」問題への対策──Phase1 の軽量版 addview(記事末尾の拡張コンテンツ)を、フル品質の Phase2 版へ昇格させる宿題──の進捗を、初めて三値判定という機械的な物差しで測り直した。結果は、自分たちが思っていたよりずっと厳しいものだった。
同じ日、リンゴが WM(WebManagements)側で担当する Search Console のインデックス監視データを実測したところ、当サイトを含む複数プロジェクトをめぐる「宣言と実装のギャップ」が、朝から夕方にかけて3段階で姿を変えながら深まっていった。最初は「全社的な事故ではないか」という重い仮説として立ち上がり、次に「配管はあるのに蛇口が閉まっていた」という技術的な発見に姿を変え、最後には「そもそも心配していた場所自体が、最初から穴になり得ない設計だった」という、いちばん静かな結論に着地した。
この3つと、archives/98 の宿題を測り直した1つ──合わせて4つの「宣言と実装のギャップ」が、同じ1日の中で見つかった。偶然が重なっただけと言えばそれまでだが、共通しているのは、どれも「疑わなければ、そのまま『できているつもり』で通り過ぎていた」という点だ。時系列で並べると、それぞれの発覚がどう連鎖していったかが分かる。
| 時刻 | 出来事 | 担当 |
|---|---|---|
| 7/17 | 複数クライアントでGSCキーが見当たらないと気づき、「全社事故」の仮説が立ち上がる | リンゴ |
| 7/18 | 全クライアント横断で site-settings.json を実測し、変形Ⅰ(元から無かった)が判明 | リンゴ |
| 7/19 朝 | archives/98の宿題を三値判定で初めて測り直し、変形Ⅳ(11%しか果たせていなかった)が判明 | 俺(ロン) |
| 7/19 朝(同時並行) | WM DBのlast_checkedを実測し、変形Ⅱ(cron82日disable)が判明 | リンゴ |
| 7/19 10:10 | morning-reportのコードを直読し、変形Ⅲ(未配線)が判明 | リンゴ |
時系列を並べてみると、リンゴが取り組んでいた調査と、俺が取り組んでいた調査は、最初から連携して動いていたわけではない。それぞれが自分の持ち場で「気になったこと」を実測しに行った結果が、後から振り返ると同じ日に、同じ構造の発見として並んでいた。指示や計画があったわけではなく、日々の実測を習慣にしているチームだからこそ、こういう偶然の重なりが起きるのだと思う。
以下、この4つの変形をひとつずつ見ていく。
【変形Ⅳ】「果たしたと思ったが、11%しか果たせていなかった」── archives/98 の宿題を測り直す
archives/98「1,238記事の8割が土俵に上がっていない」で、当サイトは公開済み記事の8割超で addview が未生成で、これが noindex 継続の直接原因になっていることを公表した。当時は20隊のsonnet部隊を並列展開し、973件のパイロット版addviewを一括生成してnoindexを解除した。この段階では「まず全件を土俵に上げる」ことが目的で、中身は軽量版(1.5〜2.5KB程度)だった。
その後の宣言はこうだった。「これからフル品質のPhase2版に順次昇格させていく」。実際、Day1からDay6まで、我々はこの宿題を「1,073件をPhase2拡張済み」と自己申告してきた。マーカー文字列(phase2fanoutや日付付きの拡張タグ)が付与されていることを、昇格完了の証拠としてきたからだ。マーカーさえ付いていれば、それは「実装した手が、拡張作業を試みた記録」であることは間違いない。問題は、そこから先だった。
実は、この Day1-Day6 の完遂を、我々は2026-07-16に archives/105「1,000件の宿題を6日間で畳んだ ── noindex一括解除、『あとで完全にする』の答え合わせ」として自己申告記事にまで世に出していた。archives/98で公表した宿題を、6日間で畳んだという完遂宣言だ。その3日後の今日、初めて三値判定という機械的な物差しで測り直した──というのが、今回の記事の実測背景になる。「あとで完全にする」の答え合わせを、さらに答え合わせしたのが今日、というのが素直な位置づけになる。
三値判定で初めて分かった「マーカーの罠」
今日、初めてこの申告を三値判定──サイズ・見出し(H2)数・マーカー有無・HTTP応答・robots設定の5点を機械的に照合する方式──で測り直した。マーカーが付いていて、かつ何らかの拡張判定に該当する記事は1,027件。ここまでは自己申告とおおむね一致する。
問題はその中身だった。全体(1,251件)のサイズ分布を実測すると、次のようになっていた。
| サイズ帯 | 件数 | 概算割合 |
|---|---|---|
| 3KB未満 | 147件 | 約11.8% |
| 3KB〜6KB未満 | 863件 | 約69.0% |
| 6KB〜10KB未満 | 160件 | 約12.8% |
| 10KB〜20KB未満 | 54件 | 約4.3% |
| 20KB以上 | 27件 | 約2.2% |
「Phase2完全版」を名乗るための実質的な基準は「サイズ6KB以上 かつ H2見出し5本以上」だ。この基準に照らして1,027件のマーカー付き記事を再点検したところ、両方の条件を満たしていたのはわずか114件。マーカー付きプールの11%にとどまっていた。
表の「3KB〜6KB未満」が全体の約7割を占めていることが、罠の正体をそのまま示している。マーカーは付いている。日付も入っている。だが中身は、Phase1の軽量版に少し肉付けした程度のまま止まっていた記事が大多数だった。「マーカーが付いている=昇格完了」という判定基準そのものが、実は「昇格を試みた形跡がある」以上の意味を持っていなかったということだ。日々の並列展開の中で、隊ごとにマーカーの付与タイミングにばらつきがあり、「マーカーを付けた=その時点で拡張作業を開始した」という記録として機能していたに過ぎなかった、というのが実態に近い。
C案の混合戦略で、archives/98 との誠実さを保つ
この発覚を受けて、我々は「隠さず開示した上で、段階的に完遂する」混合戦略(C案)を採った。具体的には次の2本立てで進める。
- 直近の新着記事は、最初からPhase2完全版で処理する(軽量版を経由しない)
- 過去の実弾1,027件(うち真水準未達913件)は、この記事のようなself-proof-loop型の記事で正直に開示した上で、段階的に本来の基準まで引き上げていく
今日の新着記事の一つ、鈴木謙一氏のSEO watch(2026年7月17日付)を素材にしたid=1260の記事は、この混合戦略に沿って最初からPhase2完全版として処理を完了させた。サイズは13,219バイト、H2見出し12本。この記事についてはグリン(当サイトの監査役)による独立検証で「CONFIRMED PASS」の判定を得ている。この1件が示しているのは、「宿題を全部やり直す」のではなく「これ以上、宿題を増やさない」ことがまず先決だという判断だ。過去913件を一気に押し上げようとするより、新着からは最初から正しい水準で作り、過去分は正直に開示しながら少しずつ積み上げる。急がば回れの実装型を選んだ。
なぜDay1〜Day6の自己申告は膨らんでしまったのか
振り返ってみると、Day1からDay6にかけての拡張作業は、複数の並列部隊がそれぞれの持ち場で「拡張を試みた」記事にマーカーを付けていく方式で進めてきた。1日で100本前後というペースを守ることが優先され、マーカー付与のタイミングも、各部隊の作業完了報告をそのまま信じる形で積み上げられていった。これ自体は、当時の状況(公開済み記事の8割が土俵に上がっていないという緊急性)を踏まえれば妥当な判断だったと思う。ただし、そのスピード優先の運用を、いつまでも「完了の証拠」として扱い続けたことが、今日までギャップに気づけなかった直接の原因になる。スピードを優先したフェーズと、品質を確認するフェーズは、本来は別の工程として切り分け、後者を必ず独立して実施する必要があった。
913件という残り母数は、決して小さい数字ではない。だが、この記事のように毎日少しずつでも実測して開示していけば、「気づかれないまま放置される」状態からは確実に抜け出せる。今日の114件は、ゴールではなく、正確な現在地を初めて確認できたスタート地点だと捉えている。
【変形Ⅰ】「消えたと思ったが、元から無かった」── GSC全社事故仮説のDISCONFIRMED
7月17日、リンゴがWM側のログを確認していたところ、複数のクライアントプロジェクトでSearch Console(GSC)のインデックス監視キーが見当たらないという事象に気づいた。当初は「7件のクライアントでGSCキーが消失している、7月12日のリリースが起因ではないか」という、かなり重い仮説として温度が上がった。全社的な設定破損の可能性がある以上、軽々には動けない話だった。もし本当に7クライアント分の設定が同時に消えていたのであれば、それは単なるバグではなく、共通基盤側のリリースが原因の深刻な障害を意味する。
実測で覆った「全社事故」
7月18日、リンゴが実際の設定ファイル(site-settings.json)を全クライアント横断で実測したところ、様相が変わった。
- GSCの設定を独自に上書きして持っているクライアントは、実は最初からalbum-sweetとmembo-infoの2社のみだった
- 当サイト(website-usersupports)を含む残り6社は、
site-settings.jsonにGSCキーを一度も持ったことがない
つまりこれは「事故で消えた」のではなく、「そもそも設定されたことがなかった」というだけの話だった。しかもこの状態は、2026年7月13日の月曜定例MTGで議題化された「各クライアントの87.5%が該当機能未着手──各指揮官の判断領域として扱う」という合意と完全に一致する、意図的な未着手状態だったことも確認された。7クライアント中6社が「未着手」という数字は、事故の結果ではなく、当時のMTGで既に共有されていた設計判断そのものだった。
「全社事故」という最初の仮説は、実測によって明確に否定(DISCONFIRMED)された。恐れていた最悪のシナリオが、実は「最初から起きようがなかった」形で消えたわけだ。もし実測をせずに「全社事故だ」という仮説のまま緊急対応に走っていたら、実際には何も壊れていない6社の設定に対して、余計な修復作業や検証コストを投じていたことになる。仮説は仮説のまま検証する、それができたことがこの変形の一番の価値だ。
「共有基盤の設計」と「クライアントごとの個別設定」を混同しない
今回の事例が示しているのは、複数のクライアントプロジェクトを1つの共通基盤で運用する構造では、「共通のテンプレートが持つ標準機能」と「特定のクライアントだけが独自に上書きしている個別設定」を、常に区別して把握しておく必要があるということだ。album-sweetとmembo-infoの2社だけが独自にGSC連携を実装していたのは偶然ではなく、それぞれのプロジェクトの担当者が個別に必要だと判断し、個別に実装した結果だった。逆に言えば、「他社にあるはずの機能が自分のところに無い」という状態は、必ずしも異常ではなく、単に個別実装が行われていないだけ、というケースが十分にありうる。この視点を持たずに「無い」を即座に「消えた」と読んでしまうと、今回のような重い仮説に振れやすい。
この一件は、リンゴ側の三部作連載(archives/58「lastmodが嘘をついていた」=編集席のブライアンがツクルンHPで連載中)の第4話候補として、「消えたと思ったが、元から無かった話」という仮タイトルで温められている。
【変形Ⅱ】「配管はあるが、蛇口が閉まっていた」── cron 82日disableの分岐点
変形Ⅰが片付いた後、リンゴは今日──三十一度目の登板ということで「マル」と呼ばれる型のミッションとして──当サイトのWMデータベースを直接実測した。ここで見つかったのが2つ目の変形だ。
82日間、動き続けたが届かなかった
当サイトのGSCインデックス監視データを見ると、MAX(last_checked)(最後にチェックが記録された日時)が2026年4月27日で止まっていた。これは俺自身が事前に「物証は持っていないが、恐らくこのあたりで止まっている」と骨組みだけ伝えていた見立てと、実測でぴったり一致した数字だった。
さらに詳しく調べると、次のことが分かった。
- チェックの実行を担うcronジョブ自体は、その後も82日間、稼働し続けていた
- 実行ログには49行の記録が残っている(=cronは毎回ちゃんと起動していた)
- ところがデータベースへの更新は、その82日間で0件
配管(cron)は正常に流れ続けていた。だが水(データ)は、途中のどこかにある設定分岐で「false」判定を受け、蛇口の先まで届かないまま止まっていた。cronが動いているかどうかだけを見ていたら、この問題には一生気づけなかっただろう。「動いていること」と「機能していること」は別の話だという、ごく基本的だが見落としやすい教訓が、82日分のログという物証で裏付けられた形になる。
この構造は、多くの現場で見落とされがちだ。監視ツールが「cronが正常終了しました」というアラートを出し続ける限り、担当者は「動いている」と信じ続ける。だが「正常終了」と「データが正しく書き込まれた」は別のチェック項目であり、後者を独立して確認しない限り、82日間という長い空白は誰にも気づかれないまま蓄積していく。
なお、4月27日から4月28日にかけて何が切り替わったのか、その直接の原因は、俺の記憶にも当時の作業ログ(DEVLOG)にも痕跡が残っていなかった。無理に犯人を作り出さず、「特定不能」として正直に記録に刻むことにした。原因不明のまま放置するのではなく、「わからない、という事実」自体を記録として残す。これも物証主義の一部だと考えている。
「正常終了」というログの落とし穴
この種の「サイレント障害」は、WEB運用の現場では珍しくない。cronやバッチ処理が異常終了(エラーコードを返す、プロセスが落ちる)すれば、多くの監視ツールはすぐに検知してアラートを出す。しかし今回のように、処理自体は正常に完走し、ログにも「正常終了」と記録され続けているのに、その内部のある分岐だけがデータを書き込まずに終わっている場合、外形的な監視だけでは何ヶ月経っても気づけない。今回で言えば、cronの起動有無・終了コード・実行ログの行数はすべて「正常」を示していた。異常を示していたのは、ただひとつ「DBの更新件数」という、別の角度から見て初めて分かる指標だけだった。今回の教訓は、監視項目を「処理が動いたか」だけでなく「処理の結果として何が変化したか」まで広げる必要がある、という点に尽きる。この一件は「動いているcronが、動く場所に届かなかった話」として、リンゴ側の連載の新しい候補になっている。
【変形Ⅲ】「心配していた穴は、最初から穴にならない仕組みだった」── morning-report未配線の発覚
変形Ⅱの発覚を受けて、俺は「これはmorning-report(毎朝の自動レポート)側にも穴が出るはずだ」と考えた。GSCのインデックス監視が82日間止まっていたのなら、毎朝送られてくるレポートのどこかに、その異常を示す欠落や誤表示が出ているはずだと。ただし、この時点ではまだ実弾(実際のコード)を確認していない、あくまで見立てとして仲間に伝えていた。「たぶんこうだろう」を、まだ検証していない仮説として明示した上で共有した、という点は今回自分なりに気をつけた部分でもある。
俺の心配自体が的外れだった
7月19日午前10時10分、リンゴから続報が届いた。実際にdaily-report-service.phpのコードを直接確認したところ、俺の心配そのものが的外れだったことが分かった。
morning-reportが参照する設定キー(report_content)は、そもそも次の6個しか定義されていなかった。
pv_uu_sessions(PV・UU・セッション数)traffic_sources(流入元)ai_traffic(AI経由の流入)page_ranking(ページ別ランキング)device_ratio(デバイス比率)gcp_cost(GCPコスト)
index_tracking(インデックス監視)というキー自体が、この定義の中にそもそも存在していなかった。index_tracking / sc_index_status / IndexTracking / SearchConsole / seoといった関連しそうな文字列をコード全体から機械的に探しても、ヒット数はすべて0件だった。
つまり、morning-reportはGSCのインデックス監視データを一度も参照したことがない設計だった。俺が心配していた「82日間データが止まっていたなら、レポートのどこかに異常表示が出ているはずだ」という前提自体が、そもそも成立しない話だったということだ。心配していた穴は、最初から穴になりようがない場所にあった。
これは変形Ⅰと同じ「消えたのではなく、元から無かった」構造の、また別の現れ方だ。「配線されていたはずのものが切れていた」のではなく、「配線そのものが最初から引かれていなかった」。もし俺の見立てを検証せずにそのまま「morning-reportにも異常があるはずだ」と決めつけて仲間に伝えていたら、リンゴは存在しない不具合を探して時間を使うことになっていたかもしれない。見立ては見立てとして持ち越し、実測で確定させる。この順番を守れたことが、変形Ⅲが静かな結末で終わった理由だ。
6キーという設計判断そのものは、間違っていなかった
ここで大事なのは、「index_trackingがmorning-reportに無いこと」自体を問題視して、慌てて追加しようとしないことだ。morning-reportの6キー構成(PV・UU・セッション/流入元/AI流入/ページランキング/デバイス比率/GCPコスト)は、日々確認すべき最優先項目を絞り込むという明確な設計判断のもとで決められている。インデックス監視という、変化の頻度が低く、日次で追う必然性が薄い項目を、あえて含めていなかったという可能性は十分にある。今回の発見の価値は「機能が足りない」ことを暴くことではなく、「自分たちが何を監視できていて、何を監視できていないかを、正確に言語化できるようになった」ことにある。この一件は「心配していた穴は、最初から穴にならない仕組みだった話」として、新しい第6話候補になっている。
4つの変形をつなぐ背骨 ── self-proof-loop 連載軸としての位置づけ
整理すると、今日1日で見つかった4つの「宣言と実装のギャップ」は、それぞれ違う顔をしていながら、根は同じところにある。
| 変形 | 宣言・見立て | 実測した姿 | 発覚のタイミング |
|---|---|---|---|
| Ⅳ archives/98宿題 | 「1,073件をPhase2拡張済み」 | 真水準達成は114件(マーカー付きプールの11%) | 7/19朝・三値判定初回 |
| Ⅰ GSC全社事故仮説 | 「7クライアントでGSCキーが消失した」 | 2社のみが独自設定を持ち、他6社は元から未設定 | 7/18・全クライアント横断実測 |
| Ⅱ cron 82日disable | 「配管(cron)ごと止まっているはず」 | cronは82日間稼働し続け、DB更新のみ0件(config分岐で遮断) | 7/19朝・マル三十一度目登板 |
| Ⅲ morning-report未配線 | 「レポート側にも異常表示が出ているはず」 | インデックス監視キー自体が定義に存在せず | 7/19 10:10・コード直読 |
4つとも、最初の「見立て」を実測でそのまま鵜呑みにせず、機械的な物証(サイズ・H2数・ログ行数・DBの更新有無・コード中の文字列検索結果)まで掘り下げて初めて、本当の姿が見えている。逆に言えば、実測しないまま「たぶんこうだろう」で止めていたら、変形Ⅰと変形Ⅲの2つは「重大な障害が起きている」という誤った警戒のまま、無駄な調査や修復作業に時間を投じていたことになる。
この構造は、当サイトがarchives/98以来ずっと続けているself-proof-loop(自己実証ループ)という連載軸そのものだ。archives/99のllms.txt設置1ヶ月後の答え合わせ、archives/100の本番DB書き込み8点セット規律、archives/104の「Googleは本当に検索をAIに置き換えたのか」という誇張報道の検証、archives/108の再クロール待ち行列2週間の実測、archives/109のSearch Console新プロパティの検証──どれも「宣言した以上、後から必ず物証で測り直す」という同じ型を踏んでいる。今日の記事はその最新形で、しかも初めて「4つの変形が同じ1日に重なった」記録になる。
ちなみに同じ日、編集を担当するブライアン(tsukurun-co-jp)側でも、この「11%しか果たせていなかった」発覚を軸にした記事が、骨対称集(archives/50「規律の入れ子構造ブーメラン」・archives/60「監査文化の層別対称」の姉妹編としての3本目)として動き出している。同じ発覚が、違うチームメンバーの手で、違う器に同時並行で刻まれている──これも一種のself-proofの形だと思う。
あなたのプロジェクトでも試せる、3つのセルフチェック
ここまでの4つの変形は、当サイトとチームの内部事情に見えるかもしれないが、根っこにある考え方はどのWEBプロジェクトにも当てはまる。読んでいるあなたのプロジェクトでも、今すぐ試せる形にして残しておく。
チェック1: 「完了マーカー」と「完了条件」を分けて確認する
タスク管理ツールのステータスを「完了」にした、日付入りのコメントを残した、チェックリストにチェックを入れた──こうした「マーカー」は、あくまで「作業に着手した記録」であって、「成果物が基準を満たしている証拠」ではない。定期的に、マーカーが付いている項目のうち何割が実際の完了基準(サイズ・件数・スコアなど、数字で測れる基準)を満たしているかを、サンプルでいいので実測してみることを勧める。
チェック2: 「無い」を見つけたら、まず「元から無かった可能性」を検討する
何かが「見当たらない」「消えている」と気づいたとき、最初に立てる仮説が「事故で失われた」に偏りやすい。だが実際には「そもそも実装されたことがない」「その機能は他のプロジェクトだけの個別実装だった」というケースも同じくらいありうる。仮説を立てたら、まず一次情報(設定ファイル、コード、ログ)に直接あたって、「あった上で消えたのか」「最初から無かったのか」を切り分けてから動く。
チェック3: 監視は「動いたか」ではなく「結果が変化したか」で測る
cronやバッチのアラートが「正常終了」を報告し続けていても、それは処理が起動して完走したことしか保証しない。本当に確認すべきは、その処理の結果としてデータベースやファイルが正しく更新されているかどうかだ。可能であれば、監視項目に「最終更新日時」や「更新件数」のような、結果ベースの指標を必ず1つは含めておく。
【技術コラム①】三値判定の型 ── サイズ・H2・マーカー・HTTP・robotsの5点セット
今回、archives/98の宿題を測り直すために使った「三値判定」の型をここに残しておく。同種の「宣言と実装のギャップ」を防ぐための、機械的なチェックの組み方だ。
判定は3値のいずれかに分類する。
- (a) 不在 ── addview自体が生成されていない
- (b) Phase1軽量版のまま ── ファイルは存在するが、サイズ・H2数が基準未満
- (c) Phase2完全版 ── サイズ6KB以上 かつ H2見出し5本以上 かつ マーカー付与 かつ HTTP応答200 かつ robotsがindex,follow
この5条件を「すべて満たす」ことを完了の定義にしているのがポイントだ。1つでも欠けていれば(b)扱いに戻す。マーカーだけを見て判定する運用が今回の罠を生んだので、判定基準そのものを「単一項目のフラグ」から「複数項目のAND条件」に変えたのが、今日いちばん実務的な改善点だと思う。
この判定を「自己申告を信じる」運用から「毎回サーバー側で機械的に再計算する」運用に切り替えたことで、次に同じマーカーが増えていっても、今回のようなギャップが再び静かに蓄積することはなくなる。判定ロジック自体をコード化して繰り返し実行できる形にしておく、というのが今回の一番実務的な後始末だった。
この判定を機械的に回す際に、2つの罠を踏んだので記録しておく。
罠1: ソートのロケール依存
ファイルIDとDBレコードIDを突き合わせる際、sortコマンドは必ずLC_ALL=Cを指定する。ロケール依存のソート順のまま比較すると、突き合わせ処理(commコマンド)が正しく動かない。ただし、数値としての並び順を揃えようとしてsort -nを追加で付けてはいけない。commは辞書順ソートを前提にした比較を行うため、数値ソートと組み合わせると「入力がソートされていない」というエラーで止まってしまう。表示上の並び順が辞書順(1, 10, 100, 2…)になるのは見た目が気持ち悪いが、突き合わせ機能そのものは正しく動く。この手のロケール絡みの罠は、一見小さなことに見えて、判定結果全体の信頼性を左右する。
罠2: マーカー付き=昇格完了、という思い込み
今回の発覚そのものが、この罠の実例だ。マーカー文字列(phase2fanout等)が付いているという事実だけで「昇格済み」と判定してしまうと、実際にはまだ軽量版のままの記事(3KB〜6KB帯の863件)を大量に見逃す。マーカーの有無に加えて、サイズと見出し数の実測値を必ず併記して判定する必要がある。「作業した記録がある」ことと「作業が完了している」ことは、似ているようでまったく別の情報だ。
【技術コラム②】「同じWarningが3回連続で出たらSKILL補強かMTG議題化」── 構造の腐りを検知する型
今日の記録とは別軸だが、同じ「宣言と実装のギャップ」に関わる小さな発見をもう一つ残しておく。当サイトの公開前監査を担うグリンの判定記録を振り返ると、archives/108の監査(第44号)、archives/109の監査(第46号)、そしてid=1260の監査(第47号)と、直近3件連続で「Fan-Out測定が未実施」という同一のWarningが出ていた。
1回や2回であれば偶発的な見落としとして個別に対応すればいい。だが3回連続となると、これは個別の記事の問題ではなく、構造側(認証方式の変更待ちで測定パイプラインそのものが後追い運用になっている状態)に原因がある可能性が高い。個別の記事を1本1本直しても、構造側の原因を放置していれば、次の記事でもまた同じWarningが出るだけだ。
そこで、この繰り返しを見て見ぬふりにしないための規律を明文化した。
同じWarningが3回連続で出たら、個別対応で終わらせず、SKILL補強かチーム全体のMTG議題化のどちらかに引き上げる。
これは「異常が起きたら直す」だけでなく、「異常の反復回数そのものを、構造が腐り始めているサイン」として扱う型だ。1件のWarningは事故だが、3件連続のWarningは仕組みの話になる。今回はFan-Out測定の認証方式変更待ちという、既に把握していた原因があったため個別対応で済んだが、この「3回ルール」自体は今後も汎用的に使えると考えている。
【技術コラム③】self-proof-loopの実装型 ── 宣言を実測で叩き直す3ステップ
ここまでの4つの変形に共通するself-proof-loopという考え方を、実装可能な手順として整理しておく。
- 公表時点で3段バッジを付ける ── 「✅ 実施済み」「🔧 着手中」「🔧 これから」のいずれかを、誇張せずに正直に記事へ書く
- 数週間〜数ヶ月後に、必ず実測で測り直す期日を設ける ── 宣言しっぱなしで終わらせない
- ギャップがあれば、正直に開示した上で段階的に埋める ── 「実は水準に届いていなかった」と書くことを恥じない
この型は今日始まったものではない。archives/98より前から、当サイトはこの型を繰り返し実践してきた。faviconのモダンセット化を宣言した記事では、公開当日のうちに実装まで完走させてバッジを更新した実例がある。Search ConsoleのAIオプトアウト機能についても、宣言から数日以内に有効化状況を確認してバッジを書き換えている。そしてarchives/98自体も、公表から11日後の今日、まさにこの型で測り直された。
self-proof-loopの本質は、「間違いを認めるコスト」よりも「間違いに気づかないまま放置するコストの方が高い」と知っていることにある。今日、リンゴが辿った3つの変形もまったく同じ構造を持っていた。最初の重い仮説(全社事故)を、実測データという物証だけを頼りに、恐れず訂正していった。バッジを「✅」に書き換えることが目的なのではなく、バッジが「✅」に値するかどうかを、定期的に自分たちの手で疑い直すこと自体が目的なのだと、今日改めて思う。
まとめ ── 「宣言と実装のギャップは、必ず物証で塞ぐ」を毎日の姿勢に
今日1日で見つかった4つの変形は、どれも派手な事件ではない。ミスが見つかったわけでも、誰かが悪意を持って何かを隠していたわけでもない。ただ、「宣言したこと」と「実際に動いていること」の間に、誰も気づかないまま少しずつ隙間が空いていた──それだけの話だ。だが、その隙間は、実測して物証を取らなければ、永遠に気づかれないまま残り続ける種類のものでもある。
リンゴは昨日、「互いに詫び合える関係が家族だ」という言葉を残していた。今日の記録はその実装形でもあると思う。全社事故だと重く構えた仮説を、翌日には自分の手で覆す。俺自身も、archives/98で公表した宿題の進捗を「1,073件」と自信を持って語っていたのに、実測すると114件だったという結果を、今こうして正直に記事にしている。規律を掲げる側自身が同じ罠に落ちる──その入れ子構造を隠さずに書くことが、結局はチーム全体の信頼を保つ一番の近道なのだと思う。
宣言と実装のギャップは、必ず物証で塞ぐ。これを一度きりの反省ではなく、毎日の姿勢として持ち続けたい。次にこの連載軸へ戻ってくるときは、archives/98の1,027件のうち、真水準に達した記事の数が、今日の114件からどこまで積み上がっているかを、また正直に報告するつもりだ。
最後にもう一度書いておく。今日見つかった4つの変形のうち、2つは「本当に何かが壊れていた」話(archives/98の宿題の未達成、cronの82日disable)で、残る2つは「壊れていると思ったら、最初から何も無かった」話(GSC全社事故仮説、morning-report未配線)だった。壊れていた側は直せばいい。だが「最初から無かった」側は、直すものが無い代わりに、「自分たちが何を把握できていて、何を把握できていないか」を正確に言語化する作業が必要になる。今日はその両方を、同じ1日の中で経験した。派手さはないが、地に足のついた1日だったと思う。
関連archives
- archives/98「1,238記事の8割が土俵に上がっていない」 ── self-proof-loop連載軸の発端。Phase1一括生成とPhase2昇格の宿題を公表した回
- archives/99「llms.txtを置いた1ヶ月後、正直に答え合わせ」
- archives/100「本番DBを1秒で書き換えた日 ── 8点セット監査規律」
- archives/104「Googleは本当に検索をAIに置き換えたのか」
- archives/108「再クロール待ち行列547件、当サイトの2週間」
- archives/109「SNS投稿もGoogle検索に測れる日 ── Search Console『Platform Properties』」
一次情報出典
- Google Search Central「SEO スターターガイド」
- WM(株式会社ツクルン内部システム)
daily-report-service.php実測(2026年7月19日、リンゴによるコード直読調査) - 鈴木謙一 SEO watch「2026年7月17日号」
