投稿した記事が公開されるまでのプロセス

2025年06月26日

このよんなーハウスのサイトにおいて投稿した記事がどのように表示されるのかの説明になります。

システム構成の全体像

この仕組みにおけるデータの流れと各サービスの連携は、以下のようになります。

まず、ユーザー（コンテンツ管理者）がmicroCMSで記事の作成や更新を行います。
コンテンツが公開されると、それをきっかけにmicroCMSからGitHub Actionsへ「Webhook」という通知が自動で送られます。
通知を受け取ったGitHub Actionsは、あらかじめ設定された自動化処理を開始します。
処理が始まると、GitHub ActionsはGitHubリポジトリからウェブサイトの元となるソースコードを取得します。同時に、microCMSに対してAPI経由でアクセスし、記事などの全コンテンツデータを取得します。
ソースコードとコンテンツデータが揃うと、GitHub Actionsはサイトのビルド（構築）を実行し、公開可能な静的ファイル（HTML/CSS/JS）を生成します。最後に、生成された静的ファイルをAzure Static Web Appsへデプロイ（配備）します。
これにより、ウェブサイト訪問者はAzure Static Web Apps上で更新された新しいサイトを閲覧できるようになります。

この構成の核心は、「コンテンツ管理」「開発・ビルド」「公開」の役割を専門のサービスに分離・連携させる点にあります。

各コンポーネント（サービス）の役割

それぞれのサービスが、この自動化ワークフローでどのような役割を担っているのかを見ていきましょう。

microCMS (ヘッドレスCMS)

役割: コンテンツ（記事、お知らせ等）の管理・入稿システム。
特徴: いわゆる「ヘッドレスCMS」の一つで、WordPressのようにWebサイトの表示機能（ヘッド）を持たず、コンテンツをAPI経由で提供することに特化しています。これにより、Webサイトの見た目（フロントエンド）とコンテンツ管理（バックエンド）を完全に分離できます。

Webhook (ウェブフック)

役割: システム間の「イベント通知」の仕組み。
特徴: microCMSで「記事が公開された」というイベントが発生した際に、その情報をトリガーとして、指定されたURL（今回はGitHub Actions）にHTTPリクエストを自動的に送信します。これが、自動化プロセスを開始する「号砲」の役割を果たします。

GitHub (ソースコードリポジトリ)

役割: Webサイトのソースコード（HTMLのテンプレート、CSS、JavaScriptなど）を管理する場所。
特徴: Gitを用いたバージョン管理システムであり、コードの変更履歴をすべて記録します。開発の拠点となる場所です。

GitHub Actions (CI/CDツール)

役割: ワークフローの自動化ツール。特にCI/CD (継続的インテグレーション/継続的デプロイ) パイプラインを構築します。
特徴: Webhookからの通知を受けると、あらかじめYAMLファイルで定義された一連の処理（コードのチェックアウト、コンテンツの取得、ビルド、デプロイ）を自動で実行する、この仕組みの「司令塔」であり「工場」です。

Azure Static Web Apps (ホスティングサービス)

役割: 完成した静的Webサイトを公開（ホスティング）する場所。
特徴: 静的サイト（HTML、CSS、JavaScriptファイルで構成されるサイト）の配信に最適化されたMicrosoft Azureのサービスです。グローバルなCDN（コンテンツデリバリネットワーク）が統合されており、世界中のどこからでも高速なアクセスが可能です。

ワークフロー解説：コンテンツ投稿からサイト更新までの流れ

それでは、一連のプロセスを時系列で見ていきましょう。

1. コンテンツの投稿・更新

Webサイトの記事を更新する際、担当者の方が行う作業は、このコンテンツ管理システム（microCMS）での操作だけです。

(1) 記事の作成・編集 microCMSにログインし、新しい記事の作成や既存記事の編集を行います。

(2) 表示の確認「公開」ボタンを押す前に、プレビュー機能を使って、実際のサイトでどのように表示されるかを確認できます。

(3) 公開内容に問題がなければ「公開」ボタンを押します。

※「公開」ボタンを押した直後には、まだWebサイトに内容は反映されません。この後の自動処理を経て、数分でサイトが更新されます。

2. Webhookによる通知

コンテンツの公開をトリガーとして、microCMSは設定されたGitHub ActionsのURLに対してWebhookを送信します。「新しいコンテンツが公開された」という情報がGitHubに伝わります。

3. CI/CDパイプラインの起動 (on GitHub Actions)

Webhookを受け取ったGitHubは、リポジトリ内に定義されたGitHub Actionsのワークフローを起動します。ここからが自動化の本番です。

4. コンテンツの取得とサイトのビルド

起動したワークフローは、定義された手順に従って以下の処理を実行します。

(1)ソースコードのチェックアウト: GitHubリポジトリから、サイトの骨格となるソースコードを取得します。

(2)コンテンツのフェッチ: microCMSのAPIエンドポイントにリクエストを送り、サイトに必要な全てのコンテンツデータ（新規記事だけでなく既存の記事も含む）を取得します。

(4)ビルド: 取得したコンテンツデータとソースコードを組み合わせ、SvelteKitが持つ機能の一つである静的サイトジェネレータを使って、Webサーバーに配置できる完成形の静的ファイル群（HTML, CSS, JavaScript）を生成します。

(5)静的サイトのデプロイ: ビルドによって生成された静的ファイル一式を、Azure Static Web Appsにアップロード（デプロイ）します。Azure側では、アップロードされた新しいファイル群にトラフィックが向くように自動で切り替え処理が行われます。

サイト更新完了

デプロイが完了すると、Webサイト訪問者は更新された新しいページを閲覧できるようになります。ステップ2からここまでの全自動プロセスが、おおよそ2〜3分で完了します。

このアーキテクチャを採用するメリット

なぜ、このような一見複雑に見える構成を取るのでしょうか。それには明確なビジネス的・技術的メリットがあります。

高速なパフォーマンス: 事前にビルドされた静的ファイルを配信するため、サーバー側での動的なページ生成が不要です。これにより、サイトの表示速度が劇的に向上し、ユーザー体験 (UX) を高めます。
高度なセキュリティ: データベースや実行環境をWebサーバーに直接公開しないため、攻撃対象となる領域が極めて少なく、非常に堅牢です。
高いスケーラビリティとコスト効率: 静的ファイルはCDNとの相性が抜群です。突発的なアクセス急増にもCDNが負荷を吸収してくれるため、安定した配信を低コストで実現できます。
優れた開発者体験 (DX): フロントエンドとコンテンツ管理が分離しているため、デザイナーやフロントエンドエンジニアは表示側の開発に、コンテンツ作成者はコンテンツ作成にそれぞれ集中でき、並行して作業を進められます。

この構成は、運用効率、サイトパフォーマンス、セキュリティを高いレベルで両立させるための、非常に合理的な現代のWebサイト構築手法の一つと言えます。

ブログ