WordPress Studioの新しいベータ体験では、Studio Codeへ自然言語で依頼し、ローカルサイトのテーマ、プラグイン、ページを作りながら、同じアプリ内のライブプレビューで変化を確認できます。公開中の本番サイトを直接編集せず、手元の検証環境でAIの提案を試せるのが大きな特徴です。
ただし、「作りたいサイトを一文で伝えれば完成」という機能ではありません。良い結果を得るには、対象ページ、変更範囲、完成条件、触ってはいけない箇所を分けて指示し、変更ごとに表示とコードを確認します。ベータ機能は提供内容が変わる可能性もあるため、重要な案件を最初から全面移行するのは避けましょう。
この記事は2026年8月14日更新のWordPress.com Developer公式ドキュメントを基準に、導入、最初の依頼、失敗時の戻し方、本番へ反映する前のチェックまで整理します。
WordPress Studioの新しいAI制作環境とは
WordPress Studioは、パソコン上へWordPressのローカルサイトを作り、テーマやプラグイン、ページを検証できるデスクトップツールです。新しいStudio体験では、エージェント型の制作機能とライブプレビューが一つの流れにまとめられました。
| 機能 | 役割 | 利点 |
|---|---|---|
| Studio Code | 自然言語の指示からファイルを調査・変更 | コードの場所を探す負担を減らす |
| ローカルWordPress | 本番と分離した検証サイト | 公開事故を防ぎやすい |
| ライブプレビュー | 変更後の表示をアプリ内で確認 | 修正と確認を短い周期で回せる |
| Beta Features | 新機能を選んで試す | クラシック体験へ戻せる |
公式ドキュメントでは、新しい体験を有効にすると、自然言語でサイト、プラグイン、テーマを構築できると説明しています。同時にベータ機能は入れ替わる可能性があり、何も提供されない期間もあり得ます。業務フローへ組み込むなら、画面名や挙動を固定の前提にしないことが大切です。
WordPress管理画面のAI機能との違い
Studio Codeはローカル開発環境でファイルやサイトを作る用途です。投稿編集画面で文章を翻訳するWordPress AIプラグインや、公開サイトの投稿を操作するMCP連携とは役割が違います。
記事本文を1本作るだけなら、通常のブロックエディターやAIライティング支援の方が簡単です。テーマのCSSを変更する、独自ブロックを試す、小さなプラグインを作るといった、複数ファイルにまたがる作業でStudio Codeの価値が出ます。
導入前に用意するもの
新しい環境を試す前に、本番サイトとの境界をはっきりさせます。ローカルだから安全と決めつけず、どのファイルを持ち込み、どのデータを使わないかを決めてください。
- WordPress Studioを動かせるパソコン
- 十分な空き容量と安定したネット接続
- 検証用の新規ローカルサイト
- 変更内容を保存するGitなどの履歴管理
- 本番へ移す場合のバックアップとステージング環境
- ロゴ、文章、画像など使用権を確認した素材
顧客サイトのデータベースをそのまま複製すると、個人情報や問い合わせ内容がローカルへ残ります。検証にはダミーデータを使い、実データが必要な場合も匿名化してください。
サイト制作を自作するか外注するか迷っている段階なら、ホームページを自作する場合と外注する場合の違いも確認すると、Studioを使う範囲を決めやすくなります。
新しいStudio体験を有効にする手順
ベータ機能の名称や場所は更新で変わる可能性があります。2026年8月14日時点の公式案内では、StudioのBeta Featuresメニュー、またはGeneral設定上部の案内から新しい体験を有効にします。
- WordPress Studioを起動する
- 新しい検証用サイトを作る
- Studioの設定からBeta Featuresを開く
- New Studio experienceを有効にする
- 対象ローカルサイトを開く
- Studio Codeとライブプレビューが使えることを確認する
動作しない場合、既存の重要サイトで設定を繰り返すのではなく、空の新規サイトで再現します。クラシック版へ戻すには、General設定下部のSwitch to Classicを使えると公式ドキュメントに案内されています。
最初は小さな変更で試す
最初の依頼に「企業サイトを完成させて」と書くと、完成条件が曖昧なまま変更範囲だけが広がります。見出しの装飾、カード1個、固定ページのヒーロー部分など、目視で正否を判断できる単位へ絞ります。
対象: 検証用サイトの子テーマだけ。
目的: トップページの見出しブロックへ、下線アクセントのスタイルを追加する。
条件: 既存の本文色とフォントサイズは変えない。スマートフォンでも横スクロールを出さない。
禁止: 親テーマ、プラグイン、データベースを変更しない。
完了: 変更ファイルと確認手順を一覧にして停止する。この型なら、何を変えたかと、どこで止まるかが明確です。結果を確認してから次の部品へ進みます。
AIへ伝える依頼の5要素
Studio Codeへ任せる仕事は、目的だけでなく制約まで言葉にします。人間の制作者へ依頼するときと同じく、対象が曖昧なら修正回数が増えます。
| 要素 | 伝える内容 | 例 |
|---|---|---|
| 対象 | 触ってよい場所 | 子テーマのstyle.cssとfunctions.php |
| 目的 | 読者に起こしたい変化 | スマホで問い合わせボタンを見つけやすくする |
| 条件 | 見た目・動作・対応幅 | 375pxで横スクロールなし |
| 禁止 | 変えてはいけないもの | 親テーマ、投稿本文、既存URL |
| 完了 | 報告と停止位置 | 変更一覧と確認手順を出して停止 |
「かっこよく」「最新風に」のような感覚語だけでは、デザインの判断基準になりません。余白、色、文字サイズ、対象端末、参考にする既存パーツを具体化します。ただし、他社サイトをそのまま複製する依頼は避けてください。
テーマを試作する安全な流れ
テーマ制作では、最初から全テンプレートを作らず、サイトの骨格、共通パーツ、個別ページの順に進めます。変更ごとにライブプレビューと複数画面幅を確認し、意図しない影響を早く見つけます。
- 既存テーマを親にするか、独自テーマにするか決める
- 色、フォント、余白、ボタンのデザイントークンを定義する
- ヘッダー、フッター、ナビゲーションを作る
- 投稿、固定ページ、アーカイブのテンプレートを作る
- 375px、768px、デスクトップ幅で確認する
- キーボード操作、コントラスト、見出し階層を確認する
- エラー、警告、不要な読み込みを確認する
AIが生成したCSSは、似た指定の重複や強すぎるセレクターを含む場合があります。表示が合っていても、!importantの乱用、固定幅、不要な外部フォント、既存クラスへの広い指定がないかコードを確認します。
親テーマを直接変更しない
既存テーマを使う場合、親テーマへ直接修正すると更新時に消える可能性があります。子テーマまたは追加CSSなど、更新で失われにくい方法を選びます。
Cocoonを使うサイトなら、Cocoon子テーマでCSSを安全にカスタマイズする方法を確認し、Studioで作った変更をどこへ移すか決めてください。
プラグインを試作するときの注意点
小さな機能でも、プラグインはWordPressの管理画面、データベース、公開ページへ影響します。見た目だけでなく、権限、入力値、出力時のエスケープ、アンインストール時の扱いを確認しなければなりません。
- 管理者だけが実行できる操作か
- nonceと権限チェックがあるか
- 入力値を検証・無害化しているか
- HTML出力を適切にエスケープしているか
- 外部通信の送信先と内容が明確か
- 無効化してもサイトが壊れないか
- データ削除を利用者が選べるか
「動いた」だけで本番投入しないこと。WordPressのコーディング規約、PHPの対応バージョン、既存プラグインとの競合も確認します。決済、会員、個人情報、セキュリティに関わる機能は、専門家のレビューなしで公開しない方が安全です。
ライブプレビューで見るべき場所
ライブプレビューは変更を早く確認する道具ですが、一つの画面が正しければ完成ではありません。ページ種類、ログイン状態、端末幅を変えて確認します。
| 確認対象 | 主なチェック |
|---|---|
| トップページ | ヒーロー、導線、画像サイズ、CLS |
| 投稿ページ | 見出し、表、画像、目次、広告周辺 |
| 固定ページ | フォーム、地図、CTA、パンくず |
| アーカイブ | カード崩れ、ページ送り、画像比率 |
| スマートフォン | 横スクロール、タップ領域、文字サイズ |
| キーボード | フォーカス表示、メニュー操作、フォーム |
キャッシュが残っていると、直したのに変わらない、または古い表示を正しいと判断することがあります。ローカル環境でも再読み込みし、生成CSSやビルド工程がある場合は出力先を確認します。
本番公開までのチェックリスト
ローカルで完成した変更を本番へ移す前に、差分、バックアップ、ステージング、本番の順に進めます。AIが変更したファイルを丸ごと上書きせず、必要な差分だけをレビューします。
- Gitなどで変更ファイルと差分を確認する
- 不要なテストコード、コメント、サンプルデータを削除する
- ステージング環境でテーマとプラグインの競合を確認する
- 本番サイトのファイルとデータベースをバックアップする
- アクセスが少ない時間帯に必要な差分だけを反映する
- キャッシュを削除し、主要ページとフォームを確認する
- エラーが出た場合の戻し方を準備する
ローカルと本番では、PHP、データベース、サーバー設定、キャッシュが異なります。Studioで動いたことは重要な検証結果ですが、本番動作の保証ではありません。
Studio Codeが向くケース・向かないケース
便利さを生かせるのは、変更範囲と完成条件を言葉にできる作業です。責任や要件が曖昧な案件では、AIによる変更速度がかえって確認負担を増やします。
向くケース
- 検証用サイトでデザイン案を短時間に試す
- 子テーマの小さなCSS変更を作る
- 独自ブロックや社内ツールの試作品を作る
- 既存コードの場所と動作を調査する
- 変更ファイルと確認手順を整理する
向かないケース
- 本番サイトをバックアップなしで直接変更する
- 決済や個人情報を扱う機能を無レビューで作る
- デザイン要件がなく「全部任せる」
- ライセンス不明の画像やコードを複製する
- 保守担当者が変更内容を追えない状態で公開する
よくある質問
コーディング経験がなくても使えますか？
試作品を作り、ライブプレビューで見た目を確認するところまでは始めやすくなります。ただし、エラー、セキュリティ、アクセシビリティ、本番反映を判断する知識は別に必要です。分からないコードを公開しないことが最低条件です。
既存の本番サイトを直接編集できますか？
WordPress Studioの主な価値はローカルで安全に試せることです。まずローカルへ再現し、差分を確認してからステージング、本番へ移します。直接編集できるかではなく、戻せる工程になっているかで判断してください。
ベータ機能を仕事で使ってもよいですか？
検証や試作には使えますが、機能の提供内容や画面が変わる可能性があります。納期や保守へ影響する中核工程は代替手段を用意し、利用条件も確認します。
AIが作ったテーマやプラグインの著作権はどうなりますか？
利用規約、学習元、入力素材、生成コードに含まれる第三者ライセンスなど複数の論点があります。AIの出力だから無条件で自由と決めつけず、利用するサービスの規約とコードの依存関係を確認してください。
まとめ
WordPress Studioの新しいAI制作環境は、Studio Codeへの自然言語指示とローカルサイトのライブプレビューをつなぎ、テーマやプラグインの試作を速くする仕組みです。公開サイトを直接触らず、小さな変更を作って確認できる点に価値があります。
最初に試すなら、空のローカルサイトで「見出しの装飾を一つ追加する」程度に絞ってください。対象、条件、禁止事項、停止位置を伝え、差分と表示を確認する。AIへ大きな仕事を一度に任せるより、この短い往復が安全で再現しやすい制作フローになります。
コメント