LASSIC Media らしくメディア
Interstageの移行先の選び方｜使っている機能で見る基準
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Interstageの移行は、アプリケーションと設定と運用の手順を、別のアプリケーションサーバーへ移す作業です。
- 移行先は、富士通の別の製品、Jakarta EE互換の製品、TomEE、Tomcatの4つの方向から選べます。
- 選ぶ前に、いまのアプリケーションが使っている機能を洗い出すことがいちばん大切です。
※ 本記事は2026年11月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
Interstageで動いている業務システムを、そろそろ移さなければならない。けれども、Tomcatに載せ替えればよいのか、別のアプリケーションサーバーを選ぶべきか、判断がつかない——。長く使ってきた基幹システムを抱える会社では、こうした迷いが起こりがちです。Interstage Application Serverは、富士通のアプリケーションサーバーで、Javaで作った業務システムを動かす土台として使われてきました。
移行先の候補は1つではなく、いまのシステムの作りによって合うものが変わります。ただし、どの移行先にも作り直しの手間はかかり、載せ替えるだけで済むとは限りません。本記事では、情報システムの担当者に向けて、Interstageの移行で扱う範囲、移行先の選択肢と違い、選び方、進め方、そして外部に頼むときに確認したい点を整理します。
目次
Interstageの移行とは
Interstageの移行は、Interstage Application Serverの上で動いている業務アプリケーションを、別のアプリケーションサーバーへ移す作業です。アプリケーションサーバーは、Javaで作った業務システムを動かすための土台のソフトウェアを指します。Interstage Application Serverは、Java EE（Javaで業務システムを作るための標準仕様）の互換製品として、v12.0がJava EE 7の、v10.1がJava EE 6の一覧に載っています。*1
移すものはプログラムだけではありません。土台が変わると、設定や運用の手順もいっしょに作り直すことになります。移行で扱う範囲は、おおむね次の3つです。
- 業務アプリケーション本体：画面の処理、データベースへの接続、ほかのシステムとの連携
- アプリケーションサーバーの設定：接続先のデータベース、通信の暗号化、ログの出し方
- 運用の手順：起動と停止、監視、バックアップ、障害が起きたときの対応
いつまでに移すかは、使っている版のサポート期限で決まります。期限は版ごとに異なるため、富士通の公式サイトのサポート情報で、自社の版の期限を最初に確かめておきます。
移行先の選択肢と違い
移行先は、大きく4つの方向に分かれます。Java EEの仕様は、いまはJakarta EEという名前で引き継がれ、その互換製品の一覧には複数の会社やオープンソースの製品が載っています。*2 富士通の製品では、Interstage Application ServerとEnterprise Application Platformの2つが一覧にあります。
| 選択肢 | 中身 | 合いやすい場面 |
|---|---|---|
| 富士通の別の製品 | Jakarta EEの互換製品一覧に載る富士通の製品 | 富士通の保守の窓口を続けて使いたいとき |
| Jakarta EE互換のアプリケーションサーバー | WildFly、Open Liberty、Eclipse GlassFishなど、一覧に載る製品 | Java EEの機能を幅広く使っているとき |
| Apache TomEE | Tomcatに、Jakarta EEの機能を加えたもの | Tomcatの使い勝手に近い形で、一部のEE機能も使いたいとき |
| Apache Tomcat | Jakarta EEの技術のうち、一部だけを実装したもの | 画面の処理が中心で、使っている機能が少ないとき |
表の4つに優劣はありません。どれが合うかは、いまのアプリケーションがどの機能を使っているかで決まります。商用のアプリケーションサーバーからの移行全般についてはWebLogic・WebSphereの移行でも扱っています。
移行先の選び方
移行先を選ぶときに見る点は、主に3つです。機能の多さから選ぶと、移したあとで足りない機能が見つかり、作り直しが増えます。
- 使っている機能：Tomcatが実装するのはJakarta EEの一部（Servlet・JSPなど画面の処理まわり）です*3。業務の処理をまとめる部品（EJB）やメッセージの受け渡し（JMS）を使っていれば、それを持つ製品が候補になります
- 名前の変更への対応：Java EE 8からJakarta EE 9で、部品の名前の頭が「javax」から「jakarta」に変わりました*4。Tomcatは10以降がJakarta EE 9の側です
- Javaの版：Tomcat 11は Java 17以降、10.1は Java 11以降、9.0は Java 8以降で動きます*3
Apache TomEEには4つの種類があり、Web Profileの種類はEJBの一部（EJB Lite）まで、PlusとPlumeの種類はJMSなども扱えます。*5 Tomcatに近い形で移したいが、Tomcatだけでは機能が足りない、という場合の選択肢の一つです。
移行の進め方
Interstageの移行は、次の4つの段階で進めます。いちばん時間がかかるのは、たいてい最初の棚卸しです。古いシステムほど、作った人がいなくなり、どの機能を使っているかが文書に残っていないことがあるからです。
- ステップ1：棚卸し。アプリケーションが使う機能、Interstageに固有の設定、つながっているシステムを一覧にする
- ステップ2：移行先を決める。前の節の3つの点で候補を絞り、小さな画面1つで試しに動かす
- ステップ3：変換と検証。名前の変更やJavaの版の違いに合わせてプログラムを直し、業務の流れどおりに動くかを確かめる
- ステップ4：切り替え。本番と同じデータで最終確認をしてから切り替え、戻す手順も用意しておく
ステップ3の名前の変更には、Apacheが変換ツールを出しています。Java EE 8向けに作られTomcat 9で動くアプリケーションを、Tomcat 10以降で動く形に自動で変換するものです。*4 ただし変換できるのは名前の部分だけで、Interstageにしかない機能に頼っている部分は人が読んで直す必要があります。Tomcatへ移したあとの版の上げ方はTomcatのバージョンアップで整理しています。
外部に頼むときに確認しておきたい点
社内に当時の開発者が残っていない場合、Interstageの移行を外部に頼むことになります。頼む前に、次の点を確かめておくと、見積もりの比べ方がはっきりします。
- 棚卸しを誰がするか：使っている機能の洗い出しを見積もりの前に行うか、作業の中に含めるか
- 移行先を選んだ理由：候補をどう比べたか、試しに動かした結果を見せてもらえるか
- 検証の範囲：業務の流れのどこまでを、誰が、どのデータで確かめるか
- 切り替えと戻し方：切り替えの日の手順と、うまくいかなかったときに元へ戻す手順があるか
- 移したあとの運用：Javaやアプリケーションサーバーの版の更新を、誰がいつ行うか
特に最後の点は、移行の作業が終わったあとに抜けやすい点です。オープンソースの製品は版の更新が続くため、移した直後から更新の計画を持っておくと、同じ移行を数年後にくり返す事態を避けやすくなります。
まとめ：Interstageの移行で確かめておきたい3つの点
Interstageの移行先を選ぶうえで、確かめておきたい点は3つに整理できます。第一に、使っている版のサポート期限を富士通の公式サイトで確かめ、いつまでに移すかを決めること。第二に、いまのアプリケーションが使っている機能を洗い出し、それを持つ移行先を選ぶこと。第三に、名前の変更やJavaの版の違いに合わせた検証と、切り替えに失敗したときの戻し方を用意することです。この3点を踏まえておけば、「Tomcatに移したのに、動かない機能があとから見つかった」という事態を避けやすくなります。移行先の選び方や進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
移行にはどのくらいの期間がかかりますか
期間は、アプリケーションの数と、使っている機能の種類で大きく変わります。一般的な目安を先に決めるより、棚卸しを済ませてから見積もるほうが外れにくくなります。サポート期限から逆算して、棚卸しは早めに始めておきます。
Tomcatに移すとInterstageの機能はそのまま使えますか
そのままでは使えない機能があります。Tomcatが実装しているのはJakarta EEの技術の一部です。*3 業務の処理をまとめる部品やメッセージの受け渡しの機能を使っている場合は、作り直すか、それらの機能を持つ移行先を選ぶ必要があります。
移行の間も今のシステムは使い続けられますか
多くの場合、移行先の環境を別に用意して検証するため、切り替えの日までは今のシステムを使い続けます。切り替えの前後で業務を止める時間が出ることがあるので、その時間帯と、元に戻す手順をあらかじめ決めておきます。
Interstageの移行のご相談
Interstageで動く業務システムの棚卸しから、移行先の選定、変換と検証、切り替え後の運用まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：Oracle「Java EE Compatibility」（https://www.oracle.com/java/technologies/compatibility-jsp.html）。出典：Java EE 7 Full PlatformとJava EE 6 Full Platformの互換製品一覧に、Fujitsu Interstage Application Server v12.0とv10.1が載っていることを参照（2026年11月確認）
- *2 参考：Eclipse Foundation「Jakarta EE Compatible Products」（https://jakarta.ee/compatibility/）。出典：Jakarta EEの互換製品一覧（FUJITSU Software Interstage Application Server、FUJITSU Software Enterprise Application Platform、WildFly、Open Liberty、Eclipse GlassFish、Apache TomEEなど）を参照（2026年11月確認）
- *3 参考：The Apache Software Foundation「Apache Tomcat Versions」（https://tomcat.apache.org/whichversion.html）。出典：TomcatがJakarta EEの技術の一部を実装したものであること、サポート中の版（11.0・10.1・9.0）と動くJavaの版を参照（2026年11月確認）
- *4 参考：apache/tomcat-jakartaee-migration（GitHub）（https://github.com/apache/tomcat-jakartaee-migration）。出典：Java EE 8向けのアプリケーションをTomcat 10以降向けに変換するツールの目的と、javaxからjakartaへの名前の変更についての記述を参照（2026年11月確認）
- *5 参考：Apache TomEE 公式サイト（https://tomee.apache.org/）。出典：TomEEがTomcatにJakarta EEの機能を加えたものであること、Web Profile・MicroProfile・Plus・Plumeの4つの種類と扱える機能の記述を参照（2026年11月確認）
