いつものAIと、
接続を進める。

プロジェクトを読めるAIに、下の依頼文を渡してください。公開先が分からなくても始められます。

このページはAIへの送信や設定変更を行いません。依頼文は手動でもコピーできます。AIの利用料はお使いの契約によります。

1. 公開先を調べてもらう

   AIが実際の構成を確認し、そのサービスの最新の公式手順を読みます。

2. 方法と費用を見て決める

   対応できるか、何を設定するか、追加料金があるかを確認。購入や設定変更は、その後です。

3. 設定して、サイトを試す

   ご自身でログインし、住所と接続先を設定します。最後に、新しい住所でログインやフォームも確認します。

住所を探す → · 取得済みの住所を設定する

GitHub Pagesにつなぐ

静的サイト向け。所有確認とHTTPSを実接続で確認済み。

商用SaaSやECのホスティング目的には利用制限があります。

1. サイトを公開する

   リポジトリの Settings → Pages で公開し、標準URLで表示を確認します。GitHub Freeではpublicリポジトリが必要です。

2. 住所の所有確認をする

   アカウント／組織の Settings → Pages に借りたホスト名を登録します。表示されたTXTの名前と値を、banchiのDNSの個別設定へ保存してから、GitHubで Verify を押します。

3. 双方に住所と接続先を登録する

   リポジトリの Pages → Custom domain に借りたホスト名を登録します。banchiでは「GitHub Pages」を選び、接続先に ユーザー名.github.io を入力。ユーザー／組織名と確認用TXTの値も入力して保存します。/リポジトリ名 は付けません。

4. HTTPSを有効にする

   GitHubの証明書発行を待ち、Enforce HTTPS を有効にします。確認用TXTは残したまま、新しい住所でサイトを試します。

ログイン・フォームなど、アプリ側の確認へ →

Cloudflare Pagesにつなぐ

別のCloudflareアカウントとの接続・HTTPSを確認済み。

1. Pagesで公開する

   プロジェクトの pages.dev のURLで、サイトやAPIが動くことを確認します。

2. Pagesに住所を登録する

   Custom domains → Set up a custom domain に借りたホスト名を追加します。Cloudflareに親ドメインの「サイト」を追加する操作ではありません。同じアカウントが親ゾーンも持つ場合は、DNS自動作成の確定前に確認し、banchiのDNSを直接上書きする画面なら止めてください。

3. banchiに接続先を保存する

   「Cloudflare Pages」を選び、Pagesが示すCNAMEの宛先を「接続先の値」に入力して保存します。必ず、前の手順でPagesへ住所を追加してから保存します。

4. HTTPSで確認する

   Pagesのドメインが有効になるまで待ち、banchiの「状態を調べる」を押します。新しい住所でフォームやAPIも試します。

ログイン・フォームなど、アプリ側の確認へ →

Vercelにつなぐ

接続・証明書発行・撤去を2026年9月7日に確認済み。

無料のHobbyは個人・非商用向けです。商用利用はプランをご確認ください。

1. Vercelに住所を登録する

   標準URLで動くプロジェクトの Settings → Domains に借りたホスト名を追加します。

2. CNAMEの値をコピーする

   Vercelが表示する、そのプロジェクト専用の接続先をコピーします。末尾の数字なども含め、値を省略しません。

3. banchiに保存する

   「Vercel」を選び、「接続先の値」に貼り付けて保存します。確認用TXTが求められた場合だけ、指定された値も入力します。

4. 証明書の発行を待つ

   VercelのHTTPSが有効になったら、banchiの「状態を調べる」を押します。新しい住所でサイト・ログイン・APIを確認します。

ログイン・フォームなど、アプリ側の確認へ →

Netlifyにつなぐ

接続・証明書発行・撤去を2026年9月7日に確認済み。

1. Netlifyに住所を登録する

   標準URLで動くサイトの Domain management から、借りたホスト名を追加します。

2. 外部DNSを選ぶ

   現在のDNSを使う方法を選びます。親の banchi.app をNetlifyへ移したり、NSを変更したりする必要はありません。

