「Perlエンジニアがいなくなった」「誰もこのコードを触りたがらない」。Perl/CGI/Mojoliciousで動くECサイトを運用していると、一度はこの不安に突き当たるのではないでしょうか。

そして決まって現れるのが、「今のうちに全面リプレイスすべきです」というベンダーの提案です。しかし、その提案に飛びつく前に、一度立ち止まって考えてみてください。 本当に今、全面リプレイスが必要なのでしょうか 。

この記事では、「Perlは死んだ言語」という煽りではなく、全面リプレイスが本当に必要かどうかを読者自身が判断できる材料を提示します。技術スタックを売り込むのではなく、「事業を止めずに改善する」という選択肢があることをお伝えするのが目的です。

Perlは「死んだ言語」ではないが、エコシステムは縮小している

まず正直にお伝えしておきたいことがあります。Perlは日本のEC業界で今も大量に稼働しています。しかし、それを見て「もうリプレイスするしかありません」と思わせるベンダーが多いのも事実です。この記事は、その手の主張への反論として書いています。

今日も動いているPerl/CGI/Mojoliciousシステムには理由があります。安定性と、10年以上積み上げてきた決済連携・制度対応の実績です。一方で、Perlを取り巻くエコシステムが縮小しているのも、また事実です。

CPANの新規PAUSEアカウント登録者数（＝新しくPerlのモジュールを公開し始めた人の数）を見ると、2025年は108件でした。2024年の97件からはわずかに増えていますが、ピークだった2012年の450件と比べると、その差は歴然です1。CPAN全体では43,500を超えるディストリビューションが公開されていますが1、新しく参入する人は着実に減っています。

一方でおもしろいのは、プログラミング言語の人気ランキング「TIOBE Index」でのPerlの動きです。2025年9月には27位から10位へ急上昇し、12月時点では9位に達しました。これは、その年で最も劇的な順位変動の一つだったと言われています2。

一見すると復権のように見えますが、実態は違います。Stack Overflowに投稿されるPerl関連の質問数は9年連続で減少しており、Perl5のコアリポジトリのGitHubスター数はわずか2,208。現代的な言語のリポジトリが数万スターを集めるのと比べると、活動は控えめです2。 順位は上がって見えても、実態としてのエコシステムは縮小し続けている 。これが「人がいない」という現場の実感の裏付けになっています。

求人市場からも同じ傾向がうかがえます。英国の求人統計サイトによると、Perlエンジニアの年収中央値はこの1年で33.33%下落し、£47,500になっています3（このデータは英国市場のものであり、日本市場の直接統計ではありませんが、Perlの労働市場が世界的に縮小傾向にあることを示す参考値として紹介します）。

全面リプレイスが必ずしも正解ではない理由

エコシステムが縮小しているなら、なおさらリプレイスすべきではないか——そう思うかもしれません。しかし、ここで急いで結論を出すのは危険です。

「ストラングラーフィグ・パターン」という考え方を提唱したMartin Fowlerは、こう述べています。

Replacing a software system that’s deeply embedded with business processes is never going to be an easy task. （事業プロセスに深く組み込まれたソフトウェアシステムの置き換えは、決して簡単な作業にはならない）4

これは決済連携や在庫管理、顧客データと密接に結びついたECシステムほど当てはまります。全面リプレイスには相応の期間と投資が必要になりますが、その間、新規機能の開発は事実上止まります。競合が新しい施策を打ち出している間、あなたのシステムは「作り直している最中」で動けなくなるのです。

技術スタックを売るのではなく、「事業を止めずに改善する」という選択肢があることを、まずお伝えしたいと思います。

先にやるべき3つの対策

全面リプレイスの前に着手できる対策は、大きく3つあります。いずれも「コードはそのまま、周りから整える」というアプローチです。

1. Docker化による開発環境の現代化

「動いているコードに触れるのが怖い」という感覚の多くは、実は環境面の不安から来ています。ローカルで同じ環境が再現できない、本番と挙動が違う——そうした不確実性を、まずDocker化で取り除きます。

Mojolicious公式のCookbookには、次のようなDockerfileの例が掲載されています5。

FROM perl
WORKDIR /opt/myapp
COPY . .
RUN cpanm --installdeps -n .
EXPOSE 3000
CMD ./myapp.pl prefork

公式のperlイメージには、cpanm（CPANモジュールのインストールツール）に加えてprove・perldocといった標準ツールも同梱されているため、特別な準備をしなくてもすぐに始められます6。

一点だけ注意が必要です。Mojoliciousの本番用サーバーであるhypnotoadは、デフォルトで自動的にデーモン化（バックグラウンドプロセス化）する仕様です。Dockerコンテナは「PID 1」のプロセスが動き続けることを前提にしているため、デーモン化されるとコンテナが意図せず終了してしまうことがあります。そのため、コンテナ内ではpreforkやdaemonコマンドの使用が推奨されています5。

