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

Thymeleafのシステム開発は、要件を整理し、発注形態を選び、RFPと契約を固めたうえで、見積を比べながら段階ごとに確認すると進めやすくなります。この順に進めると、後からの手戻りを抑えられます。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

Thymeleafは、JavaのサーバーサイドでHTMLを生成するテンプレートエンジンです。発注の対象は、部品だけでなく業務Webシステム全体になります。

通常は、Spring BootまたはSpring MVCとデータベース、認証・認可、業務ロジックを組み合わせます。さらに、外部API、インフラ、テスト、運用も発注の範囲に入ります。

Thymeleafが担当する範囲

Thymeleafは、Controllerなどから受け取ったデータを画面に表示する層を担当します。

画面表示：th:text、th:if、th:eachを使った一覧・検索・登録の画面
画面遷移：th:href、th:actionによるリンクとフォームの遷移先設定
周辺機能：認証、権限、計算、保存、メール、バックアップを担う別の仕組み

認証やデータ保存などには、Spring Securityやサービス層を使うほか、RepositoryやRDB、クラウドも組み合わせます。

「Thymeleafで開発」とだけ依頼すると、どこまでが委託先の作業かが曖昧になります。そのため、追加費用が生じやすくなります。

2026年のThymeleafと周辺バージョンの確認

Thymeleaf公式Downloadでは、2026年4月21日公開の3.1.5.RELEASEが最新リリースとして案内されています。

新規開発では、JavaやSpringの製品（Spring Boot、Spring Framework、Spring Security）、DBドライバのサポート期間と互換性も確認します。

JSPやThymeleaf 2.x・3.0系から移行する場合は、確認の対象が増えます。式や独自Dialect、セキュリティ連携、ブラウザ表示、自動テストも含まれます。

発注形態の選び方

発注形態は、要件の確定度、社内の技術担当者の有無、完成条件の明確さで選びます。たとえば、試作後に本開発する場合と、仕様を固めて納期・予算を管理する場合では、進め方が異なります。

一括請負が向く案件

一括請負は、合意した成果物を納期と金額の枠内で完成させる形態です。

向く案件：画面一覧、業務フロー、権限表、外部連携、性能条件が決まっている場合
予算管理：テスト合格基準まで決めておくと予算を立てやすい
仕様変更：現場ヒアリングで仕様が動くと、変更管理の手続きが増える

要件定義は準委任で行い、開発以降を請負に切り替える二段階発注も現実的です。

準委任が向くPoCや伴走型開発

準委任は、委託先の専門人材が一定期間、要件定義や設計、実装、レビューを支援する形態です。

要件未確定：新しい業務の完成像が固まっていない場合に使いやすい
伴走開発：発注者のプロダクト責任者と、毎週の優先順位を調整する進め方
月次確認：成果、課題、残工数、翌月計画を扱う会議体（契約時に決める）

支払基準は稼働時間や人月になることが多いため、月次の確認内容は明確にしておきます。

内製・ハイブリッド・丸ごと外注の比較

Java・Springの担当者が社内にいるか、業務知識を蓄積したいかで、内製と外注の分担を決めます。

ハイブリッド型：要件定義と受入テストは内製し、実装やテストは外注する形
一貫委託：担当者の確保が難しい場合に、基幹連携からインフラ、保守まで任せる形
責任分担：意思決定、承認、データ提供、受入判定の担当を先に決めておく

内製が難しい場合でも、発注者側の役割を決めておけば、外注後の手戻りを抑えやすくなります。

ポイント

要件が固まり完成条件を決められるなら一括請負、要件が動くなら準委任が向きます。要件定義だけを準委任で行い、開発以降を請負にする二段階発注もあります。

RFP・要件整理の内容

見積条件をそろえるための整理先が分かれています。

RFPは、複数の開発会社へ同じ前提で提案と見積を依頼する文書です。分厚い仕様書を最初から完成させる必要はありません。

まずは業務の目的、対象範囲、利用者を書きます。そのうえで、期限や制約、期待する成果物も書き加えます。さらに、誰がいつ何のデータを使い、どの状態へ変えるかも記載します。

業務範囲と画面・権限の一覧

対象業務と対象外業務を分けたうえで、業務フローと画面一覧に必要な項目を書き出します。

