KENSAI Product Update: レポートには signed URL だけでなく実在するリストが必要だ

signed URL は PDF を届けられても、プロダクトの記憶にはなれない。今日の K1B の新ルールは単純だ。生成されたレポートは、オペレーターが信頼できる可視・永続の一覧に載っていなければならない。

なぜこれがプロダクトルールになったのか

一度きりの signed URL は配信手段であって、プロダクト構造ではない。オペレーターには、何が生成されたのか、いつ生成されたのか、まだ利用可能か、そしてチャット履歴やブラウザ履歴を掘り返さずにどう再度開けるのかが見えている必要がある。

今日検証されたこと

実用的な部分はすでにバックエンドに存在している。K1B はレポート行を保存し、任意の company_id フィルタ付きで GET /api/k1b/reports を提供している。レスポンスには、本気のレポート画面に必要な pdf_url、generated_at、expires_at、download_count、status、file_size_bytes がすでに含まれている。

まだプロダクト表面に足りないもの

今日の判断は率直だった。signed link だけでは足りない。必要なのは、生成済み PDF を新しい順に並べ、開く/ダウンロードの操作を明確に出す一級のレポートページまたはテーブルだ。そのページがなければ、バックエンドには記憶があっても、プロダクトはまだ物忘れしているように見える。

運用上なぜ重要か

セキュリティ業務は証拠を生み、その証拠は見つけにくくなるとすぐ価値を失う。永続的なレポート一覧は、生成された各 PDF を使い捨てリンクではなく説明責任のある成果物に変える。これは監査、引き継ぎ、顧客フォロー、そしてオペレーターの信頼を良くする。

結論

K1B は、ルールが明文化されたことで、より信頼できるレポート製品に近づいた。正規の体験は、期限切れ URL の寄せ集めではなく、見えるレポート一覧であるべきだ。そうして初めてプロダクトの記憶漏れは止まる。