【公開前まで放置しない】今必要とされる構造化データとアクセシビリティ - ディレクター編 -

仕様書って数年前から同じフォーマットじゃないですか？

2026年現在、ウェブサイト制作には数年前には無かった対応すべき項目があります。
アクセシビリティの必須、AI検索などへの対応に構造化データ追加などです。

でも指示書・仕様書って数年前から同じフォーマットじゃないですか？

実際、コーディング・開発だけ依頼されることが多いですが、デザインデータのみ（しかもスマホデザインは無い）ということが非常に多いです。

もちろんクライアントの予算でアクセシビリティ・構造化データ非対応という案件もあると思います。
でも大抵、「アクセシビリティ・構造化データどうなってますか？」という質問が来ることがあります。

ここでは、そんな実際にありそうな仮想の状況を基にしたお話をしようと思います。

制作に必要な項目、仕様書にありますか？

OGP、検索用タイトル、メタディスクリプション、構造化データ、アクセシビリティ。実装の直前まで項目すら無い。または空欄で、「コーダーが良きに計らう」になっていませんか。ページ構成、配色、競合の見た目だけがディレクション、という進め方では、足りない案件が増えています。なぜ必要になったか。検索の出し方と、使う人の前提が、以前より説明を求めるようになった、というのが理由です。

結論です。これらは Figma やワイヤーから勝手に湧きません。 顧客の事業を聞いた人が、取材の段階で言語化する設計情報です。JSON-LD を入れれば AI 検索（いわゆる GEO）に載る、仕様書を埋めなければ現場が必ず疲弊する、とも言いません。意味と使い方を先に書かないと、実装が推測になり、確認が実装末期に寄る。現場が指示書の穴埋めをするから、仕様書を定義する側で行うことが、現場の手戻りを減らし結果工数を削減、クライアントへの早期納品に繋がります。
案件の工数を減らし、作業をスムーズにし、納期を早くする。そして成果物の価値を上げることで、結果として制作者の価値を高めます。

この記事では、フリーランスのWebディレクター兼エンジニアとして、ディレクターが先に決める範囲を整理します。
実際に「メタ情報すら決めてこない人が多い」という情報は自分の所感です。
なので現場で実際に起こり得る事例として書きます。

デザインデータから読めない、隠れた設計

OGP・検索タイトル・ディスクリプション

カンプの見出しは、検索結果や SNS のカードと同じ文とは限りません。文字数、誰に何を約束するか、禁止語、ブランドの呼び方は、見た目から決まりません。実装間際に慌てて空欄を埋める、コーダーに一任する、はよくある事例です。シェア率やクリック率を決める最重要コピー、が抜けているとは断定しません。ただ決めておく場所ではあります。取材で聞いた目的と、出してはいけない表現を、ディレクターが先に一文にする。

構造化データ（JSON-LD）

画面には出ない、検索エンジン向けのラベルです。生成 AI がファクトを一発で正しく読む、公式の GEO スコアがある、とは言いません。Google の検索ギャラリー に載る種類と、画面に見える文が一致していることが条件です。裏の仕様ではありますが、ディレクターが「何の事実か」を指定しないと、実装は見た目のテキストをなぞるだけになります。

アクセシビリティ（WCAG / JIS X 8341-3）

WCAG と、国内では JIS X 8341-3 が参照されます。色、文字サイズ、キーボード、テキスト読み上げは、静止画だけでは指示しきれません。2024年4月以降、障害者差別解消法の改正で、民間事業者の合理的配慮が求められる、という法的義務があります。全サイトが適合証明を出せ、ではありません。
ですがエンドユーザーと、クライアントの方針を、取材で確認しておかなければなりません。

今さら聞けない【1】：構造化データと、ディレクターの指定

概念は単純です。社名、営業時間、FAQ、価格など、人が読む文に、「これは Organization の名前」「これは質問と回答」と機械向けの型を付ける。誤解なく一発、は保証しません。取り違えにくいラベルです。

コーダーが文脈を一切判断できない、とは言いません。判断してほしくないのは、事業上の事実です。どの文が公式の問いと答えか、その数値が税込か、実績なのか希望なのか。取材していない実装者が決めると、画面と JSON-LD がずれます。ずれたマークアップは、ガイドライン違反 に寄ります。

取材で回収して指定する代表例です。全部を毎ページに載せない。

• Organization：正式名称、ロゴ URL、同じ SNS の URL。画面のフッターと一致させる。
• FAQPage：公開する Q と A のセット。アコーディオンに隠した本文も、マークアップする文と同じにする。
• Product / Service：名前、条件、価格。無い価格を構造化にだけ足さない。
• BreadcrumbList：パンくずの階層。ナビの見た目と URL を揃える。

今さら聞けない【2】：アクセシビリティで指定・確認すること

基本は次です。これで適合、ではありません。

• 文字と背景のコントラスト。目安は WCAG のコントラスト比。※通常テキストで「4.5:1以上」、大きな文字で「3:1以上」（レベルAA）が求められます。
• 見出しは見た目の大小ではなく、h1 から論理順。スキップしない、を原則にする。
• alt は、その画像が伝える情報。装飾は空で大丈夫です。ただ表示される画像に「画像1」というaltは情報になっていません。
• フォームは label と入力を紐づける。エラーは色だけにしない。何が駄目かをテキストで出す。

アクセシビリティチェックツールはありますが、合格がゴールではありません。

• デザイン：Figma のプラグイン（Stark など）でコントラストを見る。プラグイン名は一例です。数値は実装後にも再測する。
• ブラウザ：Lighthouse や axe DevTools の自動診断。自動で落ちない項目（読み上げの意味、フォーカス順）は残る。
• 実機：Tab だけで主要操作が届くか。VoiceOver や NVDA で、ラベルと見出しが意図どおりか。全ページ全読、は工数を見積に書く。

実際にアクセシビリティを自動でチェックしてくれるツールはありません。
全て人がキーボードや読み上げ機能でチェックする必要があります。
そのため、全部を100％対応するには膨大な工数がかかります。（人・時間）

だからこそ契約前に自社はどこまで対応するかどうかを検討しておかなければなりません。
契約後に、「あー、対応依頼すればコーダーがやるだろう」は、現場の疲弊と不満を募らせますし、ディレクター、ひいては制作会社そのものの信頼を失墜させます。

実践：取材から仕様に落とす流れ

指示書埋めから抜ける、は架空の話ではありません。決めるタイミングを前にずらす、のが重要です。

1. 取材：ページの目的、読んだ人にしてほしい行動、出してよい数字。その場で検索タイトル、OGP タイトル、ディスクリプションの原案。未定なら「未定」と日付を残す。空欄で次工程に渡さない。
2. ワイヤー：FAQ、事例、商品情報など、マークアップ対象を注記する。対象外も書く。後から足さない。
3. デザイン指示：テーマカラーを決めるとき、本文・リンク・ボタンのコントラストを確認する。足りなければ補助色を先に決める。
4. コーディング指示：見出し階層、alt のルール（誰が文を書くか）、JSON-LD の型と、画面上の対応箇所。良きに計らえ、を書かない。

ディレクター用 チェックシート

まとめ：2026年の肩書きより、先に定義できるか

構造化とアクセシビリティを設計できてこそプロ、という合格ラインはありません。先に意味と使い方を書けることが、実装末期の穴埋めより、確認しやすい。GEO 診断という商品名である必要はありません。

見出し、メタ、JSON-LD、キーボード操作の切り方の相談は、相談・お問い合わせからどうぞ。