HTML5開発の保守・運用費用・ランニングコストについて

HTML5アプリの保守・運用費用は、月額数千円から100万円以上まで幅があります。その幅を左右するのは、対象システムの規模、契約形態、対応範囲の3つです。

費用の内訳、HTML5特有の保守論点、保守体制と契約の選び方の順に説明します。全体像はHTML5開発の完全ガイドでも確認できます。

▼全体ガイドの記事
・HTML5開発の完全ガイド

HTML5開発の保守・運用費用の全体像

保守・運用費用を、人件費、更新費用、インフラ・SaaS費用の3つに分けた図。
費目ごとの対象を分けると、見積もり範囲を確認しやすくなります。

HTML5を含むWebアプリの保守・運用費用は、3つの費目に分けて考えます。費用は対象システムの規模におおむね比例するため、初期開発費を基準にすると見通しを立てやすくなります。

規模別に見ると、小規模は開発費50万〜200万円で月額数千円〜5万円程度、中規模は開発費200万〜1,000万円で月額5万〜20万円程度です。大規模になると、開発費は1,000万〜3,000万円以上、月額は30万〜100万円以上になります。

月額保守費用は、初期開発費の0.5%〜1.5%程度に収まることが多いとされます。ただし、リッチコンテンツや動画配信を多用する場合は、インフラの従量課金が上乗せされます。

HTML5アプリは、ブラウザという外部環境の変化に常にさらされます。サーバーサイドが自社管理下の実行環境で動くのに対し、HTML5のフロントエンドは多様なブラウザ、OS、端末で動作します。

新しいブラウザが出るたびに、表示や動作が変わる可能性があります。この環境追従コストを見込まないと、運用後に保守費が想定を超えてしまいます。

保守・運用費用の内訳

保守・運用費用は、人件費、更新費用、インフラ・SaaS費用の3つで構成されるため、費目ごとに何が含まれるかを押さえておくと見積もりの抜けが減ります。

  • 人件費:保守作業を担当する人の工数
  • 更新費用:パッケージやライブラリを更新するための費用
  • インフラ・SaaS費用:配信基盤と外部サービスの利用料

人件費には、ブラウザ更新によるレイアウト崩れの修正が含まれます。保守の担当者は、Service Workerのキャッシュ管理や、video・audioの不具合にも対応します。また、ユーザーからの問い合わせ対応や軽微な機能改善も、人件費の対象です。

HTML5アプリは、多数のJavaScriptライブラリに依存することがあります。そして、脆弱性が見つかるたびに、パッケージの更新とセキュリティ監査が必要になります。更新を放置すると、セキュリティリスクに直結します。

インフラ・SaaS費用には、クラウドサーバー代が含まれます。動画配信に使うCDNの従量課金も、インフラ費用の一部です。さらに、外部APIやノーコードツールのライセンス費用も確認しておく必要があります。

動画やCanvasの配信データ量が増えるほど、ランニングコストは膨らみます。このため、3費目を切り分けておくことが、運用予算を正しく見積もる第一歩になります。

月額相場と契約形態

契約形態は、必要な対応がどれだけ続くかと、毎月の固定費をどこまで抑えたいかで選びます。

  • SES・準委任契約:毎月の稼働時間を確保する契約
  • SIer型:基本料と成果報酬による管理
  • スポット保守:不具合や改修のたびに依頼する方式

SES・準委任契約は、毎月決めた時間数のリソースを提供してもらう形態です。エンジニア0.5人月分などで契約することがあり、人月単価は55万〜95万円が目安です。ブラウザ追従やアクセシビリティ維持のように継続的な作業が続くなら、準委任型が適しています。リッチコンテンツの調整など、柔軟な対応も依頼できます。

SIer型は、大企業の基幹系システムや長期保守と相性がよく、ベンダーが主導してプロジェクト単位で管理します。

スポット保守は、毎月の固定費を抑えられる一方で、即時対応の保証がありません。たとえば、iOSの更新で動画が再生できない場合だけ修正を依頼するといった使い方もできます。そのため、重要なサービスは準委任、影響度の小さいサイトはスポット保守が現実的です。

契約を結ぶ際は、対応時間の上限、緊急時のSLA、対応範囲を、あらかじめ明確にしておきます。

ポイント

判断に迷ったら、まず初期開発費がどの規模区分に当たるかを見ます。初期開発費を基準にすると、月額保守費の見当をつけやすくなります。

HTML5固有の保守論点

HTML5保守の環境追従を、主要ブラウザ、Safari(iOS)、Web標準仕様、レガシー資産の4項目で示した図。
公開後も各環境の更新に合わせた確認と対応が続きます。

HTML5アプリの保守で押さえたい論点は、ブラウザ互換・Web標準への追従とアクセシビリティの2つです。いずれも公開中は作業が継続して発生します。

ブラウザ互換とWeb標準仕様の更新追従

