Airtableと静的サイトでブログ運営を始める手順｜公開前に決めること

運用を始める前に、どこを編集すれば何が変わるかを一つに決めます。記事本文・分類・出典・公開状態はAirtable、テンプレート・CSS・JSは静的ファイル、コメントや評価など更新が必要な機能だけWorker APIへ分けます。この境界を決めると、旧CMSの上書きや二重管理を避けられます。

Airtableと公開サイトの両方を直接編集できる状態にすると、どちらが最新か分からなくなります。公開状態、slug、分類、参照元、更新日をAirtableへ集め、静的ビルドが同じ規則で読み出す形にします。API制限や一時的な取得失敗があっても、最後に成功した静的ファイルを配信できる構成が安定します。

①Airtable：記事・分類・出典・公開状態。②生成処理：検証、slug重複確認、静的JSON/HTML書き出し。③公開ファイル：現在のデザインと画面操作。④Worker API：コメント、評価、保存など動的処理。この分け方をREADMEやテーブル説明へ残し、変更時の担当範囲を揃えます。

表示用HTMLをAirtableへ丸ごと持ち、同じ見た目をテンプレートでも上書きする、公開済み記事をslugでだけ関連付けて変更後にコメントが外れる、全リクエストでAirtableを直接読む、失敗時に空データで上書きする、といった問題があります。安定キーにはrecord\_idを使い、slugはURL、表示は静的テンプレートに限定します。

1. 記事種別・公開状態・slug・分類・出典の必須項目を決める。2. ジャンル、カテゴリー、シリーズ、タグの役割を分ける。3. Airtable APIの対象フィールドと取得件数を絞る。4. 取得データを検証してから静的JSON/HTMLへ書き出す。5. publicと配信用ディレクトリを必要なファイルだけ同期する。6. Workerは /api/ と静的配信の境界を明確にする。7. check、health、代表記事、旧URL転送を確認して公開する。8. 直前の正常な静的出力へ戻せるよう履歴を残す。

最初に通常記事1本、3Q記事1本、コメント付き記事1本を代表として通します。表示とAPIが安定したら対象を増やします。日常運用はAirtable更新、検証、静的出力、check、代表ページ確認の固定順にし、取得失敗時は公開ファイルを更新しません。

記事本文、画像、CSS、JSはStatic Assetsで配信し、コメント投稿・返信・評価・保存など更新が必要な経路だけWorkerへ通します。記事とコメントの関連にはarticle_record_id、返信にはparent_comment_idを使い、slug変更後も関係が切れない構造にします。認証情報は公開JSへ置かず環境設定で管理します。

ビルド成功率、Airtable APIエラー、静的ファイルの差分、health、記事404、コメント投稿成功、ページ表示速度を確認します。異常時にどこまで戻せるか、誰が再実行するかも記録します。閲覧数の増減だけで同期品質を判断しません。

対象

正とする場所

変更方法

本文・分類・出典

Airtable

レコード更新後に検証・書き出し

HTML・CSS・JS

静的ファイル

コード変更、check、ブラウザ確認

記事表示

生成済み静的データ

正常取得時だけ更新

コメント・評価

Worker APIと保存先

安定キーで記事へ関連付け

秘密情報

環境設定・Binding

公開ファイルへ書かない

Airtableを表示の正にしないのですか？

記事データの正にはしますが、公開デザインと操作は静的テンプレートを正にします。表示変更をデータ欄のHTML上書きで行いません。

公開時に毎回Airtableを直接読みますか？

基本は検証済みの静的出力を配信します。動的に必要なAPIだけWorkerへ分けます。

slugを変えたらコメントは外れますか？

article_record_idで関連付ければslug変更後も維持できます。旧URLには301転送を設定します。

Airtableを記事データ、静的ファイルを公開表示、Workerを必要な動的APIの正として分けます。取得データを検証してから更新し、代表記事のブラウザ確認とロールバック手順を固定すれば、旧CMSなしでも継続しやすい運用になります。

• Airtable API limits

  Web APIは原則1ベース毎秒5リクエスト。429時の待機と再試行、バッチ処理を前提に設計する。

  公式情報 / 2026-07-14
• Airtable Web API

  JSONベースのWeb APIでレコードの取得・作成・更新ができ、一覧取得は1ページ最大100件。認証はPersonal access tokenまたはOAuthを使う。

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

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

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

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

  公式情報 / 2026-07-14