
WordPress 保守にかかるコストを 4 つの層(インフラ・定常作業・突発対応・機会損失)に分けて整理する考え方は、以前の記事で紹介しました。
本記事はその実践編です。フレームワークを理解したあとに残る「で、実際にどう埋めればいいのか」という部分を、記入手順・記入例・完成イメージまで含めて解説します。この記事の表をそのままコピーして、自社の数字を当てはめられる構成にしています。
目次
計算を始める前に集めておく情報
試算の精度は、手元に集める情報の精度で決まります。とはいえ、最初から完璧なデータは必要ありません。以下の 3 つが揃えば、議論の土台になる数字は作れます。
サーバ関連の請求情報(直近 3〜12 ヶ月分)
ホスティング費用、ドメイン、SSL 証明書、CDN や WAF を使っていればその利用料。経理部門に確認すれば、請求書ベースで正確な月額が把握できます。クラウドの従量課金部分は月ごとの変動があるため、平均値ではなく直近数ヶ月の実績を並べておくと説得力が増します。
担当者の作業時間の概算
正確なタイムトラッキングは不要です。「先月、WordPress の保守に関わる作業(アップデート確認・適用・動作確認・バックアップ確認など)に何時間使ったか」を担当者にヒアリングし、概算で構いません。思い出せない場合は、直近のアップデート作業1回分の所要時間 × 月の実施回数で逆算します。
過去 2〜3 年の突発対応の記録
サイト障害、プラグイン競合によるトラブル、不正アクセスの疑いへの対処、担当者交代時の引き継ぎ ── こうした「予定外の対応」を思い出せる範囲で書き出します。メールやチャットの履歴を「サイト 表示されない」「エラー」などで検索すると、忘れていた対応が掘り起こせることがあります。
テンプレートの全体像
テンプレートは 4 つの層に対応する 4 つの表で構成されます。各表を埋めたあと、最後に月額換算で合算します。
本記事では、作業時間の金額換算に時間単価10,000円を使用します。これは担当者の給与だけでなく、社会保険料などの会社負担分や間接コストを含めた、企業が人材 1 時間に支払っている実質的なコストの概算値です。自社の実態に合わせて調整してください。
表 1:インフラコスト(月次・固定)

「0 円」の項目も空欄にせず明記してください。「使っていない=対策していない」という現状の可視化も、この表の役割の一つです。
表 2:定常作業コスト(月次・人件費換算)

参考値として、プラグイン数が 20〜30 本程度の標準的な企業サイトでは、定常的な保守作業に月 3〜8 時間程度かかるケースが多く見られます(当社の支援経験に基づく目安です)。時間単価 10,000 円で換算すると月 3〜8 万円に相当します。自社の数字がこのレンジから大きく外れる場合は、作業の抜け漏れ(少なすぎる場合)や非効率な手順(多すぎる場合)がないかを確認するきっかけになります。
表 3:突発対応コスト(年次実績 → 月次換算)

実績が思い出せない、あるいは「幸い何も起きていない」場合は、この欄をゼロにするのではなく「実績なし(リスク未計上)」と明記してください。何も起きていないことと、リスクがないことは別です。この区別を表の上で示すこと自体が、意思決定者への誠実な情報提供になります。
表 4:機会損失コスト(参考値)
この層は月額の合計には含めず、参考情報として別枠で示します。定量化が難しいコストを他の実費と混ぜると、試算全体の信頼性を疑われるためです。

「サイトが 1 時間止まったらいくら失うか」という数字は、保守投資の必要性を経営層と話すときの共通の土台になります。精緻である必要はなく、桁感が共有できれば十分です。
記入例:2 つの実例とモデルケース
テンプレートの使い方を、実際の企業事例とモデルケースで示します。
実例 1:エンジニアの工数を事業部門の運用に置き換えたケース(カバー株式会社 / Amimoto)
VTuber 事業を展開するカバー株式会社では、以前は AWS EC2 上で直接 WordPress を運用しており、インフラ保守にかかるエンジニアの工数が課題になっていました。テンプレートでいえば、表 2 の作業をエンジニアが担っていた状態です。20 以上のサイトを運用しているため、1 サイトあたりの作業時間 × サイト数で定常作業コストが積み上がる構造でした。
Amimoto マネージドホスティングへの移行後は、インフラ構築から運用までの工数を大幅に削減し、事業部門の非エンジニアメンバーを中心とした運用体制を確立しています。エンジニアの時間単価を前提に計上されていた表 2 のコストが、委託料(固定額)に置き換わった形です。オートスケーリングと従量課金 CDN の組み合わせにより、イベント時のアクセス集中に対する手動でのキャパシティ調整もほとんど不要になっています。
カバー株式会社様 Amimoto マネージドホスティング利用事例
実例 2:運用人数を 4 人から 1 人に集約したケース(クリエイティブサーベイ株式会社 / Shifter)
顧客の声を事業成長につなげる SaaS を展開するクリエイティブサーベイ株式会社では、Shifter の導入により運用コストを従来の 1/4 に圧縮しました。以前は運用に 4 人ほどのメンバーが必要でしたが、現在は 1 人での運用が可能になっています。
テンプレートに当てはめると、表 2 の「月間時間」が複数人分の合算から 1 人分に減った、という変化です。仮に 4 人がそれぞれ月 5 時間ずつ関わっていた場合、20 時間 × 10,000 円 = 月 20 万円の定常作業コストが、1 人分の 5 万円に下がる計算になります。さらに、新プロダクト「Ask One」のサイトは 1 人・約 2 日という最短工数で公開を実現しており、これは表 3 の突発対応(この場合は臨時のサイト立ち上げ)にかかる工数が構造的に小さくなった例といえます。
クリエイティブサーベイ株式会社様|Shifter 活用により、1/4 の運用コスト・最短工数で Ask One プロダクトサイトリリースを実現
モデルケース:プラグイン 25 本・担当者兼務の企業サイト
架空のモデルケースとして、以下の条件で全欄を埋めた完成イメージを示します。
- コーポレートサイト 1 サイト、レンタルサーバで運用
- プラグイン 25 本、Web 担当者 1 名が他業務と兼務で保守
- 過去 2 年間にプラグイン起因の表示トラブル 2 回、担当者交代 1 回

