Cursorで古いプラグインを安全に書き換える｜脆弱性対応をAIで突破

自社サイトのWordPress管理画面を開くたびに、「このプラグイン、もう何年も更新されていないけど大丈夫かな」と不安になっていませんか。開発が止まった古いプラグインは、脆弱性が見つかっても誰も直してくれません。とはいえ、エンジニアに頼む予算もなく、結局そのまま放置するしかない。そんな板挟みのWeb担当者は本当に多いです。

この記事では、AIコードエディタ「Cursor（カーソル）」を使って、古くて危ないプラグインの機能を自社用の安全な形に書き換える、現実的な進め方を解説します。コードが読めなくても大丈夫です。判断の順番、具体的な手順、そしてやりがちな失敗まで、非エンジニアの方にも分かるよう現場目線でお伝えします。

まず決めるのは「直す」より「どう手放すか」の順番

古いプラグインへの対応は、いきなり「書き換えよう」と動くのが正解ではありません。最初にやるべきは、そのプラグインを「放置・更新・乗り換え・自作化」のどれにするかを切り分けることです。全部をCursorで作り替える必要はありません。むしろ、作り替えるべきものはごく一部です。

ここで言う「自作化」とは、開発が止まって更新が来ないプラグインの機能のうち、自社に本当に必要な部分だけを、Cursorに手伝ってもらって自分のサイト専用の軽いコードとして作り直すことです。つまり、他人が作った重くて古い仕組みに頼るのをやめて、必要な機能だけを安全な形で持ち直すイメージです。

判断の全体像を一覧にしました。自社のプラグインがどれに当てはまるか、まずここで仕分けてみてください。

状況	取るべき対応	Cursorの出番
公式で更新が続いている	素直に更新する	不要
開発停止だが代替プラグインがある	評判の良い後継に乗り換え	移行の確認に補助的に使う
開発停止で、使うのは1〜2機能だけ	その機能だけ自作化する	主役。ここで活躍する
そもそも今は使っていない	停止して削除する	不要

ポイント。脆弱性対応の第一歩は「減らす」ことです。使っていないプラグインを消すだけで、攻撃される入口（専門的にはアタックサーフェスと言います。かんたんに言うと、狙われる窓口の数です）が減ります。Cursorで書き換えるのは、削除も乗り換えもできない「どうしても必要な機能」だけに絞りましょう。

なぜ「自作化」が選択肢になるのか。開発が止まったプラグインは、便利機能が山ほど詰まっている一方で、実際に使っているのはそのうちの一部だったりします。たとえば「お問い合わせフォーム」のプラグインなら、使っているのは送信機能だけなのに、使わない決済連携やアンケート機能まで丸ごと抱えている。その使っていない部分にこそ、古い脆弱性が眠っていることが多いのです。だったら、必要な機能だけを自分のサイト用に作り直したほうが、軽くて安全になります。

Cursorで古い機能を安全に作り替える5ステップ

ここからは実際の進め方です。Cursorは、文章で指示するだけでコードを読んだり書いたりしてくれるAI搭載のエディタで、プロジェクト全体を理解した上で修正してくれる精度の高さが評価されています（2026年6月13日時点）。 コードが書けなくても、日本語で会話しながら進められます。具体的な操作ボタンは公式ヘルプに譲り、ここでは「何をどの順番でやるか」の流れをお伝えします。

ステップ1。今あるプラグインの棚卸しをする

まず、管理画面のプラグイン一覧を見て、それぞれの「最終更新日」「使っているかどうか」を書き出します。最終更新が2年以上前のものは要注意です。この時点ではまだCursorは使いません。紙やスプレッドシートで十分です。

ステップ2。Cursorに古いコードを読ませて「何をしているか」を翻訳させる

作り替えたいプラグインのフォルダをCursorで開き、「このプラグインが実際に何をしているコードか、専門知識がない人にも分かるように日本語で説明して」とお願いします。AIはコードを読んで、機能の中身を文章にしてくれます。これが、設計書のない古い仕組みを理解する一番の近道です。レガシーなシステムをAIに読ませて設計情報を再構築する手法は、すでに大手のシステム開発でも使われています。

ステップ3。必要な機能だけを「仕様書」としてまとめる

