このページの内容
2026年10月8日、Lance Martin と CJ Avilla は、毎朝 Slack と GitHub を読んで Slack に要約を投稿するエージェントの解説を公開しました。それが動いているところを見ている人はいません。いちばん役に立つ段落は、成功のように見える失敗についてのものです。ソースのサーバーが落ちていたりトークンが期限切れだったりすると、「エージェントはそのソースから何も見えず、『新着なし』と報告する」のです。
Shopify から Brevo への連絡先同期にも同じ失敗があります。2つの SaaS ツールの間のスケジュール同期はどれもそうです。黙って失敗した読み取りは、今日は誰も登録しなかったストアとまったく同じに見えます。
彼らの記事は、誰も見ていないところで動くエージェントのための6つのルールで締めくくられています。同期を運用する立場で読むと、どれも reverse ETL のルールです。ワーカーは落ちても、同期は止まらなかったは、クラッシュの中で1件の連絡先を追いかけました。このページはその上にあるチェックリストです。自動データ同期のための6つのルール、それぞれについて Tajo のランナーが今日していること、そして足りないところ。ランナー側のことは止まった同期や失敗した同期を復旧するにまとめています。
1. しおりから読み、バッチが届いたときだけ進める
彼らの最初のルールは「各ソースを固定の時間枠ではなく、しおりから読む」です。「過去24時間」という時間枠は、実行が遅れて始まれば隙間を残し、早く始まればレコードを重複させます。
Tajo の同期は、保存されたカーソルからソースをバッチ単位で読みます。カーソルはバッチの終わりに進みますが、それはそのバッチのすべてのレコードが届いたときだけです。失敗した実行は最後の問題のない位置を保つので、次の実行は中断されたバッチを飛ばさずにもう一度読みます。
注文には専用のしおりがあります。Shopify の注文のスケジュール同期は最初のスケジュール実行から始まり、前回の実行以降に変わったものを送ります。過去の注文は、人が同期を実行したときにだけ送られます。スケジュール実行と人が始めた実行は別々のカーソルを持つので、履歴のバックフィルやテスト用のバッチがスケジュール側のカーソルを巻き戻すことはありません。
代償は、中断されたバッチが二度読まれることです。それを安全にするのがルール2です。
2. すべての書き込みに、クラッシュを越えて残るキーを付ける
彼らの4つ目のルールは、投稿を「Slack が確認したときだけ」送信済みとし、そのときに初めてしおりと台帳を更新します。書留郵便はこう動きます。窓口を出たときではなく、署名入りの受領証が戻ってきたときに配達済みになります。
Tajo がレコードを書き込む前に、レコードは配信キーを受け取ります。キーは同期、ソース、ページのカーソル、ページ内の位置、レコード自体のハッシュなので、個人データは含みません。宛先を呼び出す前に確保され、書き込みが成功すると完了として記録されます。完了したキーは7日間保持されます。再試行や後のスケジュール実行は、同じレコードについて同じキーを導き出し、それが完了済みだとわかると宛先を再び呼び出しません。
これには2つの代償があります。7日を過ぎると台帳は忘れるので、古いカーソルからの再実行は再び書き込むことがあります。そして、タイムアウトした書き込みはもっともな疑いを残します。相手のシステムは応答せずに保存したかもしれません。Tajo はその書き込みを7日間失敗として記録するのではなく、後の試行でもう一度試します。宛先に独自の冪等性キーを渡せるコネクタなら、この疑いを解消できます。渡せないコネクタには、重複が1件生じる可能性が残ります。
3. 1つの実行が同期を持ち、書き込みのたびにそれを証明する
彼らの3つ目のルールは「投稿する直前に、すべての項目を確認し直す」です。同期の場合、読み取りから書き込みまでの間にいちばん変わりやすいのは、誰が書き込んでよいかです。
Tajo の各同期には1つのリースがあり、専用のトークンと15分の寿命を持ち、5分ごとに更新されます。実行は、宛先を呼び出す前にリースをまだ持っているか確認し、カーソルを進める前にもう一度確認します。リースを失った実行は止まり、そのページには「実行が途中で枠を失い、二重書き込みを避けるために停止しました。」と表示されます。動いている実行とぶつかった2つ目の実行は、後ろに並ばずに終了します。
レコードも確認されます。読み取りと書き込みの間で、レコードは同意フィルターを通ります。証明できる同意なしにマーケティング用のオーディエンスへ書き込まれようとする連絡先は、推測されずに拒否されます。ヘルプページの言葉を借りれば、失敗の方向は「慎重すぎる」側であり、「送りすぎる」側ではありません。
4. 一時的なものは再試行し、そうでないものは止める
彼らの6つのルールは、どれくらいの頻度で再試行するかについて何も言っていません。同期にはそのルールが必要です。いちばんよくある失敗は、レート制限とベンダー側のほんの数分の不調だからです。
キューに入った Tajo の実行が失敗すると、5回の試行が与えられます。その間の待ち時間は60、120、240、480秒で、合計でおよそ15分です。失敗の中には、もう一度試しても直らないためけっして再試行されないものもあります。すでに進行中の実行とぶつかった実行は再試行されず、公開済みのバージョンや接続がもう有効でない実行も再試行されません。
連続する失敗は、一度のつまずきとは違います。同期が最後に変更されてから完了した直近5回の実行がすべて失敗すると、Tajo は同期を一時停止し、最後のエラーをそのページに表示します。1回の成功でカウントはリセットされます。一時停止した同期がひとりでに再開することはありません。人が原因を直し、もう一度公開します。ワーカーの記事は、このルールを生んだ出来事を書いています。
5. 沈黙を発見として扱う
「失敗した読み取りは、静かな一日ではなく、読めなかったと報告する」。6つの中でいちばん難しく、私たちが一部しか満たせていない唯一のルールです。
守れているところ。エラーになった読み取りは実行を失敗させます。拒否されたトークンや応答しないサーバーは宛先に何も送らず、カーソルを元の位置に残し、5回の失敗による一時停止のカウントに入ります。さらに毎時13分に、Tajo は有効な同期のあるすべてのワークスペースを確認します。直近24時間に成功した実行がなければ、自分たちのチームにアラートを出します。実行が1件も記録されていないワークスペースも対象です。これが毎時のチェックです。
守れていないところ。著者たちが書いている静かな読み取りとは、レコードなしで「OK」と答える読み取りです。私たちのランナーはそれを成功として数えます。Shopify の顧客のようなソースでは、以前にレコードを生み出していた同期が0件の成功を10回続けると、別のチェックが Tajo のチームに警告します。Shopify の注文は更新時刻で読むので、空の実行は普通のことであり、このチェックは動きません。レコードをいくらか返すものの本来より少ないソースは、まったく検出されません。
反論はこうです。「15分ごとのスケジュールなら、空の実行10回は2時間半になる。なぜ最初の1回でアラートを出さないのか」。連絡先の同期は実際にデフォルトで15分ごとに動きます。そして、15分間新しい顧客がいないストアはごく普通です。最初の空の実行でアラートを出せば毎晩鳴り、いつも鳴るアラートは誰にも読まれません。その線引きは速さを信頼と引き換えにしています。それでも沈黙についての推測であることに変わりはなく、著者たちのルールではありません。
6. 同期が書き込んでよいものを一度決め、すべての実行にそれを証明させる
彼らの5つ目のルールは、エージェントの設定を「エージェントが編集できない保存場所」に置きます。6つ目は、読むだけの場所ではエージェントに読み取り専用のアクセスだけを与え、1回の実行で使える額に上限を設けます。どちらも、エージェントが他人の書いたテキストを読み、そのテキストがエージェントに命令しようとすることがあるから存在します。
同期にとっての設定ファイルは、公開済みのルールです。Tajo の同期を公開すると、プレビューしたルールそのもののダイジェストに結び付けられます。編集すると下書きに戻り、再び動く前にもう一度プレビューを通ります。すべての実行は、何かを変える前に、その公開済みバージョンを公開時の接続で動かしていることを確認します。この確認に失敗した実行は再試行されません。方向も固定されています。同期ルールは一方向に書き込み、Shopify に書き戻すことはありません。
支出の上限には対応するものがありません。私たちの同期の実行には、実行ごとの支出上限はありません。再試行の上限と一時停止が抑えるのは、失敗がどれだけ続くかであって、1回の実行にかかるコストではありません。
できていること、できていないこと
この記事の執筆時点でできていること：
- バッチのすべてのレコードが届いた後にだけ進むカーソルと、人が始めた実行では巻き戻せない、スケジュール実行用の注文カーソル。
- 7日間保持される完了済み書き込みの台帳と照合される、レコードごとの配信キー。
- 書き込みの前とカーソルが進む前に確認される、同期ごとに1つのリース。
- 60秒、その後120、240、480秒待つ実行ごとに5回の試行。衝突や無効な公開では再試行しません。
- 同期のページに表示される、5回続けて実行が失敗したときの一時停止。
- 直近24時間に成功した実行がないときの毎時のアラート。
- マーケティング用のオーディエンスに書き込まれる連絡先に対する実行時の同意フィルターと、すべての実行で公開済みバージョンであることを確かめるチェック。
できていないこと、頼る前に知っておくべきこと：
- 0件で成功した読み取りは、読めなかったとは報告されません。10回の警告がその一部をカバーします。Shopify の注文や、レコードを少なく返しすぎるソースはカバーしません。
- 24時間のアラートが届くのは Tajo で、あなたではありません。10回の警告も同じです。一時停止は同期のページに表示されます。
- 毎時のチェックが見ているのはワークスペースで、個々の同期ではありません。健全な同期が1つあると、その隣の沈黙した同期が隠れてしまいます。
- 実行ごとの支出上限はありません。
- 一時停止した同期を再開するものはありません。人が再開します。
- 5回の失敗による一時停止と24時間のチェックは、同期ごとではなく Tajo のデプロイメント全体で設定されています。
これらのどれかがあなたの同期に現れたら、止まった同期や失敗した同期を復旧するが、何が見えるか、何をすればよいかを説明しています。
著者たちは、人が毎朝読む要約のために6つのルールを書きました。同期には朝の読み手がまったくいません。だからこそ、同期のほうがこれらのルールを必要としています。ルール1から4とルール6は、今日すでに私たちのランナーのコードになっています。ルール5は半分だけ書かれています。ソースを読めない同期は、そう言うべきです。
よくある質問
誰も見ていないときに自動データ同期を安全に動かすには、何が必要ですか？
6つです。バッチ全体が届いてから初めて進むカーソル。再試行のたびに同じものが導き出され、完了した書き込みの台帳と照合される、レコードごとの配信キー。同期ごとに一度に1つの実行。上限のある再試行と、実行が失敗し続けたときの一時停止。丸1日何も成功しなかったときのアラート。そして、すべての実行がそれを動かしていると証明しなければならない公開済みのルールです。
同期が「過去24時間」のような固定の時間枠を読むべきではないのはなぜですか？
実行は時間どおりには動かないからです。遅れて始まった実行は時間枠がけっして埋めない隙間を残し、早く始まった実行はレコードを二度読みます。保存されたカーソルなら、実行がいつ始まっても、最後の問題なく終わったバッチの終わりから正確に始められます。
Tajo は、再試行された同期が同じレコードを二度書き込むのをどう防いでいますか？
各レコードは配信キーを受け取ります。これは同期、ソース、ページのカーソル、ページ内の位置、レコード自体のハッシュです。キーは宛先を呼び出す前に確保され、書き込みが成功すると完了として記録されます。完了したキーは7日間保持されます。再試行や後の実行は同じキーを導き出し、宛先を再び呼び出しません。
読み取りが黙って失敗し、ソースが何も返さなかったとき、Tajo は気づきますか？
一部だけです。エラーになった読み取りは実行を失敗させ、その実行は5回連続の失敗による一時停止のカウントに入ります。0件で成功した読み取りは成功として数えられます。Shopify の顧客のようなソースでは、以前にレコードを生み出していた同期が0件の成功を10回続けると、Tajo のチームに警告が届きます。更新時刻で読む Shopify の注文では、このチェックは動きません。