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

Strutsのシステム開発とは、画面からの要求を受けて業務処理を行い、結果を返す仕組み全体を作ることです。

刷新を考えるなら、業務要件と既存資産、セキュリティリスクを確認し、段階的に進めると業務を守りながら移行できます。

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

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

Strutsのシステムの全体像

Strutsのシステムでは、利用者のブラウザからのリクエストを受け取り、入力値を確認したうえで業務処理を実行します。

処理の結果は、画面やAPIとして返されます。

フレームワークの名前だけでは、規模や費用は判断できません。

判断には、画面、データ、連携、運用まで含めて全体を把握します。

Strutsの位置づけ：業務パッケージではなくMVCフレームワーク

Strutsは、画面表示と業務処理を分けて整理しやすくするJava向けのWebフレームワークです。MVCという考え方では、画面、リクエスト、業務データの役割をそれぞれ分けます。

• View：画面表示を担当します。
• Controller：利用者の検索リクエストを受け、指定Actionへ処理を振り分けます。
• Model：業務データや処理を担当します。
• 処理の流れ：入力値を検証し、業務ロジックとDB処理を経てJSPなどへ返します。

「Strutsのシステムを導入する」と決めただけでは、必要な機能は決まりません。たとえば、受発注、会員管理、保険といった業務ごとに、必要な機能を定義します。

在庫や販売管理の業務も対象になります。

Struts以外のJavaコードやデータベースに加えて、帳票、バッチ、認証、外部APIも設計して、初めて利用できるシステムになります。

画面・業務処理・データ・連携の一体的な把握

全体像をつかむには、基本構成、追加機能、棚卸し項目を一体で見ていく必要があります。

• 基本構成：ブラウザ、Webコンテナ、ActionやInterceptor、Java業務ロジック、データアクセス層、DB
• 追加機能：帳票、ファイル、メール、バッチ、認証基盤、APIやファイル連携
• 棚卸し項目：画面、Action、権限の組み合わせ、DBテーブル、夜間バッチ、帳票、連携先
• 利用状況：月間利用者数、ピーク時の同時実行数

古い業務システムでは、業務ルールが設定ファイル、JSP、SQLに分かれて書かれていることがあります。そのため、ソースコードだけを読んでも、仕様を再現できない場合があります。

現行資産の洗い出しが足りないと、小規模に見えた案件でも、テストや移行の段階で費用が大きく膨らみます。

Strutsの種類とシステム構成の違い

Strutsのシステムを調べるときは、Struts 1とStruts 2を分けて確認します。

名前は似ていても、Action、設定、入力値の扱い、Interceptorの考え方は異なります。

バージョンは画面の表示だけで判断せず、依存JAR、ビルド設定、実行環境の設定を照らし合わせます。

版の違いによって、移行の難しさも変わります。

Struts 1とStruts 2の違い

Struts 1とStruts 2では、中心となる部品と、動きを決める設定ファイルが変わります。

• Struts 1：Action、ActionForm、struts-config.xml、JSPタグライブラリが中心です。
• Struts 1の注意点：入力フォーム、画面遷移、検証が、設定ファイルや共通クラスに結び付いている点です。
• Struts 2：Action、Interceptor、OGNL、struts.xmlが中心で、設定や入力値の評価方式も異なります。

画面単位で変換しただけでは、動作を再現できない場合があります。

別のフレームワークへ移す場合も、変換率だけで判断せず、認証と権限、二重送信防止、例外処理、ファイル処理を個別にテストします。

新規開発と既存システムの刷新の切り分け

新規構築と既存資産の継続利用では、業務への影響も、更新の選択肢も異なります。

• 新規開発：Struts 1は2013年4月5日にサポートが終了しています。
• 既存Struts 2：旧版のまま使い続けるより、サポート対象版への更新を検討します。
• 刷新案：別フレームワークへの段階移行、パッケージやクラウドへの置換を比べます。
• 判断軸：業務価値、セキュリティリスク、移行難易度、停止可能時間。

既存システムが安定稼働し、業務固有のルールが多い場合は、短期間で全面再構築できないことがあります。

