Back

カスタムプロキシで実現するStudioサイトのサブディレクトリ運用

Fumito Kikuchi

2024.07.01

Updated:2024.12.24

Studioガイド

Studioのアドオン機能「カスタムプロキシ」で実現できるSTUDIOサイトのサブディレクトリ運用のユースケースと実装例をご紹介します。

STUDIOでのノーコード化を検討しているものの、既存のWebサイトの規模、機能性、運用体制の煩雑性などを理由に移行への判断に踏み切れない、といった悩みはないでしょうか？

「カスタムプロキシ」機能を活用すれば、既存のWebサイトでも一部サブディレクトリの相性の良いコンテンツからSTUDIOへの移行が実現できます。

この記事では、5月23日にリリースされたアドオン機能「カスタムプロキシ」の活用メリットを、ユースケースと実装例とともに解説します。

本記事は、ある程度の人数やサイト規模でSTUDIOを運用しており、多機能なWebサイトの実装や段階的な移行に関心や課題を持つ事業会社さまや制作会社さま向けの内容となります。

アドオン機能の詳細についてはSTUDIOのヘルプ記事も併せてご参照ください。

💡 この記事で取り上げる内容は、STUDIO以外のサービスを用いた応用的な設定になります。リバースプロキシからの転送設定など、カスタムプロキシ機能で想定する標準的な疎通に関してのご不明点はヘルプ記事も参照しながらトラブルシューティングいただくことを推奨いたします。

そもそも「カスタムプロキシ」とは
カスタムプロキシの具体的なユースケース
1. 広告用ランディングページ
2. 商品ページ・キャンペーンサイト
3. イベント・セミナーページ
4. メディア・ブログサイト
その他、リバースプロキシで実現できること
リバースプロキシのアーキテクチャと実装例
Cloudflareの例
セキュリティ面での留意事項
WAFの検討
最後に

そもそも「カスタムプロキシ」とは

カスタムプロキシ機能は「リバースプロキシ」サーバーからの転送をSTUDIOで許可する機能です。

リバースプロキシとは、クライアント（ブラウザ）とコンテンツサーバーの間に位置するサーバーで、クライアントからのリクエストを受け取り、オリジンのサーバーにそのリクエストを転送する役割を持ちます。

クライアントの代理としてのプロキシはインターネットに出るためのフィルタリングなどを行うのに対し、リバースプロキシはコンテンツサーバーの代理としてクライアントからのリクエストを受け取り、ロードバランシングやキャッシングによる負荷分散、セキュリティ性の向上、カスタム処理の実装など多岐にわたります。

リバースプロキシとして利用される代表的なサービスとしては、AWS CloudFront、Cloudflare、Nginx、Apacheなどがあり、企業のWebサイトにおいてパフォーマンス、セキュリティ、スケーラビリティを向上させるために活用されています。

カスタムプロキシの具体的なユースケース

カスタムプロキシ機能のユースケースとして、特に活用頻度の高い「既存のWebサイトのサブディレクトリのみSTUDIO化する運用」について詳しく解説します。

カスタムプロキシを利用することで、現在お使いのWebサイトはそのままに、一部サブディレクトリだけをSTUDIOで構築することが可能です。

具体的には、ランディングページやブログメディアなど更新頻度の高い一部のディレクトリのみをノーコード化し、エンジニアリソースなしで制作・運用を進めていきたいという企業様に多くご導入いただいております。

より活用イメージを掴んでいただくために、4つのユースケースを紹介します。

1. 広告用ランディングページ

「広告のコンバージョン率向上を目的としたランディングページ改善をマーケティング部門で完結させたい」というケースです。

現状はランディングページの改修に開発リソースが必要で、マーケティング担当者が施策を考えてから、実際にページに反映されるまでに約1~2ヶ月かかります。

そこで、 /lp というサブディレクトリだけをSTUDIOで制作し、ランディングページの細かな変更をマーケティング担当者が行える体制を構築、改善施策の実行回数が増加し、コンバージョン率向上に貢献できます。

2. 商品ページ・キャンペーンサイト

こちらのケースでは、自社でECサイトを構築・運用しており、同一ドメインでキャンペーンサイトやブランドサイトを実装する際に、些細な文言の修正・画像の変更のたびにエンジニアに依頼しなければならないという課題があります。

ECサイトを専用のサービスに乗り換える話はあがるものの、自社システムならではの要件を満たせず、頓挫してしまいます。ECサイトの機能要件を満たしつつ、広告やオーガニックで流入する集客目的のキャンペーンページの運用は機動力を担保する必要があります。

そこでSTUDIOのカスタムプロキシを活用し、自社システムは残しつつ非エンジニアが編集したいキャンペーンサイトやブランドサイトなどの一部サブディレクトリをSTUDIOでノーコード化、新商品や季節のセールに合わせたタイムリーなWebサイト運用を実現します。

3. イベント・セミナーページ

続いてはウェビナーやイベント、カンファレンスなどの特設ページ制作をマーケティング部門で内製化しているケースです。

元々イベントページの開発リソースがネックになっており、制作のリソースを考えると、企画・集客に割ける時間も制限されてしまいます。また、イベントページは既に権威性のあるドメインを持つサービスサイトの下層ページで作成する必要があります。

