記事が1000件になっても大丈夫!スケーラブルな記事管理ワークフローの構築
記事数が1000件になってもビルド時間が変わらない!外部リポジトリとISRを組み合わせた革新的ワークフローで、開発者の待ち時間をゼロに。
目次
はじめに:AIで簡単に構築、でも運用は?
AIの力を借りれば、記事管理システムは驚くほど簡単に構築できます。しかし、実際に運用を始めると、思わぬ課題に直面することがあります。
私たちのケースでは、こんな問題に直面しました:
記事数20件 → ビルド時間: 1分
記事数100件 → ビルド時間: 5分?
記事数1000件 → ビルド時間: 50分???
このままでは、記事を追加するたびにコーヒーブレイクが必要になってしまいます。
従来のアプローチの問題点
典型的な静的サイトの構成
プロジェクト/
├── public/data/
│ ├── news.json # すべての記事データ
│ └── tips.json # すべてのTIPSデータ
└── pages/
└── [slug].tsx # 静的生成
この構成では、記事を追加するたびに:
- JSONファイルを更新
- 全ページを再ビルド
- デプロイ完了まで待機
記事が増えるほど、この待ち時間は指数関数的に増加します。
革新的な解決策:外部リポジトリ + ISR
新しいアーキテクチャ
メインサイト(Vercel) 記事データ(GitHub)
↓ ↓
webリポジトリ gizin-contentリポジトリ
↓ ↓
GitHub API ← - - - - - - - → 記事JSON
↓
ISRキャッシュ(1時間)
実装のポイント
1. データローダーの改良
// 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. ローカルプレビュー機能
開発時の体験も重要です。本番公開前にローカルで確認できる仕組みを追加:
// 開発環境では一時記事も読み込む
if (IS_DEVELOPMENT) {
const tempArticles = await loadTempArticles('news')
articles = [...tempArticles, ...articles]
}
実践的なワークフロー
Step 1: 記事作成
# AIが記事を作成
→ temp/articles/tips/2025-06-19-example.json
Step 2: ローカル確認
npm run dev
# 開発サーバーで即座にプレビュー
# 「未公開(プレビュー)」バッジで識別
Step 3: ワンコマンドで公開
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分 |
ビルド時間が記事数に依存しなくなりました!
その他のメリット
-
即座の記事公開
- ビルド待ち時間ゼロ
- GitHubにpushするだけ
-
開発効率の向上
- ローカルプレビューで安心
- ワンコマンドで公開
-
スケーラビリティ
- 10,000記事でも問題なし
- CDNキャッシュで高速配信
実装時の注意点
1. 環境変数の設定
# Vercelに設定
GITHUB_OWNER=your-org
GITHUB_REPO=content-repo
GITHUB_TOKEN=ghp_xxxxxxxxxxxx
2. セキュリティ考慮
- GitHubトークンは読み取り専用で十分
- レート制限に注意(認証済みで5000回/時)
3. 移行戦略
段階的な移行がおすすめ:
- まずNewsとTipsのみ外部化
- 更新頻度の低いデータは静的なまま
- 必要に応じて追加移行
実装コード例
公開スクリプト(一部抜粋)
#!/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件になっても、変わらない快適さ。これが、運用を見据えた設計の力です。
次のステップ
このワークフローをさらに改善するアイデア:
-
GitHub Actions統合
- PRマージで自動公開
- レビューフローの確立
-
プレビューURL生成
- 一時記事の共有URL
- チーム内レビューの効率化
-
バージョン管理
- 記事の履歴追跡
- ロールバック機能
皆さんのプロジェクトでも、ぜひこのアプローチを試してみてください!
画像を読み込み中...
📢 この発見を仲間にも教えませんか?
同じ課題を持つ人に届けることで、AI協働の輪が広がります
関連記事
「記事を更新したのに公開されない!」から学ぶ固定ワークフローの自動化
ベテランエンジニアでも起こす「コミット忘れ」。実際の失敗談から、なぜ固定ワークフローをコマンド化すべきなのか、その本質的な価値を解説します。
Claude Codeのカスタムコマンドで開発効率を爆上げする方法
CLAUDE.mdの肥大化とトークン消費の問題を解決!固定ワークフローをカスタムコマンド化することで、トークン消費を20%削減しながら、より自然な指示でAIを活用する方法を解説します。
AI駆動開発における「GitHubがあるから大丈夫」という落とし穴 〜バックアップ戦略の重要性〜
AI協働開発で実際に発生した38記事のデータ破損事例。GitHubがあっても防げなかった理由と、ローカルバックアップが救世主となった経験から学ぶ、AI時代の新しいバックアップ戦略。