【AI社員実践記 第33話】27サイトの速度スコアを、毎月シートへ。5つのつまずきを直した朝

こんにちは、オフィスピコッツの小笹です。

27サイトを並べたスプレッドシートに、モバイルとPCの速度スコアが入りました。最後に残ったのは、26件の点数と、旧ドメイン1件の「取得不可」。全部成功したわけではありませんが、スタッフが1件ずつ画面を開いて集めていた数字を、サーバーから取りに行くところまでつながりました。

作業したのは、9月26日の土曜の朝です。この日は、先に管理サイトの一覧を整え、その一覧を使って速度を測る、2つの仕組みを作りました。AI社員が手順を1つ出し、私が実行して結果を返す。その繰り返しです。

前半は順調でした。ところが後半は、APIキーが3回重なって保存され、足りないタブで止まり、失敗した行があるせいで再実行も飛ばされました。最後は、許可していた接続元と、実際の接続元が違う。今回は、数字が表に入るまでに直したところも含めて書きます。

27件の画面を開く作業を、月1回の計測へ

当社では、管理しているサイトのトップページを、GoogleのPageSpeed Insightsで年2回確認していました。スタッフがURLを1件ずつ入れ、モバイルとPCの点数、改善項目の上位2つを台帳へ書きます。

1件の作業は、目安として2〜3分。27件なら単純計算で54〜81分です。準備や待ち時間もありますが、それらを分けて測った記録はありません。まず減らしたかったのは、画面を開き、結果を待ち、同じ項目を書き写す繰り返しでした。

9月23日にAI社員が出した活用案の一つが、公式APIで結果を取り、スプレッドシートへ書く方法でした。APIは、画面を人が操作する代わりに、プログラムから機能を呼び出す窓口です。25日に内容を詰め、月1回、毎月16日の朝4時に動かす案を採用しました。

ここで集める100点満点の値は、Lighthouseによる計測時のパフォーマンススコアです。実際の全訪問者が体験した速さや、サイト全体の品質を、そのまま点数にしたものではありません。今回は各サイトの対象URLを測り、変化や確認のきっかけを残します。PageSpeed Insightsの公式説明

ただ、計測の前に決めることがありました。「どのサイトの、どのURLを測るのか」。その答えが、サーバーの中の別々の場所に散らばっていました。

1つ目は、速度を測る前の「管理サイト一覧」

監視サーバーには、役割ごとに対象の一覧があります。Uptime Kumaの監視一覧、ドメインの期限を調べる一覧、リンク切れを調べる一覧、保守中バッジを配信する一覧です。同じサイトの情報でも、用途が違えば保存場所も違います。

チャット側のAI社員は、このサーバーへ直接入って中身を確かめる使い方にはしていません。お客様のドメインを聞かれて、以前にも送っていると返すやり取りがありました。情報が存在することと、次の相談でAI社員が参照できることは別でした。

第28話ではサーバーが顧客台帳を読み、第31話ではサーバーの稼働率をシートへ渡しました。今回は、仕事を進める前提になるサイト一覧を、同じように読める場所へ出します。

作ったのは「管理サイト一覧」というタブです。ドメイン、Kumaの監視名、顧客ID、顧客名、当社管理の区分、各種監視やバッジ配信の有無、取得日時を、10列にまとめます。毎朝6時55分に更新する設定にしました。

これでサーバー内の情報を全部知れるわけではありません。参照できるのは、今回集約した項目です。取得日時も一緒に残し、いつの一覧かを見て使えるようにします。

推定していた対応を、サーバーの実物で確かめる

最初の手順は、材料があるかどうかの確認でした。対象の設定ファイル、監視用コンテナ、定期実行の登録行数を見ます。この時点の実行行は22行。既存の接続設定を使う準備では、設定の項目名だけを確かめ、秘密の値は画面へ出さない形で進めました。

次に、Kumaのデータベースをコピーし、その写しから監視名とURLを読み出しました。前日の対応表で、名前から推定して要確認としていた6件も、ここで実物と突き合わせています。分からない部分を推定のままプログラムへ渡さず、対象の対応を先にそろえました。

