Struts2のシステム開発の完全ガイド - ブログ

Struts2のシステム開発は、構成、脆弱性、業務の変更頻度を押さえ、保守継続・更新・段階移行・再構築から選ぶ流れです。基本構造から費用、開発会社の選び方まで、各テーマの詳細は下の関連記事で確認できます。

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

Struts2のシステムの定義

Struts2のシステムは、画面やリクエスト処理の土台にStruts2を使うJava Webアプリケーションです。ただし、Struts2自体は業務パッケージや完成済みの基幹システムではありません。そのため、業務ロジック、データベース、認証、帳票、外部連携などを組み合わせて、一つのシステムとして構成します。

Struts2は業務システムではなく開発フレームワーク

Struts2は、JavaでWebアプリケーションを作るためのオープンソースのMVCフレームワークです。MVCとは、画面表示、リクエスト受付、業務データ処理を役割ごとに分ける考え方です。

Struts2は設定より規約を重視する作りで、プラグインによって機能を拡張できます。また、REST、AJAX、JSONを扱うWebシステムにも利用できます。

「Struts2のシステムを導入する」とは、Struts2を使ったシステムの開発、既存システムの保守、別技術への移行を指します。

Action・Interceptor・Resultによる処理の分担

Struts2の典型的な処理の流れを追うと、各要素の役割と周辺技術の構成が分かります。

リクエスト処理：ブラウザからのリクエストをActionが受け、Interceptorが認証や入力値検証を担当します。
応答：業務サービスを呼び出したあと、ResultがJSP画面やJSONを返す段階です。
周辺技術：業務ロジックにSpring、データアクセスにMyBatisやHibernate、実行環境にTomcatなどを組み合わせることがあります。

古いシステムでは、設定ファイル、JSP、独自Interceptor、外部API、バッチが複雑に絡み合っています。そのため、画面数だけで規模を判断すると、見積もりを誤るおそれがあります。

Struts2のシステムの構成とできること

各層の互換性をまとめて確認する構成です。

Struts2のシステムは、フレームワークだけでは完結しません。そのため、Webサーバ、Java実行環境、アプリケーションサーバ、DB、認証基盤、監視基盤まで含めて評価します。

既存システムの場合、Struts2だけを新しくしても、Java、Servlet、JSP、プラグイン、DBドライバが対応していないと動作しません。

ブラウザからデータベースまでを一つの業務基盤とする捉え方

利用者のブラウザの前段には、Webサーバやリバースプロキシを置きます。その後ろで、Tomcat、JBoss、WebLogicなどがJavaアプリケーションを実行します。

Struts2のActionやInterceptorは入力と画面遷移を担い、業務サービスが在庫、契約、申請、予約などのルールを処理します。

さらに、Oracle、SQL Server、PostgreSQLなどのDBや、ファイルサーバ、メール配信、会計や認証などの外部システムが接続されます。そのため、調査では全体を構成図と接続一覧にまとめます。

会員・申請・予約・販売管理などでの利用

Struts2では、会員管理や、申請受付と承認をつなぐワークフロー、空き枠を管理する予約、受注と在庫を連動させる販売管理などを構築できます。

既存の画面や帳票がすでに業務に定着しているなら、業務ルールとデータの整合性維持を優先します。フレームワークの変更が常に最善とは限りません。一方で、スマートフォン対応や頻繁な外部連携、短いリリースサイクルが必要な場合は、現行技術を残すことで追加コストが増えないかを検討します。

既存資産の活用とレガシー化への注意

Struts2の強みは、既存のJava知識、画面、業務ロジック、連携資産を活用しやすい点です。すでに安定して稼働しているなら、一から作り直すより影響範囲を抑えて、必要な修正を進められます。

設定ファイルやOGNL、JSP、独自プラグインが増えても設計書が更新されないままだと、担当が代わったときのコード解析に時間がかかります。

メリットと限界は、変更頻度、停止許容時間、保守要員、将来の連携計画をもとに評価します。

保守継続・更新・移行の選び方

判断では、業務停止のリスク、脆弱性、技術者の確保、追加開発の頻度、移行できる範囲を点検します。そのうえで、保守継続、更新、段階移行、全面再構築のどれにするかを選びます。

