「Strutsって何？」「Strutsって今も使われているの？」「Strutsって勉強する必要あるの？」という疑問をお持ちではありませんか？
名前を聞いたことはあるけど、詳しく知らないという方に、Strutsについて紐解き、Apache Strutsの概要を解説します。
フレームワークとしての特色、ほかのフレームワークとの違い、特に重要な脆弱性のポイントに加えて、保守業務が発生した際の勉強方法についても紹介します。
目次
初めてプロジェクト担当者になった方向け
プロが教える「IT基礎知識・用語集」プレゼント
この資料でわかること
・システム開発の流れ
・専門用語の解説
・開発手法によるメリット・デメリット
・失敗を防ぐコツ
Struts（ストラッツ）とは？
Strutsは、かつてJavaによるWebアプリケーション開発において、事実上の標準（デファクトスタンダード）と称されるほど広く普及したフレームワークです。 現在では新規開発で使われることはほとんどありませんが、過去に開発されたシステムの保守・運用には欠かせない知識です。
●Strutsの概要
正式名称は「Apache Struts（アパッチ・ストラッツ）」といい、JavaでWebアプリケーションを開発するために使用されるオープンソースのフレームワーク（MVCモデル）の1つです。ちなみに、Strutsは、プログラムをModel、View、Controllerの役割に分けるMVCモデルを採用しています。
2005年頃には、Apache Strutsを利用する企業や技術者が多くなり、当時事実上の標準（デファクトスタンダード）といえるほど普及しました。これは当時としては画期的なMVCモデルを採用したフレームワークであったため、大規模になりがちなJava開発において効率よくプログラムを組むことができたことで広まりました。
しかしながら、現在では開発が終了しているバージョンが多く、後継のモダンなフレームワークに置き換えが進み、下火となっています。
●Struts1とStruts2の違い
Apache Strutsには大きく分けてStruts1（以下「1系」）とStruts2（以下「2系」）があります。
1系はJakarta Projectをベースにしていましたが、2007年にリリースされたStruts2はWebWork2ベースに置き換えられました。残念ながら、1系と2系には設計思想や内部構造に大きな互換性がありません。
現在、Apache Strutsは多くの脆弱性の報告があるため、新規のWebアプリケーション開発に用いられることはありませんが、過去にApache Strutsで開発されたシステムが現在も現役で動いていることはありえます。総務省で通達が出ているように、新しいフレームワークへの移行が推進されています。
特にStruts1系は2013年にすでにサポートが終了しており、脆弱性が発見されても修正プログラムが提供されないため、非常に危険な状態です。Struts2系も古いバージョンではサポートが終了しており、新しいフレームワークへの移行が急務とされています。
Struts2の特徴
Struts2は、Struts1の課題を克服し、WebWorkの思想を取り入れて生まれました。ここでは、特にStruts1から大きく改善・変更された点と、Struts2固有の機能について解説します。
●アノテーション機能
アノテーションは直訳で「注釈、注記」という意味の言葉です。Struts2ではアノテーション機能が導入され、クラスやメソッドなどを記述する際にアノテーションを活用することで、コードだけでは表現できない情報を記述することができます。
これによりチームでコーディングする際のルールを決めることができ、効率が上がります。加えて、アノテーションのおかげでStruts1で多用されていたXMLファイルへの設定記述を大幅に減らすことが可能です。
アノテーションを利用すると設定に従ったクラスの命名などで設定ファイルの記述を大幅に削減できます。規定に従ったクラスの命名などを行うことで、設定ファイルの記述を大幅に削減する、あるいは完全に排除する「ゼロコンフィギュレーション」とすることも可能です。
このゼロコンフィギュレーションは、Struts1の設定ファイルの煩雑さという大きな欠点を解消する画期的な改善でした。
●DIコンテナ機能を導入
DIコンテナ機能は、DI（Dependency Injection：依存性の注入）を利用したコンポーネントの集まりを一箇所で管理するための機能です。
例えば、プログラムAとBがある場合、プログラムBを別のクラスとしてプログラムAから呼び出すといった関係性があると、プログラムBを変更するとプログラムAが強く影響を受けてしまい、プログラムBを変更するにはプログラムAも変えなければなりません。このような密接な関係性を「依存性」といいます。
依存関係となってしまうと後の編集が大変となるため、AとBの依存関係を一度切り離し、記録することで、プログラムが実行されるまでAとBが依存関係を持たない状態にしておきます。
同様の依存関係を無数に記述した設定ファイルを元にDIコンテナが、適切な順番にDI（依存性の注入）することによって動作の正常化と管理を行います。つまり、今まで依存関係で1つを動かすと、別のものまで変えなくてはならないという状態からDIコンテナを利用することで、簡潔なプログラムにすることができます。
これにより、大規模なアプリケーションでも各コンポーネントの独立性が高まり、テストや保守が容易になります。Struts2では、WebWorkの思想を受け継ぎ、Spring Frameworkなどと同様にこのDIコンテナの概念を取り入れました。
●ActionクラスがPOJOである
Struts2では、Struts1とは異なり、ActionクラスをPOJOとして作成が可能です。POJOとは「Plain Old Java Objects」の略で依存性を排除した何も継承しないクラスのことを指しています。
POJOの意味合いとしては昔からある平凡なJavaオブジェクトのことで、フレームワークを用いた開発が盛んになったため、特別なルールに従うオブジェクトと区別するために、ごく普通のJavaオブジェクトをPOJOと呼ぶようになりました。
Struts2では、フレームワーク固有のクラスを継承する必要がなくなったため、ビジネスロジックをよりシンプルに、かつ他のフレームワークへの移行も比較的容易になる設計となりました。
●OGNLのセキュリティホールが発見されている
Struts2は、その設計に起因する脆弱性が多数報告されており、その多くはOGNL(Object Graph Navigation Library)ライブラリを利用していることから発生しています。OGNLにはJavaとHTTPを結びつける役割がありますが、Javaに似たコードをコンパイルなしで実行するために、悪意のあるリモートコード実行が過去に何度も報告されています。
現在使用しているシステムがStrutsを使用している場合、新しいシステムへの入れ替えが必要になります。しかしながら、自社で開発できない、技術者が不足していてシステム開発に人員を割けないなどの理由がある企業は多いかもしれません。もし、外部に開発を依頼するなら、プロ(システム開発会社向けマッチングサイト)に聞くのがおすすめです。発注ナビではシステム開発に詳しいスタッフが、要望を叶えられる会社をご提案します。
Struts2とほかのフレームワークの違い
Apache Strutsは、すでにサポートが終了しています。脆弱性の報告が多いため、まだシステムで使っている場合は早急に移行が必要です。ここでは移行先の候補となる、ほかのフレームワークとの違いを紹介します。
●Spring Framework
Struts2にあるDIコンテナの機能のほかにAOP（アスペクト指向プログラミング）コンテナという機能も持ち合わせているフレームワークです。
このAOPによってオブジェクトごとに存在する共通処理をアスペクトとして抜き出し、共通のプログラムを一括管理することができるようになります。
そのため、WebアプリケーションのためのSpring MVC、バッチアプリケーションのためのSpring Batchなど多岐にわたる機能モジュールを持ち、様々なニーズに対応した機能を持っています。
●JSF（JavaServer Faces）
JSF（JavaServer Faces）はJavaの基本仕様Java SEの基本機能を拡張したJava Platform, Enterprise Edition（Java EE）の機能として提供されているWebフレームワークでUI作成に特化しています。
簡単に高性能なWebアプリのインターフェースが作成可能です。
●Play Framework
Play FrameworkはJavaとScala向けのWebアプリケーションフレームワークで軽量で動作が速く、Javaの堅牢性を活かしてバックエンドに採用することもあります。
JSFは、HTMLの知識が少ない開発者でもWebアプリケーションを構築しやすいように設計されていますが、複雑な挙動を実現しようとすると学習コストが高くなる側面もあります。
StrutsやSpring MVCとは異なり、コンポーネント指向であるため、移行の際は設計思想の違いを理解する必要があります。
●Spark Framework
Spark FrameworkはJava/Kotlin言語で記述された、小・中規模の開発を迅速に行うことに特化したマイクロフレームワークです。軽量化したフレームワークの場合、軽量化の代償としてJVM（Java Virtual Machine：Javaのプログラムを動かすソフトウェア）を活かしきれないという特徴がありましたが、Spark FrameworkはJVMを効率よく利用できるように設計されています。
特に、マイクロサービスアーキテクチャの一部として、軽量なREST APIを迅速に構築したい場合におすすめです。大規模なフルスタックフレームワークであるStrutsやSpringとは異なり、機能が絞られているため、学習コストも比較的低いですが、必要な機能は自力で構築・統合する必要があります。
Struts2の勉強方法
Struts2は脆弱性報告やサポート切れのため、早急に新しいフレームワークへの刷新が必要です。
しかし、刷新するにしてもStruts2をある程度は理解しておかないと刷新の際に必要となる仕様が理解できない可能性があります。Struts2で過去に開発したシステムでできたことが新しいシステムでできないとなってしまうと不便が発生してしまいます。
勉強するといっても現在では利用者が少ないため、教本を1から進めていく必要はありません。どちらかといえば実際のコードを見ながら動作を見ていくほうが効率よく学習ができます。
また、Struts2の処理は複雑ではないため、写経をしながら仕様を理解していくほうが良いでしょう。
しかし、無心で写経するだけでは、あまり意味はありません。ある程度写経した後は、一度立ち止まってどのような構造になっているか、どのような役割をもっているプログラムなのかを俯瞰して確認する意識があるとより効率よく勉強が進むでしょう。
Struts2の保守で重要なのは、「XML設定ファイル」「Actionクラス」「OGNL式の使い方」の3点です。これらの要素がシステムの動作にどう関わっているかを、既存のコードから逆引きで確認する学習方法が最も実用的です。
Apache Strutsの脆弱性とその対策
Apache Strutsの利用において最も注意すべき点は、セキュリティの脆弱性です。特にOGNLを悪用したリモートコード実行の脆弱性は世界的に大きな被害をもたらしました。ここでは、具体的な脆弱性の事例と、企業が取るべき対策について詳しく解説します。
●過去の脆弱性事例
Apache Strutsの脆弱性は、主にStruts2で導入されたOGNL（Object Graph Navigation Language）の処理における不備によって引き起こされてきました。
最も有名なのは、2017年に発覚した「CVE-2017-5638」です。この脆弱性は、HTTPリクエストのContent-Typeヘッダー内のOGNL式が適切に検証されずに実行されてしまうというもので、攻撃者にサーバー上で任意のコードを実行される（リモートコード実行：RCE）リスクがありました。
他にも、ファイルのアップロード処理に関する脆弱性や、パラメーターの操作に関する脆弱性などが繰り返し報告されています。
これらの脆弱性が悪用されると、情報の窃取やファイルの不正操作サーバーに対して不正なリモートコードを実行されるなど、企業の存続にも関わる重大な被害が発生する可能性があります。
●【対策1】最新バージョンへのアップデート
対策は1系、2系に分けて公開されているため、まずは利用しているバージョンを確認する必要があります。脆弱性に該当するバージョンを使用しているシステムの場合には早急に対策が必要です。
特にStruts2.0から導入されたOGNL(Object Graph Navigation Language)に関する脆弱性が多く、新しいバージョンに移行しても根本的なOGNLの機能は残るため、根本的な対策がなかなかできていないのが現状です。
Struts1系は2013年にすでにサポートが終了しているため、今後対策プログラムの提供などは行われません。修正パッチや修正版バージョンは提供されていないため、そのまま使い続けるのはリスクが高くなります。
Struts2系もバージョンによってはすでにサポートが終了しています。脆弱性が報告されている2.0から2.3系まではサポートが終了しており、2025年10月現在の最新バージョンはStruts7.1.1GAです。バージョンアップにともなう仕様変更などを確認の上、システムの更新を行うと良いでしょう。
●【対策2】WAF（Web Application Firewall）の導入
WAF（Web Application Firewall：ウェブアプリケーションファイアウォール）は、Webアプリケーションの脆弱性を狙った攻撃からシステムを保護するためのセキュリティ対策です。
Strutsの脆弱性、特にOGNLを悪用したリモートコード実行攻撃は、HTTPリクエストの特定の箇所（ヘッダーやパラメーター）に悪意のあるコードを埋め込むことで行われます。WAFは、これらのHTTP通信を監視し、既知の攻撃パターンや異常なパターンを検知した場合に通信を遮断することで、アプリケーション本体に攻撃が到達するのを防ぎます。
Strutsのバージョンアップが技術的、コスト的に困難な場合の緊急的な防御策として非常に有効です。しかし、WAFはあくまで「盾」であり、アプリケーションの脆弱性自体を修正するわけではないため、恒久的な対策としては不十分であることに注意しましょう。
●【対策3】Strutsの設定ファイル（struts.xml）の見直し
Struts2の設定ファイルである「struts.xml」は、フレームワークの動作やアクションとURLのマッピング、インターセプターの設定などを定義する重要なファイルです。
脆弱性対策の観点からは、不必要な機能や設定を無効化・制限することが求められます。例えば、開発モードに関連する設定や、動的に実行可能なOGNL式を不用意に許可する設定は、セキュリティリスクを高める可能性があります。
Strutsの公式ドキュメントやセキュリティ情報で公開されている「セキュアな設定」に関するガイドラインに基づき、特に「Wildcard Mapping（ワイルドカードマッピング）」や「Dynamic Method Invocation (DMI)」など、柔軟性が高い反面、悪用のリスクも高い機能の利用範囲を厳しく制限することが重要です。
●【対策4】システムログの監視強化
万が一、外部からの攻撃によってStrutsの脆弱性が悪用された場合、その兆候を早期に発見するためにはシステムログの監視強化が不可欠です。
特に、Webサーバーのアクセスログ、アプリケーションサーバーのエラーログ、そしてStrutsが出力するデバッグログなどを継続的に監視する必要があります。
悪意のあるOGNL式が実行されようとした場合、通常とは異なるエラーメッセージや、不審なリクエストパターン（例：非ASCII文字の連続、特殊記号の多用）がログに残ることがあります。
これらのログをしっかりと管理し、異常を検知した際には即座に対応できる体制を構築することで、被害の拡大を防ぐことが可能です。
●【対策5】Strutsからのリプレイス（移行）
Struts1系のようにサポートが完全に終了している、あるいはStruts2系であっても頻繁なバージョンアップが困難な状況にある場合、最も根本的な対策は、最新のモダンなフレームワークへのリプレイス（移行）です。
Spring FrameworkやJava EE（Jakarta EE）の最新仕様を実装したフレームワーク（例：Spring Boot、Quarkus）など、セキュリティサポートが継続しており、コミュニティが活発なフレームワークへの移行を検討すると良いでしょう。
リプレイスは多大なコストと工数を要しますが、長期的にはセキュリティリスクの低減、開発効率の向上、そして技術者の確保という点で、その投資に見合うメリットがあります。
移行計画の策定にあたっては、既存システムの機能と新しいフレームワークの互換性を慎重に評価し、段階的な移行戦略を取ることが成功のポイントとなります。
しかしながら、自社で開発できない、技術者が不足していてシステム開発に人員を割けないなどの理由がある企業は多いかもしれません。もし、外部に開発を依頼するなら、プロ(システム開発会社向けマッチングサイト)に聞くのがおすすめです。発注ナビではシステム開発に詳しいスタッフが、要望を叶えられる会社をご提案します。
システム開発の最適な発注先をスムーズに見つける方法
システム開発会社選びでお困りではありませんか？
日本最大級のシステム開発会社ポータルサイト「発注ナビ」は、実績豊富なエキスパートが貴社に寄り添った最適な開発会社選びを徹底的にサポートいたします。
ご紹介実績：29,600件（2026年2月現在）
外注先探しはビジネスの今後を左右する重要な任務です。しかし、
「なにを基準に探せば良いのか分からない…。」
「自社にあった外注先ってどこだろう…？」
「費用感が不安…。」
などなど、疑問や悩みが尽きない事が多いです。
発注ナビは、貴社の悩みに寄り添い、最適な外注探し選びのベストパートナーです。
本記事に掲載するシステム会社以外にも、最適な開発会社がご紹介可能です！
ご相談からご紹介までは完全無料。
まずはお気軽に、ご相談ください。 →詳しくはこちら
初めてプロジェクト担当者になった方向け
プロが教える「IT基礎知識・用語集」プレゼント
この資料でわかること
・システム開発の流れ
・専門用語の解説
・開発手法によるメリット・デメリット
・失敗を防ぐコツ