3. banchiにCNAMEを保存する

   「Netlify」を選び、案内された サイト名.netlify.app を「接続先の値」に貼り付けて保存します。

4. HTTPSを確認する

   NetlifyのHTTPS欄でDNS確認と証明書発行を確認します。その後、新しい住所でサイト・フォーム・APIを試します。

ログイン・フォームなど、アプリ側の確認へ →

自分のサーバー（VPS）につなぐ

2026-09-07にGCEのe2-micro＋Caddyで実測（証明書の自動発行・撤去まで確認）

必須：Web公開には、公開IPへ到達できること、ホスト名の受付設定、HTTPSが必要です。以下の通常構成では外部からTCP 80・443へ届くようにします。自宅回線でも条件を満たせば候補ですが、CGNAT・ルーター・ファイアウォール・回線規約を確認してください。グローバルIPv6があるだけでは接続できません。

1. Webサーバーの許可ホスト／virtual hostに、借りたホスト名を設定します。
2. banchiで「その他（CNAME / IPv4 / IPv6）」を選び、サーバーのIPv4またはIPv6アドレスを1つ「接続先の値」に貼ります。
   補足：両方使うときはDNSの個別設定でAレコードとAAAAレコードを並べます。
3. サーバーにCaddyなどのHTTPS終端を設定します。Caddyは通常、HTTP-01（80番）またはTLS-ALPN-01（443番）で所有を確認します。自動更新には常時稼働、書き込み可能で永続する証明書保存先、正しいDNSと到達性の維持が必要です。nginx＋Certbotでは、更新タイマーと更新後の証明書読み込みも確認します。
4. HTTPで所有確認できない場合などは、手動のDNS-01も選択肢です。ワイルドカード証明書以外にも使われますが、banchiにはDNS-01の自動更新機能はありません。ワイルドカードDNSも提供していません。

Caddy・nginx＋Certbotの設定例と確認コマンド（Markdown）

Let's Encryptのチャレンジ種別 · Caddyの自動HTTPS · certbotの手順

Cloudflare Workersにつなぐ

自分のPagesに入口を1つ追加して、既存Workerを使います。

アプリ・DB・定期処理はそのまま。banchiはDNSを提供し、通信はあなたのCloudflareアカウントで処理します。

元のURLだけにAccess等の保護を設定している場合は、公開前に認証の条件を確認してください。

1. 下の「接続用の2ファイル」に、借りた住所と既存Workerの名前を記入します。
2. Workerと同じアカウントに、新しいPagesプロジェクトとして配備します。
3. PagesのCustom domainsに住所を登録し、banchiのCloudflare Pages設定に、表示された本番のpages.dev宛先を保存します。
4. 証明書の有効化後、借りた住所でログイン・フォーム・画像などを確認します。

export default {
  fetch(request, env) {
    if (new URL(request.url).origin !== env.PUBLIC_ORIGIN) {
      return new Response('Not found', { status: 404 });
    }
    if (!env.APP) {
      return new Response('Service unavailable', {
        status: 503, headers: { 'Cache-Control': 'no-store' },
      });
    }
    return env.APP.fetch(request);
  },
};

{
  "name": "my-worker-entry",
  "pages_build_output_dir": "./dist",
  "compatibility_date": "2026-09-09",
  "vars": {},
  "services": [],
  "env": {
    "production": {
      "vars": { "PUBLIC_ORIGIN": "https://your-name.banchi.app" },
      "services": [{ "binding": "APP", "service": "existing-worker" }]
    },
    "preview": {
      "vars": { "PUBLIC_ORIGIN": "" },
      "services": []
    }
  }
}

cd pages-entry
wrangler pages project create my-worker-entry --production-branch main
wrangler pages deploy ./dist --project-name my-worker-entry --branch main

詳しい技術マニュアル（Markdown・8節） →

既存のURLへ転送する

