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

Strutsのシステムとは、Apache Strutsを画面とリクエスト処理の中心に使い、Java・データベース・Webサーバーなどを組み合わせて業務を動かすWebシステムです。Struts自体は販売管理や在庫管理のパッケージではなく、業務機能を組み立てるMVCフレームワークです。

既存システムの保守や刷新を検討している方は、「Strutsは古いからすぐ廃棄する」「最新バージョンへ上げれば問題ない」と単純に判断すると、業務停止や予算超過を招く可能性があります。本記事では、Strutsのシステムの全体像、種類、費用相場、移行の進め方、開発会社・ベンダーの選び方、セキュリティ、FAQまでを、2026年時点の情報に基づいて整理します。

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

Strutsのシステムとは？全体像をわかりやすく解説します

Strutsのシステムは、利用者のブラウザから届いたリクエストを受け取り、入力値を確認し、業務処理を実行し、結果を画面やAPIで返す構成です。フレームワークだけを見ても実際の規模や費用は判断できないため、画面、データ、連携、運用まで含めて全体を把握することが重要です。

Strutsは、画面表示と業務処理を整理しやすくするためのJava向けWebフレームワークです。MVCは、画面を担当するView、リクエストや状態を扱うController、業務データや処理を担当するModelに役割を分ける考え方です。利用者が検索ボタンを押すと、コントローラーが指定されたActionへ処理を振り分け、入力値を検証し、業務ロジックとデータベース処理を経て、結果をJSPなどの画面へ返す流れが基本になります。

そのため、「Strutsのシステムを導入する」という表現だけでは、必要な機能は決まりません。受発注、会員管理、保険、在庫、販売管理などの業務要件を定義し、Struts以外のJavaコード、データベース、帳票、バッチ、認証、外部APIを設計して初めて、利用できるシステムになります。

典型的な構成では、ブラウザの画面、Webコンテナ、StrutsのActionやInterceptor、Javaの業務ロジック、データアクセス層、データベースが連携します。さらに、帳票出力、ファイルアップロード、メール、バッチ処理、認証基盤、他システムとのAPIやファイル連携が加わります。古い業務システムでは、設定ファイルやJSP、SQLに業務ルールが分散していることも多く、ソースコードだけでは仕様を再現できない場合があります。

棚卸しでは、画面数だけでなく、Action数、権限の組み合わせ、データベースのテーブル数、夜間バッチ、帳票の種類、連携先、月間利用者数、ピーク時の同時実行数まで記録します。ここを省くと、見積もり時は小規模に見えた案件が、テストと移行の段階で大きく膨らみます。

Strutsの種類とシステム構成の違いを理解します

Strutsのシステムを調べる際は、Struts 1とStruts 2を分けて確認します。名称が似ていても、Action、設定、入力値の扱い、Interceptorなどの考え方が異なり、移行の難しさも変わります。バージョン確認では、画面に表示される情報だけでなく、依存JAR、ビルド設定、実行環境の設定を照合します。

Struts 1では、Action、ActionForm、struts-config.xml、JSPタグライブラリを中心とした構成がよく見られます。入力フォームの定義、画面遷移、バリデーションが設定ファイルや共通クラスに結び付いているため、画面単位の変換だけでは動作を再現できないことがあります。

Struts 2では、ActionとInterceptor、OGNL、struts.xmlなどが中心になります。設定や入力値の評価方式が異なるため、Struts 1からStruts 2へ、または別のフレームワークへ移す場合は、変換率だけでなく、認証、権限、二重送信防止、例外処理、ファイル処理を個別にテストする必要があります。

新規システムでStruts 1を採用する選択肢はありません。Struts 1は2013年4月5日にサポートが終了しており、脆弱性修正や最新の実行環境との互換性を期待できないためです。既存Struts 2についても、旧版をそのまま使い続けるのではなく、サポート対象バージョンへの更新、別フレームワークへの段階移行、業務パッケージやクラウドサービスへの置換を比較します。

一方、既存システムが安定稼働し、業務固有のルールが多く、短期間に全面再構築できない場合は、調査と脆弱性対応を先に行い、段階的に刷新する判断も現実的です。技術名だけで廃棄を決めず、業務価値、セキュリティリスク、移行難易度、停止可能時間を並べて判断します。

Strutsは現在も使える？サポート状況と脆弱性を確認します