ブラウザ互換とWeb標準への追従は、HTML5保守の中心的な仕事です。具体的には、主要ブラウザの表示確認、Safari(iOS)の動画再生、非推奨APIの置き換え、レガシー資産の互換性維持の4つに分かれます。

  • 主要ブラウザ:Chromeなどの更新に伴う表示と動作の確認
  • Safari(iOS):OS更新後の動画再生の挙動
  • Web標準仕様:非推奨APIの推奨手法への置き換え
  • レガシー資産:HTML5移行後の互換性の維持

Chrome、Safari、Edge、Firefoxは、それぞれ異なる予定で更新されます。更新のたびに、レイアウト崩れや特定機能の挙動変化が起きる可能性があるため、新バージョンのリリースごとに主要画面の表示と動作を確認し、問題があれば修正します。

なかでもSafari(iOS)は、OS更新で動画の自動再生ポリシーが変わることがあります。video要素の挙動が変わり、突然動画を再生できなくなる場合もあります。

HTML5周辺のWeb標準も継続的に更新され、既存APIが非推奨(deprecated)になって、推奨手法に置き換わることもあります。こうした変化を放置すると、動かない機能が徐々に増えていきます。

Flash廃止後にHTML5へ移行したレガシー資産も、互換維持の対象です。環境追従コストは、公開中に発生し続ける固定的な費用として見込んでおきます。

アクセシビリティ(WCAG)の継続的な対応

アクセシビリティ(WCAG=Web Content Accessibility Guidelines)への対応は、公開後も続きます。コンテンツを追加や更新するたびに、対応状態を保つ必要があります。

  • 画像:追加時に適切なalt属性を設定する
  • フォーム:入力欄とラベルを関連付けておく
  • 動画:追加時に字幕を用意する
  • 意味構造:main・nav・footerを適切に使い分ける

HTML5のセマンティック要素(`main`・`nav`・`footer`など)を正しく使うと、スクリーンリーダーでランドマークを移動できます。逆に、改修で構造が崩れると、アクセシビリティは低下します。

行政機関や大企業では、法令や調達要件としてアクセシビリティが求められることがあります。対応を怠ると、取引上のリスクにもつながります。

保守契約には、コントラスト比やキーボード操作の定期確認を組み込みます。スクリーンリーダーでの読み上げ確認も、長期的な品質維持に役立ちます。さらに、放置してからまとめて改修すると高くつくため、運用中に少しずつ対応を続けるほうが負担を抑えられます。

ポイント

動画やCanvasのように挙動が変わりやすい機能を使う場合は、ブラウザ追従とWCAG対応の工数を厚めに見込むのが判断の目安です。公開後も更新が続く前提で、月額の枠を組みます。

インフラ・配信コストとPWAの運用

動画やリッチコンテンツの配信コストに関わる、静的サイト、CDN従量課金、予算管理、配信最適化を示した図。
転送量に応じた費用は、予算管理と配信調整で扱います。

HTML5のリッチ機能は体験を高める一方で、運用工数とインフラ費用に影響します。Canvasや動画の配信、PWAのキャッシュ運用は、HTML5ならではのコスト要因です。

動画配信・リッチコンテンツのインフラ費用

動画やCanvasを使う場合は、配信データ量を基準に費用を見積もります。

  • 静的サイト:月額数千円〜数万円で運用できる配信方式
  • CDN従量課金:転送量に応じて料金が増える仕組み
  • 予算管理:上限と予算アラートの設定
  • 配信最適化:転送量を抑えるための調整

テキストと画像が中心なら、Cloudflare Pagesなどで運用できます。VercelやAWS Amplifyも、同じ規模の運用に使えます。

動画を多用すると、CDN(コンテンツ配信ネットワーク)の比重が増します。CDN料金は視聴データ量、つまり転送量に比例して発生するため、ユーザー数や動画の視聴時間が増えるほど、コストは膨らみます。

人気が出てアクセスが急増すると、インフラ費用が一気に跳ね上がるリスクがあります。そこで、動画は解像度とコーデックを適切に変換して転送量を抑えるほか、視聴環境で画質を変えるアダプティブビットレートも有効です。

Canvasのリアルタイム描画やWebGLでは、クライアント負荷も考慮します。また、サーバーから必要なデータを配信する仕組みの費用も確認します。

クラウドに強いエンジニアは人月単価が高い傾向にあるため、最適化を担える人材の確保も含めて、運用コストを見積もります。

PWA・Service Workerのキャッシュ運用

PWA(Progressive Web Apps)を導入したHTML5アプリでは、Service Workerによるキャッシュ運用が保守の重要テーマです。

  • キャッシュ:ファイルを一時保存して、オフライン動作を支える仕組み
  • バージョン管理:更新時にキャッシュキーを変える作業
  • プッシュ通知:配信基盤と許可状態の管理

キャッシュ戦略を誤ると、更新後も古い画面が表示され、新機能が反映されないまま問い合わせやクレームにつながることがあります。

そのため、リリースのたびにキャッシュを切り替え、古いファイルを確実に破棄します。新しいファイルを配信する仕組みも、保守対象として維持します。