業務フロー：申請、承認、差戻し、取消、締め処理、例外処理の流れ
画面一覧：画面名、利用者、入力項目、検索条件、出力、遷移先の記載
権限：「管理者」「部門担当」「閲覧者」の役割と、拠点・所属別の参照範囲

特に、Thymeleafで表示を切り替えるだけでなく、サーバー側の認可チェックを必須条件として書いておきます。

RFPに入れる非機能要件と移行条件

見積の差が大きくなりやすいのは、機能よりも非機能要件です。そのため、次のとおり条件を具体化しておきます。

性能・稼働：利用者数、同時接続数、ピーク時間、応答時間、稼働時間
障害・監査：復旧目標、バックアップ世代、ログ保存期間、監査証跡
個人情報：取り扱い方針と保護要件の明記

クラウドを使う場合は、AWSやAzureなどの契約主体を決めます。そのうえで、環境数や監視、デプロイ方法、月額費用の負担も決めておきます。

顧客、商品、取引、ユーザーなどを移す場合は、件数や欠損・重複の扱い、変換ルールを明記します。さらに、リハーサルと旧システムの停止時間も記載します。

成果物と受入基準の定義

納品対象と受入基準をRFPに書いておくと、検収時の認識違いを防げます。

設計・開発物：ソースコード、画面設計書、API仕様、DB定義
運用・管理物：テスト仕様書、操作・運用手順書、インフラ構成、Infrastructure as Code
第三者資産：第三者ライセンス一覧の納品

受入基準には、業務シナリオや権限別の表示・操作を含めます。さらに、エラー時の挙動、性能、セキュリティ、移行結果も入れておきます。

検収日、修正期限、未解決の不具合の扱いまで決めておけば、納品直前の認識違いを減らせます。

ポイント

RFPは、同じ前提で複数社に提案と見積を依頼するための文書です。業務範囲、画面と権限、非機能要件、成果物と受入基準が、比べられる形で書けているかを確認の目安にします。

契約形態と責任分界の設計

契約は、仕様変更や遅延、再委託のルールを決める土台です。知的財産やセキュリティ事故、保守の切替も、契約で取り決めます。

ThymeleafなどのOSSの利用条件と、委託先が新たに作る成果物の権利は、分けて扱います。

請負・準委任・ラボ型の違い

契約形態は、完成責任の範囲、要件の確定度、優先順位を変える必要の有無に合わせます。

請負：成果物と完成責任の範囲
準委任：業務を遂行する体制と稼働条件
ラボ型・継続契約：専任または準専任チームを一定期間確保する形

要件が固まっていないのに請負で発注すると、変更のたびに追加見積が生じます。逆に、要件が明確なのに準委任だけで進めると、総額や完成時期を管理しにくくなります。

要件定義、MVP（Minimum Viable Product）、追加機能、保守の段階で契約を分ける方法もあります。

ソースコード・OSS・知的財産の帰属

委託費を支払っても、ソースコードや設計書の利用権が発注者に自動的に移るとは限りません。

成果物の権利：著作権の帰属か利用許諾か、改変・再利用・第三者提供の可否
OSS情報：Thymeleaf、Spring、Spring Security、DBドライバ、UIライブラリの情報の納品
切替準備：リポジトリ、ビルド手順、CI/CD、環境変数、秘密情報の管理方法の引き渡し

OSSについては、ライセンス一覧やバージョン、改変の有無、脆弱性対応の担当も納品物に含めます。将来ベンダーを切り替えることを想定して、引き渡しの時期も契約で決めておきます。

セキュリティと保守の責任分界

Thymeleafの式やテンプレートに渡す値を無制限に扱うと、入力値の扱い方によってはXSSや式評価の問題につながる可能性があります。

NIST National Vulnerability DatabaseにCVE-2026-40478（2026年）が掲載されており、Thymeleaf 3.1.3.RELEASE以前の版に関係します。

更新・検査：採用版と修正版への更新方針、依存関係のスキャン、脆弱性発見時の連絡期限の取り決め
責任分界：認証・認可、CSRF、セッション、監査ログ、バックアップ、障害復旧の担当の割り振り

Spring公式のセキュリティガイドは、ThymeleafとSpring Securityを組み合わせる構成を示しています。

ポイント

