Struts2のシステム開発の完全ガイド

Struts2のシステムとは、Apache Struts 2を使って構築されたJavaのWeb業務システムであり、既存資産を生かした保守・更新・段階移行を、バージョンと脆弱性の確認から判断することが重要です。

Struts2は会員管理、申請、予約、販売管理、社内ポータルなど幅広い業務で使われてきました。一方で、古いバージョンや担当者が分からない構成を放置すると、セキュリティ、開発者の確保、機能追加、障害対応に影響します。この記事では、Struts2の基本構造、種類、開発の進め方、2026年時点の費用相場、保守継続と移行の選び方、開発会社やサービスを選ぶ際の確認項目まで、意思決定に必要な情報をまとめます。

▼関連記事一覧
・Struts2のシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Struts2のシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Struts2のシステム開発の見積相場や費用/コスト/値段について
・Struts2のシステム開発の発注/外注/依頼/委託方法について

Struts2のシステムとは何ですか？

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

Struts2は、JavaでWebアプリケーションを作るためのオープンソースのMVCフレームワークです。MVCとは、画面表示、リクエストを受け付ける処理、業務データを扱う処理を役割ごとに分ける考え方です。設定より規約を重視し、プラグインで機能を拡張できるため、REST、AJAX、JSONを扱うWebシステムにも利用できます。したがって「Struts2のシステムを導入する」という表現は、実際にはStruts2を使ったシステムを開発する、既存システムを保守する、または別の技術へ移行するという意味で使われます。

典型的な処理は、ブラウザから送られたリクエストをActionが受け取り、Interceptorが認証や入力値検証などの共通処理を行い、業務サービスを呼び出して、ResultがJSP画面やJSONを返す流れです。業務ロジックの実装にはSpringなどのDI・サービス基盤、データアクセスにはMyBatisやHibernate、実行環境にはTomcatなどのアプリケーションサーバが組み合わされることがあります。古いシステムでは、設定ファイル、JSP、独自Interceptor、外部API、バッチ処理が複雑に絡み合っていることが多く、画面数だけで規模を判断すると見積もりを誤ります。

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

Struts2を使ったシステムは、フレームワークだけで完結せず、Webサーバ、Java実行環境、アプリケーションサーバ、データベース、認証基盤、監視基盤まで含めて評価する必要があります。特に既存システムでは、Struts2のバージョンだけを更新しても、JavaやServlet、JSP、プラグイン、データベースドライバが対応しなければ動作しません。

利用者が操作するブラウザの前段には、Webサーバやリバースプロキシが置かれ、その後ろでTomcat、JBoss、WebLogicなどがJavaアプリケーションを実行します。Struts2のActionやInterceptorは入力と画面遷移を担い、業務サービスが在庫、契約、申請、予約などのルールを処理します。その先にはOracle、SQL Server、PostgreSQLなどのデータベース、ファイルサーバ、メール配信、会計や認証などの外部システムが接続されます。調査では、この全体を構成図と接続一覧に落とし込むことが大切です。

Struts2の業務システムでは、ログイン後の権限に応じてメニューを出し分ける会員管理、申請受付と承認をつなぐワークフロー、空き枠を管理する予約、受注と在庫を連動させる販売管理などを構築できます。既存の画面と帳票が業務に定着している場合は、フレームワークを変えることよりも、業務ルールとデータの整合性を維持することが優先されます。反対に、スマートフォン対応、頻繁な外部連携、短いリリースサイクルが必要な場合は、現行技術を残すことで追加コストが増えないかを検討します。

Struts2の強みは、既存のJava知識、画面、業務ロジック、連携資産を活用しやすいことです。すでに安定稼働しているシステムであれば、機能を一から作り直すより、影響範囲を抑えながら必要な修正を進められます。一方、設定ファイルやOGNL、JSP、独自プラグインが増え、設計書が更新されなくなると、担当者の交代時にコード解析へ時間がかかります。メリットと限界を、技術者の好みではなく、変更頻度、停止許容時間、保守要員、将来の連携計画で評価することが重要です。

保守継続・更新・移行はどう選びますか？

結論として、業務の停止リスク、脆弱性、技術者の確保、追加開発の頻度、移行できる範囲を点検し、保守継続、Struts2の更新、別フレームワークへの段階移行、全面再構築のいずれかを選びます。バージョンが古いから即座に全面刷新するのではなく、現行資産を調査してから、短期の安全確保と中長期の刷新を分けて計画すると判断しやすくなります。

