KVストレージによる一時コンテンツ管理 — データベースを立てない選択

はじめに

期間限定のページを作ろうと考えたとき、最初に決めることになるのが「データをどこに置くか」です。本文も画像も有効期限も、どこかに保存しておかないとページは表示できません。ここでデータベースを用意するのが定石ではありますが、一時ページやイベントギャラリーのような補助的な機能に、その重さが本当に必要かは考える余地があります。

この記事では、キーバリューストアだけで一時コンテンツを管理した理由と、実際のデータの持たせ方を解説します。キーバリューストアというのは、名前をひとつ指定すると、その中身がそのまま返ってくるシンプルな保存場所のこと。読み終わるころには、データベースを省略してよい場面と、省略すべきでない場面の線引きがつかめるはずです。

データベースを立てずにKVを選んだ理由

立ち上げまでにやることの量が違う

リレーショナルデータベース（表の形でデータを整理して管理する仕組み）は強力ですが、使い始めるまでにやることが多いんですよね。どんな項目を持つ表にするかを設計し、あとから項目を増やすときの移行手順を管理し、接続の設定やバックアップにも気を配る。売上や在庫のような業務の中核データを扱うなら、この手間はきちんと見合います。

ただ、一時ページのデータは一定期間だけ存在して消えるものです。この性質に対して表の設計から始めると、かけた準備がほとんど回収できません。KVなら、名前を決めて中身を預け、必要になったらその名前で取り出すだけ。準備に使う時間が短いぶん、機能そのものを試す時間に回せます。

一時ページのデータは、そもそも形が単純

保存したいものを並べてみると、驚くほど単純です。URLの一部になる文字列（slug）を指定したら、そのページの本文と画像の場所、そして有効期限が返ってくる。必要なのはそれだけで、複数の表をまたいだ検索も、条件を組み合わせた絞り込みも出てきません。

この「名前ひとつで中身が丸ごと返ってくればいい」という形は、キーバリューストアがいちばん得意とする使い方です。管理画面で一覧を出したいときだけは、作成済みのslugをまとめた索引を別の名前で持たせておけば足ります。データの形が素直だと、道具も素直なもので済むわけです。

動かす場所とそろえると、つなぎ込みが減る

この仕組みはVercel（作ったページを載せておく置き場所）の上で動かしているので、同じVercelが提供するKVをそのまま使いました。設定値をひとつ登録すれば接続でき、ページを生成する処理から直接読み書きできます。別のサービスを契約したり、接続情報を別管理したりする手間がありません。

つなぎ込みの箇所が減ると、動かなくなったときに疑うべき場所も減ります。プラットフォームが用意しているものを素直に使う判断は、機能の派手さには効きませんが、あとから効いてくる部分です。

表が言いたいのは、扱うデータが単純で寿命も短いなら、重い道具を選ぶ理由はそれほどない、ということです。

データの持たせ方で、あとの手間が決まる

名前に接頭辞を付けて、種類ごとに分けておく

KVでは、保存するときに付ける名前がそのまま設計になります。私は一時ページなら「page」で始まる名前、というように、種類ごとの接頭辞を先頭に付けて、そのあとにslugをつなげた名前で保存しています。中身のほうには、本文、画像の場所、有効期限、公開中かどうかをひとまとめにして入れておく形です。

接頭辞を付けておくと、あとから別の種類のコンテンツを足したときに名前がぶつかりません。地味なルールですが、最初に決めておくかどうかで、半年後の見通しがだいぶ変わります。

有効期限は、データ自身に持たせる

有効期限は、中身の一項目としてはっきり持たせています。「2026年3月31日の23時59分59秒まで」に相当する日時を、決まった書き方で書き込んでおくイメージです。

こうしておくと、期限を見張る定期実行の処理も、公開ページが表示してよいか判断するときも、同じ一箇所を見るだけで済みます。「いつ消えるか」をデータ自身が知っている状態、と言い換えてもいいかもしれません。判断のルールがあちこちに散らばらないので、あとから「終了3日前は表示を変えたい」といった要望が出ても、直す場所が一箇所で済みます。

画像は、画像の配信に強い場所へ預ける

本文はKVに入れても軽いのですが、画像そのものをKVに詰め込むのは避けています。イベントギャラリーの写真は、画像の配信と加工に強いCloudinary（画像を預けると、サイズや形式を自動で最適化して配ってくれるサービス）に置き、KVにはその場所を示すURLだけを保存する構成です。

役割を分けておくと、KVに入るデータは軽いままに保たれますし、画像の縮小や形式変換は預けた先に任せられます。ひとつの箱に全部を詰め込まないほうが、結果的にどちらも扱いやすくなる、という話です。

図をまとめると、軽い情報はKVに、重い画像は画像専門の場所に置き、公開ページが表示のたびに両方を取ってきて組み立てる、という配置です。

期限が来たら消すのか、残して非公開にするのか

保存時に寿命を指定して、自動で消えてもらう

KVにはTTL（Time To Live。保存するときに寿命を指定しておくと、その時間が過ぎたら中身が自動で消える機能）があります。期限までの長さを計算して一緒に渡しておくだけで、あとは何もしなくても消えてくれる、という手軽さです。

期限が来たら跡形もなく消えていいデータなら、これがいちばん簡単です。定期実行の処理を待つ必要すらありません。消し忘れが起こりようがない状態を、保存する時点で作れるのが強みですね。

案内を出したいなら、データは残して公開だけ止める

一方で、失効したあとに「このページは公開を終了しました」と案内を出したいこともあります。TTLで中身ごと消してしまうと、その案内すら出せません。SNSで拡散されたURLが、終了後にクリックされる場面を考えると、無視できない差です。

そういうケースでは、TTLに頼らず、有効期限の項目と公開中かどうかの目印で管理します。期限を過ぎたかどうかは日時を比べて判断し、データ自体は残しておく。失効を「削除」ではなく「非公開」として扱えるようにしておくと、終わり方を選べるようになります。

つまり、失効したあとに何かを見せたいかどうかで、選ぶ方式が決まります。

まとめ

一時コンテンツの管理に、必ずしも重量級のデータベースは要りませんでした。データの形が単純で寿命も限られているなら、KVという軽い道具のほうが、立ち上げも日々の運用も楽になります。

押さえるところは3つ。接頭辞付きの名前でデータを整理すること、有効期限をデータ自身に持たせること、そして自動削除と非公開を用途で使い分けること。この3つが、後片付けを自動化するための土台になります。どれも難しい判断ではないので、やりたいことを言葉で整理できていれば、AIエージェントと組み立てを詰めていくのに向いた領域でもあります。

保存したデータを実際に「期限が来たら失効させる」処理は、定期実行が担います。