TECN / APICE　WordPress管理画面・業務スニペットパフォーマンス設計TIPS

2026年8月7日2026年8月8日

1．目的

TECN / APICEでは、WordPress管理画面上に多数の業務スニペット、管理MENU、CSV処理、DB処理、Creators API処理などを実装しています。

機能追加を繰り返すと、個々の処理は正常でも、WordPress管理画面を開くだけで不要な初期処理が大量に実行され、画面遷移が極端に遅くなることがあります。

本資料は、WordPress管理画面全体のレスポンスを維持するために、MENU・初期処理・DB準備・診断処理等をどのように実装するかを定める開発TIPSです。

2．今回確認された実際の性能問題

2026年8月7日時点で、WordPress管理画面の「TECN記事作成」をクリックした際、画面遷移に6～10秒程度かかる状態が発生しました。

専用診断を実施した結果、次の値が確認されました。

HTTPリクエスト開始 → 診断スニペット開始：約0.021秒
admin_init 全体：約9.283秒
admin_menu 全体：約0.003秒
request開始 → admin_footer：約9.398秒

この結果から、遅延のほぼ全てが admin_init 内で発生していることが判明しました。

MENU描画処理そのものや admin_menu は原因ではありませんでした。

3．根本原因

「TECN 工程3 ブランド別商品候補取得 V1.2.2」において、

admin_init

から毎回、

setup()

を呼び出す構造になっていました。

しかし実際には、

専用管理画面を開いた時
CSVを出力する時
CSVを取り込む時
完了画面を表示する時

にも、それぞれ必要なタイミングで setup() が呼び出されていました。

したがって、WordPress管理画面を開くたびに admin_init から実行される setup() は不要な重複処理でした。

V1.2.3で admin_init → setup() を削除し、

必要な処理を実行する時だけ setup() を呼ぶ方式

へ変更したところ、「TECN記事作成」だけでなくWordPress管理画面全体のレスポンスが大幅に改善しました。

4．最重要原則

「常時初期化」ではなく「必要時起動」

TECN / APICEの管理スニペットでは、原則として、

WordPress管理画面を開いただけでは重い処理を実行しない

ことを基本とします。

重い処理は、

その機能を実際に使用した時だけ実行する

構造にします。

5．admin_initで原則実行しない処理

以下の処理を admin_init へ安易に登録しないこと。

DBスキーマ準備

dbDelta()
CREATE TABLE
ALTER TABLE
DBバージョン更新
インデックス作成

DB構造確認

SHOW TABLES
SHOW COLUMNS
DESCRIBE
information_schema検索

大量データ診断

全件COUNT
GROUP BY
大量JOIN
重複診断
商品キャッシュ全件走査
ブランド全件走査
カテゴリ全件走査

外部通信

Creators API
Amazon API
HTTP通信
wp_remote_get()
wp_remote_post()
cURL

業務処理

CSV生成
CSV解析
AI材料生成
商品候補生成
代表商品選定
大規模再判定
集計結果更新

これらを admin_init に置くと、対象機能を使用していなくてもWordPress管理画面を開くたびに実行されます。

6．正しいsetup()の呼び方

悪い例：

add_action('admin_init', array(__CLASS__, 'setup'));

この場合、投稿一覧、ダッシュボード、企業マスター、記事作成など、WordPress管理画面のほぼ全リクエストで setup() が動きます。

推奨例：

public static function render_page() {
    self::setup();
    // 専用画面処理
}

または、

public static function import_csv() {
    self::check_permission();
    self::setup();
    // CSV取込処理
}

つまり、

専用画面を実際に開いた時

または、

保存・CSV・API・反映等の実操作を実行した時

だけ setup() を呼びます。

7．管理MENUの作り方

admin_menu は基本的に、

add_menu_page()
add_submenu_page()
PAGE_SLUG登録
callback登録

だけにします。

MENU登録処理の中で、

DB検索
件数集計
状態確認
外部通信
テーブル作成
大量データ取得

を行わないこと。

今回の実測でも admin_menu は約0.003秒であり、正しく作ればMENU登録自体は非常に軽量です。

8．統合MENU・カード画面の考え方

TECN / APICEの統合MENUでは、カード表示画面自体は軽量に保ちます。

カード表示時に必要なのは原則、

タイトル
説明
PAGE_SLUG
status
callback
アイコン
バージョン表示

程度です。

カードを表示するだけで、

「商品数」
「ブランド数」
「要確認件数」
「API取得件数」

などを毎回DB集計しないこと。

必要な件数は、専用処理画面を開いた後に取得します。

9．DB初期化・スキーマ変更の基本ルール

DB初期化が必要なスニペットでも、毎回確認しないこと。

推奨方式：

DB_VERSIONをoption等で保持
専用画面または実処理時にDB_VERSION確認
未適用時だけDB構造確認
必要な場合だけdbDelta / ALTER
適用後はDB_VERSIONを保存
通常アクセスではoption確認程度で終了

ただし、可能であればスキーマ変更そのものを専用移行処理として分離する方が望ましい。

10．診断処理の基本ルール

診断は非常に重くなりやすいため、

画面を開いただけでは診断しない

こと。

推奨構造：

