EOLとは｜サポート終了の意味・EOSとの違いと期限一覧【2026年】

ソフトウェアは、出た日から順に「機能が足される時期」「修正だけが出る時期」を通り、最後に EOL を迎えます。EOL のあとに取れる道は、そのまま使う・有償の延長を買う・次の版へ移る、の3つです。

flowchart TD
    A[リリース] --> B[アクティブ<br>機能・バグ修正]
    B --> C[保守<br>セキュリティ修正だけ]
    C --> D{EOL}
    D --> E[放置<br>修正なし]
    D --> F[有償延長<br>ESU・ESM]
    D --> G[次の版へ<br>移行]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（apt 2.8.3）の上で、作業場所に置いた sources ファイルを -o Dir::Etc::SourceParts=…・-o Dir::State::Lists=… で指定して apt-get update を実行し、ホストの /etc/apt と /var/lib/apt は変えずに EOL 版（Ubuntu 23.10 mantic）のリポジトリの応答を確かめました。Python は 3.8.20（uv 0.11.32 で作業場所に入れたもの）・3.11.18・3.12.3（Ubuntu のパッケージ 3.12.3-1ubuntu0.17）・3.13.18 と pip 23.0.1／26.2.1、Node.js は 22.23.4（npm 10.9.9）、Git は 2.43.0 で実行しています。期限は endoflife.date の公開データ（API の JSON）を読み、Python Developer's Guide・Node.js・Ubuntu・Oracle・Microsoft Learn・Django の公式ページと突き合わせました。old-releases.ubuntu.com・deb.debian.org・endoflife.date への直接の接続は、この環境のプロキシで止められたため、その部分は公式ドキュメントで書いています。図は mermaid で描画を確かめました（確認日 2026年10月29日）。

EOLとは（サポート終了の意味と2つの読み方）

この節では、EOL という言葉の意味と、IT で使われる2つの読み方が分かります。

IT で EOL と書かれていたら、ほとんどは「End of Life（エンド・オブ・ライフ）」＝製品のサポートが終わることです。 日本語では「サポート終了」「製品寿命の終わり」と訳されます。メーカーや開発元が、その版（バージョン）に対して、バグの修正・セキュリティの修正・問い合わせへの対応をやめる時点を指します。

もう1つ、プログラミングでは「End of Line（行末）」の略としても EOL を使います。テキストの行の終わりを表す改行の記号（LF・CRLF）のことで、エディタの「EOL を変換」や Git の core.eol 設定はこちらです。

EOL は「止まる日」ではなく「直らなくなる日」

EOL を過ぎても、入っているソフトウェアがその日に動かなくなるわけではありません。変わるのは次の3点です。

• 新しく見つかった脆弱性の修正が出ない。 修正が出ないまま、脆弱性の情報だけが公開されていきます。
• 配布の場所がなくなる・移される。 Linux のパッケージのリポジトリや、ダウンロードのページから消えます（後の節で、apt の404の原文を載せています）。
• 周りのソフトが対応をやめる。 ライブラリの新しい版が、EOL の版にはもう入らなくなります（pip・npm の実物も後の節で）。

「サポート終了」は製品によって呼び方が違い、Microsoft は「サポート終了」「サービス終了」、Python は「end-of-life」、Node.js は「End-of-Life（EOL）」、Ubuntu は「End of Standard Support」と書きます。言葉が違っても、指しているのは「その版に修正が出なくなる日」です。

EOL・EOS・EOSL・LTSの違い（用語の一覧表）

この節では、EOL と一緒に出てくる EOS・EOSL・LTS などの略語の意味と、紛らわしい点が分かります。

いちばん紛らわしいのは EOS です。 End of Sale（販売終了）の意味で使う会社と、End of Support（サポート終了）の意味で使う会社があります。たとえば Cisco のポリシーでは、EOS は「販売終了日」（この日以降は発注できない）で、サポートを受けられる最終日は LDOS（Last Date of Support）と別に呼びます。一方、ソフトウェアの記事では EOS を「サポート終了」と書くことが多く、同じ略語で意味が逆になります。資料を読むときは、略語ではなく正式な名前と日付で確かめます。

LTS と EOL の関係