ドメインと顧客の対応表は27行。見出しを含めると28行のCSVです。これとPythonのプログラムをサーバーへ送り、ファイルのハッシュ値の照合、構文検査、必要なライブラリの確認を進めました。

設定先のタブを用意して初回実行すると、結果は27行。Kumaとの一致は26件、リンク切れの対象は1件、バッジ配信は2件、対応表の抜けは0件でした。

Kumaと一致しなかった1件は、作業記録では旧ドメインです。「27行できた」と「27件すべてを監視している」は違います。監視対象でないものは、その状態のまま表へ出ています。

ここまでを確かめ、毎朝更新する定期実行を1行追加しました。22行から23行へ。次の速度計測は、この一覧を対象に進めます。

2つ目は、同じ月の結果を重ねない速度計測

速度計測では、管理サイト一覧を基に、監視に登録されたURLを使う設計にしました。すべてのサイトへ一律に「https」を付けるのではなく、実際に使っているURLに合わせるためです。

モバイルとPCを測り、それぞれの点数と日本語の改善項目をシートへ残します。従来は上位2項目を書いていましたが、今回の設計では上位3項目を保存します。同じ月・同じドメインの結果は重ねて入れず、指定した1ドメインだけ試せるようにもしました。

30点以下なら再計測し、低い方を残すという独自の取り決めも入れています。これはGoogleが定めた採点方法ではありません。点数は計測条件で変動するので、低い値を注意のきっかけとして残す運用です。前月との差だけを見て、すぐに改修の成否を決めるための数字にはしません。

まずは自社のpikoz.netで試します。対象を1つに絞って、APIの呼び出しからシートへの記録まで通るかを見るつもりでした。ところが、点数を見る前に何度も止まりました。

キーが「ある」ことと、正しく入ったことは違った

APIキーは、チャットへ貼らず、サーバーの設定ファイルへ直接入れる手順でした。ところが私は、入力を待つ状態になる前に貼り付けてしまいました。キーがコマンドの途中へ入り、保存されず、画面に出てしまいます。

AI社員は手順を分け直し、画面へ出たキーは再発行するよう案内しました。この場面で大事なのは、入力をやり直して動くようにすることと、表示してしまったキーを扱い直すことは別だという点です。この記事には、キーの文字列を載せません。

やり直すと、設定が入っていることを示す「1」が出ました。しかし、それだけでは足りませんでした。次の実行は「速度スコア」というタブがなくて止まり、タブを追加すると、今度は「API key not valid」です。

調べた結果、保存した文字列の長さは117文字でした。作業記録では、今回の39文字のキーを3回貼り付けていたことが原因です。

このときは重複した入力を直して進めました。ただ、「長ければ先頭39文字に切ればよい」という一般的な手順にはできません。今回の原因が重複だったから直せたのであって、違う文字が混ざった場合には解決しません。

次の手順では、値そのものを出さずに、入力の有無と想定した形式・長さを確認する。「入っています」という返事を、正しく保存できた証拠にしない。この小さな違いが、今回のやり直しにつながりました。

重複を防ぐ判定が、失敗のやり直しも止めた

キーの入力を直して再実行すると、今度は「skipped=1」。点数が入りません。先ほど失敗した行がシートに残り、「今月のこのドメインは、もうある」と判断されていました。

同じ結果を二重に入れないための判定が、失敗した行にも働いていたのです。行があることを、取得できたことと同じように扱っていました。

AI社員から手で行を消すよう言われ、私は消したつもりでした。でも、もう一度実行してもスキップ。対象行がなくなったことを確認せず、次へ進めていました。最後は、初回テスト中のデータをコマンドで消して、やり直しています。

ここは「最初から表をまとめて空にすればよかった」とは書けません。運用が始まった表には、残すべき過去の結果があります。今回の初期化と、今後の失敗行の再計測は分けて考える必要があります。

成功済みなら追加しない。取得に失敗しているなら、対象を絞って再試行できるようにする。今回は手で対象行を整理して進めましたが、失敗行を自動で再試行する仕組みまで完成したわけではありません。

