既存のWeb制作会社を変えずに改善を進める方法

Webサイトの検索表示や問い合わせ導線に課題があると、「制作会社を変えたほうがよいのか」と考えがちです。しかし、問題が制作会社の能力だけでなく、依頼範囲、仕様の粒度、承認経路、公開後の検証担当にあるなら、会社を変える前に進め方を変えられます。

この記事は、既存のWeb制作会社を残したまま、診断、改善仕様、実装、公開判断、公開後の検証を分担する方法を扱います。制作会社の選び方、費用の比較、改善仕様書の14項目そのものは主題にしません。それぞれSEO・Web制作会社の選び方、BtoBサイト改善の費用と90日ロードマップ、Web改善仕様書の書き方へ委譲します。

結論：会社を変える前に、役割と受け渡す単位を分ける

既存の制作会社と改善を進めるとき、最初に決めるのは「誰がすべてを担当するか」ではありません。次の5つを分けます。

1. Observe：公開ページ、検索、計測、事業情報から何が起きているかを確認する
2. Trace：症状を生んでいる実装・設定・運用上の原因を確認する
3. Specify：対象URL、変更内容、完了条件、検証方法へ変換する
4. Execute：制作会社や社内担当者が実装し、レビューする
5. Verify：本番反映と公開後の観測を行う

1社がすべてを持つ必要はありません。ただし、各工程の責任者、入力、出力、公開判断者が決まっていないと、診断結果が制作会社のタスクへ変わらず、実装後の検証も宙に浮きます。

1. 既存契約の前に「変えないもの」を確認する

制作会社を変えずに進める場合は、新しい支援会社の提案書より先に、現契約と実装環境を確認します。

「契約内かどうか」を曖昧にしたまま仕様を渡すと、実装直前に追加費用や納期の問題になります。作業範囲を狭めることは可能ですが、誰が残りを担うかを同じ表に書きます。

2. 役割分担表には、各作業の最終責任者を一人置く

RACIは、実行担当（R）、最終責任者（A）、相談先（C）、共有先（I）を分ける方法です。実行担当が複数いても、同じ判定を最終的に引き受ける人は一人にします。会社名だけではなく、役職または担当者まで記録します。

次の表は、顧客の既存制作会社がコードを実装し、外部支援が診断を担う場合の設計例です。「責任者」は説明用の役割名なので、運用時には実際の担当者を指定してください。既存契約の責任範囲を、この表だけで変更するものではありません。

一人で実装と技術責任を兼ねる場合も、役割は別に記録します。顧客側が公開作業を担当する契約なら、その行のRとAを顧客側へ置き換えます。Aが空欄の作業は、着手前に責任者を決めます。

技術的に公開できることと、事業上公開してよいことは別の判定です。 一つの「承認済み」で、コード、公開、業務受入をまとめないようにします。外部支援が各工程を当然に代行する表にもしません。担当できる人がいない行は、支援範囲を追加するか、既存の制作会社へ依頼するか、今回は対象から外すかを決めます。

公開前の承認には、対象の版と許可する操作を残す

承認者の名前だけでなく、何を承認したかを記録します。原稿やコードが承認後に変わった場合は、その変更が承認範囲へ入るかを再確認してください。

対象：料金ページの改定
承認対象の版：原稿版またはコードの識別子
許可する操作：合意したページの本番公開
前提：価格正本との一致、日英確認、公開前テスト
公開作業者：契約で指定した担当者
公開可否の最終判断者：顧客の公開承認者
公開後の確認：表示、問い合わせ導線、計測、受信
停止・復旧の条件：価格の不一致、主要導線の障害など
残す結果：実際の公開版、確認日時、未解消事項

このメモは、承認対象を整理する説明用の例です。署名や契約の代わりにはなりません。実装担当者が技術テストを通した事実、顧客が公開を承認した事実、公開後の業務受入を、別々に確認できるようにします。

想定外の変更が必要になった場合も、既存の承認を広く読み替えず、範囲と影響を示して判断者へ戻します。料金・業務範囲へ影響しない説明上の修正と、実契約の変更も区別してください。費用の比較方法はBtoBサイト改善の費用と90日ロードマップ、技術的な公開後確認はWebサイト公開後の検証チェックリストで扱います。

3. 制作会社へ渡す資料を一つの受け渡し単位にする

制作会社に「SEOを改善してください」と依頼すると、相手は対象ページ、変更範囲、優先順位、完了条件を確認し直す必要があります。次の情報を、課題1件ごとの受け渡しパケットにします。

