WordPress外注の判断基準｜開発と保守を一体で整理する4パターン

WordPress サイトの制作や保守を外部に発注しようとして、「開発の相場」「保守の相場」を個別に検索していると、次のような壁にぶつかりませんか。制作会社が並んだ比較記事、保守サービスの料金プラン、月額いくらで何が含まれるかの一覧。情報は山ほど見つかるのに、いざ社内で「うちはどう発注すればよいのか」を説明しようとすると、判断軸がまとまらないという状態です。

WordPress 外注に関する情報の多くは「開発」と「保守」を分けて扱っています。しかし発注者側の意思決定では、この2つは切り離せません。開発時にどんな設計をしたかが保守負荷を決めますし、保守を誰に任せるかで開発ベンダーの選び方も変わります。分けて考えるほど、比較すべき軸が増えて判断が止まってしまうのです。

そこで本記事では、WordPress 外注を「①社内で抱える」「②開発だけ外注」「③保守だけ外注」「④開発・保守とも外注」の 4 パターンとして一体で整理し、自社に合うパターンを 1 つに絞り込むための判断基準を発注者の視点でまとめました。費用相場・見積もりの読み方・契約時の確認項目・発注前の社内棚卸しリストまで、社内稟議で使える形で解説します。

読み終えたときには「うちの場合はこのパターンで、比較軸はこれで、相見積もりではここを見る」というアクションプランを持ち帰っていただける構成にしています。

WordPress 外注の 4 パターンを整理する

意思決定を進める前に、そもそも WordPress 外注には大きく 4 つのパターンがあります。相見積もりやベンダー選定で迷子にならないよう、まずはこの 4 パターンから 1 つを選ぶことをゴールに設定してください。

4 パターンの一覧

開発フェーズと保守フェーズについて、それぞれ「内製」か「外注」かで整理すると、次の 4 パターンに分類できます。

「一括か分業か」の議論はパターン④の中の派生（同じ会社に任せるか、開発会社と保守会社を分けるか）として扱います。まずは 4 パターンのどれを選ぶかを決めてから、必要に応じて分業設計に進んでいく順序が意思決定の負荷を下げるコツです。

4 パターンごとに向く典型ケース

各パターンには向いている企業の典型的な状況があります。社内の状況と照らし合わせて、最初の当たりをつけてください。

• ①フル内製が向くケース: 社内に WordPress の運用経験があるエンジニア・情シス人材がいる／複数の Web プロパティを継続的に運用しており、ノウハウが社内に蓄積されている／セキュリティポリシー上、外部ベンダーにサーバー権限を渡せない
• ②開発だけ外注が向くケース: 新規制作・リニューアルは技術力が必要だが、公開後の運用は情シス・広報担当で対応可能／既に運用しているサイトがあり、社内の運用体制ができている／将来的に内製化したいので、開発時にノウハウ移管も含めて依頼したい
• ③保守だけ外注が向くケース: 既存サイトの運用負荷が担当者のキャパシティを超えている／担当者の退職・異動でノウハウが途切れた／セキュリティ対応・障害対応に不安があるが、開発は今後発生しない
• ④開発・保守とも外注が向くケース: 社内に Web 担当者がいない、または他業務との兼務で手が回らない／サイトが売上・信頼に直結するため、専門的な運用体制が必要／継続的な機能追加や改修が発生する見込み

このパターン分類は、後述の判断軸（社内リソース・サイト重要度・許容ダウンタイム）とも接続します。次章以降で、それぞれのパターンを深掘りしていきます。

開発と保守で発生する作業を分解する

外注範囲を判断する前提として、「開発」「保守」という言葉の中身を分解しておきます。作業カテゴリごとの技術要求レベルを把握することで、内製と外注の線引きがしやすくなります。

開発フェーズの作業

WordPress の開発フェーズには、次のような作業が含まれます。