403の理由は、許可していなかったIPv6だった

続いて出たのは403エラーです。エラー文には、APIキーにIPアドレスの制限があり、今回の呼び出し元がその制限に合わない、と書かれていました。

前日に許可したのはサーバーのIPv4アドレスでした。一方、このときGoogle側が受け取った接続元はIPv6です。同じサーバーからの通信でも、許可していたアドレスと、実際に使われたアドレスが違っていました。

Google Cloud側で、今回のサーバーが使うIPv6アドレスを許可先へ追加しました。制限そのものを外すのではなく、必要な接続元をそろえています。Googleの公式資料でも、接続元制限にはIPv4とIPv6の両方を指定できます。APIキーの接続元制限

設定の反映を待ってから試すと、ようやく点数が出ました。pikoz.netは、モバイル66、PC96。結果は1件書き込み、スキップ0件、失敗なしです。

27行のうち、26件の点数と1件の取得不可

自社サイトで通ったあと、残りを実行しました。途中で点数がそろわなかった対象もありましたが、2件を再計測し、最後の表では26件にモバイルとPCの値が入りました。旧ドメイン1件は、取得不可のままです。

27行が埋まっているから、27件の計測が成功したとは言えません。取得できなかったものを0点へ置き換えず、点数がある行と区別して見る必要があります。管理サイト一覧に旧ドメインが残っていることも、この表から確認できる材料です。

また、画像で見える改善項目は、列幅の都合で途中までです。上位3項目の全文や順位の妥当性まで、この画面だけで確認したとは書けません。今回は、対象ごとの点数と取得状況を一覧にするところまで進みました。

最後に、毎月16日の4時に動く設定を追加しました。定期実行の行数は23から24へ。この日の2つの仕組みで、合計2行増えています。

次の予定は10月16日です。今回確認できたのは手動実行の結果と、定期実行への登録まで。翌月に自動で動き、新しい月の結果が入り、失敗した対象を見落とさず確認できるかは、これから見るところです。

1手順ずつ進めても、確認が抜ければ止まる

今回のつまずきは、キーの入力位置、タブの作成漏れ、キーの重複、失敗行のスキップ、接続元の制限でした。どれも、起きたことが結果の表示に出ていました。

ただ、AI社員が手順を1つずつ出しただけでは、抜けは防げませんでした。タブを足すよう書いてあっても、実際にできているかを確かめていない。行を消してと伝えても、消えたかを見ないまま次の実行を案内する。設定値があることだけを見て、重複した入力に気づかない。

私の操作にも間違いがありました。その間違いが起きたとき、次の手順へ進める状態かを、短い確認で判断できるようにする必要があります。説明を長くするだけでは、今回の問題は減りません。

見る範囲も、毎回シート全体である必要はありません。タブがあるか、対象の1行が消えたか、今回の件数が何件か。直前の操作に合った確認を、その場で返してから次へ進む。この日の反省は、次の手順書へ残すことにしました。

この日にできたことと、次に確かめること

この日は、相談ややり直しも含めて午前中の作業になりました。画面にある時刻は、それぞれの処理を行った時点で、相談開始から終了までを通して測ったものではありません。今回は、全体の正確な所要時間は出していません。

同じように、年2回の手作業が今後どれだけ減るかも、まだ実績ではありません。初回は、入力のやり直しや失敗行の整理に人が関わっています。月次で回したあと、数字を集める時間と、結果を確認する時間がどう変わるかを見ていきます。

今回変えたのは、速度そのものではなく、速度の数字を集めるまでの工程です。別々に置かれた対象一覧をそろえ、その一覧を基に測り、結果を表へ残す経路ができました。

次に人がするのは、点数を上から書き写す作業ではなく、取得できなかった理由や、前と違う数字を確かめることです。その判断へ進めるよう、まず材料を集めるところから整えた土曜の午前でした。

AI社員実践記は、まだ続きます。

• 無料AI活用診断
• AIレスキュー
• ネット顧問
• AI社員実践記一覧

技術の話はここまで。考え方の話は「社外Web担当の頭の中」へ。