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

Struts2のシステム開発を発注するときは、現行調査、方針比較、RFP・契約、開発・検収の順に進めると、リスクと成果を比べられます。

発注先の探し方から委託先選びまでを、段階ごとに見ていきます。

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

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

Struts2システムの全体像と発注前に押さえる点

Struts2のシステムと呼ばれるものは、多くの場合、Struts2を土台に作られた社内業務システムです。会員サイトや申請・予約・販売管理システムも、その例に含まれます。

フレームワークだけを見ていると、周辺の機能を見落としやすくなります。たとえば、認証や帳票、バッチのほか、データ移行や外部APIも含まれます。

Struts2の位置づけ：製品ではなくJava Webフレームワーク

発注する側が見積もりの前提をそろえるには、フレームワークの特性に加えて、処理の流れや周辺構成も把握しておく必要があります。

• フレームワーク：Apache Strutsは設定より規約を重視するオープンソースのMVCで、プラグインによりREST、AJAX、JSONを拡張できます。
• 処理の流れ：Action、Interceptor、Resultの各要素が処理の流れに関わります。
• 周辺構成：サーバ、フレームワーク、ORM、データベースの組み合わせ。
• 提示する情報：Struts・Java・Tomcatの版、JAR、プラグイン、Action・JSP数、DB、バッチ、連携先。
• 見積もりの前提：利用者数とピーク時アクセス数。設計書がない場合は、コードやサーバ設定も調査対象として示します。

ブラウザのリクエストはActionが受け取り、Interceptorが認証や入力検証などの共通処理を行います。そのうえで業務サービスを呼び出し、JSPまたはJSONをResultとして返します。

周辺にはTomcat、Spring、Spring Security、MyBatis、Hibernateが組み合わされます。さらに、データベースにはOracle・SQL Server・PostgreSQLなどがあります。

発注の選択肢：保守・更新・移行・再構築

Struts2の外注では、最初から全面的な作り直しを前提にせず、選択肢を比べることが大切です。

• 保守・延命：脆弱性の解消と、Javaやサーバの更新。
• バージョン更新：Struts 6系などへの引き上げ。
• 段階移行：画面や業務ロジックを、Spring MVC・Spring Bootなどへ移すこと。
• 再構築：業務要件から見直すこと。

2026年8月時点で、Apache公式にはStruts 6.10.0と7.2.1が掲載されています。一方で、2.5系を含む一覧外のバージョンはEOLで、追加のセキュリティパッチを受けられないと案内されています（出典: Apache Struts公式、2026年）。

ただし、最新番号へ機械的に上げればよいとは限りません。Java、ServletまたはJakarta、JSP、プラグイン、サーバとの互換性を調べ、テストと切り戻しも含めて対応方針を判断します。

Struts2のシステム発注・外注の進め方

発注先を探す前に、まず自社の判断材料をそろえておく必要があります。現行調査から受け入れテストまで順に進めると、価格だけでなくリスクと成果も比べられます。

1. 現行システムの調査と判断材料の収集
2. 保守・更新・移行・再構築の方針の比較
3. 業務目的と技術情報を整理したRFPの作成
4. 複数社への提案依頼と技術ヒアリング
5. 契約後の設計・開発と受け入れテスト

発注形態の選び方

調査・保守・開発のどの形態で発注するかは、社内の知見と要件の確定度に合わせて選びます。

• 構成が不明：有識者が少なく現行構成も不明なら、調査・脆弱性診断・移行計画を先行発注します。
• 既存ベンダーを継続：コードと運用を把握していれば保守を続け、別会社から移行方針の意見を得る方法もあります。
• 要件・範囲が確定：成果物を決められる要件定義や開発は、請負にできます。
• 依存関係が不明：調査・要件整理は準委任にし、確定した改修や移行単位を請負にする方法が現実的です。

RFPに書く技術情報と業務上の目的

RFPには「古いので新しくしたい」という要望だけでなく、守るものと変えるものを示す必要があります。

• 業務目的：月末の請求処理を止めない、申請履歴を引き継ぐなど。
• 技術情報：Struts、Java、Tomcat、DB、JSP、Action、Interceptor。
• 周辺機能：プラグイン、外部連携、バッチ、帳票、設計書の有無。

会計システムとの連携や、権限を洗い出しやすくする目的も記載します。不明な項目は未確定として扱い、調査して見積もる範囲を明記します。

公開環境、個人情報や決済情報、利用者数、稼働時間、許容停止時間も共有しておきます。希望時期、予算上限、納品後の保守体制も早めに伝えます。前提と除外条件を先に示しておくと、契約後の追加費用を抑えられます。

