Thymeleafのシステム開発の発注/外注/依頼/委託方法について

Thymeleafのシステムを発注・外注するなら、Thymeleafの採用だけでなく、業務要件、Springの構成、認証・権限、データ連携、運用保守までを一つの開発範囲として定義することが重要です。

この記事では、Thymeleafを使った業務Webシステムの発注形態の選び方、RFPと要件整理の進め方、契約形態、2026年時点の費用相場、委託先の選定と見積比較のポイントを、発注者の実務に沿って解説します。

▼全体ガイドの記事
・Thymeleafのシステム開発の完全ガイド

Thymeleafのシステムを発注・外注する前に知る全体像

Thymeleafは、JavaのサーバーサイドでHTMLを生成するテンプレートエンジンです。したがって、発注する対象はThymeleafだけの部品ではなく、通常はSpring BootまたはSpring MVC、データベース、認証・認可、業務ロジック、外部API、インフラ、テスト、運用を組み合わせた業務Webシステムになります。

Thymeleafが主に担当するのは、Controllerなどから受け取ったデータを画面へ表示する層です。th:text、th:if、th:each、th:href、th:actionなどを使って、一覧・検索・登録・確認・エラー画面を作れます。一方で、ログイン認証、権限判定、受注金額の計算、在庫引当、データ保存、メール送信、バックアップは、Spring Security、サービス層、Repository、RDB、クラウドなど別の仕組みで設計します。見積依頼書に「Thymeleafで開発」とだけ書くと、これらの責任範囲が曖昧になり、後から追加費用が発生しやすくなります。

Thymeleaf公式Download（2026年）では、2026年4月21日公開の3.1.5.RELEASEが最新リリースとして案内されています。新規開発では、Thymeleafの版だけでなく、Java、Spring Boot、Spring Framework、Spring Security、DBドライバのサポート期間と互換性をまとめて確認します。既存のJSPやThymeleaf 2.x・3.0系から移行する場合は、式の書き方、独自Dialect、セキュリティ連携、ブラウザ表示、自動テストを移行対象に含める必要があります。

発注形態はどう選びますか？

発注形態は、要件の確定度、発注者側の技術担当者の有無、完成条件の明確さで選びます。小さく試してから本開発へ進みたい場合と、仕様を固めて納期・予算を管理したい場合では、適した契約と委託の進め方が異なります。

一括請負は、合意した成果物を納期と金額の枠内で完成させる形態です。画面一覧、業務フロー、権限表、外部連携、性能条件、テスト合格基準が決まっている場合は、発注者が予算を立てやすくなります。反対に、現場ヒアリングをしながら仕様が変わる案件では、変更管理の手続きが増えます。要件定義だけを準委任で行い、開発以降を請負に切り替える二段階発注も現実的です。

準委任は、委託先の専門人材が一定期間、要件定義、設計、実装、レビューなどの業務を支援する形態です。新しい業務のため完成像が固まっていない場合や、発注者側のプロダクト責任者と委託先が毎週優先順位を調整する場合に使いやすいです。支払基準は稼働時間や人月になることが多いため、月次の成果、課題、残工数、次月の計画を確認する会議体を契約時に決めます。

発注者にJava・Springの担当者がいて、業務知識も社内に蓄積したい場合は、要件定義と受入テストを内製し、実装やテストを外注するハイブリッド型が候補になります。逆に、担当者の確保が難しく、基幹連携やインフラまで一貫して任せたい場合は、上流から保守まで対応する会社へ委託します。内製できないから丸投げするのではなく、意思決定、承認、データ提供、受入判定を誰が担うかを先に定義すると、外注後の手戻りを抑えられます。

RFP・要件整理では何を決めますか？

RFPは、複数の開発会社へ同じ前提で提案と見積を依頼する文書です。分厚い仕様書を最初から完成させる必要はありませんが、業務の目的、対象範囲、利用者、期限、制約、期待する成果物をそろえる必要があります。機能名だけでなく、誰が、いつ、どのデータを使い、どの状態へ変えるのかを書きます。

まず、対象業務と対象外の業務を分けます。申請、承認、差戻し、取消、締め処理、例外処理を業務フローに並べ、画面一覧には画面名、利用者、入力項目、検索条件、出力、遷移先を記載します。権限は「管理者」「部門担当」「閲覧者」のような役割だけでなく、拠点や所属によるデータ参照範囲も決めます。Thymeleafの表示切り替えだけで権限を実現せず、サーバー側の認可チェックを必須条件にします。

