KentWebのCGIフォームが突然止まった。技術ではなく、判断の話をしよう。

はじめに

最近、KentWeb製のCGIフォームが「suEXEC policy violation」で突然動かなくなるという、不可解な事象に遭遇しました。

技術的な調査内容や再現条件などはすでに Qiita や Zenn にまとめています。

この記事では少し視点を変えて、
「なぜ修復せず、あえて置き換えたのか」という判断の背景や、
誰がどうやって対応したのかに焦点を当てて記録しておきます。

フォームが突然、何の前触れもなく壊れた

これは、とある移管案件で発生した話です。
レンタルサーバー（さくらインターネット）上に設置された、KentWebの postmail.cgi を用いたお問い合わせフォーム。

移管後、約3か月は何事もなく動作していました。
ですがある日突然、フォームを送信すると「err:」という表示だけが返り、裏側では suEXEC policy violation のエラーがログに記録されていました。

サーバー設定やパーミッション、改行コード、Perlパスなど、
KentWebのCGIでよくある原因はすべてクリアしていました。
それでも「動かない」。しかも 原因が見つからない。

修復という選択肢はあった。でも、選ばなかった

原因の特定が困難な中、私は「KentWebを直す」道を選びませんでした。
代わりに、WordPress + Contact Form 7 でフォームを再構築することにしました。

技術的に見れば、KentWebを再アップロードしたり、エラーログを掘ったりして復旧に挑むこともできました。
でも、今回のプロジェクトには以下の背景があったんです：

• フロント・バック・インフラすべてを 1人で見る体制
• 移管後の運用保守は 社内にも詳しい担当がいない
• KentWebは アップデートが止まっている
• 再発のリスクが 読みきれない

つまり、「元に戻して終わり」ではなく、“誰でも保守できる状態に変える”方が長い目で見て安全だと判断しました。

1人のエンジニアができる最適解を選んだ

私はいわゆる“フルスタック”な役割を担当しています。
インフラからバックエンド、フロント、フォーム処理、時にはサーバー設定まで、全部ひとりで見ています。
（しかも、時給1000円で。）

それでも、技術的なこだわりよりも「現場の安全性」を選びました。
これは、自分が“全体を見ている立場”だからこそできた判断だったと思っています。

今回の決断から得たこと

• レガシーを無理に引き延ばすより、置き換えの方が優しい時もある
• 「動いているものを壊さないこと」と、「壊れた時に素早く切り替えられること」は両立できる
• スキルよりも、判断の方がチームの未来を左右する

おわりに

KentWebのような古い技術資産は、今でも多くの中小規模の現場で使われています。
でもそれを維持するには、知識だけでなく判断軸が必要です。

この記事は、1人で全部を見ている薄給エンジニアが、
「動かないフォーム」をどう判断し、どこに落とし所を作ったかの記録です。

Wantedlyには、「どんな技術を使ったか」ではなく、「なぜそうしたのか」を残したい。
そう思って書きました。

🔗 関連記事

• 古の技術、KentWebのpostmail.cgiが suEXEC ポリシー違反で弾かれた話（Qiita）
• KentWebのフォームが suEXEC で突然止まった話（Zenn）