Hosting Modes は Website Builder の運用をどう変えるのか

Manus は 2026年6月24日、Website Builder の Hosting Modes を発表しました。プロジェクトに応じて Autoscale と dedicated always-on engine を切り替えるための機能です。

要点

• Hosting Modes は、Manus Website Builder でアプリの実行方式を選ぶための機能です。
• Autoscale は、トラフィックに応じてゼロから複数インスタンスへ伸縮する省コストな標準モードとして説明されています。
• 常時接続や継続処理が必要な場合は、always-on の専用エンジンを選ぶ文脈です。
• AIで作ったWebアプリを公開するチームは、サーバーの稼働方式、コスト、接続維持、運用責任を確認する必要があります。

今回のブログ記事で語られていること

今回の Manus Blog は、Website Builder で作ったプロジェクトのサーバー実行方式を選ぶ Hosting Modes を紹介しています。公式記事では、標準的なランディングページのようにアクセスがない時間は止まってもよいものと、ライブストリーミングダッシュボード、リアルタイムWebcam viewer、Discord bot のように常時接続やバックグラウンド処理が必要なものを分けています。従来は、こうした違いを扱うにはクラウド設定やデプロイパイプラインの調整が必要でしたが、Manus Website Builder ではモード切り替えで扱えるようにするという発表です。

Autoscale は、トラフィックに応じてゼロからスケールする省コストな既定モードとして読めます。アクセスが少ない時間にサーバーを止められるため、ランディングページ、キャンペーンページ、短期公開のプロトタイプ、低頻度の業務アプリには向いています。一方で、WebSocket、継続接続、定期処理、外部イベント待ち受け、ボットのような用途では、サーバーが眠ると機能しない場合があります。その場合、always-on の専用実行モードが必要になります。

この発表の実務的な意味は、AIでWebアプリを作る段階から運用方式を選ぶ必要が出てきた点です。Manus のようなエージェント型ツールでアプリを作ると、生成と公開は速くなります。しかし、公開後のサーバーがどのように動き、どのくらい費用がかかり、停止・再起動・接続切れがどう扱われるかを理解しないと、使えるはずの機能が本番で止まる可能性があります。

導入側は、プロジェクトごとにトラフィック特性、常時接続の必要性、コスト上限、監視、障害時対応を確認する必要があります。AIがWebアプリを作る時代でも、インフラの性質は消えません。Hosting Modes は、非エンジニアや少人数チームでも実行方式を選びやすくする機能ですが、選択を誤ると費用過多や機能停止につながります。今回の記事は、Manus Website Builder を実運用へ近づけるための更新です。

今回のブログ記事が関係する人

Manus Website Builder を使うプロダクト担当、ノーコード/AI開発チーム、Webアプリを短期間で公開する業務部門、社内ツール運用担当に関係します。

実務で確認したいポイント

• アプリがランディングページ型か、常時接続・継続処理型かを判定する。
• Autoscale と always-on の費用、起動時間、接続維持、制限を確認する。
• Discord bot、ライブ表示、Webhook 待ち受けなどは専用モードが必要か検証する。
• 公開後の監視、停止時対応、コストアラートを用意する。

結局、今回のブログ記事をどう読むべきか

Hosting Modes は、Manus Website Builder で作ったアプリを用途に合うサーバー実行方式へ切り替える機能です。利用チームは、AIで作れることだけでなく、公開後の稼働、費用、接続維持を確認する必要があります。