ワンウェイミラーパターン

Worker の cron を Slack List の唯一の書き手にし、すべての人間を読み取り専用アクセスにする

本セクションのすべてのページは、1 つの設計へ向かって積み上がっている。Cloudflare Worker の cron が外部データベースの行を Slack List へミラーし、bot トークンが唯一の書き手であり、リストを見られる人間は全員が読み取り専用アクセスを持つ、という設計だ。このページはそれを組み上げたもの — セットアップの仕組み、レート計算、そして「読み取り専用」が実際に何を保証し、何を保証しないのかを扱う。

外部データベース（またはソーステーブル）は、このパターンの生涯を通じて system of record であり続ける。リストはその上へ押し出されたビューであって、逆ではない — リストが成長し続ける全履歴を安全に保持できないからこそ、アイテム上限と自動アーカイブのすべてが存在する。

仕組みのチェックリスト

1. bot 自身がリストを作る

人間がリストを作ってから bot に共有するのではなく、bot に slackLists.create を呼ばせる。これで 2 つの問題が同時に解決する。

• 選択肢のスラッグを自分で決められる。 表示ラベルは何であれ、中立的な ASCII の値（例: todo / doing / done）にできる — 人間が割り当てた不透明な Opt… 形式のスラッグを追いかける、値とラベルの不一致問題がまるごと消える。

• 作成者にはアクセスが暗黙に付く。 bot が自分で作ったのではないリストに書き込みアクセスを得る方法は、本当に文書化されていない — slackLists.access.set が受け付けるのは user_ids か channel_ids だけで、シグネチャのどこにも app_ids や bot 用の引数はない。作成者は自分が作ったものにアクセスできる。未解決の疑問が付いていないアクセス経路はこれだけだ。

2. チャンネルに読み取りアクセスを付与する

slackLists.access.set を 1 回、access_level: "read"、channel_ids はプライベートチャンネルを指す — なぜパブリックではなくプライベートなのか、そして直後に有効にすべき「Only you can share」設定については権限と所有者を参照。

3. list_id、すべての column_id、すべての row_id を永続化する

ここに挙げるものはどれも、追加の呼び出しなしには再発見できない — マッピングを失った場合にそれを復旧する items.info のセンチネル行パターンについてはリストの読み取りを参照。

• list_id と書き込む各 column_id — slackLists.create のレスポンスから。

• ミラーするソース行ごとの row_id — slackLists.items.create から取得し、イベントなし、冪等性なしのとおり create 呼び出しとアトミックに自分のデータベースへ永続化する。

4. cron ティック: 保存済みの行 ID で upsert する

同期する各ソース行は、すでに row_id を保持しているかどうかで分岐する — なければ items.create、あれば items.update。これはイベントなし、冪等性なしで詳述している中核の冪等性メカニズムで、このパターンページはそれを前提に、その周囲を包むものへ話を進める。

5. description_blocks による鮮度スタンプ

同期が成功するたびに最後に slackLists.update を 1 回呼び、リストの説明を Synced from <source> · 2026-08-06 14:32 · 187 rows のような文字列へ書き換える。これは Tier 2 の呼び出し 1 回で済み、行には一切触れず、上限への影響もゼロだ — 行ごとの「最終同期」列よりはるかに安い鮮度シグナルになる。行ごとの列にすると同期あたり N 回の書き込みが必要になり、updated_by を見ている人からはすべての行が変更されたように見えてしまう。

// NOTE: the argument is `id`, not `list_id` — the one method in the
// 12-method surface that names this argument differently from every
// items.* method, which all use `list_id`.
export async function stampFreshness(
  botToken: string,
  listId: string,
  sourceName: string,
  rowCount: number,
): Promise<void> {
  const timestamp = new Date().toISOString();
  const res = await fetch("https://slack.com/api/slackLists.update", {
    method: "POST",
    headers: {
      authorization: `Bearer ${botToken}`,
      "content-type": "application/json; charset=utf-8",
    },
    body: JSON.stringify({
      id: listId,
      description_blocks: [
        {
          type: "rich_text",
          elements: [
            {
              type: "rich_text_section",
              elements: [
                { type: "text", text: `Synced from ${sourceName} · ${timestamp} · ${rowCount} rows` },
              ],
            },
          ],
        },
      ],
    }),
  });
  // Slack's Web API returns HTTP 200 even on failure — {"ok": false, "error": "..."}.
  // This call is meant to run after every successful sync tick, so a swallowed
  // rejection here would leave a stale stamp while the tick still reports success.
  const body = (await res.json()) as { ok: boolean; error?: string };
  if (!body.ok) {
    throw new Error(`slackLists.update rejected: ${body.error}`);
  }
}