全面再構築が難しいときは、調査と脆弱性対応を先に行い、段階的に刷新する判断も現実的です。

Struts 1は、脆弱性修正や最新実行環境との互換性を期待できません。

Strutsの現行サポート状況と脆弱性

Strutsは、現行のサポート対象版であれば利用できます。ただし、旧版を無条件に使い続けてよいわけではありません。

Apache Struts公式の2026年リリース情報では、7.2.1が2026年6月15日、6.10.0が2026年5月25日に公開されています。

更新できるかは、Strutsだけでなく、Java、Webコンテナ、ライブラリ、データベース、認証基盤も含めて検証します。

EOLのバージョンと移行期限の決め方

EOLを確認した後は、停止か移行かを急いで決めず、リスクと対応策を順に見ていきます。

• 対象版：Struts 1と2.3はサポート終了済みです。2.5系は2023年10月30日にEOL方針が示されました。
• 業務リスク：公式の修正パッチを前提にできず、公開範囲やデータによっては経営リスクになります。
• 影響確認：外部公開の有無、個人情報・決済情報、脆弱性の影響範囲、代替経路を調べます。
• 対応策：バックアップと復旧可能性を確認し、緊急パッチ、制限、監視、PoC、段階リリースを組み合わせます。

EOLが分かった日にすぐ業務を止めて全面移行する必要があるとは限りません。そこで、対応の期限と責任者を決め、緩和策と移行計画を合わせて管理します。

脆弱性対応：バージョンと影響範囲の切り分け

IPAの「Apache Struts2の脆弱性対策情報一覧」では、2026年1月13日にS2-069が追記されています。

S2-069は、XWorkコンポーネントのXXE脆弱性です。

影響範囲には、Struts 2.0.0〜2.3.37、2.5.0〜2.5.33、6.0.0〜6.1.0が含まれます。

対策としては、少なくとも6.1.1への更新が案内されています（出典: IPA、2026年1月13日）。

脆弱性の影響は、バージョンだけでは判断できません。外部から届く経路や、処理されるデータも確認します。

• 攻撃経路：外部から到達できるか、XML受信機能が有効かを調べます。
• 処理とデータ：認証前に処理されるか、個人情報へ到達できるか。

修正後は、入力値、権限、ファイル、エラーをテストします。ログ、性能、ロールバックも確認の対象です。IPAも更新前の動作確認を案内しており、パッチを当てただけでは完了とは考えません。

Strutsのシステム開発・移行の5段階の進め方

Strutsの刷新は、まず現行仕様を整理し、リスクを判定します。次に、PoCで方式を検証し、方式を決めてから段階リリースへ進みます。

現行どおり動かす必要がある業務では、画面の見た目より、計算、権限、締め処理、データ整合性を先に守ります。

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

1. 現行資産と業務ルールの棚卸し

調査では、次の資産、業務ルール、運用情報を集め、記録に残します。

• 技術資産：ソース、WAR、設定、JSP、Action、Form、Interceptor、独自タグ、依存ライブラリ
• 実行環境：ビルド手順と実行環境
• 画面情報：利用者、権限、入力項目、遷移先、エラー表示、帳票、CSV、添付ファイル
• 業務・運用：テーブル、バッチ、外部連携、ジョブ、監視、バックアップ、障害時の手作業
• 調査成果物：構成図、画面・Action一覧、連携一覧、リスク一覧、未解明事項

仕様書が足りない場合は、現場へのヒアリングに加えて、アクセスログ、テストデータ、問い合わせ履歴を照らし合わせます。

締め日だけの処理、特定権限の操作、画面に出ない自動計算は、移行後の障害につながりやすい項目です。

2. 代表機能による移行PoC

単純な一覧画面だけに偏らず、難しい代表機能を少数選んで、次の観点で確認します。

• 対象機能：入力・検証、認証・認可、ファイル、トランザクションを含めます。
• 連携・画面：帳票、外部API、二重送信防止を含む画面を選びます。
• 動作確認：同じ入力で同じ計算結果になるか、権限外操作を拒否するかを調べます。
• 異常時：異常が起きたとき、データが中途半端に登録されないか。
• 成果物：変換・手作業の範囲、テスト工数、未移行機能、実行環境を明記します。