技術調査の結果と対応方針の確定

現状調査では、設定やプログラムに加えて、データと運用の構成も確認します。

• コードと設定：pom.xmlやGradle、WAR、JAR、struts.xml、Action、Interceptor、JSP、OGNL。
• 業務・データ：認証・認可、DBスキーマ、バッチ、外部API、帳票。
• 運用：ログ、バックアップ、運用手順、独自タグ、手作業。

画面数だけでなく、1画面から呼ばれるActionや複数の連携、独自タグ、手作業の運用も工数に影響します。

調査の成果物として、構成図、依存ライブラリ、脆弱性の影響、難易度を受け取ります。移行候補と未確定事項も、調査結果に含めてもらいます。

脆弱性は、Apacheの情報とIPAのApache Struts 2対策情報一覧を照合して確認します。IPAは、修正パッチの適用と更新、事前の動作確認を案内しています。組み込みライブラリの一覧管理も案内されています（出典: IPA、2026年1月13日更新）。

診断で終わらせず、修正、回帰テスト、リリース、監視を発注範囲に含めるかを決めます。

Struts2の外注で選ぶ契約形態

契約形態は、作業の確定度と、成果物・品質・責任範囲の合意状況で選びます。調査前は依存関係や仕様が見えないため、一括請負が安全とは限りません。

契約書には、対象システム、成果物、検収条件、変更管理、再委託を記載します。そのうえで、知的財産、脆弱性対応、障害時の連絡方法も具体的に決めておきます。

準委任契約の向いている作業：調査と伴走型の保守

準委任契約は、一定期間の作業や専門人材の稼働を依頼する形です。コード解析、脆弱性調査、移行方式の比較、技術検討、リリース支援に適しており、作業を進めてみないと成果の形や工数が確定しにくい業務に向いています。

月単位または人月単位で管理しやすい一方で、請負のような完成責任は負いません。

作業報告、レビュー、調査結果、次月の計画は、提出物として定めておきます。担当人数だけでなく、誰がどの成果を担当するかも決めておきます。

• リーダー：構成図とリスク一覧の作成。
• Java担当：依存ライブラリの調査。
• 業務担当者：画面と帳票の確認。

役割を決めておくと、作業時間だけが積み上がる状態を避けられます。

請負契約：範囲と検収条件が固まった開発

請負契約は、合意した成果物を完成させ、検収を受ける契約です。

• 向いている作業：特定画面の改修、仕様に基づく回帰テスト、決定済みのデータ移行。
• 更新作業：合意済みのJava・サーバ更新など、範囲と完了条件を示せる作業。
• 要件が曖昧な場合：想定外のActionや連携により、追加費用や納期変更が生じることがあります。
• 検収項目：業務シナリオ、権限、異常系、性能、ログ、バックアップ、脆弱性対応、切り戻し。
• 受け入れ条件：テストデータ、判定基準、未解決課題の扱い。

調査・開発・保守を分けて進める際のリスク管理

全面移行の見積もりを一度に固定するより、工程を分けて進めるほうが、停止リスクと追加要求を管理しやすくなります。

1. 現状調査と移行計画の作成（第1段階）
2. 優先度の高い改修や更新（第2段階）
3. 残りの移行と運用改善（第3段階）
4. 第1段階の成果を使った、次段階の対象画面、工数、納期、リスクの更新
5. 会社間の引き継ぎでは、設計書、ソース、設定、テストデータ、課題、意思決定記録を渡します。
6. 切り替え時は引き継ぎ期間、回答期限、環境アクセス、秘密情報の扱いを契約で定めます。

Struts2のシステム発注費用の相場

Struts2だけを対象にした公的な平均価格は確認できません。費用は、画面・Action数、外部連携、データ移行、設計書やテスト資産の有無で変わります。求める停止時間も費用を左右します。

2026年版のSIA解説では、人月単価はスキルや地域によって60万〜200万円程度とされています（出典: SIA「システム開発の費用・相場 2026年版」）。ただし、以下の金額は単価レンジと作業量による推定で、Struts2案件の統計的な平均ではありません。

現状調査・脆弱性診断の費用目安（60万〜600万円程度）

調査規模は、システム構成や確認範囲によって変わります。

• 小規模：構成と依存ライブラリだけなら、数人週で終わる場合があります。
• 大規模：複数環境、数百のJSP・Action、設計書の欠落があると調査が増えます。
• 追加確認：外部連携や運用担当者へのヒアリングも工数に影響します。

リサーチノートの推定では、調査・診断・移行計画は60万〜600万円程度です。期間は2〜6週間が目安です。