LTS は「EOL までが長い版」です。 LTS でも EOL は必ず来ます。Ubuntu の公式ページは、LTS は2年ごとに出て、5年間の標準のセキュリティ保守を受けると説明しています。Node.js の公式ページは、偶数の版が LTS になり、LTS は重大なバグの修正を合計30か月にわたって保証するのが一般的だ、としています。LTS ではない版（Ubuntu の中間リリースや Node.js の奇数の版）は、EOL までが短く、Ubuntu の中間リリースは9か月です。

製品ごとのサポートの段階（Python・Node.js・Ubuntu・Microsoft）

この節では、EOL の前にどんな段階があり、どの段階で何が止まるのかが、製品ごとに分かります。

多くの製品は「アクティブ（機能・バグ修正）→保守（セキュリティ修正だけ）→EOL」の順に進みます。 段階の名前と長さは製品ごとに決まっています。各公式ページの記述を並べました。

• Python の security の段階では、Windows・Mac 向けのインストーラーが出ません。 Python Developer's Guide は、security の段階では「no more binaries are released」と書いています。ソースからビルドするか、OS の配布元のパッケージを使うことになります。
• Node.js は「本番は Active LTS か Maintenance LTS だけを使う」と公式ページに書かれています。奇数の版（25 など）は LTS にならず、半年ほどで EOL になります。
• Microsoft の固定ライフサイクルポリシーでは、延長サポートの間はセキュリティ更新が出ますが、セキュリティ以外の更新・設計変更・新機能の要求は受け付けません。

主要ソフトのEOL一覧（2026年10月29日時点）

この節では、Python・Node.js・Ubuntu・Java・Windows・Django の版ごとの EOL の日付が、出典つきで分かります。

以下の日付は、すべて2026年10月29日時点で endoflife.date の公開データと各公式ページを突き合わせたものです。 予定の日付は変わることがあります。作業の前に、参考・出典の公式ページで最新の値を確かめます。

Python

状態と EOL は Python Developer's Guide の「Status of Python versions」（2026年5月27日更新）です。endoflife.date は予定の EOL を月末（3.11 は 2027-10-31 など）で載せています。3.13 は2026年10月に bugfix から security の段階に移り、Windows・Mac 向けのインストーラーはもう出ません。

Node.js

Node.js の公式の「Node.js Releases」では、v26・v24・v22 が LTS、v25・v20 以前が EOL と表示され、2026年10月29日時点の「Latest LTS」は v26.13.0 でした。日付は endoflife.date の値です。

Ubuntu

標準サポートと ESM の月は Ubuntu の「Ubuntu release cycle」のページ、日付は手元の /usr/share/distro-info/ubuntu.csv（distro-info-data 2026.10.12）で確かめました。公式ページは月単位、distro-info と endoflife.date は日単位で、数日ずれることがあります（20.04 は distro-info が 2025-05-29、endoflife.date が 2025-05-31）。

Java・Windows・Django

Java は配布元（Oracle・Eclipse Temurin・Amazon Corretto など）ごとに期限が違います。配布元ごとの表は、関連記事「Javaバージョン一覧【2026年】LTSのサポート期限とJava 27・28」で扱っています。

EOLの調べ方（公式ページ・endoflife.date・手元のコマンド）

この節では、使っている製品の EOL を、どこで・どの順に確かめればよいかが分かります。

決め手は製品の公式ページです。一覧で見るなら endoflife.date、手元の版はコマンドで確かめます。

endoflife.date の API で読める項目

endoflife.date は https://endoflife.date/api/製品名.json で、版ごとの JSON を返します（API の説明は v1 のドキュメント）。Node.js の 22 を読むと次の形でした（2026年10月29日時点）。

{"cycle":"22","releaseDate":"2024-04-24","lts":"2024-10-29","support":"2025-10-21","eol":"2027-04-30","latest":"22.23.4"}

手元の Node.js は 22.23.4 で、latest と同じでした。系列が EOL でなくても、パッチ版が latest より前なら、出ている修正を取り込めていません。 EOL と同じくらい、パッチ版の遅れも見ます。

apt で入れた Python は OS の期限に従う

