この記事の要点

  • 生成AIが手順を答えられるのは、各ステップの番号・やること・所要期間が本文の文字として書かれている場合です。矢印でつないだ流れ図の画像だけでは、順番を読み取れません。
  • ステップの見出しに「ヒアリング」「ご提案」といった社内用語だけを置くと、その部分だけを切り出されたときに何をする段階なのか伝わりません。
  • 2026年8月時点で、Googleがリッチリザルト(検索結果の特別な表示)として対応している構造化データの一覧に「ハウツー」は含まれていません。2023年8月の変更以降、検索結果の見た目を変える目的では使えません。
  • 一方で書式そのものは有効で、手順を表す型はschema.orgに現在も定義されています。順番と本文の対応を、見た目に依存しない形で残せます。
  • サイトモはsite-more.comの「ご利用の流れ」の4ステップを一か所のデータとして持ち、画面の表示と構造化データの両方を同じデータから書き出しています。

手順ページとは何を指すのか

手順ページとは、ある結果に至るまでの作業を順番に区切り、各段階で何が起きるかを示したページです。「ご利用の流れ」「お申し込みから公開まで」「施工の流れ」といった名前で置かれていることが多く、士業なら相談から受任までの流れ、建設業なら現地調査から引き渡しまでの流れがこれに当たります。

読者が知りたいことは、だいたい3つに絞られます。どんな順番で進むのか。どれくらい時間がかかるのか。自分は何をすればいいのか。この3つが書かれていれば、手順ページとしては役目を果たしています。

ここで見落とされやすいのが、社内の工程表と手順ページは別物だという点です。工程表は自社が何をするかの記録ですが、手順ページは読み手が自分の負担を見積もるための情報です。同じ4段階を扱っていても、書くべき中身は変わります。

生成AIは手順をどう読み取っているのか

生成AIが手順を答えるとき、根拠にしているのはページの本文テキストと、その並び順です。「最初に何をするのか」という質問に答えるには、どれが1番目なのかが文字として判別できる必要があります。

つまずくのは、流れを1枚の図にまとめているケースです。矢印でつながった横並びの図は、人間の目には一目で伝わります。ただし画像の中の文字は本文ではありません。デザイン上きれいに収まっているぶん、問題として気づきにくい部分でもあります。

番号の扱いも同じです。画面に「STEP1」「STEP2」と見えていても、その番号が装飾用の画像や背景の飾りとして置かれている場合、文字としては残っていないことがあります。番号は文字で書く。単純な話ですが、ここが抜けている手順ページは珍しくありません。

順番が読み取れないとどうなるか。生成AIは前後関係を推測して回答を組み立てるため、実際とは違う順番で説明される場面が起こりえます。これは仕様として保証された動作ではなく、回答は同じ質問でも変わります。ただ、手がかりの少ないページほど推測に頼られる側に置かれる、という構造は言えます。

AIに引用される手順の書き方

1つのステップには、番号・何をする段階か・誰が何をするか・どれくらいかかるかの4つを揃えて書きます。この4つが同じ段落の中にまとまっていれば、その段落だけを切り出しても意味が通ります。

まず見出しの言葉選びです。「ヒアリング」「ご提案」「オンボーディング」のような言い方は社内では通じますが、切り出された瞬間に何の段階か分からなくなります。「ご要望のお伺い」「お見積りのご提示」のように、動作が見える言葉に開いておきます。

次に各ステップの本文です。次の2つを比べてみてください。

書き方 例
情報が足りない書き方 ヒアリングを行います。
切り出しに耐える書き方 1つ目の段階では、当社がお送りするヒアリングシートにご回答いただきます。お客様の作業はご回答のみで、所要時間は30分程度です。

後者は、この一文だけを読んだ人が自分の作業量を判断できます。前者からは、誰が何をどれだけやるのかが一切分かりません。

期間の書き方にも触れておきます。「お急ぎ対応可」のような表現は、読者にもAIにも情報になりません。「ご提案から2〜3営業日以内」のように起点と幅を書くと、そのまま引用できる形になります。ただし守れない数字を書く必要はありません。幅を広く取っておいたほうが、あとで齟齬が出ません。

最後に順番の明示です。各ステップの本文に「まず」「次に」「最後に」を入れておくと、見出しの番号が失われても順番が本文側に残ります。やや冗長に見えますが、切り出しへの備えとしては効きます。

ハウツーの構造化データは今も書く意味があるのか

構造化データとは、ページに書かれている内容の意味を、機械が読み取れる決まった形式で書き添えたものです。手順の場合は「これは手順を説明したページで、段階は4つあり、1番目はこれ」という情報を、文章とは別に整理して持たせます。

前提を正確にしておきます。2023年8月、Googleは「HowTo とよくある質問のリッチリザルトにおける変更」という告知を出し、手順の構造化データは検索結果の特別な表示の対象から外れました。2026年8月時点でGoogleがリッチリザルトとして対応している構造化データの一覧を確認しても、記事・パンくずリスト・商品・ローカルビジネスなどは掲載されている一方で、「ハウツー」は掲載されていません。検索結果の見た目を変える目的では、もう使えないと考えるのが妥当です。

ただし、書式そのものが廃止されたわけではありません。構造化データの語彙を定義しているschema.orgには、手順を表す型が現在も定義されています。順番付きの各段階に名前と説明を持たせられる形式で、非推奨の扱いにはなっていません。

ではサイトモがなぜ書いているのか。理由は2つあります。1つは、本文の見た目に依存しない形で順番を残せること。もう1つは、手順が変わったときに、表示と記述の食い違いに気づきやすくなることです。ただしこれは効果が公表されている話ではなく、判断の一つとして書いています。

