WebツールやWebサービスを複数開発・運用する際、それぞれを別々のサブドメイン(tool1.example.com など)で公開すると、Google AdSenseのサイト審査やSEO評価が分散してしまうという問題が生じます。
これを防ぎ、単一ドメイン配下のサブディレクトリ(/tools/tool1/、/tools/tool2/)として複数の独立したフロントエンド資産をエッジ上で統合する最適なアプローチが、**Cloudflare Workers の「Static Assets」と「Service Bindings(サービスバインディング)」**の組み合わせです。
1. システム・インフラアーキテクチャ概要
インターネットを経由したプロキシ転送(HTTP Fetch)とは異なり、CloudflareのService Bindingsは同一エッジデータセンター内のメモリ間プロセス間通信で動作します。
ユーザーアクセス (example.com)
│
▼
[メインHP Worker] (ポータル本体 / Workers Static Assets)
│
├── /tools/tool1/* ──▶ [ツール1 Worker] (Service Binding / レイテンシ0ms)
├── /tools/tool2/* ──▶ [ツール2 Worker] (Service Binding / レイテンシ0ms)
└── その他のパス ──▶ 自身の静的HTML・CSS(トップ、固定ページ等)を返却
このアーキテクチャにより、以下の恩恵が得られます:
- 外部からは単一Webポータルとして認識: AdSense審査やドメインオーソリティが1箇所に集約。
- オーバーヘッドがほぼゼロ: 追加のSSLハンドシェイクやネットワーク遅延が一切発生しない。
- 独立リポジトリ・独立ビルド: 各ツールの開発・デプロイが互いに干渉しない。
2. 親Worker(メインHP)のルーティング実装
メインポータル側の src/index.js(または TypeScript)では、リクエストURLのパスプレフィックスを判定して各子Workerへ処理を委譲します。
export default {
async fetch(request, env) {
const url = new URL(request.url);
// /tools/tool1 へのリクエストはツール1 Workerへ委譲
if (url.pathname.startsWith('/tools/tool1')) {
return env.TOOL1_SERVICE.fetch(request);
}
// /tools/tool2 へのリクエストはツール2 Workerへ委譲
if (url.pathname.startsWith('/tools/tool2')) {
return env.TOOL2_SERVICE.fetch(request);
}
// それ以外はメインHPの静的アセット(HTML/CSS/JS)を返却
return env.ASSETS.fetch(request);
}
};
3. wrangler.jsonc の設定例
親Workerの設定ファイルでは、子Workerをサービスバインディングとして定義します。
{
"name": "main-portal-worker",
"main": "src/index.js",
"compatibility_date": "2026-10-01",
"assets": {
"directory": "./dist",
"binding": "ASSETS"
},
"services": [
{ "binding": "TOOL1_SERVICE", "service": "tool1-worker" },
{ "binding": "TOOL2_SERVICE", "service": "tool2-worker" }
]
}
各ツール側(子Worker)は、自らのビルド出力ディレクトリ(dist)を assets.directory に設定するだけで、親Worker経由で自動的に高速配信されます。
4. まとめ
Cloudflare Workers と Service Bindings を活用した構成は、個人開発者が複数のWebツールを低コスト・高パフォーマンス・SEO集約型で展開するための最強のインフラパターンです。今後のWebツール展開の基盤としてぜひ活用してみてください。