Cloudflare Workerで静的記事にAPI機能を追加する考え方

記事本文、CSS、JavaScript、画像はStatic Assetsとして配信し、コメント投稿・返信・評価・保存など状態が変わる処理だけをWorkerの /api/ へ渡します。記事表示まで毎回データベースへ問い合わせないことで、公開記事を安定して表示しながら必要な参加機能だけ追加できます。

タイトル、本文、分類、出典、サムネイルは更新時に静的出力します。コメント一覧取得、投稿、返信、評価、保存は利用者の操作に応じて変わるためAPIにします。URLパス、HTTPメソッド、入力、出力、保存先、キャッシュ可否を機能ごとに決めます。

記事URLにはslugを使い、保存データの関連にはAirtableのrecord_idをarticle_record_idとして使います。コメント自身はcomment-id、返信元はparent_comment\_idで持ちます。APIは旧フィールド名との互換を保ちながら同じ値を返し、将来Supabaseへ移しても記事と返信関係が変わらない形にします。

POSTレスポンスをキャッシュする、slugだけでコメントを関連付ける、認証トークンを公開JavaScriptへ書く、CORSと入力サイズを無制限にする、保存成功前に画面だけ更新する、といった実装は不整合を生みます。読み取りと更新を分け、失敗時に元の表示へ戻せるUIにします。

1. 静的記事と /api/ のルートを分ける。2. article_record_id、comment-id、parent_comment_idを定義する。3. GET一覧を実装し空・失敗・遅延を確認する。4. POST投稿へ入力検証、長さ制限、認証・レート制御を入れる。5. 返信をparent_comment_idで追加する。6. 必要なGETだけキャッシュし、更新後の再取得方針を決める。7. 秘密情報をBindingsへ置く。8. ローカル、プレビュー、公開環境で投稿・返信・件数同期を確認する。

現在はAirtableのCommentsを正としても、APIの入出力をarticle_record_id、comment-id、parent_comment_idへ揃えておけば保存先を交換しやすくなります。画面側は保存先を直接意識せず、同じJSON形を受け取ります。コメント件数は公開済み状態の親・返信を含む集計規則を一つに固定します。

静的アセットは配信基盤のキャッシュを使い、コメントGETなど短時間の再利用が安全な応答だけCache APIの対象候補にします。POST、PUT、DELETEはキャッシュせず、更新成功後は再取得または対象キーの無効化を行います。Airtableトークン、保存先、Static Assets、KVやD1などは環境Bindingsで渡します。

記事表示、コメント空状態、一覧取得、投稿、返信、入力エラー、API失敗時の表示、再読込後の保持、コメント件数、slug変更後の関連を確認します。PC・モバイル、ライト・ダーク・システムでも投稿ボタン、返信フォーム、エラー文言が崩れないか見ます。

処理

経路

キー

キャッシュ

記事HTML/CSS/JS

Static Assets

slug

配信基盤

コメント一覧

GET /api/comments

article_record_id

短時間のみ候補

コメント投稿

POST /api/comments

comment-id

しない

返信投稿

POST /api/comments

parent_comment_id

しない

評価・保存

POST /api/...

user-id＋target-key

しない

記事本文もWorkerで毎回取得しますか？

通常は検証済みの静的記事を配信し、更新が必要な操作だけAPIにします。

slugを変更したらコメントはどうなりますか？

article_record_idで関連付ければ維持できます。旧記事URLは新slugへ301転送します。

GETはすべてキャッシュしてよいですか？

いいえ。個人状態や更新頻度、権限を確認し、共有して安全な短時間の読み取りだけ候補にします。

Static Assetsで記事を配信し、コメント・返信・評価など更新処理だけを /api/ へ分けます。article_record_idとparent_comment_idを安定キーにし、GETと更新のキャッシュ方針、Bindings、失敗時UIを揃えることで、保存先を変えても既存表示と操作を維持しやすくなります。

• Cloudflare公式：Bindings

  WorkerはBindingsを通じてKV、D1、R2、Static Assetsやシークレットなどのリソースへアクセスできる。

  公式情報 / 2026-07-14
• Cloudflare公式：Cache API

  WorkerからCache APIを使ってレスポンスを読み書きできる。キャッシュ対象と更新系APIは分けて設計する必要がある。

  公式情報 / 2026-07-14
• Cloudflare公式：Routes

  Routeパターンにより、既存ドメイン上の特定URLをWorkerへ割り当てられる。

  公式情報 / 2026-07-14
• Cloudflare公式：Static Assets

  HTML・CSS・画像などの静的アセットをWorkerと一緒に配信し、既定では静的アセットを優先して解決できる。

  公式情報 / 2026-07-14