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初期化が必要なスニペットでも、毎回確認しないこと。

推奨方式：

1. DB_VERSIONをoption等で保持
2. 専用画面または実処理時にDB_VERSION確認
3. 未適用時だけDB構造確認
4. 必要な場合だけdbDelta / ALTER
5. 適用後はDB_VERSIONを保存
6. 通常アクセスでは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管理画面全体が遅くなった場合、個別スニペットを推測で修正しない。

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

最低限確認するもの：

1. REQUEST開始 → スニペット実行開始
2. admin_init
3. admin_menu
4. current_screen
5. admin_enqueue_scripts
6. admin_head
7. 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へ置かず、「必要時起動」を基本とする。