【AI社員実践記 第24話】サーバーの時計は誰の時計か　cronを4本足す前に確かめた1行

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

朝7時。

ノートPCの前でPowerShellを開き、いつもの監視用VPSへ接続しました。

この日の作業は、サーバーに新しい自動処理を追加すること。

AI社員には前もって作業手順書を作ってもらっていました。

何を確認するか。

どのコマンドを打つか。

どこで一度止まって結果を見るか。

手順は一通り揃っています。

つまり私は、

手順書どおりに進めればいい朝

のはずでした。

ところが、最初の現状確認をAI社員へ見せたところで止められました。

「この手順書、時刻の前提が違っているかもしれません」

と言われたのです。

実際の作業時間は、ここから一通りの確認・登録まで約30分。

短い作業でしたが、その中で、

• cronの9時間ズレ
• –helpで本番処理が始まる問題
• Ubuntu側のPython保護
• .envの想定違い
• Search Consoleから次の改善候補を1件まで絞る処理

まで確認することになりました。

今回は、そんな朝の話です。

最初にやったのは「追加」ではなく現状確認

最初の作業は、現在サーバーに登録されているcronの確認でした。

cronは、

「何曜日の何時に、このプログラムを実行する」

という予約表です。

新しい処理を追加する前に、まず現在の一覧を表示します。

既存の処理には、

ドメイン期限チェック。

月次稼働率レポート。

リンク切れチェック。

補助金の締切ウォッチ。

差分監視。

保守表示バッジの更新。

などが並んでいます。

AI社員へこの画面を渡しました。

すると、予定していた次のコマンドではなく、

「まずサーバーのタイムゾーンを確認してください」

と返ってきました。

既存のcronを見ると「日本時間で動いている」ように見えた

AI社員が気にしたのは、既存の実行時刻です。

例えば保守表示バッジ。

これは毎朝7時50分に動いています。

cronにも、

50 7

と書かれています。

リンク切れチェックも同じです。

毎週水曜日の朝3時ごろに動く処理が、

0 3

になっています。

どちらも、

cronへ書かれた時間と、実際に動いている日本時間が一致している。

ところが、事前に作った新規処理の手順書では、

「サーバーはUTCで動いている」

という前提になっていました。

日本時間で動かしたい時刻を、わざわざUTCへ9時間戻して書く設計です。

もしこのサーバー自体が日本時間なら、その換算は不要です。

そこで確認したのが、この1行でした。

date; timedatectl | grep -i “time zone”

結果は、

Asia/Tokyo (JST, +0900)

でした。

サーバーの時計は、日本時間です。

正しい知識で、間違った手順書ができていた

「日本時間はUTC+9」

これは正しいです。

「UTCで動くcronなら、日本時間から9時間引いて登録する」

これも正しい。

でも今回のサーバーは、

そもそもJSTで動いていました。

前提だけが違います。

そのまま登録していたら、

「毎月15日3時30分」

に動かしたい処理が、

14日18時30分

に動きます。

「月曜日4時」

なら、

日曜日19時。

処理自体は正常に動くので、エラーにはなりません。

メールも届きます。

ファイルもできます。

だから余計に厄介です。

台帳には月曜4時と書いてあるのに、実際には日曜19時に動き続ける。

そんな状態になりかけていました。

過去のcronにも同じ9時間ズレが残っていた

既存のcronをさらに見ると、似た設定がありました。

例えばドメイン期限チェック。

当初の考えでは、

月曜日の朝6時

に動かす処理です。

ところが現在の予約では、

日曜21時

になっています。

以前設定したときにも、

「JSTをUTCへ換算する」

という同じ思い込みをしていたわけです。

今回のAI社員は、

過去に設定したcronの痕跡を見て、今回の手順書の矛盾に気づいた

ことになります。

ここが今回かなり面白かったところです。

AIが一般知識を間違えていたわけではありません。

現物を見ずに、一般論を当てはめていた。

そして今回は、現物を見たことで止まれました。

既に動いている処理は、あえて直さない

では、既に9時間ずれている処理も全部直すのか。

今回は直しませんでした。

実際には、その時刻で正常に動いているからです。

さらに現在の自動処理には、Uptime Kumaを使った「点呼」もあります。

処理が正常終了すると、

「終わりました」

という合図を返します。

cronだけ急に9時間動かすと、点呼の間隔まで変わります。

場合によっては、

「いつもの時間に返事が来ない」

という余計な通知を出す可能性があります。

ならば、

正常に動いているものは触らず、台帳側を実際の時刻に合わせる。