手元の Ubuntu 24.04 の Python 3.12 は、版の番号が 3.12.3 のままでした。上流の 3.12 の最新は 3.12.16 ですが、Ubuntu は修正をパッケージに取り込んで配っています。

$ dpkg -s python3.12 | grep -E '^(Version|Status)'
Status: install ok installed
Version: 3.12.3-1ubuntu0.17

$ zcat /usr/share/doc/python3.12/changelog.Debian.gz | grep -m3 -E 'CVE|^python3.12'
python3.12 (3.12.3-1ubuntu0.17) noble-security; urgency=medium
    - debian/patches/CVE-2026-4360.patch: pass the filter function through
    - CVE-2026-4360

OS のパッケージは「3.12.3」という番号のまま、後ろの -1ubuntu0.17 の部分で修正が増えていきます。 番号だけを見て「パッチ版が遅れている」と判断しないようにします。OS とカーネルの版の確かめ方は、関連記事「LinuxのOS・バージョン確認コマンド｜os-releaseとunameの違い」で扱っています。

手元の環境のEOLを一括で確かめるスクリプト

この節では、1台のサーバーに入っている OS・Python・Node.js・Java の版と EOL までの日数を、まとめて出す方法が分かります。

Ubuntu には、版ごとの EOL を書いた CSV（distro-info-data パッケージの /usr/share/distro-info/ubuntu.csv）が最初から入っています。 中身は次の形です。

version,codename,series,created,release,eol,eol-server,eol-esm,eol-legacy
22.04 LTS,Jammy Jellyfish,jammy,2021-10-14,2022-04-21,2027-06-01,2027-06-01,2032-04-21,2037-04-30
23.10,Mantic Minotaur,mantic,2023-04-20,2023-10-12,2024-07-11
24.04 LTS,Noble Numbat,noble,2023-10-12,2024-04-25,2029-05-31,2029-05-31,2034-04-25,2039-04-28
26.04 LTS,Resolute Raccoon,resolute,2025-10-09,2026-04-23,2031-05-29,2031-05-29,2036-04-23,2041-04-30

この CSV と、endoflife.date から写した表を使って、手元の版を判定するスクリプトを書きました（Python 3.13 で実行。外部へは問い合わせません）。

import csv, datetime, os, re, subprocess, glob

TODAY = datetime.date(2026, 10, 29)
# endoflife.date の公開データ（2026年10月29日時点）から写した EOL 日
EOL = {
    "python": {"3.8": "2024-10-07", "3.9": "2025-10-31", "3.10": "2026-10-01",
               "3.11": "2027-10-31", "3.12": "2028-10-31", "3.13": "2029-10-31", "3.14": "2030-10-31"},
    "nodejs": {"18": "2025-04-30", "20": "2026-04-30", "22": "2027-04-30", "24": "2028-04-30", "26": "2029-04-30"},
    "eclipse-temurin": {"8": "2030-12-31", "11": "2027-10-31", "17": "2027-10-31", "21": "2029-12-31", "25": "2031-09-30"},
}

def judge(eol):
    d = (datetime.date.fromisoformat(eol) - TODAY).days
    if d < 0:   return f"EOL済み（{-d}日経過）"
    if d < 180: return f"残り{d}日（半年以内）"
    return f"残り{d}日"

def run(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True)
        return (p.stdout + p.stderr).strip()
    except FileNotFoundError:
        return ""

rows = []
# OS：/etc/os-release の VERSION_ID を ubuntu.csv で引く
osr = dict(l.strip().split("=", 1) for l in open("/etc/os-release") if "=" in l)
vid = osr["VERSION_ID"].strip('"')
for r in csv.DictReader(open("/usr/share/distro-info/ubuntu.csv")):
    if r["version"].split()[0] == vid:
        rows.append(("Ubuntu", vid, r["eol"], "ubuntu.csv の eol（標準サポート）"))
        rows.append(("Ubuntu", vid, r["eol-esm"], "ubuntu.csv の eol-esm（Ubuntu Pro）"))
