業界特化ポータルの共通生成基盤
― 複数ポータルを1つの仕組みで支える開発事例

「業界特化のポータルサイトを作りたい」という需要は、医療・介護・法務など多くの領域に存在します。しかし、業種ごとに手作業でHTMLを生成・更新し続けることには限界があります。掲載施設数が数千〜数万件規模になると、ページ生成・データ更新・SEO管理のコストが急速に膨らみ、複数業種への横展開はさらに困難になります。

また、全国の施設情報を扱うポータルでは、緯度経度の欠損（地図に表示されない施設が混在する）、掲載内容の偏りや中立性の担保、薄いコンテンツページによるサイト評価の低下といった品質課題が常につきまといます。これらを「人手で都度チェックする」運用モデルでは、スケールと品質の両立ができません。

こうした背景から、次の3点を同時に解決できる仕組みが必要でした。

• config切り替えだけで複数業種のポータルを同じコードベースから生成できること
• Geocoding品質・中立性・薄いページの除外が仕組みとして自動化されていること
• 小さなチームで複数サイトを継続的に運営できる低コスト体制を実現できること

Pythonで静的サイトジェネレーターを内製し、build_site.pyという1ファイルをconfigの切り替えだけで複数業種のポータルに横展開できる共通基盤を構築しました。業種ごとのサイト名・ドメイン・料金・文言の差分はsite_config_*.jsonに集約し、地域SEOテンプレート（47都道府県の導入文・FAQ）はregion_texts_*.jsonとして分離することで、新業種への追加コストを大幅に下げています。

データ品質の設計では、Geocoding APIで全施設の緯度経度を付与し、品質監査スクリプト（latlng欠損監査）で地図表示の品質を継続的にモニタリングします。中立性チェックはcheck_neutrality.pyとして独立したスクリプトに整理し、git commit時のpre-commitフックとビルド時の両方で自動実行する二重構成にすることで、禁止語の混入を構造的に防いでいます。

また、正式な施設IDを持たない薄いページは、ビルド時に自動でnoindexかつsitemap除外が強制される設計を採用しています。これにより、量産サイトにありがちな「薄いページがインデックスされてサイト全体の評価を下げる」問題を構造的に排除しています。

掲載施設が数万件規模になると、人手での品質管理は現実的ではありません。本共通基盤では、品質の担保を「仕組み」として自動化することを基本方針としています。中立性チェックは禁止語リストを単一ファイル（check_neutrality.py）で一元管理し、ポータル記事・施設説明文のいずれにも同じ基準が適用されます。

• 禁止語チェックはpre-commitフックとビルド時の二重構成で自動実行（人手の確認に依存しない）
• Geocoding品質はlatlng欠損監査スクリプトで継続モニタリング（地図に出ない施設をビルド前に検出）
• 薄いページ（正式IDなし）はビルド時に自動でnoindex＋sitemap除外が強制される設計
• GitHub Actions（CI）による自動チェックで、push・PRのタイミングでも品質を検証

この共通基盤と品質設計は、在宅クリニックナビ・訪問看護ステーションナビをはじめとする自社運営の医療・介護系ポータルを支えており、新たな業種・地域への横展開も同じ仕組みで進めています。

新業種・新地域へのポータル展開は、共通基盤が整っているとはいえ、データソースの選定・Geocoding精度の確認・SEO設計のカスタマイズなど、業種ごとの初期検証が必要です。一気にフル公開するのではなく、段階的に精度と範囲を広げる進め方を採っています。

• Phase 1: 対象業種・データソース・掲載要件のヒアリング、地域SEOテンプレートの設計
• Phase 2: configの作成、限定地域・限定件数でのビルド検証（Geocoding精度・中立性チェック確認）
• Phase 3: 全国規模でのビルド・品質監査（latlng欠損・薄いページ除外・noindex設計の確認）
• Phase 4: 本番公開・Search Console連携・SEO効果のモニタリングと改善サイクルへ

GitHub PagesとCloudflareを組み合わせた静的配信構成により、高速表示とCDN配信を低コストで実現しています。GA4とSearch Consoleを組み込んだ分析基盤も共通化されており、ポータルが増えても運用コストが線形に増加しない設計を目指しています。