その方が安い。

今回はそう判断しました。

「設定ミスを見つけたら全部直す」

ではなく、

今の安定稼働を壊すほどの問題か

で判断します。

次は –help で止まった

タイムゾーンの確認が終わり、新しい処理の登録へ進みました。

次に確認したのは、月次の定点観測スクリプトです。

cronへ入れる前に、

「まず起動できるかだけ確認しよう」

という手順になっていました。

手順書に書かれていたのは、

python3 fixed_obs_check.py –help

です。

普通なら、使い方を表示して終わるコマンドに見えます。

実行しました。

ところが、

画面が返ってきません。

33サイトの本番処理が始まっていた

原因は単純でした。

このPythonスクリプトは、

–helpに対応していません。

引数を無視して、通常どおり本番処理を開始。

33サイトを順番に巡回し始めました。

私としては、

「ヘルプを確認しただけ」

のつもりです。

実際には、

月次観測を本番実行していた。

AI社員に、

「このまま待つ？」

と確認。

少し待って戻らなければCtrl+Cで止めることにしました。

最終的には途中で停止。

途中結果のファイルは残らず、以前の初回データもそのままでした。

壊れたものはありません。

cronへの登録だけ進めます。

–helpが使えるかは、AIではなくコードが決める

この出来事も、今回のテーマと同じです。

AI社員は、

–help

が使える前提で手順書を書いていました。

CLIのプログラムではよくある仕様です。

でも、

実際のこのスクリプトが対応しているかは別。

一般的には正しい。

この現物には当てはまらない。

タイムゾーンと同じでした。

手順書より、実物の方が強い。

今後は「安全確認用のオプションだから大丈夫」と決めつけず、そのコードで本当に実装されているかを見る必要があります。

Ubuntu 24.04にも一度止められた

Google Search Consoleのデータを取得する処理では、必要なPythonライブラリを追加しました。

pip3 install

を実行すると、そのままでは入りません。

Ubuntu側から、

システム管理下のPython環境を直接変更しないように

止められました。

そこで既存環境を壊さない範囲で、ユーザー領域へ入れる方法へ変更。

こちらはすぐに通りました。

AIが作った手順が古い。

OS側の仕様が新しくなっている。

こういうことも、実際に触ると出てきます。

.envも、想定していた中身と違った

もう一つはメール設定です。

新しい処理では、既存の「締切ウォッチ係」の設定を流用する予定でした。

手順書では、

.env

の中に、必要なメール設定がまとまっている想定です。

実際に見ると、

パスワードの設定しかありません。

送信元メールアドレスは、既存のPythonスクリプトへ直接書かれていました。

そこでAI社員が既存コードを検索。

今の構成を確認してから、

• .envへ送信元の設定を追加
• 新しい処理用のキーを追加

という形にしました。

既存スクリプトはできるだけ触りません。

最近のVPS作業では、

新しい仕組みに既存環境を合わせるのではなく、動いている既存環境へ新しい仕組みを寄せる

ことが増えてきました。

第8係「GSC取りこぼし抽出」を動かしてみる

この日追加した処理の一つが、

第8係「GSC取りこぼし抽出」

です。

Google Search Consoleの直近28日分を取得し、

かなり表示されているのに、クリックされていない検索語やページ

を抽出します。

初回テストでは、

1,269行中、条件一致5件。

その中身を見ると、

3件は同じページに集中していました。

表示回数は1,404回。

ただし、このページは9月初めに既に修正しています。

残り2件のうち1件も、同じく修正済み。

つまり、

5件中4件は「既に対応中」

です。

残った1件が、

「seo対策 滋賀」

平均順位29.5位。

こちらはまだ手を入れていません。

1,269行の検索データから、

「次に見るならここ」

という1件まで絞れました。

Search Consoleを眺める30分を、自動処理へ渡す

もちろん、同じことは人間でもできます。

Search Consoleを開く。

期間を調整。

表示回数を見る。

クリック率を見る。

掲載順位を見る。

ページを確認。

既に対応済みか確認。

これをやれば、同じ候補へたどり着けます。

ただ、

毎週同じように見るか

と言われると、続きません。

そこで毎週、自動で候補だけを抽出します。

人間は、

届いた候補を見て、やるかどうか判断する。

また一つ、

「探す」

という作業を機械へ渡しました。

第7係は「全ページマップ差分」

同じ日に追加したもう一つの処理が、

第7係「全ページマップ差分」

です。

WordPressの公開ページをAPIから取得し、現在の状態を保存します。

初回では、