「最新診断を実行」ボタン
↓
手動実行
↓
診断SQL実行
↓
結果をoption / transient等へ保存
↓
通常画面では直近結果だけ表示

TECN 商品ブランドマスター V1.7.0で採用した「手動診断方式」を基本とします。

11．大量集計結果の扱い

企業数、ブランド数、商品数、要確認件数など、大量データを毎回リアルタイム集計する必要がない場合は、

手動更新
保存時更新
バッチ更新
transient
option
専用集計テーブル

等を利用します。

単なる管理画面表示のために毎回大量集計を行わないこと。

12．外部APIの基本ルール

Creators API等の外部通信は、

必ず明示的な業務操作を起点にする

こと。

例：

「Amazon商品取得」
ボタン
↓
Creators API通信

という構造にします。

管理画面を開いた、MENUを表示した、ページを移動しただけでは外部APIを実行しません。

13．新規スニペット作成時の性能チェック

新しい管理スニペットを作成するときは、実装前またはレビュー時に次を確認します。

フック

admin_initに重い処理がないか
plugins_loadedに重い処理がないか
initに管理専用の重い処理がないか
admin_menuがMENU登録だけになっているか

DB

dbDeltaを毎回呼んでいないか
SHOW TABLES / SHOW COLUMNSを毎回実行していないか
全件COUNTやGROUP BYを通常画面で実行していないか

外部処理

API通信を画面アクセス時に行っていないか
CSV生成を通常画面で行っていないか

UI

カード一覧表示のためだけに大量DB検索していないか
状態表示のために全件診断していないか

14．遅くなった場合の診断手順

WordPress管理画面全体が遅くなった場合、個別スニペットを推測で修正しない。

まず時間を区間別に測定します。

最低限確認するもの：

REQUEST開始 → スニペット実行開始
admin_init
admin_menu
current_screen
admin_enqueue_scripts
admin_head
admin_footer

今回のように、

admin_init：約9秒
admin_menu：約0.003秒

であれば、MENUを修正しても意味がありません。

実測値から遅いフックを特定して、そのフックに登録されている処理を追う

ことを基本とします。

15．TECN / APICE 今後の開発原則

今後作成する、

随時記事作成
指示書A
指示書B
Creators API補強
商品候補
商品キャッシュ
代表選定
記事登録
診断ツール

についても同じ原則を適用します。

基本形

通常アクセス
→ 何もしない

専用画面アクセス
→ 必要なデータだけ読む

ボタン実行
→ 必要な処理だけ実行

完了
→ 結果だけ保存

この方式を 「必要時起動」 と呼び、TECN / APICE管理スニペットの標準実装方針とします。

16．今回の教訓

WordPress管理画面の性能は、コード量やスニペット数だけでは決まりません。

50～60本のスニペットが存在していても、それぞれが必要時起動であれば十分高速に動作します。

一方、1本のスニペットでも admin_init で重い処理を毎回実行すると、WordPress管理画面全体を数秒～10秒以上遅くすることがあります。

したがって、

「何本あるか」より「いつ動くか」

を重視して設計します。

TECN標準ルール

WordPress管理画面では、使っていない機能の処理を走らせない。
MENUはMENU登録だけ。
DB準備・診断・CSV・API・集計は、その機能を実際に使用した時だけ実行する。
重い処理はadmin_initへ置かず、「必要時起動」を基本とする。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

WORK-admin

TECN / APICE　WordPress管理画面・業務スニペットパフォーマンス設計TIPS

1．目的

2．今回確認された実際の性能問題

3．根本原因

4．最重要原則

「常時初期化」ではなく「必要時起動」

5．admin_initで原則実行しない処理

DBスキーマ準備

DB構造確認

大量データ診断

外部通信

業務処理

6．正しいsetup()の呼び方

7．管理MENUの作り方

8．統合MENU・カード画面の考え方

9．DB初期化・スキーマ変更の基本ルール

10．診断処理の基本ルール

11．大量集計結果の扱い

12．外部APIの基本ルール

13．新規スニペット作成時の性能チェック

フック

DB

外部処理

UI

14．遅くなった場合の診断手順

15．TECN / APICE 今後の開発原則

基本形

16．今回の教訓

TECN標準ルール

この記事を書いた人

コメント

コメントするコメントをキャンセル

TECN / APICE WordPress管理画面・業務スニペット パフォーマンス設計TIPS

1．目的

2．今回確認された実際の性能問題

3．根本原因

4．最重要原則

「常時初期化」ではなく「必要時起動」

5．admin_initで原則実行しない処理

DBスキーマ準備

DB構造確認

大量データ診断

外部通信

業務処理

6．正しいsetup()の呼び方

7．管理MENUの作り方

8．統合MENU・カード画面の考え方

9．DB初期化・スキーマ変更の基本ルール

10．診断処理の基本ルール

11．大量集計結果の扱い

12．外部APIの基本ルール

13．新規スニペット作成時の性能チェック

フック

DB

外部処理

UI

14．遅くなった場合の診断手順

15．TECN / APICE 今後の開発原則

基本形

16．今回の教訓

TECN標準ルール

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

TECN / APICE　WordPress管理画面・業務スニペットパフォーマンス設計TIPS

コメントするコメントをキャンセル