古いバージョンだからといって、すぐに全面刷新するとは限りません。まず現行資産を調査し、短期の安全確保と中長期の刷新を分けて計画すると、判断しやすくなります。

保守継続が向くケース

利用者が少なく、仕様変更も限られていて、現在のJavaやアプリケーションサーバを安全に維持できる場合は、保守継続が現実的です。

保守継続でも、Struts2本体と依存ライブラリを一覧にして、脆弱性情報を定期的に確認する作業は欠かせません。

バックアップやログ、復旧手順、担当者も、あわせて更新します。公開範囲が限られていても、認証情報や個人情報を扱うなら、攻撃経路と漏えい時の対応を想定しておきます。

Struts2や周辺環境の更新が向くケース

既存の画面や業務ロジックを大きく変えずに、古いライブラリやJava、アプリケーションサーバを更新できるなら、バージョン更新が候補になります。

Apache Struts公式では、2026年6月にStruts 7.2.1、同年5月にStruts 6.10.0が公開されています（出典: Apache Struts公式リリース情報、2026年）。ただし、最新番号だけで決めず、Java、ServletまたはJakarta、JSP、プラグイン、タグ、OGNL設定、アプリケーションサーバの互換性を検証します。

Spring MVC・Spring Bootなどへの段階移行が向くケース

機能追加が多く、開発者の確保や外部連携の拡張が課題になっているなら、Spring MVCやSpring Bootなどへの移行を検討します。

移行では、ActionをControllerに置き換えるだけでなく、画面遷移と認証・認可、入力値検証、トランザクションを確認します。帳票やバッチ、APIも対象に含めます。

また、データ移行と監査ログも業務単位で確認します。照会画面や独立した申請機能から始め、並行稼働とデータ照合を行えば、一括切替のリスクを抑えられます。

全面再構築が向くケース

業務ルールが変わって画面、データモデル、連携先、権限体系をまとめて見直す場合や、現行コードから仕様を再現できない場合は、全面再構築も候補になります。

現行機能を移すだけでなく、未使用機能を整理し、現場の例外運用を洗い出します。そのうえで、現行と新システムの差分を利用部門と確認します。

着手の前に、移行対象データ、切り戻し条件、教育計画を決めておきます。

ポイント

業務停止のリスクや脆弱性、技術者の確保、移行できる範囲を先に点検します。古いバージョンでも、現行資産の調査結果を見てから保守継続・更新・移行・再構築を選びます。

Struts2のシステム開発・更新の進め方

前段の調査内容が後続工程の判断材料になります。

Struts2案件は、まず現状を調査し、その結果をもとに方針を決めます。そのあとで設計・開発、テスト、リリースへ進み、保守へつなぎます。

移行案件では、コード変更だけでなく、現行仕様を見える形にし、業務を変えない部分と変える部分を関係者と合意する工程が品質を左右します。

▶ 詳細はこちら：Struts2のシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 現行資産の洗い出しと影響範囲の確定

まず、pom.xmlやGradle定義、WAR、JARを調べ、struts.xmlも確認します。次に、Action、Interceptor、Result、JSPといった構成要素を一覧にします。OGNL式や独自プラグインも一覧に加えます。

Java、Servlet、アプリケーションサーバの版を確認します。DBや認証方式、外部APIも洗い出します。さらに、バッチや帳票、ファイル連携を調べ、監視とバックアップの体制も確認します。

設計書がない場合でも、リポジトリ、サーバ上の配備物、ジョブ定義を照合し、アクセスログや問い合わせ履歴と合わせれば、利用機能を推定できます。また、Struts 1とStruts 2を取り違えないよう注意します。

2. 脆弱性と業務要件の同時整理

まず、バージョンや依存ライブラリ、公開URLを整理します。加えて、認証の方式、個人情報の種類、利用者数、停止可能時間を押さえ、緊急度を判断します。

脆弱性の対応を優先して更新すると、画面や連携が壊れる可能性があります。逆に、業務要件を優先して現状を維持すると、パッチを適用できない状態が長引きます。

安全性、業務継続、費用、納期を同じ評価表に並べると、経営層と開発担当者が共通の前提で話し合えます。

3. 設計・開発での境界とテストの先行決定

更新では、互換性のあるJavaとライブラリを決めます。次に、設定の差分やAction、入力値検証を設計します。JSPタグやファイルアップロード、認証・認可の扱いも対象です。

