SEO・AIO
AIエージェントによる
SEO改善の誤実装
— 何を止め、どう再発防止したか
2026年4月、私たちはClaude Codeを使い、netsujo.jpのSEO改善を一括で進めました。多数のファイルを横断して修正し、構造化データ、リダイレクト、OGP、内部リンク、表示速度などをまとめて整えました。
一方で、その作業には明確な誤りも含まれていました。一般的なWebページをGoogle Indexing APIへ送信し、それをインデックス促進策として扱っていたことです。Googleの公式仕様では、Indexing APIの対象は、求人情報を表すJobPosting、またはVideoObject内のBroadcastEventを持つライブ配信ページに限られます。一般的な会社情報、サービス、ブログ記事へ使うAPIではありません。
この記事では、作業量や速度を誇るのではなく、なぜ誤った実装が通り、どのように止め、今後どのような品質ゲートを設けるかを整理します。
この記事の要点
一般ページをGoogle Indexing APIへ送信し、それをインデックス促進策として扱った記述を撤回します。同APIの対象はJobPostingとライブ配信ページに限られます。
リダイレクト修正、OGPの是正、構造化データの見直し、内部リンク追加など、対象と検証方法が明確な修正は残します。誤っていたのは施策全部ではなく、適用対象を確認しない進め方でした。
再発防止として、適用対象の確認、事実と仮説の分離、停止条件、反証レビュー、作業量と成果の分離という5つのゲートを工程に置きます。これは当社の運用手順であり、普遍的な正解ではありません。
対象読者は、AIエージェントにコード修正やSEO作業を任せている開発・Web担当者です。検索順位やAI回答への掲載を保証する内容ではありません。
更新・訂正履歴
- 初版公開2026年4月17日
Claude Codeで実施したSEO改善を「17施策の一括改善」として公開しました。
- 訂正2026年7月23日
一般ページへのGoogle Indexing API送信を施策として記載していた点を訂正し、llms.txt・ai-plugin.jsonの効果が未検証であることを追記しました。
- 全面改稿2026年8月6日
撤回対象の記述(Indexing APIによる一括申請の実績表、その再現用プロンプト、施策一覧の「対応済み」表記)を本文から削除し、誤りの経緯と再発防止の品質ゲートを中心に再構成しました。
出典(Google公式): Using the Indexing API / AI features and your website
— 01
実装の速度と正しさは別の評価軸です
実装速度が上がるほど、前提の誤りも同じ速度で広がります。速く直せたことは、正しく直せたことの証明にはなりません。
AIエージェントは、大量のコードやページを横断する作業に向いています。今回も、リダイレクト先の修正、記事固有のOG画像設定、構造化データの見直し、関連記事の追加など、手作業では時間がかかる変更をまとめて進められました。
問題は、実装速度が上がるほど、前提の誤りも高速で広がることです。
短絡した三つの前提
GoogleへURLを通知するAPIがある
インデックス未登録のURLが多数ある
APIを使えば改善できるのではないか
この三つが短絡的につながり、対象ページの条件を確認する工程が抜けました。コードが動き、APIが応答し、処理件数が表示されたため、作業完了と判断しやすい状態でもありました。しかし、技術的に実行できることと、公式仕様に沿っていることは同じではありません。
— 02
誤って実施したこと
サイトマップに含まれるURLと、Search Consoleで確認した旧URLをまとめてIndexing APIへ送信していました。初版はその件数を成果として記載し、再現用のプロンプトも公開していました。この説明は撤回します。
撤回した記述
- Indexing APIによる一括申請の件数を、インデックス改善の実績として並べた比較表
- 同じ手順を読者が再現するための、Indexing API一括申請のプロンプト例
- 効果の確度が異なる施策を、まとめて「対応済み」と表示した一覧
一般ページのクロールやインデックス登録を確認する場合、私たちが現在使うのは次の方法です。調査手順の詳細はクロール済み-インデックス未登録の原因調査にまとめています。
- 1
XMLサイトマップを正しく生成し、Search Consoleへ送信する
- 2
重要ページへ内部リンクを設置する
- 3
URL検査で代表ページの状態を確認する
- 4
サーバーログでGooglebotの来訪を確認する
- 5
重複、canonical、noindex、レンダリング、本文品質を点検する
- 6
公開後の反映を一定期間観測する
Indexing APIを、一般的なSEO施策として案内することはありません。
— 03
同時に見直したAI検索向け施策
設置した事実と、検索露出に効果があるという評価は、分けて扱う必要があります。初版で「対応済み施策」として並べたAI向けファイルは、現在は同じ強さで評価していません。
当時の記事では、llms.txt、llms-full.txt、ai-plugin.json、ai:description、AI向けのAnswer-First形式なども「対応済み施策」として並べていました。現在は、これらを同じ強さで評価していません。
Googleは、AI OverviewsやAI Modeに表示されるために、特別なAI向けファイル、特別な文章形式、AI専用の構造化データは必要ないと説明しています。Google検索において優先すべきなのは、通常の検索要件を満たし、独自で有用な内容を公開し、重複や技術的な障害を減らすことです。
llms.txtは提案仕様として検証余地がありますが、Google検索向けの必須施策ではありません。現在の位置づけはllms.txtは必要かで整理しています。ai-plugin.jsonも、現在のChatGPT検索へサイトを登録するための一般的な要件ではありません。設置した事実と、検索露出に効果があるという評価は分ける必要があります。
— 04
残してよい改善と、撤去すべき主張
今回の施策すべてが誤っていたわけではありません。対象と検証方法が明確な修正は残し、確度を伴わない主張だけを撤去しました。
残してよい改善
- ▸404へ到達していた旧URLのリダイレクト修正
- ▸ブログ記事のog:typeとog:imageの改善
- ▸物販ではないサービスへ不適切なProduct構造化データを使っていた問題の修正
- ▸関連記事、関連サービスへの内部リンク追加
- ▸一覧ページの初期表示量の削減
- ▸型チェック、ビルド、URLヘルスチェックの自動化
撤去または再評価する主張
- ▸一般ページへのIndexing API送信をSEO施策として扱うこと
- ▸llms.txtやai-plugin.jsonを標準的なAI検索対応と呼ぶこと
- ▸テキスト対HTML比率をAI検索の重要指標として一般化すること
- ▸AIクローラーを許可すれば引用や推薦が増えると受け取れる表現
- ▸実装直後の状態を、検索流入や問い合わせの成果として扱うこと
作業量は成果ではありません
変更したコードの量、処理したURLの数、作業時間は、成果そのものではありません。成果を評価するには、公開後の検索表示、クリック、問い合わせ、誤回答、再現性を別途観測する必要があります。
— 05
なぜ誤りが公開まで進んだのか
原因は、AIの誤回答だけではありません。人間側のレビュー設計にも問題がありました。
仕様確認より実行を先にした
「どう実装するか」を先に考え、「そもそも適用対象か」を後回しにしました。
API成功を施策成功と取り違えた
HTTP応答が成功しても、その利用目的が正しいとは限りません。処理件数が出ると、成果が出たように感じやすくなります。
一つの記事へ異なる確度の施策を並べた
公式仕様に基づく修正、業界で使われる試行、独自仮説を同じ「対応済み」の表へ入れました。読者から見ると、すべて同じ確度に見えます。
公開前の反証レビューがなかった
実装担当と記事作成担当が同じ前提を共有していたため、「この施策が誤りだとしたら、どの公式文書で否定されるか」という確認が不足しました。
— 06
今後の品質ゲート
AIエージェントへSEOやWeb改善を任せる場合、私たちは次の順序を必須にします。当社の運用手順であり、普遍的な正解として示すものではありません。運用の全体像はAIエージェントで会社を回すに記載しています。
適用対象を確認する
API、構造化データ、robots制御、計測機能は、対象ページと用途を公式文書で確認します。
事実・仮説・実験を分ける
記事と実装仕様に、「公式仕様」「自社で確認した事実」「観測から置いた仮説」「効果未検証の実験」のラベルを付けます。
実行前に停止条件を決める
対象外のURL、過大な権限、想定外のAPI応答、ビルド失敗、計測不能が見つかった場合は自動処理を停止します。
公開前に反証レビューを行う
「この結論が間違っている可能性」を探す役割を、実装担当とは別に置きます。公式文書、一次情報、現在の製品仕様を確認します。
作業量と事業成果を分ける
変更ファイル数や作業時間は生産性指標です。検索表示、流入、問い合わせは成果指標です。両者を同じ表で比較しません。
— 07
誤りを隠さない運用にこそ価値があります
AIエージェントは、調査、修正、テストを高速化します。ただし、速度が正しさを保証するわけではありません。人間が目的、適用条件、承認、公開後の責任を持たなければ、誤った施策も同じ速度で広がります。
今回の誤実装は、AIを使ったこと自体より、公式仕様の確認と反証レビューを工程に組み込まなかったことが原因です。
私たちは、過去の記事を静かに書き換えて終わらせません。何を誤り、何を止め、現在はどう評価しているかを履歴として残します。AIエージェントを実務へ使う会社として、成功例だけでなく、誤りを修正できる運用も公開していきます。
この記事の著者