結論として、Strutsは現行のサポート対象版であれば利用できますが、旧版を無条件に使い続けてよいわけではありません。Apache Struts公式の2026年のリリース情報では、7.2.1が2026年6月15日、6.10.0が2026年5月25日に公開されています。実際の更新可否は、StrutsだけでなくJava、Webコンテナ、ライブラリ、データベース、認証基盤を含めて検証します。

Struts 1はEOLであり、Struts 2.3もサポート終了済みです。Struts 2.5系も2023年10月30日にEOL方針が示されています。EOL版では、問題が見つかっても公式の修正パッチを受け取れる前提がなく、公開範囲や扱うデータによっては重大な経営リスクになります。

ただし、EOLを確認した当日に業務を止めて全面移行する必要があるとは限りません。まず外部公開の有無、個人情報や決済情報の有無、脆弱性の影響範囲、代替経路、バックアップと復旧可能性を確認します。そのうえで、緊急パッチ、アクセス制限、監視強化、移行PoC、段階リリースを組み合わせ、期限と責任者を決めます。

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、方式決定、段階リリースの順で進めます。現行踏襲が必要な業務では、画面の見た目よりも、計算、権限、締め処理、データ整合性を先に守ることが成功の条件です。

最初に、ソースコード、WAR、設定ファイル、JSP、Action、Form、Interceptor、独自タグ、依存ライブラリ、ビルド手順、実行環境を集めます。画面一覧には、利用者、権限、入力項目、遷移先、エラー表示、帳票、CSV、添付ファイルを記録します。さらに、データベースのテーブル、バッチ、外部連携、ジョブ、監視、バックアップ、障害時の手作業も整理します。

仕様書が不足している場合は、現場担当者へのヒアリングとアクセスログ、テストデータ、問い合わせ履歴を照合します。特に、締め日だけ実行される処理、特定の権限だけ使える操作、画面には表示されない自動計算は、移行後の障害につながりやすい部分です。調査成果物として、構成図、画面・Action一覧、連携一覧、リスク一覧、未解明事項を残します。

次に、単純な一覧画面だけでなく、難しい代表機能を選びます。入力とバリデーション、認証・認可、ファイルアップロード、トランザクション、帳票、外部API、二重送信防止を含む画面を少数選定し、移行後に必要な手作業とテストケースを測定します。自動変換できる行数だけで成功率を判断しないことがポイントです。

PoCでは、画面が表示されるかだけでなく、同じ入力に対して同じ計算結果になるか、権限外の操作を拒否できるか、異常時にデータが中途半端に登録されないかを確認します。PoCの成果物には、変換可能な範囲、手作業の範囲、テスト工数、移行できない機能、必要な実行環境を明記します。

方針は、(1)短期のパッチと保守、(2)既存業務を維持したStrutsの更新、(3)Spring MVCやSpring Bootなどへの段階移行、(4)SaaSや業務パッケージへの置換、(5)新規スクラッチ開発の5案で比較します。比較軸は、費用と期間だけではありません。業務適合度、停止時間、データ移行、操作変更、将来の保守性、セキュリティ、社内運用体制を並べます。

標準化できる販売、勤怠、在庫などはパッケージへ寄せ、競争優位につながる固有業務だけを個別開発するハイブリッド構成も候補です。画面を変えたくない場合は段階移行、業務自体を変えたい場合は要件から再設計するなど、技術方式と業務改革の範囲を混同しないようにします。

開発では、単体テスト、結合テスト、総合テスト、受入テストを分け、現行と移行後の結果を比較できるデータを用意します。特に、月次・年次処理、同時更新、権限別メニュー、異常終了、再実行、帳票の合計、外部連携の再送を検証します。テストケースは画面数に比例するだけでなく、権限や分岐、データ状態の組み合わせで増えます。

リリースは、読み取り系や管理系など影響範囲が小さい機能から始め、一部部門で並行稼働します。移行前後の件数・金額・ステータスを突合し、切り戻し条件、責任者、連絡網、復旧手順を決めます。クラウドへ移す場合は、コンテナ、CI/CD、依存ライブラリのスキャン、集中ログ、バックアップ、監視、ロールバックも要件に含めます。

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

Struts単体の料金表はほとんどないため、以下は2026年の業務Webシステム相場、Java系エンジニアの人月単価、移行工程の公開情報から組み立てた推定です。実際の費用は、画面数、Action数、帳票、バッチ、連携、テスト資産、停止制約で大きく変わります。金額は税込・税別や作業範囲が異なるため、見積書の条件を揃えて比較します。

