Cloudflare D1 にトークを保存し続ける LINE Bot を作って試した

「Cloudflare D1 にメッセージを保存し続ける LINE Bot をつくる」という記事を見かけた。 作り方を聞くだけでなく、実際に1個作ってもらい、自分のトークに招待してみることにした。

保存を確かめたあと、Claude Code の報告を読んで引っかかった。 取引先との記録グループには入れないでほしい、と書いてある。 自分は、まさに取引先とのやり取りに入れるつもりで作っていた。

作った Bot の流れ

Bot の中の流れは、次の3段である。

1. LINE のグループで誰かが発言する
2. 「Webhookの利用」がオンなら、LINE がそのメッセージを Webhook で Cloudflare Workers に送る
3. Worker が署名を確かめ、D1 に日時、グループ、テキストを1行ずつ書き込む

作って試した手順

作業は、Cloudflare Workers の定石をまとめたスキルを読み込んだうえで進めた。 D1 のデータベースは Claude Code に作らせた。 詰まったのは、依存パッケージの導入である。 npm install がエラーで止まったので、issue に記録を残させてから pnpm で入れ直させた。 今度は pnpm の「公開直後の版は入れない」設定（minimumReleaseAge）に最新の wrangler が引っかかり、版の指定を緩めさせて通した。

型チェック、テスト8件、D1 のスキーマ適用までは Claude Code が自力で進めた。 止まったのは LINE Developers のログイン画面である。 1Password の自動入力は入っているのにボタンが押せない状態だったので、ログインだけ自分で済ませた。

Messaging API のチャネルは、「LINE公式アカウントを作る → Messaging API を有効にする」の順でしか作れない。 Claude Code は記録用の公式アカウントの作成フォームを進め、宣伝アカウントを友だち追加するチェックを外してから作成を完了させた。 続けて管理画面で次の設定を入れ、リロード後も保持されていることを確かめた。

• グループへの参加：有効
• 応答メッセージ：無効
• あいさつメッセージ：無効

Channel secret は、旧い値が漏れていたので Claude Code に再発行させた。 新しい値は画面に表示させず、そのままファイルへ退避させている。 本番デプロイの確認を求められ、自分は「y」とだけ返した。 デプロイ後、Claude Code は署名が不正なリクエストを弾くかを確かめてから、Webhook URL を登録した。

テストグループで1通送ってみた。 D1 を見ると0件だった。 原因は、送ったのが「Webhookの利用」をオンにする直前だったことである。 オンになるまで、LINE は Worker にメッセージを転送しない。 もう一度送ると、2026-10-14 14:37:11 の日時で、グループとテキスト「これは投稿のテストです」の1行が入った。

コミットでも一度止まった。 Claude Code は、生成された型定義（1.6万行）をコミットから外し、型チェックのたびに生成し直す形に変えた。 あわせて、.dev.vars があってもなくても型チェックが通るように直してから、コミットをやり直した（Codex のレビューに約1分かかる）。

なぜ取引先とのグループに入れないのか

コミットを頼むついでに、あの一文の理由を聞いた。 疑問はほかにもあった。 公式アカウント作成時に同意したデータ利用の規約によって、トークの中身は外に漏れているのか。 有料プランを契約しないと、守秘義務に反することになるのか。

さらに、自分なりの推測もぶつけた。 LINE でやり取りしている時点で規約に同意しているなら、Bot を通そうが通すまいが、内容によっては見られる。 それなら気にしても意味がないのではないか。

返ってきた答えは「半分は合っている」だった。

• 規約の上では、Bot がなくても LINE は内容を扱える立場にあり、差は小さい
• 技術的には差があり、Bot を入れると「規約上は扱えるが、暗号化されていて読めない」状態から、Bot 側で本文を読める状態に変わる

Bot が入っていない人同士のトークでは、テキストは暗号化されていて、LINE のサーバー側でも本文は読めない。 これが LINE の公式説明だという。 無料プランかどうかは関係がない。 料金プランは公式アカウントの話で、一般の利用者同士のトークにはプランがない。

自分は、サーバーの管理者なら普通に読めると思っていた。 意外だった。

成り立つ使い方はどこにあるか

ここから自分で整理した。 取引先から「Bot を入れていいですか」と言われたら、断る理由は特にない。 逆に、こちらから Bot を入れてしまうと、取引先は断りづらい。 同意の取り方として、それはイマイチである。

最初は「MacBook に LINE アプリを入れたくない人が使えばいい」という話から試し始めていた。 そこからたどり着いたのは、次の場面である。 LINE で業務連絡を受ける側の人が、連絡は見逃したくないけれど MacBook に LINE は入れたくない、という理由で、自分から「Bot を入れてもいいですか」と頼む。 これなら成り立つ。 Claude Code に確かめると、その理解で合っているという返事だった。 こちらから提案する使い方ではなく、自分の用途としても合わない、とも言われた。

Claude Code は、導入記録をまとめる途中で、もう一つ足りないものにも気づいた。 今の構成は D1 に溜めるだけで、Mac で読む手段がない。 その用途で実際に使うには、新着をメールや Slack に転送する仕組みか、読むための Web ページが要る。 返信は Bot の名前でしか送れないので、返信まで考えると結局 LINE アプリが必要になる。 用途はさらに絞られた。

導入記録の表示確認と push

この結論は、導入記録に書いてもらった。 Claude Code は導入記録を Markdown と HTML で作り、Chrome で表示を確かめた。 表が画面からはみ出していたが、その場で直った。 原因は pandoc が自動で付ける列幅の指定だろう、という見立てだった。

最後に、導入記録（Markdown と HTML）と、README の Bot 一覧への追記をコミットして push させた（c7783f0）。 Codex のレビューは指摘なしだった。 テスト用のグループは自分のものなので、Bot は入れたままにしてある。

学び

• Bot が入っていない人同士の LINE のトークは、LINE の公式説明ではサーバー側でも本文を読めない。Bot を入れると、そのトークの本文は Bot 側に届いて読める状態になる。それを使ってよいかは、相手の同意の問題として別に残る
• この Bot が成り立つのは、連絡を受ける側が自分から Bot を入れたいと頼む場面くらいである。しかも D1 に溜めるだけでは読めないので、転送か閲覧用ページを足さないと実用にならない