ボードレイアウト
ボードは独立した本物のレイアウトモードだが、設定は完全に UI 側で、API 引数はどこにも存在しない
Slack Lists は本物のカンバン風ボードを描画する — 本セクションの他のページで書いてきた運用上の負担を払ってでも Lists を使う価値がある、その理由がこの機能だ。ただしボードは、明確な線の UI 側に完全に閉じ込められている。12 メソッドの API 表面には、ボードの存在を知っているものが 1 つもない。
グループ化されたテーブルではなく、本物のレイアウトモード
Slack のヘルプ記事は、リストのレイアウトをちょうど 2 つ文書化している。テーブルレイアウト（「アイテムを行、フィールドを列として整理する」）とボードレイアウト（「アイテムがフィールドでグループ化され、列間で移動できる」）だ。切り替えは UI 操作（フィルタアイコン → レイアウト → ボード / テーブル）で、「グループ化」コントロールがどの列の値をボードの列にするかを選ぶ。レイアウトは名前を付けて共有できるビューとして保存できる。
「ドラッグ」という言葉の出どころ
Slack 自身のページは「ドラッグ」も「カンバン」も一度も使っていない — 確認したすべてのロケールの表記は「アイテムを列間で移動できる」だけだ。具体的な操作としてのドラッグ＆ドロップは、Slack ではなくサードパーティの実機記事（ClearFeed、2026-05-07）によって確認された。ボードレイアウトと列グループ化の存在は Slack が述べた事実として扱ってよいが、「ドラッグ＆ドロップ」という表現に限ってはサードパーティによる確認であって Slack からの直接の引用ではないものとして扱うこと。ボードができた後に閲覧者に何ができて何ができないかは権限と所有者を参照。
UI 限定: 12 メソッドの表面のどこにも API 引数がない
slackLists.create が取るのは name、description_blocks、schema、copy_from_list_id、include_copied_list_records、todo_mode のみで、引数一覧全体を確認しても view、layout、board、group_by といった引数はない。API でビューが登場する唯一の場所は、読み取り側の slackLists.items.info が返す views[] 配列だが、文書化されたサンプルに出てくる型は record と table だけで、ボード型は含まれていない。ボードをセットアップしたり、記述したり、確認したりする API 経路は、作成時にも更新時にも読み取り時にも存在しない。
ボードは人間が手作業で、毎回 1 回ずつセットアップする。 これは権限と所有者の所有者構成を規定するのと同じ制約だ。bot はリストを作ってアクセスを付与できるが、ボードレイアウトを有効にし、グループ化する列を選び、デフォルトビューとして保存できるのは UI をクリックする人間だけである。
未検証
ボード固有の 2 つの問いは実証検証の対象としてフラグが立てられていたが、実ワークスペースで決着をつけられたはずのこのプロジェクトのスパイクがスキップされたため、未検証ステータスのままだ。
ボードレイアウトがグループ化に使える列型。 Slack のドキュメントに登場する実例はいずれも単一選択のステータス列を使っており、select が対応済みの（あるいは唯一まともに動く）グループ化可能な型であることを示唆している — しかし「グループ化」コントロールが実際にどの列型を受け付けるかを列挙したページはない。設計を確定させる前に、選んだ列型でボードが正しく描画されることを確認すること。ユーザー型や日付型など他の列型がグループ化軸として機能すると仮定しないこと。
items.infoのviews[]がボード型のビューを報告し得るのか。 文書化された唯一の例にはrecordとtableしか出てこない。これは文書化された例からボードビューが省かれている証拠ではあっても、このフィールドが決してボードを含み得ないという証明ではない — 「views[]にボード型がない」は報告内容であって網羅的に確認された事実ではないものとして扱うこと。
どちらの問いもワンウェイミラーパターンのパターンを妨げるものではない — そこにある一度きりの手作業によるボードセットアップについて、確定させる前に実機で確認が要るというだけだ。
保存済みビュー
リストにアクセスできる人なら誰でも — 読み取り専用の閲覧者も含めて — 誰かがすでに保存したビューの間を切り替えられる。この切り替えは閲覧者ごとのもので、破壊的ではない。新しいビューの保存には編集アクセスが必要で、読み取り専用の閲覧者によるレイアウトやフィルタの調整は一時的なもの、ページを離れた瞬間に消える。デフォルトビュー（全員が最初に開いたときに見るもの）の設定はさらに狭く、所有者のみ、しかも UI でしか設定できず API 経路はない — この具体的な主張に含まれる未検証のニュアンスと、それがリストの所有者を誰にすべきかにどう影響するかは権限と所有者を参照。
作り直すとビューはすべて失われる
スキーマは slackLists.create の後は実質的に凍結される — 列を追加・削除・型変更する API は 1 つも文書化されておらず、API レベルで認められた回避策は copy_from_list_id + include_copied_list_records で新しいリストを作ることだ（copy_from_list_id と schema を同じ呼び出しで渡すことはできない）。これは新しい list_id と新しい column_id を生み、あらゆる場所で永続化し直す必要が出る。
copy_from_list_id だけでは、足りなかった選択肢が追加されるわけではない — コピー元リストのスキーマを、選択肢もろともそのまま再現する。ここから実際にスキーマを変更するには 2 段階が要る。まずコピーして凍結されていない新しい list_id を得て、次に人間がその新しいリストの列の選択肢を Slack UI で手作業で編集する（select の選択肢の追加・改名・色変更は UI 限定の操作で、API では決してできない）。コピーの段階が「古い list_id が凍結されている」を解決し、手作業の段階が「別の選択肢セットが必要」を解決する。2 段階目を飛ばすと、同じ選択肢が欠けたままの 2 つ目のリストが残るだけだ。
これは Slack が直接文書化した事実ではなく分析だが: ビュー（ボードレイアウトとそのグループ化設定を含む）はリストごとに完全に UI から設定されるもので、コピー / 作成の API 表面には、それらを新しいリストへ引き継ぐという記述がどこにもない。新しいリストは独自の list_id を持つ本当に別のオブジェクトであり、そもそもビューの設定には API 表現が存在しないのだから、新しいリストが古いリストのボードレイアウト、グループ化列、デフォルトビューを自動的に受け継ぐ仕組みは存在しない。リストの作り直しを伴うスキーマ変更では、コード内の list_id / column_id 参照を張り替えるだけでなく、手作業のボードセットアップ（ボードレイアウト、グループ化、デフォルトビュー）をやり直す分の予算も見込んでおくこと。
これこそが、「スキーマを変える必要がある」を気軽に手を出すものではなく、高くつくほぼ手作業のイベントとして扱うべき最大の理由だ。migrations/*.sql 的な追加変更ではなく、ボードらしく見えるようになるまで人間が手で再設定しなければならない新しいオブジェクトなのである。
関連ページ
権限と所有者 — ビューを保存・設定できるのは誰か、そしてボードレイアウトをクリックして作り出せる人が誰かを決める所有者構成。
ワンウェイミラーパターン — 一度きりの手作業によるボード設定ステップを含む、完全なセットアップチェックリスト。