Studio.Dropを既存のStudioサイトで試してみた｜点検から画面の見直しまで、AIと進めた記録

2026年10月、Studio.Drop を試しました。Studio が2026年9月に発表した新しいサービスで、執筆時点ではクローズドβです。

新しくサイトを作るのではなく、今動いている Studio のサイトを3つ、Drop に取り込んでいます。

1. 小さなお店のサイト（5ページ）

2. 弊社のホテルのサンプルサイト（日本語と英語で10ページ）

3. 私たち夫婦の旅ブログ「waooh.jp」（約470ページ）

小さな2つは、数分でほぼそのまま Drop の上で動きました。waooh.jp では手間も抜けも出ましたが、それがきっかけで、2年放っておいた本番のサイトを AI と点検して手直しし、画面の作りも変えることにしました。

この記事の中心は、Studio のサイトを Drop に取り込む検証です。Drop は本来、取り込んだサイトをそのまま Drop で公開し、AI と会話しながら更新していくためのものです。waooh.jp では、AI（Claude）からつないで、気になっていた画面の作りを Drop の上で作り直す実験もしました。こちらは今のまま Studio で公開を続けるため、できあがったデザインは Studio にも反映しています。

1. 小さな2つのサイトは、ほぼそのまま入った

取り込みは、Drop の画面で元のサイトの URL を入れ、所有者であること（または複製する権利があること）にチェックして始めます。高速モードは使っていません。

あとは4つの段階が自動で進み、最後の「Drop に最適化」では、Drop の AI が共通部分の整理や記事の登録まで済ませます。

10月23日に取り込んだ結果です。

写真はパソコンとスマホ幅の等倍の画面で、公開中のサイトと1ページずつ比べました。2章の waooh.jp で出た写真の抜けやリンクの残りは、どちらにもありませんでした。

Drop 上のサイトは、Claude Code（AI のコーディング支援ツール）から MCP（AI ツールとサイトをつなぐ仕組み）で、ページの構造や本文を直接読み書きできます。今回の2つでも確かめています。

一方で、元のドメインと結びついた仕組みは、Drop のプレビューでは動きませんでした。

1. Web フォントの一部が読み込まれず、見出しなどが別の書体になりました

2. ホテルのサイトでは、Cookie の同意の表示が出ませんでした

どちらも、Drop で公開して元のドメインに切り替えれば動く可能性があると考えています（公開していないので未確認です）。なお、お店のサイトでは、写真の一部を Drop の中ではなく、元の Studio の保管場所から読み込んでいました（表示はされています）。

2. 約470ページの waooh.jp では、手間と抜けが出た

waooh.jp は、2010年の日本一周と、2011〜2012年の新婚旅行で回った世界一周を、WordPress で書いていた旅ブログです。2024年末に、Studio の WordPress 取り込み機能で381記事を Studio に移しました（弊社の2023年の記事「WordPressの投稿記事をSTUDIOにインポートする方法 - 200記事が1分で！-」で紹介した機能です）。

写真が抜けた記事や読みにくいページの作りには気づいていました。ただ、381記事を元の WordPress と1本ずつ見比べて手を入れるのは、相当な手間です。直しても自分たちが満足するだけで、優先順位は上がらないまま、約2年がたっていました。

この記事には、waooh.jp が3つ出てきます。

①　元の WordPress。今は表に出さず、バックアップとして残しています。

②　Studio のサイト。今動いている waooh.jp です。

③　Drop 上のサイト。10月7日に②を取り込んだもので、公開はしていません。

※ ②に移したのは2024年末です。今の取り込み機能とは、仕様が変わっている部分があるかもしれません。

③への取り込みでは、次のことが起きました（10月7日の時点）。

1. 取り込み全体は、画面に出た目安の約150分に対して、30分弱で終わりました

2. 1回目の取り込みは471ページを見つけたものの、入ったのは125ページでした。残りの344記事は、最適化の段階で Drop の AI が元のサイトから補っています。その344ページでは、バナーやアイコン用のフォントなど一部のファイルが入らず、1回目に無かった記事へのリンク288本は元のサイト（②）の URL のままでした

3. 348記事で写真が抜けて見えました。Studio は記事の大きめの写真を、画面に合わせてサイズ違いのファイルに差し替えて表示しています。waooh.jp では、WordPress から取り込んだ写真にその小さいサイズのファイルが無く、Drop は差し替える前の住所をそのまま使ったため、表示されませんでした

1章の2つとの違いは、ページ数と、写真を WordPress から取り込んでいたことです。取り込んだ日が2週間ほど離れているので、その間に Drop 側が変わった可能性もあります。

