Javaアプレットの課題の一つは、Webブラウザとは別にJavaの実行環境を用意する必要があったことだ。Javaプラグインを使う場合は、その導入に加えて、Javaのバージョンや設定、更新状況を管理する必要があり、情シスの負担となった。

　安全性にも課題があった。Webから取得したプログラムを端末で動かすため、Javaアプレットには、ローカルファイルへのアクセスや他のプログラムの起動、ネットワーク通信などを制限する「サンドボックス」が設けられていた。一方、業務アプリでは、印刷やファイル操作など、サンドボックスの制限を超える処理が必要になることもある。こうした場合には、必要な権限を与える「署名付きアプレット」が利用された。

　JavaプラグインやJava実行環境では、脆弱（ぜいじゃく）性もたびたび発見された。修正プログラムが提供されるたびにJavaを更新する必要があったが、更新によって既存のアプレットが動かなくなることもあった。その結果、本来は安全性のために更新すべきなのに、業務を止めないために古い環境を維持するという、安全性と互換性の板挟みが生じた。

　その間に、JavaScriptやHTML、CSS、そしてWebブラウザ自体も進化した。画面の一部を更新したり、入力に応じて表示を変えたり、図形やグラフを描いたりといった処理を、追加のプラグインなしで実現できるようになった。スマートフォンの普及も、PCのWebブラウザでプラグインを前提とするJavaアプレットの利用範囲を狭めていった。

　こうした流れを受け、主要なWebブラウザはJavaを含む従来のプラグインへの対応を順次終了した。Java側でも、Javaプラグインなどの配布技術は2017年の「JDK 9」で非推奨となり、2018年の「JDK 11」で削除された。Webブラウザ側とJava側の双方で対応が終わり、Javaアプレットは通常のWeb環境では動かせなくなった。

　かつては、Webブラウザに機能を追加することで実現していた処理も、やがてWebの標準機能で実現できるようになった。一方で、追加の実行環境を管理し、安全性と互換性を維持する負担は残った。Webの進化とともに、Javaアプレットを使い続ける理由は、少しずつ失われていった。

「動いているから困らない」が刷新を遅らせる

　一般的なWebブラウザでJavaアプレットを動かせなくなっても、それを使ってきた業務までなくなるわけではない。統計的な裏付けはないものの、社内申請や受発注、図面の表示、帳票の印刷、工場設備やネットワーク機器の管理など、Javaアプレットを利用した古いシステムが、今も業務を支えているケースはある。

　こうしたシステムでは、アプレットが単なる画面表示だけでなく、入力内容の確認や計算、ローカルファイルの操作、プリンタへの出力、カードリーダーなどの周辺機器との連携まで担っていることもある。そのため、見た目の似たWeb画面を新しく作るだけでは、置き換えられない場合がある。

　さらに、長年使われてきたシステムには、プログラムの中に業務上のルールや例外処理が蓄積されていることも多い。設計書には残っていない処理や、現場で受け継がれてきた操作手順もあるだろう。移行するには、アプレットだけでなく、サーバやデータ、周辺機器、業務手順まで含めて整理する必要がある。

　一方で、刷新には相応の費用と時間がかかる。現在のシステムで業務が回っている以上、作り直しても利用者から見た変化が小さく、投資効果を示しにくい場合もある。特に利用者が限られるシステムでは、他の投資が優先され、刷新が後回しになりやすい。

　その結果、対応するJavaやWebブラウザの組み合わせを維持し、専用端末や仮想環境などに利用範囲を限定して使い続ける方法が取られることもある。だが、これは依存関係を解消したのではなく、動作する環境を維持しているにすぎない。端末の故障やOSの更新、証明書の期限切れ、接続先の変更などをきっかけに、突然使えなくなるリスクも残る。

　Javaアプレットに依存する仕組みが残るのは、単に古い技術だからではない。業務に必要な機能が深く組み込まれ、周辺システムや業務手順まで含めた置き換えが必要になるためだ。そこにコストや業務への影響も重なり、移行を難しくしている。