• 影響範囲：影響を受けるJARと公開範囲の確認。
• 修正とテスト：修正方法と回帰テスト対象の決定。
• リリース：実施可能な時間帯と代替案の調査。

本開発だけを先に見積もると、独自Interceptorや帳票仕様が後から分かり、予算や納期が膨らむおそれがあります。

パッチ適用・小規模改修の費用目安（120万〜1,000万円程度）

費用は120万〜1,000万円程度、期間は1〜3か月が目安です。その幅は、パッチ適用だけで済むか、互換性のないライブラリや独自プラグインも直すかで変わります。

• 作業範囲：脆弱性修正、Java・サーバ更新、設定変更、主要画面の回帰テスト。
• 見積項目：対象版、変更JAR、修正画面、テストケースを分けて示す。
• 付帯作業：環境構築とリリース支援の有無の明記。

Apache公式はCVE-2025-68493に対し、少なくともStruts 6.1.1への更新を案内しています。CVE-2025-64775では、Struts 6.8.0または7.1.1への更新が緩和策です（出典: Apache Struts公式セキュリティ情報、2026年確認）。

対象環境への影響と更新後の業務動作は個別に確認します。脆弱性番号だけで費用を断定せず、依存関係とテスト量から見積もります。

Spring移行と全体再構築の費用目安：Spring移行は600万〜6,000万円、全体再構築は1,000万円以上

リサーチノートの推定では、費用は600万〜6,000万円程度、期間は6〜18か月です。業務単位で進めれば、範囲を抑えられます。ただし、複数部署と外部連携を一度に切り替える場合は、費用が上振れしやすくなります。

全体再構築は、要件定義から移行、教育、運用設計まで含めると1,000万〜5,000万円以上です。期間は8〜24か月以上が目安です。

• Spring移行：画面・Controllerに加えて、認証・認可、業務ロジック、検証、セッション、帳票、API、テスト、運用までを移す範囲。
• 全体再構築：要件定義、データ移行、教育、運用設計までが対象。

人月単価による試算では、10人月は600万〜2,000万円、20人月は1,200万〜4,000万円になります。工数は仮定値なので、移行対象と新規機能を分けて根拠を確認します。

保守・運用費：初期費用とは分けた確認

一般的な業務システムの保守・運用は、初期開発費の年15〜25％、または月15万〜80万円程度が目安です。ただし、Struts2固有の平均価格ではありません。

脆弱性監視、24時間監視、第三者診断、緊急リリースを含む場合は、費用が上振れします。

• 保守対象：脆弱性確認、パッチ、OS・Java・ミドルウェア更新、障害調査。
• 運用作業：バックアップ、ログ監視、問い合わせ対応。
• 月額条件：問い合わせ時間、障害優先度、対応開始時間、修正上限、定例報告、休日対応。
• 追加費用：「軽微な改修」の定義と、画面・帳票変更が保守外となる条件。
• 別作業の単価：通常保守、緊急対応、機能追加、環境更改と承認手順。

RFPと要件整理で決める事項

RFPは、受託会社に同じ条件で提案してもらうための資料です。そのため、現行の事実、業務目的、守る制約、提案を求める範囲を分けて記載します。

情報がそろうと、調査を含まない提案と、移行・テスト・保守まで含む提案を比べられます。

現行資産の整理：画面・コード・データ・運用

現行資産を洗い出すときは、画面、コード、データ、運用の情報をそろえます。

• 画面：部署、頻度、権限、入出力、帳票、エラー、業務上の重要度。
• コード：Action、Interceptor、Result、JSP、独自タグ、設定、JAR、テスト。
• データ：テーブル、件数、保持期間、個人情報、マスタ、移行先、照合方法。
• 運用：ジョブ、バックアップ、監視、障害連絡、手作業、リリース、環境差分。

設計書がなければ、コード解析に加えて業務担当者へヒアリングします。調査では、未使用画面、担当者だけが知る締め処理、表に出ないCSV連携が見つかる場合があります。

不明点をすべて無くすより、調査で解決する項目と発注者が決める項目を分けて整理します。

機能要件と非機能要件の記載

RFPでは機能要件と非機能要件を分けて書きます。更新によって挙動が変わる可能性も、あわせて考慮します。

• 機能要件：申請、承認、検索、登録、集計、帳票、通知、API、バッチ、データ移行。
• 稼働要件：稼働・停止可能時間、応答、同時利用者数、バックアップ、復旧目標。
• 管理要件：監視、ログ、認証、権限、暗号化、診断、監査。
• 構成の選択：Java、ServletまたはJakarta、コンテナ化、クラウド・オンプレミス、DB、認証基盤。
• 方式比較：Struts2の継続も含め、サポート、担当者確保、脆弱性、機能追加、移行難度を同じ表で比べること。