抜けて見えた写真は、はじめは2年前の移行で落ちたものと見て、10月7日の夜、Claude Code に③と①を全381記事で照合してもらいました。大半は上の2と3によるもので、本番の②では、よくある画面なら表示されていました。

Drop 側の不具合と本番の不具合は、分けて確かめる。これが最初の学びです。

3. 本番の Studio サイトにも、43記事の欠けがあった

その延長で、②と①も照合しました。②は公開ページを、①はバックアップの WordPress のデータを読み、写真の枚数と本文を1記事ずつ比べたうえで、写真が実際に表示されるかも確かめています。

この照合に Drop は使っていません。公開ページと元のデータがあれば、それだけでできます。

381記事のうち43記事に、欠けがありました。

1. 本文と写真の抜け（5記事）。日本一周11日目は、写真17枚のうち16枚と、前半と末尾の本文が抜けていました

2. 写真だけの抜け（2記事）

3. リンクが切れた写真（10記事）。うち6記事は、写真のファイル名の誤りでした

4. 端末や画面の幅によって出ない写真（26記事）

ページの作りにも、不具合がありました。こちらは取り込み機能とは関係のない、デザイン側の問題です。

1. 「前の記事へ／次の記事へ」が、全381記事で、押すと今の記事がもう一度開くだけでした

2. 地域ページのパンくずが、6ページとも「アフリカ」でした

3. 検索窓は、スマホではページの下の方にしかありませんでした

旅ブログは前の日、次の日と読み進めるものなので、1は致命的でした。

データ側では、ほかにも、記事末尾の「・」だけの行（17記事。WordPress 時代のシェアボタンの名残）と、原因の分からない公開日のずれ（6記事）が見つかりました。

4. 欠けを直し、画面を見直した

翌朝、Drop の上で、気になっていた画面の作りを AI に作り直してもらう実験をすることにしました。本物の381記事が入った③なら、MCP 経由でどこまでできるかを、実際の記事で確かめられます。順番は、先に本番の欠けを直し、そのあと画面に取りかかりました。

4.1 本番の欠けを直す

①から本文と写真を取り出して、②の本文に戻しました。端末によって出なかった写真は Studio に上げ直し、「・」だけの行は消し、公開日も①に合わせています。

直したあと、同じ照合をもう一度かけ、「①より写真が少ない記事 0」「100字以上の文章の抜け 0」を確かめました。点検は、直したあとに同じ物差しで測り直すところまでで1セットです。

直せなかったものもあります。43記事のうち4記事は、元の WordPress にもファイルが無い写真や、配信元で消えた広告の画像があり、戻せませんでした。

2章で書いた、小さいサイズのファイルが無い写真（182記事・5,048枚）は、本番でも、普通のモニターでブラウザの幅を狭くしたときなどに表示されませんでした。

こちらは上げ直さず、サイト全体のカスタムコードに、読み込めなかったものだけを元のサイズのファイルに切り替える短いスクリプトを足しています（10月23日）。記事は1本も書き換えていません。公開後に、等倍の画面で幅を375pxにして全381記事を開き、写真が残らず出ることを確かめました。Studio の画像の出し方に合わせた手当てなので、Studio 側が変われば効かなくなるかもしれません。

4.2 Drop の上で画面を作り直し、Studio にも反映する

③の上で、MCP 経由で AI に画面を作り直してもらいました。

HTML を自由に書けるので、地域・国・記事の3種類のページを手早く形にして見比べられます。新しい画面に入れるデータ（旅の順、前後の記事、地域や国ごとの紹介文83本など）も③の中身から用意し、OK を出すまで本番の画面には手を入れていません。

waooh.jp は今のまま Studio で公開を続けるので、せっかくなら、ここで作った画面を Studio の本番にも反映しようと考えました。そのため、案は Studio のエディタにある部品だけで作っています。

最後の組み直しも Claude Code に任せました。ログインしたブラウザで Studio の管理画面を操作させ、CMS の項目の追加と381記事への入力、エディタでの部品の配置、カスタムコードまで進めています。ただし、これは Studio が公式に用意している方法ではないので、まねするときは注意が必要です。

10月7日の夜に始めて、翌日の午後には公開しました。本番のサイトでの作業は、その日の朝からの約7時間です。

地域ページ（6つ）は、国名のボタンだけでした。訪れた順の国のカード、期間・国数・記事数と紹介文、「最初の記事から読む」を足し、パンくずも直しています。

国・県・テーマのページ（77）は、新しい順だった記事を旅の順に並べ替え、写真3枚の帯と紹介文、「最初の記事から読む」を置きました。

