先に要点
- この記事の「枯れた技術」は、「もう新しい話題にならないが、地味に動き続けている、当たり前の道具」を指す。Bash / sed / awk / make / cron / SQL(言語仕様) / Vim / C / Apache HTTPD / Subversion / jQuery のような顔ぶれ。派手ではないが、止まらない側。
- これは 「いまも本流の主役」(PostgreSQL / Linux / Python / TypeScript / Kubernetes / Java の最新 LTS など、まだ新機能で話題になり続ける技術)とも、「主役を退いたレガシー」(COBOL / VB6 / Delphi など)とも別物。主役と枯れたとレガシーは三層に分けて考えるのが分かりやすい。
- 枯れた技術を選ぶメリットは 「実績豊富」「運用知見が世間に蓄積」「派手な変化に振り回されない」「学習投資が長持ちする」「AI が圧倒的に書ける」「OS / シェルに最初から入っている」。攻めの差別化要素ではないが、毎日の作業の効率を支える土台として効く。
- デメリットは 「新機能やパラダイムは増えない」「採用ブランディングでは弱い」「習熟に時間がかかる割に話題性が薄い」。攻めの差別化はできないので、主役技術と組み合わせて使うのが基本。
- 判断軸は 「使う頻度」「学習コストの回収期間」「運用環境(サーバ / シェル / バッチ)」「主役技術への置き換えコスト」。新規プロジェクトの主役は別途選び、その周辺の運用・ビルド・テキスト処理は枯れた技術に任せるのが現実的なバランス。
「最新の React Server Components を試したい」「Bun に乗り換えるべきか」「Rust で書き直すべきか」 ── 技術選定の話は常に新しい方向に流されがちです。一方で、「枯れた技術を選ぶ」という戦略には、新しい技術の派手さに隠れて見えにくい価値があります。
ただし日本語の「枯れた」はあいまいで、いろんな意味で使われるので、最初に整理しておきます。
主流 / 枯れた / レガシー — 3 つに分けて考える
技術の状態を「新しい / 古い」の二択で語ると、たいてい話が雑になります。実用的には次の 3 層 に分けるのが分かりやすい。
| 分類 | 状態 | 代表例 |
|---|---|---|
| 主流(現役の主役) | 新機能のリリースが活発、新規プロジェクトの第一候補、SNS や Conference で話題 | PostgreSQL / Linux / Python / TypeScript / Kubernetes / Java(最新 LTS)/ Nginx / Redis / Go |
| 枯れた(地味だが現役の道具) | 派手な変化はもう終わったが、世界中の現場で当たり前に使われている。新しい話題にはならない | Bash / sed / awk / make / cron / SQL(言語仕様)/ Vim / Emacs / C / Apache HTTPD / Subversion / jQuery / XML |
| レガシー(主役を退いた) | 新規開発はほぼ消滅、保守需要中心、採用市場が縮小 | COBOL / VB6 / Delphi / Classic ASP / 古い Perl 案件(レガシー言語の市場価値で扱う側) |
ポイントは、主流と枯れたは別物だということ。PostgreSQL や Linux は確かに長く使われていて成熟していますが、毎年のように新機能(pgvector、io_uring、論理レプリケーション機能など)が話題になり、新規プロジェクトでも積極的に採用されます。これは「主流」であって、「枯れた」と呼ぶには活発すぎる。
一方、Bash や sed や make や cron は、もうここ 10〜20 年で 新しい話題はほとんどありません。でも世界中のサーバで毎日動いていて、シェル作業から CI/CD のスクリプトまで、当たり前のように使われています。これが本来の「枯れた」。
そしてレガシーは「過去の資産が残っているから保守されているだけ」で、新規プロジェクトに採用される側ではない。記事 418 で詳しく扱っています。
本記事の主題は真ん中の「枯れた」。主流に乗ることでもなく、レガシーに逃げることでもない、「もう話題にならないが、当たり前に動き続ける道具」を意識的に選ぶ戦略を扱います。
枯れた技術の特徴
「枯れた」と「新しい」を並べて、性質の違いを整理します。
| 軸 | 枯れた技術 | 新しい技術 |
|---|---|---|
| 登場時期 | 20〜50 年以上前 | 1〜5 年前 |
| 新機能の頻度 | ほぼなし(必要なものは出揃った) | 頻繁に出る |
| 挙動の安定性 | 長年変わらず、破壊的変更がほぼない | 破壊的変更が起きうる |
| SNS / 技術ブログでの露出 | ほぼなし(語ることがない) | 盛ん |
| 運用ノウハウ | 世界中の現場で枯らされている | 少数の早期採用者のみ |
| 学習投資の寿命 | 20 年単位で使える | 3〜5 年で変わるリスク |
| OS / シェルへの組み込み | 標準で入っていることが多い | 別途インストールが必要 |
| AI の出力品質 | 非常に高い(コーパスに膨大) | 不安定なこともある |
| 採用ブランディング | 弱い | 強い |
ここで誤解しないでほしいのは、「枯れた = 古いだけ」ではないこと。Bash や make は 30〜50 年前に作られた道具ですが、今日も世界中で使われ、AI に書かせると非常に高品質な出力が返ってきます。「変化が止まったから消えた」のではなく、「変化が止まる場所まで成熟した」のが枯れた技術です。
枯れた技術を選ぶ価値 — 6 つの利点
「もう新しい話題にならない道具」を意識的に選ぶことで得られる価値を整理します。
①実績と運用ノウハウが世界中に蓄積
Bash や cron や sed のような道具は、世界中のサーバで毎日動いている。「自分のチームが直面する問題は、ほぼ誰かが先に解決している」状態が完成している。Stack Overflow / man / 数十年分のブログ記事まで、脱出ルートが圧倒的に豊富。
② 学習投資が長く効く
新しい技術は3〜5 年で大きく変わることがある(Webpack → Vite、Redux → Zustand など)。枯れた技術は 20 年単位で使える。Bash や Vim や make を覚えると、定年まで腐らずに使えるベーススキルになる。
③ 派手な変化に振り回されない
Next.js の頻繁な破壊的変更のような騒ぎがほぼない。「動いている = しばらく動き続ける」という安定感は、運用と精神衛生の両方に効く。
④ OS / シェルに最初から入っている
Bash・sed・awk・grep・find・cron・SQL クライアントは、ほぼすべての Linux / macOS に標準で入っている。追加インストールが要らない / 環境差で詰まらない。CI / コンテナ / 古いサーバでも、いつでも使える前提で書ける。
⑤ AI が圧倒的に書ける
LLM の学習コーパスには、過去 20〜30 年分の Bash / sed / awk / make / SQL コードが大量に含まれている。枯れた技術のコードは AI の出力品質が非常に高い。「awk で集計するスクリプト」「Makefile でビルドジョブ」を AI に頼めば、ほぼ一発で実用品が返ってくる。
⑥ ベンダー / コミュニティの心変わりに巻き込まれない
枯れた技術は OSS で長年運営されており、「特定企業が方針転換して打ち切る」リスクが構造的にない。Vercel が料金を変える、Google がプロジェクトを止める、のような事業継続リスクと無縁。
要するに、枯れた技術は 「主役にはならないが、いつ呼んでも応えてくれる道具」。攻めには使えなくても、守りと日常作業の効率化で着実に効きます。
枯れた技術のデメリット
良いことばかりではありません。リスクとセットで把握しておきます。
新機能や新パラダイムは出てこない
Bash や sed や make に「次のメジャーアップデートで便利な新機能が来る」ことはほぼない。枯れた = もう変化しない ので、新しい開発体験は提供してくれない。攻めの差別化要素にはならない。
採用ブランディングでは弱い
「うちは Bash と cron と Subversion です」では、求人票で若手を引きつけるのは難しい。「枯れた技術を使っている = 古い会社」と見られがち。主役技術(PostgreSQL / Python / Kubernetes など)や新しい技術と組み合わせて見せ方を作る必要がある。
習熟に時間がかかる割に話題にならない
Vim や awk や Bash を本格的に習熟するのは決して簡単ではない。だが SNS で「Vim 極めた」と言っても 2026 年の今は誰も話題にしない。努力が外向きの評価になりにくいのはレガシーとも似た側面。
主役の代わりにはならない
枯れた技術は「主役」「アプリ本体」を担えない。Bash で Web サービスを書く、awk でデータベースを設計する、のような使い方は無理。あくまで「主役の周辺で動く便利な道具」として位置づけるのが正解。
「枯れた技術 = 無敵」ではなく、「主役にはなれないが、主役の足元を支える」役割と理解して選ぶのが現実的です。
どの層を、どの場面で使うか
3 層(主流 / 枯れた / レガシー)を、場面別にどう使い分けるか整理します。
| 場面 / 領域 | 主役に置くもの | 枯れた技術の出番 |
|---|---|---|
| 新規 Web サービスのアプリ層 | 主流(Next.js / Rails / Django / Go) | — |
| 新規サービスの DB | 主流(PostgreSQL / MySQL) | — |
| 新規サービスの OS / コンテナ | 主流(Linux 最新 LTS) | — |
| CI/CD のビルドスクリプト | — | 枯れた(Bash / make / シェルスクリプト) |
| 定期バッチ / ジョブスケジュール | — | 枯れた(cron / crontab / シェル) |
| ログ解析 / テキスト処理 | — | 枯れた(grep / sed / awk / jq) |
| 本番サーバでの調査作業 | — | 枯れた(Vim / ssh / tail / less) |
| DB 操作 / 集計 | 主流(PostgreSQL クライアント / ORM) | 枯れた(SQL の言語仕様そのもの) |
| 古い社内ツール(Subversion / Apache) | — | 枯れた(動くなら無理に置き換えない) |
| レガシー業務の保守 | — | 該当しない(レガシーの領域) |
| AI / 機械学習 | 主流(Python / PyTorch / Anthropic SDK) | — |
| 個人開発の MVP | 新しい技術 + 主流 | シェル周りは枯れたで補う |
ポイントは 「アプリ本体や DB は主流」「シェル・バッチ・ログ・テキスト処理は枯れた」「過去資産はレガシーで保守」という三層の役割分担。枯れた技術は主役を取りに行く道具ではなく、主役の手元を支える便利な道具として理解するのが筋。
判断軸 4 つ
「これを枯れた技術で書くか、主流の技術で書くか」を決めるための具体的なチェック項目です。
迷ったら「主役は主流、周辺は枯れたで賄う」と覚えるとだいたいハマります。
キャリア観点の判断
エンジニア個人のキャリアで、枯れた技術をどう位置付けるかを整理します。
主役技術だけ追うとベースが薄い
毎年新しいフロントエンドフレームワークを追い続けても、3〜5 年で半分は陳腐化する。Bash や SQL や Vim の習熟は 引退まで使えるので、長期的な投資としてリターンが大きい。
枯れた技術はベーススキル
シェル・SQL・基本コマンドは、どんなチーム・どんな言語スタックでも要求される。主役技術が何であれ、土台として通用する。「Vim でログを grep する」のような基本動作が早いと、現場全体の作業速度が変わる。
理想は「主流 + 枯れた」の組み合わせ
「主流技術で稼ぎ、枯れた技術で日常作業を効率化する」のがバランス良い。Python や TypeScript を本職にしつつ、シェル / awk / make / Vim を高速に使えると、市場価値が一段上がる。
レガシーへの逃げ込みとは違う
枯れた技術を選ぶことと、レガシーに張ることは別。枯れた技術は今日も毎日使う道具であって、保守需要に逃げ込む選択ではない。「シェル極めた」と「COBOL 専業」はキャリアの意味がまったく違う。
「主流 = メインで稼ぐ」「枯れた = ベーススキルとして長持ち」「レガシー = 保守需要」の 3 軸を持つと、キャリア設計が立体的になります。
「主流 + 枯れた」の組み合わせ例
組織の規模・フェーズに応じた、現実的な技術スタックの例を整理します。
| フェーズ | 主役(主流 + 新しい技術) | 枯れた技術での補強 |
|---|---|---|
| スタートアップ MVP | Next.js / PostgreSQL / Linux / Drizzle | Bash / make でデプロイ、cron でバッチ、sed/awk で運用ログ整形 |
| スタートアップ成長期 | + Redis / Kubernetes / CI/CD | シェルスクリプトでの定型運用、SQL チューニング、Vim での緊急対応 |
| 中堅事業会社 | Java(LTS)/ Spring / PostgreSQL | Jenkins ジョブのシェル、ログ集計の awk、社内ツールの Apache HTTPD |
| 大企業基幹 | レガシー保守 + API ゲートウェイ層に Go | シェル / make / SQL ベースの運用基盤 |
| 個人開発 | 主流 + 興味のある新技術 | Bash で雑に試す、make でビルド統一、cron で定期実行 |
「主役技術 = 何で書くか」、「枯れた技術 = どうやって動かして / 監視して / 集計するか」 という分業が、現実の現場では普通に成立しています。
AI 時代の「枯れた技術」の意味
AI コーディング環境(Claude Code など)が普及した今、枯れた技術の価値はちょっと意外な形で上がっています。
AI は枯れた技術を圧倒的に書ける
LLM の学習コーパスには、過去 20〜30 年分の Bash / sed / awk / make / SQL コードが大量に含まれている。「awk でログを集計するワンライナーを書いて」「make でビルドジョブを組んで」のような依頼は、ほぼ一発で実用品が返ってくる。
最新技術は AI が苦戦することもある
2024 年以降に出た技術(Bun / Qwik など)は、AI の学習データが追いついていない場面がある。古い API を提案してくることが多く、ドキュメントを毎回 AI に見せる必要がある。
「自分で書かない」が現実的に
Vim / awk / sed / make を覚えるコストは決して低くなかったが、AI に頼めば書けてしまう時代になった。「枯れた技術を読めれば書けなくてもいい」運用が現実的になり、ベーススキルとしての敷居が下がっている。
レガシー保守との関係
枯れた技術のコードは AI が高精度で読み解く。レガシー保守の入り口として AI が刺さるのは、枯れた技術のドキュメントとサンプルが世界中に蓄積されているからでもある。
「枯れた技術 + AI」 の組み合わせは、「書ける人が減ったが、AI が代わりに書ける」という需給バランスの変化を起こしています。手作業の習熟は前ほど報われないかもしれませんが、「読めて指示できる」レベルは引き続き重要です。
「枯れた技術」選びでよくある失敗
最後に、枯れた技術を選ぶ判断でハマりやすい失敗パターンを整理しておきます。
「主流」「枯れた」「レガシー」を混同する
PostgreSQL を 「枯れた」と呼ぶと違和感がある(実態は主流)。COBOL を 「枯れた」と呼ぶと「いま採用してもいい」と誤解されかねない(実態はレガシー)。3 つは別物として呼び分けるのが第一歩。
主役に枯れた技術を使う
Bash で Web サービスを書く、awk で帳簿システムを作る、のような「主役を枯れた技術に任せる」設計は無理がある。枯れた技術は道具、主役は別途選ぶ。
EoL のバージョンを「枯れた」と誤認
「枯れた = もう更新しなくていい」と誤解して、EoL のバージョンを使い続ける。PHP 5.6 / Java 8 / Python 2 / Node 18 などはサポート切れ。Bash や make のような枯れた技術と違って、サポート中の言語・OS は最新を追い続けるのが原則。EoL は endoflife.date で確認。
枯れた技術ばかりを学ぶ
Vim / awk / sed を深く学ぶのは価値があるが、それだけだと現代の Web 開発から取り残される。主流の技術と組み合わせて学ぶのが現実的。「シェル + Python」「make + Git + GitHub Actions」のような組み合わせがバランス良い。
「枯れた技術を使う」は、レガシーに逃げ込むことでも、主役の座を譲ることでもない。「主役の手元を支える道具として、意識的に選び続ける」姿勢が肝。
「枯れた技術」に関するよくある質問
Q. 「主流」「枯れた」「レガシー」「終わった」をもう一度整理してください。
A. ① 主流:PostgreSQL / Linux / Python / TypeScript / Kubernetes など、いまも新機能で話題になり続け、新規プロジェクトの第一候補になる技術。② 枯れた:Bash / sed / awk / make / cron / SQL / Vim / C / Apache HTTPD / jQuery など、新しい話題にはならないが、世界中で毎日使われている地味な道具。③ レガシー:COBOL / VB6 / Delphi / Classic ASP など、主役を退いて保守需要のみ残った技術(記事 418 の領域)。④ 終わった(EoL):PHP 5.6 / Python 2 / Java 8 のように、サポートが切れて移行必須のバージョン。本記事は ② を主題にしています。
Q. PostgreSQL や Linux は「枯れた」ではないんですか?
A. 本記事の定義では「主流」に分類します。確かに長く使われていますが、PostgreSQL は pgvector・論理レプリケーション・パフォーマンス改善などで毎年話題になり、新規プロジェクトでも積極的に採用されます。Linux も同様で、io_uring や eBPF のような新機能が今も活発に追加されています。「成熟しているが、まだ新しい話題が出続ける」のは「枯れた」というより「主流」と呼ぶほうが自然です。
Q. Bash や Vim を本格的に学ぶ価値はありますか?
A. あります。シェル / Vim / awk / sed の習熟は、20 年以上使えるベーススキルです。AI が書いてくれる時代になっても、読めて指示できるレベルは引き続き必要。とくに本番サーバでの調査や CI/CD のメンテナンスでは、シェルが速く叩ける人と叩けない人で作業速度が大きく違います。
Q. Subversion や jQuery はまだ使っていいですか?
A. 動いているなら無理に置き換えないのが基本。Subversion は Git に押されましたが、社内ツールで安定運用しているなら問題なし。jQuery も同様で、既存システムの保守なら現役です。新規プロジェクトでは Git や Vanilla JS / Vue / React を選ぶのが普通ですが、これは「主流に乗る」という判断であって、「枯れた jQuery が悪い」わけではありません。
Q. 採用市場で「枯れた技術しかできない」と見られませんか?
A. 枯れた技術だけだと不利ですが、主流 + 枯れたの組み合わせは強い。「Python(主流)+ シェル(枯れた)」「TypeScript(主流)+ Vim(枯れた)」のような組み合わせは、現場での即戦力性が高く評価されます。「主流で稼ぐ、枯れたで生産性を上げる」キャリア設計が現実的。
Q. 個人開発でも枯れた技術を使うべきですか?
A. 主役は主流の技術(Next.js / Python / Go など)を選び、周辺(ビルド・デプロイ・バッチ・ログ整形)は枯れた技術を活用するのがバランス良い。Bash で Makefile を書いて make でデプロイ、cron で定期実行、awk で集計、というのは個人開発でも十分実用的です。
Q. AI 時代に枯れた技術を覚える意味は?
A. あります。AI に枯れた技術のコードを書かせるとき、「読んで判断できる」レベルは必要。AI が出した awk スクリプトが意図通りか確認できないと、雑に使ったときに事故が起きます。「自分でゼロから書く必要は薄いが、読めて指示できる」レベルが、今後 10〜20 年使える投資先です。
参考リンク
- endoflife.date: 各種技術の EoL 一覧
- TIOBE Index: tiobe.com/tiobe-index
- ThoughtWorks Technology Radar: thoughtworks.com/radar
- 「Choose Boring Technology」 — Dan McKinley: boringtechnology.club
- GNU Bash 公式: gnu.org/software/bash
- Vim 公式: vim.org
- 「人月の神話」 — Frederick Brooks: 古典的に読まれている開発論の名著