見積差が大きくなりやすいのは、機能より非機能要件です。想定利用者数、同時接続数、ピーク時間、画面応答時間、稼働時間、障害時の復旧目標、バックアップ世代、ログ保存期間、監査証跡、個人情報の取扱いを記載します。クラウドを使う場合は、AWSやAzureなどの契約主体、環境数、監視、デプロイ方法、月額費用の負担も決めます。既存システムから顧客、商品、取引、ユーザーを移す場合は、データ件数、欠損や重複の扱い、変換ルール、移行リハーサル、旧システムの停止時間を明記します。

RFPには、ソースコード、画面設計書、API仕様、DB定義、テスト仕様書、操作マニュアル、運用手順書、インフラ構成、Infrastructure as Code、第三者ライセンス一覧を納品対象として記載します。受入基準は「動くこと」ではなく、代表的な業務シナリオ、権限ごとの表示と操作、エラー時の挙動、性能、セキュリティ、移行結果を確認できる形にします。検収日、修正期限、未解決の不具合の扱いまで決めると、納品直前の認識違いを減らせます。

契約形態と責任分界はどう設計しますか？

契約は、支払い方法だけでなく、仕様変更、遅延、再委託、知的財産、セキュリティ事故、保守切替のルールを決める土台です。Thymeleafのようなオープンソースを採用する場合も、OSSの利用条件と、委託先が新たに作成した成果物の権利を分けて扱います。

請負では成果物と完成責任の範囲を定め、準委任では業務を遂行する体制と稼働条件を定めます。ラボ型や継続契約では、専任または準専任チームを一定期間確保し、優先順位を変えながら開発できます。要件が未確定なのに請負で固定すると、変更のたびに追加見積が発生します。逆に、要件が明確なのに準委任だけで進めると、総額や完成時期を管理しにくくなります。要件定義、MVP、追加機能、保守で契約を分ける方法も検討します。

委託費を支払っただけで、ソースコードや設計書の利用権が発注者へ自動的に移るとは限りません。契約書で、成果物の著作権の帰属または利用許諾の範囲、改変・再利用・第三者提供の可否、納品時期を定めます。Thymeleaf、Spring、Spring Security、DBドライバ、UIライブラリなどのOSSは、ライセンス一覧、バージョン、改変の有無、脆弱性対応の担当を納品物に含めます。将来のベンダー切替を想定するなら、リポジトリ、ビルド手順、CI/CD、環境変数、秘密情報の管理方法も引き渡し条件にします。

Thymeleafの式やテンプレートへ渡す値を無制限に扱うと、入力値の扱いを誤った場合にXSSや式評価の問題につながる可能性があります。NIST National Vulnerability DatabaseのCVE-2026-40478（2026年）では、Thymeleaf 3.1.3.RELEASE以前に関係する情報が掲載されているため、採用バージョン、修正版への更新方針、依存関係のスキャン、脆弱性発見時の連絡期限を契約に入れます。Spring公式のセキュリティガイドでも、ThymeleafとSpring Securityを組み合わせてWebアプリケーションを保護する構成が示されています。認証・認可、CSRF、セッション、監査ログ、バックアップ、障害復旧を、委託先と発注者のどちらが担当するか明確にします。

Thymeleafのシステムの費用相場と見積の読み方

Thymeleaf自体はオープンソースのため、ライセンス購入費が開発費の中心になるわけではありません。費用の中心は、要件定義から設計・実装・テスト・移行・運用設計までの人件費です。SIA株式会社「システム開発の費用・相場 2026年版」（2026年）の公開相場では、システム開発の人月単価はスキルや地域でおおむね60万〜200万円程度とされています。以下はThymeleaf固有の公定価格ではなく、Java・Spring系の業務Web開発に画面数や連携規模を当てはめた概算です。

