Astro / GitHub Pagesで静的サイトを安全に低コストで運用する

私たちは、コーポレートサイトをできるだけ静的に、できるだけGitHub上の変更管理に寄せて運用しています。

AstroでHTMLを生成し、GitHub Pagesで配信し、GitHub Actionsで公開作業を自動化する。そこにClaude Codeを組み合わせて、記事追加や文言修正の下書き、差分整理、公開前チェックを進める。こうすると、サイト運用を「サーバーを触る仕事」ではなく「会社の言葉を更新し、差分を確認して公開する仕事」に寄せられます。

コーポレートサイトは、毎分データが変わるアプリケーションではありません。日常的に発生するのは、サービス説明を直す、Tech Blogを出す、採用情報を更新する、問い合わせ導線を見直す、といった変更です。これらを毎回WebサーバーやDBの運用と結びつけると、更新の心理的な重さが増えます。

その重さを外すために、私たちはコーポレートサイトを「静的に生成して、GitHubで確認して、GitHub Pagesに出す」構成にしています。実装の枝葉よりも大事なのは、編集、確認、公開の流れをシンプルに保つことです。

全体像は、編集から公開までをGitHubに集める

この構成の中心は、コーポレートサイトの変更をGitHub上の流れとして扱うことです。

記事や会社情報を更新する。Pull Requestで差分を見る。GitHub Actionsで検証する。mainに入ったらAstroがサイトを生成する。生成されたHTML、CSS、JavaScript、画像をGitHub Pagesで配信する。問い合わせや通知のような動的処理は、フォームや外部サービスに分ける。

流れとしては、次のように捉えています。

コンテンツを更新する
Pull Requestで変更を見る
GitHub Actionsで検証する
Astroで静的ファイルを生成する
GitHub Pagesで公開する
フォームや計測は外部サービスに逃がす

この流れにしておくと、サイト表示のために常時動くアプリケーションサーバーを持たずに済みます。公開されるのは、Astroが生成した静的なサイトです。運用中に見るべきものも、サーバーの状態ではなく、変更差分、検証結果、公開ログになります。

AstroとGitHub Pagesで運用するコーポレートサイトの全体像

Astroは、コーポレートサイトを静的に扱いやすい

Astroを使う理由は、コーポレートサイトを「静的に生成できる情報の集合」として扱いやすいからです。

ブログ記事、会社情報、サービス説明、著者情報、画像、計測設定。これらは、頻繁に変わるリアルタイムデータではありません。Gitで管理し、レビューし、ビルド時にページへ反映するほうが自然な情報です。

もちろん、すべてを静的に閉じる必要はありません。問い合わせフォーム、Slack通知、GA4への送信、資料請求後のメール送信などは、Google Forms、Google Apps Script、GTM/GA4のような外部サービスに任せればよいです。サイト本体は表示に集中し、フォーム処理や通知はそれぞれの得意な基盤へ分ける。この分け方が、運用の見通しをよくします。

Astro / GitHub Pagesの組み合わせは、この分担が作りやすいです。サイト本体は静的に生成する。公開はGitHub Pagesに任せる。外部サービスとの接続はリンク、フォーム、計測イベントとして扱う。コーポレートサイトに必要な要素を、過剰なアプリケーション構成にしないまま組み合わせられます。

GitHub Actionsで、公開を運用フローにする

GitHub Actionsを入れると、公開作業を「担当者ごとの作業」から「リポジトリに書かれた運用フロー」にできます。

Pull Requestでは、文章や設定の差分を見ます。同時に、lint、test、buildを走らせます。mainにマージされたら、同じ環境でAstroをビルドし、GitHub Pagesへ公開します。人がローカルでビルドしてアップロードする流れを持たないので、公開作業のばらつきが減ります。

GitHub Actionsのもうひとつの価値は、ログが残ることです。ビルドが失敗した場合、どのコミットで、どのjobが、どのログで止まったのかを見られます。記事のメタ情報が壊れていればビルドで止まり、テストが落ちれば公開前に気づけます。公開判断を、担当者の勘ではなく、PRとCIの結果に寄せられます。

peaceiris/actions-gh-pages は、Astroのビルド成果物を gh-pages ブランチへ反映するために使えます。公開ブランチを分けられるので、ソースを管理するブランチと、配信される静的ファイルを置くブランチを分けやすいです。一方で、ブランチへpushするための権限設計は必要です。GitHub Pages公式の actions/deploy-pages を使う構成もあるため、チームの権限設計や運用方針に合わせて選びます。

GitHub ActionsからGitHub Pagesへ公開する流れ

コストは、サーバー代ではなく利用枠で考える

この構成では、WebサーバーやDBを常時起動する前提ではなく、GitHubのプランと利用枠でコストを考えます。

GitHub Pagesは、リポジトリから静的ファイルを配信する仕組みです。public repositoryであればGitHub Freeでも利用できます。private repositoryで使う場合は、GitHub Pro、Team、Enterprise Cloudなどのプラン条件を確認します。

GitHub Actionsについても、まずは公式の無料利用範囲を見ます。2026年6月時点のGitHub Docsでは、標準GitHub-hosted runnerはpublic repository、GitHub Pages、Dependabotで無料利用の対象です。private repositoryの通常ワークフローでは、プランごとに月間minutesとstorageの枠があります。GitHub FreeとGitHub Free for organizationsはActions minutesが月2,000分、GitHub ProとGitHub Teamは月3,000分です。

