Nanobanana Icon

Tech Blog

Google Antigravity の登場で脱WordPressが現実味を帯びてきた

2025-12-01（月）

はじめに：脱WordPressは「思想」ではなく「運用コスト」の話になった

「WordPressをやめたい」は、しばしば宗教論争みたいに扱われますが、現実はもっと事務的です。
更新・セキュリティ・プラグイン互換・表示速度・バックアップ・脆弱性対応。これらの運用コストが積み上がると、ブログは「書く」より「守る」時間が増えます。

一方で、脱WordPressの受け皿はずっと前から存在していました。代表格が SSG（Static Site Generator） と ヘッドレスCMS です。

脱WordPressの有力候補：SSGかヘッドレス

1) コストを抑えるならSSG

SSGは、ビルドして静的ファイル（HTML/CSS/JS）を配信します。
サーバーが重い処理をしないので、表示が速く、セキュリティ面も比較的ラクです。Cloudflare Pages や GitHub Pages のような静的ホスティングと相性が良く、運用費も抑えやすいです。

ただし、SSGはだいたい次の作業が発生します。

  • コマンド実行（Node.js / npm / build）
  • Git操作（commit / push / branch）
  • Markdown作成（Front Matter、見出し構造、画像パス、リンク整形）
  • デザイン調整（CSS、テンプレート、レイアウト崩れ）

要するに「エンジニアの当たり前」が、そのまま参入障壁になります。

2) 非エンジニアに優しいのはヘッドレス

ヘッドレスCMSは、管理画面（CMS）と表示（フロント）を分離します。書く体験が整っていて、複数人運用もしやすいです。

ただし、月額費用が発生しがちで、画像やAPIリクエストで従量課金になるケースもあります。小さく始めたい個人ブログだと、心理的ハードルが出ます。

「SSGが難しい」を解決するのがAIエージェント

これまでSSGの弱点は、技術的な作業が「人間の手」で必要だったことです。
ところが、AIエージェントが “実作業” を肩代わりし始めると、状況が変わります。

  • コマンド実行を代行する
  • Git操作を代行する
  • Markdownの雛形を作る
  • 既存記事の移植・整形をする
  • デザイン崩れを画面で確認して直す

つまり、SSGの障壁だった「面倒な手作業」を、文章で指示できるようになります。

今回の本題：Google Antigravity が「脱WordPressの現実度」を上げた

Google Antigravity は、いわゆる “AIエディタ” のカテゴリーに入りますが、ポイントは「チャットが賢い」ではありません。
エージェントがIDEの中で作業者として振る舞うところです。

Antigravityで起きることは、ざっくり言うと次の通りです。

  • エージェントがタスクを分解して計画を作る
  • エディタ上でファイルを編集する
  • ターミナルでコマンドを実行する（許可制）
  • ブラウザ操作も含めて検証する
  • 作業の根拠を“Artifacts”として残す（やったことの証跡）

ここが重要で、SSG運用に必要だった「コマンド・Git・CSS」の部分が、自然言語の指示で前に進むようになります。

何が嬉しいのか：SSG移行の「つまずきポイント」を直撃している

1) いきなり最小構成を作って動かせる

例えば 11ty（Eleventy）でブログを作る場合、通常は以下を人間がやります。

  • package.json を作る
  • テンプレートやレイアウトを組む
  • 記事一覧と記事ページのルーティングを作る
  • ビルド成果物の出力先を整える
  • Cloudflare Pages のビルドコマンドに合わせる

Antigravityに「最小の11tyブログを作って、ビルドが通るところまでやってください」と投げると、エージェントが一気通貫で進める世界観になります。
人間はレビューと微調整に集中します。

2) デザイン崩れを直す速度が変わる

SSGはちょっとしたCSS調整で詰まります。
余白・見出し・コードブロック・スマホ表示・OGPカード…このあたりが遅い。

Antigravityは、IDEと（必要なら）ブラウザ操作まで含めて、見た目の修正を繰り返せます。
「この余白を詰める」「見出しの階層でフォント差を出す」「記事カードを2カラムにする」みたいな指示が、そのまま修正作業に直結します。

3) Git push までを“作業”として扱える

SSG最大の障壁は、最後の最後に出てくる Git です。

  • 何をcommitするのか
  • どのブランチか
  • ビルドが落ちたらどこを見るのか
  • 間違えて秘密情報を入れていないか

Antigravityの価値は、ここを「手順」ではなく「作業単位」で進められる点にあります。
もちろん許可制・レビュー前提にすると安全性も上がります。

学び方の順序が変わる：基礎より先に、応用から始められる時代へ

今までは、基礎から固めて応用に進むのが正攻法でした。
SSGなら「Node/npm → Git → Markdown → テンプレート → デザイン → デプロイ」という順序で理解を積み上げるのが安全だったからです。

ただ、AIエージェントの登場で、この順序が現実的に崩れ始めました。
言い換えると 「まず応用を動かして、必要になった基礎だけ後から埋める」 という学び方が成立します。

たとえば、最初の一歩はこうなります。

  • 「ブログをSSGで公開する」というゴールだけ決める
  • エージェントに雛形生成・ビルド・デプロイまでを進めてもらう
  • 途中で出てきたエラーを“教材”にして、必要な範囲だけ理解する
  • 見た目や記事の書き方を直しながら、自然に知識が増える

この進め方は、基礎を軽視するという話ではありません。
基礎の学習を“前提条件”から“必要条件”に変えるということです。

結果として、非エンジニアでも「運用に耐える形」まで到達しやすくなり、エンジニアにとっても「初期構築の摩擦」が減ります。
脱WordPressは「理解してから始める」から、「始めてから理解する」へ寄っていきます。

ただし注意点：AIエージェントで“簡単”になるほど、リスクも寄る

便利さの裏側には管理ポイントがあります。

  • ターミナル実行権限をどこまで与えるか
  • secrets（APIキー等）を誤ってコミットさせない運用
  • 生成物の著作権・ライセンス（テンプレやコード片の取り扱い）
  • SEOの基本（重複、構造化、canonical、サイトマップ）
  • 依存パッケージの更新（SSGは放置すると将来詰まる）

「作業が速い＝レビューの重要度が上がる」ので、Human-in-the-Loopの設計が実務的です。

結論：脱WordPressは「できるか」ではなく「続くか」の問題になった

SSGは昔から最有力でした。ただ、難しさが“学習の壁”として残っていました。
Google Antigravity のようなエージェント型IDEが登場すると、その壁が「作業委譲」に置き換わります。

  • エンジニアは速度が上がる
  • 非エンジニアは入口が広がる
  • チームは運用の標準化がしやすくなる

脱WordPressは、思想ではなく運用設計の話に落ちてきました。
2025年はその転換点になり得ます。