すでに公開しているページへ案内する使い方です。DNSの入力や、転送先への借りたホスト名の登録は不要です。302（一時的な転送）で、ブラウザに表示されるURLは転送先へ変わります。

1. 住所を取得したアカウントでログインし、住所一覧から「住所の設定」を開きます。取得直後は使い方の選択が開きます。設定済みなら「使い方を変える」を押します。
2. 「ほかの URL へ転送する」を選び、「転送先の URL」へ動作する完全なURL（https://推奨）を入力して、「これにする」で保存します。ページのパスも入力できます。借りた住所自身は指定できません。
3. 借りた住所を開き、ブラウザの表示URLとページが意図した転送先になったことを確認します。入力した1つのURLへ転送するため、借りた住所に付けたパスやクエリは引き継ぎません。

DNS接続から切り替えると、その住所の接続レコード・配下の名前・所有確認TXT・CAAなどはすべて撤去対象になります。保存直後は削除処理やDNSキャッシュにより旧公開先へ届く場合があります。旧公開先のカスタムドメイン登録は、転送の動作と旧DNSの撤去・キャッシュ切れを確認してから解除してください。切替が進まない場合はお問い合わせください。

接続の4ステップ

1. 公開先で、サイトを動く状態にする

   ホスティング標準のURLでサイトが開くことを確認します。カスタムドメインが使えるプランかも見ておきます。公開先が求めるDNSレコードの種類も確認します。

2. 借りた住所を、公開先へ登録する

   banchiの「住所一覧」→「住所の設定」でホスト名をコピーします。公開先の「Custom domain／独自ドメイン」に貼ります。
   必須：https:// や末尾のパスは付けません。ホスト名全体を入力します。

3. banchiに、接続先の値を保存する

   使い方の選択で「自分のホスティングにつなぐ」を選びます。設定済みなら、先に「使い方を変える」を押します。公開先のプリセットを選び、値を「接続先の値」へ貼り、「この値でつなぐ」で保存します。
   必須：貼るのはCNAMEの宛先か、IPv4かIPv6を1つだけです。パスやポート番号は付けません。

   補足：複数のIP、追加の名前、Web用のTXT・CAAはDNSの個別設定を使います。

4. 待ってから「状態を調べる」を押す

   公開先の証明書発行を待ち、banchiで「状態を調べる」を押します。「接続済み」になったら新しい住所を開きます。
   待つ時間：公開先とDNSのキャッシュによります。／出る表示：診断の表示の見方で意味を確かめます。／次にやること：アプリの設定と確認へ進みます。

banchiの診断が見るのは、2系統のDNSと、rootへのHTTPS応答（200〜399）までです。ログインの成功、投稿の完了、決済の成功は確認しません。

DNSを個別に設定する

住所の設定で「DNSレコードを直接編集」を開き、公開先が指定した「種類・名前・値」を入力します。ここでは借りた住所を your-name.banchi.app とします。

名前の書き方

借りた住所そのもの（root）

rootとは、借りた住所そのものです。@ または your-name.banchi.app と入力します。

その配下の名前

www.your-name.banchi.app のように完全なホスト名を入力します。api.dev.your-name.banchi.app、_verify.your-name.banchi.app も同じです。
必須：www だけの相対名は使えません。他の利用者の住所と *.your-name.banchi.app も指定できません。

レコードの種類

A・AAAA

公開先のIPv4・IPv6を指定します。同じ名前に複数のIPも置けます。ローカル専用IPと予約済みの一部アドレスは対象外です。

CNAME

CNAMEとは、別名の指し先です。公開先の完全なホスト名を指定します。
必須：同じ名前に別のレコードは置けません。rootのCNAMEとrootのTXTは共存できません。公開先が別名の確認用TXTを指定した場合だけ、その指定に従います。必須の名前が衝突する場合は、名前を変えず運営へご相談ください。

TXT

Webサービスの所有確認などに使います。証明書の所有確認用TXT（DNS-01。下で説明します）も手動で入力できます。自動更新の機能は付いていません。メール用のSPF・DKIM・DMARCは対象外です。

CAA