イメージサイズをさらに抑えたい場合は、Alpine Linuxをベースにし、ビルドに使ったコンパイラなどのツールを最後に削除する手法もあります7。ただしこの手法は少し古い記事で紹介されたもので、Mojolicious公式もCookbookのContainers節を参照するよう案内しています。実際に採用する際は、執筆時点の情報を確認してください。

2. テスト自動化で変更の恐怖を取り除く

「触ったら壊れるかもしれない」という属人化の恐怖は、テストが無いことに起因しているケースが少なくありません。ここで大切なのは、「まず全部にテストを書く」ことではなく、「触る箇所からカバレッジを可視化していく」という段階的なアプローチです。

Perlには、テストカバレッジを後付けで計測できるDevel::Coverというモジュールがあります。Perlの内部処理（op）をカウント用の関数に置き換えることでコードの実行状況を記録する仕組みで、公式ドキュメントでは次のように説明されています。

Code coverage data are collected by replacing perl ops with functions which count how many times the ops are executed.8

perl -MDevel::Cover yourprogのように既存のプログラムを実行するだけでデータを収集でき、coverコマンドでHTMLレポートを生成できます8。つまり、テストが全く無いレガシーコードにも、後から差し込むことができるということです。

テストフレームワーク自体も、Test::Builderを土台に作られていた旧来の仕組みから、Test2::Suiteという後継フレームワークへ移行が進んでいます。「Tools」「Plugins」「Bundles」という3層構造を持ち、レガシーコードにも段階的に導入しやすい設計になっています9。

3. APIレイヤーの切り出し

3つ目は、フロント・決済・物流といった構成要素を、少しずつ本体から切り離していくアプローチです。

先ほど紹介したストラングラーフィグ・パターンは、まさにこの考え方を体系化したものです。Fowlerはこう表現しています。

Like the fig, it begins with small additions, often new features, that are built on top of, yet separate to the legacy code base. （絞め殺しの木のように、それは小さな追加——多くの場合は新機能——から始まる。レガシーコードの上に構築されながらも、それとは切り離された形で）4

Fowlerの記事では、段階的な近代化を進めるための4つの活動が整理されています4。

  1. 達成したい成果を明確にする
  2. システムをどこで小さく分割できるか（＝「継ぎ目」）を見極める
  3. その部分を段階的に提供する
  4. これを継続的に実施できるよう、組織自体を変えていく

新旧のシステムが一時的に共存する期間は、二重管理のコストがかかり無駄に見えるかもしれません。しかし、その一時的なコストは、全面リプレイスにともなうダウンタイムのリスクに比べれば、はるかに小さいというのがFowlerの主張です4。まずどこを切り出せそうか、EC事業者であればフロントエンド・決済・物流の3領域から検討してみることをお勧めします。

自社実績——10年物Perl/MojoliciousレガシーECを、止めずに近代化した知見

ここまで理屈を述べてきましたが、これは机上の理論ではありません。Meetsourceでは、2014年から2024年にかけて、10年稼働してきたPerl/Mojolicious基盤の美容ECシステムを近代化するプロジェクトに携わってきました。

このプロジェクトで行ったのは、まさに上記3つの対策です。段階的なリファクタリングとDocker化、CI/CD自動化を実施し、リリースを一度も止めることなく技術的負債を解消しました。その結果、開発速度は2倍になり、運用コストの膨張に歯止めがかかったことで、事業者は浮いたリソースを新規機能の投資に回せる体制を築けました。

「止めずに近代化する」というアプローチは、絵に描いた餅ではなく、実際にやり切れるものです。

いつ全面リプレイスに移るべきか

ここまで紹介した3つの対策は、決してリプレイスを永遠に避けるためのものではありません。目的は、「本当に全面リプレイスが必要かどうか」を落ち着いて判断できる状態を作ることです。

3つの対策をやり切ってもなお、「新規事業のスピードに追いつけない」と感じるようになったら、それが全面リプレイスを検討すべきタイミングです。判断基準をより詳しく知りたい方は、リプレイスの判断基準そのものを扱った別記事「ECサイトのリプレイス、いつやるべき？判断基準と失敗しないための3つのフェーズ」もあわせてご覧ください。

大切なのは、不安に急かされて決めるのではなく、材料が揃った状態で自分たちのタイミングで決めることです。

Perlレガシーでお困りの場合、まずは現状のシステムを一緒に診断しませんか？ 無料の30分課題整理を受け付けています。コンタクトフォームからお気軽にご連絡ください。

Footnotes

  1. CPAN Report 2026 (neilb.org) ↩ ↩2

  2. Perl’s TIOBE Comeback: #27 to #9 Isn’t What It Seems ↩ ↩2

  3. itjobswatch.co.uk Perl求人トレンド ↩

  4. Martin Fowler “StranglerFigApplication” ↩ ↩2 ↩3 ↩4

  5. Mojolicious::Guides::Cookbook（Containers節） ↩ ↩2

  6. Docker Hub 公式 perl イメージ ↩

  7. Mojolicious wiki: Bundling application into Docker image ↩

  8. Devel::Cover（metacpan） ↩ ↩2

  9. Test2::Suite（metacpan） ↩