- このトピックには0件の返信、1人の参加者があり、最後に
により1日、 11時間前に更新されました。
-
投稿
-
使える場面、状況の想定
WordPressで自作のオリジナルテーマを開発しているときや、外注したホームページ制作会社からの納品物を検収する際に、その品質を正しく評価するのは容易ではありません。
目に見えるデザインが綺麗で、動作が整っていても、内部のプログラム構造がWordPressの標準仕様に準拠しているかどうかは、高度な専門知識がなければ判断がつかないためです。これらの内部構造は、将来的なセキュリティリスクや、修正のしやすさ、保守・管理・運用にかかるメンテナンスコストにも大きく影響します。
オリジナルテーマの品質は、いわば自社のWebマーケティング戦略を支える、資産価値そのものです。ここでは、専門知識がなくても、自社サイトが今後も安全に成長させられる「資産」になっているのか、それとも見えない技術的な「負債」を抱えた欠陥品であるのかを、AIを使って客観的にチェックする方法をご紹介します。
プログラムコードの問題点の洗い出し・非推奨な実装やリスクの確認・WordPress公式基準との乖離を可視化したい場面で、ご活用ください。
解決プロンプト（相談）
あなたは、WordPress公式の仕様を完璧に熟知した、利害関係のない中立なシニアWebエンジニア（技術監査人）です。
受託開発によって制作されるWordPressの「オリジナルテーマ」が、WordPress本来の管理機能や拡張性、保守性を標準的な状態で満たしているかを判断するための、一般的な「公式基準」を整理してください。※注意：公式ディレクトリへの「一般公開・配布（Theme Review）」のための審査要件ではなく、あくまで「納品されたサイトを自社で安全に運用・管理・更新できるか」という品質・監査の視点で回答してください。
以下の条件を必ず満たしてください：
・WordPress公式の仕様（Theme Handbook等）をベースとしつつ、受託開発で発生しやすい「手抜き・仕様不備（関数の欠落やハードコーディング）」の監査に特化すること
・各項目に「発注者にとってのリスク優先度を付与し、更新不可・動作不良など、想定される状態を記載すること
・専門知識がない発注者でも「何が問題なのか」が直感的に理解できる平易な言葉で説明すること
・実際にファイル（functions.phpやheader.phpなど）を開いてチェックできるように、具体的な「着眼点」を含めること出力構成：
1. 概要（受託開発のオリジナルテーマにおいて、WordPress公式基準を満たすことの重要性）
2. 管理画面の標準機能に関する公式基準（メニューやパーツなどを管理画面から変更できるようにするための共通仕様）
3. テンプレート階層とファイル構成に関する公式基準（WordPressが推奨する標準的なファイル設計ルール）
4. プラグイン互換性と干渉に関する公式基準（必須フックの配置など、外部プラグインを安全に動かすための共通仕様）
5. 発注者向け：公式基準に基づいた「一般的なチェックリスト」まとめAIの回答例
1. 概要
なぜ「WordPress公式基準」を満たす必要があるのか
受託開発の「オリジナルテーマ」は、見た目が完成していても、
内部構造がWordPress標準仕様に沿っていない場合があります。その場合、発注者側では次のような問題が起こります。
- 管理画面から編集できない
- 更新するとレイアウトが壊れる
- プラグインが正常に動かない
- 他社が引き継げない
- 制作会社しか修正できない
- WordPress本体アップデートに追従できない
つまり、「見た目が動く」ことと、
「WordPressとして正しく作られている」ことは別問題です。WordPress公式は、テーマ開発者向けに以下のような標準仕様を定義しています。
- テンプレート階層（Template Hierarchy）
- Theme Functions
- Theme Support
- Hook（wp_head / wp_footer など）
- Customizer
- Navigation Menu API
- Widget API
- enqueue（CSS/JS読み込み方式）
これらは単なる推奨ではなく、
「WordPressの管理機能・拡張性・保守性を正常に保つための共通ルール」です。受託開発では、この標準仕様を無視して「固定HTML化」されているケースが非常に多く、
特に以下が典型的な問題です。- 管理画面から変更できない
- 画像や文言がPHPに直書き
- メニューが固定
- titleタグ固定
- プラグインが効かない
- 独自実装でWordPress機能を殺している
そのため、納品物は「デザイン」ではなく、
「WordPressとして正しく実装されているか」を監査する必要があります。
2. 管理画面の標準機能に関する公式基準
2-1. メニュー管理（Navigation Menus）
公式仕様
WordPressでは、メニューは管理画面「外観 → メニュー」から
変更可能であることが標準です。テーマ側では通常、functions.php に以下を定義します。
register_nav_menus()チェック箇所
functions.php
register_nav_menus( array( 'global' => 'グローバルメニュー' ) );header.php
wp_nav_menu()が使われているか。
問題例（危険）
<ul> <li><a href="/about">会社概要</a></li> </ul>のようにHTML直書き。
発注者リスク
優先度：★★★★★（極めて高い）
- メニュー変更のたびに制作会社依存
- 管理画面から更新不可
- ページ追加時にリンク漏れ
- 多言語化困難
2-2. タイトルタグ管理（titleタグ）
公式仕様
add_theme_support('title-tag');チェック箇所
functions.php
add_theme_support('title-tag');があるか。
問題例
header.php に：
<title>会社名</title>固定記述。
発注者リスク
優先度：★★★★★
- SEOプラグインが効かない
- ページごとのタイトル変更不可
- SNS共有時に誤表示
2-3. アイキャッチ画像（Featured Image）
公式仕様
add_theme_support('post-thumbnails');チェック箇所
functions.php に存在するか。
問題例
画像URLをPHPやHTMLへ直接記述。
発注者リスク
優先度：★★★★☆
- ブログ更新時に画像管理困難
- OGP画像連携不可
- 記事一覧が崩れる
2-4. ウィジェット対応
公式仕様
register_sidebar()チェック箇所
functions.php
register_sidebar(があるか。
問題例
サイドバー内容が固定HTML。
発注者リスク
優先度：★★★☆☆
- バナー変更不可
- 広告差し替え不可
- ノーコード運用不能
2-5. カスタムロゴ対応
公式仕様
add_theme_support('custom-logo');チェック箇所
functions.php
問題例
<img src="/logo.png">固定。
発注者リスク
優先度：★★★☆☆
- ロゴ変更のたびに改修費
- 管理画面運用不能
2-6. CSS/JSの読み込み方法
公式仕様
wp_enqueue_style() wp_enqueue_script()チェック箇所
functions.php 内。
問題例
header.php に：
<link rel="stylesheet" href="style.css">直書き。
発注者リスク
優先度：★★★★★
- キャッシュ不整合
- プラグインJS競合
- jQuery重複読込
- 表示崩れ
3. テンプレート階層とファイル構成に関する公式基準
3-1. Template Hierarchy（テンプレート階層）
公式仕様
WordPressには以下の役割分担があります。
- front-page.php
- home.php
- single.php
- page.php
- archive.php
- category.php
チェック箇所
テーマ内に適切なテンプレート分離があるか。
問題例
全部 index.php に書かれている。
発注者リスク
優先度：★★★★☆
- 改修時に全体崩壊
- 引継ぎ困難
- 修正費高騰
3-2. header.php / footer.php の共通化
公式仕様
get_header(); get_footer();チェック箇所
各テンプレートに：
get_header();があるか。
問題例
各ページにヘッダーをコピペ。
発注者リスク
優先度：★★★★☆
- 修正漏れ
- ページごとに表示差異
- 更新コスト増大
3-3. get_template_part() による部品化
公式仕様
get_template_part()チェック箇所
一覧カード等が部品化されているか。
問題例
同じHTMLが複数ファイルに重複。
発注者リスク
優先度：★★★☆☆
- 修正漏れ
- 保守困難
3-4. ハードコーディング禁止
公式仕様
URL・画像・サイト名等は関数利用。
home_url() get_template_directory_uri() bloginfo()問題例
https://example.com/contact固定。
発注者リスク
優先度：★★★★★
- ドメイン変更時に全滅
- ステージング環境破損
- SSL移行失敗
4. プラグイン互換性と干渉に関する公式基準
4-1. wp_head() の設置
公式仕様
header.php の </head> 直前：
<?php wp_head(); ?>必須。
チェック箇所
header.php
問題例
wp_head() が無い。
発注者リスク
優先度：★★★★★（最重要）
- SEOプラグイン無効
- GAタグ動かない
- CSS/JS読込失敗
- reCAPTCHA無効
4-2. wp_footer() の設置
公式仕様
footer.php の </body> 直前。
<?php wp_footer(); ?>発注者リスク
優先度：★★★★★
- JavaScript系プラグイン故障
- 計測タグ停止
- 管理バー不具合
4-3. body_class()
公式仕様
<body <?php body_class(); ?>>問題例
<body>固定。
発注者リスク
優先度：★★★☆☆
- プラグインCSS不整合
- ページ判定不能
4-4. wp_body_open()
公式仕様
<?php wp_body_open(); ?>body開始直後。
発注者リスク
優先度：★★★★☆
- GTM導入不能
- アクセス解析制限
4-5. The Loop を正しく使っているか
公式仕様
while ( have_posts() ) : the_post();問題例
投稿内容を直接SQLや固定HTMLで出力。
発注者リスク
優先度：★★★★☆
- プラグイン非対応
- ページネーション破損
- SEO不整合
5. 発注者向け：公式基準に基づいた「一般的なチェックリスト」
最重要（必須）
項目 確認ファイル 問題がある状態 wp_head() header.php SEO・計測系が壊れる wp_footer() footer.php JS系が動かない enqueue方式 functions.php CSS/JS競合 title-tag functions.php SEO変更不可 ナビメニュー functions.php / header.php メニュー更新不可 ハードコーディング 全体 URL変更で破綻 管理画面運用
項目 確認ポイント アイキャッチ post-thumbnails ロゴ変更 custom-logo ウィジェット register_sidebar メニュー変更 wp_nav_menu 保守性
項目 危険状態 テンプレート分離 index.phpだけ 部品化 コピペ大量 共通化 header重複 固定URL 直書き
実務上の重要ポイント
「WordPressで作られている」≠「WordPress準拠」
非常に多いのが：
- WordPressをCMSとしてだけ利用
- 中身は固定HTML
- 管理画面と連動していない
というケースです。
これは実質的には
「静的HTMLサイトをWordPressに載せただけ」
であり、WordPress本来の保守性・拡張性を失っています。
最後に：監査時の判断基準
発注者視点では、次の問いが極めて重要です。
「制作会社がいなくなっても、自社で安全に運用できるか？」
WordPress公式仕様に沿っているテーマは：
- 他社引継ぎ可能
- プラグイン拡張可能
- 管理画面運用可能
- 将来改修可能
という「資産」になります。
逆に、公式仕様を無視したテーマは：
- 制作会社依存
- 更新不能
- ブラックボックス化
- 将来全面リニューアル
につながりやすく、長期的な運用コストが非常に高くなります。
ポイント解説
デザインや挙動に問題がなくても、プログラムがWordPressの標準仕様に沿っていなければ、将来的なアップデートや他社への引き継ぎの際に必ず不具合が噴出します。
メニューの変更やウィジェット機能による要素の追加、画像の差し替えなどが、管理画面からノーコードで簡単に編集できる状態になっているかどうかが、その後の運用コストの明暗を分けると言っても過言ではありません。
特定のプラグインが機能しない、SEO設定やアクセス解析タグが反映されない、ドメイン変更時にサイト全体が動かなくなる、といった致命的な事態も想定されます。AIのアドバイスで、実際に問題がありそうなファイルが特定出来たら、対象のPHPファイルをGeminiやChatGPTのチャット画面に直接アップロードして、続きのプロンプトで以下を入力してみてください。
「同じ視点で確認して、このファイルのプログラム的な問題点を指摘してください。」
更に詳細な問題点の指摘と、具体的な改善策をAIに提示させることができます。注意事項
AIは非常に厳格で高精度な監査を行ってくれますが、提示された修正コードを専門知識がない方が、自分で直接本番環境のテンプレートファイルに上書きすることは、絶対に避けてください。開発元の制作会社に相談をして、どこまで修正対応が可能か、それが「瑕疵や不具合」にあたるのか、あるいは「合意済みの仕様」なのかについて、十分な話し合いを行うことが先決です。
WordPressのオリジナルテーマの品質において、発注者が納得できるラインに達していれば、必ずしも全ての公式基準を完璧に満たしている必要はありません。
契約や費用、納期なども考慮した上で、ビジネス面での現実的な調整を行うための判断材料の一つとして、このチェック方法をご活用ください。
- このトピックに返信するにはログインが必要です。