現行調査・脆弱性診断・移行PoCは、100万〜300万円、期間は1〜2か月が目安です。数画面、単一データベース、連携が少ない保守や機能追加は100万〜300万円、1〜3か月程度です。複数業務、権限、帳票、API連携を含む中規模の機能追加や再構築は300万〜800万円、3〜6か月程度を見込みます。

Struts 1からSpring MVCやSpring Bootへ移行する場合は、1,000万〜3,000万円、4〜8か月程度が一つの目安です。大規模基幹、EDI、複数データベース、並行稼働、複雑なデータ移行を含む場合は3,000万〜1億円超、6〜18か月になることがあります。2026年公開の一般的な業務Webシステム相場でも、小規模100万〜300万円、中規模300万〜800万円、大規模800万円〜数千万円というレンジが示されています（出典: 2026年公開のシステム開発費用相場調査）。

なお、JavaやSpring Bootのエンジニア単価を月80万〜120万円と仮置きし、2〜4名が6か月稼働すると、技術者工数だけで960万〜2,880万円になります。ここへ要件定義、プロジェクト管理、環境構築、移行、総合テスト、予備工数が加わるため、Struts移行の推定レンジが一般的な小規模開発より高くなります。

費用は開発費だけではありません。現行調査、ライセンス、クラウドやサーバー、監視、脆弱性診断、データ移行、教育、マニュアル、リリース立ち会い、旧環境の並行稼働、運用引き継ぎを分けて確認します。移行後は、Java・Webコンテナ・データベースの更新、パッチ適用、バックアップ、障害対応、問い合わせを含む保守費も必要です。

保守・運用費を初期開発費の年15〜25％程度で仮置きすることもありますが、これは契約範囲を決めるための参考値です。24時間監視や休日対応まで含めるか、脆弱性対応を別見積もりにするかで変わります。旧版を維持する場合の診断・個別対応費と、移行した場合の運用費を3〜5年の総保有コストで比較します。

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

開発会社やベンダーは、Javaを扱えるかだけでなく、既存Strutsの調査、脆弱性対応、移行後の保守、業務テストまで任せられるかで選びます。個社名の知名度より、担当者が現行資産を読み、リスクと前提を見積書に書き、業務部門と技術部門をつなげられるかを確認します。

「Javaに対応できます」という説明だけでは不十分です。Struts 1または2のどのバージョンを扱ったか、ActionやJSP、設定ファイル、独自タグをどう調査したか、Spring系への移行や現行踏襲を経験したか、担当予定者が同席できるかを尋ねます。公開できる事例がなければ、守秘義務に配慮した範囲で、規模、課題、期間、テスト方法、移行後の保守体制を説明できるか確認します。

提案内容は、調査フェーズと本開発を分けているか、変換ツールの適用範囲と手作業の範囲が明示されているか、テストデータと受入基準が定義されているかを見ます。現行コードを十分に読まずに一律の画面単価を出す提案は、後から追加費用が発生しやすいため注意が必要です。

相見積もりでは、Strutsのバージョン、画面数、Action数、テーブル数、外部連携、帳票数、バッチ、ユーザー数、現行テストの有無、停止できる時間、希望する移行先を同じ資料で伝えます。見積書は、要件定義、設計、製造、テスト、移行、教育、管理、保守の費目に分けてもらいます。

契約では、成果物の範囲、検収条件、追加変更の扱い、障害の定義、脆弱性が見つかったときの責任分担、再委託、ソースコードと著作権、第三者ライブラリのライセンス、データ返却、契約終了時の引き継ぎを確認します。準委任と請負のどちらかだけで良し悪しを決めず、調査は準委任、仕様確定後の開発は請負など、作業の不確実性に合わせて設計します。

刷新直後は、移行元と移行先の差分に関する問い合わせが増えます。運用開始後の問い合わせ窓口、障害の一次切り分け、脆弱性情報の確認、パッチ適用、性能監視、バックアップ復元、開発環境の再構築手順を誰が担当するかを決めます。保守担当者が変わっても対応できるよう、構成図、依存関係、リリース手順、テスト手順、既知の制約を納品物に含めます。

担当者の経験だけに依存する体制は、退職や異動で再びブラックボックス化します。ソースコードの保管場所、課題管理、レビュー記録、脆弱性対応履歴を発注者側でも参照できるようにし、月次の保守報告で未対応リスクと次回更新時期を確認します。

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

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