自動変換できた行数だけで、成功率は判断しません。PoCでは、手作業の量と必要なテストケースも測ります。

3. 5つの選択肢の比較と方針決定

方針を決めるときは、次の5案を比べます。そのとき、方式ごとの業務適合度と移行負担も見ます。

• 短期のパッチと保守：現行システムを維持し、パッチで対応
• Strutsの更新：既存業務を維持したままの更新
• 段階移行：Spring MVCやSpring Bootなどへの段階的な移行
• パッケージ置換：SaaSや業務パッケージへの置き換え
• スクラッチ開発：新規でのシステム開発

比較の軸は、費用と期間だけではありません。業務適合度、停止時間、データ移行、操作変更が並びます。さらに、将来の保守性、セキュリティ、社内運用体制も含まれます。

販売、勤怠、在庫など標準化しやすい業務はパッケージに寄せ、競争優位につながる固有業務だけを個別に開発する構成も候補になります。

画面を変えたくない場合は段階移行を、業務そのものを変えたい場合は要件から設計し直します。技術の方式と業務改革の範囲は、分けて考えます。

4・5. テストと段階リリースによる業務保護

テストからリリースまで、業務への影響を抑えるための確認事項を順に整えます。

• テスト工程：単体、結合、総合、受入を分け、現行比較用データを用意します。
• 業務シナリオ：月次・年次、同時更新、権限、異常終了、再実行の検証。
• 出力・連携：帳票の合計や、外部連携の再送の確認。
• 段階リリース：影響の小さい機能から出し、一部部門で並行稼働します。
• 移行準備：件数・金額・状態を突合し、切り戻し条件や責任者、連絡網、復旧手順を定めます。

テストケースは、画面数だけでなく、権限、分岐、データ状態の組み合わせによっても増えます。

クラウド移行では、コンテナやCI/CDの仕組みを要件に含めます。依存ライブラリのスキャン、集中ログ、バックアップ、監視、ロールバックも、同じ要件の中で扱います。

Strutsのシステム開発・移行にかかる費用相場と内訳

Struts単体の料金表は、ほとんど見当たりません。そのため、ここに示す金額は、2026年の業務Webシステム相場、Java系人月単価、移行工程の公開情報から組み立てた推定です。

費用は、画面数、Action数、帳票、バッチ、連携で変わり、テスト資産や停止制約も左右します。税込・税別や作業範囲は見積もりごとに異なるため、見積書の条件をそろえて比べます。

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

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

規模別の費用と期間の目安

規模や作業条件によって、費用と期間の目安は次のように変わります。

• 調査・診断・PoC：100万〜300万円、1〜2か月。
• 小規模保守・追加：100万〜300万円、1〜3か月。数画面、単一DB、少連携が前提です。
• 中規模の追加・再構築：300万〜800万円、3〜6か月。複数業務、権限、帳票、API連携を含みます。
• Struts 1からSpring MVC・Boot：1,000万〜3,000万円、4〜8か月。
• 大規模基幹など：3,000万〜1億円超、6〜18か月となることがあります。

大規模基幹の例では、EDI、複数DB、並行稼働、複雑なデータ移行が含まれる場合があります。

2026年公開の一般的な業務Webの相場は、小規模で100万〜300万円、中規模で300万〜800万円、大規模で800万円〜数千万円です（出典: 2026年公開のシステム開発費用相場調査）。

JavaやSpring Bootの人月単価を80万〜120万円と仮定します。たとえば、2〜4名が6か月稼働すると、技術者工数だけで960万〜2,880万円になります。

要件定義、管理、環境構築、移行、総合テスト、予備工数も加わります。そのため、Struts移行の推定額は小規模開発より高くなります。

初期費用以外のコストの合算

初期費用以外も含めて、運用開始後までの支出を次の項目で見積もります。

• 初期準備：調査、ライセンス、クラウド・サーバー、監視、診断、データ移行
• 導入付帯：教育、マニュアル、立ち会い、旧環境の並行稼働、運用引き継ぎ
• 参考額：保守・運用費は初期開発費の年15〜25％程度で仮置きする場合があります。
• 総保有コスト：旧版維持費と移行後運用費を3〜5年で比べます。

