【発注側も知っておくべき】2026年のWeb制作で失敗しないための「要件定義」と「アクセシビリティ」 - クライアント編 -
「Web制作はプロに任せておけば安心」「安くて見栄えが良ければいい」。発注の場で、よく出る言葉です。見た目の発注は、必要です。それだけで足りるかは、別です。
見た目のデザイン性だけしか見ずに発注すると検索にも AI にも載らない可能性はあります。
画面の外（キーボード、読み上げ、シェアカード、機械向けの型）まで範囲に入れるかで、見積もりの規模は変わります。
結論です。発注側が、構造化データ（いわゆる AI 対策）とアクセシビリティの意味を知り、要件の段階で範囲を指定すること。 失敗を防ぎ ROI を最大化する、とは言えません。
追加の手戻りと、公開後の「想定していなかった改修」を減らせます。制作者の言い訳ではなく、発注者が項目の中身を見られるようにする話です。
ディレクター編・デザイナー編・コーダー編の続きとして、発注側の確認項目をまとめます。対等なパートナーシップの指標ではありません。
何を買うかを、同じ言葉で話すということです。
この記事では、フリーランスのWebディレクター兼エンジニアとして、見積もりの行の読み方を整理します。架空の診断商品名や、格安は必ず手抜き、という断定はしません。
なぜ、発注者側の知識が効くのか
法と社会の要請（範囲は案件で決める）
2024年4月以降、障害者差別解消法の改正で、民間事業者の合理的配慮が求められます。全サイトに WCAG AA の適合証明が義務、ではありません。JIS X 8341-3 と WCAG は、目標を決めるときの参照です。CSR や ESG の文言に必ず書く、とも限りません。高齢者、障害を持つ方、スマホ時、音声読み上げを、対象ユーザーに含めるかを、要件で決めましょう。決めていないと、見積もりの「アクセシビリティ対応」が、中身の無い行になります。
AI 検索（GEO）と、ファクトの出し方
JSON-LD が無いと、生成 AI の回答枠から排除される、という公開資料はありません。あるのは、社名・価格・FAQ など、画面に出した事実と、機械向けの型を揃えると、取り違えにくい、ということです。集客の決定打、とも言いません。発注者が正しい会社情報、出してよい数字、対象外を渡さないと、制作側は推測します。推測のマークアップは、後から直すことになりかねません。
極端に安い見積もりで、削られやすいもの
安い会社は構造化とアクセシビリティを削っている可能性が高い、と決めつけることはできません。しかし起きやすいのは、行が「デザイン」「コーディング」だけで、確認対象（コントラスト、キーボード、JSON-LD の型、OGP の文案）が無いことです。公開後に全面改修が必要、は必ず発生するわけではありません。
足りない範囲を、公開後に足す二重投資、は起こり得ます。安さの比較の前に、その行が何を含むかを聞くようにしましょう。
要件定義で、制作会社に確認する4点
1. 誰が、どの環境で使うか（目標レベルの合意）
高齢者や障害のある利用者、音声読み上げ、スマホを含めるか。WCAG AA を目標にするか、対象ページを限るか。含めないなら、その旨を書面に残す。曖昧な「できるだけ使いやすく」は、検収できません。
2. 自社の事実を渡す（構造化の情報源）
正式な社名、住所、出してよい FAQ、価格の条件、事例の掲載範囲。制作会社に「調べて埋めて」だけだと、画面と JSON-LD がずれます。埋め込む型（Organization、FAQ、Product 等）と、対象外を取り決める。無い星や在庫を作らない。
3. 検索タイトル・OGP・メタの決め方と日程
誰が文章を書くか、いつまでに初稿か。実装末期の空欄は、手戻りになります。要件のスケジュールに、1行入れる。
4. 公開後の更新で、品質が落ちないか
CMS で記事を足したとき、見出し順、alt、マークアップが崩れる前提があるか。更新ガイドラインや、触ってよい範囲が見積もりに含まれるか。含まれないなら、運用は別契約、と先に理解しておきましょう。
丸投げと、要件から揃える発注
制作プロセスでは、前者はカンプと納品日だけが先に決まる。後者は、対象ユーザー、出す事実、検収の目標が先です。見積もりの妥当性は、行の有無です。無い行は、後から追加になります。公開後の集客と耐久は、保証しません。事実が辿れるページと、操作が残るページは、更新しやすい、です。共創によってのみ成功、という事実はありません。同じチェックリストで話すことが発注者と制作者の差を埋めます。
発注者用 ヒアリング＆要件定義チェックシート
フェーズ | 発注側の確認 | 制作会社への質問例 | NGに近い答え |
|---|---|---|---|
比較 | 見積もりの行に何が含まれるか | アクセシビリティと構造化は、どの作業か | 「一式に含まれます」（中身が無い） |
比較 | 安い理由 | 対象外のブラウザ、端末、ページは何か | 「全部やります」（範囲が無い） |
要件 | 使う人 | 読み上げとキーボードは検収するか。目標は AA か | 「見た目で十分です」 |
要件 | 出す事実 | 社名・FAQ・価格の正は誰が渡すか | 「こちらで調べます」（出典が無い） |
要件 | JSON-LD の型 | どのページに何を付けるか。対象外は何か | 「全部入れます」 |
要件 | メタと OGP | 文案の担当と締切はいつか | 「実装のときに適当に」 |
デザイン | コントラスト | 本文とボタンは測るか | 「ブランドカラー優先でおしゃれな低コントラスト」 |
実装 | 見出しと | カンプの大小とタグは一致させるか | 「見た目どおりのタグ」 |
検収 | キーボード | Tab で主要操作が届くか | 「マウスで確認しました」 |
運用 | 更新 | CMS で崩れる箇所と、ガイドラインはあるか | 「公開したら終わりです」 |
契約 | 追加 | 要件追加の見積もり条件は何か | 「軽く直します」（境界が無い） |
まとめ：買う範囲を、同じ言葉にする
2026年の制作は発注者と制作者の共創によってのみ成功する、という合格ラインはありません。要件で、誰向けか、何の事実を出すか、何で検収するかを揃える。診断という商品名である必要はありません。
要件の切り方、見積もり行の読み方、アクセシビリティとマークアップの範囲の相談は、相談・お問い合わせからどうぞ。