移行では、現行の業務サービスと新しいControllerやAPIの境界を定め、機能単位で切り替えられる構成にします。

テストは、単体テストに加えて主要業務シナリオや権限別の操作を確認します。さらに、外部連携や帳票、性能、障害復旧、セキュリティも対象にします。テストデータと期待結果を先に作っておけば、変更の影響をたどれます。

4. リリース後の保守を含めた計画

本番リリースでは、バックアップや切り戻し条件、メンテナンス告知、監視、問い合わせ窓口を決めておきます。段階移行の場合は、旧システムへ戻せる期間と二重登録の防止も必要です。

脆弱性情報の確認、依存ライブラリの更新、ログの保管、障害訓練、設計書の更新は、定例作業にします。保守契約には、問い合わせへの対応だけでなく、緊急パッチの調査、影響の説明、検証、復旧目標も含めます。

ポイント

前段の現状調査で、資産と影響範囲、脆弱性と業務要件を整理してから設計に入ります。テストとリリース後の保守は、計画の初めから含めておきます。

Struts2のシステム開発の費用相場と期間

Struts2だけを対象にした公的な平均価格はありません。そこで、2026年公開の一般的な開発相場と、調査・移行作業を人月に置き換えた推定を示します。

金額は、画面数やAction数、外部連携、データ量で変わります。さらに、設計書やテスト資産、停止可能時間によっても左右されます。予算の初期目安として使ってください。

▶ 詳細はこちら：Struts2のシステム開発の見積相場や費用/コスト/値段について

▶ 詳細はこちら：Struts2のシステム開発の発注/外注/依頼/委託方法について

作業パターン別の費用目安

作業パターンごとの概算は、次のとおりです。なお、調査の段階でも、依存ライブラリ確認やコード解析、構成図、テスト方針、概算計画に専門知識が必要です。

現状調査・脆弱性診断・移行計画：60万〜600万円程度
パッチ適用・小規模改修：120万〜1,000万円程度
Struts 2.5系から6系などへの更新：300万〜4,000万円程度
Spring MVCやSpring Bootへの移行：600万〜6,000万円程度
全面再構築：1,000万円から数千万円以上になる場合があります

画面、連携、データ移行が多い全面再構築では、金額が上振れする場合があります。金額は、規模や対象範囲によって異なります。

2026年の一般的な相場では、人月単価は60万〜200万円程度です。規模別では、小規模業務ツールが100万〜300万円、中規模業務システムが500万〜1,000万円、大規模システムが1,000万円から数千万円以上とされています（出典: 2026年公開の国内システム開発費用調査）。

たとえば、8人月を人月60万円で計算すると480万円です。管理、要件定義、環境構築は、別途加わる場合があります。テスト、セキュリティ診断、移行支援も、別途加わることがあります。

期間とランニングコストの同時見積もり

開発期間は、どの作業を選ぶかで大きく変わります。現状調査から全面再構築まで、作業ごとの期間の目安を示します。

現状調査：2〜6週間
パッチ適用・小規模改修：1〜3か月
フレームワーク更新：3〜9か月
Springなどへの段階移行：6〜18か月
全面再構築：要件定義からリリースまで8〜24か月以上になる場合があります

全面再構築は、人数を増やしても期間が単純に短くなるとは限りません。現場確認やテストデータの作成、利用部門の受入れ、リリース調整がボトルネックになるからです。

運用費は、監視、バックアップ、クラウドやサーバ、ログ保管に分けて見積もります。脆弱性監視や問い合わせ、緊急対応も、見積もりの項目に入れます。なお、保守費を初期開発費の年15〜25％程度とする場合もあります。

24時間監視、第三者診断、緊急パッチの即日対応を含めると、保守費は上振れします。そのため、初期費用だけで決めず、3年程度の総保有コストで比較します。

見積書の一式計上の分解と比較

見積書は、項目ごとに分けてもらいます。要件定義や現行調査、設計、実装、データ移行、テストに加え、脆弱性診断、リリース、教育、保守も含めます。

「移行一式」の表記では、対象画面やテスト回数、データクレンジングの担当が分かりません。そこで、Action数や外部連携本数、帳票、バッチを確認し、権限パターンやテストケース数も聞いておきます。