• 新規制作: 要件定義、情報設計、デザイン、テーマ開発（オリジナルテーマ or 既存テーマのカスタマイズ）、コーディング、CMS 構築、初期コンテンツ投入
• リニューアル: 既存サイトからのコンテンツ移行、URL 設計、リダイレクト設定、SEO 引き継ぎ、デザイン刷新
• 機能追加: 問い合わせフォーム、会員機能、決済連携、外部 API 連携などのプラグイン開発・カスタマイズ
• カスタマイズ: 既存テーマの部分修正、独自のカスタム投稿タイプ・カスタムフィールドの実装

これらは HTML/CSS/PHP/JavaScript の知識に加え、WordPress のフック（アクション・フィルター）や標準関数の理解が必要になります。特にオリジナルテーマ開発・機能追加は、社内の情シス兼務担当者では対応が難しいレベルです。

保守フェーズの作業

公開後の保守フェーズには、次のような作業があります。

• アップデート対応: WordPress 本体・テーマ・プラグインのバージョンアップ、動作確認、互換性チェック
• バックアップ: 定期的なファイル・データベースのバックアップ、リストア手順の確認
• 稼働監視: サイトのダウン検知、応答速度モニタリング、SSL 証明書の有効期限管理
• 障害対応: 表示崩れ・404 エラー・500 系エラーの復旧、プラグイン競合の切り分け
• セキュリティ対応: 脆弱性情報の追跡、改ざん検知、不正ログイン監視、WAF の設定
• 軽微修正: テキスト差し替え、画像差し替え、リンク修正、記事投稿の代行

保守は「動いていて当たり前」の状態を維持する仕事ですが、実務ではアップデートによる互換性トラブル、プラグイン競合による表示崩れなど、想定外の対応が発生します。作業ボリュームは月ごとに変動するため、月額定額プランでどこまでカバーされるかは業者ごとに違います。

開発と保守の連続性

開発時の設計判断は、保守フェーズの負荷を大きく左右します。たとえば次のような設計上の選択が、後々の運用コストに直結します。

• テーマの選び方: 有償テーマを使うと初期費用は下がるが、テーマ提供元のアップデート打ち切り・仕様変更が発生すると保守負担が増える
• プラグインの使い方: 便利なプラグインを多数導入するとカスタマイズが早いが、プラグイン同士の競合や個別プラグインのアップデート停止で保守が複雑化する
• カスタマイズ範囲: WordPress のコア機能を書き換える形でカスタマイズすると、コア更新のたびに手作業での再適用が必要になる

つまり、「開発」と「保守」は分断された作業ではなく連続しており、開発フェーズでどんな選択をしたかが、その後 5 年 10 年の保守コストを決めます。この視点は、後述する「同じ会社に一括で頼むか、開発と保守を分けるか」の判断にも直結します。

外注か内製かを判断する 3 つの軸

「そもそも社内で抱えるか、外部に出すか」を決めるための 3 つの軸を提示します。それぞれの軸を順に評価し、最後に 2×2 マトリクスで自社の位置を診断してください。

判断軸 1: 社内リソース

自社に Web 担当者がいるか、いる場合にどの範囲の作業ができるかを棚卸しします。

• Web 担当者がいない: 記事投稿・文言修正すらできない → 保守を外注する必要性が高い
• Web 担当者が兼務でいる: 記事投稿と軽微な文言修正はできるが、プラグイン設定変更やエラー切り分けは難しい → 保守の一部（特にアップデート対応・障害対応）を外注する構成が現実的
• エンジニアが専任でいる: WordPress のカスタマイズ・障害対応まで社内で完結できる → 内製化の余地が大きい

ここで注意したいのは、「担当者がいる」ことと「継続対応が可能」であることは別だという点です。担当者が退職・異動した場合の代替要員がいなければ、実質的にはリソース不足として扱うべきです。

判断軸 2: サイトの重要度

サイトが自社ビジネスにどれだけ直結しているかを評価します。重要度が高いほど、専門的な保守体制が必要になります。