# Python：入っている python3.x をすべて（同じ実体は1回だけ）
seen = set()
for exe in sorted(glob.glob("/usr/bin/python3.[0-9]*") + glob.glob("/path/to/uvpy/*/bin/python3.[0-9]")):
    if exe.endswith("-config") or os.path.realpath(exe) in seen: continue
    seen.add(os.path.realpath(exe))
    v = run([exe, "-c", "import sys;print('%d.%d.%d'%sys.version_info[:3])"])
    mm = ".".join(v.split(".")[:2])
    if mm in EOL["python"]:
        rows.append(("Python", v, EOL["python"][mm], exe))
# Node.js
v = run(["node", "-v"]).lstrip("v")
rows.append(("Node.js", v, EOL["nodejs"][v.split(".")[0]], "node -v"))
# Java（OpenJDK は配布元で期日が違う。ここでは Temurin の値を参考に）
m = re.search(r'version "(\d+)', run(["java", "-version"]))
if m:
    rows.append(("Java", m.group(1), EOL["eclipse-temurin"][m.group(1)], "参考：Temurin の EOL"))

print(f"確認日 {TODAY}")
for name, ver, eol, src in rows:
    print(f"{name:<8}{ver:<10}{eol:<12}{judge(eol):<22}{src}")

実行した結果です（パスの一部を短くしています）。

$ python3 -I eolcheck.py
確認日 2026-10-29
Ubuntu  24.04     2029-05-31  残り945日                ubuntu.csv の eol（標準サポート）
Ubuntu  24.04     2034-04-25  残り2735日               ubuntu.csv の eol-esm（Ubuntu Pro）
Python  3.8.20    2024-10-07  EOL済み（752日経過）       /path/to/uvpy/cpython-3.8-linux-x86_64-gnu/bin/python3.8
Python  3.11.18   2027-10-31  残り367日                /usr/bin/python3.11
Python  3.12.3    2028-10-31  残り733日                /usr/bin/python3.12
Python  3.13.18   2029-10-31  残り1098日               /usr/bin/python3.13
Node.js 22.23.4   2027-04-30  残り183日                node -v
Java    21        2029-12-31  残り1159日               参考：Temurin の EOL

• EOL 済みの Python 3.8 が1つ見つかりました（この記事の検証のために入れたもの）。1台に複数の Python が入っていると、どれがアプリで使われているかで結果が変わります。
• Node.js 22 は残り183日で、もう少しで「半年以内」に入ります。半年を切ってから更新を始めると、検証の時間が足りなくなりがちです。
• Python 3.12.3 は前の節のとおり Ubuntu のパッケージで、実際の保守の期限は Ubuntu 24.04 に合わせて見ます。

Python の版を切り替える方法は関連記事「pyenvとは｜インストール・使い方・仕組みとエラーの直し方」で、Node.js の版を切り替える方法は関連記事「Node.js バージョン管理｜nvm・fnm・mise・Volta比較と実測」で扱っています。

EOLを過ぎると何が起きるか（apt updateが404になる実例）

この節では、EOL 版の OS を使い続けたときに、パッケージの取得で実際に何が起きるかが、apt の原文で分かります。

Ubuntu は、EOL になった版のリポジトリを通常のミラー（archive.ubuntu.com）から外します。 そのため、EOL 版のまま apt update を実行すると、Release ファイルが見つからず404になります。

再現の方法（ホストの設定を変えない）

EOL 版の Ubuntu 23.10（mantic、2024年7月11日に EOL）を指す sources ファイルを作業場所に置き、apt の設定の場所を -o で差し替えて実行しました。/etc/apt と /var/lib/apt/lists には触れていません。

W=/path/to/work/apt
mkdir -p $W/parts $W/lists/partial $W/cache/archives/partial
cat > $W/parts/eol.sources <<'EOF'
Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: mantic
Components: main
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
EOF
LANG=C apt-get \
  -o Dir::Etc::SourceList=/dev/null \
  -o Dir::Etc::SourceParts=$W/parts \
  -o Dir::State::Lists=$W/lists \
  -o Dir::Cache=$W/cache \
  update

Ign:1 http://archive.ubuntu.com/ubuntu mantic InRelease
Err:2 http://archive.ubuntu.com/ubuntu mantic Release
  404  Not Found [IP: 91.189.91.83 80]
Reading package lists...
E: The repository 'http://archive.ubuntu.com/ubuntu mantic Release' does not have a Release file.
$ echo $?
100