ログイン、マスタ、一覧・検索・登録、簡易申請に絞った小規模MVPは、概算で300万〜800万円、期間は2〜4か月が一つの目安です。権限、承認ワークフロー、CSV、帳票、メール、監査ログ、1〜2件の外部連携を含む標準的な部門システムは、800万〜2,500万円、4〜9か月程度を見込みます。複数部門・拠点、既存基幹連携、複雑な計算、データ移行、冗長化、運用監視まで含む中〜大規模案件は、2,000万〜1億円超、9〜18か月以上になる可能性があります。これは公開されている人月単価と一般的な工数から逆算したレンジであり、特定案件の価格を保証するものではありません。

見積書では、要件定義、画面設計、方式設計、DB設計、実装、単体テスト、結合テスト、総合テスト、受入支援、データ移行、教育、プロジェクト管理を分けて確認します。例えば8人月×60万円で480万円、15人月×100万円で1,500万円という計算でも、テストやPMが別計上なら総額は変わります。画面1枚の単価だけで比較せず、画面数、入力項目、状態遷移、権限分岐、API本数、帳票数、データ件数、環境数が同じ前提かをそろえます。出典を確認できない「一式」や、工数ゼロに見える管理費は、作業内容を質問します。

初期開発費のほかに、クラウドのコンピューティング、DB、ストレージ、通信、監視、バックアップ、メール配信、証明書などの月額費用が発生します。保守運用は、公開相場でよく使われる初期開発費の年15〜25%程度という目安を起点にできますが、障害対応の時間帯、問い合わせ件数、改修枠、脆弱性対応、JavaやSpringのメジャーアップデートを含むかで変わります。運用開始後に必要な費用を見積書から除外せず、3年程度の総保有コストでパッケージ、クラウド、スクラッチを比較します。

委託先選定と見積比較のポイント

Thymeleafの対応可否だけで会社を選ぶと、画面開発はできても業務移行や保守で困ることがあります。候補会社には同じRFPを渡し、技術、業務理解、体制、見積の透明性、契約条件を同じ軸で比較します。公開実績は参考になりますが、現在の受注可否や担当者の経験まで保証するものではないため、提案時に具体的な確認を行います。

「Thymeleafに対応できます」という一文だけでなく、Spring Bootの版、Javaの版、Spring Security、MyBatisまたはJPA、利用するRDB、Docker、AWSやAzure、CI/CD、自動テストの経験を確認します。さらに、画面開発以外の業務実績を質問します。例えば、申請・承認、販売、在庫、請求、予約、公共・医療など、自社と近い業務での要件定義、データ移行、障害対応の経験があるかを確認します。候補会社が提示する事例では、担当範囲、人数、期間、難しかった点、現在の保守体制まで聞くと、実績の中身を見極めやすくなります。

提案書の会社名だけでなく、実際に参加するプロジェクトマネージャー、業務担当、テックリード、画面担当、テスト担当、インフラ担当を確認します。要件定義と受入テストで発注者が行う作業、委託先の再委託先、海外拠点の利用、担当者交代時の引き継ぎ方法も比較対象です。週次の進捗会議、課題管理、仕様変更の承認、ソースコードレビュー、品質指標、エスカレーション先が提案に含まれている会社は、開発中のリスクを管理しやすいです。

見積比較では、最安の会社を選ぶ前に、見積に含まれる工程と含まれない工程を一覧にします。要件定義、UI設計、実装、テスト、移行、教育、保守、クラウド費用、ライセンス、交通費、消費税、追加改修の単価を横並びにします。画面数が同じでも、承認分岐や帳票、外部API、データクレンジングを含むかで工数は変わります。質問への回答が速いか、リスクを正直に指摘するか、前提条件を文章で残すかも、金額と同じくらい重要な選定材料です。

発注からリリースまでの進め方

発注先が決まった後も、発注者の判断が不要になるわけではありません。業務の優先順位を決め、成果物をレビューし、受入判定を行う責任は発注者に残ります。次の流れをRFPと契約のスケジュールへ落とし込みます。

最初に、業務責任者、情報システム担当、現場代表、決裁者を決めます。次に現行業務とデータを棚卸しし、Must・Should・Couldの優先順位を付けます。RFPを3〜5社へ同じ条件で渡し、質問回答の期限、提案期限、プレゼンテーション、評価、契約交渉の予定を設定します。技術だけでなく、現場が使える画面か、移行後の業務が成立するかを評価するため、現場代表を選定会議に参加させます。