小さなコーポレートサイトでは、Actionsの消費量も見積もりやすいです。たとえば、1回のPRチェックと公開処理を合計3分と見積もり、月30回走らせても90分です。実際の消費量は依存関係、テスト数、画像処理、runner種別で変わりますが、費用の見方は「サーバーを何台動かすか」ではなく「何回ビルドするか」になります。

GitHub Pages側にも前提があります。公開済みサイトは1GB以内、デプロイは10分以内、帯域は月100GBのsoft limitがあります。ECサイト、SaaS、パスワードやカード番号を扱う取引のように、GitHub Pagesの想定用途から外れるサイトには使わない前提です。コーポレートサイト、採用ページ、Tech Blogのように静的配信で足りる領域に絞ると、コストと運用負荷を抑えやすくなります。

Claude Codeは、更新作業を軽くするために使う

Claude Codeは、サイトを自動で公開させるためではなく、更新作業を軽くするために使っています。

記事の下書き、説明文の整理、関連CTAの確認、OGPの抜け漏れ確認、表現のトーン調整。こうした作業は、リポジトリの構造と運用ルールが決まっているほど任せやすくなります。AIに自由に書かせるのではなく、「このサイトでは何をどこに置くのか」「公開前に何を見るのか」を読ませてから作業させるほうが安定します。

そのために、私たちはサイトのルールをリポジトリ側へ寄せています。Tech BlogとNewsを分ける。著者情報や会社情報を重複させない。成果数値を保証表現にしない。GA4のevent paramsに個人情報を入れない。こうしたルールを文章として置いておくと、Claude Codeに依頼したときも、単に本文を生成するだけでなく、公開に必要な周辺情報まで見ながら作業できます。

AIを使うほど、人間が見るポイントは減らすのではなく明確にします。本文は読めるか。会社の見立てとして強すぎないか。関連サービスへの導線は自然か。画像やOGPは入っているか。計測に個人情報が混ざっていないか。こうした確認をPRで見る運用にしておくと、AIは作業者として扱いやすくなります。

AIを使ったコーポレートサイト更新のガードレール

この構成で気をつけていること

静的サイトに寄せるほど、何を静的サイトの外に出すかを先に決めておく必要があります。

まず、問い合わせ処理はサイト本体に持たせすぎません。フォーム、通知、メール送信、計測は、それぞれ外部サービスやGASに分けます。サイトは表示に集中させ、送信後の処理はフォーム基盤に任せます。

次に、画像とOGPは記事運用の一部として扱います。本文だけを追加して終わりにすると、一覧やSNSで見たときに弱くなります。記事を出すときは、ヒーロー画像、OGP、タイトル、説明文、関連導線までまとめて確認します。

そして、GitHub Actionsの権限は必要最小限にします。peaceiris/actions-gh-pages で公開ブランチへpushするなら contents: write が必要ですが、workflow全体に広い権限を持たせる必要はありません。公開用のtokenやsecretを増やす前に、GITHUB_TOKEN で足りる範囲を確認します。

最後に、編集体験はチームに合わせます。MarkdownとPull Requestで十分なチームもあれば、管理画面が必要なチームもあります。広報チームが頻繁に更新し、予約投稿や承認フローを画面上で完結させたい場合は、ヘッドレスCMSやフォーム入力型の編集フローを組み合わせたほうがよいです。

向いているのは、会社の言葉を育てるサイトです

Astro / GitHub Pages / GitHub Actionsの構成は、会社の言葉を少しずつ育てていくサイトに向いています。

サービス説明を磨く。Tech Blogを積み上げる。採用情報を更新する。問い合わせ導線を改善する。こうした運用では、複雑なサーバー構成よりも、変更の見通し、レビューしやすさ、公開ログの残り方が効いてきます。

反対に、ログイン後の個別画面、リアルタイムな価格表示、在庫、検索、通知、決済のような機能が中心なら、静的サイトではなくアプリケーションとして設計するべきです。静的サイトで済むものと、アプリケーションとして持つべきものを分けることが大事です。

私たちは、コーポレートサイトの初期運用では、まず静的サイトとして育てる構成を選びます。運用の中心をインフラではなく、コンテンツと変更管理に置けるからです。必要になったところだけ、フォーム、CMS、検索、通知などを外部サービスや別コンポーネントとして足していくほうが、全体の見通しを保ちやすいです。

まとめ

Astro / GitHub Pagesなら、コーポレートサイトを静的サイトとして安全に低コストで運用しやすくなります。GitHub Actionsを組み合わせると、公開作業を人の記憶に頼らず、PR、CI、デプロイログで確認できる形にできます。

Claude Codeを加えると、記事追加や文言修正の作業も軽くできます。ただし、AIに自由に書かせるのではなく、サイトの構成、公開フロー、確認ポイントを先に決めておくことが前提です。

この構成の狙いは、コーポレートサイトを「触るのが怖いWebサーバー」ではなく、「会社の言葉を少しずつ更新していける静的な知識基盤」として扱うことです。

参考にした一次情報

コーポレートサイトのAIを前提にした運用設計を相談する