利用者が少なく、仕様変更が限定的で、現在のJavaやアプリケーションサーバを安全に維持できる場合は、保守継続が現実的です。ただし、保守継続は何もしないことではありません。Struts2本体と依存ライブラリの一覧を作成し、脆弱性情報を定期的に確認し、バックアップ、ログ、復旧手順、担当者を更新する必要があります。公開範囲が限定されていても、認証情報や個人情報を扱うなら、攻撃経路と漏えい時の対応を想定します。

既存の画面や業務ロジックを大きく変えず、古いライブラリ、Java、アプリケーションサーバを更新できる場合は、バージョン更新が候補になります。Apache Struts公式では、2026年6月にStruts 7.2.1、2026年5月にStruts 6.10.0が公開されています（出典: Apache Struts公式リリース情報、2026年）。ただし、最新番号だけを見て決めるのではなく、Javaのバージョン、ServletまたはJakartaへの対応、JSP、プラグイン、タグ、OGNL設定、アプリケーションサーバの互換性を検証します。

今後も機能追加が多く、開発者の確保や外部連携の拡張が課題になっている場合は、Spring MVCやSpring Bootなどへの移行を検討します。移行では、Struts2のActionを新しいControllerへ置き換えるだけでは足りません。画面遷移、認証・認可、入力値検証、トランザクション、帳票、バッチ、API、データ移行、監査ログまで業務単位で確認します。まず照会系画面や独立した申請機能から始め、並行稼働とデータ照合を行う方式なら、全機能を一度に切り替えるリスクを抑えられます。

業務ルールが変わり、画面、データモデル、連携先、権限体系をまとめて見直す場合や、現行コードを解析しても仕様を再現できない場合は、全面再構築も候補です。ただし、全面再構築では現行機能を新システムへ移すだけでなく、使われていない機能を整理し、現場の例外運用を洗い出します。現行システムと新システムの差分を利用部門と確認し、移行対象データ、切り戻し条件、教育計画まで決めてから着手することが大切です。

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

Struts2の案件は、いきなり改修を始めるより、現状調査、方針決定、設計・開発、テスト、リリース、保守の順に進めます。移行案件ではコードを変更する作業だけでなく、現行仕様を見える化し、業務が変わらない部分と変える部分を合意する工程が品質を左右します。

最初に、pom.xmlやGradleの定義、WAR、JAR、struts.xml、Action、Interceptor、Result、JSP、OGNL式、独自プラグインを一覧化します。続いてJava、Servlet、アプリケーションサーバ、データベース、認証方式、外部API、バッチ、帳票、ファイル連携、監視、バックアップを確認します。設計書がなくても、リポジトリ、サーバ上の配備物、アクセスログ、ジョブ定義、問い合わせ履歴を照合すれば、実際に使われている機能を推定できます。Struts 1とStruts 2を取り違えないことも重要です。

バージョン、依存ライブラリ、公開URL、認証の有無、個人情報の種類、利用者数、停止できる時間を整理し、緊急度を判断します。脆弱性だけを見て更新すると、画面や連携が壊れる可能性があります。逆に、業務要件だけを見て現状維持すると、修正パッチを適用できない状態が長引きます。安全性、業務継続、費用、納期を同じ評価表に並べると、経営層と開発担当者が共通の前提で話し合えます。

更新の場合は、互換性のあるJavaとライブラリの組み合わせを決め、設定差分、Actionの変更、入力値検証、JSPタグ、ファイルアップロード、認証・認可を設計します。移行の場合は、現行の業務サービスと新しいControllerやAPIの境界を定め、機能単位で切り替えられる構成にします。テストでは、単体テストだけでなく、主要業務のシナリオ、権限別操作、外部連携、帳票、性能、障害復旧、セキュリティを確認します。テストデータと期待結果を先に作ると、変更の影響を追跡しやすくなります。

本番リリースでは、バックアップ、切り戻し条件、メンテナンス告知、監視、問い合わせ窓口を決めます。段階移行なら、旧システムへ戻せる期間とデータの二重登録を防ぐ仕組みが必要です。リリース後は、脆弱性情報の確認、依存ライブラリの更新、ログの保管、障害訓練、設計書の更新を定例化します。保守契約は、問い合わせ対応だけでなく、緊急パッチの調査、影響範囲の説明、テスト環境での検証、復旧目標まで含めて確認します。

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

