目次

はじめに：EOL管理、やった方がいいのはわかっているけど......

EOL(End of Life)をしっかり管理することは、ソフトウェアの脆弱性にいち早く対処するために欠かせません。サポートが切れた製品を使い続けることは、セキュリティインシデントや障害対応の難航に直結するリスクです。

そうはわかってはいても、台帳作成やツール導入の大変さを考えると、なかなか着手できずにいる方も多いのではないでしょうか。

このブログでは特に、すでにAWS環境を運用しているものの、セキュリティやEOL管理に手が回っていない方に向けて、Amazon Inspectorと生成AIを組み合わせることで、簡単にEOL管理を始める方法を提案します。

1. EOL管理には、3つの壁がある

EOL管理がなかなか進まない背景には、次の3つの壁があると感じています。

　
• わかりづらさ：EOLを迎えても、すぐには問題が起こらない
• 手間の多さ：始めようにも、いいやり方が思いつかない
• 陳腐化：始めても、運用を続けていくうちに形骸化していく

それぞれ見ていきましょう。

1-1. わかりづらさ:EOLを迎えても、すぐには問題が起こらない

EOLを迎えた古いシステムであっても、多くの場合はそのまま動き続けます。

見た目は何も変わらないため、EOL管理の重要性はわかりづらく、「今のところ困っていないなら大丈夫」と、EOL管理の導入そのものが後回しにされがちです。

しかし、いざシステムに新機能を追加したくなったときや、システムに不具合があったときに、バージョンが古いため対応できないことがあります。そうなる前に、EOLを管理して都度対応していく必要があります。

1-2. 手間の多さ:始めようにも、いいやり方が思いつかない

いざEOL管理を始めようとすると、多くの場合「台帳を人の手で作るか、専用ツールを導入するか」の二択に行き着きます。

台帳を1から作成するには、まず社内にあるソフトウェアやミドルウェアを漏れなく洗い出す必要があります。そのうえで、製品ごとのEOL情報を1つずつ確認しながら調べていく作業が必要で、相応の時間がかかります。

かといって専用のEOL管理ツールを導入すれば、この調査の手間はある程度解消されるものの、導入・運用コストがかさみます。中小規模のチームであれば、費用対効果を説明する社内稟議のハードルも決して低くありません。

1-3. 陳腐化:始めても、運用を続けていくうちに形骸化していく

仮に台帳を作ってEOL管理をスタートできたとしても、そこで終わりではありません。

EOL管理は一度台帳を整備すれば完了する業務ではなく、情報を継続的に更新し続ける必要があります。この運用の手間が積み重なることで、次第に更新が滞り、台帳の内容が実態と乖離していく、という事態に陥りがちです。

2. Amazon Inspectorと生成AIで実現する、第三の選択肢

これらの問題の解決策として見つけたのが、Amazon InspectorやAWS Configと生成AIを組み合わせる方法です。

Amazon Inspectorは、システムの脆弱性を検出するためのAWSのサービスですが、SBOM(Software Bill of Materials:ソフトウェア部品表)を出力する機能も備えています。これを使えば、稼働中のシステム（Amazon EC2 インスタンス、Amazon ECR、AWS Lambda 関数）にどんなソフトウェアが使われているかを自動的に洗い出せます。あわせてAWS Configを使うことで、ミドルウェアの構成情報も取得できます。

つまり、AWS環境をお使いであれば、台帳のベースとなる資産情報の収集そのものを、人の手をかけずに自動化できるのです。これまで1から頑張って情報を集めていた負担が、ぐっと軽くなります。専用ツールを新たに導入するコストもかかりません。

また、生成AIに取得したSBOMを読み込ませることで、使われているソフトウェアやミドルウェアのEOLを一瞬で取得することができます。

私たち自身、以前はEOL情報をひとつずつGoogle検索で調べていましたが、この仕組みによってその手間と時間を大きく減らすことができました。

3. 実際にやってみました

具体的な流れは、次の4つのステップです。

1. SBOMの出力：Amazon Inspector / AWS Configを使って、IT資産情報を自動収集してSBOMを出力する
2. SBOMのパッケージ単位変換：生成AIを使って、モジュール単位の情報をパッケージ単位に整理する
3. EOL取得：生成AIを使って、パッケージ単位のEOL情報を取得する
4. バージョンアップ対応：人間が、EOLの近いものから対応判断を行う

まず、Amazon InspectorのSBOM出力機能を使い、使用しているソフトウェア構成の情報を抽出します。コンソール、またはAWS SDKを使うことが可能です。出力できる情報は、Amazon EC2インスタンス、Amazon ECR、AWS Lambda関数が対象です。あわせてAWS Configからミドルウェアの情報も取得し、IT資産情報をまとめたSBOMを用意します（ステップ1）。

［図3］Amazon InspectorのSBOM出力画面

しかし、実際にやってみると、SBOMから出力される情報は、非常に細かいモジュール単位のデータでした。1つのソフトウェアは、実際には無数の小さなモジュールの組み合わせ（Pythonの細かなライブラリ等）でできています。モジュール単位のまま1つひとつEOLを調べていては、「情報は集まったけれど、扱いきれない」という新たな課題に直面することになります。

そこで、管理すべき情報の粒度そのものを見直しました。実務でEOL管理をするうえで本当に必要なのは、細かいモジュール単位ではなく、実務で扱いやすいパッケージ単位（DiangoやPython本体等）のEOL情報です。Amazon Inspectorが出力したSBOMを生成AIに読み込ませ、モジュール単位の膨大な情報を、実用的なパッケージ単位に整理させることにしました（ステップ2）。

パッケージ単位に整理できたら、続けて生成AIにそれぞれのパッケージのEOL情報をインターネットから調べさせ、台帳に反映します（ステップ3）。「情報を集める」だけでなく「情報を使える形にし、EOLまで調べる」ところまで、生成AIに任せられるようになったのが、この方法の一番のポイントだと感じています。

最後に、出来上がった台帳をシステム担当者に渡し、アプリのEOLが近いものから優先的にバージョンアップやリプレイス等の対応判断をします。そしていつ、どのように対応するかなどの計画を作り、計画を実行します。（ステップ4）。

4. 低コスト・低負担で運用を続けられる

この仕組みは、半年に一度のサイクルで運用しています。EOL対応は頻繁に発生するものではないため、このくらいの間隔でも十分に実態を追える運用になっています。

また、全自動化を目指すのではなく、情報収集と整理という手間のかかる部分は生成AIに任せ、バージョンアップやリプレイス等の判断は人が担っています。そのような役割分担にしたことで、無理なく、そして安心して運用を続けられる体制になっています。

「導入したはいいが、結局誰も使わなくなった」ということにならないように、続けやすさを意識した設計です。

結論：EOL管理は、思っているほど大変じゃない

台帳を1から手で作る必要も、高額な専用ツールを導入する必要もありません。AWS環境の機能と生成AIを組み合わせるだけで、低コスト・低負担でEOL管理を始めることができます。

「今のところ問題が起きていないから」「いいやり方が思いつかないから」と後回しにしてしまいがちなEOL管理ですが、積み上がるリスクは、決して小さくありません。

「やった方がいいのはわかっているけれど、コストや手間を考えるとなかなか踏み出せない」----そう感じている方にこそ、今回ご紹介した方法を知っていただきたいと思います。

EOL管理は、決して大掛かりな準備がなければ始められないものではありません。EOL管理にお悩みの方はぜひ一度、生成AIを活用したシステム開発・AWS構築を得意とする当社へご相談ください。

ご相談はこちらから