何が技術を交代させるのか — 自社のスタックがその軌跡上にあるかを点検する方法

• はじめに — 一覧ではなくパターンを見るための記事
• 交代を生む五つの力
  • 1. プラットフォームが機能を吸収する
  • 2. 運用負担が利得を超える
  • 3. 保守人員がボトルネックになる
  • 4. ライセンスが変わる
  • 5. 問題の定義が移動する
• 自社のスタックがその軌跡上にあるかを確認する方法
  • 文書で確認すること
  • コマンドで確認すること
  • 一覧として管理すること
• 移るのか、待つのか
• 最後に — 一覧を扱う態度について
• あわせて読みたい
• シリーズ

はじめに — 一覧ではなくパターンを見るための記事

前の三回で30あまりのプロジェクトを見ました。一覧そのものは時間が経てば古びます。残るのはパターンです。何が交代を生み、自社のスタックで同じ兆候をどう見分けるか。

前提を改めて書いておきます。場所を譲ったプロジェクトの多くは自分の時代には正しい選択でした。 以下の力はおおむねプロジェクトの品質とは無関係に働きます。

交代を生む五つの力

1. プラットフォームが機能を吸収する

最も多いパターンです。PhantomJSはブラウザがヘッドレスモードを内蔵したことで、jQuery MobileはCSSとタッチイベントが標準になったことで場所を譲りました。

これは失敗ではありません。ツールが需要を証明すると、プラットフォームがその需要を取り込みます。 あるツールが埋めている穴が、いずれ標準で埋まる性質のものかを問えば、そのツールの残り寿命をおおよそ見積もれます。

2. 運用負担が利得を超える

KafkaがZooKeeper依存を外したのが代表例です。検証済みの外部システムを借りるという初期判断は合理的でしたが、別のアンサンブルを運用するコストが発生し続けました。

ここで見るべきシグナルは明確です。本体ではなく付属物の運用に費やす時間の割合です。この割合が大きくなると、いずれ本体がその機能を吸収するか外します。

3. 保守人員がボトルネックになる

このシリーズで最も繰り返された理由です。LibSassの廃止告知は言語の進化に追随するエンジニアリング余力がないと率直に書き、ingress-nginxの引退告知は数年にわたり一人か二人が余暇に維持してきたと述べ、Create React Appの廃止告知も活発なメンテナーがいない点を挙げました。

依存関係のリスクはコードの品質ではなく、そのコードを維持できる人の数にあります。 そしてこの数はスター数やダウンロード数ではまったく見えません。

4. ライセンスが変わる

技術的な理由がまったくないのに移動が起きる唯一の軸です。事実だけ整理するとこうなります。

その後の揺り戻しも併せて見ないと均衡を欠きます。Elasticは2024年8月29日にAGPLを選択肢として追加し、既存のライセンスをなくすのではなく一つ加えるのだと述べ、Redisは2025年5月1日にRedis 8からAGPLv3を追加しました。

そして各変更から生まれたフォークです。

三つのフォークがいずれも財団へ行った点がこの流れの核心です。ライセンス変更に対する市場の反応は、別の会社へ移ることではなく中立的な運営主体を作ることでした。

ここで動機を推測はしません。各社は自らの発表文で理由を述べており、それをそのまま読めば十分です。実務者にとって重要なのは一つです。ライセンスは変わりうる値であり、たいてい遡及しません。

5. 問題の定義が移動する

TSLintはよくできたリンターでしたが、パーサーを差し替え可能に設計した側のほうが長く残りました。rktは代替ランタイムでしたが、結果として残ったのは特定のランタイムではなく標準インターフェースでした。

個別の実装で解いた問題は、インターフェースで解いた側に押される傾向があります。 ツールを選ぶとき、それがインターフェースを定義する側なのか特定の実装なのかを区別しておけば、5年後にどちらが残るかを推し量りやすくなります。

自社のスタックがその軌跡上にあるかを確認する方法

印象ではなく確認可能なシグナルで見ます。

文書で確認すること

• 公式文書にサポート終了日があるか。言語とフレームワークにはたいてい存在します。
• READMEやサイトに廃止の文言があるか。BowerとMoment.jsはリポジトリが生きたまま新規利用を勧めないと書いています。
• 後継プロジェクトが指定されているか。RomeはBiomeを、Heapsterはmetrics-serverを明示しました。
• エスカレーション経路が文書化されており、最近実際に機能した実績があるか。

コマンドで確認すること