Struts2だけを対象にした公的な平均価格はありません。ここで示す金額は、2026年に公開された一般的なシステム開発相場と、現行調査や移行作業を人月に置き換えた推定です。画面数、Action数、外部連携、データ量、設計書の有無、テスト資産、停止可能時間によって大きく変わるため、予算の初期目安として利用してください。

現状調査、脆弱性診断、移行計画だけなら、60万〜600万円程度が一つの目安です。依存ライブラリの確認、コード解析、構成図、テスト方針、概算計画まで含めると、短い調査でも複数人の専門知識が必要になります。パッチ適用や小規模改修は120万〜1,000万円程度、Struts 2.5系から6系などへの更新は300万〜4,000万円程度、Struts2から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数、外部連携本数、帳票、バッチ、権限パターン、テストケース数、休日作業の有無も確認します。追加費用が発生する条件と、仕様変更の単価も契約前に明文化します。

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

開発会社を選ぶときは、「Struts2を使えます」という一言だけでなく、保守・脆弱性対応型、バージョン更新型、Spring移行型、業務再構築型のどこに強いかを見ます。現行資産の調査からテスト、リリース後の保守まで同じ責任範囲で説明できるか、担当者がコードと業務の両方を理解できるかを確認します。

実績を確認するときは、Struts2を使った新規開発なのか、既存システムの保守なのか、脆弱性対応なのか、Struts 6や7への更新なのか、Springなどへの移行なのかを分けて聞きます。さらに、Javaやアプリケーションサーバの更新、DB移行、API連携、性能改善、テスト自動化、24時間運用の経験も確認します。過去の案件名や規模だけでなく、担当した工程、現在の技術者体制、類似案件の担当者が参画できるかを具体化することが大切です。

問い合わせには、Strutsのバージョン、JavaとTomcatのバージョン、画面数、Action数、JSPの量、データベース、外部連携、利用者数、設計書の有無、希望する移行先、停止可能時間を含めます。依頼先からは、現行コードをどう解析するか、依存ライブラリの脆弱性をどう確認するか、テストをどう設計するか、データ移行の照合方法、切り戻し手順、リリース後の問い合わせ窓口を提案してもらいます。質問への回答が一般論だけで、前提条件や調査範囲を示さない場合は注意が必要です。

契約では、成果物、ソースコード、設定ファイル、テスト結果、設計書、権利関係、再委託、秘密情報の取り扱い、脆弱性発見時の連絡期限、障害時の対応時間を確認します。保守体制では、一次受付と技術調査の担当を分けるのか、特定の技術者に依存していないか、引き継ぎ資料を更新するかを見ます。個人情報を扱うシステムでは、委託先の監督、アクセス権限、ログ、インシデント報告、データ返却・消去まで契約と運用に落とし込みます。

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

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

Struts2はWebアプリケーションを作るためのフレームワークであり、認証・認可、脆弱性管理、監査ログ、運用監視を自動で保証する製品ではありません。Apache公式も、Struts2は純粋なWebフレームワークでセキュリティ機構そのものを提供しないと説明しています。システムの安全性は、フレームワーク、アプリケーションコード、サーバ、ネットワーク、運用手順をまとめて管理して初めて確保できます。

Apache Strutsの公式情報では、古いバージョンはサポートが終了し、セキュリティパッチが提供されない場合があります。2025年に公表されたCVE-2025-68493ではXWorkコンポーネントのXXE脆弱性が案内され、少なくともStruts 6.1.1以降への更新が緩和策として示されています。また、CVE-2025-64775ではmultipartリクエスト処理によるディスク枯渇型のサービス拒否が案内され、Struts 6.8.0または7.1.1以降への更新が示されています（出典: Apache Struts公式セキュリティ告知、2026年確認）。対象バージョンを使っているかだけでなく、影響を受ける機能を有効にしているか、公開範囲がどこか、修正後に回帰テストを実施したかまで記録します。