移行後は、Java、Webコンテナ、データベースの更新やパッチ適用が要ります。加えて、バックアップ、障害対応、問い合わせを含む保守費も見積もります。

年15〜25％は、契約範囲を決めるための参考値です。24時間監視や休日対応、脆弱性対応を含めるかどうかで、費用は変わります。

Strutsのシステム開発会社・ベンダーの選び方

開発会社は、Javaに対応できるかだけでなく、既存Strutsの調査、脆弱性対応、移行後の保守、業務テストを任せられるかで選びます。

知名度よりも、担当者が現行資産を読み解き、リスクと前提を見積書に書き、業務部門と技術部門をつなげられるかを見ます。

Strutsの実績の確かめ方：技術名より証拠

「Javaに対応できます」という答えでは、Strutsの実績は確かめられません。過去の案件で何を扱い、何を任されたかを聞くと、本当に手がけたかどうかが見えてきます。

• 対象バージョン：Struts 1または2のどの版を扱ったか。
• 調査経験：Action、JSP、設定ファイル、独自タグをどう調べたか。
• 移行経験：Spring系への移行や現行踏襲を経験したか。
• 担当体制：担当予定者が参加でき、テストや保守を説明できるか。
• 提案範囲：調査と本開発、変換ツールと手作業を分けているか。

公開事例がない場合は、守秘義務に配慮したうえで、規模、課題、期間、テスト方法、移行後の保守を説明できるかを見ます。

テストデータと受入基準も確かめます。現行コードを読まずに画面単価で一律に出した提案は、追加費用が生じやすいため注意が要ります。

同じ条件での見積もりと体制の比較

相見積もりでは、各社に同じ資料で次の条件を伝え、見積もりと体制を比べます。

• 対象範囲：版、画面・Action・テーブル数、連携、帳票、バッチ
• 前提条件：利用者数、現行テスト、停止可能時間、希望移行先
• 費目：要件定義、設計、製造、テスト、移行、教育、管理、保守
• 契約条件：成果物、検収、変更、障害・脆弱性の責任、再委託
• 権利・終了時：著作権、ライセンス、データ返却、契約終了時の引き継ぎ

準委任と請負のどちらが良いかは、一概には言えません。調査は準委任、仕様が確定した後の開発は請負など、不確実性に合わせて設計します。

移行後の保守体制と知識の引き継ぎ

運用後の窓口と担当範囲を決め、知識を発注者側にも引き継げる体制にします。

• 問い合わせ：窓口と、障害の一次切り分けの担当。
• 運用作業：脆弱性情報、パッチ、性能監視、復元、開発環境の再構築ごとの担当。
• 納品物：構成図、依存関係、リリース・テスト手順、既知の制約。
• 共有記録：発注者が、コードの保管場所や課題、レビュー、脆弱性履歴を参照できる状態。
• 定期報告：月次で未対応リスクと次回の更新時期を確認します。

刷新直後は、移行元と移行先の差分に関する問い合わせが増えがちです。担当者の経験だけに頼ると、退職や異動で再びブラックボックス化します。

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

Strutsのシステム刷新で起きやすい失敗と対策

技術の変換ばかりに目が向くと、業務ルール、データ品質、利用者の手順、運用責任が抜け落ちます。そのため、失敗のパターンを把握し、要件、テスト、契約、体制の各段階に対策を組み込みます。

技術だけの置き換えによる業務テストの不足

自動変換でコンパイルが通ると、移行が終わったように見えることがあります。ただし、別のフレームワークでは挙動が変わる可能性もあります。

現行画面と移行後画面を比べるだけでは足りません。業務シナリオ単位の受入テストを行い、次の項目を検証します。

• 入力・権限：入力値の境界、権限の組み合わせ、二重送信防止
• 業務処理：締め処理や外部連携の再送
• 出力：帳票における端数
• 受入準備：重要業務の期待結果の決定と、代表データの固定