Javaアプレット依存システムの見直し方

　判断の出発点は、Javaアプレットそのものではなく、それが担っている業務だ。誰が、どのような場面で使い、停止するとどの業務に影響するのか。利用頻度や許容できる停止時間、手作業で代替できるかまで含めて、まず現状を把握する。

　次に、Javaアプレットが担っている機能を洗い出す。入力や照会だけなのか、計算や帳票印刷、端末内のファイル操作、周辺機器との通信まで行っているのか。サーバ側の処理やデータベースとの関係も確認し、どこまでを刷新する必要があるのかを明らかにする。ソースコードや設計書が残っていなければ、利用者への聞き取りや実際の操作を基に、現在の仕様を確認する。

　現在の実行環境を、どの程度維持できるかも重要だ。必要なOSやWebブラウザ、Javaの種類やバージョン、プラグイン、証明書、接続先などを整理する。保守やセキュリティ更新を受けられるか、端末が故障した際に同じ環境を再構築できるか、インストール用のファイルや設定情報が残っているかも確認しておきたい。再構築できない環境に依存しているシステムは、障害が起きて初めて問題が表面化することもある。

　刷新の方法は、残すべき機能に応じて考える。入力、申請、照会などが中心なら、ブラウザの標準機能で動くWebアプリへの移行が考えやすい。計算や業務上の判定をサーバ側へ移せば、端末ごとのJava環境への依存も減らせる。周辺機器の制御や端末内のファイル操作が欠かせない場合は、デスクトップアプリや機器メーカーの後継製品、端末側の処理とWebシステムを組み合わせる方法なども選択肢になる。

　すぐに刷新できず、専用端末や仮想環境で使い続ける場合は、移行までの暫定措置とする。利用者や接続先、権限を必要最小限に絞り、維持する理由と責任者を明確にする。故障時の復旧手順や代替手段、次回の見直し時期まで決めておけば、単なる延命ではなく、計画的な移行までの期間として管理できる。

　維持できる期間が見通せており、用途も限定され、停止時の代替手段があるなら、一定期間使い続けるという選択肢もある。一方で、環境を再構築できない、更新手段がない、停止した場合の業務への影響が大きいといった条件が重なるほど、刷新を検討する必要性は高まる。

　以前と同じ環境に戻すことは、目の前の業務を再開するための対応になる。だが、その先も同じ環境を維持できるとは限らない。次に端末が壊れたり、OSや周辺環境が変わったりしたときにも業務を続けられるかは、別の問題として考える必要がある。

　Javaアプレットの見直しで問われているのは、古い技術を残すかどうかだけではない。そこに組み込まれた機能と業務を改めて洗い出し、それらをこれからも維持できる環境へどう引き継ぐか。その判断こそが、重要になる。

死神管理人：　古いWebブラウザとJavaを残せば、ひとまず仕事は続けられるかもしれない。でも、それで解決したとは言えないんだね。

アンデッド管理人：　そう。その環境をいつまで維持できるかは別の問題だ。端末が故障したときに再構築できるか、更新できないソフトウェアをどう管理するかまで考える必要がある。

死神管理人：　見た目の似たWeb画面を作れば、置き換えられるとも限らない、と。

アンデッド管理人：　画面の裏で、帳票の印刷やファイルの操作、周辺機器との連携まで処理していることがあるからね。何をしているのかを洗い出して、それぞれの処理をどこへ移すか考えなければならない。

死神管理人：　確認すべきなのは、Javaのバージョンだけではなく、アプレットが支えている業務と、端末側の機能や依存関係ということだな。

アンデッド管理人：　そういうことだ。Javaアプレットが使えなくなっても、仕事は残る。以前の環境で動かす方法だけでなく、次の環境でも仕事を続ける方法を考える。それが情シスに残された宿題なんだ。