公開先が指定する、証明書発行者（認証局）の設定です。例は 0 issue "letsencrypt.org" です。
必須：実際に使う認証局と一致させます。値を誤ると、証明書の発行・更新が止まることがあります。

件数と、先に保存できるもの

必須：レコードは1住所あたり標準5件までです。確認用TXT、CAA、banchiの案内用レコードも件数に数えます。rootのA・AAAA・CNAMEを指定しない間は案内用rootが1件入るため、自分で使えるのは残り4件です。

案内用レコードとは、rootの公開先が未指定のあいだbanchiが自動で補うレコードです。あとからrootを指定すると自動で入れ替わります。手で編集する必要はありません。

所有確認TXTだけを先に保存し、あとで公開先を設定できます。配下のWebサイトだけを使うこともできます。ただしHTTPS診断の対象はrootです。追加した名前ごとに、登録・証明書・動作をご自身で確認してください。

診断の表示の見方

アプリ側の設定と、公開前の動作確認

URLが変わると見直す設定があります。該当するものだけ確認してください。独自ドメインを変えるときにも必要な作業です。

ページ・画像・API

新しい住所のトップと下層ページを直接開き、再読み込みします。画像・CSS・APIが旧URLやHTTPを参照していないか確認します。

ログイン

認証サービスの許可URLと、OAuthの戻り先（callback URL）を新しい住所へ更新します。ログイン→再読み込み→ログアウトを試します。パスまで一致させる必要があるサービスもあります。

投稿・フォーム・別ホストのAPI

接続先アプリの許可Origin（アクセス元として許すサイト）・CORS・CSRF（別サイトからの偽の送信を防ぐ仕組み）へ、必要な新しいURLだけを登録します。実際に送信し、保存結果まで確認します。
必須：CORSを一律に解除する方法は使いません。

人間確認（Turnstileなど）

ウィジェットの所有者が、借りたホスト名を許可対象に追加します。Turnstileでは https:// やパスを付けません。追加後、新しい住所のフォームで確認します。
必須：banchi.app 全体の許可は、他の利用者も含むため避けてください。

Cookie・セッション

CookieのDomain属性を省略し、自分のホストに限定します。親の banchi.app は指定しません。__Host- で始まるCookieはそのホスト専用の印で、Secure; Path=/ を付け、Domain属性は付けません。
必須：SameSiteだけに頼らず、操作元を検証します。ブラウザは banchi.app 配下をまとめて「同じサイト」と扱うことがあるためです。

アプリ内の決済

接続先アプリが決済を使う場合は、成功・キャンセル・管理画面からの戻り先URLを更新します。Webhookも移す場合は送信先と署名検証を確認し、テスト環境で成功・中断・重複通知を試します。banchiの住所代の支払いとは別の設定です。詳細な確認項目（Markdown）

WebSocket・動画・ファイル

使っている場合は、新しい住所で接続・切断・再接続、再生、部分読み込みを確認します。DNSの成功だけでは動作を保証しません。

HTTPS・ブラウザ

証明書警告が出ないこと、スマートフォンでの表示、重要な操作後の再読み込みを確認します。
必須：証明書警告を無視したまま、公開完了にしないでください。

Turnstileの許可ホスト · CORS · Cookieの範囲

うまく動かないとき

解決しない場合は不具合報告フォームへ。ホスト名、公開先サービス、発生日時、操作、診断コードを記載してください。GitHubアカウントは不要で、内容は非公開で扱います。パスワード、秘密鍵、Cookie、ログイン用リンクは送らないでください。

使えるDNSと、独自ドメインとの違い

できること

借りたホスト名と、その配下の複数階層に、A・AAAA・CNAME・Web用TXT・CAAを設定できます。件数は標準5件までです。

できないこと

MX・SPF・DKIM・DMARCなどのメール設定、NS委任、ワイルドカード、他の利用者の住所への設定です。サブドメインの仕組み上の禁止ではなく、現在のbanchiの提供範囲です。

所有権と継続利用

