本ページでは、地域イベントプラットフォーム『明日は晴れるかな』を安定運用するために欠かせない APIコスト・サーバー負荷・スケール戦略について整理します。
現在の運用は ConoHa WING（共有サーバー）単体による構成ですが、これは「技術的制約」ではなく 予算・管理負荷を最適化するための戦略的選択です。設計段階では、フロントにVPS（Nginx）を配置し、 バックエンドをConoHaに分離する構成も検討していました。
システム自体は全国規模に対応できる柔軟な設計ですが、APIコストやサーバー負荷を考慮し、 現在は会津・福島を中心とした地域特化運用を採用しています。
下図は「APIコスト」「サーバー負荷」「スケール戦略」の全体像をまとめたものです。
1. 全国展開できる設計と、地域特化運用を選択した理由
本システムは、地方 → 県 → 地方圏 → 市町村 の4階層タクソノミー、AIパイプライン、施設データモデルなど、 全国展開を前提とした設計で構築されています。
しかし、全国規模で運用すると Google Places API や OpenAI API の使用量が急増し、以下のようにコストが大幅に上昇します。
しかし、対象エリアを全国化した場合、Google Places API や OpenAI API の消費量が大幅に増え、以下のような運用コストが跳ね上がります。
- Places API 呼び出しの増加（地名・会場数の増加）
- AIリンク集パイプライン（Step0〜4）の都道府県 × カテゴリ分増加
- 投稿件数増加 → AIレビューの負荷増大
- WP Cron の増加による共有サーバー負荷の上昇
これらは「技術的な限界」ではなく、持続可能な予算で安定運用するための戦略的判断です。
2. Google Places API のコスト最適化
Google Places API は、住所や公式サイトURLなどの施設情報を取得する強力なサービスですが、呼び出すたびに課金されます。
■ 既に実装済みの節約仕様
- place_id を施設CPTに保存し、2回目以降はAPIを呼ばない
- 施設自動生成は初回のみ実行（同じ会場が複数イベントで使われる地域特性に最適）
- 住所・電話番号などの応答メタをキャッシュとして再利用
このキャッシュ戦略により、イベント数が増加してもAPIコストが指数関数的に増えない構造を実現しています。
3. OpenAI API（AIレビュー）のコスト最適化
イベント投稿・施設投稿時にバックグラウンドで実行されるAIレビューは、複数の分析ステップがあり一定量のトークンを消費します。
- レビュー結果をメタに保存し、再処理を最小化
- 今後、差分レビュー（変更された箇所のみ再チェック）へ拡張予定
- 処理は非同期（WP Cron）で実行し負荷を分散
- 必要に応じて軽量モデルへ自動切替予定
会津・福島限定運用であれば、現状のコストで安定した運用が可能です。
4. サーバー構成とスケーラビリティ戦略
開発当初には、以下のような分散構成も検討しました。
- フロント：VPS（Nginx）
- バックエンド：ConoHa WING（PHP-FPM）
- 静的アセットをCDN配信
しかし、この構成はサーバー管理コストが高く、予算も跳ね上がるため、現在はConoHa単体 × 地域運用という最適バランスで運用しています。
■ 設計は全国対応、運用は地域特化
- タクソノミーとDBは全国規模を想定
- AIパイプラインも県単位で拡張可能
- コスト最適化のため、現在は会津・福島に縮小して運用
「全国対応できる柔軟性」と「地域運用の現実性」を両立したハイブリッド戦略です。
5. 今後の最適化ポイント
- フライヤーOCR＋自動項目補完の実装（入力の粗さとAIレビューコストを同時に改善）
- リンク集AIパイプラインの「差分更新」対応
- 施設データのローカルキャッシュ強化
- 高負荷時には VPS / 専用サーバーへの段階的移行
これらの改善により、全国展開にも備えた柔軟なスケール戦略を維持します。
開発思想やAI協働の背景については、バイブコーディング実践例をご覧ください。
開発者プロフィール
Rさん（障がい者施設 支援員／地域情報サイト運営／元エンジニア）
福島県会津で福祉現場に従事しながら、余暇時間を使ってChatGPTとの共同開発を推進。
「人は検証と指示、AIはコーディング」という役割分担を確立し、短期間で多機能な地域プラットフォームを構築。
本ページの内容は、2025年9月〜11月にかけてRさんとChatGPTが実際に構築した
「明日は晴れるかな」プロジェクトの開発記録に基づいています。