記事ページ（381）は、前後の記事を旅の順にして行き先の記事名を出し、「リトアニアの旅の記事」のような目次を置いています。

4.3 1週間後に、検索窓

きっかけは、新聞にスペインの飛び地セウタが出てきて、自分たちが行ったかどうかを調べようとしたことでした。ところが、スマホでは検索窓が見つかりません。

パソコンはヘッダーの右端に、スマホはメニューの一番上に検索窓を置きました。

調べ直すと、行ったのはもう一つの飛び地メリリャ（2011年8月4日の記事）で、セウタはその記事の説明に出てくるだけでした。こちらは Drop を使わず、Studio だけで直しています。

5. 人が受け持ったこと

手を動かしたのは主に AI ですが、決めることは人が担いました。作業の順番、画面の方向、そして公開です。

Claude Code の自動実行では、サイト全体の公開のような大きな操作は安全確認で止まったので、そのボタンは人が押しています。直した記事ごとの再公開は、1本目を人が確かめてから任せました。

6. どんなサイトなら、Drop でそのまま動くか

3つのサイトを取り込んで分かったことです（2026年10月・クローズドβの時点）。

1. Studio のエディタで作った、ページ数の多くないサイトなら、数分でページ・写真・リンク・埋め込みまでほぼそのまま入りました（今回は5ページと10ページ）

2. Web フォントや Cookie の同意など、元のドメインと結びついた仕組みは動かないことがあります。表示と動きを1ページずつ確かめる

3. 数百ページあるサイトは、1回で入りきらないことがあります（waooh.jp は10月7日の時点で125ページまで）。後から補われたページのリンクやファイルを確かめる

4. もともと写真を WordPress から（通常の）Studioに取り込んだサイトは、Drop 側で写真が抜けて見えることがあります。本番でも起きているかは、分けて確かめる

既存の Studio サイトを直したい方へ（特に WordPress から移したサイト）

1. 元の WordPress は、消さずに残しておく。waooh.jp は①を残してあったので、2年後でも照合できました

2. 写真の枚数と本文の文字数を、元の WordPress と1記事ずつ比べる。あわせて、写真が実際に表示されるかも確かめる。waooh.jp の43記事のうち、枚数と文字数の差で分かったのは7記事だけで、残りの36記事は表示を見て初めて見つかりました

3. 公式ヘルプが「インポートされない主なデータ」に挙げるもの（ギャラリー、埋め込み全般、画像のキャプションなど）を、元の WordPress でどれだけ使っているか数える

4. 外部を参照したまま入った写真を探す。元のサーバーを止めると出なくなります（waooh.jp では約60枚）。エディタでは、画像の下に［外部サーバーを参照しています］と出ます（公式ヘルプ）

5. 取り込んだ大きめの写真が、どの画面でも出るかを確かめる。waooh.jp では、長い辺が640px以上の写真にサイズ違いのファイルが無く、等倍の画面で幅を狭くすると約5,000枚が表示されませんでした（4.1の方法で手当て済み）。エディタから上げ直すと解消します

6. 記事のデータとは別に、ページの作り（前後の記事、パンくず、検索窓）が、自分のサイトの読まれ方に合っているかを見る

7. まとめ

Studio のエディタで作った小さなサイトは、数分でほぼそのまま Drop に入りました。約470ページで写真を WordPress から取り込んでいた waooh.jp は、手間も抜けも出ましたが、それが2年放っておいたサイトに手を付けるきっかけになっています。

本番の点検と修正そのものは、元の WordPress と公開ページ、そして AI があればできます。Drop を待たなくても、既存の Studio サイトは直せます。MCP でつないだ AI は、本物の記事が入った Drop 上のサイトを読み書きでき、画面の作り直しまでできました。

機会があれば、元の WordPress（①）も Drop に直接取り込んで、2024年に Studio の取り込み機能で移したときとの違いを比べてみたいと思っています。

2023年の記事は「最後に適宜調整を」で締めくくっていました。waooh.jp の場合、その中身は43記事の欠けを直すことと、ページの作りを読まれ方に合わせることでした。写真が多い、記事同士がつながっている、10年以上の蓄積がある。こうした条件は、事業者のブログや実績ページにも当てはまります。参考になれば幸いです。

関連記事

• コーポレートサイトをWordPressからSTUDIOに移行したワケ（2021年・取り込み機能ができる前に、手作業で移した記録）

• WordPressの投稿記事をSTUDIOにインポートする方法 - 200記事が1分で！-（2023年・取り込み機能の使い方）