Struts2のシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Struts2のシステム開発は、現行資産を調べ、延命・バージョン更新・移行・再構築から方針を選んだうえで、段階的に設計と移行を進めるのが基本の流れです。この流れを踏むと、稼働後の安全な運用につながります。

全体像は、Struts2のシステム開発の完全ガイドもご覧ください。

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

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

Struts2の全体像と開発方針

Struts2では、ブラウザのリクエストをActionが受け、Interceptorで認証や入力検証を行います。その後、業務サービスとデータベースを呼び出し、JSPやJSONで結果を返す構成が基本です。

実際の業務では、TomcatやWebLogicなどのサーバ、Spring、MyBatisやHibernateが組み合わさります。部品が多いぶん、OracleやSQL Serverなどのデータベースを含め、周辺部品ごとに業務上の重要度を把握しておく必要があります。

Struts2の位置づけ：業務システムではなくJavaのWebフレームワーク

Apache公式の説明では、Struts2は設定より規約を重んじ、プラグインで拡張できるMVCフレームワークです。

• 対応機能：REST、AJAX、JSONに対応したオープンソースです
• 用途：会員管理、申請、予約、販売管理、社内ポータルの土台になります
• 見積もり：画面・Action・帳票・バッチ・外部APIの数、利用者数、権限が見積もりの材料になります
• 安全対策：認証基盤・認可・CSRF・入力検証の方式を、監査ログやバックアップ、診断と合わせて決めておきます

業務ルールや画面、データは案件ごとに設計します。このため、製品の導入費だけでは開発費は分かりません。

認証や安全な運用は、Struts2を採用するだけでは得られません。Apache公式のセキュリティガイドも、フレームワークの機能とシステム全体の安全性を分けて扱っています。そのため、安全対策は業務要件と同じタイミングで検討します。

延命・バージョン更新・移行・再構築の4方針の比較

既存システムは、いきなり全面刷新に進まず、次の4方針を比べて選びます。

• 延命：短期のパッチ適用と保守で、時間を確保する方法
• 更新：Struts 6系などサポートされる系統への更新
• 移行：Spring MVCやSpring Bootへ、業務単位で移すこと
• 再構築：業務要件からシステムを作り直すこと

どの方針を選ぶかは、停止リスク、予算、開発者の確保、変更したい機能の量で判断します。

2026年8月時点で、Apache公式にはStruts 6.10.0と7.2.1のリリースが掲載されています。一方で、Struts 2.5系は2023年10月30日にEOLとなり、Apacheのセキュリティパッチや更新を受けられません（出典: Apache Struts公式EOL情報、2026年）。

古い系統を保守し続ける場合も、現行バージョンと依存ライブラリを確認し、移行計画を作成しておきます。

Struts2のシステム開発の6フェーズ

開発会社に相談する前に、現行システムの事実を集めておくと、提案と見積もりの精度が上がります。

企画だけでなく移行や保守も含めて、次の6フェーズで進めます。

1. 要件整理で、現行資産と業務の優先順位を確定する
2. 選定で、保守力と移行力を確認する
3. 設計・開発で、変更範囲と境界を管理する
4. テストで、業務・連携・セキュリティを検証する
5. 稼働前に、移行準備と切り替えを行う
6. 稼働後に、運用を定着させる

フェーズごとに完了条件を決めておき、未解決の判断を残したまま次の工程へ進まないことが大切です。

フェーズ1：要件整理での現行資産と業務の優先順位の確定

まず、現行資産を一覧にします。対象は、設定・実行ファイル・ソース、画面、データベース、連携などです。

1. pom.xmlまたはGradle設定・WAR・JAR一覧、struts.xml、Action・Interceptorを確認する
2. JSP・OGNL式・Spring設定、DBスキーマ・バッチ、外部API・帳票、認証方式を調べる
3. Struts 1と2を区別し、依存関係と実行環境をサーバ上でも確認する
4. 古い設計書は、ソースと実画面を照合して、機能一覧を作り直す
5. 利用部門・月間件数・締め日、停止可能時間、法令・監査要件、残す画面と廃止機能を聞き取る
6. 公開範囲・個人情報・特権操作、障害時の手作業、保存年数、連携先・方式、テストデータ・設計書の有無を確認する
7. 止められない業務と後回しにできる業務を分けて、段階移行の単位を決める

フェーズ2：選定での保守力と移行力の確認

候補会社には、現行資産の解析から更新、データ移行、リリース後の保守まで対応できるかを尋ねます。

• 技術経験：Strutsのバージョン、Java、Tomcat、Spring、認証基盤の経験の有無
• 対応体制：脆弱性対応・コード解析・テスト自動化の範囲と、担当者の経験年数
• 提案内容：調査の内容、移行対象と対象外、仮定・テスト方針・切り戻し条件、納品物・保守窓口を明記してもらう
• 実務確認：画面や障害事例を示してもらい、調査ログと切り分け順の説明を受ける
• 契約確認：再委託、ソースコードの権利、脆弱性発見時の連絡期限を契約前に確認する