お渡しするのは、契約期間中のサブドメイン利用権です。親ドメインの所有権は付きません。同じ名前を他のレジストラへ移管することもできません。

証明書・ブラウザの境界

証明書の発行上限と、ブラウザが「同じサイト」と見る範囲は、親ドメインで共有する場合があります。親ドメインのDNS・契約・評判による影響も共有され得ます。親全体のCookieや認証許可は使わず、借りたホスト単位で設定してください。

通信費と防御

サイト配信費とアクセスへの対処は、公開先の契約・設定に従います。banchiの料金に、サーバー利用料や公開先の無制限な通信・攻撃対策は含みません。

接続先の変更・更新停止・利用終了

接続先を変えるとき

先に新しい公開先へホスト名を登録し、そのあとbanchiの接続先を変更して確認します。切替中は古い接続先へ届く場合があります。旧公開先の削除は、切替を確認してから行ってください。

料金と自動更新

料金は1住所ごとに年額500円（税込）です。同じメールで複数の住所を持て、契約と更新日は住所ごとに独立します。「自動更新の停止へ」で対象住所の契約を確認し、Stripeで停止を確定します。支払い済みの期間までは利用できます。販売は日本国内の方向けです。

利用を終えるとき

必須：先にbanchiで「接続をやめてパークに戻す」を選びます。パークとは、取得したことを示す案内ページの状態です。公開先の登録だけ先に消さないでください。DNSが残る間に、第三者がその公開先で住所を登録できる場合があります。

1. banchiで「接続をやめてパークに戻す」を選び、接続DNSとTXTの削除・反映を確認します。
2. 公開先のCustom domain、認証サービスの許可URL、Turnstileの許可ホストを解除します。
3. GitHubのアカウント／組織にある Verified domains の所有確認登録も、別途解除します。

解除できない場合や、banchi側で編集できないときは、運営へ連絡してください。再開のご相談も受け付けます。

利用期間・解放までの詳細は利用規約へ

このマニュアルで確認した範囲

• GitHub Pages：2026年9月6日、通常のbanchi画面から取得・DNS設定し、所有確認、HTTPS強制、つなぎ帳の検索・保存・共有・ファイル出力を実ブラウザで確認。
• Cloudflare Pages：2026年9月5日、別アカウントへのDNS-only CNAME・HTTPSを実測。試験用の接続は検証後に撤去済み。
• Vercel：2026年9月7日、実際のVercelプロジェクトで接続保存・DNS診断・証明書発行・撤去までを実ブラウザで確認。
• Netlify：2026年9月7日、実際のNetlifyサイトで接続保存・DNS診断・証明書発行・撤去までを確認。
• 自分のサーバー（VPS）：2026年9月7日、GCEのe2-micro＋Caddy（HTTP-01）で接続保存・DNS診断・証明書発行・撤去までを確認。
• Firebase Hosting：2026年9月10日、実際のFirebaseプロジェクト（Spark無料プラン）で接続保存・証明書発行・「接続済み」・撤去までを確認。
• Google Cloud Run：2026年9月10日、実際のCloud Run UIで直接のDomain mappingを試し、親ドメインのSearch Console確認が必須という制約を実機で確認。banchi.appはこの確認対象にできないため、直接接続は使えません。Firebase Hosting経由（Blaze必須）は未確認のままです。
• Vercel・Netlify・自分のサーバー・Firebase Hostingの4件は、いずれも接続先アプリ本体の動作を別途確認する必要があります。
• 未実証の範囲：到達可能なIPv6サーバーへのHTTPS通し接続、A＋AAAAの二重構成、手動DNS-01の発行・更新、nginx＋Certbotの通し接続、個々のWorker／R2アプリのPages移行、AWS Amplify・Azure Static Web Apps・Heroku・DigitalOcean App Platformの実接続（利用者自身のアカウントが必要）は未実証です。掲載する設定例は公式資料に基づく導入例です。既存Caddy試験で証明書の更新時期まで待つ長期試験はしていません。