6. 定期的な照合、アーカイブパスも含めて

低頻度の全件パス — items.list をページングし、自分のデータベースと差分を取り、その後同じパスを archived: true でもう一度実行する。詳しい仕組みと、2 回目のパスが自動アーカイブの除去を見る唯一の方法である理由はイベントなし、冪等性なしを参照。

7. 明示的な削除による自己制限

Slack が報告している（そして未検証の）自動アーカイブ挙動に頼るのではなく、リストごとの実際の上限のはるか手前で items.deleteMultiple を使って自分の古い行を退避する。ポリシーの全体像とコピーして使える退避ヘルパーはアイテム上限と自動アーカイブを参照。

唯一の手作業ステップ: ボードのセットアップ

ボードレイアウト、グループ化列、デフォルトビューは UI 限定かつ所有者が設定するものだ — ボードレイアウトを参照。これは権限と所有者の所有者構成（bot が人間を所有者に昇格させるか、人間がリストを作成・設定して bot に書き込みアクセスを与えるか）に沿って、人間が一度だけ手作業で行う。cron ティックの一部ではなく、一度きりのセットアップコストである。

ミラーのレート計算

アクティブ 300 行で自己制限したミラーを想定する（1,000 行の天井から十分手前に留まる理由はアイテム上限と自動アーカイブを参照）。

読み取り専用が与えてくれないもの

read アクセスの付与は実在するサーバー強制の制限だ — しかしそれは沈黙の保証ではないし、絶対でもない。

• 閲覧者はアイテムのスレッドでコメントを読むことも投稿することもできる。 「読み取り専用」のボードでも議論は起こり得る。直接編集ができないだけだ。

• 所有者と管理者はいつでもリスト全体を削除できる。 他の誰がどのアクセスレベルを持っていようと関係ない。管理者のオーバーライドを防ぐ ACL 設定は存在しない。

• 公開された Form ワークフローはアクセスレベルを完全に迂回する — ミラーされたリストには一切公開しないこと。

5 つの穴の全リストと、このパターンが依存する所有者構成は権限と所有者を参照。

セットアップチェックリスト

1. ワークスペースが有料プラン（Pro 以上）であり、管理者によって Lists が無効化されていないことを確認する。

2. アプリに lists:read と lists:write スコープを追加して再インストールする（スコープの追加は再インストールを強制する）。

3. 所有者構成を選ぶ（権限と所有者を参照）。どちらを選んでも書き込み権を持つ人間はちょうど 1 人になる — その人の名前を runbook に記録すること。

4. access_level: "read" で、リストをプライベートチャンネルへ共有する。

5. 「Only you can share」（共有 → 詳細設定）を有効にし、読み取りアクセスが付与先を越えて広がらないようにする。

6. リスト上に Form ワークフローを一切公開せず、フィールド変更通知はテストが済むまでオフのままにする — （人間の編集ではなく）API 由来の書き込みが「フィールド変更時に通知」する自動化を発火させるかは文書化されておらず、もしそうだとしたら、毎ティックでセルを書き換える cron がチャンネルを通知で埋め尽くしかねない。

7. 管理者がいつでもボードを削除できること、そして閲覧者がアイテムのスレッドにコメントできることを、最初から受け入れておく — どちらもセットアップの不備ではなく、Lists の仕様である。

関連ページ

• リストの読み取り

• イベントなし、冪等性なし

• アイテム上限と自動アーカイブ

• 権限と所有者

• ボードレイアウト