SEARCH

知りたいことから探す

キーワードを入力すると、記事タイトルと本文から検索します。

会社を育てる

WordPressのサイトヘルス7項目をAIと確認。直したもの、戻したもの、残したもの

黄色い補修布の帆と、折り畳んだ予備の帆を載せた小さな帆船の模型

WordPressの「サイトヘルス」に残っていた7項目を、Codexと一緒に確認しました。2026年10月17日の作業では4項目が解消し、最後の表示は「致命的な問題0件・推奨改善3件・通過29件」になっています。

ただ、今回書き残しておきたいのは、減らした数よりも一度入れたものを戻したことと、手をつけずに残したものがあることです。AIに保守を頼むなら、そこまで含めて一つの仕事にしたほうがいい。サイトを実際に触ってもらって、そう考えるようになりました。

この記事では、このブログで何を直し、どこで止めたかをまとめます。同じ7項目がほかのサイトにも出る、という手順書ではありません。自分のWordPressで「これは今やっていいのか」と迷ったときの、判断の材料になればと思います。

「解消できるものは対応して」と頼んだ

今回Codexに伝えたのは、こんな依頼です。

サイトヘルスに残っている7項目も確認して、解消できるものは対応してください。

このブログは、記事を書くだけでなく、WordPressのテーマ作りや投稿作業にもAIを使っています。テーマを21回直したときも、実際の記事を表示して、崩れたところを見つけては修正する進め方でした。

保守も調べてもらうことはできます。ただ、文章の言い回しを直すのと、サイトの設定を変えるのとでは、間違えたときに起きることが違う。今回は変更前の状態を残し、一つずつ確認してもらいました。

サイトヘルスは、WordPressの設定や注意が必要な点を確認する画面です。項目は「致命的な問題」「推奨改善」「通過したテスト」に分かれます。詳しい説明はWordPress公式の案内にあります。

7項目を、全部同じ扱いにはしなかった

今回の対応を、公開できる範囲でまとめるとこうなります。WordPress本体のチェックに加えて、使っているプラグインからの案内も含まれています。

確認した項目今回の扱い
停止中のプラグイン使っていないものを、復元できる形で退避
未使用のテーマ使用中のテーマと予備を残して整理
管理者の二要素認証本人が登録し、有効表示を確認。再ログインでの試験は未実施
ページキャッシュ導入し、生成・消去・再生成を確認
永続オブジェクトキャッシュ試したあと、今回の運用には合わず撤回
監視に関する通知記録を確認し、監視と通知を継続
データベースの更新影響範囲が広がるため、今回は保留

使わなくなったプラグインやテーマの整理は進めました。一方で、二要素認証の登録は僕の端末で行う必要がありました。AIが作業を進めても、本人が受け持つ操作は残ります。

この区別は地味ですが、頼む前よりも頼んだあとに大事になりました。「対応済み」と言われたものが、設定を保存した段階なのか、実際に動いた段階なのかで、こちらが確認することも変わるからです。

入れたキャッシュを、その日のうちに戻した

今回、いちばん判断が必要だったのはキャッシュでした。ひとくくりにしがちですが、試したものは二つあります。

一つは、作ったページを再利用するページキャッシュ。もう一つは、WordPressが処理に使うデータを再利用する永続オブジェクトキャッシュです。

後者を試すと、コマンド側で設定を変えたのに、Webの管理画面には古い状態が残る場面がありました。管理画面から保存し直したあとは表示がそろったものの、このブログではAIがコマンド経由でも記事や設定を扱います。その運用で古い値が残る可能性を、そのままにしておくわけにはいきません。

入れたものを、外しました。

試行を撤回し、関連する仕組みが動いていないことまで確認してもらいました。「導入できた」で終えていたら、ここは残っていたはずです。

ページキャッシュのほうは採用しています。公開記事ではキャッシュが作られ、消したあとにまた作られることを確認しました。一方、無料診断や登録完了のページなどは対象から外しています。ページによって扱う内容が違うので、サイト全体へ一律にかける形にはしませんでした。

なお、今回の記録から「何%速くなった」とは言えません。確認したのは、必要な場所で動き、外したい場所では動かないことです。速度の改善量は、別に測る必要があります。

通知が残る理由と、更新を止めた理由

監視の通知も残しました。記録があることと、侵入されたことは同じではありません。反対に、通知を消せば安全になるわけでもない。今回は記録を確認し、監視を続ける扱いにしています。

もう一つ残したのが、データベース更新です。

使っているサーバーの移行手順を確認すると、このブログ一つの中で完結する作業ではなく、同じサーバーのほかのデータベースまで確認する必要がありました。そこで、対象を広げて調べる前に、Codexから確認が入りました。

今回は保留する。

これが僕の返答です。詳しい調査も移行も、そこで止めています。サイトヘルスの項目を一つ減らすために、確認していない範囲までまとめて進めるつもりはありませんでした。

保留は解決ではありません。次に扱うときは、影響するサイト、バックアップ、作業時間、戻し方をそろえて判断する必要があります。今回はその宿題を残した、という状態です。

次に頼むなら「戻す条件」も最初に渡す

今回の進め方を踏まえると、次は次のように頼みます。実際の依頼文をそのまま転載したものではなく、使い回しやすい形に整理した例です。

サイトヘルスの各項目を確認してください。
まず、意味・対象範囲・変更案・変更前の保存方法を整理してください。
設定を変えたら、管理画面と公開ページの両方で確認してください。
問題が出た場合の戻し方と、戻す条件も書いてください。
ほかのサイトに範囲が広がる作業や、削除を伴う作業は、実行前に確認してください。
最後に、直したもの・戻したもの・残したものを報告してください。

AIが作業を進めてくれるぶん、僕は「どこまで任せるか」を決める必要があります。全部を自分で操作しなくても、何が変わったか、何が残ったかは分かる状態にしておきたい。

サイトヘルスの数字だけを見れば、今回は7項目から3項目になりました。その間にあったのは、整理、本人の操作、動作確認、撤回、保留です。

AIに任せる最初の仕事を決める

サイト保守は、AIへ何でも頼めるようになるための最初の題材としては、少し重いかもしれません。まずは普段の仕事を一つ取り出し、渡す材料と、自分で確かめるところを決めるほうが始めやすいはずです。

どの作業から試すか迷っている方に向けて、7問の無料AI仕事診断を用意しています。概要はメール登録なしで確認できます。診断で候補を見て、「これなら一度任せてみよう」と思える仕事を一つ選んでみてください。

今回の保守も、始まりは「残っている7項目を確認して」という一つの依頼でした。進めるものを決め、合わなければ戻し、範囲が広がれば止める。そのやり取りまで含めて、AIと仕事をする形が見えてきました。

Featured

次に読みたい記事