対応力を確かめるには、「Struts2に対応できますか」と聞くより、上の5つの観点で具体的に尋ねる方が役立ちます。

フェーズ3：設計・開発での変更範囲と境界の管理

設計では、機能要件に加えて、変更範囲とシステム間の境界を明確にします。

• 非機能要件：認証・認可、入力検証、エラー・監査ログ、性能、バックアップ・監視・障害通知の方針を決めておく
• 処理経路：Actionから業務サービス、DB、外部APIへ流れる経路を図にまとめる
• 移行設計：旧画面と新画面、旧データと新データの対応表を作ったうえで、画面単位と業務ドメイン単位のどちらで移すかを決める
• 変更と例外の管理：設定・Interceptorの変更履歴とレビュー基準を整え、不正入力や権限外操作を定義する
• 段階移行：新旧の結果を比べるログやデータ照合を用意し、切り替え後の原因調査を早められるようにする

OGNL式、アップロード、JSON、セッション、権限まわりは、入力や操作の受け付け方に直接関わる部分です。そのため、設定やInterceptorを変えるときは、この範囲を変更の確認対象に含めます。

フェーズ4：テストでの業務・連携・セキュリティの検証

テストは業務シナリオを中心に組み立て、あわせて脆弱性情報との照合も行います。

1. 単体、結合、システム、受入の順に、テストを進める
2. 更新時は、Action・Interceptor・入力検証・JSP、アップロード・セッション・例外・権限、外部API・バッチ・帳票を回帰確認する
3. 締め処理、取消、二重送信、通信タイムアウトを再現する
4. 依存ライブラリを一覧にし、Apache Struts公式とIPAの脆弱性情報と照らし合わせる

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

更新後は互換性を確かめる必要があるため、本番へ直接適用せず、検証環境でテストします。あわせて、失敗したときの切り戻し手順も確認します。

フェーズ5・6：稼働と定着、運用の仕組みづくり

稼働後の確認結果を改善バックログに変換し、運用担当者へ必要な情報を引き継ぎます。

1. 稼働前に、データ移行リハーサルとバックアップからの復元を確認する
2. DNS・ロードバランサー切り替え、権限、監視・アラート、問い合わせ窓口、切り戻し判断者を準備する
3. 当日は時刻単位で作業を進め、実施者・承認者・次へ進む確認項目を決める。利用者が多い場合は、代表部門や限定機能で先行稼働する
4. 稼働後は、障害件数、処理時間、問い合わせ、利用率、手作業の残量を確認する
5. ログ・再起動条件・バックアップ、脆弱性情報の確認先、緊急連絡先を運用担当者へ引き継ぐ
6. 保守契約では、問い合わせ、障害一次対応、パッチ、OS・Java・サーバ更新、定期レビューを分ける

Struts2のシステム開発費用相場とコストの内訳

Struts2だけの公的な平均価格は確認できません。そのため、費用は人月単価と工数を基に算出します。費用に影響するのは、画面数・Action数・連携本数です。さらに、移行難易度、テスト資産、納期・保守体制も費用に影響します。

相場はあくまで目安で、現状調査をせずに特定の金額を断定することはできません。

見積もりでは、調査・開発・テスト・移行・教育・保守の費用を分けて比べます。

現状調査から再構築までの費用レンジ

リサーチノートと2026年時点の一般的な相場情報を基にした検討レンジです。

• 現状調査など：脆弱性診断・移行計画を含め60万〜600万円
• パッチ・小規模改修：120万〜1,000万円
• バージョン更新：Struts 2.5系からの更新は300万〜4,000万円程度
• Spring移行：Spring MVCやSpring Bootへの移行は600万〜6,000万円
• 再構築：周辺システムを含む場合は1,000万〜5,000万円以上の可能性

この金額は、画面数や作業量を人月に置き換えて推定したものです。Struts2案件の公的な平均額ではありません。

SIA株式会社は、2026年7月に受託開発の相場を更新しています。小規模は20画面以下で、人月100万〜180万円、総額500万〜1,200万円です。一方で、中規模は60画面以下で、人月150万〜220万円、総額2,000万〜6,000万円です（出典: SIA株式会社、2026年7月）。

Struts2の画面移行は、画面数が少なくても、複雑な権限や外部連携があると工数が増えます。このため、画面数だけで判断しないことが大切です。

初期開発費に加えた運用・更新費の見積もり

見積書では、初期開発、継続運用、バージョン更新の項目を分けて示してもらいます。

• 開発工程：要件整理と調査から、基本・詳細設計、実装、単体・結合テスト、受入支援までを含みます
• 導入作業：脆弱性診断・データ移行・インフラ、マニュアル・教育・リリース支援
• 更新作業：Java・Servlet・JSP・プラグイン・アプリケーションサーバの互換性確認
• 運用保守：監視・バックアップ・ログ保管、問い合わせ・障害対応、定期パッチ・脆弱性情報・性能改善
• 保守費の目安：初期開発費の年15〜25％、月額15万〜80万円。24時間監視、緊急対応、第三者診断で上振れ（出典: 業務システム全般の一般相場整理、2026年）