そこで、カスタムプロキシとCMS機能を活用して「セミナーのタイトル」「日時」「申し込みフォーム」などの必要な情報を入力するだけでページが完成する体制を作り、マーケティング部門で内製化。イベント施策をスピーディに推進できるようになります。

4. メディア・ブログサイト

最後にご紹介するのは、メディア・ブログサイトでの活用事例です。

自社のオウンドメディアで記事投稿や編集、ブログのデザイン修正が属人化しているという課題があります。また、記事投稿の画面もわかりづらく、記事を公開にも不必要な時間がかかっています。

STUDIO CMSに移行することで、よりスムーズに記事投稿やリライトを進められるようになります。また、カスタムプロキシを利用し/blogというサブディレクトリにSTUDIOを配置することで既存ドメインの評価をそのまま引き継ぎ、SEO対策や分析運用も継続できます。

このように、「誰でも簡単にWebサイトを制作・編集できる体制を構築したい。ただ、今のWebサイトをすべてノーコード化するのは難しい」という状況に対して、カスタムプロキシは効力を発揮します。

その他、リバースプロキシで実現できること

昨今はより自由度の高いWebプラットフォームの実装を求めることが多く、マイクロフロントエンドといった言葉も提唱されており、サブディレクトリごとに柔軟なホスティングを行うニーズは特に増えています。

Netlify社からの引用

1つ目は、フロントエンドソフトウェアの歴史を見て分かるとおり、フロントエンド領域の変化は激しい。それは、次の3要素が複合しているからだと推測する。
利用者側の要求変化
開発者側の要求変化
自由度の高いWebというプラットフォーム
モノリスなフロントエンドだと、技術の進化に追従することは困難だ。適切にアプリケーション設計（インタフェース設計）を維持しなければ、新たな技術を取り込むのにビックバンリリースをせざる得ない状況に陥る。 新たな技術を取り込むことは大切なことであり、それは外界の変化に追従しないといけないからだ。

ノーコードによるWeb制作との相性も良く、さまざまな可能性が考えられるでしょう。

加えて、企業によっては以下のようなニーズもあり、リバースプロキシが重宝されることがあります。

独自証明書の管理
特定URLに対するフィルタリング
301リダイレクトの一括管理
認証のカスタム実装

セキュリティの観点ではSTUDIOのセキュリティ対策として、常時SSL化や、WAFの導入で悪意あるスクリプト実行のブロックなど行なっており、標準的な構成でも外部攻撃からの保護は充分に担保されています。

負荷分散においても、標準でグローバルロードバランシングで冗長化がされているため、基本的には別途リバースプロキシを追加いただく必要はありません。

リバースプロキシのアーキテクチャと実装例

Cloudflareの例

では具体的にCloudflareでの実装と連携を見てみましょう。

あるドメインに対して/lpのランディングページと/blogのブログページのみをSTUDIOに向け、/storeのオンラインストアは別のサービスでホスティングするケースを想定します。リバースプロキシにはCloudflareを利用します。

従来の構成とリバースプロキシ構成の違いは以下のようになります。

Cloudflareのすべてのプランで利用可能なWorkersで、特定のパスにリクエストがあった場合に任意のSTUDIOサイトに振り分ける処理を実装をし、デプロイします。

ヘッダーにはSTUDIOプロジェクトで発行したx-studio-proxy-keyを付与します。

以下、Workerでの実装内容の簡単な解説です。

イベントリスナーの実装

Workerに対するすべての'fetch'イベント（受信リクエスト）をリッスンし、handleRequest関数で処理します。

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

リクエスト処理の実装

受信したリクエストを処理するメインとなる関数の実装です。まずリクエストのURLパスが/lpまたは/_nuxtで始まるかどうかをチェックします。/_nuxtはSTUDIOサイトのページレンダリングに必要なリソースファイルの取得のために転送します。そして、新しいリクエストを作成します。

async function handleRequest(request) {
  const url = new URL(request.url)

  // リクエストのパスが/lpまたは/_nuxtで開始するかをチェック
  if (url.pathname.startsWith('/lp') || url.pathname.startsWith('/_nuxt'))　　　　
  {

  // オリジンに転送する新しいリクエストを作成
   const newUrl = new URL(url.pathname,'https://samplesitefk.studio.site')
   newUrl.search = url.search

   const modifiedRequest = new Request(newUrl, {
     method: request.method,
     headers: request.headers,
     body: request.body
   })

リクエストの転送とレスポンスの取得

// オリジンへリクエストを転送
const response = await fetch(modifiedRequest)

// レスポンスを取得
    return new Response(response.body, {
      status: response.status,
      statusText: response.statusText,
      headers: response.headers
    })
  }

// /lpまたは/_nuxtで始まらないパスの場合、リクエストをそのまま透過
  return fetch(request)
}

トリガー設定でカスタムドメインの登録

任意のドメインへのアクセスで、デプロイしたWorkerがトリガーされるようにカスタムドメインを設定します。ここで登録するドメインはサイト訪問者が実際にアクセスするドメインになります。今回はCloudflare DNSで発行したドメインを利用します。