契約形態は要件の確定度に合わせて選び、仕様変更や再委託、知的財産、セキュリティ、保守の責任分界は契約書で取り決めてから発注するのが目安です。

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

規模ごとの概算レンジを並べて見比べられます。

ThymeleafはOSSのため、ライセンス購入費が開発費の中心ではありません。費用の中心は、要件定義から運用設計までの人件費です。

SIA株式会社「システム開発の費用・相場 2026年版」（2026年）では、人月単価はスキルや地域によりおおむね60万〜200万円程度です。

ここで示す金額は公定価格ではなく、Java・Spring系の業務Web開発に、画面数や連携規模を当てはめた概算です。

規模別の費用の幅（300万円〜1億円超）

機能と期間の条件をそろえて、規模ごとの概算を見比べます。いずれも、個別案件の価格を保証するものではありません。

小規模MVP：ログイン、マスタ、一覧・検索・登録、簡易申請で300万〜800万円、2〜4か月
部門システム：権限、承認、CSV、帳票、メール、監査ログ、外部連携1〜2件で800万〜2,500万円、4〜9か月
中〜大規模：複数部門・拠点、既存基幹連携、複雑な計算、データ移行、冗長化、運用監視を含み2,000万〜1億円超、9〜18か月以上

この幅は、公開されている人月単価と一般的な工数から逆算したものです。

見積の工程・工数・前提条件への分解

工程ごとの作業と工数を確認し、同じ条件で出された見積どうしを比べます。

工程：要件定義、画面・方式・DB設計、実装、各テスト、受入支援
導入作業：データ移行、教育、プロジェクト管理が計上されているかの確認
比較条件：画面数、入力項目、状態遷移、権限分岐、API本数、帳票数、データ件数、環境数

たとえば、8人月×60万円なら480万円、15人月×100万円なら1,500万円です。ただし、テストやPMが別計上なら、総額は変わります。

画面単価だけで比べず、同じ条件にそろえて読みます。また、出典の分からない「一式」や、工数がゼロに見える管理費は、作業内容を質問します。

初期費用以外のクラウド・保守・更新費

初期開発費だけでなく、クラウドや保守、更新にかかる継続費用も含めて比べます。

クラウド：計算資源、DB、ストレージ、通信、監視、バックアップ、メール、証明書
保守運用：公開相場では初期開発費の年15〜25%程度が目安
更新：Java・Springの大規模更新や脆弱性対応が含まれるかどうか

保守費は、障害対応時間や問い合わせ件数、改修枠、脆弱性対応、更新作業の範囲によって変わります。

運用費を見積から外さず、3年程度の総保有コストで、パッケージ、クラウド、スクラッチを比べます。

ポイント

費用は初期開発費だけで比べず、同じ条件の見積かどうかを先に確かめます。そのうえで、クラウドや保守などの継続費用も含めて総額を比べます。

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

Thymeleafに対応しているかだけで会社を選ぶと、画面の開発後に業務移行や保守で困ることがあります。そこで、同じRFPを候補会社へ渡し、比べます。

比較軸は、技術と業務理解、体制、見積の透明性、契約条件です。ただし、公開実績は、現在の受注可否や担当者の経験までは保証しません。

Thymeleaf・Spring・DBの実績

対応可能という説明だけでなく、周辺技術と自社に近い業務での経験を確かめます。

技術：Spring Boot・Javaの版、Spring Security、MyBatisまたはJPA、RDB
開発環境：Docker、AWSまたはAzure、CI/CD、自動テスト
業務経験：申請・承認、販売、在庫、請求、予約、公共・医療など

要件定義やデータ移行、障害対応の経験についても質問します。そのうえで、事例の担当範囲や人数、期間、難所、現在の保守体制を確かめます。

担当範囲と開発体制の評価

提案会社の名前だけでなく、実際に参加する人と発注者側の作業も確認します。

担当者：PM、業務担当、テックリード、画面・テスト・インフラ担当
体制条件：発注者の作業、再委託先、海外拠点、交代時の引き継ぎ
管理方法：週次会議、課題、変更承認、コードレビュー、品質指標、連絡先

管理方法まで提案に含めている会社は、開発中のリスクを把握しやすくなります。

同じ前提と除外項目をそろえた比較

