デジタルガーデン

GitHub API を引き剥がす：ローカルファーストのアーキテクチャ決定

2026-09-13 · 約 3 分 · アーキテクチャ · ローカルファースト · 決定復盤

事故現場

個人ポータル v1 にはとても「ギーク」な設計がありました。ビルド時に GitHub API へリクエストし、ユーザーのリポジトリやスター数を自動でページに同期する。データは常に新鮮、手動保守はゼロ。

しかしある日、api.github.com/users/min09577 が 404 を返し始めました——アカウントがプラットフォームのリスク管理にマークされたのです。ビルドは動き続け、データソースは消え、ページの作品リストは縮退したサンプルデータに落ちました。

アカウントは永远アクセス可能という前提——誤り。リスク管理、誤判定、地域の問題。どれひとつ取っても 404 は空から降ってきます。
ビルドマシンのネットワークは信頼できるという前提——脆弱。ビルド成果物が 1 回のネットワークリクエストの成否に依存するなど、エンジニアリングとして許容できません。
データ量はリアルタイム性に見合うという前提——誤り。作品リストは数ヶ月に 1 回変わるだけ。それのために実行時依存を導入するのは、リスクとリターンが完全に釣り合いません。

データソースを引き剥がしました。リポジトリと統計はすべて config.ts にローカル管理し、ビルド時の外部リクエストはゼロに。直接の利益が 3 つ：

ローカル化は自動化の永久放棄ではありません。元の getGitHubData() のシグネチャはそのまま残してあります。将来アカウントが復旧したら、fetch のロジックを差し戻すだけで、上位のコンポーネントは 1 行も変わりません。

今回の復盤で最も大事な教訓はこれです：依存を引き剥がすとき、インターフェースはその場に残せ。データソースは交換できても、契約は交換するな。

今後「ビルド時に外部サービスへリクエストする」というアイデアが出たら、まずこの篩にかけます：

このデータの変化頻度は、持ち込む故障リスクに見合っているか？

月単位で変わるコンテンツには——見合わない。おとなしくコードベースに入り、履歴は git に管理してもらいなさい。