GUIDE

個人で複数の Web ツールを運営する設計 — サブドメイン構成と運用

公開: 2026年4月 / 最終更新: 2026年5月

1 人の開発者が複数の Web ツールを運営するとき、ドメイン・デプロイ・運用の 設計を最初に決めておくと、ツールが増えるごとの追加コストを大きく下げられます。 本記事は、本サイト（ads-to-x402.com）が実際に採用している構成の 考え方を整理したものです。

1. 共通する課題

個人運営で複数のツールを公開すると、おおむね次のような共通課題が発生します。

• 独立性の担保: ツール A の障害がツール B に波及しないこと
• 共通要素の重複: プライバシーポリシー、お問い合わせ、 運営者情報などをツールごとに書くのは非合理
• SEO とブランディング: ユーザーから見て「同じ運営者の信頼できるサービス群」と認識されたい
• 広告・収益化: AdSense 等の審査単位を ドメインで揃えると後続の追加が楽になる

2. ドメイン分割の選択肢

単一ドメインで複数ツールを束ねる場合、選択肢は大きく 3 つあります。

(A) サブドメイン分割

例: app1.example.com, app2.example.com

• 各ツールを独立リポジトリ・独立デプロイにできる
• SSL・DNS は親ドメイン側で一元管理
• AdSense は親ドメイン承認で配下サブドメインに自動展開
• 一方、Cookie・認証は 意図的に共有しない限り別ドメイン扱い（厳密には Public Suffix の挙動を確認）

(B) サブディレクトリ分割

例: example.com/app1, example.com/app2

• SEO 上の評価を 1 ドメインに集約しやすい
• 1 つのデプロイ環境で全ツールを賄うので、リバースプロキシ等の ルーティング設計が必要
• 1 ツールの障害が同一ホストのほかツールに波及しやすい

(C) 完全分離（独立ドメイン）

例: app1.com, app2.com

• ブランドが完全独立、相互の影響ゼロ
• ドメイン費用・SSL 管理がツールの数だけ発生
• 運営者単位のブランディング（複数ツールを束ねる）が難しい

3. 本サイトが採用している構成

ads-to-x402.com は (A) のサブドメイン分割を選択しています。 理由は次のとおりです。

• 独立デプロイができる: ツールごとに別リポジトリ・別 Vercel プロジェクトに分けることで、片方をデプロイし直しても他方は無影響
• 共通要素を apex に集約できる: プライバシーポリシー・ 運営者情報・お問い合わせを apex に一本化し、各サブドメインからリンクで参照
• AdSense の審査単位が一致する: 親ドメインで承認されれば、 配下サブドメインを管理画面で追加するだけで広告配信が始められる
• 追加コストが小さい: 新ツールを足すたびに必要なのは DNS のサブドメイン 1 行と、デプロイ先（Vercel 等）の 1 プロジェクトだけ

現状のドメインマッピングは次のようになっています。

4. ハブとサブドメインの役割分担

複数ツールを束ねるハブサイトを apex に置く場合、「ハブが何を提供するか」を明確にしないと、 ただのリンク集になりがちです。本サイトでは次のように役割を分けています。

• サブドメイン: 動くもの（ツール、アプリ）。 機能 UI・状態保持・実際の処理を担う
• apex（ハブ）: 読むもの（解説、ガイド、運営情報）。 ツールの背景・前提知識・運営方針を文章で提供

この分け方には実務上のメリットがあります。サブドメインのツール改修と 解説記事の更新が独立して進められる、解説記事を増やしてもツール側の コードが膨らまない、apex 側のコンテンツ追加だけで AdSense の審査基準を 満たしやすくなる、などです。

5. 運用の最小構成

このパターンを始める場合の最小構成は、おおむね次のとおりです。

1. ドメイン取得 (1〜2,000 円/年程度)。 一般的なレジストラから、サブドメインが自由に切れる TLD を選ぶ
2. DNS の一元管理。Cloudflare 等の DNS 専門サービスに ネームサーバを移管し、サブドメインの追加削除はここで完結させる
3. デプロイ先の選択。Vercel・Cloudflare Pages・Netlify など、 無料枠でも十分なホスティングを 1 つ選ぶ
4. 共通テンプレート。プライバシーポリシー・お問い合わせ・ 運営者情報の文面をテンプレ化し、新ツール追加時にコピーで済むように
5. 監視。各ツールに /api/health 等の 軽量エンドポイントを置き、外部監視サービスで定期チェック

6. 共通要素のテンプレート化

サブドメインを増やすときに毎回手で書きたくない共通要素は、次のあたりです。

• プライバシーポリシー（広告配信・Cookie・アフィリエイトの記載）
• 運営者情報・お問い合わせ窓口
• フッターのリンク群（ハブ apex への戻り、ポリシーへの参照）
• OGP・JSON-LD の基本テンプレート

本サイトでは、上記をハブ apex に集約しつつ、各サブドメイン側のフッターから ハブの該当ページにリンクする形で運用しています。 これにより、ポリシー文面の更新が必要になったときに 1 箇所だけ直せば、 ユーザーから見た一貫性が保たれます。

7. AdSense 審査の観点

AdSense の審査は、申請したドメイン単位で行われます。 サブドメインごとに別申請するのは可能ですが、 ハブ apex で一括承認を取ったうえで、配下サブドメインを 管理画面に追加する流れの方が、各ツール側の作業が少なくなります。

ハブ apex を申請する場合、ハブそのものに 独立した読み物としての価値が必要です。単なるサブドメインへの導線リスト（リンク集）だけだと 「Low value content」で不承認になる例が多く、本サイトの本記事を含む 解説・ガイド・運営情報が、その対策の一例です。

8. 失敗しやすいポイント

• Cookie の取り扱いをドメイン全体で揃えていない: サブドメインごとにポリシーの内容がずれると、レビューや問い合わせ対応で 手戻りが発生する
• ハブが空っぽ: サブドメインに飛ばすだけのリンク集にすると、 ユーザー体験・SEO・AdSense のすべてで評価が下がる
• SSL/DNS の二重管理: DNS 設定をレジストラ側と ホスティング側で分けると、トラブル対応が複雑化する。 DNS は 1 箇所に寄せるのが原則

関連リンク

• 運営者情報
• Mock L&R の解説
• Keiba Calculator の解説