直す場所は、自社サイトの中にはなかった。― 観測は、引用の出どころまで読む ―
観測結果を開いて、引用されている出どころを数えた。公式サイトではないページが並んでいた。公開していない項目は口コミ由来の数字で埋められ、よい意味で使われていた語は経由地を経て負の語に変わって出力されていた。測ったあとに読むのは、順位ではなく、何がどこから引かれたかである。直す順番は、出どころを確かめ、空欄を埋め、言葉を置き直す。
noteで読むJournal
問いと、その結論。
情報設計をめぐる思考の記録です。フレームワークが生まれた背景、現場で確かめたこと、 まだ結論の出ていない問い。ここには各回の問いと結論だけを置いています。
※ 記事の本文は note に掲載しています。このページはその索引です（全40本）。
CHAPTER IV
AI時代に選ばれる方法論
AI検索への具体的な対応から、ECの商品詳細ページ、そして事業戦略まで。AI時代に選ばれるための手順を扱う章です。全2本を公開中。
同じ質問を、630回した。― AI検索対応は、測る条件を決めるところから ―
第四章の第一話。AI検索への対応は、何かを直す前に同じ条件で測るところから始まります。ある学習塾の支援で90の質問を7つのAI面に投げ、630回の回答を記録した観測をもとに、ログアウトを原則とする条件の固定、ブランド名を含む質問と含まない質問で測るものを分けること、面ごとに並ぶ候補の数が違うため面どうしは出現率と平均順位で比べることを整理します。Google 検索セントラル「AI 機能とウェブサイト」（Google検索のAIによる概要とAIモードについての文書）を引いています。
noteで読むChapter III
AIO／GEO — AI検索に引用される構造
第二章で立てた判断構造の考え方を、AI検索という実務の場へ持っていく章です。9本と総集編を公開中。
9本の実例を、①から⑨の順に並べ直す。― Information Designer 第三章 総集編 ―
第三章の9本を、判断構造シーケンスの①判断目的から⑨検証の順に並べ直した総集編。前半の三話で①〜③と構造化の土台を置き、後半の六話で④評価基準から⑨検証までを1話に一つずつ実例で確かめたことを整理します。どの工程も前の工程が決まっていないと先へ進めないこと、ユレは言葉だけでなくチャネルや並べ方の間でも起きることをまとめ、第三章版の9つの問いを置いておきます。
noteで読むチェックは通った。でも、1本足りなかった。― 検証は、作った意図と突き合わせて終わる ―
判断構造シーケンスの最後、⑨検証の回。自社サイトの記事索引で本数の表記がすべて同じ「足りない数」で揃っていた経験から、表記同士の一致と、必要なものが揃っていることは別だと整理します。Google 検索セントラル「Google 検索上の構造化データ ガイドライン」（Google 検索のリッチリザルトに関する文書）が、技術面はリッチリザルト テストなどで検出できる一方、品質に関するガイドラインは自動化ツールで簡単にテストできないと書いている点を引き、形式の確認と内容の確認を分けます。結論は、検証は作ったものを意図と突き合わせて終わり、その意図は作る前に書き残しておく、ということです。
noteで読むそのブランドは、どこに属していますか。― 構造化は、同一性と所属の宣言から始まる ―
企業サイトとブランドサイトが別に建っていた。人が見ればロゴから同じ会社だと分かるが、その関係を機械が読む側に伝える宣言はどこにもなかった。宣言は二つに分かれる。これは何者かという同一性と、どこに属するかという所属である。所属は一つに限らないが、曖昧になるのは複数あるときではなく、宣言がないときだ。
noteで読む「コシがある」と書かなかった理由。― 訳語は、褒め言葉の在庫から選ばない ―
訳語の候補に、麺のコシの強さを表す定型の語が挙がった。けれどもその店の麺は、柔らかいことが特徴だった。褒め言葉は、その商品を観察して選ばれるとは限らない。そのカテゴリで使われてきた語彙の在庫から当てはめられていることがある。表現は、実態の側から選び直す必要がある。
noteで読む並べ方を変えたら、比べられなくなった。― 順序は、何を同じものとして扱うかの宣言 ―
グループの見出しを変えたら、比較の列が働かなくなった。箱の中が揃っていれば、箱の中では比べられない。順序の扱いは読む機械によって違う。スクリーンリーダーには効き、Google 検索では順番どおりでなくてよいと明記されている。だから整える理由は、人が判断できるようにするためにある。
noteで読む基準は決めた。では、何で裏づけるか。― 根拠は、主張の隣に置く ―
「軽い」は基準であって根拠ではない。何グラムで、何と比べて、誰が測ったのか。根拠は主張の隣に置く。取れない根拠は、空欄にして「要確認」と書く。
noteで読む比較表はあるのに、選ばれない。― 評価基準は、誰が決めるのか ―
Googleがバリエーション商品の識別に使う軸は6つに限定列挙されていて、それ以外の違いは属性名も値も自分で決める自由記述の欄に入ります。自由記述は機械に届きますが、書き手ごとに揃わないため共通の比較軸にはなりません。だから何を基準に選んでほしいのかは、判断目的から降ろして、こちらが名指しして書く必要があります。
noteで読むその商品情報、どれが原本ですか。― チャネルをまたぐユレの正体 ―
Googleは商品データとランディングページの価格や在庫を一致させることを運用要件として示しています。チャネルをまたぐユレは誤りではなく分業から生まれるため、各担当の注意力では止まりません。揃える前に、項目ごとの原本をどこに置くかを決める必要があります。
noteで読む構造化データは、AIへの呪文ではない。― 入れるより、揃える ―
Googleは生成AI検索に構造化データが必須ではないと明記しており、可視HTMLにない情報はAIに拾われにくいという検証結果も出ています。問うべきは入れたかどうかではなく、本文・画像・FAQ・構造化データが同じ事実を同じ内容で語れているかです。
noteで読むAIは、一つの問いを分解して探している。― AI検索に引用される構造の作り方 ―
AI検索は一つの質問を複数のサブクエリへ分解し、並列に検索して回答を組み立てています。だから拾われる条件はページ全体の出来ではなく、分解された一つの問いに単独で答えられる単位がページの中にあるかどうかです。
noteで読むChapter II
判断構造の設計
情報を増やす前に、判断構造を設計する。6本と総集編で、理論・実装・検証を一巡しています。
情報を増やす前に、判断構造を。― Information Designer 第二章 総集編 ―
第二章の6本は、別々のテーマに見えて一つのことを書いていました。情報を増やす前に、判断構造を設計する。自社のページを点検するための9つの問いも、この回に置いています。
noteで読む判断は、変わったか。
アクセス数や滞在時間が示すのは見られた量であって、判断できたかではありません。見るべきは判断が次に進んだ痕跡で、そこで分かるのは、どの判断材料が足りなかったかです。
noteで読むAIも、判断している。
いま商品ページを読むのは人だけではなく、検索を要約するAIや購入を支援するAIエージェントも判断者です。ただし人向けの設計とAI向けの構造化は別の仕事ではなく、地続きです。
noteで読む判断構造シーケンスを、実際のページに実装する。
9段階の設計手順は、そのまま1ページの設計図として使えます。優れたページとは情報量が多いページではなく、どの判断材料をどの順番で提示するかが設計されたページです。
noteで読む判断できる構造を設計するには、順番がある。
判断目的から検証までの9段階を、判断構造シーケンスと呼んでいます。情報の並び順はその6番目にすぎず、順序だけを直しても判断構造は完成しません。
noteで読む情報を整理しても、なぜ判断できないのか
整理は必要ですが、それだけでは足りません。整理は情報を分類して見つけやすくすること、設計はどの順番で理解すると判断しやすいかを決めることで、別の仕事です。
noteで読むなぜAIはあなたの商品を理解できないのか
AIが賢くなれば理解される、とは限りません。問題はAIが商品を理解できないことではなく、人間が理解できるように商品情報を設計していないことにあります。
noteで読むChapter I
MICIと情報構造
Information Designer として何を設計しているのか。MICIとは何か。毎週1本、4つの流れで書いてきた回です。
AI検索と、理解の条件2026.05.24 — 2026.06.14・全4本
なぜFAQや比較表は、AI検索に強いのか
FAQは質問と回答、比較表は比較軸と差異という構造を最初から持っています。強いのはAIがその形式を好むからではなく、判断材料が構造として整理されているからです。
noteで読むAI検索時代に、なぜ構造が重要になるのか
商品ページの読者は、もう人だけではありません。理解されなければ比較されず、比較されなければ推薦されない。だから構造そのものが競争力になります。
noteで読むMICIとEC2026.04.05 — 2026.05.17・全5本
MICIはECでどう機能するのか
ECの商品ページは説明の場ではなく、意思決定のための構造です。言葉の定義・前提条件・比較軸が揃っていない状態では、情報量を増やしても売上にはつながりません。
noteで読む事業の骨格2026.02.22 — 2026.03.22・全6本
Information Designerは、何を生み出すのか。
うまくいくかどうかは、施策ではなく判断で決まります。そしてその判断は、人でも経験でもセンスでもなく、構造から生まれます。
noteで読むなぜ、マーケターではなくInformation Designerなのか。
戦略が決まらないのは、能力の問題ではなく構造の問題です。言葉・前提・比較軸・判断基準という骨格が整うと、戦略は静かに決まります。
noteで読むはじめに ― 正しく理解されるということ2026.01.25 — 2026.02.19・全6本
Information Designerは、何を設計しているのか
設計しているのは情報そのものではなく、情報どうしの関係性です。すべてが一本の論理で貫かれ、接点ごとに揺れていない状態が整うと、説明が減ります。
noteで読むなぜ「理解される順序」は壊れるのか ― 現場で繰り返される3つのパターン
事実より先に結論を語る。事実と解釈が混ざる。受け手の理解プロセスが設計されていない。真面目な現場ほど、この3つに陥ります。
noteで読むうまくいかない施策には、共通点があるのでは
リソースやスピードの不足は、結果として現れた現象であって原因ではないことが多いと感じています。丁寧に見ていくと、前提が共有されていないという共通点が浮かび上がります。
noteで読むInformation Designer が扱うのは「言葉」ではなく「構造」
何が事実で、どこからが解釈で、どの順序で提示されるべきか。文章はその結果として生まれるもので、仕事は誠実さを削ることではなく、誠実さが正しく伝わる形に整えることです。
noteで読む正しく伝えているつもりでも、正しく伝わらない時代に
正しく伝えていることと、正しく理解されていることは、別の状態です。読み手が人だけでなくなったいま、問われるのは誰が読んでも同じ意味で理解できるかどうかです。
noteで読む