固定ページ239件

投稿1,940件

を取得しました。

合計2,179ページです。

これを基準にして、次回から、

• 新しく増えた
• 更新された
• 消えた

という差分だけをメールします。

2,000ページを超えるサイトになると、

人間が、

「全部のページを把握している」

という状態は現実的ではありません。

だったら、

全部を覚えるのではなく、前回との差だけ覚える。

第21話でAI社員の「記憶をファイルに置く」話を書きましたが、サイト管理でも同じ考え方になってきました。

OS更新後に再起動して、最後に現物をもう一度見る

この日はUbuntuの更新も行いました。

更新後にサーバーを再起動。

再接続して、

• カーネル
• 稼働時間
• Uptime Kuma
• cron登録数

などを確認します。

正常に起動しています。

今回も、

設定を書いた時点では終わりにしない。

再起動後の現物を見るところまでを作業に含めました。

実作業は約30分だった

ここまでの実作業時間は、

約30分。

当初の手順書にはもっと長い想定時間が書かれていましたが、実際にはそこまでかかりませんでした。

今回時間を使ったのは、

大量のコマンド入力ではありません。

むしろ、

「この前提、本当に合っている？」

を確認する時間です。

サーバーの時計は何時か。

–helpは本当にhelpか。

.envには本当に必要情報があるか。

既存コードはどうなっているか。

目の前のものを見て、その都度AI社員が手順を修正しました。

AIが速かったより、止まったことの方が価値があった

今回、30分でいくつもの作業が進みました。

でも、

「AIを使ったら30分で終わった」

ことより印象に残ったのは、

作業開始5分も経たないうちにAIが止まったこと

です。

自分で作った手順書に従わず、

既存cronを見て、

「前提がおかしい」

と言った。

もしそのまま進んでいたら、新しい処理は9時間ずれて登録されていました。

しかもエラーにはなりません。

普通に動き続けます。

正常に動く間違い。

こういうものが一番見つけにくい。

正しい知識ほど、前提確認が必要

今回のタイムゾーン問題は、

AIが知らなかった話ではありません。

むしろ正しい知識を使っています。

UTC。

JST。

9時間差。

全部合っています。

それでも間違った。

なぜなら、

「このサーバーはUTCである」

という前提が間違っていたからです。

AIでも人間でも、

知識が正しいことと、

今の現場へ正しく適用できることは別です。

だから、サーバー作業では今後も、

最初に現物確認を入れる。

これを基本にします。

手順書を書いた者が、手順書を一番疑う

今回の学びを一言にすると、

これです。

手順書を書いた者が、手順書を一番疑うべき。

AI社員が書いたから信用しない。

という話ではありません。

人間が書いた手順書でも同じです。

昨日正しかった情報が、

今日も正しいとは限りません。

OSが変わる。

設定が変わる。

以前の自分が変更している。

別の担当者が触っている。

だから、

手順書を現物へ当てる。

合わなければ、手順書側を変える。

月曜の朝に「提案材料」が勝手に揃う

今回の追加で、週明けにAI社員が使える材料も増えました。

既存の週次判定。

全ページ差分。

GSCの取りこぼし候補。

人間が、

Search Consoleを開く。

ページ一覧を見る。

前回データと比較する。

その作業は必要ありません。

機械が集めて、候補だけを残します。

そのうえでAI社員が、

「今週は何をするか」

を考える。

自動化の目的も、

単純な「時短」から少し変わってきました。

人間やAIが判断する前の材料集めを、自動化する。

最近はその使い方が増えています。

今回の結論

今回、監視用VPSへ新しい自動処理を追加しました。

実作業は約30分。

その中で、

• cronのタイムゾーン前提の誤り
• 過去の9時間ズレ
• –helpで本番が始まる問題
• Ubuntu側のPython保護
• .envの想定違い
• GSC 1,269行から5件の候補抽出
• 全2,179ページの初回スナップショット

まで確認しました。

でも、今回一番大きかったのは新しい処理そのものではありません。

AIが、AIの書いた手順を途中で止めたこと。

そして、

現物を見てから進めたこと。

です。

AIへ作業を任せると、

答えが速く返ってくることに目が向きがちです。

でも実際の仕事では、

止まるべきところで止まれること

の方が価値を持つ場面があります。

今回の30分は、それをかなり分かりやすく感じた作業でした。

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

• 無料AI活用診断：https://pikoz.net/ai-shindan/
• AIレスキュー：https://pikoz.net/ai-rescue/
• ネット顧問：https://pikoz.net/komon/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

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