ハコヅミを作る #39：ベータ版の前に足りないものを洗い出す（サーバーのログ、お知らせ）
前回（#38）で、ベータ版の前に要るもの、と考えていたものは、すべて本番に出ました。
あとは、Cloudflare Access を外すだけ。……のはずでしたが、その前に、1つ聞いてみました。
他に、ベータ版のリリース前に対応しておいたほうがいいことってある？
返ってきた答え
Claude Code は、リポジトリを確かめたうえで、大事な順に挙げてくれました。
| 挙がったもの | 今の状態 |
|---|---|
| サーバーのログ | 残す設定が、入っていない |
| エラーの画面 | SvelteKit の素の表示（番号と、英語の一言）が出る |
| データを戻す手順 | 一度も試したことがない |
どれも、言われてみれば、そのとおりです。
特に、ログは盲点でした。テスタから「保存できませんでした」と言われても、今のままでは、何が起きたかを見る手段がありません。自分1人で使っているうちは、手元で同じことを試せば済みました。人が使い始めると、そうはいきません。
「今はやらなくてよいもの」も、理由と一緒に挙がりました。アクセスの解析（プライバシーポリシーで「使わない」と書いた）、オフライン対応（大きいので、声が出てから）、などです。
今回は、ログと、同じ流れで思いついた「お知らせ」の話です。
ログを残す
Cloudflare Workers には、ログを残す仕組みがあります。設定のファイルに、数行足すだけです。
"observability": { "enabled": true, "head_sampling_rate": 1, "redact_query_string": true }
無料の範囲では、1日 20 万件まで、3 日のあいだ残ります。10 人のテスタなら、十分です。
redact_query_string は、URL の「?」から後ろを残さない設定です。Google のログインから戻ってくるときの URL には、ログインのコードが入ります。それを残さないために、入れました。
設定を入れるだけでは、危なかった
ここまでなら、数分の作業です。ところが、Claude Code は、設定を入れる前に、アプリがログに何を書き出すかを調べました。
SvelteKit は、サーバーで思わぬ失敗が起きると、エラーをそのままログに出します。ふだんは、それで困りません。問題は、データベースの問い合わせで失敗したときです。そのときのエラーの文は、こういう形をしています。
Failed query: insert into "gears" ("product_name") values (?)
params: ひみつのテント
params: の後ろに、送られてきた値が入っています。ギアの名前、メモ、キャンプ場。利用者が登録した内容です。
ログを残す設定がなかった今までは、このエラーは、どこにも残りませんでした。設定を入れたとたんに、登録した内容が、ログに残るようになります。プライバシーポリシーには、「登録した内容は、管理のための画面には出ません」と書いたばかりです。
そこで、エラーをログに出す前に、params: から後ろを取り除くようにしました。残すのは、エラーの名前、文（値を除く）、場所だけです。
確かめ方も、工夫がありました。わざと失敗する一時的なページを作り、「ひみつのテント」という値を仕込んで、ログと画面に出ないことを見ています。ページは、確かめたあとに消しました。
実際のログを見る
開発環境に出して、ダッシュボードでログを見ました。クッキーは、こう残っていました。
"cookie": "REDACTED"
Cloudflare の側で、自動で伏せてくれます。URL も、/plans/REDACTED/edit のように、id のところまで伏せられていました。こちらで頼んだ以上に、守られています。
その代わり、「どのプランで起きたか」は、ログからは分かりません。分かるのは、「プランの編集の画面で起きた」まで。不具合を調べるときは、テスタに「どの画面で、何をしたときか」を聞くことになります。それでよい、と考えました。
お知らせを出す場所
ログの話をしているうちに、もう1つ、足りないものに気づきました。
テスタが意見を送ってくれて、こちらが直す。直したことを、伝える場所がありません。意見を送っても、何も変わらないように見えたら、次の意見は出てこないでしょう。
もう1つ、理由がありました。#36の利用規約に、こう書いています。
変えるときは、変わる内容と、いつから変わるかを、本サービスの中で前もってお知らせします。
「本サービスの中」に当たる場所が、まだありませんでした。約束しておいて、守る手段がない状態です。
データベースには、持たない
お知らせを、どこに持つか。Claude Code に相談すると、3つの案を比べてくれました。
| 案 | 向き・不向き |
|---|---|
| コードの中のファイル | 履歴が Git に残る。テーブルも、投稿の画面も、増えない。出すには、デプロイが要る |
| データベースと、管理画面 | すぐ出せる。ただし、投稿の画面・下書き・入力の確かめなど、作るものが多い |
| ブログの記事へのリンク | ブログは作る側の記録なので、使う人向けの文にならない |
1つ目にしました。お知らせの大半は、リリースと一緒に出ます。デプロイが要ることは、困りません。利用規約も、同じやり方（文をコードに書き、変えるときはプルリクエスト）にしています。
お知らせ1件は、こう書きます。
{
id: 'beta-start',
date: '2026-10-05',
kind: 'feature',
title: 'ベータ版を始めました',
body: ['ハコヅミのベータ版を始めました。……']
}
種類は4つ（新機能、改善、不具合の修正、大事なお知らせ）。大事なお知らせは、日付にかかわらず、いちばん上に固定します。日付から 7 日のあいだは、「新着」の印が付きます。
人ごとの「読んだ」の記録は、持ちません。持つと、テーブルが1つ増えます。前回の「はじめに」のカードと同じ考え方です。
画面イメージと、フッターの判断
トップページの、メニューの下に、新しいお知らせを出します。画面イメージは、見本のお知らせを入れて撮りました。
トップページのお知らせの画面イメージ（中身は見本）。左が案A、右が案B
選んだのは、左の案A です。ギアやキャンプの一覧と同じ、タブの見出しなので、画面どうしがそろいます。
この画像には、もう1つ、見るところがあります。フッターです。「お知らせ」のリンクを足して4つにしたら、スマホの幅では、2行になりました。「お問い合わせ」だけが、2行目にこぼれています。
フッターには、置かないことにしました。お知らせへは、トップページから行けます。画面イメージを撮っていなければ、2行になることには、出してから気づいたはずです。
お知らせの一覧のページ（中身は見本）。大事なお知らせは、いちばん上に固定される
リリースの手順に入れる
仕組みを作っても、書くのを忘れたら、意味がありません。CLAUDE.md に、1行足しました。
本番リリースの PR を作るときに、お知らせを足すかを確かめる
これで、リリースのたびに、Claude Code が「お知らせは要りますか」と聞いてくれます。文の下書きも、一緒に出てきます。
おわりに
- 「ほかに、やっておくことは？」と聞いてみる。自分の見えていないところが、挙がる
- ログを残す前に、何が書き出されるかを調べる。使っている仕組みが、利用者のデータを出していることがある
- 守りを確かめるときは、わざと値を仕込んで、出ないことを見る
- 約束したこと（「お知らせします」）には、守る手段を用意する
- 人が書いて、たまに出すものは、コードの中に持てば足りる
- 続けるための仕組みは、手順に入れる
次回は、エラーの画面と、小さな直しです。