見積の工程と対象外の項目を横に並べ、各社の前提をそろえます。

工程・費用：要件定義、UI設計、実装、テスト、移行、教育、保守
外部費用：クラウド、ライセンス、交通費、消費税、追加改修単価
提案姿勢：回答速度、リスク指摘、前提条件の記録の比較

承認分岐、帳票、外部API、データクレンジングの範囲によって、工数は変わります。そのため、金額以外も選定材料に加えます。

ポイント

Thymeleafに対応できるかだけで選ばず、技術、業務理解、体制、見積の透明性、契約条件を同じ基準で比べます。事例の担当範囲と実際に参加する担当者も必ず確かめます。

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

発注者の準備から移行後の運用までが一続きです。

発注後も、発注者は優先順位を決め、成果物をレビューし、受入判定を担います。この流れを、RFPと契約の予定に反映します。

発注前のRFP・候補会社・社内体制の準備

発注前に、社内の責任者と優先順位を決め、提案依頼の予定を組みます。

業務責任者、情報システム担当、現場代表、決裁者の選任。
現行業務とデータの洗い出しと、Must・Should・Couldの優先順位づけ。
RFPを3〜5社へ同じ条件で渡し、質問回答の期限や提案、プレゼン、評価、契約交渉の日程を決める。
現場代表も選定会議に加わり、画面の使いやすさと移行後の業務を評価する。

要件定義から開発・テストまでの段階確認

工程ごとに決める内容と、その確認方法をそろえておきます。

要件定義で業務フロー、画面遷移、権限、データモデル、外部連携、非機能要件を合意する。
設計でテンプレート構成、共通レイアウト、フォーム検証、例外処理、Spring Securityの認可、ログ出力を確認する。
画面モックや動く試作品を早めに触り、現場の言葉と画面の動きを照合する。
テストに権限違反、入力値、二重送信、セッション切れ、外部連携停止、データ欠損も含める。

移行・教育・運用開始も開発の一部

本番移行や利用者教育、保守の引き継ぎまでを、開発計画に含めます。

本番相当データで移行をリハーサルし、件数、金額、関連付け、権限、検索結果を照合する。
利用者向けの操作説明、管理者向けの登録・権限変更手順、障害時の連絡先を用意する。
1部門や1業務で先行稼働し、問い合わせと改善を反映してから段階展開する方法もある。
保守受付時間、障害優先度、目標応答時間、定期更新、改修見積のルールを決める。

引き渡し後も、ベンダー任せで運用が止まらない体制を用意します。

よくある質問

費用や技術の判断は、業務範囲、既存環境、セキュリティ要件によって変わります。

Thymeleafのシステム開発は安くできますか？

ThymeleafはOSSのため、テンプレートエンジンのライセンス費を抑えやすいものの、開発費全体が自動的に安くなるわけではありません。

費用を左右するのは、画面数や権限、ワークフローです。さらに、外部連携やデータ移行、テスト、保守の工数も影響します。

標準化できる業務にSaaSやパッケージを使い、独自性が必要な画面や業務だけを開発すると、総額を抑えられる可能性があります。

既存のJSPシステムをThymeleafへ移行できますか？

移行はできます。テンプレートだけを替えるのか、Spring Boot、Spring Security、DB、インフラも刷新するのかで、期間と費用が変わります。

まず、現行画面とタグライブラリ、認証の仕組みを洗い出します。また、次の項目も確認しておきます。

セッションの扱い
帳票
Java・アプリサーバーの版

代表的な画面で移行を検証し、独自タグや複雑なJavascriptの置き換え方法を確かめたうえで、段階的な計画を立てます。

Thymeleafのセキュリティは発注時に何を確認しますか？

発注時には、認証・認可、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年程度の総費用を、初期費用の安さと並べて見る

業務課題とRFPのたたき台

発注のたたき台には、業務課題と必要な条件を書き出します。

業務と利用者：解決する課題、利用者と権限、必要な画面の書き出し
既存条件：データ、外部連携、希望時期、予算上限の整理
構成比較：たたき台を複数社に示したうえでの、Thymeleaf＋Spring、SaaS、パッケージの比較

技術選定から契約、移行、保守までを一体で検討できる委託先を選ぶと、手戻りを抑えられ、利用され続けるシステムにつながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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