飯田 友広
代表取締役
Netsujo株式会社 代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。京都ビッグデータ活用プラットフォーム参画(小規模企業会員・ベンチャー)、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」参画(2026-03-10)、IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」を京都府庁旧議場で開催(2026-07-02・Netsujoとして主催、企画・登壇・運営/京都府デジタル政策推進課は共催)。京都美術工芸大学での講義・龍谷大学でのセミナー実績、ITコミュニティ「みやこでIT」(connpassメンバー614名・イベント167件・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。ソーシャル企業認証「S認証」認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。
プロフィールを見るこの記事が向いている方
AIエージェントにコード修正やSEO作業を任せている開発・Web担当者
実装した施策が公式仕様に沿っているかを、公開前に確認する仕組みを作りたい方
AIを使った改善を、作業量ではなく事業成果で評価したい方
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. AIに任せた実装を、公開前にどう検証すればよいですか?
適用対象を公式文書で確認し、実装担当とは別の役割で反証レビューを行う工程を置きます。
Q. すでに公開した記述に誤りが見つかったらどうしますか?
静かに書き換えず、訂正履歴を記事上部へ残し、何を撤回したかを明示します。
Q. 作業量と事業成果を、どう分けて見ればよいですか?
変更ファイル数や作業時間は生産性指標、検索表示・流入・問い合わせは成果指標として別に扱います。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
関連するサービス
Web営業基盤|Netsujo SIGNAL
対象と根拠を決めてから、実装へ進む
AIエージェントを使ったWeb改善、実装仕様の設計、公開前の技術レビューに対応しています。大量修正を速く進めることより、対象、根拠、停止条件、検証方法を定義してから実装することを重視しています。まず無料診断で現状を確認できます。