ステップ2の説明を見ながら、「自社が本当に使っている機能はこれとこれ」と絞り込みます。そして、その機能の仕様をCursorに箇条書きでまとめてもらいます。ここで使わない機能をバッサリ落とすのが、安全化の肝です。

ステップ4。セキュリティ要件を添えて作り替えを指示する

ここが最重要です。AIは「動くコード」は得意ですが、「安全なコード」は指示しないと出してくれません。漠然と「作り替えて」ではなく、守ってほしいルールを具体的に添えます。WordPressなら、次のような指示を一緒に渡すと精度が上がります。

• 入力のチェック：フォームから来た値は必ずsanitize_text_field()などで無害化してから使う
• データベース操作：SQLは直書きせず$wpdb->prepare()を使う（不正な命令の混入を防ぐため）
• 権限の確認：その操作をしてよい人かcurrent_user_can()でチェックする
• なりすまし防止：フォーム送信にはnonce（ワンタイムの合言葉）を入れる
• 動作を変えない：今の見た目と使い勝手は維持し、新機能は足さない

専門用語が並びましたが、意味を全部覚える必要はありません。大事なのは、この一覧をそのままCursorに貼り付けて「このルールを守って書いて」と伝えることです。安全なコードのお手本をAIに渡すと、安全なコードが返ってきやすくなります。Cursorの基本的な使い方はCursorを「最強のWeb更新アシスタント」にする記事でも詳しく解説しています。

ステップ5。本番に入れる前に必ずテスト環境で確かめる

できあがったコードは、いきなり本番サイトに入れてはいけません。テスト用の環境（本番のコピー）で動かし、フォーム送信やログインなど、実際の操作を一通り試します。問題がなければ、まず本番のバックアップを取ってから入れ替えます。この順番を飛ばすと、表示崩れやデータ消失につながります。

AIが生成したコードは、2025年の調査で約45%がセキュリティテストに通らなかったとも報告されています。 「AIが書いたから安全」という思い込みは禁物です。最後は必ず人の目とテストで確認しましょう。

取り組むと何が変わるか。コストと安心の両面で効く

古いプラグインを自作化すると、サイトはどう変わるのでしょうか。一番大きいのは、「誰かの更新を待つ受け身の状態」から「自分でコントロールできる状態」になることです。開発が止まったプラグインは、脆弱性が見つかっても永遠に直りません。自社のコードにしておけば、いざというときCursorで自分が直せます。

コスト面でも効きます。これまで「外注に作り替えを頼むと数十万円かかるから放置」だった作業が、Cursorを使えば担当者の数時間〜数日の作業で形になるケースが出てきます。実際、設計書のない古いシステムをAIで解析して作り直し、工期短縮とコスト削減を実現したという企業事例も報告されています。大手システム会社でも、生成AIでレガシーシステムの設計書を復元し、開発の生産性を高める取り組みが進んでいます。

市場全体で見ても、古い仕組みを新しくする「モダナイゼーション」の需要は伸びています。関連市場は2025年の約249.8億ドルから2030年には約568.7億ドルへ拡大すると予測されており、AIを使った刷新が当たり前になりつつあります。中小企業にとっても、これは「専門の開発会社でなくても、現場の担当者が少しずつ手を打てる時代になった」という追い風です。

成功している会社に共通するのは、一気に全部やろうとしないことです。まず一番危なそうなプラグイン1つを自作化し、うまくいったら次へ、と小さく回しています。最初の1つで「自分たちでもできた」という手応えをつかむのが、続けるコツです。

現場でよくある失敗と、その防ぎ方

ここからは、実際にやってみた人がつまずきがちなポイントを正直にお伝えします。先に知っておけば、ほとんどは避けられます。

失敗1。「AIが書いたから大丈夫」と信じて本番に入れてしまう

一番多いのがこれです。Cursorはもっともらしいコードを返してきますが、入力値のチェックが甘かったり、ログインは確認しても「その人がその操作をしてよいか」の確認（認可）が抜けていたりします。AIが書いたコードは脆弱性を含みやすいという調査結果もあります。 防ぎ方は、ステップ4のセキュリティ要件を必ず添えること、そしてステップ5のテストを省略しないことです。この2つだけで、危険度は大きく下がります。