要件定義では、業務フロー、画面遷移、権限、データモデル、外部連携、非機能要件を合意します。設計では、Thymeleafのテンプレート構成、共通レイアウト、フォームバリデーション、例外処理、Spring Securityの認可、ログ出力を確認します。開発中は、画面モックや動くプロトタイプを早めに触り、現場の言葉と画面の挙動が一致しているかを確認します。テストでは、正常系だけでなく権限違反、入力値、二重送信、セッション切れ、外部連携停止、データ欠損もシナリオに含めます。

リリース前には、本番相当のデータで移行リハーサルを行い、件数、金額、関連付け、権限、検索結果を照合します。利用者向けの操作説明、管理者向けのユーザー登録や権限変更の手順、障害時の連絡先を用意します。初回リリースを一斉展開せず、1部門や1業務で先行稼働し、問い合わせと改善点を反映してから段階展開する方法も有効です。引き渡し後は、保守の受付時間、障害の優先度、目標応答時間、定期更新、改修の見積ルールを確認し、ベンダー任せで運用が止まらない体制を作ります。

よくある質問

Thymeleafのシステムを発注する際に、担当者からよく寄せられる質問へ回答します。費用や技術の判断は、個別の業務範囲、既存環境、セキュリティ要件によって変わるため、ここでは判断の軸を示します。

Thymeleafはオープンソースのため、テンプレートエンジンのライセンス費用を抑えやすいですが、開発費全体が自動的に安くなるわけではありません。画面数、権限、ワークフロー、外部連携、データ移行、テスト、保守の工数が費用を左右します。標準化できる業務はSaaSやパッケージを使い、独自性が必要な画面や業務だけをThymeleafで開発すると、総額を抑えられる可能性があります。

移行できますが、画面テンプレートだけを置き換えるのか、Spring BootやSpring Security、DB、インフラまで刷新するのかで期間と費用が変わります。まず現行画面、タグライブラリ、セッション、認証、帳票、Java・アプリサーバーのバージョンを棚卸しします。代表画面で移行検証を行い、独自タグや複雑なJavascriptの置き換え方法を確認してから、段階的な移行計画を作ると安全です。

サーバー側の認証・認可、CSRF対策、XSS対策、入力値検証、セッション管理、秘密情報の管理、監査ログ、依存ライブラリの脆弱性スキャンを確認します。画面上でボタンを隠すだけでは認可にならないため、APIやControllerでも権限を検証する設計にします。採用バージョンの更新方針と、脆弱性が公表されたときの修正期限、保守契約の範囲をRFPと契約へ記載します。

Thymeleafのキーワードだけでなく、Java・Springの業務システム実績、認証・権限、DB、クラウド、データ移行、保守の実績を確認します。候補を3〜5社に絞り、同じRFPで提案と見積を依頼し、実際の担当者との打ち合わせを行います。提案書に書かれた実績の担当範囲、再委託の有無、成果物の権利、ソースコードの引き渡し、保守終了時の移管条件まで確認して選定します。

まとめ

Thymeleafのシステムを発注・外注するときは、テンプレートエンジンの採用判断だけでなく、業務システム全体の要件と責任範囲を決めることが出発点です。発注形態は、要件の確定度と社内体制に合わせて請負、準委任、ハイブリッドを選び、RFPでは画面、権限、連携、移行、非機能、成果物をそろえます。

2026年の概算レンジは、小規模MVPで300万〜800万円、標準的な部門システムで800万〜2,500万円、中〜大規模で2,000万〜1億円超ですが、Thymeleafだけで決まる価格ではありません。人月、画面数、権限分岐、外部連携、データ移行、テスト、クラウド、保守の前提をそろえて比較します。見積の安さだけでなく、後から増額しやすい除外項目と、更新・脆弱性対応を含む3年程度の総費用を確認します。

まずは、解決したい業務課題、利用者と権限、必要な画面、既存データ、外部連携、希望時期、予算の上限を書き出します。そのたたき台をもとに複数社へ相談し、Thymeleaf＋Springの構成が本当に適切か、SaaSやパッケージとの組み合わせが適切かを比較します。技術選定、契約、移行、保守を一体で検討できる委託先を選ぶことが、発注後の手戻りを抑え、利用され続けるシステムにつながります。

▼全体ガイドの記事
・Thymeleafのシステム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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