「ライブラリ更新一式」と書かれていても作業範囲が分からないため、内容を具体的に確認します。

金額の安さだけでなく、対応時間、対象作業、追加作業の単価も比べます。

Struts2のシステムの見積もりのポイント

会社ごとに調査範囲やテストの深さが違うため、総額だけを比べると判断を誤りやすくなります。

見積依頼書には、現行環境、対象業務、画面数・Action数・DB、外部連携を記載します。加えて、利用者数・停止可能時間・希望移行先、設計書の有無、納期も必要です。

不明項目は「要調査」とし、調査後に本見積へ切り替える二段階契約も検討します。

見積書での納品物と前提条件の確認

見積書では、工数や納品物、テストと移行の範囲、契約条件を確かめます。

1. 工程ごとの工数・担当ロール・納品物、対象外、利用環境を記載してもらう
2. レビュー回数・テストケース数・移行リハーサル回数を比べる
3. テスト費用に、計画・ケース作成・実施・不具合修正・再テスト、利用部門の受入支援が含まれるか確認する
4. データ移行の項目変換・欠損データ・件数照合、移行後バックアップ、失敗時の戻し方を確認する
5. 準委任か請負か、検収条件、仕様変更・遅延連絡・第三者ライブラリのライセンス、ソース引き渡し・再委託承認を確認する

現行仕様が不明なまま、固定価格と短納期だけを約束すると、追加費用や品質低下につながります。最初は準委任で調査し、仕様とリスクが見えてから、移行部分を請負に分ける方法もあります。

会社の比較：「保守型」と「移行型」の区別

Struts2を扱える会社でも得意分野は異なるので、次の4つの型を見分けます。

• 保守型：障害対応やパッチ適用を重視する
• 更新型：Struts 6系などへの更新を得意とする
• 移行型：Springへの移行を中心に対応する
• 再構築型：業務再設計やクラウド化まで行う

まず、「止めずに維持する力」と「将来の技術負債を減らす力」のどちらが必要かを決めます。

面談では、現場担当者の参加時期、ソース解析報告書、脆弱性発生時の一次回答時間を聞きます。さらに、テスト環境の準備を誰が担うかも確かめます。

また、担当者の経験や現在の技術対応状況を確かめたうえで、2社から価格を取り、調査報告書とリスク一覧のサンプルも比べます。

Struts2のシステム開発でよくある質問（FAQ）

Struts2では、バージョンの古さや安全性、移行の必要性、費用の決め方について、よく質問が寄せられます。各質問には、判断を急がず、まず確認すべき点で直接答えます。

Struts2のシステムは今すぐ別の技術へ移行すべきですか？

すべてのシステムを直ちに全面移行する必要はありません。

• EOLの系統：Struts 2.5系などは放置せず、現状調査と移行計画に着手する
• 判断材料：公開範囲・個人情報・脆弱性の影響、停止可能時間・開発者の確保を確認する
• 対応時期：短期のパッチ対応と、中長期の更新・移行を分けて考える

Struts2のシステム開発は何円から依頼できますか？

費用は作業の規模によって変わるため、まずは主な検討レンジを押さえておきます。

• 現状調査：60万〜600万円程度
• パッチ・小規模改修：120万〜1,000万円程度
• Spring移行・再構築：数百万円から数千万円以上の可能性

画面数・連携・テスト・納期で金額が変わるため、調査と本開発を分けて見積もる方法が安全です。

Struts2に詳しい開発会社へ何を伝えると見積もりが早くなりますか？

見積もりを早めるには、環境とシステムの規模、希望する対応方針を伝えます。

• 環境・規模：Strutsのバージョン、Javaとサーバ、画面・Action・JSP・帳票の数
• 利用条件：DB・外部連携、利用者数・公開範囲、設計書の有無
• 参考資料：pom.xml・依存JAR、構成図・機能一覧・障害履歴があると、調査工数を見積もりやすい

機密情報は、契約とアクセス権を整えたうえで、必要最小限だけを共有します。

まとめ：調査と段階移行によるStruts2のシステム開発

Struts2のシステム開発は、フレームワーク名だけで判断せず、既存資産と運用体制を一覧にすることから始めます。そこでは、Action・Interceptor・JSP・依存ライブラリのほか、Java、サーバ、DB、外部連携も確かめます。

要件整理から定着までの6フェーズに分け、各段階で作るものと完了の条件を決めます。

費用は現状調査、パッチ・小規模改修、更新、Spring移行、再構築で、それぞれ異なります。

根拠のない一式見積もりは受け入れず、工数・テスト範囲・移行リハーサル、保守・脆弱性対応・切り戻しを分けて比べます。

現行技術を残すか移行するかは、セキュリティ・業務停止リスク・予算・開発者確保・将来の変更量から判断します。無理のないシステム開発につながります。

▼全体ガイドの記事
・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を創業。