同じ URL を curl で確かめると、サポート中の noble は200、EOL の mantic は404でした。

$ curl -sSI http://archive.ubuntu.com/ubuntu/dists/mantic/Release | head -1
HTTP/1.1 404 Not Found
$ curl -sSI http://archive.ubuntu.com/ubuntu/dists/noble/Release | head -1
HTTP/1.1 200 OK

サポート中のリポジトリと混ざっているとき

EOL の mantic と、サポート中の noble を両方書いた sources で実行すると、noble の取得は成功したうえで、全体の終了コードは100になりました。

Ign:1 http://archive.ubuntu.com/ubuntu mantic InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble InRelease [256 kB]
Err:3 http://archive.ubuntu.com/ubuntu mantic Release
  404  Not Found [IP: 91.189.91.83 80]
Get:4 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages [1808 kB]
Reading package lists...
E: The repository 'http://archive.ubuntu.com/ubuntu mantic Release' does not have a Release file.
apt-get exit=100

終了コードが100なので、Dockerfile の RUN apt-get update && apt-get install … や CI のジョブは、ここで止まります。 「昨日まで通っていたビルドが急に落ちた」の原因が、ベースイメージの OS の EOL だった、という形で表に出ることがあります。

移された先（old-releases）と、この環境で起きたこと

Ubuntu の EOL 版のパッケージは old-releases.ubuntu.com に移されます。sources の URI をそちらに向けると取得はできますが、修正はもう出ません。あくまで次の版へ移るまでのつなぎです。 この環境では old-releases への接続がプロキシで止められ、次の文言になりました（名前解決の段階で止まり、警告だけで終了コードは0）。

Err:1 http://old-releases.ubuntu.com/ubuntu mantic InRelease
  Could not resolve 'old-releases.ubuntu.com'
Reading package lists...
W: Failed to fetch http://old-releases.ubuntu.com/ubuntu/dists/mantic/InRelease  Could not resolve 'old-releases.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

Debian も同じく、EOL の版は archive.debian.org に移されます（この環境では deb.debian.org・archive.debian.org への接続も同じく止められたため、実行していません）。apt のサブコマンドと update・upgrade の違いは、関連記事「aptコマンド一覧｜updateとupgradeの違い・apt-getとの違い」で扱っています。

EOL版の言語でパッケージが入らない（pip・npmの実例）

この節では、EOL の Python・Node.js で、ライブラリの新しい版が入らなくなる様子と、エラーの読み方が分かります。

ライブラリは、対応する言語の版を宣言しています。 Python は Requires-Python、Node.js は package.json の engines です。EOL の版は、新しいライブラリの対象から外されていきます。

Python 3.8 で pip install numpy==2.3.0

EOL の Python 3.8.20 の venv（pip 23.0.1）で、NumPy 2.3.0 を入れようとした結果です（長い行を途中で省いています）。

$ pip install 'numpy==2.3.0'
ERROR: Ignored the following versions that require a different python version: 1.25.0 Requires-Python >=3.9; … 2.0.0 Requires-Python >=3.9; … 2.1.0 Requires-Python >=3.10; … 2.3.0 Requires-Python >=3.11; … 2.5.0 Requires-Python >=3.12; … 2.5.4 Requires-Python >=3.12
ERROR: Could not find a version that satisfies the requirement numpy==2.3.0 (from versions: 1.3.0, 1.4.1, … 1.24.3, 1.24.4)
ERROR: No matching distribution found for numpy==2.3.0

「No matching distribution found」だけを見ると、名前の打ち間違いやネットワークの問題に見えます。 1行目の「require a different python version」が、本当の原因（Python の版が足りない）です。

版を指定しないと、黙って前の版が入る

もっと気づきにくいのは、版を指定しない場合です。pip install --dry-run で、Python 3.8 と 3.13 で入る版を比べました。

Python 3.8 で pip install django と打つと、エラーも警告も出ずに、すでに EOL の Django 4.2 が入りました。 言語の EOL が、上に載るフレームワークの EOL を連れてきます。requirements.txt の版の固定の書き方は、pip の公式ドキュメントで確かめられます。

Node.js 22 で engines が「>=24」のパッケージ