リポジトリのアーカイブ状態と最終プッシュ時刻はAPI一回で確認できます。

# アーカイブ状態と最終プッシュ時刻
OWNER_REPO="kubernetes/ingress-nginx"
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${OWNER_REPO}" \
  | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('archived   :', d['archived'])
print('pushed_at  :', d['pushed_at'])
print('open_issues:', d['open_issues_count'])
"

より重要なのはマージ権限を何人が持っているかです。貢献者が多くてもマージする人が少数なら、その少数がバス係数そのものです。

# 直近100件のマージ済みPRにおけるマージ者の分布
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${OWNER_REPO}/pulls?state=closed&per_page=100" \
  | python3 -c "
import sys, json, collections
prs = json.load(sys.stdin)
c = collections.Counter(p['merged_by']['login'] for p in prs if p.get('merged_by'))
for who, n in c.most_common(10):
    print(f'{n:4d}  {who}')
print('distinct mergers:', len(c))
"

一覧として管理すること

主要な依存関係ごとに四つの値を書いておくだけで、多くの事故を防げます。公式のサポート終了日、リポジトリのアーカイブ状態、指定された後継プロジェクト、そしていま移るとしたらかかる費用のおおよその見積もりです。

最後の値が肝心です。導入時点で離脱コストを一度見積もっておけば、後で移るかどうかを感情ではなく数字で決められます。

移るのか、待つのか

すべての廃止告知が即座の行動を求めるわけではありません。二つの軸で分けると判断が容易になります。

第一の軸はセキュリティ露出です。 セキュリティ修正がもう出ず、その構成要素がネットワークに露出しているなら最優先です。ingress-nginxに関する声明が、引退後も使い続ける選択は利用者を攻撃にさらすと明確に警告したのがこの場合です。逆にCIの中だけで動くビルドツールなら、同じ廃止告知でも緊急度は異なります。

第二の軸は代替の成熟度です。 後継が公式に指定され移行文書があれば費用は予測可能です。逆に代替が複数あってどれも支配的でないなら、もう一巡待つ選択が合理的なこともあります。

二つの軸を掛け合わせるとこうなります。

• 露出が高い + 代替が明確 → いま移ります。
• 露出が高い + 代替が不明確 → まず露出を減らします。隔離、アクセス制限、商用延長サポートの検討。
• 露出が低い + 代替が明確 → 次の大きな作業にまとめて処理します。
• 露出が低い + 代替が不明確 → 一覧に載せ、四半期ごとに状態だけ確認します。

そして忘れがちな選択肢が一つ。メンテナンスされているツールをあえて置き換えることもコストです。 Gruntのようにリポジトリが生きていてセキュリティ修正が提供されるツールなら、流行が過ぎたという理由だけで移る必要はありません。

最後に — 一覧を扱う態度について

このシリーズを書きながら守った規則がいくつかあります。他所で同じ主題を扱うときにも役立ちそうなので残しておきます。

• 利用者とメンテナーが残っているプロジェクトを死んだと書きません。事実はたいてい場所を譲ったか用途が狭まったです。
• なぜやめたのかを推測しません。公開された内容だけを伝え、出典を示します。
• 確認できなければ外します。印象は根拠ではなく、出典を示せない利用量の傾向は引用しません。
• 何を残したのかを必ず書きます。 多くのプロジェクトは名前より長く残るものを残しました。

最後の項目がこのシリーズを書いた理由です。Atomが残したElectron、rktが作った標準化への圧力、ZooKeeperが定義した調整サービスというカテゴリ。プロジェクトの名前が一覧から消えても、そのプロジェクトが証明したものはいま私たちが使っているツールの中に入っています。

いま皆さんが使っているスタックも、いつかこの一覧に載るでしょう。それは悪いことではなく、そのツールが何かを証明したという意味である可能性が高いのです。

状態情報は2026-08-12に直接確認しました。プロジェクトは再び活発になることもあるので、最新の状態はご自身で確認してください。

あわせて読みたい

• バス係数は決められる人の数だ
• オープンソースのガバナンスが壊れるとき
• オープンソースライセンスの変化 2026
• Airflow 2 EOL移行の現実
• レガシーコードと向き合う
• ツール: SW定期点検チェックリスト · テキスト比較 · Gitプレイグラウンド

シリーズ

1. ビルドとフロントエンドツール
2. インフラとコンテナ
3. データストアとキュー
4. 言語とフレームワーク、ランタイム
5. 何が技術を交代させるのか (この記事)