Strutsの移行では、技術変換に目が向きすぎると、業務ルール、データ品質、利用者の手順、運用責任が抜け落ちます。失敗のパターンを先に知り、要件、テスト、契約、体制へ対策を埋め込むことが大切です。

自動変換でコンパイルが通ると、移行が完了したように見えます。しかし、入力値の境界、権限の組み合わせ、締め処理、帳票の端数、外部連携の再送、二重送信防止などは、別のフレームワークへ移すと挙動が変わる可能性があります。現行画面と移行後画面の比較だけでなく、業務シナリオ単位の受入テストを行います。

対策として、移行前に重要業務の期待結果を決め、代表データを固定します。受入テストには業務部門の担当者を参加させ、金額、件数、状態遷移、出力帳票を突合します。不具合を技術チームだけで閉じず、業務影響と優先度を共有すると、リリース判断がしやすくなります。

フレームワーク更新をきっかけに、画面デザイン、業務ルール、データベース、認証、帳票、クラウド移行まで同時に変えると、原因の切り分けが難しくなります。改善したい項目をすべて一つのリリースに詰め込むのではなく、セキュリティ対応、現行機能の維持、業務改善を分けて、優先順位と予算を段階化します。

見積もりには、未確定事項、前提、除外範囲、追加変更の単価、予備工数を明記します。最初の調査で不明点が多い場合は、調査・PoCを先行させ、その結果をもとに本開発の契約を見直します。経営会議では、費用だけでなく、停止リスク、脆弱性リスク、担当者不足による保守リスクも同じ表で比較します。

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

最後に、Strutsのシステムを調べる際に多い質問へ回答します。自社のバージョンや構成が分からない場合は、回答を一般化せず、現行調査で事実を確認することが出発点です。

Struts 1を新規開発に使うことは推奨できません。サポートが終了しており、将来の脆弱性対応や実行環境との互換性に大きな不確実性があるためです。新規開発では、現行のサポート方針、セキュリティ更新、開発者の確保、保守期間を確認できる技術を選びます。

すぐに廃棄するのではなく、まずバージョン、脆弱性、外部公開範囲、業務重要度、移行難易度、停止可能時間を調査します。EOLや重大な脆弱性があり、外部から到達できる場合は緊急度が高くなりますが、短期の緩和策と移行PoCを並行し、切り戻し手順を用意して段階的に刷新する方法もあります。

小規模な保守や機能追加は100万〜300万円、現行調査・PoCは100万〜300万円、Struts 1からSpring系への移行は1,000万〜3,000万円、大規模基幹の刷新は3,000万〜1億円超が目安です。ただし、これは公開相場と人月単価から算出した推定であり、画面数、連携、帳票、バッチ、データ移行、テスト、停止制約で変わります。

Strutsのバージョン、JavaとWebコンテナのバージョン、画面数、Action数、データベース、帳票、バッチ、外部連携、ユーザー数、ピーク時の負荷、現行テストの有無、停止可能時間、希望する移行先を伝えます。ソースコード、設定ファイル、構成図、画面一覧、障害履歴を共有できると、調査と見積もりの精度が上がります。分からない項目は不明のまま提示し、調査工程を提案してもらいます。

まとめ：Strutsのシステムは調査して段階的に判断します

Strutsのシステムは、Strutsだけで構成される製品ではなく、Java、画面、データベース、認証、帳票、バッチ、外部連携を組み合わせた業務基盤です。新規開発でStruts 1を選ぶべきではありませんが、既存システムは業務価値とリスクを確認したうえで、パッチ、サポート対象版への更新、Spring系への段階移行、パッケージ置換、再構築を比較します。

最初に行うべきことは、バージョンと依存関係の確認、画面・Action・データ・連携・運用の棚卸し、脆弱性と停止リスクの判定です。その後、難しい代表機能でPoCを実施し、費用、期間、テスト工数、データ移行、保守体制を具体化します。開発会社やベンダーを選ぶ際は、技術名だけでなく、現行資産を調査した証拠、受入テストの考え方、移行後の知識継承、契約と成果物の範囲を確認します。

費用は、調査・PoCで100万〜300万円、Struts 1からSpring系への移行で1,000万〜3,000万円などが目安ですが、公開価格ではなく前提付きの推定です。自社の画面数や連携数を整理し、複数の提案を同じ条件で比較すると、予算とリスクを現実的に管理できます。

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