休日作業の有無や追加費用の条件、仕様変更の単価は、契約前に書面で明確にしておきます。

ポイント

費用は、作業パターンごとの概算と期間・ランニングコストの両方で比べます。見積書は一式計上をほどき、対象画面やAction数、テスト範囲を確かめてから比較します。

Struts2の開発会社・ベンダーの選び方

「Struts2を使えます」という一言だけで判断せず、保守・脆弱性対応型、バージョン更新型、Spring移行型、業務再構築型のどこに強いかを見ます。

現行資産の調査からテスト、リリース後の保守まで責任範囲を説明できるか、担当者がコードと業務を理解しているかを確認します。

作業内容で見る実績の確認

実績は、新規開発や既存保守、脆弱性対応、Struts 6や7への更新、Springなどへの移行に分けて確認します。

さらに、Javaやアプリケーションサーバの更新、DB移行の経験も確認します。API連携や性能改善、テスト自動化、24時間運用の経験も、あわせて見ます。

案件名や規模だけでなく、担当した工程、現在の技術者体制、類似案件の担当者が参画できるかを確かめます。

提案時の技術面と業務面の質問

問い合わせには、Struts、Java、Tomcatのバージョンや画面数、Action数を含めます。さらに、JSP量、DB、外部連携、利用者数も伝えます。

設計書の有無や希望する移行先、停止可能時間も示します。そして、依頼先にはコード解析や脆弱性確認、テスト設計、データ照合について尋ねます。

切り戻し手順やリリース後の窓口も確認します。回答が一般論にとどまり、前提条件や調査範囲が示されない場合は、注意が必要です。

契約と保守体制の比較

契約と保守体制では、責任範囲や情報管理を次の観点で確認します。

成果物・権利：ソースコード、設定、テスト結果、設計書の範囲と権利関係。
契約条件：再委託、秘密情報の扱い、脆弱性発見時の連絡期限、障害対応時間の取り決め。
保守体制：一次受付と技術調査の担当、特定技術者への依存、引き継ぎ資料の更新状況。
個人情報：委託先の監督やアクセス権限、ログ、インシデント報告、データの返却・消去の定め。

個人情報に関する項目は、契約と運用の両方に反映します。

▶ 詳細はこちら：Struts2のシステム開発でおすすめの開発会社/ベンダー6選と選び方

ポイント

依頼先は、保守、更新、移行、再構築のどれに強いかで比べます。実績は作業内容で確かめ、契約では責任範囲と保守体制をそろえて比較します。

Struts2のシステムで欠かせないセキュリティと運用

フレームワークの外側にも管理が必要な構成です。

Struts2はWebフレームワークで、認証・認可や脆弱性管理、監査ログ、運用監視を自動で保証するものではありません。Apache公式も、Struts2は純粋なWebフレームワークで、セキュリティ機構そのものは提供しないと説明しています。

安全性を確保するには、フレームワーク、アプリケーションコード、サーバ、ネットワーク、運用手順をまとめて管理します。

バージョンと依存ライブラリの定期確認

サポート状況と公表された脆弱性を確かめ、対象システムへの影響を照合します。

サポート終了：古いバージョンは対象外となり、パッチが提供されない場合があります。
CVE-2025-68493：2025年に公表されたXWorkコンポーネントのXXE脆弱性。
同脆弱性の緩和策：少なくともStruts 6.1.1以降への更新。
CVE-2025-64775：multipart処理によるディスク枯渇型のサービス拒否。
同脆弱性の緩和策：Struts 6.8.0または7.1.1以降への更新（出典: Apache Struts公式セキュリティ告知、2026年確認）。

対象バージョンに加え、影響を受ける機能が有効かどうか、公開範囲、修正後の回帰テストまで記録します。

入力・認証・JSP・ログのアプリケーション単位での保護

画面とAPIでは、入力値検証、CSRF対策、出力エスケープを整えます。さらに、SQLインジェクション対策やアップロード制限、セッション管理、権限確認も進めます。

JSPは直接公開せず、Action経由で制御します。OGNL式は、必要以上に使わないようにします。エラーには、内部構成や個人情報を表示させません。

管理者操作や個人情報へのアクセスは、監査ログに残します。次に、ログの改ざん防止や保管期間、閲覧権限、アラート条件を決めます。

