副業の相談で「十年以上前に作ったCGIがまだ動いていて、作った人はもういません。ずっと見てもらえませんか」と頼まれました。Perlの業務委託を引き受けたら抜けられなくなるのではないかと身構えたところで、相手は「まず、直すか、やめるかを決めたいんです」と付け加えました。仕様書の無い古いコードの面倒を、終わりなく見続けることになるのではないか。その不安は、引き受け方を変えると小さくできます。Perlの副業は、面倒を見る約束ではなく、決めるための材料を渡す約束にします。

1. Perlの保守が副業で重く見える理由

呼び出される側に回る保守

「見てもらえませんか」と頼まれると、まず浮かぶのは障害の連絡です。動いて当たり前のスクリプトは、止まった日にだけ名前を呼ばれます。夜でも休日でも連絡が来る形では、本業と並べることができません。保守という言葉には、こうした待機まで含まれているように聞こえます。これが重く見える1つ目の理由です。

2つ目は、範囲が決まらないことです。仕様書が無いコードでは、どこまでが依頼の対象なのか、頼む側も引き受ける側も言い切れません。ある日は文字化けの相談、翌週は別のスクリプトの調整、と依頼が広がっていっても、最初に範囲を書いていなければ断る根拠がありません。

3つ目は、期限が無いことです。「ずっと」と言われた仕事には終わりの日がなく、副業の時間を毎月どれだけ空ければよいのかも読めません。ただし、この3つはPerlという言語の性質ではなく、保守を引き受ける形の問題です。ここから先は、書き手の見立てとして読んでください。

約束の形を変えると別の仕事になる

同じコードでも、引き受ける単位を変えると仕事の姿が変わります。たとえば「動作を調べて報告書にする」「直す・消す・載せ替えるの比較を渡す」という単位なら、期限と成果物を先に決められます。障害のたびに呼ばれる形とは、約束の中身がまるで違います。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

冒頭の依頼でも、相手が望んでいたのは直すかやめるかの決定でした。決めたい人に要るのは、面倒を見続ける人ではなく、決められるだけの材料です。では、その材料はなぜ要るのでしょうか。まず、サポートの終わった環境で動き続けるものに何が起きるかを確かめます。

2. サポートの終わった環境で動き続けるコード

IPAが注意喚起した対象はWindows 10

最初に断っておくと、ここで引くIPAの注意喚起はWindows 10についてのものです。Perlも、CGIも、Webサーバーも取り上げていません。Perlの話に使えるのは、サポートが終わった環境で何が起きるかという仕組みの部分だけです。

IPAの注意喚起によると、Windows 10のサポートは2025年10月14日（米国時間）に終了し、以後はセキュリティ更新プログラムの提供がなくなります¹。サポート終了の一例ですが、更新が止まった日を境に、見つかった弱点が塞がれなくなる構図がよく分かります。

注意喚起は、OSだけでなく、そのOS上で稼働するアプリケーションもサポートが順次終了していくため、あわせて対策が必要だと利用者に呼びかけています¹。OSの更新が止まると、その上で動くものにも影響が広がるという見方です。

さらにIPAは、サポート終了後に発見された脆弱性は修正が行われない可能性が高く、意図せずセキュリティ上のリスクを抱えることになると説明しています¹。これはOS上で動くサードパーティ製ソフトウェアについての説明です。

注意喚起の内容を項目別に並べる

IPAの注意喚起の内容は、サポートの終了日、終了後に起きること、その上で動くアプリケーション、終了後に見つかった脆弱性の4項目に分けて読めます。下の表は、それぞれ注意喚起に書かれている内容だけを並べたものです。Perlやサーバーの話は1行も含まれていません。主語はいずれもWindows 10とその上で動くソフトウェアです。

項目	IPAの注意喚起の内容
サポート終了日	2025年10月14日（米国時間）1
終了後	セキュリティ更新プログラムの提供がなくなる1
上で動くアプリケーション	サポートが順次終了1
終了後に見つかった脆弱性	修正が行われない可能性が高い1

古いサーバーで動くCGIへの当てはめ

ここからは書き手の見立てです。十年以上前に作られたCGIが、保守の止まった古いサーバーの上で動き続けているなら、Windows 10と同じ構図が当てはまる場合があります。更新が止まった環境の上で動くものは、新しい弱点が見つかっても塞がれにくくなるからです。

ただし、これは個々のサーバーを調べて初めて分かることです。Perlで書かれているから危ない、という話ではありません。Perl本体の状況はIPAの注意喚起に書かれていませんし、この記事でも判断しません。分かれ目になるのは、CGIが動いている環境の側のサポートの状態です。

副業で依頼を受ける側から見ると、ここが調査の入口になります。動いている環境と、そこで使われているものの一覧が、直すか消すかを決める最初の材料になるからです。

3. ウェブサイトの脆弱性は「直す」か「消す」か

修正を完了した26件の内訳

IPAの報告では、2025年第4四半期（10月〜12月）に修正を完了したウェブサイトの脆弱性26件のうち、ウェブアプリケーションを修正したものが23件（88%）、当該ページを削除したものが3件（12%）でした²。割合の母数は、この26件です。