• 売上に直結するサイト: EC・受注フォーム・見積依頼が主要導線 → ダウンタイム・障害の影響が大きく、専任の保守体制が必要
• リード獲得・問い合わせ経路として重要: 資料ダウンロード・問い合わせフォームが機能 → セキュリティインシデントが起きた場合の信頼失墜が大きいため、外部の保守体制で堅牢性を確保したい
• 情報発信中心: コーポレートサイト・オウンドメディア → ダウンタイムの直接的な売上影響は小さいが、SEO 資産の毀損リスクは考慮が必要
• 社内向け・軽量サイト: 情報公開が主目的 → 保守の優先度は相対的に低く、コストを抑えたプランでも許容される

判断軸 3: 許容できるダウンタイム

サイトが停止した場合に、どのくらいの時間まで許容できるかを評価します。ここが厳しいほど、SLA（サービスレベル合意）付きの外注が必要になります。

• 数時間の停止でも売上・信頼に影響が出る: SLA を明記した保守契約が必須。24 時間 365 日の障害対応窓口を持つ業者を選ぶ
• 半日〜 1 日は許容できる: 平日日中の対応で問題ない一般的な保守プランで対応可能
• 数日は許容できる: 内製での対応、またはスポット契約の保守で十分

2×2 マトリクスで自社の位置を診断する

3 軸を組み合わせて、まずは 2×2 のマトリクスで大枠を掴んでください。縦軸に「サイトの重要度（高／低）」、横軸に「社内リソース（有／無）」を取ると、次のような 4 象限になります。

このマトリクスは「絶対の答え」ではなく、初期仮説を作るためのツールです。次章の「一括依頼 vs 分業依頼」で、パターンを更に絞り込んでいきます。

開発と保守を同じ会社に依頼すべきか、分けるべきか

パターン④（開発・保守とも外注）を選んだ場合、「同じ会社に一括で頼むか、開発会社と保守会社を分けるか」という判断が発生します。この論点は競合記事ではあまり整理されていませんが、実務では大きな影響があります。

一括依頼のメリット・デメリット

開発と保守を同じ会社に任せるパターンです。多くの開発会社は保守プランをオプション提供しています。

メリット:

• 開発時の設計意図が保守に引き継がれるため、障害対応・機能追加時の調査工数が少ない
• 窓口が 1 社に集約されるため、コミュニケーションコストが低い
• 開発と保守の責任範囲が明確で、「開発の不具合か、運用ミスか」の切り分けで揉めない
• 長期契約を前提とすれば、開発費用の値引き交渉がしやすい

デメリット:

• 保守の専門性が開発会社の得意分野に依存する（開発は強いがインフラ運用に弱い会社もある）
• 契約ロックインが強く、他社に切り替える際の移管コストが大きい
• 値付けの透明性が下がる（保守費用がバンドルされて、内訳が見えにくくなるケースがある）
• 開発会社の廃業・撤退リスクが、そのまま保守停止リスクになる

分業依頼のメリット・デメリット

開発は制作会社、保守は運用専門会社に分けるパターンです。

メリット:

• 保守専業の会社は障害対応・セキュリティ対応の専門性が高い（24 時間 365 日対応・多数のサイトを並行監視する体制が整っている）
• 保守費用の値付けが独立するため、比較検討がしやすい
• 開発会社の変更が保守に影響しないため、ロックインリスクが低い
• 保守会社が中立的な立場で、開発会社の成果物（品質・ドキュメント）を評価できる

デメリット:

• 開発時の設計意図が保守会社に引き継がれない可能性があり、初期の情報連携が必要
• 窓口が 2 社に分かれるため、障害発生時の切り分けや責任範囲の合意が必要になる
• 契約管理・支払管理の手間が増える
• 保守会社の受け入れ条件（対応可能なテーマ・プラグイン・ホスティング環境）に開発仕様を合わせる必要がある

一括 vs 分業を判断するチェックリスト

以下の項目でチェックが多い方を選ぶのが目安です。

一括依頼が向くケース:

• 開発から公開まで短期間で進めたい（意思決定の速さ優先）
• サイト規模が小さく、保守作業も限定的
• 社内に発注管理の余力があまりない（窓口を 1 社にまとめたい）
• 継続的な機能追加が見込まれる（開発会社と同じ会社で対応する方が効率的）