公開先の仕様は変わることがあります。画面の指示がこの手順と違う場合は、公開先の公式案内と必要なDNSの種類を確認し、不明点を運営へお知らせください。

公開先は、State of JavaScript 2025 のホスティング利用経験上位10社をもとに選んでいます（10,704人、複数回答）。世界の個人開発者だけの利用シェアではありません。AWSなどは具体的なサービスへ分け、CloudflareはPagesとWorkersの2方式を案内します。Stack Overflow 2025も補助資料として照合しました。選定元の調査 · 補助調査

AWS Amplify Hosting

アプリの準備から詳しく読む

条件付き・banchiでの実接続は未確認。ビルド・配信などは従量料金です。借りた範囲外の確認レコードやNS変更を求められたら、保存せずに止めてください。実接続の試験には利用者ご自身のAWSアカウントが必要で、2026年9月10日の点検では新規アカウント作成・新規課金は行っていません。

1. Amplifyで公開するリポジトリ・ブランチを選び、ビルドコマンドと出力先を確認して配備します。SSRは対応フレームワークの構成が必要です。標準URLで表示・APIを確認します。
2. Hosting → Custom domains → Add domainで、借りたホスト名（例 your-name.banchi.app）を「domain」欄に入力し、Manual configurationへ進みます。
   必須：Amplifyは既定で「www.を付けた名前」も自動追加し、そこへ転送する設定にします。Rewrites and redirectsで不要な方を外すか、追加のwww名をbanchiの5件枠内で受け入れるか、先に決めてください。banchi.app全体は登録しないでください。
3. View DNS recordsの証明書確認用CNAMEと配信用CNAMEを確認します。すべて借りた名前かその配下で、合計5件以内なら、banchiのDNSの個別設定へ保存します。必須：証明書確認用CNAMEは、ドメイン追加の直後に保存してください。時間が経つとAmplifyの確認頻度が下がり、保留状態のまま止まることがあります。
4. Amplifyのドメインと証明書が正常になったら、借りた住所で表示・ログイン・APIを確認します。確認用CNAMEは、証明書の更新のため残します。

Firebase Hosting

アプリの準備から詳しく読む

2026年9月10日に実測。実際のFirebaseプロジェクト（Spark無料プラン）で接続保存から証明書発行・「接続済み」・撤去までを確認しました。表示はクイック セットアップの手順です。親のbanchi.appをTXTで確認するよう求められた場合は利用できません。App Hostingや動的API連携は、Hostingの無料枠と料金条件が異なります。

1. Firebase Hostingを設定し、firebase.jsonのhosting.publicをビルド済み静的ファイルの出力先に合わせて配備します。標準URLで確認します。動的APIは別の実行環境が必要で、「App Hosting」も別サービスです。
2. Hostingのカスタム ドメインを追加に借りたホスト名を入力し、クイック セットアップを選びます。表示される1本のCNAME（サイト名.web.app宛）を控えます。TXTでの所有確認は求められませんでした。旧来のA/AAAA方式が必要な場合は「詳細指定」タブに切り替えます。
3. banchiで「その他（CNAME / IPv4 / IPv6）」を選び、控えたCNAMEを接続先の値に保存します。
4. Firebaseの証明書発行を待ちます（実測では保存から約9分半）。Connectedと証明書を確認し、借りた住所で表示・ログイン・APIを試します。認証を使う場合は、借りたホスト名を許可する設定も確認します。

Azure Static Web Apps

アプリの準備から詳しく読む

公式手順を確認済み・banchiでの実接続は未確認。Freeは個人向けでカスタムドメイン2件までです。認証機能や既存APIとの連携によっては有料プランが必要です。実接続の試験には利用者ご自身のAzureアカウントが必要で、2026年9月10日の点検では新規アカウント作成は行っていません。