ただし、この26件はIPAに届け出られた脆弱性のうち、その四半期に修正を完了したウェブサイトの分です。CGIやPerlに限った数ではなく、年間の数や全ウェブサイトの割合でもありません。ページを消す選択が一般的かどうかは、ここからは言えません。

出典：IPA『ソフトウェア等の脆弱性関連情報に関する届出状況[2025年第4四半期（10月～12月）]』をもとに作成。割合は26件が母数です

とはいえ、数は少なくても、ページごと消すという対処が実際に選ばれた事実は残ります。修正だけが答えではないとき、その判断はだれが、何を材料に下すのでしょうか。

通知から3ヶ月という目安

同じ報告の脚注は、ウェブサイトの脆弱性の対処の目安を、運営者が通知を受けてから3ヶ月以内としています²。制度上の目安であり、法律上の期限ではありません。副業の納期をこの3ヶ月で決める根拠にもなりません。

書き手の見立てでは、この目安が示すのは、運営者が限られた期間のうちに「直す」か「消す」かを決める場面に置かれうる、ということです。材料が無いまま日数だけが進む状況を避けるには、コードが何をしていて、直す場合に何に触れるのかを、先に書き出しておく必要があります。

材料とは、動作の説明、入力と出力の一覧、動いている環境の記録です。これを渡す仕事なら、依頼の終わりを「材料を渡した日」と決められます。終わりのない保守と区切った仕事を分けるのは、この一点です。

4. 作った人に連絡が取れないソフトウェア

連絡不能開発者の公表

IPAの同じ報告には、調整機関から連絡が取れないソフトウェア製品の開発者を、連絡不能開発者として名前を公表した件数があります。2025年第4四半期末時点の累計は251件でした²。

数え方には注意が要ります。対象はソフトウェア製品の開発者で、ウェブサイト運営者の数でも、Perlのコードの数でもありません。累計の値なので、その四半期に増えた数とは別です。冒頭の依頼のCGIが同じ状況にあるかどうかも、この数からは分かりません。

この数から借りるのは、作った人に連絡が取れなくなる事態が、IPAの報告で公表の対象になっている、という点だけです。作った人がいなくても、コードは動き続けます。困るのは、動いている中身を説明できる人がいなくなったときです。

立場ごとに困ることと渡せるもの

作った人がいないコードを前に、困り方は立場によって違います。運営する側は中身を説明できず、直す側は影響の範囲が読めず、決める側は続けるか替えるかを決められません。下の表は、立場ごとの困りごとと、副業で渡せるものを書き手の見立てで並べたものです。渡せるものはどれも、コードを読んで書き出す作業から生まれます。

立場	困ること	副業で渡せるもの
運営する側	誰も中身を説明できない	コードを読んで書き出した動きの記録
直す側	影響範囲が分からない	呼び出し関係と入力・出力の一覧
決める側	続けるか替えるかを決められない	判断材料の報告

3つの立場に共通して欠けているのは、中身の説明です。副業の依頼がこの形で来たとき、断る理由にも引き受ける理由にもなるのは、作った人がいないことそのものではなく、説明できる材料が無いことです。では、その材料を作る仕事は、具体的に何をするのでしょうか。

5. 仕様書の無いコードを読む仕事の形

調べる作業を4つに分ける

仕様書の無いコードを読む仕事は、書き手の見立てでは4つの作業に分けられます。動作の調査、入出力の洗い出し、依存の確認、判断材料の整理です。どの作業にも、終わったと言える形があります。それが成果物です。

動作の調査では、スクリプトが呼ばれてから結果を返すまでの処理を追い、流れ図に書き出します。コードを書き換える作業ではありません。読んで分かったことを、別の人が読める形に残す作業です。

入出力の洗い出しでは、スクリプトが受け取るもの、読み書きするファイルやテーブル、画面や他のスクリプトへ渡すものを一覧にします。直す側が最初に知りたいのは影響の範囲なので、この一覧は表2の立場でいえば直す側に渡す材料です。

依存の確認では、動いている環境と、コードが呼び出しているモジュールを記録します。第2節の見立てを確かめる作業は、この一覧から始まります。最後の判断材料の整理では、直す・消す・載せ替えるの3案を同じ観点で比べ、決める側に渡します。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

成果物が仕事の終わりを決める

この形の利点は、仕事の終わりを成果物で決められることです。「処理の流れ図と、入出力の一覧を渡したら完了」と最初に書いてあれば、渡した日が終わりの日になります。障害のたびに呼ばれる保守とは、約束の置き場所が違います。

一方で、成果物は読む人が使えなければ意味がありません。流れ図は、コードを読んでいない人が追える粒度で描きます。一覧は、直す側がそのまま影響範囲の確認に使える並びにします。書き手の見立てでは、副業で評価されやすいのは、コードを速く書く力より、読んだ中身を他の人に渡せる形に直す力です。

ここまでの作業は、本番の環境を触らなくても進められる場合があります。コードのコピーと、動いている環境の情報を受け取れれば、手元で読めるからです。本番に触れるかどうかは、受ける前に決める項目の1つになります。

