「わざわざ CMS を用意せずに、GitHub Issues を CMS として使う」という選択には、明確なトレードオフがあります。ここでは両面を対比して整理します。
そもそもの考え方
GitHub Issues を CMS として使うというのは、次のような役割の借用です。
- 記事（コンテンツ） = Issue
- 公開状態 = ラベル（
status:published/status:draft） - 公開の自動化 = GitHub Actions + API
- 表示 = Astro などの静的サイト生成
つまり「入力 UI を作らない」という選択をしている点が、最大の特徴でもあり最大の制約でもあります。
メリット
| 項目 | 内容 |
|---|---|
| 無料 | GitHub アカウントがあれば追加コストなしで運用できる |
| 開発者に馴染みがある | Markdown ネイティブの UI で、GitHub に慣れた人なら説明不要 |
| バージョン管理 | Issue のコメント・編集履歴がそのまま残る |
| 自動化との相性 | GitHub Actions / API が標準装備で、ビルド・公開を自動化しやすい |
| データの所有権 | 外部 CMS に依存せず、コンテンツが自分のリポジトリに残る |
| 通知・コメント | レビューや議論を GitHub の機能でそのまま行える |
| 権限管理 | リポジトリ権限（書き込み可否など）で公開者を制御できる |
デメリット
| 項目 | 内容 |
|---|---|
| WYSIWYG なし | リッチエディタがない。Markdown で書ける人に限られる |
| 非エンジニアに不親切 | 「ラベルを付けて公開」という運用は慣れが必要 |
| フィールドが弱い | リッチな構造化フィールド（画像ライブラリ、リレーション等）は不得手 |
| 大規模に弱い | 記事が数千件規模になると検索・運用が辛くなりやすい |
| GitHub 仕様に依存 | API や添付の仕様変更で壊れることがある |
| 複雑なワークフロー | 多段レビュー・監査ログ・フィールド単位の権限などは作込みが必要 |
専用CMSとの対比
| 観点 | GitHub Issues CMS | 専用CMS（microCMS / Contentful 等） |
|---|---|---|
| コスト | 無料 | プランによる（無料枠あり） |
| 入力 UI | Markdown のみ | WYSIWYG / リッチエディタ |
| 権限管理 | リポジトリ単位 | フィールド・ワークフロー単位まで細かく設定可 |
| メディア管理 | 添付 URL（外部 CDN） | ライブラリ・最適化が標準装備 |
| 自動化 | GitHub Actions と一体 | 各CMS の Webhook / API |
| 学習コスト | 開発者には低い | 使い方の学習が必要 |
| データ管理 | 自分のリポジトリ | ベンダーのクラウド |
どの場面に向くか
向いているケース
- 開発者中心のチーム・技術ブログ
- 記事数が数十〜数百程度
- 無料・自動化・GitHub 内完結を重視
- テキスト主体の記事（画像は URL で十分）
向かないケース
- 非エンジニアが多数執筆する
- リッチな管理画面・メディアライブラリが必要
- 数千記事規模の大規模メディア
- フィールド単位の権限管理・複雑なレビューワークフローが必要
まとめ
GitHub Issues を CMS にするのは「シンプルさ・無料・自動化」を優先する選択です。逆に「リッチな編集体験・高度な運用」を求める場合は専用CMS が適しています。
「テキスト主体のブログを、開発者が GitHub 内だけで運用したい」という用途には、このテンプレートの構成が十分実用的です。まず最小構成で始め、痛みが出た時点で専用CMS への移行を検討するのが現実的な進め方です。