PWAは、公開後も更新フローにキャッシュ管理が加わり続けます。そのため、通常のHTML5アプリより保守の難度が上がります。

Service Workerを理解したエンジニアが対応できる体制を整えておく必要があります。専門性が求められるため、準委任型で人材を継続して確保する価値が高まります。

ポイント

配信データ量の見込みが立てにくい段階では、CDNの従量課金に上限と予算アラートを設けておくと、想定外の請求を抑えやすくなります。

保守体制の選び方と契約のポイント

保守費用は、自社に合う体制と契約条件で管理します。内製か外注かの選択が、運用フェーズのコストと品質を左右します。

内製と外注のメリット・デメリット

内製と外注は、サービス規模と社内エンジニア体制を基準に比べます。

  • 内製の利点:仕様に詳しい担当者による改修
  • 内製の課題:固定人件費と属人化
  • 外注の利点:必要なリソースを変動費で確保
  • 外注の課題:連絡とコード理解の負担

内製では、サービスやコードを熟知した担当者が不具合を調べるため、ビジネスの変化にも柔軟に対応できます。また、ブラウザ対応やアクセシビリティの知見を、社内に蓄積できます。

長期的には内製のコスト効率が高まることもありますが、フロントエンドエンジニアの固定人件費は継続的に発生します。さらに、特定の担当者に依存する属人化も課題で、担当者が退職すると、保守が立ち行かなくなる恐れがあります。

外注では、ブラウザやWeb標準に詳しい専門会社の知見を活用できます。一方で、外部とのコミュニケーションコストが発生する点はデメリットです。特に、開発会社と異なる会社へ依頼すると、コード理解に時間がかかります。

現実的には、内製と外注を組み合わせるハイブリッド体制も選べます。たとえば、中核の改善は内製し、ブラウザ追従は外注する方法があります。また、アクセシビリティチェックなどの定型保守だけを外注することもできます。

ソースコードとドキュメントを整備しておくと属人化を防げ、それが長期的な保守コストを抑える基盤になります。

保守契約で確認すべき項目

契約条件では、対応範囲と追加費用の境界を先に確認しておく必要があります。

  • 対応範囲:現状維持と追加開発の区別
  • 対応時間とSLA:緊急時の一次対応の取り決め
  • 工数上限:月ごとの工数枠の設定
  • 実費負担:インフラやライセンスの負担者
  • 引き渡し:終了時のコードと文書の条件

対応範囲では、バグ修正やブラウザ追従だけを含むかを確認します。新機能の追加や改善を含む場合は、追加開発として扱うかを決めておきます。

多くの保守契約では、機能追加が別見積もりになります。そのため、月額に含まれる作業の線引きを、契約段階で明確にしておきます。

SLA(サービスレベル合意)では、緊急障害の一次対応時間を確認します。さらに、対応可能な時間帯が平日日中か24時間365日かも確かめます。動画配信など、障害がビジネスに直結するサービスでは、特に丁寧に確かめます。

準委任契約では、月◯時間までという工数枠が設けられることがあります。その場合、上限を超えた作業の扱いと料金も、あらかじめ決めておきます。

CDNの従量課金や外部API利用料は金額が変動するため、保守費に含まれるかどうかを事前に確かめる必要があります。

コードと文書の引き渡しは、契約終了後に保守先を変える場合の出発点になります。そのため、契約終了時のソースコードとドキュメントの引き渡し条件も、契約段階で定めておきます。

これらの項目を合わせた総所有コスト(TCO)で比べると、契約ごとの違いが見えやすくなります。

ポイント

社内にフロントエンドの担当者を常時置けるかが、内製と外注の判断の分かれ目です。置けない場合は、ブラウザ追従のような継続作業だけを外注し、中核の改善を社内に残す方法が現実的です。

まとめ

HTML5を含むフロントエンド開発では、保守費用とランニングコストを見積もる必要があり、その費用は人件費、パッケージ更新、インフラ・SaaS費用の3つに分かれます。

月額相場の目安は、小規模が数千円〜5万円、中規模が5万〜20万円、大規模が30万〜100万円以上です。

ブラウザという外部環境への追従は公開中に継続して発生し、ブラウザ互換、Web標準、アクセシビリティへの対応を続ける必要があります。さらに、動画配信のCDN従量課金や、PWAのキャッシュ運用も費用要因になります。

保守体制は、内製、外注、ハイブリッドをサービスの重要度で使い分けます。契約では、対応範囲、SLA、工数上限を明確にし、インフラ費用の負担も確認します。加えて、契約終了時のコードと文書の引き渡し条件も、事前に確かめておきます。

初期開発費だけでなく、3年・5年のライフサイクルでTCOを把握します。信頼できる保守パートナーを選ぶことが、HTML5アプリを長く保つ近道です。

保守プランを検討するなら、複数社へ規模と要件を提示して見積もりを取るところから始めることをお勧めします。

▼全体ガイドの記事
・HTML5開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。