1. Static Web Appsでリポジトリとブランチを選び、アプリ・APIのソース場所とビルド出力先を設定して配備します。標準のazurestaticapps.netで確認します。統合APIは/api配下、45秒以内で、WebSocketは使えません。
2. そのアプリの標準ホスト名を、banchiのDNSの個別設定でrootのCNAMEへ保存します。
3. AzureのSettings → Custom domains → Add → Custom domain on other DNSで借りたホスト名を入力し、CNAMEで検証します。TXTを求められたら、指定された名前が借りた範囲内か確認して追加します。
4. 検証と自動HTTPSが正常になったら、借りた住所で表示・ログイン・APIを確認します。

Heroku

アプリの準備から詳しく読む

公式手順を確認済み・banchiでの実接続は未確認。アプリの実行環境は有料です。Ecoは月5米ドルで、休止などの制限があります。実接続の試験には利用者ご自身のHerokuアカウント（有料プラン契約）が必要で、2026年9月10日の点検では新規アカウント作成・新規課金は行っていません。

1. Herokuでwebプロセスの起動コマンドを設定し、環境変数PORTで待ち受けるアプリを配備します。標準URLとドメイン追加に必要なアカウント確認・料金条件を確認します。
2. アプリのSettings → Domains and certificatesに借りたホスト名を追加します。
3. 表示されたDNS Targetの…herokudns.comを、banchiのDNSの個別設定でrootのCNAMEへ保存します。herokuapp.comのURLではありません。
4. Automated Certificate Management（ACM）を有効にし、証明書が正常になったら、借りた住所で表示・ログイン・APIを確認します。

DigitalOcean App Platform

アプリの準備から詳しく読む

条件付き・banchiでの実接続は未確認。App PlatformはDNSSECが有効なドメインに非対応です。購入前に条件をご相談ください。静的サイトの無料枠と、動的アプリ・転送の料金は別です。実接続の試験には利用者ご自身のDigitalOceanアカウントが必要で、2026年9月10日の点検では新規アカウント作成は行っていません。

1. App Platformで静的サイトはStatic Site、APIは有料のWeb Serviceを選び、ビルド出力先または起動コマンド・HTTPポートを設定します。標準URLで確認し、借りる住所がDNSSECの条件を満たすか確認します。
2. Networking → Domains → Add domainに借りたホスト名を入力し、You manage your domainを選びます。
3. 表示された…ondigitalocean.appのCNAMEを、banchiのDNSの個別設定でrootへ保存し、DigitalOceanでAdd domainを完了します。
4. ドメインと証明書が正常になったら、借りた住所で表示・ログイン・APIを確認します。

Google Cloud Run

アプリの準備から詳しく読む

条件付き・banchiでの実接続は未確認（直接のDomain mapping制約は実機で確認済み）。2026年9月10日、実際のCloud Run UIで「ドメイン マッピングを追加」を試したところ、確認済みドメインの選択肢はこのGoogleアカウントでSearch Console「ドメイン」プロパティとして確認済みのドメインに限られ、banchi.appはその対象になっておらず選べませんでした（ドキュメント上の記載ではなく、実操作での確認です）。下のFirebase Hosting経由の接続はこの試験では確認しておらず、Blazeが必要で60秒の制限とCookieの制限があります。購入・有料構成の追加前にご相談ください。

1. Cloud Runのサービスを、0.0.0.0と環境変数PORTで待ち受ける構成で配備し、標準URLで確認します。同じプロジェクトのCloud Billing・Blazeの料金条件も確認します。Hosting経由では__session以外のCookieが通常転送されないため、ログイン方式を先に確認します。
2. Firebase Hostingを初期設定し、firebase.jsonのhosting.rewritesに公開対象パスとCloud RunのserviceId・regionを設定します。公開範囲とアプリ自身の認証を維持してください。
3. Hostingを配備し、標準のweb.app等のURLでページ・API・ログインを確認します。60秒を超えるリクエストには、この経路を使えません。
4. Firebase Hostingの手順で借りたホスト名を登録し、指定された確認・接続DNSをbanchiへ保存します。親のbanchi.appのTXTを要求されたら止めます。
5. 証明書が正常になったら、借りた住所で表示・ログイン・API・保存を再確認します。