Googleで優先する情報源に追加
WooCommerceの拡張機能をアップデートするため、テストの準備を進めているとします。AIを使ってリリースノートを確認し、テスト計画の下書きも用意ができたところ、同僚から「今回のアップデートは、独自に設定した決済ルールに影響しないか」と確認されます。そうしたルールを設定しているクライアントのストアがいくつかあることは覚えていますが、具体的にどれだったかを思い出せません。
そこでSlackで詳細を把握している開発担当者に確認しますが、昼まで会議中です。返事を待つ間、別の作業に取りかかることにしました。
一方、同じAIツールを使用している別のWeb制作会社では、各ストアの管理メモから決済の例外設定をすぐに確認できます。テスト用の注文と、適用されるはずの割引額も記録されているため、担当者はそのまま検証作業を進められます。
AIによって変更作業の準備にかかる時間が短縮されるほど、こうした日々の情報管理の違いが、チーム全体の作業効率を大きく左右するようになります。
そこで今回は、チーム内に蓄積されたサイトの情報を必要時にすぐ活用できるようにする方法や、AIの提案を開発担当者が適切に評価するために必要な情報の整備について解説します。さらに、こうした改善によって、複数のクライアントサイトの管理にどれだけの時間を節約できているかを測定する方法もご紹介します。
作業が滞る原因はどこにある？
AIを活用して20分でコードの修正を終え、レビューに回したとします。技術責任者は、別のクライアントサイトにも同じカスタマイズが使われていないか確認する必要がありますが、木曜日まで手が空きません。その間も作業を進めていると、最初の修正をレビューしてもらう頃には、さらに4件の修正がレビュー待ちになっています。
各タスクの対応履歴を見れば、問題は明らかです。コードの修正は数分で終わるのに、レビュー待ちには何日もかかっています。AIツールの契約を増やしても、この待ち時間は解消されません。
Atlassianが2025年に実施した開発者体験に関する調査では、開発者の50%が、組織内の非効率な業務などが原因で、コーディング以外の作業に週10時間以上を費やしていると回答しています。この調査は、6ヶ国の開発者と管理職3,500名を対象に実施されたもので、時間を浪費する主な原因の一つに、「必要な情報を探す作業」が挙げられています。実際の作業時間を計測したデータではなく、回答者の自己申告に基づく結果ですが、Web制作会社が業務の非効率を見直すうえで参考になります。
たとえば、チーム内の誰かがレビューのたびにリポジトリのリンクを探したり、どのサイトで同じカスタマイズが使われているかをほかのメンバーに説明したりしているかもしれません。すぐにテストを始められる担当者がいても、必要なアクセス権限が付与されるまで作業を進められないこともあります。
こうした問題を防ぐには、サイトごとに必要な情報を記録し、担当する開発者が適切なアクセス権限を持っている状態にしておくことが重要です。既存のテスト手順を誰でも確認できれば、担当者はすぐに作業を始められます。技術責任者は、変更によって予期しない動作が発生した場合など、本当に判断が必要な場面に集中でき、毎回「コードはどこにある？」という質問に答える必要もなくなります。
チーム内に蓄積されたサイトの情報が、これまで以上に重要に
卸売業者向けのオンラインストアで、顧客ごとの価格を取得するカスタムURLの応答に数秒かかっているとします。処理を高速化する方法をAIに尋ねると、「応答を10分間キャッシュする」という提案が返ってきました。これなら、リクエストのたびに価格を計算する必要がなくなります。
しかし、このストアでは顧客ごとに個別の価格が設定されています。キャッシュされた応答が別の顧客に返されると、他社向けの価格が表示されてしまうおそれがあります。この機能を実装した開発者は、共有キャッシュを使用していない理由を理解していますが、半年後にパフォーマンス改善を担当する別の開発者は、こうした事情を知らずにキャッシュの導入を提案してしまうかもしれません。
このような情報は、コードのそばに簡単なコメントを残しておくだけでも役立ちます。たとえば、「卸売価格が顧客ごとに異なるから、この応答は共有キャッシュに保存しないこと」といった一文で十分です。
さらに、サイトの管理記録には、該当するコードへのリンクと、異なる価格が設定された2つのテストアカウントを記載しておきます。変更を加えた後、それぞれのアカウントでログインし、表示される価格が各顧客の契約価格と一致しているか確認できるようになります。
こうした情報があれば、担当者はAIが提案したWordPressのキャッシュ設定の変更が適切かどうかを判断できます。また、別の方法をAIに検討させる際にも、サイト固有の事情を踏まえた提案を得やすくなります。
ほかの担当者にサイトの管理を引き継ぐ際、どのような情報を伝える必要があるか考えてみてください。
-
「購買部門が毎週月曜日の会議でこのレポートを使用するため、それまでに生成を完了させる必要がある」
-
「インポートするデータの日付には、仕入先のタイムゾーンが使用されている」
-
「このプラグインの不具合が修正されるまでは、暫定的な回避策を残しておく必要がある」（該当する不具合報告へのリンクも記載）
プラグインのアップデートによって問題が解消された場合は、その旨と日付も記録しておきましょう。古い手順が残ったままだと、AIがその情報を要約する際に、すでに不要になった回避策を提案し続ける可能性があります。
AIを使用する際は、制作会社として承認されたツールを利用し、入力する情報からパスワードなどの認証情報を必ず除外してください。顧客情報についても、質問への回答に必要な場合を除き、入力しないようにします。
正確な診断データがあれば、AIの提案をすばやく評価できる
「決済処理がときどき遅くなる」という情報だけでは、原因を絞り込めません。AIに尋ねれば、考えられる原因をすぐにいくつも挙げてくれますが、実際に問題を解決するには、診断データをもとに可能性を一つずつ検証していく必要があります。
たとえば、商品数が少ない注文では問題がないものの、カートに12種類の商品を追加すると、合計金額の再計算に6秒かかるとします。APM（アプリケーションパフォーマンス監視）ツールで処理を調べると、独自に実装された割引計算用の関数が原因であることがわかりました。この関数は、カート内の商品ごとにデータベースへアクセスし、同じ購入者の注文履歴を繰り返し取得していました。
ここまでわかれば、AIへの質問も具体的になります。「注文履歴を一度だけ取得し、同じ計算処理の中で再利用できないか」という観点から、コードの調査を手伝ってもらえます。
ステージング環境でコードを修正したら、再び12種類の商品をカートに追加し、データベースへのクエリ数を確認します。商品の数量を変更しても、割引が正しく適用されることも検証してください。いくら応答時間が短くなっても、購入者に誤った合計金額が表示されては意味がありません。
翌朝、別のメンバーがこの問題の調査を引き継ぐ場合を考えてみましょう。APMのトレースデータは残っていても、卸売業者用のアカウントを使ってステージング環境でテストしたことまで伝わるとは限りません。そのため、こうしたテスト条件も記録しておく必要があります。WordPressのエラーログを確認してもらう場合は、同じテストに関連するログを特定できるよう、該当する時間帯とタイムゾーンも伝えます。
AIを使って原因を調査する際にも、こうした情報は重要です。Splunkが可観測性（オブザーバビリティ）の専門家1,855人を対象に実施した2025年の調査では、48%がAI活用に向けた最大の障壁としてデータ品質の低さを挙げています。どれほど詳細なトレースデータがあっても、どのアカウントで割引ルールが適用されるのかがわからなければ、AIが問題を正確に分析するための情報は不足してしまいます。
診断データが揃っていれば、クライアントへの状況報告も具体的になります。たとえば、商品数の多いカートでは同じ注文履歴が繰り返し読み込まれていることや、修正後にどのようなテストで改善を確認するのかを説明できます。「いくつかの方法を試している」と伝えるだけでなく、処理が遅くなっている原因と、その解決に向けた対応を明確に示せます。
管理環境を標準化し、複数のサイトで改善策を活用する
あるサイトで実施したパフォーマンス改善が、ほかのサイトにも役立つことがあります。ただし、そのためには、同じ問題が発生している可能性のあるサイトを把握しておかなければなりません。
たとえば、あるレポート作成用プラグインが、過去1年間の注文合計を15分ごとに再集計しているとします。しかし、クライアントがそのレポートを確認するのは週1回の会議のみ。定期的な再集計がデータベースに負荷をかけていることを確認したため、実際の利用頻度に合わせて更新スケジュールを変更しました。
同じプラグインを、ほかの11件のオンラインストアでも使用しているとします。各サイトに導入されているプラグインの一覧が最新の状態で管理されていれば、該当するサイトをすぐに特定し、それぞれの設定を確認できます。一覧がなければ、各サイトの管理画面を一つずつ開いたり、請求書からプラグイン名を探したりしなければなりません。
複数のWordPressサイトを管理していると、「このサイトのカスタムコードはどこに保存されているのか」といった確認作業も積み重なります。ファイルの保存場所や設定項目の名称をサイト間で統一しておけば、担当者が情報を探す手間を減らせます。また、プラグインの設定画面だけではわからない情報も記録しておくと便利です。たとえば、WordPressのcronジョブをサーバー側から実行しているかどうかなどです。
サイトの管理記録には、レポートの更新設定とあわせて「担当者が日中何度もこのレポートを確認する」といった情報も残しておきましょう。別のストアで採用した週1回の更新スケジュールをそのまま適用すると、クライアントが古いデータを参照することになりかねません。
使用しているプラグインのバージョンも記録しておくことが重要です。新しいバージョンで追加されたスケジュール設定機能を探しても、古いバージョンを使用しているサイトでは見つからず、担当者が無駄な時間を費やしてしまう可能性があります。
AIを使えば、エクスポートした設定を比較したり、同じ変更を適用できそうなサイトの一覧を作成したりできますが、変更を加える前に、実際のサイトと照らし合わせて確認してください。同じプラグインを使用していても、クライアントによって機能の使い方が異なる場合があります。
さらに、プラグインの導入手順に「クライアントはどのくらいの頻度でこのレポートを使用するか」という確認項目を追加しておくことをおすすめします。次に別のストアへ導入する際、担当者は初期設定の段階で適切な更新頻度を決められます。
月曜日の朝にしか確認しないレポートを、週を通して15分ごとに再集計する必要はありません。一度調査して得られた知見をチーム内で共有しておけば、次のサイトへの導入時にも活用でき、同じ問題を繰り返し調査する手間を省けます。
既存のレビュープロセスにAIを取り入れる
毎週火曜日にプラグインの更新状況を確認する際、変更履歴のチェックに多くの時間を費やしているかもしれません。サイトごとにインストール済みのバージョンと最新版を比較し、どの変更点を詳しく調べる必要があるか判断しなければなりません。たとえば、独自の割引ルールを設定しているオンラインストアでは、チェックアウト時の価格計算に関わる変更を特に注意して確認する必要があります。
こうした作業にはAIを活用できます。インストール済みのプラグインのバージョンと割引ルールの仕組みを伝えれば、価格計算に影響する可能性のある変更点を抽出してもらえます。ただし、AIによる要約には、元のリリースノートへのリンクも含めることが重要です。開発担当者が変更内容の前後関係を確認できるようにするためです。アップデートが実際にサイトへ影響するかどうかは担当者が判断しますが、確認すべき情報をあらかじめ絞り込むことで、レビューにかかる時間を短縮できます。
一方、「管理しているすべてのサイトを確認して、対応が必要なものを教えてください」といった漠然とした指示では、AIに十分な情報を与えられません。一見すると詳しいレポートが生成されても、開発担当者が確認すべき重要な互換性の問題が見落とされている可能性があります。
まずは、構成や設定をよく把握している数件のサイトで、対象を絞ったAIによるレビューを試してみて、それから自分で確認した結果と比較します。たとえば、まだ提案段階の修正と、すでにリリースされた修正を正しく区別できているか、バージョン番号が不明な場合に、推測で補うのではなく、不明な情報として扱えているかなどです。
スクリプトを使用すれば、各サイトにインストールされているプラグインのバージョンと、公開されている最新版を比較できます。また、設定情報のエクスポートデータが取得できていないサイトを検出することも可能です。
設定情報を取得できなかった場合、レポートには「レビュー未完了：このサイトの設定情報を取得できませんでした」と表示されます。これにより、該当するサイトが確認済みとして扱われることなく、担当者の作業リストに残ります。
単に空欄になっているだけでは、問題が見つからなかったサイトと区別できず、確認漏れにつながるおそれがあります。
業務効率化によって生まれた余力を測定する
「この情報はどこにあるのか」という問い合わせに何度も対応する必要がなくなれば、技術責任者はその分、クライアント案件に集中できます。新規クライアントを受け入れる前でも、こうした改善の効果は実感できるはずです。
プロジェクト管理ツールやサポートツールに記録されたチケットを分析すれば、これまで作業を滞らせていた原因が解消され、実際に待ち時間が短縮されているかを確認できます。チームが抱える課題に応じて、以下のような指標を追跡しましょう。
- リリースまでの待ち時間：修正が完了してから、検証を経てリリースされるまでにどのくらいの時間がかかっているか
- 原因調査にかかる時間：報告された問題の原因を特定するまでに、開発担当者がどのくらいの時間を費やしているか
- チケットの再オープン率：対応完了後に、同じ問題でチケットが再オープンされる割合
- 予定外のサポート対応時間：突発的な不具合への対応によって、予定していたプロジェクト作業の時間がどのくらい失われているか
たとえば、設定情報の確認にプロジェクト責任者の協力が必要だったメンテナンスに関するチケットが6件あったとします。サイトの管理記録を整備した後、新たに発生した同じような作業に関するチケット6件を確認してみましょう。そのうち5件を責任者に確認することなく対応でき、修正後も問題が再発していなければ、情報の整備が業務効率化につながっていると判断する材料になります。
ただし、チケットをクローズして残りの調査を別の担当者に引き継いだだけでは、チーム全体の作業時間は減りません。また、開発担当者は、5分程度の細かな問い合わせ対応をタイムシートに記録しないこともあります。記録されていなくても、こうした割り込みによって作業が中断され、集中できる時間が削られていることに変わりはありません。
改善の効果を正確に判断するには、数週間にわたって作業内容が似ているチケットを比較することが重要です。その際は、チケットの件数にも注目してください。問い合わせの少ない週は、ドキュメントの整備やAIツールの導入とは関係なく、プロジェクト作業に充てられる時間が自然と増えるためです。
こうした改善によって、技術責任者が週に2回、午後の時間をクライアント案件に充てられるようになったとします。次にサポート対応が集中する週が来れば、その時間を安定して確保できるかどうかを確認できます。
予定していた作業の多くを翌週に持ち越すことなく完了できれば、新たなクライアント案件を受け入れる余力があるかどうかを、より確かな根拠に基づいて判断できるようになります。
チーム全体で使い慣れたサーバー環境を整える
「ログを確認して」と伝えるだけで済むのは、担当者がログの場所を把握している場合です。クライアントごとに異なるサーバーサービスを使用していると、サポート対応のたびに、慣れない管理画面から必要な情報を探すところから始めなければなりません。チーム全体で使い慣れた環境があれば、すぐに原因の調査に取りかかれます。
Kinstaでは、こうした作業をMyKinstaに集約できます。オンラインストアの動作が遅くなった場合は、調査に必要な期間だけKinsta APMを有効にし、PHPの処理、データベースクエリ、外部リクエストなどのトランザクションを分析できます。また、サイトの各種ログも管理画面から確認できます。
Kinsta APMを使用すると、複数のサイトのログ確認やメンテナンス作業を効率的に進められます。
開発担当者は、WordPressのステージング環境で卸売業者用のテストアカウントを使用し、先ほどの12種類の商品をカートに追加した際の遅延を再現できます。正しい割引額も把握しているため、本番環境の注文に影響を与えることなく、修正後の計算結果を検証できます。
ただし、処理速度を比較する際には注意が必要です。ステージング環境と本番環境でキャッシュ設定が異なっていたり、ステージング環境に割り当てられたリソースが少なかったりすると、応答時間を単純に比較しても正確な評価はできません。
また、ほかのメンバーがサポート対応を引き継ぐ際、最初のやり取りが「アクセス権限を付与してもらえますか？」にならないようにしたいものです。MyKinstaのマルチユーザー機能を使用すれば、必要なメンバーにあらかじめステージング環境へのアクセス権限を付与し、本番環境へのアクセスは修正を反映する担当者だけに制限できます。複数のクライアントサイトを日常的に担当するメンバーには、サイトごとに権限を設定する代わりに、企業単位の役割を割り当てることもできます。
同じ割引機能の拡張プラグインを複数のストアで使用している場合は、サイトラベルを活用すると、該当するサイトを簡単に特定できます。修正後のテストが必要になった際には、ラベルで対象サイトを絞り込み、各サイトの管理記録からそれぞれの価格設定ルールを確認できます。
ただし、ラベルは実際のサイト構成に合わせて更新する必要があります。すでに拡張プラグインを使用していないストアが、いつまでも対象サイトの一覧に残らないようにしましょう。
まずは身近な課題から改善する
決済機能の不具合を修正しても、ステージング環境へのアクセス権限がなく、テストを始められないことがあります。チケットに「ステージング環境へのアクセス権限待ち」と記載されたまま、半日が過ぎてしまうということもありえます。最近のチケットでこうした状況が繰り返されているなら、改善すべき課題は明確です。担当する開発者が、アカウントの所有者の対応を待たずに作業できるよう、必要なアクセス権限をあらかじめ付与しておく必要があります。
権限の割り当て一覧を確認するだけでなく、実際に担当者自身のアカウントでログインしてもらうことも重要です。管理画面にはアクセスできても、必要な環境を操作する権限がないかもしれません。チケットの対応に追われていないときに確認しておけば、クライアントを待たせることなく問題を解消できます。
「いつもの決済テストを実施して」という指示も、割引機能を実装した開発者と同じように、担当者がストアの仕様を理解していることが前提になっています。引き継いだ担当者は、どのアカウントに卸売価格が適用されるのか知らないかもしれません。割引ルールのコードへのリンクとあわせて、テストに使用するアカウントの情報を記録しておけば、開発者からの返事を待たずに作業を進められます。
次のチケットに「ログインできましたが、カートの合計金額はいくらになるのが正しいですか？」というコメントがあれば、まだ情報が不足していることがわかります。質問に回答する際は、想定される合計金額もテストアカウントの情報と一緒に記録しておきましょう。そうしなければ、翌週決済のテストを担当する別のメンバーから、また同じ質問を受けることになります。
次のサイト管理をもっと効率的に
冒頭で紹介した2つのWeb制作会社の例に戻りましょう。どちらの開発者も、午前10時にはAIを使ってテスト計画の下書きを完成させています。しかし、決済の例外設定が文書化されている会社では、すぐにテストを始められる一方、もう一方の会社では、会議中の担当者からの返事を待たなければなりません。
AIによってチームがより多くの作業を短時間で準備できるようになるほど、こうした小さな違いが大きな意味を持ちます。必要な情報が整理されていれば、特定の担当者に質問や確認作業が集中することなく、AIによる効率化のメリットを十分に活かせます。
まずは、繰り返し発生している待ち時間の原因を一つ特定し、解消することから始めてみてください。そして、次に担当する開発者もその改善を活かせるよう、必要な情報を残しておくことが大切です。
KinstaのWordPress専用マネージドクラウドサーバーなら、管理するクライアントサイトが増えても、チーム全体が使い慣れた環境で問題の調査や変更のテストを進められます。