分業依頼が向くケース:

• サイトの重要度が高く、保守の専門性を最優先したい
• 数年後に保守会社を乗り換える可能性を残しておきたい
• 開発会社に対する保守業務のセカンドオピニオンを持ちたい
• 24 時間 365 日の障害対応など、開発会社では対応できない SLA が必要

判断がつかない場合は、まず「開発と保守を同じ会社に一括で依頼するが、契約は開発契約と保守契約に分けて締結する」という中間形を検討してください。契約が分離していれば、後から保守会社を切り替える選択肢を残せます。

WordPress 外注の費用相場と見積もりの読み方

費用相場の情報は、意思決定の最終フェーズで比較軸として使います。ただし「金額だけ」で選ぶと後悔する典型パターンなので、「何が含まれているか」の読み方をセットで押さえてください。

開発費用の相場

新規制作・リニューアルの費用相場を規模別に整理します。以下は 2026 年時点の一般的な目安です（出典: Web幹事「WordPressホームページ制作費用の相場」、ok-design「WordPressホームページの費用相場」 ほか）。

• 小規模（5〜10 ページ、既存テーマ活用）: 30 万〜 100 万円。テンプレートベースのため制作期間は 1〜 2 ヶ月
• 中規模（10〜 20 ページ、部分オリジナルデザイン）: 100 万〜 300 万円。標準的なコーポレートサイトはこのレンジ
• 大規模（オリジナルデザイン、機能開発を含む）: 300 万〜 800 万円以上。ページ数が多い、または EC・会員機能・外部システム連携を伴うケース

同じ「中規模」でも、要件定義・デザイン工程の深さ、オリジナルテーマ開発かテーマカスタマイズか、公開後の運用ドキュメント作成の有無で 100 万円単位で金額が変わります。WordPress 案件に限らず、システム開発全般の見積もりで「どこに費用が乗るか」を体系的に押さえたい場合は、システム開発における見積もりのチェックポイントも併せてご参照ください。

保守費用の相場

保守費用は月額プランで提供されることが多く、含まれる作業範囲によって次のようなレンジになります（出典: DigitalCube LabWorks「WordPress 保守の費用相場」、アウルキャンプ「WordPress保守費用の相場」 ほか）。

• ライトプラン（月額 5,000〜 10,000 円）: 本体・テーマ・プラグインのアップデート、定期バックアップ、稼働監視。障害対応は別料金
• スタンダードプラン（月額 10,000〜 20,000 円）: 上記＋セキュリティ監視、月次レポート、軽微な修正対応（月 2〜 3 回）
• フルサポートプラン（月額 20,000〜 50,000 円）: 上記＋コンテンツ更新代行、24 時間障害対応、優先サポート、改善提案

金額差は「1 ヶ月あたりに含まれる作業時間」「緊急対応の対応時間」「自動化ツールで済ませるか人が確認するか」といった要素で生まれます。単純な金額比較ではなく、「自社が求める SLA・作業範囲に対して、この金額でカバーされているか」の観点で見比べてください。

見積書で確認すべき項目

見積書を読むときは、次のポイントを必ず確認してください。金額が同じでも中身は全く違うケースがあります。

• 含まれる作業範囲: どの作業が定額に含まれ、どの作業が別料金か。「軽微な修正」の定義（何分・何箇所までか）
• アップデート範囲: WordPress 本体のみか、テーマ・プラグインまで含むか。有償プラグインの更新料は誰が負担するか
• バックアップの頻度・保存期間: 日次か週次か、何世代残るか、リストアは無料か有料か
• 障害対応の対応時間・応答時間: 平日日中のみか 24 時間か、初動応答は何時間以内か
• 追加費用が発生する条件: 「範囲外の作業」「大幅な仕様変更」の定義。時間単価はいくらか
• サーバー・ドメイン・SSL 費用: 保守費用に含まれるか、実費請求か
• 報告書・レポートの提供頻度: 月次レポートの内容と提供形式

これらが見積書に明記されていない場合は、必ず問い合わせて書面で回答をもらってください。契約後のトラブルの大半は、「言った・言わない」ではなく「書いていない・書いていた」で決着します。

