他社制作WordPressの保守引き継ぎ：受ける前に見る10項目

他社が作った WordPress サイトの保守を頼まれたとき、引き受ける前に何を調べ、どこで「受ける」「条件付きで受ける」「断る」を分ければよいか。この記事はその問いに、フリーランスや小さな制作会社の目線で答えます。結論は、調査を保守とは別の有料の仕事として見積もり、10項目を確かめて判定表で決めることです。記事の中の確認表は、そのまま調査報告の目次として使えます。

他社制作の保守は「調査」を別の仕事として見積もる

他社が作ったサイトは、引き受ける前に中身を調べる時間が必ず要ります。その時間は保守の月額に混ぜず、調査として別に見積もり、別に発注してもらうのが基本です。

他社制作のサイトの保守は受けない、と公開している制作会社もあります。理由として挙げているのは、同じ WordPress でも制作会社ごとに内部の作りが大きく違うこと、そのため予期しないトラブルの責任の範囲があいまいになることです。受ける側が怖いのもまさにこの2点なので、この記事の10項目は「作りを知る」と「責任の線を引く」ためのものにしています。

調査を有料の商品として公開している例もあります。WordPress の引き継ぎを専門にする WPドック は、制作会社・フリーランス向けに「現状調査・工数見積もり」を 9,800円（税込。作業を依頼すると全額値引き）、「引き継ぎ・復旧」を10万〜30万円（調査後に個別見積もり）と公開しています。これは1社の公開価格で、市場の相場を調べた数字ではありません。それでも「調査はタダではない」と依頼主に説明するときの手がかりにはなります。

調査の進め方は4段階

段階	必要な権限	やること
① 一次調査	依頼主が自分の管理者アカウントで操作（こちらはログインしない）	依頼主が取ったサイトヘルスの情報のコピーを受け取り、版・プラグイン・警告を見る
② 二次調査	サーバー（SSH・FTP）、ドメイン・DNS の管理画面	ファイルの照合、アカウントの棚卸し、バックアップの確認
③ 報告と判定	なし	判定表で「受ける／条件付き／断る」を決め、報告書を渡す
④ 保守契約	名義を整えたあとの正式な権限	範囲と「受けた時点の状態」を書いて契約する

WordPress の管理者アカウントが前の制作会社の担当者のものしかない場合もあるので、①でも、こちらが誰かのアカウントを借りて入ることはしません。依頼主が自分のアカウントを持っていなければ、そのこと自体を項目8の棚卸しの結果として記録します。①の段階で断る理由が見つかれば、サーバーの権限をもらう前に話を止められます。権限を受け取るほど、手を引くときに返す・消す手間も増えるので、順番を守る意味があります。

調査費の見積りの例

調査の時間は、サイトの規模とプラグインの数でかなり変わります。次は計算の例で、時間と単価は仮に置いた数字です。

作業	時間（例）
一次調査（サイトヘルスの読み取り、プラグインの確認）	2時間
二次調査（ファイルの照合、アカウント、バックアップ、独自コードの拾い出し）	4時間
報告書の作成と説明	2時間
合計	8時間

例: 時間単価を5,000円と置くと、8時間 × 5,000円 = 40,000円（税別）です。自分の時間単価に置き換えて計算してください。

発注は調査と保守を分けてもらう

依頼主には、調査の発注と保守の発注を分けてもらいます。調査の結果「受けない」と決めても、調査の報酬は受け取れる形にしておくためです。

従業員を使わない個人として受けるなら、発注する側にはフリーランス・事業者間取引適正化等法（フリーランス新法、2024年11月1日施行）の3条で、業務の内容・報酬の額・支払期日などを書面かメールなどで明示する義務があります。発注する側が従業員を使う事業者なら、支払期日は給付を受け取った日（保守のような役務なら提供を受けた日）から60日以内に決める必要があります（4条）。制作会社から外注として受ける場合は、資本金や従業員数によって、2026年1月1日に施行された中小受託取引適正化法（取適法、旧下請法）の対象になることもあります。対象かどうかは公正取引委員会のページの簡易診断ツールで確かめられます。条件の明示の書き方は「フリーランス新法とWeb制作の外注：条件の明示・60日払い・発注文例」にまとめています。

項目1〜3：ドメイン・サーバー・DNS とメールの名義と権限