6. 受ける前に決めておくこと

依頼の約束に書く6項目

終わりのある仕事にするには、引き受ける前に約束の中身を書き出します。書き手の見立てでは、調査の範囲、成果物の形、期限、本番環境に触れるかどうか、修正まで含めるかどうか、追加の依頼の扱いの6項目です。下の表は、それぞれの項目で決める内容の例を並べたものです。例に挙げた形は一つの目安で、依頼ごとに中身は変わります。

決めること	例
調査の範囲	どのスクリプトまでを対象にするか
成果物の形	報告書、一覧表
期限	成果物を渡す日
本番環境に触れるかどうか	触れる場合の手順と立ち会い
修正まで含めるかどうか	調査だけか、修正も含めるか
追加の依頼の扱い	別の見積もりとして受ける

6項目のうち、後から効いてくるのは範囲と追加の依頼の扱いです。冒頭の「ずっと見てもらえませんか」は、この2つが空白のまま始まった形です。先に書いておけば、翌週に別のスクリプトの相談が来ても、新しい約束として話し合えます。

範囲の外に出たときの扱い

範囲を決めても、読んでいる途中で想定外のものが見つかることはあります。たとえば、一覧に載っていなかったスクリプトが別の場所から呼ばれていたときです。そのときは、見つけた事実を成果物に書き足し、対象を広げるかどうかは依頼主と決め直します。黙って広げると、範囲を決めた意味が薄れます。

期限も同じ扱いです。成果物を渡す日は、調査の範囲と一緒に決めます。第3節で見たとおり、IPAの3ヶ月は運営者が通知を受けてからの対処の目安で、副業の納期の根拠ではありません。納期は、読む量と本業に割ける時間から、自分で見積もります。

本番環境に触れる場合は、触れる前の状態を記録し、いつ誰が何をするかを先に合意します。ここも約束の一部です。では、この6項目を、本業と並べるときの受け方にどうつなげればよいのでしょうか。

7. 本業と並べるための受け方

資料から借りるものと、見立てで足したもの

この記事で資料に頼った部分は、数えるほどです。Windows 10のサポートが2025年10月14日（米国時間）に終わったこと¹、2025年第4四半期に修正を完了した26件のうち3件がページの削除だったこと²、連絡不能開発者の公表が累計251件に達していること²、対処の目安が通知から3ヶ月以内であること²です。

ただし、どれもPerlのCGIを直接調べた資料ではありません。そこから先、つまり古いCGIにも同じ構図があり得ることと、調査と判断材料の報告に区切って受けると終わりのある仕事になることは、書き手の見立てです。資料の数字は、見立てを支える背景として読んでください。

受け方の順番

本業と並べるうえで大切なのは、順番を入れ替えないことです。範囲を決める前に読み始めると、読む量が際限なく広がります。判断材料を渡す前に修正へ進むと、依頼の中身が途中で変わります。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

4番目の「続きは別の契約で」は、冒頭の「ずっと」を言い換えた部分です。材料を渡したあとに修正や運用を頼まれたら、範囲と期限を決め直した別の契約として話し合います。1つの約束の中に、終わりのない部分を残さないためです。

決めるための材料を渡す約束

古いコードの相談で、相手が欲しがっているのは、面倒を見続ける人とは限りません。冒頭の依頼主は、直すか、やめるかを決めたいと言いました。そこに応える仕事なら、読む力と、読んだ中身を渡せる形に直す力があれば、本業と並べても始められます。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の経験に合う条件を確かめてみてください。範囲と成果物を先に決められる案件かどうかは、話を聞くときに確かめられます。

Perlの副業は、面倒を見る約束ではなく、決めるための材料を渡す約束にします。範囲を決め、読んで書き出し、材料を渡して、続きは別の契約で話す。その順番を守れば、引き受けたあとに抜けられなくなる不安は、最初の約束の段階で小さくできます。

8. よくある質問

Perlの経験が古くても副業で受けられますか

書き手の見立てでは、受けられる場面があります。調査と判断材料の報告が中心の仕事なら、問われるのは新しい書き方より、既存の書き方を読めるかどうかだからです。過去に読み書きしたCGIやバッチの経験は、そのまま読む力として使えます。

調査のあとに修正も頼まれたらどうしますか

その場で引き受けず、別の契約として範囲と期限を決め直します。修正は、本番環境への影響や確認の手間が調査とは違うため、同じ約束の延長にすると終わりが見えなくなります。決め直すときの項目は、表3の6項目と同じです。

本業で使っているコードと似た仕事を受けるときに確かめることは何ですか

書き手の見立てでは、2つあります。1つは、本業の契約書や社内規程で副業がどう扱われているかです。もう1つは、秘密保持の範囲です。本業で触れたコードや情報を、副業の成果物に持ち込まないことを、受ける前に確かめます。判断に迷うときは、本業の側の窓口に尋ねます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 独立行政法人情報処理推進機構「Windows 10 のサポート終了に伴う注意喚起」（2026年6月26日・2026年10月確認）
＊2 独立行政法人情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況[2025年第4四半期（10月～12月）]」（2026年1月22日・2026年10月確認）