5 年 TCO で比較する考え方

初期費用と月額費用を別々に比較すると、意思決定を誤りやすくなります。5 年間の総コスト（TCO = Total Cost of Ownership）で見比べる視点を持ってください。

たとえば、次の 2 つの提案を比較してみます。

初期費用だけを見ると B 社は 2 倍高く見えますが、5 年トータルでは B 社の方が安いという結果になります。もちろん、実際にはサービス品質・機能追加の必要性なども加味しますが、まずは 5 年 TCO で「土俵を揃える」ことが比較の第一歩です。

複数社の見積もりを並べても金額差の理由が読み解けない場合は、相見積もり比較ガイドで「なぜ会社ごとに見積もりが違うのか」の構造を整理していますので、比較軸の点検にご活用ください。

発注前に確認すべき契約・運用ポイント

金額に現れない「隠れ論点」を発注前に確認しておくことで、契約後のトラブルを大幅に減らせます。相見積もりを取る際・契約書を確認する際は、次のチェックリストを使ってください。

SLA（対応時間・緊急対応・復旧時間の合意）

SLA（Service Level Agreement）は、業者がどのレベルのサービスを保証するかの合意事項です。少なくとも次の項目は書面で確認してください。

• 対応時間: 平日 9〜 18 時か、24 時間 365 日か
• 初動応答時間: 障害連絡から何時間以内に応答するか
• 復旧目標時間: どのレベルの障害を、何時間以内に復旧させるか
• 稼働率保証: 99.9% など、月間の稼働率の目標値
• 未達成時の対応: SLA を満たせなかった場合の返金・減額の有無

「対応します」「善処します」といった抽象的な表現は、いざ障害が発生したときに実効性を持ちません。数値で書かれた合意事項があるかを確認してください。

権限管理（サーバー・DB・管理画面へのアクセス範囲）

保守を委託すると、業者にサーバー・データベース・WordPress 管理画面のアクセス権を渡すことになります。情報漏洩・不正操作のリスクを抑えるため、次を確認してください。

• アクセス権限の付与範囲: 管理者権限を渡すか、限定した権限で運用するか
• アクセスログの取得: 誰がいつ何を操作したかのログが残るか
• アクセス経路の管理: VPN 経由、IP 制限、多要素認証などの制約があるか
• 担当者の管理: 業者側の担当者が退職・異動した場合のアカウント削除フローが明確か
• 秘密保持契約（NDA）: 契約書に秘密保持条項が含まれているか、期間は何年か

「渡した権限は最終的に自社の管理責任」と考え、契約書での縛りだけでなく、社内側でも定期的な権限棚卸しの仕組みを作ってください。

契約解除・引き継ぎ条件（他社への移管可否）

保守業者を将来変更する可能性を想定して、契約解除と引き継ぎの条件を確認します。

• 契約解除の予告期間: 何ヶ月前に通知が必要か
• 引き継ぎ資料の提供: サーバー情報・アカウント情報・独自カスタマイズの仕様書などが引き継ぎ時に提供されるか
• データの返却・削除: 契約終了時にデータをどう扱うか
• 移管作業の費用: 引き継ぎ作業に別途費用が発生するか

ここが曖昧なまま契約すると、実質的に「その業者以外に切り替えられない状態」でロックインされます。契約段階で「もし将来切り替える場合、どう対応するか」を必ず確認してください。

追加費用が発生する条件

「これは追加費用です」と契約後に言われるのを防ぐため、追加費用の条件を明文化しておきます。

• 軽微修正の範囲: 何分・何箇所・何回までが定額に含まれるか
• スコープ外の作業: 新規機能追加・大幅なデザイン変更などの扱い
• 時間単価: 追加作業の時間単価はいくらか、事前見積もりは必須か
• 緊急対応の追加料金: 夜間・休日対応の追加料金の発生条件
• サーバー移転・ドメイン変更: これらが発生した場合の作業費用

