OSS・依存ソフトのサポート期限をまとめて確認できる「EOL Timeline」を作りました
はじめに
EOL Timeline という依存ソフトウェア（OSS・フレームワーク・プラットフォームなど）のサポート期限をタイムライン形式でまとめて確認できる開発ツールを WEB アプリケーションとしてリリースしました。
この記事では EOL Timeline を作った動機や技術的な詳細、工夫点などを紹介していきます。
▼ ページリンク
作ろうと思ったモチベーション
いきなりですがみなさん以下のような経験をしたことがあるのではないでしょうか。
「サービスの中長期開発計画を立てよう！ところで依存ソフトウェアのサポート期限っていつだっけ？どこ見ればわかるんだっけ？」
「新しく OSS を導入したい！でもこの OSS っていつまでサポートされるんだろう？」
依存ソフトウェアのサポート期限を過ぎても使い続ければ脆弱性等に対応されず、結果的に自サービスがセキュリティインシデントに見舞われる可能性があります。
そのため依存ソフトウェアのサポート期限を把握し適宜アップデートしていく必要がありますが、それらのサポート期限は各ソフトウェアの公式サイトやレポジトリなどにまとめられており、すべての期限を俯瞰して確認するにはスプレッドシート等で自力でまとめなおすなど面倒な作業が必要になります。
大規模なアプリケーションであればあるほどより多くの外部ソフトウェアに依存している場合が多いため、その苦労も一入です。。。
endoflife.date などソフトウェアの EOL 情報をまとめてくれているサイトもありますが、それぞれのソフトウェアが独立したページで構成されており俯瞰して確認するには上記同様面倒な作業が必要になります。
▼ endoflife.date
EOL Timeline とは
EOL Timeline は上記の課題感を軽減すべく、ソフトウェアのサポート期限を簡単に俯瞰できるように構築された WEB アプリケーションです。
EOL Timeline はソフトウェアが一覧表示されている「サイドメニュー」と選択されたソフトウェアバージョンのサポート期限が描画される「タイムライン」で構成されています。
サイドメニューには各種ソフトウェアとそのバージョンが一覧で表示されており、ここで選択したものがメイン領域のタイムラインに反映されます。
ソフトウェアの数が多いため基本的には必要なものを検索して選択するようなイメージです。
タイムラインには選択されたソフトウェアバージョンの release~EOL（サポート期限） までの期間が視覚的に表示されており、複数ソフトウェアの期間を俯瞰して確認することができます。
またタイムラインは「年・四半期・月」単位での表示が可能なので、ざっと確認したいときは年単位や四半期単位、より細かく確認したいときは月単位など確認粒度に応じて表示変更が可能となっています。
上記により endoflife.date ではできなかった複数ソフトウェアを跨いだサポート期限の俯瞰的な確認を実現しています。
技術詳細
技術スタック
本アプリケーションは以下の技術スタックで構成されています。
- typescript
- react
- react-router
- tailwind
- shadcn/ui
- frappe/gantt
今回アプリケーション自体がシンプルで静的ファイル配信で済ませたかったため SPA 形式でアプリケーションを作成するつもりでした。
上記のニーズと今後の拡張の容易さを鑑み react-router を採用しました。
shadcn/ui は今回初めて利用しましたがいい感じの UI が簡単に作れて感動しました。
frappe/gantt がガントチャートを描画するための OSS です。今回タイムラインを表現するために採用しました。
ガントチャートを描画するための OSS は他にも複数存在するのですが、frappe/gantt は軽量でシンプルな機能を提供しており、今回のアプリケーションの要件と合致していたため採用しました。
今回のような時間軸に沿ってバーを表示するのみであればかなり簡単にできるため、プロトタイピングなどで採用するには最適かと思います。
システム構成
（DNSとかは省略）
構成はとてもシンプルです。
EOL Timeline は SPA なので cloudflare pages の静的サイト配信機能を使ってファイルを配信しています。
endoflife.date の API については必要な段階でクライアントサイドから都度フェッチするような構成です。
こだわった点
安く動かすこと
特に広告とかも貼っていない完全に趣味のアプリケーションなのでできるだけお金をかけないことを目標としました。
前述のシステム構成はこの目標に則って検討しました。
cloudflare pages からのレスポンスはほとんどが長期間 CDN キャッシュの効く静的ファイルなので、この配信による料金はほぼかかりません。
アプリケーションの公開に伴って cloudflare register にてドメインを購入したためその代金（たしか1500円/年くらい）のみがこのアプリケーションの運用費用という形になりました。
lighthouse のスコア
ユーザ体験の最低限の担保のため lighthouse については常に green になるよう定期監視と改善を行っています。
具体的には performance は 90 点以上、それ以外は 100 点を目標として、毎週金曜朝位に github actions にて lighthouse アクションを実行しスコアの計測と検査を行っています。
スコアが閾値を割った場合には週末に対応しています。
目標の閾値については基本的には lighthouse:recommended をベースとしつつ performance を warn -> error と厳しく設定しています。
厳しくする理由として、performance は他の項目よりも広いユーザの体験に直接影響してくるもののため厳しく監視しています。
▼ 2025/09/01 時点のスコア
CI/CD
後述の Renovate によるパッケージの自動アプデ & 自動マージを安心して行うため、CI の充実に力を入れました。
パイプライン構成は以下の通りです。
PR・マージ双方で同様の CI ワークフローを実行しており、マージ時のみ CD ワークフローを実行しています。
品質チェックは全て CI ワークフローの中で実行しているため CD ワークフローにはデプロイ以外のアクションは含まれていません。
CI ワークフローでは lint, build, test, tsc, test-storybook, e2e-test, security-audit を行っています。
アプリケーションの規模にしては厚めの構成かと思いますが完全自動マージを実現するため厚くしました。
テストについては高速に回せるテスト（ユニットテスト=test、インテグレーションテスト=test,test-storybook）を充実させ e2e テストは必要最小限にすることを目指しました。
特にインテグレーションテストについてはユーザ体験に近いテストを高速に回せる方法のため、vitest-axe を用いた最低限の a11y や a11y 用のプロパティの付与（aria-labelなど）のテストは *.test.tsx に寄せ信頼性高く高速に回せるよう工夫しました。
これによって CI を 1 分程度で完了することができるようになっています
また信頼性・安定性を高めるため flaky なテストは徹底的に潰しています。
外部依存を極力排除したり test-storybook や e2e において要素の変化を検証するテストでは waitFor 等で待つことを徹底したりなどです。
これによって後述する Renovate の PR 自動マージも安定して動作させることができるようになりました。
Renovate
Renovate を導入し依存パッケージの自動更新を実現しています。（majorアップデートは手動）
CI を充実させたこともあり、自動マージは不安やストレスなく運用できています。
CI/CD の章にフロー図を用意したため詳細はそちらを参照いただければと思いますが、簡単なフローとしては「Renovate-bot が更新PRを作成 -> CI実行 & Renovate が自主 approve -> CI が成功 -> main にマージ」という流れになります。
Approve しているのは branch protection rule に準拠するためです。
これにより CI が失敗=依存OSSの更新によってアプリケーションが破壊されない限りは自動で依存OSSが更新される環境を作ることができました。
導入時に発生した問題（platformAutomerge について）
他の方が詳しい解説をいろいろ作成してくださっているため導入には特に難しいところはありませんでしたが platformAutomerge プロパティについては色々な記事とは挙動が異なり、結果無効にすることに至ったため備忘録的にメモを残そうと思います。
発生した問題としては platformAutomerge を有効にすると自動マージが行われないという問題です。
approve 済み & CI 成功状態でも以下のようなボタンから自動マージを手動で有効にしないと自動マージされないような状態でした。
なぜ自動マージが走らないのかは結局わからずじまいでしたが platformAutomerge 無効状態でも問題なくマージが行われているため一旦これで運用しています。
▼ 設定
node, pnpm を除外しているのは github actions のランタイムバージョンとの整合性を保つためです。
その他の設定の詳細については色々な方が解説を上げてくださっているため割愛します。
AI との協働開発
コーディングエージェントを使った本格的な開発を行なっていなかったためこのアプリケーションを機にがっつり協働開発してみました。
chatGPT 自体は以前から契約しており、またちょうど gemini cli で発表された時期だったため chatGPT + gemini cli の組み合わせで開発を行いました。
今後の開発に活かす意味も込めて良かった点・微妙だった点・今後へのまとめを残します。
がっつり協働開発したのが初めてなこともあり反省点の方が多くなってしまいましたが全体としての開発体験はとても良かったです。
良かった点・やってよかったこと
- 初期のプロトタイピングの速度が向上した
- 簡単な要件・仕様を入力するだけでそれらしい状態にしてくれるため最初のブラッシュアップの速度と精度が向上した感覚
- 本質以外の作業にかかる時間が大幅に短縮された
- storybook の環境整備やテスト環境の構築など本質的なプロダクションコード以外に割く作業時間が大幅に削減されました
- エラー分析が効率的に行えるようになった
- とりあえずエラー文を chatGPT に投げることで 7~8 割くらいのエラーは解決できる印象です
- 作業計画を立てさせ、TDD に倣った開発フローで作業してもらったこと
- こちらの要求に対して実装計画を立てさせ、それに沿って TDD 方式で作業をさせていました
- 計画を立てさせレビューすることで過不足ないアプリケーションを作成でき、また TDD 形式で作業をさせることで過剰なコードを抑制できたためこの方式をとって良かったと感じています
- 動作確認スクリプトを充実させたこと
- 上述の TDD にも繋がりますが、動作確認スクリプト（lint, tsc, build, test, test-storybook, e2e）をプロジェクト早期に整備し、修正のたびに成功することを確認させることでフィードバックループを高速に回し結果的に作業が早く完了していると感じました。
微妙だった点・反省点
- 古い構文を使ってしまう
- 特に命令しないと関数宣言に function 構文を使ったりし始めます
- 古いオプションを使ってしまう
- frappe/gantt を使った実装を行なってもらう際、現在の利用バージョンにはないプロパティを利用しようとして袋小路に陥っているケースがありました
- 「ツールチップに〇〇と表示したいんだけどできる？」みたいなプロンプトを投げていたのですが事前にプロパティなどの実現可否の簡単な調査は必要です
- UI系の修正には注意が必要
- storybookテストの結果などから修正指示を投げていたのですが袋小路に陥って解決できないケースが多くありました
- 当然ですが AI にはブラウザでの見た目は見えないため、frappe/gantt のようなクライアントサイドで DOM 挿入して描画されるようなコンポーネントのデバッグは苦手です
- その場の気づきで仕様やバリデーションを追加するので要件定義書・仕様書との整合性を保つのが大変
- 開発がとんとん拍子に進んでいくため、最初に作成した仕様書に書いていないこともその場の気づきで実装してしまうことが多々ありました
- 仕様書が陳腐化してしまい後から見返した際に仕様書と挙動が噛み合わないことがありました
今後に活かすこと
- コーディングルールに推奨構文などを明示する
- nodejs であれば「ES2022以降の構文を利用すること」などをコンテキストファイル（gemini cli の場合は GEMINI.md） に記載しておくことでモダンな構文でコーディングを進めてくれるため明示しておくべきかと思います
- 要件定義と仕様書の更新も AI の開発フローに組み込み、実装と同時に AI に更新させる
- 9/9現在だと kiro や spec kit など仕様書駆動開発のためのツールがリリースされているためこれをプロジェクト初期段階に導入するのが良いかもしれません
- （どうしても UI の修正まで AI 作業で完結したい場合は）snapshot など AI が理解可能な形で UI を表現する方法を取り入れる
今後やりたいこと
- 各ソフトウェアの詳細ページ作成（/nodejs, /react 的な）
- サイドメニューのソフトウェアのカテゴリ分け
- ユーザカスタムデータの入力とタイムラインへの反映
- ユーザのカスタムデータと合わせてサポート期限を見れるようにすることでユーザ個別のスケジュール策定に役立てるようにしたい
- 例）〇〇案件と EOL 期限を俯瞰して確認する
- 広告の追加
- ユーザが増えてきたら収益化したいなと思っています
おわりに
初めての技術記事ということもあり読みにくい部分や構成になっている部分があったと思いますが、最後まで読んでいただきありがとうございました🙇
今後もなにか投稿できればと思っていますので見かけたら読んでいただけると嬉しいです！
ぜひ EOL Timeline をあなたの開発に役立ててもらえると嬉しいです！
Discussion