運用におけるパッチ適用と復旧の一連の手順

IPAは、Apache Struts 2の脆弱性について、パッチを適用し、事前に動作確認してから更新するよう案内しています（出典: IPA「Apache Struts2の脆弱性対策情報一覧」、2026年1月更新）。

検証は本番だけで行わず、テスト環境で主要シナリオを実行します。あわせて、バックアップから復旧できることも確認します。

依存関係は毎月または四半期ごとに確認し、緊急情報が出たときは臨時に判定します。また、リリース承認者や切り戻し担当、利用部門の連絡先を決めておくと、判断が遅れにくくなります。

ポイント

安全性は、フレームワーク、アプリケーション、サーバ、運用手順をまとめて管理して確保します。脆弱性は、バージョンと依存ライブラリを定期的に照合します。

よくある質問（FAQ）

Struts2のシステムについて、現場で多い疑問を取り上げます。バージョンや構成によって答えが変わる場合は、確認すべき情報も併せて示します。

Struts2のシステムはパッケージ製品ですか？

いいえ。Struts2はJava Webアプリケーション開発用のフレームワークです。そのため、業務システムには業務ロジック、DB、認証、画面、外部連携、運用基盤を別途設計・開発します。

導入費用は、Struts2のライセンス料ではなく、要件定義や開発、テスト、環境構築、保守の作業量で決まります。

古いStruts2を使っている場合はすぐに移行すべきですか？

すぐに全面移行するとは限りません。まずは、バージョン、依存ライブラリ、公開範囲、個人情報、脆弱性の影響を調べます。

パッチを適用できる場合は、テスト環境で更新と回帰テストを行います。中長期の移行計画も、あわせて作ります。

サポート終了や技術者不足、機能追加の増加、サーバ更新期限が重なる場合は、短期対策に加えて、段階移行や再構築を早めに予算化します。

Struts2からSpringへ移行する費用はいくらですか？

小規模な調査や一部機能の移行は数百万円です。一方で、中規模以上で画面、業務ロジック、認証、データ、外部連携を含む場合は、600万〜6,000万円程度が推定範囲です。

金額は一律ではなく、画面数やAction数、連携本数で変わります。テスト資産や設計書、データ移行、並行稼働期間でも左右されます。

先に現行調査を発注し、対象範囲と移行単位を確定してから本開発の見積もりを取ると、金額の根拠を比べやすくなります。

Struts2に詳しい開発会社には何を確認すべきですか？

保守の経験や現行資産の洗い出し、脆弱性対応を確認します。さらに、Javaやサーバの更新、Struts 6や7への対応、Spring移行の経験も見ます。

データ照合や回帰テスト、リリース後の保守についても尋ねます。問い合わせ時には、バージョンや画面数、Action数を示します。また、外部連携やDB、設計書、利用者数も共有します。

停止可能時間と希望方針も伝えます。提案書には、調査方法、成果物、前提、追加費用の条件、緊急連絡体制が記載されているかを確認します。

まとめ

Struts2のシステムは、Java Webフレームワークを中心に、画面、業務ロジック、認証、DB、外部連携、運用基盤を組み合わせた業務システムです。

判断は、名称ではなく中身から始めます。まず、バージョン、依存ライブラリ、公開範囲、業務の重要度、技術者、テスト資産を洗い出します。

現状調査から始める保守・更新・移行の比較

まずサポート状況と脆弱性を確認し、必要であればパッチ適用を優先します。

判断では、業務を安定して続ける保守継続、現行資産を生かす更新、機能追加に備える段階移行、業務を見直す再構築を比べます。

費用は、初期開発費だけでなく、テスト、移行、教育、保守、緊急対応を含めた総額で見積もります。

開発会社へのコードと業務の両面からの確認

依頼先の説明と提案を、次の観点で確認します。

対応計画：現行調査、脆弱性対応、互換性検証、データ移行、回帰テスト、切り戻し、リリース後保守の流れを説明できるかを見ます。
提案条件：対象範囲、成果物、体制、費用内訳、追加条件、契約上の責任の所在を、そろえて比べます。
事前調査：サーバ上のJARや設定、Java・アプリケーションサーバ、連携先、設計書、運用手順を確かめたうえで、関係者と共有します。

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