作業場所に "engines": {"node": ">=24"} を書いた小さなパッケージを作り、Node.js 22.23.4 のアプリから入れました（外部には接続しない --offline）。

$ npm install --offline
npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: 'newlib@1.0.0',
npm warn EBADENGINE   required: { node: '>=24' },
npm warn EBADENGINE   current: { node: 'v22.23.4', npm: '10.9.9' }
npm warn EBADENGINE }

added 1 package in 811ms

$ npm install --offline --engine-strict
npm error code EBADENGINE
npm error engine Unsupported engine
npm error engine Not compatible with your version of node/npm: newlib@1.0.0
npm error notsup Not compatible with your version of node/npm: newlib@1.0.0
npm error notsup Required: {"node":">=24"}
npm error notsup Actual:   {"npm":"10.9.9","node":"v22.23.4"}

npm の既定では警告（warn）だけで入ってしまい、終了コードも0でした。 --engine-strict（または .npmrc の engine-strict=true）を付けたときだけエラーになります。警告を読み飛ばすと、対応外の版のまま動かして、実行時に初めて壊れることになります。

EOLのリスク（セキュリティ・運用・費用・取引）

この節では、EOL の製品を使い続けると、どんな種類の問題が起きるのかが整理して分かります。

EOL の製品に例外の修正が出たこともある

2017年5月のランサムウェア WannaCrypt（WannaCry）のとき、Microsoft はサポートが終わっていた Windows XP・Windows 8・Windows Server 2003 にも、例外としてセキュリティ更新を出しました（Microsoft Security Response Center のブログ、2017年5月13日）。サポート中の Windows 向けの修正（MS17-010）は、その年の3月に出ていました。サポート中の製品には事前に修正が届いていて、EOL の製品は大きな被害が出たあとの例外の対応になった、という順番が、EOL の意味をよく表しています。例外は毎回あるものではありません。

EOL対応の進め方（更新計画と判断表）

この節では、EOL が近い・過ぎた製品を見つけたときに、何から手を付け、どう決めればよいかが分かります。

まず一覧を作り、外から触れられるものから順に更新します。 次の順に進めると、抜けが出にくくなります。

1. 1棚卸し（一覧を作る）OS・言語・DB・ミドルウェア・フレームワーク・コンテナのベースイメージ。版と EOL を表にする
2. 2インターネットに面したものからWeb サーバー・公開 API・VPN 機器。外から届くものほど先に
3. 3土台から上へOS → 言語の実行環境 → フレームワーク → ライブラリの順。上だけ上げても下が止める
4. 4次の LTS を選ぶEOL までの残りが長い版へ。2つ先まで見て、すぐ次の更新が来ないものを
5. 5テストして切り替えるCI で新旧の版を並べて動かし、差を確かめてから本番を切り替える
6. 6次の EOL を予定に入れるEOL の半年前・1年前に見直す予定を、カレンダーやチケットに入れる

判断表：EOL までの残りと、取る行動

• 1コンテナのベースイメージも一覧に入れたFROM の行の OS と言語の版。ホストが新しくても中が EOL のことがある
• 21台に複数ある言語の実体を数えた手元では Python が4つあった。アプリが使う実体で判定する
• 3OS のパッケージは OS の期限で見た3.12.3-1ubuntu0.17 のように、番号の後ろで修正が増える
• 4CI で engine-strict・Requires-Python を効かせた警告で通さず、対応外の版をエラーにする
• 5日付の出典と時刻の基準を残した公式の表・確認日・タイムゾーンを一覧に書く

すぐ移行できないときの暫定策（延長サポート・隔離）

この節では、EOL までに更新が間に合わないときに、取れる手段とその限界が分かります。

暫定策は「時間を買う」ための手段で、EOL の解決ではありません。 期限と移行の日付を決めたうえで使います。

Windows 10 の ESU は、組織向けは最大3年（1年目は2025年11月開始、年単位で購入）、個人向けは2027年10月12日までと Microsoft のページに書かれています（2026年10月29日時点）。どちらも Windows 10 バージョン 22H2 が条件です。

もう1つのEOL：改行コード（End of Line・LF・CRLF）