最初に見るのは技術ではなく名義です。ドメインとサーバーの契約者が前の制作会社のままで、承諾も名義変更も得られないなら、その時点では受けないのが安全です。

項目1 ドメインの登録者は誰か

.jp で終わるドメインなら、JPRS WHOIS（https://whois.jprs.jp/ ）で登録者名を確かめられます。.com などは登録者の情報が伏せられていることが多いので、依頼主にドメインの管理画面の契約者情報を見せてもらいます。登録者が前の制作会社なら、移管や名義変更には前の制作会社の手続きが要ります。

WHOIS ではネームサーバーも見えます。これで DNS がどこで管理されているか（レンタルサーバーか、ドメインの管理会社か、別の DNS サービスか）の当たりが付きます。

項目2 サーバーの契約者は誰か

サーバーの契約者が前の制作会社のとき、依頼主から聞いた ID とパスワードでそのまま入ってよいかは慎重に考えます。不正アクセス禁止法は、他人の ID とパスワードを入力して利用できる状態にする行為を不正アクセスとしつつ、アクセス管理者や、その ID の利用権者の承諾を得てする場合を除いています（2条4項1号）。依頼主がサーバーの契約者でない場合、依頼主の承諾だけで足りるのかは状況によって変わります。

実務としては、サーバー・ドメインの契約者が誰かを確かめ、契約者本人から書面かメールで「調査のために入ってよい」という承諾をもらってから入ります。前の制作会社と連絡がつかない、承諾が取れない場合は、名義の整理を先に依頼主に進めてもらいます。個別の事情で判断に迷うときは弁護士に相談してください。

項目3 DNS とメールはどこにあるか

DNS の管理画面に誰が入れるかと、メールがどのサーバーで動いているかを確かめます。メールがサイトと同じレンタルサーバーで動いている場合、サーバーを移すと、DNS の切り替えと同時にメールの受け取り先も変わります。DNS のレコード（MX・SPF など）は、DNS の管理画面で依頼主に一覧を見せてもらうのが確実です。

ここを調べないまま「サーバーを移したらメールが届かなくなった」となると、原因が前任者の設定でも受けた側の責任に見えます。移す予定がなくても、調査報告には「メールはどこで動いているか」を一行書いておきます。

項目4：権利（著作権と有料テーマ・プラグインのライセンス）

改修を伴う保守を受けるなら、依頼主と前の制作会社の契約書を見せてもらいます。「著作権を譲渡する」とだけ書かれていても、改変の権利まで依頼主に移っているとは限りません。

著作権法61条2項は、著作権を譲渡する契約で27条（翻案権など）と28条（二次的著作物の利用の権利）が譲渡の目的として「特掲」されていないとき、これらの権利は譲渡した側に残ると推定する、と定めています。つまり契約書に「27条及び28条の権利を含む」といった書き方がなければ、テーマやデザインを改変する権利が前の制作会社に残っていると推定されることがあります。依頼主と前の制作会社の契約の解釈は当事者の問題なので、気になる書き方なら依頼主から弁護士に確かめてもらいます。

人格権の例外と翻案権は別の問題

改変には、財産権の翻案権（27条）と、著作者人格権の同一性保持権（20条）の2つが関わります。著作者人格権は譲渡できない（59条）ので、契約書では譲渡の条項と並べて「著作者人格権を行使しない」という特約があるかを探します。

契約書で探す文言	無いときに残りうる問題
「著作権（著作権法27条及び28条の権利を含む）を譲渡する」	翻案権が前の制作会社に残ると推定される（61条2項）
「著作者人格権を行使しない」	改変に対して同一性保持権を主張される余地がある

同一性保持権には、プログラムを特定のコンピューターで動くようにするため、またはより効果的に動くようにするために必要な改変を例外とする定めがあります（20条2項3号）。ただしこれは人格権の例外で、翻案権が前の制作会社に残っているかどうかは別の問題として残ります。翻案権の側では、プログラムの複製物の所有者が自ら実行するために必要な限度で複製・翻案できる定め（47条の3第1項と47条の6第1項6号）がありますが、保守を受けた制作者の作業にどこまで当てはまるかは個別の判断です。PHP の版上げに伴う修正でも「権利上問題ない」と決めつけず、デザインの変更を含む改修なら、上の2つの文言が契約書にあるかを確かめてから受けます。