• 課題IDと対象URL
• 観測された症状と確認した事実
• 実装上の原因と、まだ仮説である箇所
• 変更後の文言、構造、コード、設定の案
• 触ってよい範囲と触ってはいけない範囲
• 優先度、担当、期限、依存する作業
• 本番公開前の確認項目と、公開後の再確認日
• 必要な権限と、権限を持つ担当者

改善仕様書の様式をそのまま運用に使う場合は、Web改善仕様書の書き方を参照します。この記事で重要なのは様式の再解説ではなく、既存の制作会社へ渡す前に、誰が判断し、誰が実装し、誰が確認するかを合わせることです。

4. 会議は「相談」ではなく意思決定の場にする

既存会社との定例会議が長くても、課題の担当と期限が決まらなければ改善は進みません。会議ごとに扱う情報を固定します。

着手会議で決めること

• 今回のリリースに含める課題ID
• 対象URLと対象外URL
• 実装方法の決定期限
• 仕様差分が出たときの判断者
• 本番公開日と、公開停止の判断基準
• 公開直後に確認する人と確認方法

実装レビューで確認すること

• 仕様の変更内容が本番コード・CMS・タグ設定に反映されているか
• 日本語と英語、PCとスマートフォンの表示が揃っているか
• metadata、canonical、構造化データ、内部リンクが想定どおりか
• CTA、フォーム、GA4イベントが重複せず動くか
• 変更対象外のページに意図しない影響がないか

公開後会議で確認すること

• 本番HTML、status、redirect、sitemapの確認結果
• フォーム受信とGA4イベントの照合
• Search Consoleの取得状態
• 未完了の課題、次の期限、判断が必要な事項

会議の議事録には、決まったことだけでなく、決めなかったことと、その理由も残します。未確認のまま進めた場合は、確認担当と期限を置きます。

5. 既存制作会社との衝突を減らす3つの原則

原則1：実装方法を一方的に指定しない

診断側が「このコードに変えてください」と断定しても、既存のCMS、フレームワーク、デプロイ制約に合わないことがあります。診断側が固定するのは、目的、対象、確認事実、完了条件です。実装方法は制作会社が環境を確認したうえで提案し、差分が出たら判断者が承認します。

原則2：既存会社を競合相手として扱わない

診断、仕様化、実装、公開後確認は別の能力です。既存会社が本番実装を担うなら、仕様と検証を受け渡す相手です。制作会社の実装知識を前提にしつつ、検索・計測側の確認事実を不足なく渡します。

原則3：成果ではなく、完了と観測を分ける

本番HTMLに変更が反映されたことは、実装の完了です。検索順位、AI検索での表示、問い合わせ数の変化は、公開後の観測です。外部要因があるため、観測結果を制作会社の成果保証として扱いません。

6. うまく進まないときの切り分け

1件の改善を分担して公開し、受け渡しの往復、実装の遅れ、公開後の検証漏れを記録すると、契約を変えるべきかを感情ではなく事実で判断できます。

よくある質問

既存の制作会社がSEOに詳しくなくても進められますか？

進められます。検索・計測側が確認事実と完了条件を整理し、制作会社が実装方法と影響範囲を判断する分担にします。仕様を「SEOを改善する」で止めないことが前提です。

既存制作会社にすべての権限を渡す必要がありますか？

必要ありません。作業に必要な範囲だけ、担当者・期間・環境を分けて付与します。GA4、Search Console、CMS、GitHubの権限設計はWeb改善支援にどこまで権限を渡すべきかで整理しています。

SIGNALが既存制作会社の代わりに実装する記事ですか？

代わりにすることを前提にしていません。契約範囲に応じて、公開情報の診断、改善仕様、実装支援、公開後の検証を分担します。実装担当と公開判断者は、案件ごとに明示します。

まとめ

既存のWeb制作会社を変えずに改善を進めるには、次の順で整えます。

1. 現契約、環境、権限、公開経路を確認する
2. Observe、Trace、Specify、Execute、Verifyを工程として分ける
3. RACIで実行担当と最終責任者を固定する
4. 課題1件ごとに、対象URL・事実・変更・完了条件・検証を渡す
5. 会議を意思決定と期限の場にする
6. 実装の完了と、公開後の効果観測を分ける

制作会社を変える判断が必要なケースもあります。ただし、契約や能力の問題と、受け渡し・責任者・検証の問題を分けて確認してから判断します。SIGNALの無料診断では、公開情報をもとに最初に確認すべき課題を整理します。検索順位、AI回答への掲載、問い合わせ数を保証するものではありません。