この節では、プログラミングで出てくる「行末の EOL」が何を指し、どう確かめるのかが分かります。

行末の EOL は、テキストの行の終わりに入る見えない記号です。 Linux・Mac は LF（\n）、Windows は CRLF（\r\n）を使うのが一般的で、昔の Mac OS は CR（\r）でした。同じ「a、b」の2行を3通りで保存し、od -c と file で見ました。

== lf
0000000   a  \n   b  \n
lf.txt: ASCII text
== crlf
0000000   a  \r  \n   b  \r  \n
crlf.txt: ASCII text, with CRLF line terminators
== cr
0000000   a  \r   b  \r
cr.txt: ASCII text, with CR line terminators

CRLF のシェルスクリプトを Linux で実行すると、1行目の #!/bin/sh の後ろに \r が付いたままになり、次のエラーになりました（bash 5.2）。

$ ./s.sh
/bin/bash: line 1: ./s.sh: cannot execute: required file not found

Git では git ls-files --eol で、リポジトリの中（i/）と作業ツリー（w/）の改行コードを見られます。CRLF のファイルを core.autocrlf true で add すると、リポジトリには LF で入りました。

$ git config core.autocrlf true && git add w.txt
$ git ls-files --eol
i/lf    w/crlf  attr/                 	w.txt
$ git config core.autocrlf input && git add x.txt
warning: in the working copy of 'x.txt', CRLF will be replaced by LF the next time Git touches it
$ printf '* text=auto eol=lf\n' > .gitattributes
$ git ls-files --eol
i/lf    w/lf    attr/text=auto eol=lf 	.gitattributes
i/lf    w/crlf  attr/text=auto eol=lf 	w.txt

Python の open() は、テキストモードでは CRLF を \n に変えて読みます（バイナリモードでは b'a\r\nb\r\n'、テキストモードでは 'a\nb\n' でした）。チームで改行コードをそろえる設定は、関連記事「Git改行コード設定｜autocrlfと.gitattributesの違い」で扱っています。

よくあるエラー・つまずき（EOLが原因のもの）

この節では、EOL が原因で出るエラーの原文と、その読み方・直し方が一覧で分かります。

つまずきやすい点です。

• 「最新のパッチ版を入れている」と「EOL ではない」は別の話です。 Python 3.10.22 は 3.10 の最後のパッチ版でも、3.10 自体が EOL です。
• endoflife.date と公式で日付が数日ずれることがあります。 契約や社内の基準に書く日付は公式の値を使います。
• Microsoft の日付は米国太平洋時間です。 表の「10/14/2026 6:59:59 AM」は、日本時間では同じ日の夜です。

よくある質問

この節では、EOL について検索でよく聞かれる疑問への答えが分かります。

Q. EOLとは何の略ですか？ A. IT では主に「End of Life」の略で、製品や版のサポートが終わることです。プログラミングの文脈では「End of Line」（行末・改行コード）の略としても使います。

Q. EOL を過ぎたソフトウェアは使えなくなりますか？ A. その日に動かなくなるわけではありません。ただし、新しく見つかった脆弱性の修正が出なくなり、配布のリポジトリも消えていきます。手元では、EOL の Ubuntu 23.10 のリポジトリが404になり、apt-get update が失敗しました。

Q. EOL と EOS の違いは何ですか？ A. EOS は End of Sale（販売終了）と End of Support（サポート終了）の両方の意味で使われます。Cisco では EOS は販売終了日で、サポートの最終日は LDOS と呼びます。資料ごとに正式な名前で確かめます。

Q. EOL と EOSL の違いは何ですか？ A. EOSL（End of Service Life）は、保守サービスも含めて完全に終わることを指す言葉として、主にハードウェアの保守で使われます。EOL のあとも一定期間は保守が続く製品があり、その保守も終わる時点が EOSL です。

Q. LTS なら EOL はありませんか？ A. あります。LTS は EOL までが長い版です。Ubuntu の LTS は標準で5年、Node.js の LTS は合計30か月が目安で、どちらも期限が来ます。

Q. Python 3.10 はもう使えませんか？ A. 2026年10月1日に EOL になりました（2026年10月29日時点）。動きはしますが、上流からの修正は出ません。3.12 以降へ移る計画を立てます。OS のパッケージとして入っている場合は、その OS の保守の期限も確かめます。

