Strutsのシステム開発は、現行業務と資産の調査から始め、移行方式を選んだうえで、設計・テスト・段階的な稼働へと順に進みます。稼働後は、運用と改善を続けて安全に定着させます。
開発の全体像、6フェーズの進め方、費用相場と見積もりの確認点の順に説明します。
▼全体ガイドの記事
・Strutsのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Strutsのシステム開発の全体像
Strutsは業務パッケージではなく、JavaでWebアプリケーションを構築するMVCフレームワークです。業務システムは、画面、業務ロジック、データベースを中心に組み立てられます。そこへ認証、帳票、バッチ、外部APIなども組み合わせ、全体として機能します。そのため、進め方を決める際は、フレームワークの更新だけでなく、業務機能と周辺基盤も対象に含めます。
Strutsが担う役割とシステム構成
Struts 1とStruts 2で中心になるのは、次の要素です。
- Struts 1：Action、ActionForm、struts-config.xml、JSPタグライブラリの組み合わせが典型構成です。
- Struts 2：Action、Interceptor、OGNL、struts.xmlなどが中心となる構成です。
- 周辺基盤：TomcatやJBoss、OracleやPostgreSQL、Spring、Hibernateなどとの組み合わせです。
帳票ツール、夜間バッチ、外部サービスとの連携も、実際の業務システムを構成する要素です。
現行の調査では、まず画面とActionを結んだ構成図を作り、そこに参照・更新テーブル、権限、外部連携を加えます。帳票とバッチも、同じ図に含めます。たとえば、受注登録画面であれば、入力チェックから在庫引当、得意先マスタの参照、売上計上、メール通知まで追います。
エラー時のロールバックも調べます。特に、業務ルールがJavaやSQLに埋め込まれている場合は、画面を新しくしても同じルールを再現できなければ、移行は成功といえません。
新規開発と既存Struts刷新の区別
新規開発では、サポート終了とセキュリティ対応の観点からStruts 1を避けるべきです。
たとえば、Struts 1.xは2013年4月5日にEOLで、Struts 2.3.xは2019年9月12日にEOLです。さらに、Struts 2.5.xのEOL日は2023年10月30日です（出典: Apache公式「End-of-Life Versions」、2026年確認）。
既存システムの方針は、古さだけで決めず、業務価値、脆弱性、停止可能時間、移行難易度から考えます。
既存資産の方針は、次の5つの選択肢から検討します。
- 短期対応：パッチを適用し、現行の構成のまま保守を続けます。
- Struts更新：サポート対象のバージョンへ上げる方法です。
- 段階移行：機能を分けて、Spring系へ少しずつ移す方法です。
- 置き換え：SaaSやパッケージへの入れ替えです。
- スクラッチ開発：システムを新たに作り直す方法です。
標準的な業務はパッケージへ寄せ、競争優位に直結する処理だけをJavaで残すハイブリッドも現実的です。
判断では、何を使うかより先に、何年、どの体制で安全に業務を続けるかを決めます。
Strutsのシステム開発の進め方
Strutsの開発は、現行業務と技術資産に残る不確かさを減らす順番で進みます。そのうえで、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分け、フェーズごとに終了条件を決めておきます。
終了条件を確認してから次へ進めば、後工程での手戻りや追加請求を抑えられます。
1. 要件整理フェーズでの業務と現行資産の棚卸し
最初に、対象業務と利用者、処理量、繁忙期を整理します。また、停止可能時間や法令・監査の要件も押さえます。
個人情報や決済情報を扱うかも確認し、WARファイルやソースコードなどの現行資産を一覧にします。Actionや独自タグ、ライブラリを洗い出し、Java・Tomcat・DBのバージョンも棚卸しします。
工数を読むには、画面数だけでは足りません。Action数、テーブル数、外部連携数、帳票数、バッチ数も数えます。さらに、権限パターンとテストデータの有無も、工数を読むうえで確認しておきたい点です。
棚卸しでは、次の5点を確認して、その結果を成果物とあわせて残します。
- 業務フロー：画面遷移との食い違いの有無。
- バージョン：ソースコードと本番環境の版がそろっているか。
- 例外処理：担当者の頭の中だけにある処理が残っていないか。
- 外部接続：APIやEDIの接続先と認証方式の把握。
- 復旧手順：障害が起きたときの対処を再現できるかどうか。
成果物には、構成図や画面・Action一覧、連携一覧を含めます。課題・リスク一覧と現行テストの棚卸し結果も加えます。
2. 選定フェーズでの保守・移行・置換の比較
選定では、現行調査の結果をもとに、次の案と判断材料を比べます。
- 比較案：短期保守、Struts更新、Spring系移行、SaaS・パッケージ置換、スクラッチが候補です。
- 評価軸：セキュリティ、業務継続性、将来の採用・保守性、データ再利用、画面変更、期間、総保有コストで比べます。
- 脆弱性への対応：ネット公開で影響を受けるなら、安価な保守より、パッチ適用や早期移行を優先します。
- PoC対象：代表画面から難しい処理を2〜5種類選びます。候補は、入力チェック、認証、ファイルアップロード、トランザクション、帳票、外部APIです。
- PoCの確認：実装方法、変換率、テスト工数、性能を見て、画面の比較条件を合意したうえで本開発へ進みます。
変換後の結果が、業務上の期待結果と一致するとは限りません。
3. 設計・開発フェーズでの現行踏襲の範囲の確定
設計と開発では、要件を整理したうえで、移行と実装の扱いを決めます。
- 機能要件：画面、帳票、バッチ、権限、データ更新、APIを記載します。
- 非機能要件：応答時間、同時利用者数、可用性、ログ保存、バックアップ、監視、障害復旧、脆弱性対応の条件を示します。
- Spring系への移行：JSPの見た目、Actionの状態管理、Interceptor、入力値変換、エラー処理を設計し直します。
- 移行時の設計：二重送信防止とセッションの扱いも、改めて決めます。
- 開発の標準化：基盤部品と代表画面から作り始め、共通エラー処理、認証、データアクセスを、パイロット開発で固めます。
自動変換ツールを使う場合は、変換対象と手作業の対象を分けておきます。そのうえで、生成コードのレビューを、誰がどこまで受け持つかも決めます。
たとえば、シーイーシーの公開事例では、Struts 1からSpring MVCへ変換し、比較検証、運用テスト、リリースまで約6か月です（出典: 株式会社シーイーシー公開事例、確認時点2026年）。
期間は画面数や連携数で変わるため、自社へそのまま当てはめず、PoCの結果から再見積もりします。
4. テストフェーズでの現新比較と受入条件の確定
テスト計画では、現新比較と受入条件を具体的に決めます。
- テストの種類：単体、結合、システム、受入、性能、セキュリティ、障害復旧の7種を計画します。
- 現新比較：同じ入力を与えて、画面、登録データ、計算結果、帳票、外部連携の差分を調べます。
- 受入条件：業務シナリオ、合格率、重大障害の残存可否、性能基準、データ件数、権限、ブラウザ、夜間バッチ、連携先を決めます。
- テストケース：正常系に加え、入力漏れ、桁あふれ、同時更新、二重送信、タイムアウトを含めます。
- 障害確認：外部サービス停止、DB障害、権限外アクセスの場合の動きを確かめます。
TISのFintan事例では、現行ソースを全量調査したうえで、StrutsのTOKENによる二重サブミット防止などの非互換点を検討しています（出典: TIS株式会社 Fintan「StrutsからSpring MVCへのマイグレーション事例」）。その後、テスト方針と製造へ進んでいます。
業務部門が受け入れる場合は、技術用語を避けるのが基本です。たとえば、「受注を登録して出荷指示が作成される」などの業務シナリオで合意します。
5. 稼働フェーズでの切り替えと戻し方の準備
切り替え前後の準備と判断基準は、次のとおり定めます。
- 稼働前の準備：移行リハーサル、切り替え手順、担当者、開始・終了時刻、連絡網を決めます。
- 運用・個人情報：監視項目、バックアップ、ロールバック条件を定めます。扱うデータが保護対象の場合は、一時ファイル、作業者の権限、ログ、廃棄方法も計画に入れます。
- 段階移行：停止が休日の数時間だけなら、一括ではなく読み取り系や管理系から移し、旧・新データを突合します。
- 切り替え判断：予定時刻ではなく、データ件数と金額、在庫、権限、主要画面、連携、バッチの確認がすべて終わった時点で決めます。
- 戻し方：重大な差分や性能劣化が出た場合の復帰条件を決めます。戻せない場合は、経営層を含む意思決定者とリスク許容度を合意します。
6. 定着フェーズでの保守と改善の仕組み
稼働後は、問い合わせへの対応だけで終わらせず、運用と改善を定期的に回していきます。
- 定期運用：日次のバックアップ確認、ログ監視、月次の障害・性能レビューを運用に含めます。
- 更新計画：四半期ごとに脆弱性を確認し、Java・Tomcat・DB・ライブラリのバージョンアップを運用カレンダーに入れます。
- 利用部門の支援：操作マニュアル、業務別手順、エラー時の連絡先、FAQ、教育担当者を用意します。
- 保守契約：脆弱性パッチ、障害対応時間、休日対応、性能監視、軽微な改修を定めます。
- 改善指標：問い合わせ件数、処理時間、手作業削減、障害再発率、パッチ適用までの日数を毎月確認します。
特に、IPAはApache Struts 2の脆弱性について、基本的には修正パッチを適用して更新し、事前テストで動作を確かめる必要があると案内しています（出典: IPA「Apache Struts2の脆弱性対策情報一覧」、最終更新2026年1月13日）。
発注側は、開発会社との契約に、ソースコードと設計書の引き渡し範囲も明記しておきます。
Strutsのシステム開発にかかる費用相場と内訳
Struts単体の定価はありません。費用は画面やActionの数、DBの規模で変わるほか、連携や帳票、バッチ、テスト資産、停止制約、移行方式でも変わります。
次に示すのは、2026年の業務Webシステム相場、Java系エンジニアの人月単価、公開された移行期間を組み合わせた推定です。
ただし、公開されたStruts移行事例の費用は非公開です。そのため、ここでは断定額ではなく、予算を置くための目安として示します。
ケース別の費用と期間の目安
ケース別の推定レンジは、対象範囲と規模を照らして確認します。
- 現行調査・診断・PoC：100万〜300万円、1〜2か月程度
- 小規模な保守・機能追加：100万〜300万円、1〜3か月程度
- 中規模の機能追加・再構築：300万〜800万円、3〜6か月程度
- StrutsからSpring系への移行：1,000万〜3,000万円、4〜8か月程度を置くケースがあります。
- 大規模な基幹刷新：3,000万〜1億円超、6〜18か月になることもあります。
小規模の目安は、数画面で単一DB、連携も少数のケースです。一方で、中規模は複数の業務をまたぐケースです。
最初の3ケースは、2026年の小規模・中規模の業務Web開発相場を参照した推定です。さらに、診断だけか改修まで含むかでも変わります（出典: 2026年公開の業務Webシステム費用相場情報、リサーチノート整理）。
Struts移行の推定は、2〜4名が6か月稼働する想定で、Java系の人月単価は月80万〜120万円程度とします。
この金額には、要件整理、プロジェクト管理、テスト、予備工数も含まれています。
大規模刷新は、50画面以上で、複雑な権限やEDI、複数DB、並行稼働、データ移行を含む場合があります。そのため、画面数だけでなく、例外処理と連携の数も必ず加味します。
費用を構成する項目と見落としやすいコスト
見積書は作業別に分けて、別途費用になりやすい項目も確認します。
- 開発作業：要件整理・現行調査、基本設計・詳細設計、製造、データ移行
- テスト・基盤：単体・結合・総合・受入支援、インフラ構築、リリース、プロジェクト管理
- 別途になりやすい項目：脆弱性診断、性能試験、帳票再現、接続先調整
- 稼働準備・定着：休日切り替え、並行稼働、操作教育、文書整備
見積もりの総額が安く見えても、別途項目が含まれていなければ、後から追加費用が発生します。
運用保守費は、初期開発費の年15〜25%程度を仮置きすることがあります。これは、契約範囲から組み立てる予算の目安です。パッチの適用だけか、24時間監視や障害の一次対応まで含むかで変わります。
初期費用に加え、移行後3〜5年の保守、クラウド・ライセンス、診断、教育も比べます。将来のJavaやミドルウェアの更新も含めて、総保有コストを見積もります。
Strutsのシステム開発で見積もりを取るポイント
見積もりの精度は、発注前に不確かな点を洗い出せるかで決まります。
「Strutsの改修一式」とだけ書かれた見積もりでは、会社ごとに前提が異なり、価格を比べられません。
そこで、現行バージョン、画面数、Action数を同じ資料で伝えます。DB、連携先、帳票、バッチも、その資料に含めます。データ件数や停止可能時間、希望する方式も伝えたうえで、調査・PoCと本開発を分けて提案してもらいます。
RFPと現行資料に入れるべき情報
RFPと現行資料には、見積もりに必要な情報をそろえて記載します。
- 業務・処理条件：目的、背景、対象業務、利用者数、ピーク時の処理量を記載します。
- システム条件：現行と将来の構成、環境制約、セキュリティ、データ移行、テスト、稼働・保守の条件。
- 現行資料：画面一覧、業務フロー、ER図、連携仕様、帳票サンプル、障害履歴、テストケース、ソース提供範囲をそろえます。
- 情報共有：機密情報があれば秘密保持契約を結び、必要最小限だけを渡します。
- 調査成果物：構成図、依存ライブラリ、脆弱性の影響、移行方式、PoC、課題、概算工数、次の見積条件を含めます。
要件が未確定なら、固定価格の本開発をすぐには求めず、現行調査を準委任などの調査フェーズとして発注します。
あわせて、調査の終了条件を決めておけば、調査だけで終わってしまう事態を避けられます。
開発会社を比較するときの質問
候補会社には、経験や調査力、移行・保守の体制を具体的に質問します。
- 経験・調査力：Struts 1・2の資産、Action、JSP、設定ファイル、独自基盤を扱えるかどうか。
- 移行実績：Spring MVC・Spring Bootの事例を尋ね、匿名化した工程と成果物を確かめます。
- 体制・責任：担当者の経験年数、脆弱性対応、現新比較、データ移行で誰がどこまで受け持つか、稼働後保守。
- 契約・成果物：ソースコードと設計書を、どこまで引き渡すか。
- 提案比較：金額、調査の深さ、前提、除外項目、追加単価、納期、テスト範囲、障害責任、終了時の引き継ぎを並べて比べます。
たとえば、「テスト一式」と書かれていても、単体だけか、現新比較や性能、脆弱性、受入支援まで含むかで意味が変わります。
前提が明確で、リスクと対策を説明できる提案は、最安値の提案より総額を管理しやすくなります。
移行・刷新で起きやすいリスクと対策
移行・刷新では、業務の把握、切り替え、セキュリティに関わるリスクを確認します。
- 現行把握：仕様の未文書化、埋もれた業務ルール、属人化した例外処理を洗い出します。
- 移行・切り替え：テストデータ不足、接続先の変更制約、短い停止時間、旧環境へ戻せないリスクを確認します。
- 事前検証：業務部門と要件を整理し、代表画面のPoCや現新比較用の正解データ、連携先とのリハーサルを用意します。
- セキュリティ確認：Struts、Java、Webコンテナ、ライブラリ、OS、DB、認証、ファイルアップロード、ログを点検します。
- ネットワークと権限：外部公開だけで判断せず、社内網、委託先接続、バックアップ、管理画面の権限も評価します。
Apache公式は、EOL版にセキュリティパッチやバグ修正を提供しないと説明しています（出典: Apache Struts公式「End-of-Life Versions」、2026年確認）。
Strutsのシステム開発でよくある質問
Strutsの開発では、技術の古さだけでなく、業務を安全に維持できるかと、どの範囲を移行するかが問われます。
費用をどの根拠で決めるかも、よく問われます。特に判断に迷いやすい3つの質問に、ここで直接答えます。
Strutsは2026年に新規開発で使えますか？
Struts 1やEOLのStruts 2.3・2.5は、新規開発で避けるべきです。
- 現行版：2026年確認時点で、Apache公式ダウンロードページはStruts 7.2.1や6.10.0などを案内しています。
- 互換性：採用時はJavaやWebコンテナとの適合、サポート方針、脆弱性情報を確かめます。
- 判断区分：既存資産の短期保守と、新規システムの技術選定は別々に考えます。
StrutsからSpringへ移行するときは全て作り直しますか？
すべてを一度に作り直す必要はなく、段階的に移行する方法があります。
- 現行調査：業務ルール、画面、データ、連携を分けて捉えます。
- 再利用判断：変換ツールや共通部品で再利用する部分と、手作業で設計し直す部分を分けます。
- 段階移行：読み取り系や利用頻度の低い機能から移し、現新比較と利用部門の受け入れを繰り返します。
Strutsのシステム開発費用はどうすれば正確に出せますか？
見積もりの精度を上げるには、資産と作業範囲を具体化したうえで、調査結果をもとに推定額を更新します。
- 提示する資産：画面、Action、DBテーブル、外部連携、帳票、バッチ、権限を伝えます。
- 提示する条件：データ移行、テスト、停止制約を伝え、現行調査とPoCを先に行います。
- 見積もりの確認：含む・含まない項目、前提、追加変更、検収条件、保守範囲を確認します。
- 推定レンジ：小規模100万〜300万円、中規模300万〜800万円、Struts移行1,000万〜3,000万円を出発点にします。
まとめ：6フェーズで判断するStrutsのシステム開発
Strutsの開発は、要件整理、選定、設計開発、テスト、稼働、定着の順で進みます。各フェーズの終了条件を確かめながら、現行資産と業務ルールを踏まえて方針を選びます。
既存のStrutsでは、バージョンと脆弱性に加えて、画面やAction、JSP、DB、連携を棚卸しします。さらに、帳票やバッチ、業務ルール、テスト資産も調べ、保守・更新・Spring移行・パッケージ置換を比べます。
着手前に確認する最終チェックリスト
着手前に確認し、提案書へ記載してもらう事項を整理します。
- 現行環境：バージョンとEOL状況、停止可能時間、資産の規模を把握します。
- 資産調査：画面・Action・DB・連携・帳票・バッチの数を確認し、代表画面でPoCを行います。
- 提案条件：移行方式、テスト、データ移行、ロールバック、セキュリティ、保守体制を明記してもらいます。
- 費用比較：推定レンジを起点に、調査・設計・開発・テスト・稼働後保守を分けて比べます。
最初の一歩は現行調査と小さな相談
全面刷新を急いで決める前に、判断に必要な材料を少しずつそろえていきます。
- 構成資料と課題を集め、開発会社へ現行調査とPoCの範囲を相談します。
- 業務価値、セキュリティ、移行難易度、3〜5年の総保有コストを比べます。
- 現場、情報システム部門、経営層で同じ終了条件を決めます。
▼全体ガイドの記事
・Strutsのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。