契約書だけでなく、実際の運用フローとしても「追加費用が発生する作業は、事前に見積もりを提示してもらう」を業務プロセスに組み込んでおくと、後々のトラブルを防げます。

発注前に社内で準備すべき情報と、判断フローチャート

相見積もりに入る前に、社内で棚卸ししておくべき情報があります。この準備がない状態でベンダーとの打ち合わせに入ると、業者からの提案がバラバラで比較できません。最後に、本記事全体を 1 枚の判断フローとしてまとめます。

発注前チェックリスト（社内棚卸し項目）

相見積もりの前に、次の情報を社内で整理してください。ベンダーに開示する情報を揃えることで、見積もりの精度が上がり、比較がしやすくなります。

• 現行サイトの情報（既存サイトのリニューアル・保守見直しの場合）
  • WordPress のバージョン
  • 使用中のテーマ（オリジナル / 有償 / 無償テーマの種類）
  • インストール済みのプラグイン一覧
  • ホスティング環境（サーバー、CDN、ドメイン管理会社）
  • 現在の管理体制（誰がアップデートしているか、直近の障害履歴）
• サイトの目的・KPI
  • 制作・保守の目的（リード獲得、EC、情報発信など）
  • 主要 KPI（月間 PV、CV 数、目標売上）
  • 想定されるトラフィック規模と季節変動
• 予算感
  • 開発の初期予算（レンジで OK）
  • 月額保守予算のレンジ
  • 5 年トータルの許容予算
• 担当者リソース
  • 社内の Web 担当者の人数と業務範囲
  • 記事投稿・軽微修正を誰が担当するか
  • 業者との窓口担当者
• セキュリティ・コンプライアンス要件
  • 個人情報を扱うか、扱う場合の管理要件
  • アクセス権の付与制約
  • 監査対応の必要性

これらを 1 枚の資料にまとめておくと、複数ベンダーへの見積依頼が効率的に進みます。各社に同じ情報を渡すことで、比較の土俵が揃うのも大きなメリットです。

判断フロー（4 パターン診断 → 一括 or 分業 → 見積比較 → 契約チェック）

本記事全体の意思決定ロジックを、判断フローとしてまとめます。上から順に判断していくことで、比較軸が定まらない不安が解消されます。

1. 社内棚卸しを完了する: 上記の発注前チェックリストで自社の情報を揃える
2. 判断軸 3 つで自社の位置を評価する: 社内リソース・サイト重要度・許容ダウンタイムの 3 軸で、2×2 マトリクスの位置を決める
3. 4 パターンから 1 つを選ぶ: フル内製 / 開発だけ外注 / 保守だけ外注 / 開発・保守とも外注のいずれかに絞る
4. 外注する場合、一括か分業かを決める（パターン④のみ）: 前述のチェックリストで、一括依頼か分業依頼かを選ぶ
5. 相見積もりの依頼要件を作る: 開発と保守の要件、SLA、権限管理、契約解除条件を明記した RFP（提案依頼書）を作成
6. 3 社程度で相見積もりを取る: 5 年 TCO で比較し、見積書の中身（含まれる作業範囲・追加費用条件）を確認
7. 契約チェックリストで契約書を確認する: SLA、権限管理、契約解除、追加費用条件が明文化されているかを確認
8. 契約締結後の運用フローを合意する: 追加作業の見積依頼フロー、月次レポートの内容、緊急連絡フローを事前に合意

このフローは「順序が大事」です。特にステップ 2〜 4（自社の位置評価 → 4 パターンから選択 → 分業判断）を飛ばして、いきなり見積もりを取りに行くと、業者ごとの提案がバラバラで比較不能になります。裏返せば、上から順に判断を積み上げることで、比較軸が定まらない不安が解消されるということです。

WordPress の外注は、選択肢の多さゆえに意思決定が難しく見えます。しかし、「開発と保守を一体で捉える」「4 パターンから 1 つを選ぶ」「判断の順序を守る」の 3 つを押さえれば、社内稟議で説明できる根拠を持って発注に進めます。本記事のチェックリスト・判断フローを、相見積もりの前段で使っていただければと思います。