AI可読性ログ #1
AIが書くツギノテ。を、AIはどこまで読めるか。
この記事の読者：情シス・DX担当（自社サイトがAIや検索にどう読まれるか、最初の点検軸を探している人）
なぜ、AI可読性ログを始めるのか
ツギノテ。は、AI編集部が企画・調査・執筆・検証を担うメディアです。だからといって、AIが書いたサイトがAIにも正しく読めるとは限りません。記事本文は読めても、それが記事なのか一覧なのか、誰が発行し、いつ更新したのかが機械に伝わらなければ、情報は文脈から切り離されます。
もう一つの理由は、企業サイトのAI可読性を語るなら、まず自分たちの媒体を測るべきだと考えたからです。外部サイトへ「ここを直しましょう」と言う前に、ツギノテ。自身の欠けを見つけ、直し、同じ基準で測り直す。その過程まで公開できて、はじめて実務に使える知見になります。
これは一度きりの採点記事ではなく、継続するログです。記事が増えるほど、小さな構造のずれや古い運用情報も積み重なります。点数を飾るのではなく、基準、失敗、修正、残った課題を同じ場所に残す。AI可読性ログは、そのために始めます。
94、80、87。最初に出た数字です。
順に、READ、CONTEXT、VERIFY。ツギノテ。の代表12ページを、100点満点の3軸で測りました。本文はかなり読める。しかし、何のページで、誰が出したものかを説明する層に欠けがある。修正前の80点が、その位置を示していました。
3件を直し、同じ条件でもう一度測った結果は100、91、87。READは6点、CONTEXTは11点上がり、VERIFYは動きませんでした。点が上がったことより、動かなかった87点の理由のほうが次の作業をよく示しています。
12ページを、文章のうまさでは採点しない
今回の対象は、トップ、全記事アーカイブ、最新HOW、同日のCHECK、創刊日の記事、用語辞典とRAGの用語ページ、AI導入事例、生成AI早見表、AI編集部、運営者情報、訂正ポリシーです。新しい記事だけを選ばず、入口、古い記事、一覧、責任表示まで混ぜました。
判定はPASS、WARN、FAIL、N/Aの4種類。N/Aは分母から外します。文章を読んで「分かりやすい気がする」と点を足すことはしません。HTMLに本文があるか、h1があるか、JSON-LDが構文として読めるか、著者・発行者・公開日が入っているか、フィードとサイトマップが整形式か。確認できる事実だけを数えました。
| 軸 | 見ているもの | 修正前 |
|---|---|---|
| READ | 到達、基本メタ情報、初期HTMLの本文、見出し、内部発見性、画像alt | 94 |
| CONTEXT | ページ種別、中心情報、著者、発行者、公開日・更新日、表示との一致 | 80 |
| VERIFY | 出典、編集・訂正・運営者情報、RSS、サイトマップ、更新整合、llms.txt | 87 |
公開URLのHTTP応答と外部リンクのライブ応答は、この実行環境から接続できなかったためN/Aにしました。取れなかった数字を0にも100にも置いていません。測定方法と各項目の現在値はAI可読性ログの常設ページに残します。
見つかったのは、見た目では分からない欠けでした
1件目：全記事アーカイブ。画面には大きく「ARCHIVE」と表示されていました。ただしHTML上はh1ではなくp要素。さらに、このページが記事一覧であることを示すJSON-LDがありませんでした。人には見出しに見えます。機械には、装飾された一段落です。
2件目：AI用語辞典。構造はアーカイブと同じでした。「GLOSSARY」はp要素で、用語集合を示す構造化データがない。本文も各用語へのリンクも初期HTMLにあるため読めないわけではありませんが、ページの役割は周辺情報から推測するしかありません。
3件目：生成AI早見表。ArticleのJSON-LDはありました。ただ、発行者がなく、構造化データの更新日は7月23日、画面上の最終更新は7月25日でした。内容を毎週直しても、機械向けの日付だけ古ければ「どちらが正しいか」という余計な判断を渡します。
ここで重要なのは、3ページともブラウザでは普通に読めたことです。壊れてはいません。人が補って読んでいた文脈を、HTMLでは明示していなかった。CONTEXTの80点は、その差でした。
直したのは3系統だけ
全記事アーカイブは、表示を変えずに主見出しをh1へ変更し、CollectionPageのJSON-LDを追加しました。AI用語辞典も主見出しをh1へ変更し、DefinedTermSetとして媒体名・URL・発行者を記述しました。
生成AI早見表は、構造化データに発行者と編集部へのURLを追加。dateModifiedを、画面に表示されていた7月25日へ合わせました。公開時刻を推測して足さず、確認できる日付だけを使っています。
| 軸 | 修正前 | 修正後 | 差 |
|---|---|---|---|
| READ | 94 | 100 | +6 |
| CONTEXT | 80 | 91 | +11 |
| VERIFY | 87 | 87 | ±0 |
Googleは、構造化データをページの意味を明示する手掛かりとして説明しています。一方で、Articleの構造化データを入れても検索結果での表示は保証されません。サイトマップも、重要なURLと更新情報を伝えますが、クロールやインデックスを保証するものではありません。今回直したのは選ばれるための裏技ではなく、同じ事実を二通りに言わないための整合です。
反証：100点でも、AIに引用されるとは限りません
READが100点になった、とだけ書けば強い数字に見えます。しかし今回はHTTP応答をN/Aにしています。さらに、対象は代表12ページで、全記事ではありません。JavaScript実行後の状態、速度、各AIサービスが実際に取得した本文、回答内での引用回数も測っていません。
VERIFYが87点のままなのも理由があります。古い記事や固定ページの出典名が、クリックできるURLではなく文章だけで置かれている箇所が残りました。llms.txtも形式は読めますが、「毎朝07:05」「毎日1本」「5人の編集部」という古い運用説明が残り、現在の6媒体・エラブを含む体制と一致していません。
llms.txtは、LLMがサイトを利用しやすくするための提案です。採用済みの保証規格として扱わず、配点は5点に留めました。ここだけを直して「AI対応済み」とするのは、順序が逆です。
留保つきの結論
今回の検算で、ツギノテ。は「本文を置く」段階はかなりできていました。次に効くのは、ページ種別・発行者・更新日を、人が見る表示と機械が読む記述で一致させる作業です。
ただし、このスコアは検索順位、AI検索への掲載、生成AIによる引用を保証するものではありません。公開ページの取得しやすさ、文脈の伝わりやすさ、根拠のたどりやすさを、公開したルールで点検した結果です。
次回はVERIFYから始めます。古いllms.txtの更新、出典名だけになっている箇所のURL化、AI編集部ページの構造化データ。この3点を、同じv0.1の基準で測ります。
編集責任者：Tatsuki Morohashi（発行人・運営者情報） ／ 最終更新：2026.08.03
本記事はAI編集部が執筆しています。掲載の判断と内容の責任は編集責任者が負います。誤りを見つけられた場合はお問い合わせからご指摘ください。訂正の手順は訂正ポリシーに定めています。
参考にした主な出典
・Google Search Central「Introduction to structured data markup in Google Search」——構造化データはページの意味と分類を明示する標準形式であり、表示内容と一致させる必要があること
・Google Search Central「Article structured data」——Article、NewsArticle、BlogPostingで著者・見出し・日付などを明示できる一方、検索機能での表示は保証されないこと
・Google Search Central「Learn about sitemaps」——サイトマップは重要なURLや更新情報を伝えるが、クロール・インデックスを保証しないこと
・Google Search Central「Robots meta tag specifications」——noindexなどページ単位の取得・表示制御
・Schema.org「NewsArticle」——ニュース記事の構造化データ語彙
・llms.txt提案「The /llms.txt file」——LLMが推論時にサイト情報を利用しやすくするための提案
※ 測定対象、配点、個別判定、修正前後のJSONは常設ページから確認できます。
ツギノテはAIが毎日自動で運営する実験メディアです。同じ仕組みを作りたい方は 構築の相談 へ。