有料テーマ・有料プラグインの名義

有料のテーマやプラグインは、ライセンスの名義とキーの持ち主を確かめます。前の制作会社のアカウントで買われていると、ライセンスが切れたときに更新できず、セキュリティ修正が受け取れなくなります。Patchstack の調査（後述）では、有料の部品は、実際に悪用が確認された脆弱性が無料の部品の3倍ありました。

写真やイラストの素材も同じです。ストック素材のサイトのアカウントが前の制作会社の名義なら、使用許諾の範囲を依頼主が説明できるかを聞いておきます。

項目5〜6：WordPress と PHP の版

版は、管理画面の「ツール」→「サイトヘルス」→「情報」タブで分かります。この画面には、内容をすべてクリップボードにコピーするボタンがあるので、サーバーの権限をもらう前でも、依頼主が自分の管理者アカウントで取ったコピーを送ってもらえば一次調査ができます。

項目5 WordPress の版

WordPress.org は、公式にサポートしているのは最新版だけだとしています。2026年10月6日に出た 7.1.3（セキュリティ修正7件・不具合修正4件）のお知らせでは、古い版へのセキュリティ修正の移植は 4.7 系までとされています。2026年10月16日時点の最新は 7.1.3 です。

最新から大きく離れた版で止まっているサイトは、本体の更新だけでなく、テーマやプラグインがそれに付いてこられるかの確認が要ります。更新を保守の月額に含めず、版上げとして別に見積もる理由になります。

項目6 PHP の版

php.net の表では、PHP の各版はおおむね2年間の通常のサポートと2年間のセキュリティ修正のみの期間があります。2026年10月16日時点のセキュリティ修正の期限は次のとおりです。

PHP の版	セキュリティ修正の期限
8.1 以前	終了
8.2	2026年12月31日
8.3	2027年12月31日
8.4	2028年12月31日
8.5	2029年12月31日

WordPress.org の推奨は PHP 8.3 以上です。PHP 7.4 以上でも動くものの、サポートが終わった版はサイトを脆弱性にさらしうる、と書かれています。8.2 で動いているサイトは、2026年12月31日に期限が来るので、引き受けた直後に版上げの作業が発生する前提で見積もります。

項目7：プラグイン（閉鎖・放置・WordPress.org にないもの）

本体の版よりも重く見るべきなのは、どのプラグインが入っていて、更新が続いているかです。脆弱性の大半はプラグインから見つかっているからです。

WordPress のセキュリティ企業 Patchstack が2026年2月25日に公開した「State of WordPress Security in 2026」によると、2025年に公開された WordPress 周辺の新しい脆弱性は11,334件で、前年より42%増えました。そのうち91%がプラグイン、9%がテーマで、本体は6件（いずれも優先度の低いもの）でした。公開の時点で修正版が出ていなかったものが46%あり、よく狙われた脆弱性は、公開から最初の大量の悪用までの時間（加重中央値）が5時間でした。

閉鎖されたプラグインは更新が来ない

WordPress.org のプラグインが閉鎖されると、配布の zip が作られなくなり、管理画面からも新しく入れられなくなります。開発者向けの FAQ は、新しい持ち主がいないプラグインは利用者が更新を受け取れなくなり、セキュリティ上の影響が大きいと書いています。すでに入っているサイトの画面に、閉鎖が目立つ形で出るとは限らないので、こちらから確かめに行きます。

WP-CLI で一覧を取る

サーバーで WP-CLI が使えるなら、次のコマンドでプラグインの一覧と WordPress.org での状態をまとめて取れます（列の名前は WP-CLI の公式の文書で確かめたものです）。

wp plugin list --fields=name,status,version,update_version,wporg_status,wporg_last_updated --format=csv > plugins.csv
wp plugin list --status=must-use
wp plugin list --status=dropin

wporg_status は、WordPress.org に載っていれば active、閉鎖されていれば closed、WordPress.org に無いもの（有料・自作など）や取得できなかったものは空になります。wporg_last_updated は WordPress.org での最終更新日です。must-use と dropin は管理画面のプラグイン一覧で見落としやすいので、別に出しておきます。

CSV に印を付けるスクリプト

取った CSV に、確かめるべきプラグインの印を付ける Python のスクリプトです。標準ライブラリだけで動きます。

