Slack無料プランのバックフィルが、エラーも出さずに空振りしていた

問い合わせ対応チャンネルのログを自動でMarkdown化し、保存する仕組みを作っていたとき、しろまえ殿は妙なことに気づいた。

古い日付のメッセージだけ、何度取得しても件数が0で返ってくる。

エラーは出ていない。

処理は「成功」した顔をしている。

なのに、中身が無い。

90日という壁は、UIだけの話ではなかった

調べていくと、Slackの無料プランには「90日より古いメッセージは取得できない」という制約があることが分かった。

これがUIだけの制限だと思っていたのが、そもそもの見立て違いだった。

API(conversations.historyという履歴取得の呼び出し)にも同じ壁が効いていた。

Pro以上へ課金しない限り、90日より前へは原則遡れない。

そして厄介なのが、境界を越えた要求への応答の仕方だった。

エラーを返してくれれば、まだ気づける。

しかし実際には、空の配列を黙って返すだけだった。

「データが無い」のか「取得に失敗した」のか、見た目では区別がつかない。

たとえば宅配便の再配達依頼で、対応エリア外だと伝えられずに、ただ荷物が届かないだけなら、利用者は自分の依頼が通ったと思い込んでしまう。

それと同じ構造だった。

この挙動を知ってから、しろまえ殿はバックフィル(過去分をまとめて取り込む処理)の設計を変えた。

「空配列は失敗として扱う」という前提を先に置く。

日次の通常バッチとは別系統のスクリプトにして、既にファイルがある分はスキップする冪等な作りにした。

途中で止めても、再開すれば重複なく続きから取れる。

もう一つ、見落としやすい点があった。

Slack標準のエクスポート機能が書き出す画像は、実体ではなくURLの参照だけだった。

ワークスペースから元のメッセージが消えると、そのURLも失効する。

過去ログを後から開いても、画像は表示されない。

画像そのものを残したいなら、ボット専用の認証キー(Slackが発行する専用のアクセス鍵)を使ってAPI経由でファイル本体をダウンロードする設計にする必要があった。

さらに、標準のエクスポート機能はパブリックチャンネルのみが対象で、プライベートチャンネルは別枠の申請が要る。

対象範囲によって、実現できることそのものが変わってくる。

この一件でしろまえ殿が得たのは、Slackの仕様そのものより、確認の順番だった。

0件という結果を見たとき、「対象期間に何も無かった」と決めつける前に、まず取得範囲の制約を疑う。

エラーが出ないからといって、成功したとは限らない。

見た目の「成功」を、そのまま信じない。

それが、地味だが効く教訓だった。

Slack ヘルプセンター「Usage limits for free workspaces」（無料プランのメッセージ・ファイルの90日可視性制限。確認日: 2026-08-27）

https://slack.com/help/articles/115002422943

制度・仕様は変更されることがある。実際に確認する際は、Slackの最新の公式情報を確認してほしい。