AIに画面とAPI連携を作らせると、試作品は早く動き始めます。ところが、本番公開後の請求や障害は、コードが完成した時点では見えにくいものです。
とくに確認したいのが、一回のページ閲覧で、外部APIを何回呼ぶかです。閲覧のたびに最新情報を取りに行く設計では、アクセスが増えるほど外部API、サーバー処理、データベースの利用量も増えます。無料枠があるサービスでも、利用量が枠内に収まるとは限りません。
公開前に必要なのは、特定サービスの最安プラン探しではありません。閲覧数と外部呼び出し回数の関係を式にし、更新頻度に合う取得方式を選び、上限を超えたときに止められる状態を作ることです。
最初に「一閲覧あたりの外部呼び出し」を数える
まず、ページを一回表示したときに発生する処理を分けます。
- 静的なHTML、CSS、画像の配信
- 自社のサーバー処理やFunctionsの実行
- 外部APIへの問い合わせ
- データベースの読み書き
- 失敗時の再試行
同じ「ページ表示」でも、どこまで従量課金の対象になるかはサービスごとに異なります。たとえばCloudflare Pagesでは、Functionsを呼ばない静的アセットのリクエストと、Workersとして数えられるFunctionsのリクエストが分けて説明されています。料金や上限は変更され得るため、導入時点の公式条件を確認します。(Cloudflare Pages Functionsの料金)
上限を考えるときは、次の概算から始められます。
一日あたりの外部呼び出し上限
= 一日のページ閲覧数 × 一閲覧あたりの外部API数 × 再試行係数仮に、一日1万回の閲覧、一閲覧あたり2回の外部API呼び出し、再試行を含まない条件なら、一日2万回です。これは料金予測ではなく、設計上の呼び出し回数を確認するための例です。実際の請求は、キャッシュ、エラー、ボット、APIごとの課金単位などで変わります。
取得方式は4つに分けて選ぶ
「常に最新であるほど良い」と決める前に、業務上どの鮮度が必要かを確認します。取得方式は、次の4つに分けられます。
1. 閲覧時に取得する
利用者がページを開くたびに外部APIへ問い合わせます。残席、在庫、決済直前の金額など、その瞬間の値が判断に必要な場合に向きます。
一方で、閲覧数がそのまま呼び出し回数へ反映されやすく、外部APIが遅いと画面も遅くなります。タイムアウト、再試行、上限超過時の表示を先に決めます。
2. イベントを受けて更新する
外部サービス側のWebhookなどを受け、変更が起きたときだけ自社データを更新します。更新イベントを受け取れること、署名検証や再送処理を実装できることが条件です。
イベントの欠落や重複に備え、最終更新時刻と照合処理を残します。
3. 定期的に取得して保存する
1時間ごと、一日数回など、決めた間隔で取得し、自社側にスナップショットを保存します。利用者には保存済みの値を返すため、閲覧数と外部API呼び出しを切り離せます。
先ほどと同じく外部APIを2回使う処理でも、1時間ごとの更新なら、概算は一日48回です。ただし、最大1時間古い情報を表示する可能性があります。画面には更新時刻を出し、古い情報で判断してよい業務だけに使います。
4. 人が必要時に更新する
更新頻度が低い情報や、公開前に人の確認が必要な情報では、管理画面の更新ボタンや承認付きの手動反映が適します。自動化率は下がりますが、間違ったデータを連続配信するリスクを抑えられます。
重要なのは、システム全体を一方式にそろえないことです。商品説明は定期更新、在庫はイベント更新、決済直前だけ閲覧時取得、といった分け方ができます。
キャッシュは「古くてもよい時間」と一緒に決める
キャッシュを入れれば、同じ問い合わせを毎回実行せずに済む場合があります。Cloudflare WorkersのCache APIも、キャッシュの保存と取得の方法を公式に示しています。(Cloudflare Workers Cache API)
ただし、「キャッシュを使う」だけでは運用条件になりません。最低限、次を記録します。
- 何をキャッシュするか
- 何分まで古くてよいか
- 更新失敗時に古い値を表示するか
- 強制更新を誰が実行できるか
- キャッシュを消した後、外部APIへ負荷が集中しないか
鮮度の要件がないままキャッシュ時間だけを決めると、費用は下がっても誤った業務判断につながります。
公開前に運用・費用台帳を一枚作る
APIの情報をコードや請求画面だけに残さず、一枚の台帳へまとめます。
| 項目 | 記録する内容 |
|---|---|
| 用途 | どの画面・業務で使うか |
| 取得方式 | 閲覧時・イベント・定期・手動 |
| 呼び出し上限 | 一日・一か月の概算 |
| 鮮度 | 何分、何時間まで古くてよいか |
| 費用 | 固定費、従量単価、無料枠、通貨 |
| 通知 | 予算の何％で誰へ知らせるか |
| 停止 | 何を止め、画面に何を表示するか |
| 復旧 | 再取得、照合、公開再開の順序 |
| 所有者 | 契約者、支払者、技術担当、更新日 |
ログには、秘密情報や個人情報をそのまま残しません。OWASPのLogging Cheat Sheetは、セキュリティイベントの記録だけでなく、ログへ含めるべきでない情報や、ログ自体の保護も整理しています。(OWASP Logging Cheat Sheet)
停止条件と復旧条件を公開前に決める
予算通知だけでは、担当者が見逃したときに止まりません。次の段階を決めます。
- 予算の50％で担当者へ通知する
- 80％で更新頻度を下げる、または非必須の取得を止める
- 上限到達や連続失敗で外部取得を停止し、保存済みデータと更新時刻を表示する
- 原因を確認し、欠落期間を照合してから再開する
割合は一例です。重要なのは、通知、縮小、停止、復旧を別の状態にすることです。停止時にページ全体を落とす必要はありません。外部連携だけを止め、説明付きで保存済み情報を出す設計も選べます。
また、公開したコードを戻せる状態も必要です。Cloudflare Pagesでは以前のデプロイへロールバックする手順が案内されていますが、データベースや外部API側の変更が同時に元へ戻るとは限りません。(Cloudflare Pagesのロールバック)
小さな公開で確認する順番
最初から大きなアクセスを想定した複雑な基盤にしなくても、次の順で確認できます。
- テスト用データで、一表示あたりの呼び出し回数をログに残す
- 想定閲覧数を入れ、日次・月次の上限を概算する
- 鮮度に合わせて4方式から選ぶ
- API停止、タイムアウト、上限到達を再現する
- 保存済み表示と手動復旧を確認する
- 限定公開し、実測値を台帳へ戻す
画面の品質確認にはLighthouse CIのような継続的な検査を使えます。ただし、スコアだけで売上、SEO、費用、データの正しさが保証されるわけではありません。(Lighthouse CI)
AIで作る速度が上がったからこそ、公開前に見るべきものはコード量ではなくなりました。閲覧が何を起動し、どこで費用が増え、何が起きたら止めるのか。その関係を一枚にできれば、小さなサイトでも運用判断を人に戻せます。
具体的な構築・改善まで進めたい場合は、案件相談フォームから、対象業務、現在の流れ、必要な成果物をお知らせください。含む・含まない範囲、利用アカウント、責任分界、検収方法を確認してから個別にお見積もりします。