こんにちは——同じメッセージで2つのことを尋ねましたね。3つのドメインの同期が設定より1時間遅れて実行された理由と、その勢いで最適化チームを自律モードに切り替えるべきかどうか。実はこの2つは同じ話に行き着くので、別々に答えるのではなくまとめて説明します。
まずシステムの構造から始めましょう。それが両方の疑問を説明してくれます。ここではすべてのチームが「1回のみ」「手動」「自律」のいずれかのモードで動きますが、「自律」は別枠の高性能なモードではありません。それはスケジュールが付いていて、ループが閉じられたままの手動実行です。同じエージェント、同じガードレール、すべて同じで、違うのはボタンを押すタイミングをあなたではなくスケジューラーが決めるという点だけです。これがわかれば、残りは自然と腑に落ちます。
なぜ同期とスケジュールが別々の場所にあるのか
| スケジュール | 何を駆動するか |
|---|---|
| データ同期 | サーチコンソール/アナリティクス/ストアデータをダッシュボードに毎日取り込む処理——他のすべての燃料になる |
| エージェント実行 | 各同期後の自動最適化実行、ブリーフキューを補充するリサーチスイープ、そして稼働させたままにしているチーム |
同期設定は各ドメインに、実行設定は各チームに紐づいています——1つにまとまった自動化ページにあるわけではなく、初めて探したときには違和感を覚えるかもしれません。しかしこれは意図的な設計です。同期の頻度はデータに関する問題です——サーチコンソールが実際にどれくらいの速さで更新されるか。実行の頻度はチームに関する問題です——そのチームに、見たものへどれくらいの速さで動いてほしいか。これらは異なる質問であり、異なる答えを持ちます。以前のバージョンのこのプラットフォームでは、これらが1つのページにまとめられており、片方を触るだけで両方について考えざるを得なくなっていました。それを分離したのがこの修正です。
最適化チームのスケジュールを組む前に知っておく価値があること——スケジュールで発火する実行と、手動で開始する実行は、開始してしまえば全く同一のものを生成します。同じレポート、同じ履歴エントリ、同じクレジットコスト、実行中に開いて何をしているか見ることができる点も同じです。スケジュール実行はコスト削減のための軽量な簡易版だと思い込む人を見てきましたが、そうではありません。自分で開始した実行を信頼できないなら、それをタイマーには載せないでください。
移行したスケジュールで実際に何が問題だったのか
以前のツールから時刻をそのままコピーしたと言っていましたね——UTC 14:00、現地時間で午後2時に合わせたつもりのものです。それがまさに落とし穴です。時刻フィールドが求めているのは現地時刻であって、UTCではありません。検出されたタイムゾーンがすぐ下に表示されるので、推測する必要はないはずです。そこにUTC値をそのまま貼り付けると、すでに現地時間であるものとして扱われ、もう一度UTCに変換されてしまい、結果として午後2時ではなく午後4時に実行されることになります。残りの2つのドメインの修正方法:古いツールが出していたUTC値は無視して、時刻を現地時間で入力し直してください。
実際にお尋ねになった1時間のズレ——同期が午前6時ではなく午前7時に実行された件——はDSTの副産物で、毎年3月と10月に追いかけ回すよりも一度きちんと理解しておく価値があります。1月にベルリンで6:00の同期を設定すると、プラットフォームは5:00 UTCとして保存します。ベルリンは冬にUTC+1だからです。単純なスケジューラーなら、そのまま永遠に5:00 UTCで発火し続けます。DSTの切り替えが来ると、ベルリンはUTC+2に移行し、同じ5:00 UTCのタイミングが現地時間では7:00になります——エラーもなく、ひっそりと、想定より数時間遅れた数字になるだけです。私たちは入力時点で現在のオフセットに対して変換を行うため、6:00のスケジュールはDSTの有無にかかわらず、実行日の壁時計上で6:00を意味します。現地時間で入力し直した後もまだ1時間のズレが見られる場合は、サポートチケットを出す価値があります——新しく入力し直したスケジュールでそれが起きるべきではありません。
実際の頻度を設定する
- 同期：1日1回、それ以上は不要。 Search Consoleのデータは、順調な日でも2〜3日遅れで届きます。3つのドメインで1時間ごとに同期しても、より新しい数値が得られるわけではなく、同じ遅延データを何度も取得するジョブで同期履歴が埋まるだけです。
- 最適化：独自の時計ではなく、同期に連動。 これは、これからスケジュールを組む上で最も重要な部分です。Googleのその日のAPIが遅く、同期が6:00ではなく6:02に完了した場合、最適化の実行は独自の6:15スロットを待って前日の数値を使うリスクを冒すのではなく、その新しいデータに対してすぐに実行されます。独立した2つの時計は、ずれが生じる日までは問題なく見えるものです。
- リサーチ：週1回、コンテンツチームが実際にさばける量に合わせる。 ブリーフは一晩で古くなるわけではありませんが、レビューされずキューに溜まったブリーフは、誰も対応しなくてもクレジットを消費します。チームが現実的に週4〜5件のブリーフを承認できるなら、その量に合わせてスイープの規模を決めましょう。毎日のスイープを週次レビューの習慣に流し込んでも、誰も消化しきれないバックログが積み上がるだけです。
- 広告（来月そのチームに着手する際）：あえてスケジュールなし。 下書きはオンデマンドで生成され、あなたの承認なしに投稿されたり出費されたりすることはありません。理由は自動運転による広告支出への反対論に書いていますが、要は、コンテンツ同期のスケジュールミスは些細な迷惑事で済むのに対し、広告支出のスケジュールミスは請求書になる、ということです。そのチームの設定が、今日あなたが設定しているものと同じ見た目になるとは思わないでください。
では――最適化を自律モードに切り替えるべきでしょうか？
正直な答えは、質問が示唆するほど劇的なものではありません。オンにしても変わることは思ったより少ないのです。エージェントは、あなた自身が実行をクリックしていたときになかった能力を新たに得るわけではありません――破壊的な操作に対する確認ゲートも、判断基準も、その他すべても同じです。変わるのは、いつ実行するかを誰が決めるかだけです。今はあなたが決めています。スケジュールにすると、時計が決めることになります。
「自律モードは安全か」の代わりに私が実際に問いたいのは、こういうことです――直近3回の手動最適化実行の結果が、あなたが設定したどんな頻度であれ、無人のまま繰り返されることに納得できますか？もし「はい」なら準備はできています――オンにしましょう。もし、その3回それぞれを自分自身が事前にレビューしていたから納得できているのだとしたら、それは重要なシグナルであり、もう少し手動を続けるのが正しい判断であって、度胸がないという話ではありません。
現状――3つのドメインを移行したばかりで、時刻もまだ完全には落ち着いていない――を踏まえると、自律モードはあと数日待つことをお勧めします。残り2つのスケジュールを直し、明日の同期が正しい時刻に着地するのを確認し、最適化をあと2〜3回手動で実行して、実際に何が起きるかを一通り見届けましょう。それからスケジュール設定すればいいのです。上記の頻度に関する疑問は、抽象論としてよりも、実際の実行結果を目の前にしたほうがずっと答えやすくなります。1週間待つことに損はありません。