#!/usr/bin/env python3
"""wp plugin list の CSV を読み、引き継ぎの前に確かめるプラグインに印を付ける。

使い方:
  wp plugin list --fields=name,status,version,update_version,wporg_status,wporg_last_updated --format=csv > plugins.csv
  python3 plugin_triage.py plugins.csv 2026-10-16 730
  （引数: CSV のファイル、基準日、何日更新が無ければ印を付けるか）
"""
import csv
import sys
from datetime import date


def triage(row, today, stale_days):
    notes = []
    if row["wporg_status"] == "closed":
        notes.append("閉鎖: 更新が来ない。置き換えを見積もる")
    elif row["wporg_status"] == "":
        notes.append("WordPress.org に無い: 有料か自作。更新の手段と名義を確かめる")
    if row["wporg_last_updated"]:
        try:
            days = (today - date.fromisoformat(row["wporg_last_updated"])).days
        except ValueError:
            notes.append(f"日付が読めない（{row['wporg_last_updated']}）: 目で確かめる")
        else:
            if days >= stale_days:
                notes.append(f"最終更新から{days}日")
    if row["update_version"]:
        notes.append(f"更新待ち {row['version']} → {row['update_version']}")
    if row["status"] == "inactive":
        notes.append("無効: 使わないなら削除を提案")
    return notes


def main():
    path, today, stale_days = sys.argv[1], date.fromisoformat(sys.argv[2]), int(sys.argv[3])
    with open(path, newline="", encoding="utf-8") as f:
        rows = list(csv.DictReader(f))
    flagged = 0
    for row in rows:
        notes = triage(row, today, stale_days)
        if notes:
            flagged += 1
            print(f"{row['name']} ({row['status']}): " + " / ".join(notes))
    print(f"--- {len(rows)}件中 {flagged}件に印")


if __name__ == "__main__":
    main()

動作を確かめるため、架空のプラグイン6件の CSV を手で作り、Python 3.14 で実行しました（2026年10月16日）。入力と出力は次のとおりです。プラグインの名前と値は説明用に作ったもので、実在のプラグインの状態ではありません。最後の行は、日付の形が違う行で止まらずに印が付くかを見るため、わざと「/」区切りにしています。

name,status,version,update_version,wporg_status,wporg_last_updated
sample-form,active,5.2.1,5.3.0,active,2026-09-30
sample-seo,active,3.0.4,,active,2026-10-01
sample-slider,active,1.8.0,,closed,
sample-gallery,inactive,2.1.0,,active,2022-11-05
theme-addon-pro,active,4.0.2,,,
sample-legacy,active,0.9.2,,active,2024/03/01

$ python3 plugin_triage.py sample-plugins.csv 2026-10-16 730
sample-form (active): 更新待ち 5.2.1 → 5.3.0
sample-slider (active): 閉鎖: 更新が来ない。置き換えを見積もる
sample-gallery (inactive): 最終更新から1441日 / 無効: 使わないなら削除を提案
theme-addon-pro (active): WordPress.org に無い: 有料か自作。更新の手段と名義を確かめる
sample-legacy (active): 日付が読めない（2024/03/01）: 目で確かめる
--- 6件中 5件に印

実際の WP-CLI の出力の形は、実機では試していません。WP-CLI のソース（wp-cli/extension-command の Plugin_Command.php、2026年10月16日時点）では、wporg_last_updated は Y-m-d（例: 2026-09-30）の形で、サイトのタイムゾーンで書き出されます。閉鎖されたプラグインは、WordPress.org の配布の記録から日付が取れれば入り、取れなければ空になるので、閉鎖の行でも日付が入っていることがあります。形が違う行があってもスクリプトは止まらず、「日付が読めない」の印を付けます。

「730日」は、2年更新がなければ放置を疑う、という編集部の目安です。サイトの性格に合わせて変えてください。WP-CLI が使えないサーバーなら、サイトヘルスの「情報」タブの有効・無効のプラグインの一覧と、各プラグインの WordPress.org のページを目で見比べます。

項目8：改ざん・公開されたファイル・管理者アカウント

受ける前に、すでに改ざんされていないか、見えてはいけないファイルが公開されていないか、誰が管理者なのかを確かめます。ここで問題が見つかったら、それは保守ではなく復旧という別の仕事です。