受入には業務部門も加わり、金額、件数、状態遷移、帳票を突き合わせます。不具合の業務への影響と優先度を共有しておくと、リリースの判断がしやすくなります。

全面刷新による範囲の拡大と予算・期間の超過

範囲を抑えて段階的に進めるため、次の点を計画と見積もりに反映します。

• 変更範囲：セキュリティ、現行機能、業務改善を分け、優先順位と予算を段階ごとに決める。
• 見積前提：未確定事項、前提、除外範囲、追加変更単価、予備工数の明記
• 不明点：調査やPoCの先行と、結果をもとにした本開発の契約見直し
• 経営判断：費用、停止、脆弱性、担当者不足による保守リスクを同じ表での比較

更新と同時に、画面、業務ルール、DB、認証、帳票、クラウドまで変えると、問題の原因を切り分けにくくなります。

Strutsのシステムに関するよくある質問

自社のバージョンや構成が分からないときは、現行調査で事実を確かめるところから始めます。

Strutsは新規のシステム開発に使えますか？

Struts 1を新規開発に使うことは、推奨できません。サポートが終了しており、将来の脆弱性対応や実行環境との互換性に不確実性があるためです。

新規開発では、現行のサポート方針やセキュリティ更新、開発者の確保、保守期間を確かめられる技術を選びます。

既存のStrutsシステムはすぐに廃棄すべきですか？

すぐに廃棄するより前に、バージョン、脆弱性、外部公開範囲、業務の重要度、移行の難易度、停止可能時間を調べます。

EOLや重大な脆弱性があり、外部から到達できる場合は、緊急度が高くなります。その場合は、短期の緩和策と移行PoCを並行する方法もあります。

切り戻しの手順を用意したうえで、段階的に刷新する選択肢もあります。

Strutsの移行費用はどのくらいかかりますか？

作業の規模によって、費用の目安は大きく変わります。

• 小規模な保守や機能追加：100万〜300万円
• 現行調査やPoC：100万〜300万円
• Struts 1からSpring系への移行：1,000万〜3,000万円
• 大規模基幹の刷新：3,000万〜1億円超

これは、公開相場と人月単価から算出した推定です。実際の金額は、規模と作業条件によって変わります。

規模では、画面数と連携、帳票、バッチが効きます。作業条件では、データ移行、テスト、停止制約が効きます。

開発会社やベンダーには何を伝えればよいですか？

見積もりと調査に必要な情報を、次のように整理して伝えます。

• 環境：Struts、Java、Webコンテナの各バージョン
• システム規模：画面、Action、DB、帳票、バッチ、外部連携
• 利用・移行条件：ユーザー数、ピーク負荷、現行テスト、停止可能時間、希望移行先
• 共有資料：ソース、設定、構成図、画面一覧、障害履歴

資料を共有できると、調査と見積もりの精度が上がります。不明な項目はそのまま伝え、調査工程の提案を求めます。

まとめ：Strutsのシステムの調査と段階的な判断

判断で押さえるべき3つのポイント

Strutsのシステムは単体の製品ではなく、業務基盤です。画面やデータベースに加え、帳票、バッチ、外部連携まで組み合わせて成り立っています。

新規開発でStruts 1を選ぶべきではありません。既存システムについては、業務価値とリスクを確認したうえで判断します。

パッチ、サポート対象版への更新、Spring系への段階移行、パッケージ置換、再構築を比べて考えます。

最初に着手するチェック項目

刷新を始めるときは、現状調査から会社選びまでを、次の順に確かめます。

• 現状把握：バージョン、依存関係、画面、Action、データ、連携、運用の棚卸し。
• リスク判定：脆弱性と停止リスクの確認。
• 方式検証：難しい代表機能でPoCを行い、費用、期間、テスト工数、データ移行、保守体制を具体化します。
• 会社選び：調査実績、受入テスト、知識継承、契約と成果物の範囲の確認。

調査・PoCは100万〜300万円、Struts 1からSpring系への移行は1,000万〜3,000万円などが目安です。

これらは公開価格ではなく、前提付きの推定です。画面数や連携数を整理し、複数の提案を同じ条件で比べれば、予算とリスクを管理しやすくなります。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・【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を創業。