失敗2。AIが「古いやり方」を提案してくる

AIは過去のコードを大量に学んでいるため、すでに非推奨になった古い書き方や、セキュリティ修正前の古いバージョンのライブラリを提案してくることがあります。これに気づかず採用すると、せっかく作り替えたのに別の穴を開けてしまいます。防ぎ方は、「2026年時点で推奨される最新の安全な方法で書いて」と一言添えることです。さらに、生成されたコードを保存した瞬間に問題を見つけてくれるチェックツール（PHPStanなど）をローカルに入れておくと、機械的に弾けます。

失敗3。1つのファイルに全部詰め込んで「秘伝のタレ」化する

AIに「あれも追加」「これも修正」と継ぎ足していくと、1つのファイルがどんどん長くなり、誰も中身を把握できない状態になります。これは現場で「秘伝のタレ」と呼ばれる、保守できないコードの典型です。しかもAIには一度に読める量の限界（トークン制限）があり、コードが長すぎると最初の指示を忘れてバグを出します。防ぎ方は、機能ごとにファイルを分け、1回の指示は小さく区切ることです。「この関数は20行以内で」「動作は変えずに」と制約を具体的に伝えると、AIの精度が上がります。

失敗4。バックアップを取らずに入れ替える

意外と多いのがこれです。作り替えに集中するあまり、元の状態のバックアップを取らずに本番を上書きしてしまう。これで戻せなくなると、復旧に何倍もの時間がかかります。防ぎ方はシンプルで、入れ替え前に必ずサイト全体とデータベースのバックアップを取ること。これを作業手順書の冒頭に固定で書いておきましょう。セキュリティの基本的な考え方は「AIセキュリティ」超入門の記事もあわせて読むと整理しやすいです。

正直に言うと、ここは外注を頼ったほうが早い

ここまで「自分でできる」とお伝えしてきましたが、現場を見てきた立場から、率直に妥協点もお伝えします。Cursorでの自作化は万能ではありません。向いている作業と、プロに任せたほうが安い作業がはっきり分かれます。

向いているのは、フォーム送信、簡単な一覧表示、表示の出し分けといった「動きが単純で、影響範囲が読める」機能です。逆に、会員情報や決済、個人情報を大量に扱う機能は、自作化はおすすめしません。ここでミスをすると、情報漏えいという取り返しのつかない事故に直結するからです。攻撃側もAIを使って脆弱性を大量に見つけ、突いてくる時代です。重要なデータを扱う部分は、専門家のレビューを通したほうが結果的に安く済みます。

もう一つの見落としが「保守責任の移動」です。プラグインを自作化した瞬間から、その面倒を見るのは自社になります。WordPress本体がバージョンアップして動かなくなったとき、直すのは自分たちです。これは自由と引き換えの責任です。だからこそ、自作化するのは「使うのは1〜2機能だけ」のシンプルなものに絞るべきなのです。

内製と外注の切り分けは、こう考えると分かりやすいです。「壊れても自分で2時間以内に戻せる範囲」は内製、「壊れたら事業が止まる範囲」は外注。この線引きをチームで決めておくだけで、無理な自作化による事故をぐっと減らせます。教科書には「AIで全部できる」と書いてありますが、現場の本音は「できることと、やってはいけないことを見極めるのが一番大事」です。

よくある質問

まとめ。小さく1つから、でも大事な所は無理しない

古いプラグインの脆弱性対応は、「全部直す」のではなく「減らして、必要な分だけ安全に持ち直す」のが現実的な道筋です。Cursorを使えば、コードが読めなくても、その第一歩を自分たちで踏み出せます。まずは一番危なそうなプラグイン1つの棚卸しから始めてみてください。

とはいえ、「うちのサイトはどこまで自作化していいのか分からない」「重要な機能だから判断に自信がない」という方も多いはずです。ここまで読んで、自社だけでやり切るのは少し不安だと感じた方は、Cursorでお問い合わせフォームを自作する記事もヒントになります。コレットラボのAI業務システム化支援では、内製と外注の線引きから一緒に整理し、Cursorでの作り替えを伴走しています。現状の棚卸しだけでも大歓迎です。気になった方は、AI業務システム化の詳細はこちらからお気軽にご相談ください。