ファイルを照合する

wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

wp core verify-checksums は、本体のファイルを WordPress.org のチェックサムと照合します。安全のため WordPress を読み込まずに動き、--include-root を付けると、ルートのフォルダーに WordPress 以外のファイルがあるときに知らせます。wp plugin verify-checksums は WordPress.org のチェックサムとの照合なので、WordPress.org で配っていない有料・自作のプラグインは照合できません。そこは中身を目で見るしかなく、その時間を調査費に入れます。

本体のファイルが一致しない、ルートに見覚えのない PHP ファイルがある、という結果なら、保守の契約の前に「調査と復旧」を別に見積もります。改ざんされたまま引き受けると、以後の被害が受けた側の作業のせいに見えるからです。

サイトヘルスの警告と公開されたファイル

サイトヘルスの「状態」タブは、重大な問題として、訪問者にエラーを表示する設定（WP_DEBUG_DISPLAY）や、誰でも見られるかもしれないファイルにエラーを書き出す設定（WP_DEBUG_LOG）を知らせます。エラーには公開すべきでない情報が含まれうるからです。あわせて、公開フォルダーに残ったバックアップのファイルやデータベースの書き出しがないかも見ます。IPA の「安全なウェブサイトの運用管理に向けての20ヶ条」も、公開すべきでないファイルを公開していないか、不要になったページを放置していないかを確認項目に挙げています。

管理者アカウントの棚卸し

管理者の一覧に、前の制作会社の担当者や、依頼主の退職者のアカウントが残っていることがあります。引き受けるときは、誰のアカウントを残し、誰のものを消すか（またはパスワードを変えるか）を依頼主に決めてもらい、その記録を残します。前の制作会社のアカウントを消すと、相手が作業できなくなるので、消す日を前の制作会社にも伝えるのが筋です。

項目9〜10：作りの癖とバックアップ

最後に、どこまで自分の手に負えるかと、壊したときに戻せるかを確かめます。資料は無いのが普通、という前提で調べる時間を見積もります。

項目9 独自コードと作りの癖

見る所	確かめること
テーマ	子テーマを使っているか。親テーマを直接編集していると、親テーマの更新で消える
functions.php	量と中身。フォームの送信、外部サービスとの連携、ショートコードが書かれていないか
外部サービスの鍵	API のキー、地図・予約・決済などの連携。キーの持ち主の名義
定期実行	WP-Cron やサーバーの cron で動いている処理
資料	構成の説明、更新の手順、過去の不具合の記録があるか

サイトヘルスの「情報」タブの「有効なテーマ」には、親テーマがあるかどうかが出ます。「なし」で、しかもテーマが配布物ではなく前の制作会社の自作なら、更新の手段が無い代わりに、更新で消える心配もありません。逆に配布されているテーマを直接編集していたら、更新の前に差分を取り出して子テーマに移す作業が要ります。

項目10 バックアップと戻し方

いまバックアップを誰が、何で、どこに取っているかを聞きます。「取っているはず」ではなく、戻したことがあるかまで聞きます。保守の契約が切れた前の制作会社のバックアップは、引き継ぎの日から止まることがあるからです。

引き受ける前に自分でも1つ取っておきます。

wp db export before-handover.sql

これに wp-content フォルダーの複製を合わせて、「受けた時点の状態」の証拠にもします。テスト環境（ステージング）を作れるサーバーかどうかも見ておき、作れないなら更新のたびに本番で試すことになる分、作業の時間を多めに見積もります。

判定表と調査報告・保守契約に書くこと

10項目の結果は、次の表で判定します。断るか受けるかの二択にせず、多くの場合は「条件を付けて受ける」になり、その条件は調査報告書と保守契約に書いて残します。