入力値検証、CSRF対策、出力エスケープ、SQLインジェクション対策、ファイルアップロード制限、セッション管理、権限チェックを、画面とAPIの両方で確認します。JSPを直接公開せずAction経由で制御すること、OGNL式を必要以上に使わないこと、エラーメッセージに内部構成や個人情報を出さないことも重要です。管理者操作や個人情報へのアクセスは監査ログに残し、ログの改ざん防止、保管期間、閲覧権限、アラート条件を決めます。

IPAはApache Struts 2の脆弱性について、修正パッチを適用し、事前に動作確認してから更新するよう案内しています（出典: IPA「Apache Struts2の脆弱性対策情報一覧」、2026年1月更新）。本番だけで検証せず、テスト環境で主要シナリオを実行し、バックアップから復旧できることを確認します。毎月または四半期ごとの依存関係確認、緊急情報が出た場合の臨時判定、リリース承認者、切り戻し担当、利用部門への連絡先を決めておくと、脆弱性発生時に判断が遅れません。

よくある質問（FAQ）

Struts2のシステムについて、現場で特に多い疑問をまとめます。バージョンや構成によって答えが変わる質問では、判断のために確認すべき情報も示します。

いいえ、Struts2はJava Webアプリケーションを開発するためのフレームワークです。業務システムとして利用するには、業務ロジック、データベース、認証、画面、外部連携、運用基盤を別途設計・開発します。そのため、導入費用はStruts2のライセンス料ではなく、要件定義、開発、テスト、環境構築、保守の作業量で決まります。

すぐに全面移行するとは限りませんが、まずバージョン、依存ライブラリ、公開範囲、個人情報、脆弱性の影響を調査します。修正パッチを適用できるなら、テスト環境で更新と回帰テストを行い、同時に中長期の移行計画を作ります。サポート終了、技術者不足、機能追加の増加、サーバ更新の期限が重なっているなら、短期の安全対策だけでなく、段階移行や再構築の予算化を早めます。

小規模な調査や一部機能の移行なら数百万円、画面・業務ロジック・認証・データ・外部連携を含む中規模以上の移行なら600万〜6,000万円程度が推定の範囲です。Struts2固有の一律価格ではなく、画面数、Action数、連携本数、テスト資産、設計書、データ移行、並行稼働の期間によって変わります。先に現行調査を発注し、対象範囲と移行単位を確定してから本開発の見積もりを取ると、金額の根拠を比較しやすくなります。

保守だけでなく、現行資産の棚卸し、脆弱性対応、Javaやアプリケーションサーバの更新、Struts 6や7への対応、Springへの移行、データ照合、回帰テスト、リリース後の保守まで経験があるかを確認します。問い合わせ時には、バージョン、画面数、Action数、外部連携、DB、設計書の有無、利用者数、停止可能時間、希望する方針を伝えます。提案書に調査方法、成果物、前提条件、追加費用の条件、緊急時の連絡体制が書かれているかも確認します。

まとめ

Struts2のシステムは、Struts2というJava Webフレームワークを中心に、画面、業務ロジック、認証、データベース、外部連携、運用基盤を組み合わせた業務システムです。判断の出発点は、Struts2の名称だけで古い・新しいと決めることではなく、バージョン、依存ライブラリ、公開範囲、業務の重要度、技術者、テスト資産を棚卸しすることです。

サポート状況と脆弱性を確認し、必要ならパッチ適用を優先します。そのうえで、既存業務を安定して使い続ける保守継続、現行資産を生かすバージョン更新、将来の機能追加に備える段階移行、業務そのものを見直す再構築を比較します。費用は初期開発費だけでなく、テスト、移行、教育、保守、緊急対応を含む総額で見積もることが大切です。

依頼先を選ぶときは、Struts2の経験年数だけでなく、現行調査、脆弱性対応、互換性検証、データ移行、回帰テスト、切り戻し、リリース後の保守を一つの計画として説明できるかを見ます。提案を比較するときは、対象範囲、成果物、体制、費用の内訳、追加条件、契約上の責任分界をそろえてください。最初の一歩は、サーバ上のJARや設定、Java・アプリケーションサーバ、連携先、設計書、運用手順を確認し、関係者と現状を共有することです。

▼関連記事一覧
・Struts2のシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Struts2のシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Struts2のシステム開発の見積相場や費用/コスト/値段について
・Struts2のシステム開発の発注/外注/依頼/委託方法について