開発事例
8 分

記事が1000件になっても大丈夫！スケーラブルな記事管理ワークフローの構築

静的サイトジェネレーターの宿命であるビルド時間の増大。記事数に依存しない革新的なワークフローで、開発効率を劇的に改善した事例を紹介します。

Next.jsGitHubCI/CDスケーラビリティワークフロー

はじめに：AIで簡単に構築、でも運用は？

AIの力を借りれば、記事管理システムは驚くほど簡単に構築できます。しかし、実際に運用を始めると、思わぬ課題に直面することがあります。

私たちのケースでは、こんな問題に直面しました：

記事数20件 → ビルド時間: 1分
記事数100件 → ビルド時間: 5分？
記事数1000件 → ビルド時間: 50分？？？

このままでは、記事を追加するたびにコーヒーブレイクが必要になってしまいます。

従来のアプローチの問題点

典型的な静的サイトの構成

プロジェクト/
├── public/data/
│   ├── news.json      # すべての記事データ
│   └── tips.json      # すべてのTIPSデータ
└── pages/
    └── [slug].tsx     # 静的生成
    この構成では、記事を追加するたびに：
  1. JSONファイルを更新
  2. 全ページを再ビルド
  3. デプロイ完了まで待機

記事が増えるほど、この待ち時間は指数関数的に増加します。

革新的な解決策：外部リポジトリ + ISR

新しいアーキテクチャ

メインサイト（Vercel）          記事データ（GitHub）
     ↓                           ↓
  webリポジトリ            gizin-contentリポジトリ
     ↓                           ↓
 GitHub API ← - - - - - - - → 記事JSON
     ↓
 ISRキャッシュ（1時間）

実装のポイント

1. データローダーの改良

typescript
// lib/data-loader.ts
async function fetchFromGitHub(path: string): Promise<string | null> {
  const response = await fetch(
    `https://api.github.com/repos/${GITHUB_OWNER}/${GITHUB_REPO}/contents/${path}`,
    {
      headers: {
        'Authorization': `Bearer ${GITHUB_TOKEN}`,
        'Accept': 'application/vnd.github.v3.raw'
      },
      next: { revalidate: 3600 } // ISR: 1時間キャッシュ
    }
  )
  return await response.text()
}

2. ローカルプレビュー機能

開発時の体験も重要です。本番公開前にローカルで確認できる仕組みを追加：

typescript
// 開発環境では一時記事も読み込む
if (IS_DEVELOPMENT) {
  const tempArticles = await loadTempArticles('news')
  articles = [...tempArticles, ...articles]
}

実践的なワークフロー

Step 1: 記事作成

bash
# AIが記事を作成
→ temp/articles/tips/2025-06-19-example.json

Step 2: ローカル確認

bash
npm run dev
# 開発サーバーで即座にプレビュー
# 「未公開（プレビュー）」バッジで識別

Step 3: ワンコマンドで公開

bash
npm run article:publish tips temp/articles/tips/2025-06-19-example.json
    このコマンドが自動的に：
  • 外部リポジトリにファイルをコピー
  • Git commit & push
  • 一時ファイルを削除

Step 4: 自動反映

ISRにより、1時間以内に本番サイトに反映されます。ビルドは不要！

導入効果

ビルド時間の比較

記事数 従来の方式 新方式
20件 1分 1分
100件 5分 1分
1000件 50分 1分

ビルド時間が記事数に依存しなくなりました！

その他のメリット

  1. 即座の記事公開
    2. - ビルド待ち時間ゼロ - GitHubにpushするだけ
  1. 開発効率の向上
    2. - ローカルプレビューで安心 - ワンコマンドで公開
  1. スケーラビリティ
    2. - 10,000記事でも問題なし - CDNキャッシュで高速配信

実装時の注意点

1. 環境変数の設定

bash
# Vercelに設定
GITHUB_OWNER=your-org
GITHUB_REPO=content-repo
GITHUB_TOKEN=ghp_xxxxxxxxxxxx

2. セキュリティ考慮

  • GitHubトークンは読み取り専用で十分
  • レート制限に注意（認証済みで5000回/時）

3. 移行戦略

    段階的な移行がおすすめ：
  1. まずNewsとTipsのみ外部化
  2. 更新頻度の低いデータは静的なまま
  3. 必要に応じて追加移行

実装コード例

公開スクリプト（一部抜粋）

bash
#!/bin/bash
# scripts/publish-to-content.sh

# gizin-contentリポジトリに移動
cd "$CONTENT_REPO"

# 最新を取得
git pull origin main

# ファイルをコピー
cp "$ORIGINAL_DIR/$FILE" "$TYPE/articles/$FILENAME"

# コミット&プッシュ
git add .
git commit -m "feat: 新記事追加 - $FILENAME"
git push origin main

まとめ：運用を見据えた設計の重要性

AIによる初期構築は素晴らしいスタート地点です。しかし、真の価値は運用フェーズで発揮されます。

    今回の改善により：
  • 開発者の待ち時間: 50分 → 0分
  • 記事公開の手間: 複雑 → ワンコマンド
  • スケーラビリティ: 限定的 → 無限大

記事が1000件になっても、10000件になっても、変わらない快適さ。これが、運用を見据えた設計の力です。

次のステップ

このワークフローをさらに改善するアイデア：

  1. GitHub Actions統合
    2. - PRマージで自動公開 - レビューフローの確立
  1. プレビューURL生成
    2. - 一時記事の共有URL - チーム内レビューの効率化
  1. バージョン管理
    2. - 記事の履歴追跡 - ロールバック機能

皆さんのプロジェクトでも、ぜひこのアプローチを試してみてください！

Tips一覧に戻る