「サーバ代は月 2,500 円」という認識だったサイトの実態が、人件費を含めると月 7〜8 万円となる、この差分の可視化が、テンプレートの最も重要なポイントです。
委託した場合のコストと並べる
現状コストが出たら、外部委託した場合の金額を隣に並べます。ここでは当社が提供する 2 つのサービスを例にします。
Shifter(静的化ホスティング)の場合
中規模ビジネス向けの Tier2 で月額 $60(年払いの場合 $48/月)です。日本円では為替により変動しますが、月 1 万円前後が目安になります。静的化により表 2 のアップデート関連作業の大半と、表 3 の障害対応リスクが構造的に小さくなるため、モデルケースであれば現状の実質月額コスト 77,500 円に対して、委託後は Shifter 利用料+コンテンツ更新作業(数時間分)程度に収まる試算が成り立ちます。
Amimoto マネージドホスティングの場合
動的 WordPress のまま運用する場合の選択肢です。料金はサイトの規模・構成により異なりますが、参考として Professional Large プランで月額 38,500 円(税込)、年払いの場合は 10% オフになります。インフラ領域(表 1 の一部と、表 2 のうち OS・ミドルウェア関連、表 3 のインフラ起因障害)が委託範囲になります。WordPress 本体・プラグインのアップデートはスコープ外のため、その部分も委託したい場合は WordPress アップデート代行との組み合わせになります。モデルケースの実質月額コスト 77,500 円と比較すると、Amimoto 単体で月 38,500 円。一見コストが並んでいるように見えますが、社内運用側の 77,500 円には突発対応の変動リスクと属人性が含まれており、委託側は固定額でインフラ起因の障害対応まで含まれる ── この「予測可能性の差」が金額の比較に隠れた論点です。
比較表にする際は、金額だけでなく次の軸を含めてください。

社内で見せるときの注意点
いくつか簡潔に触れておきます。委託後の金額が現状の実質コストを下回らないケースもありますが、その場合でも突発対応の予測可能性や属人性の解消という価値は残ります。人件費按分の内訳はメモを残し、根拠を聞かれたら答えられるようにしておくこと。機会損失は実費と混ぜて合計せず、参考値の位置づけを守ること。この3点を押さえておけば、試算の信頼性は保てます。
数字に表れないコスト ── 「自分が判断しなければならない」という負荷
ここまでのテンプレートは、時間とお金に換算できるコストを扱ってきました。しかし、保守を社内で抱えることのコストには、数字にしにくいもう一つの層があります。それは、担当者が負い続ける心理的な負荷です。
脆弱性情報が公開されたとき、このアップデートを今すぐ適用すべきか、様子を見てよいのか。プラグインを更新したらサイトが崩れないか。障害が起きたとき、原因の切り分けを自分ができるのか ── こうした判断を、専門外の担当者が一人で下し続ける状態は、作業時間の多寡とは別の消耗を生みます。「何かあったら自分の責任になる」という緊張感は、兼務担当者の場合、本来の業務への集中も削っていきます。
外部委託がもたらす価値の一つは、この判断の負荷を専門家に委ねられることです。LabWorks では、WordPress と AWS の両領域に 12 年以上の運用実績を持つチームが、脆弱性情報のモニタリングから対応の優先順位づけまでを担います。担当者は「判断する人」から「報告を受けて確認する人」に立場が変わります。経営層や情報システム部門から「セキュリティ対策はどうなっているか」と問われたときも、委託先からの説明をもとに答えられる体制になるため、説明責任の面でも担当者が一人で抱え込む必要がなくなります。
この心理的コストの低下は本記事のテンプレートには金額として載りませんが、委託を検討する際の判断材料としては、数字と同じ重みを持つ要素だと我々は考えています。試算の数字が拮抗しているとき、最後の決め手になるのはこの部分であることも少なくありません。
まとめ
WordPress 保守の費用対効果を判断するには、まず現状の実質コストを 4 層に分けて可視化することが出発点です。本記事のテンプレートを使えば、サーバ請求書・担当者へのヒアリング・過去の対応記録という 3 つの情報から、意思決定者と共有できる数字を作れます。
数字を埋めてみて「そもそも何が保守の範囲に入るのか判断がつかない」「委託した場合の見積もりと比較したい」という段階になったら、LabWorks へご相談ください。現状のヒアリングから保守範囲の整理、比較検討まで一緒に進めることができます。
関連リンク
当社へご興味をお持ちいただきありがとうございます。
「こんなことやってみたい!」と、ぜひ気軽にご相談ください。
担当者よりご連絡差し上げます。










