バイブコーディングとは、AIに自然言語で指示してコードを生成させ、人がほとんど手書きしない開発の進め方を指します。2025年2月にAndrej Karpathy氏が提唱した呼び方で、Collins英語辞典は2025年の「Word of the Year」に選びました。速く作れる一方、指示した変更が本番へ要件どおり反映されたかを確かめる工程が抜けやすく、そのずれはSEOの数値悪化として遅れて表面化します。
この記事でわかること
- 「動いた」と「反映された」は別物： AIが作った画面が動いていても、検索エンジンから見た要件が満たされているとは限りません。
- 検証は3ステップで足りる： 変更前に完成条件を仕様へ翻訳し、変更前後を照合し、本番URLを実測する。この順番が要です。
- 点検は8項目に絞る： HTTP・title・canonical・robots・構造化データ・内部リンク・レンダリング後HTML・計測タグを見れば、致命的な事故はほぼ防げます。
バイブコーディングとは？SEOでは「作れた」と「正しく反映された」を分ける
バイブコーディングとは、AIに自然言語で指示してコードを書かせる開発の進め方です。人はコードを書きません。
作るものの提示と、生成物の確認に集中する進め方だと言い換えてもよいでしょう。
この進め方が広がったこと自体は、中小企業にとって追い風です。これまで見積もりを取って数週間待っていた小さな改修が、その日のうちに形になります。問題は速度ではなく、速度に検証が追いついていないことです。Search Engine Landのドナ・ルジョー氏は2026年8月14日の記事で、AIは数分で動くプロトタイプを作れるが、それは「頼んだものを作った」証明にはならないと指摘しました。同氏自身のサービスでも、中核機能のひとつが本番から欠落したまま8か月間、月次の状況報告をすり抜けていたと明かしています。
検索エンジンから見たとき、ページが「動いている」ことと「要件どおりに実装されている」ことは別の話です。画面上は正しく表示されていても、canonicalが別ページを指していれば評価は移りますし、noindexが外れていなければ検索結果に出ません。誤解のないように書いておくと、バイブコーディングで作ったから不利になるわけではありません。Googleが取得・レンダリング・インデックスできる実装になっているかどうかだけが問われます。
改修そのものの進め方や費用感については「ホームページ改修とは？リニューアルとの違い・費用・SEO注意点を解説【2026年】」で整理しています。
AIコードはなぜ「惜しいが違う」状態になるのか
AIは動くコードを作るのが得意で、要件どおりかを確かめる工程を持たないからです。
指示と実装のずれは、画面が動くかどうかの確認では表面化しません。
この「惜しいが違う」という感覚は、数字にも表れています。Stack Overflowが2025年に実施した開発者調査では、AIツールを使っている・使う予定があると答えた開発者は84%（前年76%）に達した一方、出力の正確性を信頼していないと答えた人は46%と、前年の31%から大きく増えました。さらに66%が「ほぼ正しいが完全には正しくない」解に時間を取られていると回答しています。使う人は増え、信頼は下がり、手戻りが増えている構図です。なお同じ調査では、バイブコーディング自体は72%が「していない」と答えており、AIツールの利用率とバイブコーディングの普及率は分けて読む必要があります。
品質面の傍証もあります。Veracodeが100を超えるLLMに80種類のコーディング課題を解かせた2025年の調査では、生成されたコードの45%にOWASP Top 10相当の脆弱性が含まれていました。Javaは失敗率72%、JavaScriptは43%です。2026年春の追跡調査でも合格率は55%前後で横ばいで、モデルを大きくしても改善しないと報告されています。これはセキュリティの指標であってSEO実装の精度ではありませんが、「動くコード＝要求を満たすコード」ではないという前提を裏づける材料にはなります。
（実務知見）改修されたページを受け取ったとき、当社は必ず「どこかが間違っている」という前提で全体を目視してから点検に入ります。体感では5回に1回程度は実際に指示と違う箇所が残っています。この打率を知っているかどうかで、確認にかける時間の配分が変わります。
バイブコーディング後のSEO検証は3ステップ
変更前に完成条件を仕様へ翻訳し、変更前後を照合し、本番URLを実測する。この3つで足ります。
手順1 変更前に「完成条件」を仕様へ翻訳する
AIに渡すのは症状ではなく、完成条件です。何が問題で、どう変わればよく、どこで確かめるかまで書きます。
ここで多いのが、SEOツールの監査レポートをそのままAIや制作会社に渡してしまう進め方です。ルジョー氏も、監査レポートは仕様書ではないと明確に書いています。スキャナの出力は問題の一覧であって、期待する状態の定義ではありません。「このページのcanonicalが自己参照になっていない」という指摘を、「/service/ のcanonicalを https://example.com/service/ の自己参照に変更する。確認方法はURL検査のレンダリング後HTML」という形まで翻訳して初めて、検証できる指示になります。
手順2 変更前後の差分を照合する
改修後だけを見ても、それが正しいかは判定できません。変更前の状態を保存してから作業に入ります。
保存するのは、対象URLのレンダリング前HTML、URL検査のスクリーンショット、head内のtitle・meta・canonical・robots、計測タグの発火状況、主要KWの順位です。手元にテキストで残しておけば、改修後に同じものを取り直して並べるだけで差分が出ます。（アイダイム分析）ここを省くと「なんとなく良くなった気がする」以上の判定ができなくなり、後から順位が動いたときに原因の切り分けができなくなります。
手順3 本番URLをGooglebotとユーザーの両方から実測する
ブラウザで見えていることと、Googleが取得できていることは一致しません。両方から見て初めて実測です。
ユーザー視点はブラウザの表示とソース表示、Googlebot視点はSearch ConsoleのURL検査ツールで確認します。公開URLをテストすると、レンダリング後のHTML、スクリーンショット、HTTPレスポンス、読み込めなかったリソース、JavaScriptのコンソールメッセージまで見られます。JavaScriptで後から差し込んでいる要素は、ここで初めて「入っていない」ことが分かる場合があります。
AIに自己採点させて終わりにしない
生成したAIに「できていますか」と聞き返すのは、検証ではありません。同じ前提で作られた答えが返るだけです。
確認は、生成とは別のセッション・別の担当・別のツールで行います。AIを使うにしても、実装を担当させたスレッドではなく、仕様と実際のHTMLだけを渡した新しいスレッドで突き合わせさせるほうが、ずれを拾えます。
ステージングが無い現場のルール
多くの中小企業サイトには検証用の環境がありません。本番しかない前提で、事故を小さくする決め方に切り替えます。
ステージングとは、本番と同じ構成で用意する練習用のサイトのことで、ここで試してから本番へ反映するのが一般的な定石です。ただし共用サーバーで運用している中小企業サイトでは、そもそも用意されていないことが珍しくありません。（アイダイム分析）その場合は「1回の指示で1か所だけ変える」「変える前の状態をコピーして保存する」「アクセスの少ない時間帯に反映する」「反映直後に必ず点検して、戻す判断をその場でする」の4つをルールにします。検証環境の代わりになるのは、変更単位の小ささと、戻せる状態を先に用意しておくことです。
臨床検査の精度管理をSEO改修に転用する
検査値と同じで、期待値・異常検知・是正・再検査の4点をそろえると、反映漏れが残りません。
当社代表は臨床検査技師として10年以上の実務経験があります。検査室では、測定値をそのまま報告することはありません。あらかじめ決めた判定基準に対して、外れていないかを見て、外れていれば原因を追い、直したうえでもう一度測ります。この4点セットが精度管理（QC）の骨格です。
サイト改修も構造は同じです。「canonicalを直した」で終わらせず、直した後の期待値（自己参照であること）を先に決め、実測し、外れていれば是正し、再検査の日付まで決めます。（実務知見）当社では改修を受け取ったページに対して、Search Consoleを開く前に必ず全体を目視します。ツールは指定した項目しか見ませんが、目視は「指定し忘れた場所」の異常に気づけるためです。実際、5回に1回程度は目視の段階で違和感が出ます。
「正常範囲」という言葉をそのまま持ち込むと誤解を招くので、SEOでは「期待値・判定基準」と言い換えます。順位のように外部要因で揺れる指標は判定基準にせず、実装が仕様どおりかという二値で判定できるものを点検項目に選ぶのが要点です。
AI改修後に必ず確認する8項目
HTTP、title、canonical、robots、構造化データ、内部リンク、レンダリング後HTML、計測タグの8つです。
この順番には意味があります。検索エンジンが「取得できる→正規URLを判断できる→内容を認識できる→こちらが計測できる」という流れに沿っており、上から順に見ると、下の項目の異常が上の異常に由来していないかを切り分けられます。
| 点検項目 | 期待値・判定基準 | 確認する場所 | 外れていたときの一手 |
|---|---|---|---|
| HTTPステータス・リダイレクト | 対象URLが200。旧URLは301で1回だけ転送 | URL検査のHTTPレスポンス | 転送の連鎖・ループを解消し、最終URLを1つに定める |
| title・メタディスクリプション・H1 | 指示した文言と一字一句一致。重複出力がない | ソース表示／レンダリング後HTML | テーマとSEOプラグインのどちらが出力しているかを特定して片方に寄せる |
| canonical | 原則は自己参照。パラメータ付きURLも正規URLを指す | レンダリング後HTML | 別ページを指していれば即修正。テンプレート側の固定値化を疑う |
| robots.txtとnoindex | クロール可・インデックス可。テスト用の記述が残っていない | URL検査のクロール可否／インデックス可否 | robots.txtとmetaタグ・X-Robots-Tagを別々に確認して解除する |
| 構造化データ | 改修前に出ていた型が消えていない。必須項目にエラーがない | リッチリザルトテスト | 出力元（テーマ・プラグイン・直書き）を特定して復元する |
| 内部リンク | 主要導線のリンクが残り、リンク先が200 | ブラウザ／クロールツール | 消えた導線を復元。相対パスの書き換えミスを確認 |
| レンダリング後HTMLの主要コンテンツ | 本文・見出しがレンダリング後HTMLに存在する | URL検査のライブテスト | クライアント側描画に寄りすぎていないか、読み込み失敗リソースを確認 |
| 計測タグ・コンバージョン | 計測タグが1回だけ発火し、フォーム送信を計測できる | ブラウザの開発者ツール／解析画面のリアルタイム | テンプレート差し替えでの脱落・二重設置を確認して片方を外す |
8つのうち、①から④までが崩れると流入そのものが止まります。時間がないときは上の4つだけでも確認してください。技術面の全体像は「テクニカルSEOの基本｜効果的な対策を解説」、構造化データの書き方と検証手順は「JSON-LDとは？構造化データの書き方・実装・検証方法」で解説しています。
検証ツールの使い分け
1URLはURL検査、構造化データはリッチリザルトテスト、サイト全体はクローラーで見ます。役割が違います。
どのツールも「何が分からないか」を知って使うことが大切です。とくにURL検査のライブテストは万能ではなく、Googleも重複URLの扱いや品質・セキュリティ上の問題、手動対策といったインデックスの全条件を検査するものではないと明記しています。
| ツール | 分かること | 分からないこと |
|---|---|---|
| URL検査ツール（ライブテスト） | Googlebot視点のレンダリング後HTML・スクリーンショット・HTTPレスポンス・読み込めなかったリソース | インデックスされるかどうかの最終判定。1URLずつしか見られない |
| リッチリザルトテスト | 構造化データの検出結果とエラー・警告 | リッチリザルトが実際に表示されるかどうか |
| PageSpeed Insights | 改修前後の表示速度・体験指標の劣化 | 実装が仕様どおりかどうか |
| ブラウザのソース表示・開発者ツール | ユーザー視点の表示、タグの発火、コンソールエラー | Googlebotから同じに見えているかどうか |
| クロールツール | サイト横断でのステータス・title重複・リンク切れの差分 | 個別URLのレンダリング詳細 |
1ページだけの改修ならURL検査とブラウザで足りますが、テンプレートに手を入れた改修では影響が全ページに及ぶため、クロールツールでの横断確認まで入れてください。Search Console側でAI検索まわりの数値をどう読むかは「サーチコンソールのAIモードは一律1位ではない｜生成AIデータの読み方と点検手順」で扱っています。
よくある失敗と是正記録の残し方
失敗の多くは、1回の指示で変えた範囲が大きすぎることから起きます。記録を1行残すだけで再発が止まります。
同じ修正を何度やっても直らないときに疑う5か所
直したはずの変更が反映されない場合、原因はコードではなく配信経路や上書きにあることがほとんどです。
（実務知見）現場では「何度指示しても同じ箇所が直らない」という状況が実際に起こります。（アイダイム分析）このとき疑う順番は、①キャッシュ（サーバー・CDN・キャッシュ系プラグイン・ブラウザ）で古いHTMLが配られている、②編集したファイルが実際には使われていない（親テーマと子テーマ、別テンプレート）、③後段の上書き（テーマやSEOプラグインが同じタグを出力している）、④同じタグの二重出力で後勝ちになっている、⑤変更が本番へ配信されていない、の5つです。AIに何度も指示を出し直す前に、この5か所を切り分けてください。反映されない原因が指示の書き方ではなく環境側にある限り、AIを何回まわしても直りません。
変更単位を小さくして、戻せる状態を先に作る
1回の反映で1か所だけ変えます。戻す手段を用意してから作業を始めます。
AI経由の改修でよく聞くのが、やり直しの操作で保存前の変更まで消えたという話です。ファイル単位のコピーでも構わないので、作業前の状態をどこかに残しておきます。反映と点検を交互に挟むと、異常が出たときの原因が直前の1変更に絞られます。
是正記録は7項目を1行で残す
記録に残すのは、URL・変更要求・期待値・実測値・差異・是正内容・再検査日の7つです。
臨床検査で是正記録を残すのと同じ考え方で、「誰が見ても同じ判断ができる」形にしておきます。（アイダイム分析）この1行があると、次に同じテンプレートを触るときに点検箇所が即座に分かり、担当が変わっても引き継げます。チェックリストだけの運用が形骸化するのは、実測値と差異を書く欄がないためです。
📌 AIで速く作りつつ、公開前の点検と是正記録まで社内で回すのが難しい場合は、制作・改修から検証までを一括で任せる選択肢もあります。
→ サイト制作のサービス詳細を見る
バイブコーディングとSEOのよくある質問
実務でよく聞かれる疑問を、先に結論から答えます。
Q. バイブコーディングで作ったサイトはGoogleに不利ですか。
A. 作り方そのものは評価に影響しません。Googleが取得・レンダリング・インデックスできる実装になっているかだけが問われます。判断材料はレンダリング後HTMLに主要コンテンツが存在するかどうかです。
Q. AIにSEOの改修を任せても大丈夫ですか。
A. 任せて構いませんが、完成条件を仕様の形で渡し、人が実測するところまでを1セットにしてください。指示が症状の羅列だと、指示どおりでも要件を満たさない実装になります。
Q. 改修したAIに確認させれば十分ですか。
A. 十分ではありません。生成と同じ前提で確認するため、ずれがそのまま通ります。別のセッション・別のツール・人の目のいずれかを必ず挟んでください。
Q. 点検は公開前と公開後のどちらで行いますか。
A. 両方です。公開前はソース表示で仕様との一致を、公開後はURL検査でGooglebot視点の取得結果を確認します。公開後の点検は反映直後に行い、後日の再検査日も決めておきます。
Q. 順位が落ちていなければ成功と考えてよいですか。
A. 判断できません。インデックスの更新には時間差があり、noindexや計測タグの脱落は数週間後に数値へ現れます。順位ではなく、実装が仕様どおりかという二値で判定してください。
参考情報
- Donna Rougeau「The missing step in vibe coding: Verify what actually shipped」Search Engine Land（2026年8月14日）https://searchengineland.com/the-missing-step-in-vibe-coding-verify-what-actually-shipped-484975
- Stack Overflow「2025 Developer Survey｜AI」https://survey.stackoverflow.co/2025/ai
- Veracode「2025 GenAI Code Security Report」https://www.veracode.com/blog/genai-code-security-report/
- Veracode「Spring 2026 GenAI Code Security Update」https://www.veracode.com/blog/spring-2026-genai-code-security/
- Google Search Console ヘルプ「URL 検査ツール」https://support.google.com/webmasters/answer/9012289?hl=ja
- Collins Dictionary「Word of the Year 2025」https://www.collinsdictionary.com/woty