RFPに含めるセキュリティと受け入れ条件

Apache公式によると、Struts2自体は認証や認可を提供する製品ではありません（出典: Apache Struts公式セキュリティガイド）。

• 脆弱性対応：監視担当、緊急パッチの評価期限、診断者、公開前承認者、事故連絡経路。
• セキュリティ要件：認証・認可、CSRF、入力検証、秘密情報、監査ログ、個人情報、再委託先。
• アクセス確認：正常系に加え、権限のない操作を防げること。
• データと異常系：想定外入力で情報が漏れず、旧新システムの残高・申請状態が一致すること。
• 切り戻し：障害時に戻せる条件の決定。

発注者側の業務責任者が判定できる形式にすると、納品後のトラブルを減らせます。

Struts2の委託先と見積書の比較観点

委託先を選ぶときは、Struts2と書かれているかを見るだけでなく、依頼内容ごとに必要な経験を確かめます。保守、Struts 6系への更新、Spring移行、クラウド・DB更改では、必要な経験が異なります。

同じRFPを候補会社へ渡し、提案、調査方法、体制、成果物、費用、契約を比べます。

保守型か移行型かの見極め：実績の中身

依頼内容に応じて、委託先に確認する実績を分けます。

• 保守：現行版解析、障害再現、緊急パッチ、サーバ・DBの切り分け。
• 移行：Struts1・Struts2からSpring MVC・Spring Bootへの移行、画面と業務ロジックの対応、データ移行、並行稼働。
• テスト：回帰テストや不足時の補完、変換後の手修正と業務テスト。

公式サイトに実績があっても、現在の担当者が対応できるとは限りません。そのため、担当予定者の経験と稼働時期を聞いておきます。

事例では、規模、画面数、利用者数、移行先、担当範囲、期間を確認します。あわせて、保守の有無と、どの課題をどう解決したかを聞くと、自社との類似性を判断しやすくなります。

委託先への質問：担当者・調査方法・保守体制

技術ヒアリングでは、調査・移行・障害対応の進め方を具体的に尋ねます。

• 構成調査：Struts・Java・Tomcatの版、依存JARの脆弱性をどう特定しますか。
• 仕様と方針：設計書のない画面の復元方法と、Spring移行・Struts更新の判断基準は何ですか。
• テスト：回帰テストの範囲と、不足分の補い方はどうしますか。
• 障害対応：本番障害時に誰が何時まで一次対応しますか。
• 体制・支援：担当者の氏名・経験、再委託、コード等の保管・環境アクセス、脆弱性対応期限、保守窓口。

発注者側で用意する業務担当者とテスト環境も、あらかじめ明確にしておきます。提案段階で曖昧な回答があれば、契約前の確認事項として残します。

見積書の比較：総額ではなく前提・工数・除外範囲

複数社の見積もりでは、作業項目をそろえて比較します。

• 工程：要件定義、調査、設計、実装、データ移行。
• 確認作業：テスト、脆弱性診断、リリース、教育。
• 運用：保守、発注者作業、追加費用の条件。

見積書に「開発一式」とある場合は、画面、Action、帳票、連携、テストケース数を確認します。さらに、想定人月、単価、期間、体制、前提条件も尋ねます。

安価な提案では、調査を含まず、データ移行や受け入れを発注者側に置く場合があります。保守が別料金になっている可能性もあります。

高額な提案では、移行リハーサル、並行稼働、性能試験、教育、障害対応が含まれる場合があります。総額だけで比べず、納品物、リスク、発注者の作業、追加費用の条件も比べます。

発注後の進行とStruts2システムの失敗防止

発注後は、発注者側で業務判断を止めない仕組みを作ります。そのため、週次の課題管理、月次の品質確認、変更承認、環境別のリリース記録を決めておきます。経営層への報告方法も定めます。

調査中に想定外の仕様が見つかるため、早期に小さな成果物を確認します。

最初の数週間の構成図とリスク一覧のレビュー

調査初期に成果物を確認し、開発前に前提違いを見つけます。

• 調査資料：構成図、依存ライブラリ、画面・Action、外部連携の一覧。
• リスク情報：脆弱性の影響と未確定事項。業務担当者は未使用機能や例外業務を確認します。
• 小規模検証：移行では代表画面や業務を選び、認証、入力検証、例外処理を確かめます。
• 業務シナリオ：帳票、性能、権限まで確認し、自動変換率だけでは成否を判断しないこと。

