候補は2つ。画面上で自由に編集できる「Studio」と、 決まった入力画面に書き込むだけの「入力画面方式」（新構成）。 どちらも9館のサイトは作れます。違いが出るのは作った後 ── 季節ごとの入れ替えを、9館ぶん、ずっと回し続けるときです。
対象は以下の9サイト（合計約110ページ）。現在はすべて、更新のたびに制作会社へ依頼する作りです。
管理の大変さの正体は、同じ種類の更新が9館ぶん、季節のたびに発生することです。 プランの入れ替え、料理と季節写真の差し替え、お知らせ、料金や期間の変更 ── 1館なら小さな作業でも、9館では毎回9倍になります。 この「9倍」をどう扱うかが、2つの方式の分かれ目です。
Studioは「独立した9軒の家」。入力画面方式は「共通の骨組みを持つ長屋」です。
図1 ｜「予約ボタンを目立たせたい」「全館のトップに連休の帯を出したい」── こういう修正のたびに効いてくる差です。
実際の宿の名前で。左がStudio、右が入力画面方式です。
判定: できる（権限設定が前提）
判定: できる（仕組み上壊れない）
判定: 9回作業（CMS部分のみ予約可）
判定: 仕込み次第で作業ゼロ
判定: 作業×9
判定: 作業×1＋自動終了
判定: 自分たちで完結
判定: 制作側に依頼
判定: 引き継ぎは操作教育しだい
判定: 日常は軽いが制作側依存が残る
2026年7月17日時点の公式料金にもとづく試算。ドメイン（住所）代は両案とも別途年1〜2万円程度／9館。
| 項目 | Studio | 入力画面方式 |
|---|---|---|
| 月額（9館） | 10,710円Personal 1,190円 × 9館（年払い時） | 0円入力画面・公開の仕組みとも無料枠で運用可 |
| 年額（9館） | 約128,500円10年で約130万円 | 0円かかるのはドメイン代のみ |
| 初期の作り込み | 人手での組み立てが中心1館の型づくり後は複製で短縮可 | 制作側がまとめて構築みささの試作は公開済み・費用実証済み |
| デザイン変更費 | 0円（自分たちで変更） | 制作側に依頼依頼の取り決め（保守）が必要 |
徹底的に比べた結果、優劣は「使い方」で決まります。以下の質問に答えるだけで結論が出ます。
QUESTION
季節ごとに変えたいのは ──
(a) 写真・プラン・お知らせ・料金ですか？
(b) ページのデザインや構成そのものですか？
補足を2つ。①Studioの「スタッフが触るとデザインが壊れる」不安は、ライター権限（記事管理だけ触れる設定）でかなり防げます。 これは公平に伝えておきたい点です。②それでも構造上変わらないのは、「9館横断の一括修正ができない」こと。 共通の帯・ボタン・導線を直すたびに9回作業が発生する点は、プランを上げても解消しません。
グループの実態（プラン・写真・お知らせが季節で回る／デザインの骨格は各館で固定）が（a）に近いなら入力画面方式、 各館が見た目づくりまで自走したいなら（b）でStudio、という判断になります。
ここから先は技術詳細。どこに何が置かれ、やめたくなったとき何を持ち出せるか。
図3 ｜ 一体型（密結合）と部品型（疎結合）。10年運用を考えると「出口があるか」は費用と同じくらい効く。
システム面の本質はこの図に尽きます。Studioは編集・CMS・配信が1社に密結合していて快適な代わりに、 サイトの書き出し機能がなく、やめる判断=全損です。入力画面方式は3層が分離していて、 各層が標準的な形式（Gitのコード・JSONのデータ・静的ファイル）なので、どの部品も後から交換できます。 microCMSの無料枠が渋くなったら別のCMSへ、Cloudflareが嫌になったら別のホスティングへ、が現実的に可能です。
移行の実務で詰まりやすい3点。予約は問題なし、勝負は「旧URLの引き継ぎ」。
図4 ｜ URL引き継ぎの実務。ここを雑にやると9館の検索順位を同時に落とす。
| 項目 | Studio | 入力画面方式 |
|---|---|---|
| 独自ドメイン接続 | プロジェクト設定でCNAMEを9館ぶん登録。SSL自動有料プラン必須（Mini以上） | Pagesプロジェクトに9館ぶん登録。SSL自動CloudflareへDNSごと移すとドメイン管理も一元化・原価に |
| 旧URLの301 | 1件ずつリダイレクトページ作成（一括不可）約110本を人手で。.html付きパスは要検証 | _redirectsファイルで一括スクレイプ台帳から自動生成可能 |
| 予約（489ban） | 両案とも影響なし ── 全館「外部リンク」なのでボタンのURL設定だけ（9館ぶんのclient ID一覧は取得済み） | |
| 予約カレンダー埋め込み・GTM等の計測タグ | カスタムコード=上位プラン限定Personalでは不可の機能あり。要プラン確認 | 制約なし現行サイトのGTM設定をそのまま移設可 |
| 英語ページ | ページ複製で作る（更新は日英二重管理）awa-ippeで実際に起きている運用 | 型に英語1ページを組み込み現行/en/は簡易1ページと判明済みなので負荷小 |
今回の案件で実際に計測した数字。見積もりではなく実測ベース。
図5 ｜ 実測: Astro側=みささ試作（スクレイプ30分・構築1日・修正の再公開2〜3分）／Studio側=Cowork検証（2026-07-17）。
| フェーズ | Studio | 入力画面方式 |
|---|---|---|
| 初期構築（1館目の型） | AI委任率 約4割ドラッグ&ドロップ不可・画像アップ1枚制限・要素選択が不安定（Cowork実測）。型づくりは人間が速い | AI委任率 ほぼ10割スクレイプ→実装→公開まで全自動。実証済み |
| 2館目以降の複製 | AI委任率 約7割プロジェクト複製後の文言・画像URL・リンク差し替えはCoworkが安定。検収は人間 | AI委任率 10割フォルダー複製+台帳流し込み。人間は最終確認のみ |
| 修正1回の所要（例: ロゴ崩れ） | Coworkで数十分〜／人間で数分GUI操作のラウンドトリップが遅い | 2〜3分で本番反映実測: 修正→ビルド0.6秒→デプロイ→公開 |
| デザイン変更 | 人間がGUIで自由に（AIは苦手） | AIがコードで対応（人間は指示だけ）ただし「制作側に頼む」体制が前提 |
なぜこの差が出るか。コードはテキストなのでAIの母語ですが、GUIは「画面を見る→クリックする→結果を見る」の遅いループで、 しかもStudioエディターはドラッグ&ドロップ必須の操作が多く、そこがAIには物理的に苦手です（Cowork検証で確認済み）。 つまり「AIに任せて放置したい」なら入力画面方式、「人間がGUIで作りたい」ならStudio、と工数の観点でも同じ結論に収束します。
「触れる広さ」はStudio、「触って安全」は入力画面方式。レイヤーごとに見るとこうなります。
| サイトの層 | Studio | 入力画面方式 |
|---|---|---|
| ① プラン・お知らせ・客室情報季節ごとに回る「中身」 | 触れる（ライター権限で安全化可能）CMS化した範囲のみ。設計しだい | 触れる（入力画面のみ・壊せない）スマホ可・予約公開/自動失効つき |
| ② 固定ページの文言・写真温泉の紹介文、館の物語など | 触れる（ただしデザイン権限が必要）=レイアウトを壊せる状態で触ることになる | 触れない（制作側が対応）更新頻度が低い層なので依頼ベースで十分 |
| ③ レイアウト・デザイン | 触れる（Studioの存在意義） | 触れない（制作側=AIが対応） |
| ④ サイト構造・ドメイン・リダイレクト | 管理画面から可能（オーナー権限） | 制作側が対応 |
注意点はStudioの②です。ライター権限で守れるのはCMSに載せた中身だけで、 固定ページの文言や季節写真を旅館スタッフに直させるなら、結局デザインまで触れる権限を渡すことになります。 「非エンジニアが広く触れる」は「非エンジニアが壊せる」と表裏一体 ── この矛盾を権限設計でどこまで抑えられるかが、Studio運用の設計ポイントです。
入力画面方式を選んだ場合にだけ載せられる拡張。依頼→AI編集→承認→自動反映のループ。
図6 ｜ 依頼→AI編集→承認→自動反映のループ。プロトタイプ2〜3日・実用版1週間弱で構築可能。
このループはコードとデータが手元にある入力画面方式だからこそ組める拡張です（Studioには外部から編集する入口がない）。 「プラン追加」のような中身の依頼はAIが入力画面のデータを直接更新、「見た目を変えたい」依頼はAIが修正案を下書き ── どちらも先方の承認なしには本番に出ません。写真の権利や表現のチェックが承認者の手に残る点も、リスク管理としてそのまま機能します。