サイトモの考え方

手順ページで先に手を入れるのは、いつも本文の書き方です。構造化データはそのあとに置く補強で、本文が薄いまま記述だけ足しても意味は増えません。順番を取り違えないようにしています。

サイトモの実装例:4ステップを一か所で管理する

サイトモはsite-more.comの「ご利用の流れ」について、4ステップを一つのデータとして持ち、画面に表示する流れと構造化データの両方をそこから書き出しています。各ステップに番号・見出し・所要期間・当社がすること・お客様にお願いすることを項目として持たせ、画面ではカードとして並べ、構造化データでは順番付きの段階として出力する形です。

実際に公開しているのは、次の4段階です。

  • 1つ目:無料AIO診断(約30分・完全オンライン/お客様の作業はフォーム入力とURLのご共有のみ)
  • 2つ目:ご提案(診断後2〜3営業日以内/提案内容のご確認とご質問)
  • 3つ目:制作(ヒアリングから公開まで2〜4週間目安/ヒアリングシートへのご回答と写真・ロゴ等のご提供)
  • 4つ目:公開・運用(公開後も継続/月次・年次レポートのご確認)

書き出している構造化データを簡略化すると、次のような形になります。

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "ホームページ制作のご利用の流れ",
  "step": [
    { "@type": "HowToStep", "position": 1, "name": "無料AIO診断", "text": "..." },
    { "@type": "HowToStep", "position": 2, "name": "ご提案", "text": "..." }
  ]
}

この作りにしている理由は、二重管理をなくすためです。ステップの文言を変えたときに、画面だけ直して記述が古いまま残る、という事故が起きません。手順は事業のやり方が変わるたびに更新される情報なので、更新の手数を減らしておく価値があります。

あわせて、このページの更新日はGitのコミット日付から自動で書き出しています。手順を直した日がそのまま更新日として出る状態にしておくと、いつ時点の流れなのかを読み手も機械も判断できます。

手順ページを整えると何が変わるのか

もっとも大きいのは、問い合わせ前の不安が減ることです。手順ページを見に来る人は、たいてい「頼んだあと、自分にどれだけ手間がかかるのか」を気にしています。作業量と期間が書かれていれば、その場で判断できます。

生成AIの側から見ると、引用の単位が作りやすくなります。段階ごとに区切られ、それぞれが独立して意味を持つ文章は、質問に対して必要な部分だけを取り出しやすい形です。逆に、流れ全体を1つの長い段落で説明していると、どこを切り出しても情報が足りません。

社内向けの効果もあります。手順を文章として書き切ろうとすると、期間の見積もりや誰の作業なのかが曖昧な箇所が出てきます。そこが実務上の詰まりどころだった、というのはよくある話です。

注意点:手順ページで避けたい書き方

段階を細かく分けすぎると、1つずつの中身が薄くなります。10段階に割った結果、各段階が一言だけになっているページは、切り出しても情報になりません。目安としては4〜6段階で、それぞれに具体的な作業と期間が書ける粒度に収めます。

実際と違う期間を書くのは、当然ながら避けます。手順ページは引用されると独り歩きするため、そのまま社外の説明として使われます。守れる幅で書く。これは対策というより約束の話です。

もう一つ、構造化データ特有の注意があります。Googleの構造化データに関する一般的なガイドラインでは、ページの読者に表示されないコンテンツをマークアップしないよう明記されています。本文に書いていない段階を記述だけに足す、という使い方はできません。表示と記述は一致させます。

最後に、これは効果の話ではありません。手順ページを整えることでAIに引用されるようになる、と保証できるものではなく、生成AIの回答は同じ質問でも変わります。ここで書いているのは、読み取れる状態にしておくという前提の整備です。

まとめ

手順ページの改善は、書き足す作業よりも「書いてあるつもりだった部分を文字にする」作業になることが多いです。図の中にしかない番号、担当者の頭の中にしかない所要期間、そのあたりを本文に出していく。順番としてはそこが最初です。

構造化データは、その本文が整ってからで間に合います。手順の構造化データは検索結果の見た目には効かなくなりましたが、書式としては生きているので、表示と記述を同じデータから出す作りにしておくと更新が楽になります。

まずは自社の「ご利用の流れ」を開いて、番号・作業内容・期間・お客様がやることの4つが本文の文字として書かれているかを確認してみてください。1段階でも欠けていれば、そこが手を入れる場所です。

よくある質問

手順ページに図解を入れるのはやめたほうがいいですか

やめる必要はありません。図解は人にとって理解を助けます。問題になるのは、図解しか置いていない状態です。図と同じ内容を本文の文章としても書いておけば、両方に対応できます。

手順の構造化データは削除したほうがいいですか

削除する必要はありません。2023年8月以降、検索結果の特別な表示には使われませんが、schema.orgの型としては現在も有効で、書いていることによる不利益は公表されていません。ただし本文の内容と一致していることが条件です。

段階はいくつが適切ですか

決まった数はありません。実務としては4〜6段階が扱いやすく、各段階に作業内容と期間を具体的に書けるかどうかを基準に決めるのが現実的です。書けないほど細かいなら、まとめたほうが伝わります。

期間が案件によって大きく変わる場合はどう書けばいいですか

幅と条件を書きます。「2〜4週間(ページ数と原稿のご準備状況によります)」のように、変動する理由まで一文に入れておくと、切り出されても誤解が生まれにくくなります。

参考情報