Q. Windows 10 はいつまで使えますか？ A. サポートは2025年10月14日に終わりました。ESU に登録すると、個人向けは2027年10月12日まで、組織向けは最大3年間、セキュリティ更新を受け取れます（2026年10月29日時点の Microsoft の公式ページ）。

Q. EOL の日付はどこで調べればよいですか？ A. 確定するのは各製品の公式のライフサイクルのページです。多くの製品をまとめて見るなら endoflife.date が便利で、API の JSON でも取れます。Ubuntu なら /usr/share/distro-info/ubuntu.csv にも入っています。

Q. EOL 版の Ubuntu で apt update が404になります。 A. その版のリポジトリが通常のミラーから外されたためです。次の版へ上げるのが本来の対処で、一時的には sources の URI を old-releases.ubuntu.com に向けると取得できます（修正はもう出ません）。

Q. pip で最新版が入らず、前の版が入ります。 A. 使っている Python がライブラリの対象より前の版の可能性があります。手元の Python 3.8 では、NumPy は 1.24.4、Django は EOL の 4.2.30 が入りました。python --version を確かめ、Python を上げます。

Q. 改行コードの EOL を変えるにはどうしますか？ A. エディタの改行コードの設定で LF・CRLF を選んで保存し直します。Git でそろえるなら .gitattributes に * text=auto eol=lf のように書きます。

まとめ

• EOL は End of Life の略で、サポートが終わり修正が出なくなること。止まる日ではなく、直らなくなる日。プログラミングでは End of Line（改行コード）の意味もある。
• EOS は販売終了とサポート終了の両方の意味で使われる。略語ではなく正式な名前と日付で確かめる。LTS にも EOL はある。
• 2026年10月29日時点で、Python 3.10・Node.js 20・Windows 10・Windows 11 24H2（Home・Pro）・Django 4.2 は EOL。Node.js 22 は残り183日。
• EOL 版の Ubuntu では apt update が404と終了コード100で止まり、EOL の Python では新しいライブラリが入らないか、黙って前の版（EOL のこともある）が入った。npm の EBADENGINE は既定では警告だけ。
• 棚卸し → 外に面したものから → 土台から上へ、の順で更新し、次の EOL を予定に入れる。延長サポートや隔離は時間を買う手段。

参考・出典

確認日はいずれも 2026年10月29日です。

• endoflife.date（トップ・各製品の API）：https://endoflife.date/
• endoflife.date「API v1」：https://endoflife.date/docs/api/v1/
• Python Developer's Guide「Status of Python versions」：https://devguide.python.org/versions/
• Node.js「Node.js Releases」：https://nodejs.org/en/about/previous-releases
• Ubuntu「Ubuntu release cycle」：https://ubuntu.com/about/release-cycle
• Oracle「Oracle Java SE Support Roadmap」：https://www.oracle.com/java/technologies/java-se-support-roadmap.html
• Microsoft Learn「Windows 10 Home and Pro」：https://learn.microsoft.com/ja-jp/lifecycle/products/windows-10-home-and-pro
• Microsoft Learn「Windows 11 Home and Pro」：https://learn.microsoft.com/ja-jp/lifecycle/products/windows-11-home-and-pro
• Microsoft Learn「拡張セキュリティ更新プログラム（Windows 10）」：https://learn.microsoft.com/ja-jp/windows/whats-new/extended-security-updates
• Microsoft「Windows 10 Extended Security Updates」：https://www.microsoft.com/en-us/windows/extended-security-updates
• Microsoft Learn「固定ライフサイクル ポリシー」：https://learn.microsoft.com/ja-jp/lifecycle/policies/fixed
• Microsoft Security Response Center「Customer Guidance for WannaCrypt attacks」：https://www.microsoft.com/en-us/msrc/blog/2017/05/customer-guidance-for-wannacrypt-attacks
• Cisco「製品の販売終了およびサポート終了に関するポリシー」：https://www.cisco.com/c/ja_jp/products/eos-eol-policy.html
• Django「Download」（Supported versions）：https://www.djangoproject.com/download/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。