前提違いが見つかった場合は、開発着手前に範囲や予算を見直せます。

業務継続を中心にしたテストとリリースの設計

業務継続を確認できるテストと、切り戻しを含むリリース手順を設計します。

1. 単体、結合、システム、性能、セキュリティ、受け入れの各テストを行います。
2. URL、画面遷移、セッション、入力、権限、エラー表示、CSV・帳票、外部APIを確認します。
3. 旧新システムを同じデータで動かして照合し、目視で見つけにくい差を探します。
4. リリース前にバックアップ、切り戻し条件、連絡先、作業手順、監視、判断者を確認します。
5. 停止が難しい場合は段階リリース、並行稼働、時間帯別移行、機能単位の切り替えを検討します。

安定稼働期間と、無償修正と追加契約の境界は、検収前に決めておきます。

発注者側に残す成果物と知識：ブラックボックス化の防止

成果物と管理方法を決めておくと、情報が特定の担当者だけに集中するのを防げます。

• 保管する成果物：コード、設定、構成図、データ定義、テスト仕様、運用手順。
• 履歴と更新：脆弱性対応、障害原因・対策、納品形式、更新頻度。
• アクセス管理：リポジトリ権限、バックアップ、引き継ぎ方法。
• 機密情報：再委託先、アクセス範囲、ログ保管、事故報告期限、監査。
• 契約終了：情報の返却・削除と、担当者・情報管理・事故対応の確認。

情報が特定の担当者に偏ると、再発注や緊急対応の選択肢が狭くなります。

よくある質問（FAQ）

発注の相談では、継続利用、移行、予算についての質問が多く寄せられます。特に確認されやすい質問について、判断の順番が分かるように回答します。

Struts2のシステムはそのまま使い続けても問題ありませんか？

継続利用の可否は、システムの安全性と運用条件を確認して判断します。

• 確認項目：バージョン、依存ライブラリ、公開範囲、脆弱性、保守体制。
• 継続できる条件：安全に更新・運用できるなら、短期利用も選択肢です。
• EOL版：公式パッチを受けられないため、調査と移行計画を先延ばしにしません。
• 最終判断：停止リスク、開発者確保、予算、期間を合わせて検討します。

Struts2のシステム発注費用は最初にいくら用意すべきですか？

全体費用を最初から断定せず、まず調査・診断・移行計画を予算化します。

• 初期調査：60万〜600万円程度が目安ですが、構成規模と調査範囲による推定です。
• 次の見積もり：パッチ・小規模改修、版更新、Spring移行、再構築を分けます。
• 別途確認：保守費用とデータ移行費用も個別に確認します。

Struts2に対応できる委託先はどのように探せますか？

対応領域の実績と、実際に担当する人の説明内容を確かめます。

• 実績分野：Struts2対応、レガシーJava・Spring Boot移行、Java業務システム保守。
• 提案比較：候補会社へ同じRFPを渡します。
• 担当者の技術：コード解析、脆弱性対応、移行、テストを説明できるか確認します。
• 契約前確認：経験、再委託、SLA、成果物、ソース引き渡しを確認します。

Struts2のシステムをクラウドへ移行すれば安全になりますか？

クラウド移行だけでは脆弱性や古いライブラリは解消されず、個別の対策が必要です。

• 実行環境：Java、サーバ、JARを設計します。
• セキュリティ：認証、秘密情報、WAFを設計します。
• 運用継続：ログ、バックアップ、監視、切り戻しを決めます。
• 同時更新：変更点が増えるため、段階移行や検証環境でのリハーサルを計画します。

まとめ

発注前の現行資産と対応方針の整理

Struts、Java、依存ライブラリのほか、画面、Action、JSP、DB、連携、運用を洗い出します。保守・更新・移行・再構築を比べ、不足があれば調査と計画を先に外注します。

発注後の成果物・テスト・保守体制の確認

発注後の体制まで決めておくと、進行と引き継ぎの判断材料が残ります。

• 発注前の整理：現行資産を洗い出し、停止リスクと予算に合う方針を選びます。
• 方式と契約：保守・パッチ、Struts 6系更新、Spring段階移行、再構築を比べ、準委任と請負を使い分けます。
• RFPと見積もり：業務目的、非機能、セキュリティ、テスト、運用、再委託、引き継ぎを示し、工数・単価・前提・除外範囲を比較します。
• 委託先選び：不明点をまとめて複数社へ同条件で調査を依頼し、保守型と移行型を担当者の経験で評価します。
• 成果と知識の保管：構成図やリスクを早期確認し、ソースコードと運用知識を発注者側にも残します。

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

▼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を創業。