ダッシュボードサーフェスの選び方
Slack の bot が読み取り中心のデータを公開できる 5 つの場所を順位付けして比較し、選択のルールを示す。
シナリオ: bot が — 例えば Cloudflare Worker の cron ジョブが — 定期的にステータスボードを Slack へ公開する。チームは普段働いている場所でそれを見られるべきだが、bot の足元でそれを編集できてはならない。そのデータを載せられるサーフェスは 5 つある。ここではその特定の目的 — 文書でもフォームでもなく、ダッシュボード — に向けて 5 つを順位付けする。
一覧での順位
| # | サーフェス | bot から書けるか | 読み取り専用の強制 | 更新コスト | 表現力の上限 |
|---|---|---|---|---|---|
| 1 | ピン留めした chat.update メッセージ | Yes | 絶対的 | API 呼び出し 1 回 | Table block、最大 100 行 |
| 2 | Slack Lists | Yes（GA の 12 メソッド） | 設定可能、ただし穴あり | 行ごとの create/update と自前の行 ID 管理 | 本物のカンバンボード |
| 3 | 外部ダッシュボードへのチャンネルブックマーク | Yes（bookmarks.add） | 自分のアプリが決める | ゼロ | 無制限 — 自分の UI だから |
| 4 | キャンバス | Yes | 設定可能 | 1 回、ただし文書全体の置き換え | Markdown 文書、表のみ |
| 5 | App Home タブ | Yes（views.publish） | Yes | 更新ごとに O(users) 回の呼び出し | フル Block Kit、ユーザーごと |
1. ピン留めした chat.update の Block Kit メッセージ — まずこれを作る
bot から書けるか: Yes。chat.postMessage を 1 回呼んで結果をピン留めし、以降は更新のたびに chat.update を呼ぶ。
読み取り専用の強制: 絶対的で、設定は一切要らない。メッセージを投稿したアプリだけがそれを編集できる — 設定すべき ACL も、間違えうる共有ダイアログも、メッセージ本文への書き込み権を他人に渡す管理者オーバーライドも存在しない。ここに挙げた中で、読み取り専用という性質を設定ミスで壊しようがない唯一のサーフェスだ（reference/
更新コスト: 更新 1 回につき API 呼び出しちょうど 1 回。メッセージのブロックをその場で編集してもチャンネル通知は発生せず（ダッシュボードとしては正しい挙動）、「編集済み」フラグも付かない。
表現力の上限: 評判よりずっと高い。Block Kit の Table block は最大 100 行 × 20 列、合計 10,000 文字まで描画でき（reference/
厳格な上限: 上記の Table block の上限、Block Kit のメッセージあたりのブロック数上限全般、そしてチャンネルメンバーなら誰でもメッセージのピン留めを外せること（ピン留めを外しても削除はされない）。
評価: デフォルトの選択肢。 API 呼び出し 1 回、永続化すべき状態なし、上限ポリシーなし、手作業のセットアップなし、そしてこのリストで最も強い読み取り専用の保証。Slack List で本物のボードとアイテムごとのスレッドを得るには、およそ 10 倍のコードと運用面が必要になる。まずこれを出すこと。実物を見たチームが列を求めてきたときに初めて移行を検討すればいい。
2. Slack Lists — 唯一の本物のボード、そして最も長い請求書
bot から書けるか: Yes。slackLists.* の 12 メソッドはすべて bot トークン（xoxb）互換で、lists:read + lists:write スコープが要る。動かす前に前提が 3 つある。有料プラン（Enterprise 限定ではなく、任意の有料ティア）、その 2 つのスコープ（追加すると OAuth の再インストールが強制される）、そしてリストごとのアクセス — スコープだけでは、リストが bot またはそのチャンネルへ共有されるまで list_not_found のままだ。
読み取り専用の強制: 自動ではないが、本当に設定可能でサーバー側で強制される。slackLists.access.set は read、write、owner のいずれかの access_level を必須で取り、読み取り専用はエスカレーションについて閉じている — 閲覧者は閲覧アクセスを再共有できるが、編集権は決して付与できない。既知の穴: 閲覧者はアイテムのスレッドにコメントできる、所有者や管理者は自分が閲覧できるリストを削除できる、そして UI の共有ダイアログはデフォルトが「Can edit」（手作業で共有する人間は変更を忘れないようにする必要がある — API はパラメータが必須なのでこれに陥りようがない）。
更新コスト: このリストで最も高い。どのメソッドにも upsert も冪等性キーもない — 同一の items.create を 2 回呼べば 2 行できる — ので、返ってきた行 ID を呼び出し側が永続化し、create と update を自分で分岐しなければならない。items.list には limit / cursor / archived 以外のフィルタも検索もないため、失った ID マッピングの復旧はリスト全体をページングすることを意味する。
表現力の上限: ここで実際のボードを描画する唯一のサーフェス。ボードレイアウトはアイテムをフィールドでグループ化し、保存済みビューとアイテムごとのスレッドに対応し、閲覧専用ユーザーには見るだけで触れないボードを提供する — フィルタして読むことはできるが、カードのドラッグもビューの保存もできない。
厳格な上限: Pro / Business+ ではリストあたりアイテム + サブタスクで 1,000（Enterprise Grid では 5,000）。スキーマは作成後に実質凍結される（API での列の追加・削除・型変更は不可、列は 30 まで）。slackLists.info もリストの列挙も存在しないため、リスト ID とすべての列 ID は作成時に永続化しないと失われる。ボードレイアウトとビューは UI 限定でデフォルトビューは所有者のみが設定できるため、bot が作ったリストであっても、ボードをクリックして作り出す書き込み権を持つ人間が必要になる。
未検証: 行数上限に達したときの自動アーカイブ
アイテム上限に達したときに最も古い行が自動アーカイブされるのか、それとも単に over_row_maximum で新規 create が失敗するだけなのかは、先行調査が報告している内容にとどまり、Slack 自身のドキュメントでも実 API でも確認されていない — このプロジェクトの検証スパイクはスキップされた（テストトークンが用意できなかった）。実証的に確認されるまでは over_row_maximum を唯一の権威あるシグナルとして扱い、上限で静かに退避が起こることを前提としたミラーを設計しないこと。
評価: チームがボードを強く求める場合にだけ採用する。 本物の列を持つ唯一のサーフェスであり、読み取り専用のリストであれば Lists の通常のネックである「変更イベントがない」問題も回避できる（bot が唯一の書き手なので）。しかしその代償として、恒久的な行 ID の管理、まだ完全には検証できない上限退避ポリシー、進化させられないスキーマ、bot には実行できない手作業のビュー設定、そして人間の共同所有者が必要になる。書き込み経路の全体、スキーマのルール、全メソッドについてはリストを参照。
3. 外部ダッシュボードへのチャンネルブックマーク — 何もしないという選択肢
bot から書けるか: Yes — bookmarks:write スコープ付きの bookmarks.add で、チャンネルのブックマークバーにリンクを固定できる。
読み取り専用の強制: Slack 側は単なるリンクにすぎず、それ以外はすべて自分のダッシュボードの認証モデルが決める。
更新コスト: ゼロ。ダッシュボードがライブデータを描画するので、同期するものが何もない。
表現力の上限: 無制限。自分の UI なので、Slack がネイティブに描けるどんなものよりも常に上回る。
厳格な上限: Slack の中にはないこと — クリックして飛ぶ動作が 1 回、加えてダッシュボード側のログインの手間がかかる。チャンネルからひと目で分かるものは何もない。
評価: 他に何を作るとしても、これはやっておく。 コストゼロ、完全な忠実度、常に最新。唯一の弱点であるチャンネル内でひと目で分からない点は、選択肢 1 が API 呼び出し 1 回で補ってくれる。
4. キャンバス — ダッシュボードではなく文書
bot から書けるか: Yes — 作成は canvases.create、後からの更新は canvases.edit。
読み取り専用の強制: canvases.access.set に access_level: "read" を渡して設定でき、1 点において Lists より厳格だ — キャンバスの閲覧者はコメントすら一切できない。セットアップは順序に依存する。アクセスを付与する前に、キャンバスをチャンネル（またはユーザー）へ共有しておく必要がある。
更新コスト: canvases.edit は API 呼び出しあたり 1 操作しか対応していないため、bot が再生成する文書にとって現実的に回る更新パターンは文書全体の replace だけになる — 呼び出しは 1 回だが、毎回文書全体を組み立て直して送ることになる。
表現力の上限: Markdown 風の文書 — 見出し、表、チェックリスト。ボードも列もウィジェットレイアウトもない。
厳格な上限: 呼び出しあたり 1 操作、コンテンツ 1 MiB の上限、そして文書型のレンダリングのみ。書き込み経路の全体と、現行の Slack ドキュメントに対して再確認したすべての上限はキャンバスを参照。
評価: ダッシュボード用途では見送る。 ピン留めメッセージに対する唯一の構造的な強み — チャンネルキャンバスはチャンネルから流れ去らない恒久的なタブであること — が、その代償（更新通知なし、更新のたびに文書全体を再送、数値やボードのレイアウトを持たないレンダラ）を上回ることはめったにない。キャンバスは散文向けに使うこと — runbook、議事録、プロジェクト計画 — ステータスボードには使わない。
5. App Home — 読み取り専用、しかし誰にも共有できない
bot から書けるか: Yes — views.publish。
読み取り専用の強制: Yes、しかもきれいに — ユーザーはアプリの Home タブを一切編集できない。ピン留めメッセージに次いで、このリストで最もすっきりした読み取り専用の構造だ。
更新コスト: O(users)。App Home は単一のユーザーとアプリが共有する 1 対 1 の空間なので、更新のたびにユーザー 1 人につき views.publish を 1 回呼ぶ必要があり、しかも bot はその対象ユーザーが誰かを追跡しなければならない。
表現力の上限: メッセージと同じくフル Block Kit — ただし描画はユーザーごとにプライベートに行われる。
厳格な上限: 共有可能なリンクがない。「ここを見て」と投稿して 1 つの URL にチームを向かわせる方法がなく、各自がアプリの Home タブへ自分でたどり着く必要がある。
評価: チーム共有のダッシュボードとしては最も不向き。 ユーザーごとのプライバシーは、パーソナライズされたビューにとっては機能だが、「チャンネル全員が同じボードを見る」用途にとっては逆機能だ。閲覧者ごとに本当に違うデータを見せる必要があるときにだけ手を伸ばすこと。
選択のルール
Slack の中で数字が見えてほしいのか、それともチームがボードとして作業する必要があるのか。数字なら、ピン留めした chat.update メッセージ（#1）に、必要なら充実した外部ダッシュボードへのブックマーク（#3）を添えて、そこで止める。チームが本当にパイプラインをボードとして回すなら — ステージ A から C まであり、カードは手で動かされ、チャンネル全体が同じボードを眺めるなら — Slack Lists（#2）を、bot 以外は全員読み取り専用にし、行数上限に収まる有界な作業セットにして、書き込み権を持つ人間を 1 人だけ指名して使う。ここで検討したどの読み取り専用ダッシュボードのシナリオでも、キャンバスと App Home はこの 3 つに劣る。