見つかったこと	判定の例	依頼主への伝え方
ドメイン・サーバーの名義が前の制作会社で、承諾も名義変更も取れない	受けない（名義を整えてから）	契約者の名義の整理を先にお願いする
本体のファイルの不一致、見覚えのないファイル	保守の前に復旧を別に見積もる	調査と復旧の見積りを出す
PHP 8.2 以前、WordPress が古い版	条件付き（版上げを別に見積もる）	期限の日付を示して版上げを提案する
閉鎖・放置のプラグイン	条件付き（置き換えを見積りに入れる）	代わりのプラグインと作業の時間を示す
有料の部品のライセンスが前の制作会社の名義	条件付き（依頼主の名義で買い直す）	費用は依頼主の負担と伝える
契約書に改変の権利の定めが無い	条件付き（権利の確認を依頼主に頼む）	確認がとれるまで改修は受けない
親テーマの直接編集、資料の無い独自コード	条件付き（改修は時間単価で）	月額は更新と監視まで、と範囲を区切る
上のどれにも当たらない	通常の月額で受ける	受けた時点の状態を報告書で残す

依頼主が版上げや名義の整理に応じないときは、無理に受けないことも選択肢です。その場合も、調査報告書は依頼主に渡します。次の制作者が同じ調査をやり直さずに済み、依頼主にとっても調査費を払った意味が残ります。

調査報告書の目次（コピーして使える確認表）

調査の成果物は報告書です。報告書に書いた「受けた時点の状態」が、その後の不具合の責任を切り分ける根拠になります。

#	項目	書くこと
1	ドメイン	登録者、管理会社、有効期限、ネームサーバー
2	サーバー	契約者、会社とプラン、ログインできる人、承諾をもらった日
3	DNS とメール	DNS の置き場所、メールが動いているサーバー
4	権利	前の制作会社との契約書の有無と著作権の条項、有料の部品のライセンスの名義
5	WordPress の版	調査日の版と最新版
6	PHP の版	調査日の版とセキュリティ修正の期限
7	プラグイン	一覧（閉鎖・WordPress.org 外・長く更新の無いもの・無効のものに印）
8	改ざんとアカウント	ファイルの照合の結果、公開されたファイル、管理者の一覧
9	作りの癖	子テーマの有無、独自コードのある場所、外部サービスの鍵
10	バックアップ	誰が何で取っているか、戻したことがあるか、自分で取った日
―	判定と見積り	すぐ直すもの・あとで直すもの・保守の月額

付録として、サイトヘルスの「情報」のコピーと、WP-CLI の出力を付けます。報告書はパスワードやキーそのものを書かず、「誰が持っているか」だけを書きます。

保守契約に書くこと

保守契約には、調査報告書を引用して次のことを書きます。

• 範囲: 更新、バックアップ、監視、確認の頻度
• 範囲外: 改修、版上げ、復旧（時間単価で別に見積もる）
• 受けた時点の状態: 調査報告書の日付と版。それ以前からある原因の不具合は範囲外で、有償で対応する
• 名義と権限の一覧: ドメイン・サーバー・有料の部品・外部サービス
• 解約のときに返すもの: 権限の返却、作成した資料、バックアップの扱い

契約書の条文の書き方は「ホームページの保守契約書の書き方：範囲・対応時間・解約と引き継ぎ」に、ひな形は Handoff の保守契約書のひな形にあります。手放す側が何を渡すべきかは「保守をやめたい制作者の引き継ぎ手順：伝え方・名義・後任探し」に書いているので、前の制作会社に資料を頼むときの参考になります。

引き継ぎの話は、最初の打ち合わせで項目1〜2を聞く

引き継ぎの相談は、最初の打ち合わせで項目1〜2（ドメインとサーバーの名義）を聞くだけで、受けられるかどうかの見当がかなり付きます。Handoff では、保守を手放したい制作者が、お客の名前やサイトの URL を伏せたまま「引き継いでほしい」を出せます。出す側が、名義・版・プラグインの数を掲載の時点で書いておくと、受ける側が調査の見積りを早く出せます。相手が決まって連絡先が見えたら、最初に項目1〜2を聞きます。

契約や取引の条件でもめたときは、厚生労働省の委託で第二東京弁護士会が運営する「フリーランス・トラブル110番」（https://freelance110.mhlw.go.jp/ ）に無料で相談できます。

明日からやること

• この記事の「調査報告書の目次」を自分の書式に写し、空欄のまま1枚作っておく
• 自分の時間単価で調査費の見積りを1つ作り、保守の見積りと別の行にする
• 他社制作のサイトの相談が来たら、最初にドメインとサーバーの契約者の名前を聞く
• WP-CLI が使えるサーバーで、手元のサイトに wp plugin list の列を足して一度実行し、wporg_status の出方を見ておく