WEBサイト
タイトルで探すと 45組。元記事のURLで探すと 139組。同じ当サイトの、同じ1,291本を、同じ「重複を探す」という目的で数えただけなのに、答えは3倍 違った。
2026年8月17日、当サイトは実務記事（seo_article）の作り方をゼロから見直す作業を始めた。書き直すかどうかを決める前に、まず「そもそも今、何本あるのか」「そのうち何本が重複しているのか」を確かめる必要があった。そこで思い出したのが、前日に公開したarchives/128「出力は在った。だから誰も測らなかった」だ。あの記事は、datePublishedやog:typeのような「値が入っているのに、中身が間違っている」穴を4つ扱った。今回はそれとは少し違う。値そのものは正しい。ただ、同じ内容が複数の記事として別々に存在していた。
重複を数える方法を1つだけ試して「45組」という数字を出したところで、ふと気づいた。この45組という数字は、たまたま「タイトルが完全に一致する」という条件で数えただけの結果ではないか。条件を変えたら、数字はどう動くのか。試したら、3倍になった。
「重複コンテンツ」という言葉自体は、SEOの世界では珍しくもない。だが、多くの解説記事は「重複を見つけたら統合しよう」という対処の話から始まる。今回引っかかったのはその手前だ。「見つけたつもりの重複」が、本当に重複の全体だったのかを確かめないまま、対処に進みかけていた。この記事は、その過程と、読者が自分のサイトで同じことを5分で確かめるための3つの方法を書く。
1. 実測：当サイトで重複を数えてみた
分母をどう決めたか
当サイトの実務記事は、記事管理用のテーブルにまとめて入っている。収集済みであることを示す有効フラグが立っているレコードを数えると 1,291本（2026年8月18日 15時 時点）。これが今回の分母だ。分母を確定させずに「N組見つかった」とだけ報告すると、その数が多いのか少ないのか誰にも判断できない。だから、まず対象の全体を数えるところから始めた。
分母を確定させる作業は地味だが、ここを飛ばすと後の数字がすべて宙に浮く。「重複が139組ある」と言われても、対象が10本なのか10,000本なのかで受け取り方はまったく違う。自分のサイトで同じ調査をするときも、まず「対象は何本か」を1行で言えるようにしてから、重複の照合に進む方がいい。
タイトルの完全一致で数えると 45組
最初に試したのは一番手軽な方法だった。記事タイトルが一字一句同じレコードをグループ化する。
SELECT title, COUNT(*) AS cnt
FROM articles
GROUP BY title
HAVING cnt > 1
ORDER BY cnt DESC;結果は 45組。1,291本のうち、タイトルが他のどれかと完全に一致する記事が複数含まれていた。「よし、この45組を1本ずつ確認して統合しよう」と、そのまま作業に入りかけた。ここで一度立ち止まったのが、今回の分かれ道になった。
元記事URLの完全一致で数えると 139組
当サイトの記事管理には、もう1つ手がかりになるカラムがある。実務記事の多くは業界ニュースの要約として作られているため、「どの記事をもとに書いたか」を示す元記事のURLをレコードごとに保持している。このURLで同じグループ化をかけ直した。
SELECT url, COUNT(*) AS cnt
FROM articles
WHERE url <> ''
GROUP BY url
HAVING cnt > 1
ORDER BY cnt DESC;結果は 139組。重複に含まれる記事の本数を合計すると 460本で、分母1,291本の35.6%にあたる。タイトルで探した45組の、約3倍だ。同じデータベース、同じ1,291本を対象に、同じ「重複」という目的で数えているのに、数える列を1つ変えただけで結果が3倍に開いた。
この SQL には1つだけ条件が要る。WHERE url <> '' がそれだ。書き直しが終わった記事は、元記事のURLを空にしてある。もう他社記事の要約ではなく、自分たちで書いたものだからだ。この条件を付け忘れると、URLが空の記事どうしが「同じURLを持つ1つのグループ」として数えられてしまう。
これは実際に踏んだ。この記事を書く途中で同じ集計をやり直したとき、条件を付けずに走らせて 140組 という値が出た。1組だけ多い。最初は「データベースが変わったのだろう」と考えたが、変わっていたのは条件のほうだった。同じ時刻に条件付きで測り直したら、139組のままだった。
数字が食い違ったとき、まず疑うのはデータの変化ではなく、数え方の条件だ。
🔧 当サイト着手中 ── 139組のうち、実際に統合を終えたのはまだ2組だけだ（301リダイレクトで463番の記事を462番へ、1014番・1015番の記事を212番へ統合済み）。残り137組は、どちらを正規のURLとして残すかの判断待ちで並んでいる。
2. なぜ3倍の差が出たのか
組の大きさの分布
139組の内訳を、1組あたりの本数で数え直してみると、次のような分布になった。
| 組の本数 | 組の数 | 含まれる記事の延べ本数 |
|---|---|---|
| 11本 | 1組 | 11本 |
| 9本 | 1組 | 9本 |
| 8本 | 9組 | 72本 |
| 7本 | 2組 | 14本 |
| 6本 | 8組 | 48本 |
| 5本 | 12組 | 60本 |
| 4本 | 11組 | 44本 |
| 3本 | 12組 | 36本 |
| 2本 | 83組 | 166本 |
一番多いのは「2本だけ重複している」組で、83組（全体の約6割）。だが最大の組は11本もの記事が、同じ1本の元記事から作られていた。表を眺めると、2本の組が突出して多く、そこから3本、4本と本数が増えるにつれて組の数は減っていく。よくある偏りの形だ。だが、この「よくある形」に安心してはいけない。1組あたりの本数が少ないからといって、その組が見つけやすいとは限らないからだ。
同じ素材から複数の切り口で要約された記事
3倍の差が出た理由は単純だ。同じ元記事を読んで要約するとき、要約する人（今回はAIによる自動生成）が毎回まったく同じタイトルをつけるとは限らない。ある回は「クリック率」に注目したタイトルを、別の回は「業界動向」に注目したタイトルをつける。中身の骨格は同じでも、タイトルだけを見ると別の記事に見える。
タイトルの一致だけを見ていると、この「切り口が違うだけの重複」がまるごと見えなくなる。94組（139組から45組を引いた差）が、タイトル一致という網の外側にいた。これは全体の68%にあたる。当サイトが最初に出した「45組」という数字は、正しい数字ではあったが、重複全体の3分の1にも満たなかった。
この原因は、当サイトに限った話ではないはずだ。複数の書き手・複数のツールで記事を量産しているサイト、ニュースをまとめて紹介するキュレーション型のサイト、あるいは古い記事をリライトして再公開する運用をしているサイトは、同じ構造で重複が生まれやすい。1人がタイトルだけ変えて実質同じ内容を書き直す、複数の担当者が同じ話題を知らずに別々に書く、といった場面は珍しくない。「うちはタイトルの管理ができているから大丈夫」という前提が、そもそも成り立たないことがある。
3. 最大の重複組（11本）を開いてみる
11本のうち4本はタイトルまで完全一致していた
先ほどの表で最大だった「11本」の組を、実際に開いてみた。ある1本の元記事（業界ニュース1本）から、11本の実務記事が作られていた。そのうち4本は、タイトルまで一字一句同じだった。
「AIモードのリンククリックは3%未満!? 見えてきた『AIモードの適切な位置づけ』【SEO情報まとめ】」
この1本のタイトルが、4回そのまま使われていた。これは45組（タイトル完全一致）のうちの1組として、すでに検出できていたはずの重複だ。ここまでは、方法①だけでも見つけられる範囲にある。
残り7本はタイトルを見ても気づけない
問題は残りの7本だ。同じ元記事から作られたにもかかわらず、それぞれ違うタイトルがついていた。実際のタイトルを3本だけ挙げる。
- 「【2026年6月追記】AIモードのクリック率は依然低いまま — AI時代のKPIの組み直し方」
- 「AhrefsがAI連携『リモートMCPサーバー』提供、高度なSEO分析と戦略立案をノーコードで」
- 「サイトリニューアルで、SEO用語を使わずに事業サイドとのやりとりとSEOを円滑に進める方法」
この3本を並べて読んでも、同じ元記事から作られたとは誰も気づかない。1本目は「クリック率」の話に見える。2本目は「AI連携ツール」の紹介に見える。3本目にいたっては「事業サイドとのやりとり」という、一見まったく別のテーマに見える。要約する側が元記事のどの段落に注目するかによって、出てくるタイトルはここまで離れることがある。
残りの4本のタイトルも並べる。
- 「AI向けライティングの超重要ポイントを渡辺隆広氏が紹介、これは押さえなきゃ損だ【SEO情報まとめ】」
- 「AIモード経由クリックが3%未満 — 権威ドメイン集中とCVR50%増、5つの実態指標」
- 「コンテンツ改修の優先順位付けをどう考えるか — AIを活用したコンテンツ分析でできること・できないこと」
- 「2025年、AIがSEO戦略の主流になる──検索行動変化とAI活用データ分析」
7本すべてを見渡すと、「クリック率」「執筆術」「分析ツール」「事業サイドとの調整」「コンテンツ改修」「戦略全体」と、切り口がばらばらに散っている。しかし元をたどれば、すべて同じ1本の記事から生まれている。人が7本を順番に読んでも、7つの独立した話題として受け取るはずだ。
タイトルだけで重複を探す方法は、この7本を1本も見つけられない。そして、この11本の組は139組のうちのたった1組にすぎない。同じ構造の見落としが、残りの138組にも潜んでいる可能性がある。方法①だけを実行して「45組見つけたので調査完了」と報告していたら、この見落としに気づく機会は無かった。数を数え終えたことと、探すべき対象を数え終えたことは、別の話だった。
4. 方法① タイトルの完全一致で照合する
SQLでの照合手順
もう一度、方法①を整理する。データベースを直接見られる環境なら、先に挙げたSQLで一発だ。データベースにアクセスできない場合は、記事一覧をCSVやスプレッドシートでエクスポートし、タイトル列を選んで「重複データの検出（重複の削除プレビュー）」機能を使えば同じことができる。多くの表計算ソフトに標準で入っている機能で、専門的な知識は要らない。
この方法の限界
今回の実測で分かった通り、この方法はタイトルを変えて書き直された重複を検出できない。当サイトの場合、139組のうち94組がこの盲点に入っていた。比率にすると約68%だ。「タイトル一致だけで重複調査は終わり」と判断するのは早い。だからといって方法①が無意味というわけではない。所要時間5分でできる方法として、まず最初にかける価値はある。ただし、それで見つかった数字を「重複の全体像」として扱ってはいけない、というのが今回の実測が示した結論だ。
この記事のタイトルにある「5分」の内訳を書いておく。データベースやCMSの管理画面を開く（1分）、方法①のクエリまたはスプレッドシート機能を実行する（1分）、結果の件数を確認する（1分)、母数と照らし合わせて「多いか少ないか」を判断する（2分）。ここまでで5分になる。ただし、これはあくまで「タイトル一致という1つの網をかけ終える」までの時間であり、方法②③まで含めた「重複の全体像を確かめる」時間ではない。この違いを取り違えないことが、今回の実測でいちばん伝えたい点でもある。
5. 方法② 本文の内容で照合する
冒頭文字列のハッシュ化
タイトルに頼らず本文そのものを比較する方法がある。本文をタグなしのテキストに正規化し、冒頭のN文字（たとえば300字）だけを取り出してハッシュ値を計算し、同じハッシュ値を持つ記事をグループ化する。
import csv, hashlib, re, html
from collections import defaultdict
groups = defaultdict(list)
with open("articles_export.csv", encoding="utf-8") as f:
for row in csv.DictReader(f):
body = re.sub(r"<[^>]+>", "", row["body"])
body = html.unescape(body)
body = re.sub(r"\s+", "", body)
key = hashlib.md5(body[:300].encode("utf-8")).hexdigest()
groups[key].append(row["id"])
for key, ids in groups.items():
if len(ids) > 1:
print(key, ids)タグを取り除き、実体参照を戻し、空白を除去してから比較する手順は、当サイトが文字数を数えるときに使っている正規化と同じ形にしてある。archives/128で「測り方を1つに固定しないと、同じ本文でも複数の答えが出る」と確認したのと同じ理由だ。文字数を測るときも、重複を照合するときも、比較の前に「何を数えているか」をそろえておかないと、答えが実装ごとに揺れてしまう。
冒頭300字という数字に絶対的な根拠は無い。短すぎると別の記事の書き出しがたまたま一致する誤検出が増え、長すぎると加筆・修正された記事を見逃しやすくなる。自分のサイトの記事の平均的な導入部分の長さを見て、100〜500字の範囲で試し、実際にどの程度の組が見つかるかを確認しながら調整するのが現実的だ。数字を1つに決め打ちせず、複数の長さで試してみる方が安全になる。
全文ハッシュとの使い分け
冒頭だけを比較する理由は、記事の後半が加筆・修正されていても、書き出しの数百字が同じなら「元は同じ記事」として検出できるからだ。逆に、記事全体が完全に同一かどうかを確かめたいときは、正規化した本文全体をハッシュ化する。冒頭だけだと「導入だけ流用して本文は別物」という誤検出のリスクがあるので、疑わしい組が出たら全文ハッシュで二度確認するのが安全だ。この2段構えは手間が増えるが、片方だけでは正反対の方向に外れることがある。冒頭一致だけを信じると誤検出が増え、全文一致だけを信じると見逃しが増える。
6. 方法③ 見出し構成で照合する
h2の並びを連結してハッシュ化する
3つ目は、本文の見出し（h2タグ）だけを抜き出して、その並び順を比較する方法だ。
import re, hashlib
from collections import defaultdict
groups = defaultdict(list)
for row in rows: # 同じCSVエクスポートを想定
headings = re.findall(r"<h2[^>]*>(.*?)</h2>", row["body"], re.S)
headings = [re.sub(r"<[^>]+>", "", h).strip() for h in headings]
key = hashlib.md5("|".join(headings).encode("utf-8")).hexdigest()
groups[key].append(row["id"])この方法の強みは、本文の言い回しがまるごと書き直されていても、記事の骨格（見出しの並び）が同じなら見つけられることだ。逆に、見出しごと構成し直された記事には効かない。3つの方法はどれも一長一短で、どれか1つが万能というわけではない。
3つの方法の使い分け
| 照合方法 | 必要なもの | 強み | 弱点 |
|---|---|---|---|
| ①タイトル完全一致 | タイトル列だけ | いちばん手軽。表計算ソフトでも可能 | 書き直されたタイトルは検出できない（当サイトで94組を見逃した） |
| ②本文のハッシュ照合 | 本文をテキストで抽出できること | タイトルが違っても、内容が同じなら見つかる | 一部改変された組は、冒頭・全文のどちらか一方でしか一致しないことがある |
| ③見出し構成のハッシュ照合 | 見出しタグ（h2等）が本文に入っていること | 言い回しが違っても、構成が同じなら見つかる | 見出しごと書き直されると効かない |
当サイトが今回実際に数えられたのは①（45組）と、当サイト固有の元記事URL照合（139組）の2つだけだ。多くのサイトは、当サイトのような「元記事URL」の列を持っていない。自分で書いた記事には、そもそも参照元という概念が無いことが多いからだ。だからこそ②③のような、本文そのものから重複を見つける方法が必要になる。🔧 当サイト着手中 ── ②③はまだ当サイトの全1,291本に対して実行していない。定期チェックに組み込む作業は、これから着手する。
もう一点、注意しておきたいことがある。②③で「一致」が見つかったからといって、それが必ずしも「不要な重複」とは限らない。たとえば、業界で毎年のように語られる定番トピックについて、別々の時期に独立して書いた記事は、見出しの並びが似通うことがある。これは本当の重複ではなく、テーマが定番であることの結果だ。ハッシュ値の一致は「同じ可能性が高い候補」を絞り込むための道具であって、それ自体が「削除すべき」という判断を意味しない。最終的な判断は、人が本文を開いて確認してから下す。
7. 陰性対照 ── 自分で書いている記事では、重複は0組だった
同じCMS・同じ仕組みでも、書き方次第で防げる
ここで、比べる対象を変えてみる。当サイトには、実務記事（seo_article）とは別に、筆者が1本ずつ手で書いているAI Ronブログがある。この記事も含めて128本ある。同じデータベース、同じCMSの仕組みで、まったく同じタイトル完全一致のクエリをかけた。
結果は0組。128本のうち、タイトルが完全に一致するペアは1つもなかった。
この差は、CMSの仕組みの問題ではないことを示している。実務記事(seo_article)は、同じ元記事を複数回、別々のタイミングで要約する運用になっていたため重複が生まれた。AI Ronブログは、1本ずつテーマを選んで書いているため、そもそも同じ話を2回書く構造になっていない。同じ土台の上でも、作り方が違えば重複の出方はまったく違う。これが今回、比較対象として置いた陰性対照だ。
ただし、この0組という結果を「AI Ronブログには重複防止の仕組みがある」と読むのは早い。実際には、AI Ronブログにも既存記事とタイトルを機械的に突き合わせる工程は無い。0組だったのは、1本ずつテーマを選んで書くという執筆スタイルの結果、そもそも同じ話を選ぶ機会が少なかったからだ。つまり今回の陰性対照が示したのは「実務記事側の仕組みに欠陥がある」ということではなく、「同じ元記事を複数回・別々のタイミングで要約する」という運用そのものが重複を生みやすい形だった、ということだ。原因を「仕組み」ではなく「運用」に置いたのは、この対照があったからこそ言える。
陰性対照を置く考え方は、archives/124「猫のファイルが『効いている証拠』を無効化した日」で扱った内容と同じ骨だ。「重複が多い」という結果だけを見ても、それが仕組みの問題なのか運用の問題なのかは分からない。重複が出ない対照群を並べて、はじめて切り分けられる。今回の場合、実務記事とAI Ronブログは同じテーブル構造・同じ管理画面を使っている。もし重複が「システムの仕様」だったなら、AI Ronブログ側にも同じ比率で重複が出ていたはずだ。0組という結果は、原因が「作り方」の側にあることを裏付けている。
8. 重複が生むかもしれないもの、そして断定できないこと
当サイトのケースは「同じ元記事を複数回要約した」という、やや特殊な原因だった。だが、重複コンテンツが生まれる原因はそれだけではない。Googleのドキュメントでは、サイトに重複が生まれる典型的な原因として、地域別に用意した内容がURLだけ違う「地域バリアント」、スマートフォン版とPC版で別ページになる「デバイスバリアント」、httpとhttpsの両方が生きている「プロトコルバリアント」、並び替えや絞り込み機能が生成する「サイト機能によるもの」、開発中のページがそのまま公開されてしまう「意図しないもの」の5種類を挙げている。自分のサイトに重複があるかを調べるときは、当サイトのような「同じ話を2回書いた」パターンだけでなく、この5種類にも思い当たる節が無いかを合わせて確認すると見落としが減る。
カニバリゼーションの仮説
同じテーマの記事が複数存在すると、検索結果での評価が1本に集約されず、複数の記事に分散する可能性がある、というのはSEOの世界でよく語られる話だ。Google自身も、この現象について公式ドキュメントで説明している。
"Some duplicate content on a site is normal and it's not a violation of Google's spam policies. However, having the same content accessible through many different URLs can be a bad user experience (for example, people might wonder which is the right page, and whether there's a difference between the two) and it may make it harder for you to track how your content performs in search results."
（日本語訳: サイト内にある程度の重複コンテンツがあるのは普通のことで、Googleのスパムポリシー違反にはあたらない。ただし、同じ内容が多くの異なるURLからアクセスできる状態は、ユーザー体験を損なう可能性があり（たとえば、どちらが正しいページなのか、2つに違いがあるのかを読者が迷うことがある）、また自分のコンテンツが検索結果でどう機能しているかを追跡しにくくする可能性がある）
ここで書かれているのは「ユーザー体験を損なう可能性」と「パフォーマンスを追跡しにくくする可能性」の2点だ。「順位が下がる」とは書かれていない。断定的な因果関係ではなく、可能性として語られている点に注意したい。この一次情報を確認せずに「重複があるから順位が下がる」と書いてしまうと、公式の見解より強い主張を、当サイトが勝手に作ってしまうことになる。原典に当たる作業は、記事を厚くするためではなく、書きすぎないために要る。
確かめる手段が無いと正直に書く理由
当サイトの139組・460本について、「重複が表示回数を分散させたかどうか」を、当サイトの実測データで確かめようとした。だが、これは断定できない。Search Console のデータは、クエリ別の集計とページ別の集計が別々の勘定になっており、「このクエリの表示回数が、どのページに何回ずつ配分されたか」を、重複ページ同士で突き合わせる形では取り出せない。
「そう見えるが、確かめる手段が当サイトには無い」というのが、今回の正直な到達点だ。断定せずに、確かめられなかったことをそのまま書く。この姿勢はarchives/123「『+28%』と『+9%』は、同じ調査の、同じプラットフォームの数字だった」で確認した、他人の実測を自分のサイトに当てはめる前に確かめる、という規律の裏返しでもある。今回は「自分の実測から、確かめられない主張を作らない」という形で同じ規律を守った。数字が無いところに数字を作ることは、今回はしない。
9. 当サイトの現在地（self-proof）
ここまでの実測を受けて、当サイトが実際に行ったこと・まだ行っていないことを、正直に開示する。
✅ 当サイト実施済 ── 2026年8月18日、重複を含む1,286本を含む実務記事全体を非公開（noindex）にした。検索結果には出さず、URLを直接知っている場合のみ200で表示される状態にした。詳しい経緯はarchives/105「1,000件の宿題を6日間で畳んだ」で扱った noindex 運用の延長線上にある判断だ。
🔧 当サイト着手中 ── 139組の統合（301リダイレクト）。今のところ完了しているのは2組だけで、残り137組は判断待ちの状態にある。統合には「どちらのURLを正規として残すか」の判断が1組ごとに要るため、機械的には終わらない。この判断を自動化しなかったのは、11本の組で見た通り、タイトルや見出しだけでは記事の質を判断できないからだ。137組を一括処理する誘惑はあるが、今回の実測がその誘惑に対する答えでもある。
🔧 当サイト着手中 ── 方法②（本文ハッシュ照合）・方法③（見出し構成ハッシュ照合）を、今後の記事公開フローの定期チェックに組み込む。今回は方法①（タイトル一致）と、当サイト固有の元記事URL一致でしか確認できておらず、②③はまだ全記事に対して実行していない。当サイトが持っている「元記事URL」という答え合わせの列は、他の多くのサイトには無い。だからこそ、当サイト自身が②③を実際に運用してみて、どれだけ拾えるかを確かめる必要がある。
この3つのバッジのうち、胸を張って言えるのは1つだけだ。残り2つは「まだやっていません」という開示にすぎない。だが、やっていないことを隠さずに書くこと自体が、この記事の趣旨と矛盾しない。139組という数字を出した以上、そこから先の対処が途中であることも、同じ精度で報告する。数字だけを見せて、対処の状況を見せないのでは、読者にとって「結局どうなったのか」が分からないままになる。
10. まとめ ── 読者が今日からできる3ステップ
タイトルで数えれば45組。同じデータの、別の列で数え直せば139組。数える対象は1,291本のまま、何一つ変えていない。変えたのは「何を1つの単位として数えるか」だけだった。そして、その差の内訳を実際に開いてみると、11本もの記事が同じ1本の元記事から生まれていて、そのうち7本はタイトルを見ても気づけない形になっていた。方法を1つしか試さなければ、この7本は永遠に「別々の記事」として扱われ続ける。
この記事を読んだ人が、今日から自分のサイトで試せることを3つにまとめる。
- まずタイトル完全一致で数える。5分あればできる。ただし、これは「最低限」の網であって、「これで十分」ではない。当サイトはこの1つの方法だけで「45組」という数字を最初に出し、そこで止まりかけた。
- 元記事のURLや出典を記録している場合は、そちらでも数え直す。当サイトはこの列があったおかげで、タイトル一致だけでは94組を見逃していたと気づけた。参照元の記録が残っているCMSなら、この照合はSQL1本で終わる。
- URLの記録が無い場合は、方法②か③のどちらかを試す。本文ハッシュは実装が簡単で、見出し構成ハッシュは言い回しの違いに強い。両方使えるなら両方使い、一致した組は最後に人の目で確認する。ハッシュ値が一致したからといって、機械的に統合や削除を決めない。
この記事を読んだ人に伝えたいのは、「重複があった」という結論そのものより、「1つの方法で0件だったことは、無いことの証明にならない」という、その手前の話だ。当サイトも、この記事を書く前まで45組しか見えていなかった。自分のサイトの中身は、自分では一番気づきにくい。だからこそ、確かめる方法を1つに固定せず、複数の切り口で数え直す習慣そのものが、いちばんの対策になる。
もう1つ付け加えると、今回の調査そのものにも限界がある。方法②と③は、実際にはまだ当サイトの1,291本に対して実行していない。139組という数字は、当サイトが偶然持っていた「元記事URL」という特別な列があったから出せた数字であって、方法③（見出し構成のハッシュ照合)を実行すれば、この139組がさらに増える可能性も、逆に一部が別記事として正しく判定される可能性も、どちらもまだ確かめていない。「タイトルより広く数えられた」ことと、「これで重複の全体が確定した」ことは、別の話だ。次にやることは、この記事に書いた方法②③を、実際に自分のサイトで動かすことになる。
関連 archives（連載軸として読む）
- archives/128「出力は在った。だから誰も測らなかった」 ── 直前の記事。値は入っているのに中身が違う4つの穴を扱った（2026-08-17）
- archives/124「猫のファイルが『効いている証拠』を無効化した日」 ── 陰性対照を置く考え方の起点
- archives/117「同じ条件で測っていなかった」 ── 測定条件をそろえずに数字を比べることの危うさ
- archives/123「『+28%』と『+9%』は、同じ調査の、同じプラットフォームの数字だった」 ── 他人の実測を自分のサイトに当てはめる前に確かめる3点
- archives/105「1,000件の宿題を6日間で畳んだ」 ── 当サイトのnoindex一括運用の起点
