AIネイティブ時代のWeb制作へ。人間には体験を、AIには真実を、エージェントには行動を
SEO / AIO / LLMO / Agent-ready UXを監査・実装するエージェントスキルを公開しました。
実際に自社サイトにも使ってみたところ、LighthouseのSEOスコアが100でも、AIネイティブの観点ではまだ見えていない課題があることがわかりました。
公開リポジトリ：
Webサイトは、もう人間だけが読むものではなくなってきた
ここ最近、これからのWebサイトがどうあるべきかについて、深い思索を巡らせています。
これまでのWebは、基本的には「人間が読むもの」という大前提のもとで作られてきました。人が検索し、結果をクリックしてページを読み、他社と比較した上で、最終的に問い合わせや購入に至る――。その一連の流れを支えるために、SEOやデザイン、コピーライティング、そしてUI/UXといった技術が磨かれてきたわけです。
しかし、生成AIが検索エンジンやブラウザ、さらにはOSのコアへと組み込まれ始めたことで、この前提が少しずつ、しかし確実に揺らぎ始めています。
人がいちいちすべてのページを読み比べるのではなく、AIが先回りして情報を集め、比較・要約し、その人に合わせて再構成して提示する。さらにその先では、AIエージェントが人間の代わりに予約や問い合わせを自律的に済ませてしまう。そんな未来が、すぐそこまで来ています。
そうなると、Webサイトは単に「人間に情報を読ませる場所」ではなくなります。 AIに読まれる場所であり、エージェントに操作される場所。そして人間にとっては、ブランドの気配や世界観を五感で受け取る場所になっていく。
最近は、そんな新しいWebの姿をリアルに想像しています。
AI同士が手を繋ぐWeb
先日、Xでこんなことをポストしました。
WEB側もAIを使ってAIに向けて情報を送り出していくし、ユーザー側のAIもより深い情報を引き込むのがうまくなっていくわけで、お互い近づいてAI同士で手を繋いで上手いことやってくれたら人間の意思が介在しないままパーソナライズされた最適解として提示されることになるのは自然だよな。
— さかもと()｜未定義→実装 (@mocchalera) June 9, 2026
これからのWebでは、運営者側もAIを活用し、自分たちのサービスや思想を「AIが最も理解しやすい形」に整理して送り出すようになります。一方で、ユーザー側にも、その人の好みや制約を深く理解したAIが寄り添っている。
この両者が直接対話し、条件をすり合わせてくれるようになれば、人間が泥臭く検索結果を巡る必要はなくなります。最終的に人間には、「今のあなたにはこれが最適ですよ」と洗練された答えだけが届く。
これは技術の進化として、非常に自然な帰結です。Googleが公開している「生成AI検索最適化ガイド」を見ても、複数のクエリから情報を広げて回答を生成するRAG（検索拡張生成）の仕組みが重視されており、彼ら自身もこの変化を「SEOの地続きにある品質向上」と捉えています。
つまり、AI検索の時代になってもWebサイトは消えません。むしろ「AIに読まれること」を前提に、その役割が新しく定義され直していくのです。
ただし「最適解」は中立ではない
ここで私たちが忘れてはならないのが、AIが提示する「最適解」は決して完全無欠で中立なものではない、ということです。
AIがどの情報を信頼し、何を重視して重みづけするかによって、出力される結果はいくらでも変わります。だからこそ、運営者は自分たちの「公式情報」を、自らの手でしっかりと保持しておかなければなりません。
AIに勝手に、かつ雑に解釈されてしまう前に、「私たちの正解はこれです」という事実を、誤読しにくい形で提示しておく。これこそが、私が「AI Truth Layer（AIに向けた真実の層）」と呼んでいるものの正体です。
三つの層で設計する、これからのWeb
この思考を整理していくうちに、これからのWebサイトは「三つの層」で捉えると非常にすっきり設計できることに気づきました。
1. Human Experience（人間への体験）
写真や映像、心地よいスクロール、インタラクションなどを通じて、ブランドの世界観や気配に触れてもらう、情緒的な体験の層。
2. AI Truth（AIへの真実）
サービス内容、価格、FAQ、構造化データなど、AIが読んでも決して誤解しない、検証可能な「公式情報の正本」としての層。
3. Agent Action（エージェントへの行動）
問い合わせや予約、購入といった導線を、AIエージェントが迷わず自律的に操作できるように整えられた、機能の層。
人間には体験を。AIには真実を。エージェントには行動を。
この指針は、これからのWeb制作において私の大きな軸になりそうです。
情報はAIが読めばいい。でも、雑でいいわけではない
実は、この「三つの層」という考え方に思い至る前、私の中の仮説はもっと単純なものでした。
「数字やスペックのような純粋な情報は、全部AIが読んでくれればいいんじゃないか」
かなり極端に言えば、そう考えていたのです。営業時間や料金、仕様、会社概要、FAQといったファクト（事実）のデータは、人間がいちいちページを隅々まで読み込む必要はありません。AIが裏側でサッと目を通し、ユーザーの質問に合わせて必要なところだけを教えてくれれば、それで十分事足ります。
だからこそ、これからの人間向けのWebサイトは、もっと体験に特化していくはずだ。没入感があり、ブランドの世界観が肌で伝わり、訪れるだけで心が動くような、そんな尖った場所に変わっていくのだろう――。最初は、そんな二元論的な未来を想像していました。
しかし、さらに深く思索を巡らせていくうちに、自分の中の解像度がもう一段階上がってきました。
単に「AIが読めればいい」と、情報を雑に放り出していいわけでは決してない。むしろその逆ではないか、と気づいたのです。
AIが読み込む情報だからこそ、それは圧倒的に正確で、常に最新に保たれ、きれいに構造化されていなければなりません。なにより、人間向けの画面に表示されている内容と、裏側でAIに渡すデータとの間に、ほんの少しの矛盾もあってはならないのです。
Googleが公開しているドキュメントを読み解いても、同じような本質が語られています。
生成AI検索に対応するために、何か特別な、AI専用の裏魔術のようなマークアップが用意されているわけではありません。むしろ、これまで培われてきた「構造化データ（schema.org）」を正しく実装することが、AI検索の時代でも引き続き強力な基盤になると説明されています。また、AI検索に引っかかりやすくするためだけに不自然なページを量産したり、応答を意図的に操作しようとするコンテンツ設計は避けるべきだ、とも釘を刺されています。
つまり、AIに好かれるための「不自然な裏口」を急ごうとするのではなく、人間にとってもAIにとっても誠実で、検証可能な「正しい公式情報」を実直に整えること。
それこそが、私たちが今、最も向き合うべき現実的な方向性なのだと思っています。
人間向けのWebは、もっと感情に寄っていく
AIが情報をきれいに整理してくれるようになると、人間が直接Webサイトを訪れる「理由」そのものが変わっていきます。 単にスペックや数字、ファクトを知るためだけなら、AIに要約してもらえば事足ります。では、それでも人間がわざわざサイトにアクセスする意味とは何でしょうか。
それはきっと、「心が動く体験」を求めているからだと思うのです。 「このブランドの雰囲気が好きだな」「この人に仕事を頼んでみたいな」と、感情が動く瞬間。
たとえばアウトドアブランドのサイトなら、単なるスペック表だけでなく、山の澄んだ空気や雪の感触が伝わる映像、開発者の熱い想いに触れる体験が必要です。宿のサイトなら、部屋の広さだけでなく、窓から差し込む朝の光や、そこで過ごす静かな夜の時間を想像できるかどうかが大切になります。
人間向けのWebは、情報の置き場から「体験の場所」へと純化していく。 ただし、これは「派手な演出や3Dを入れればいい」という浅い話ではありません。そのブランドの本質を、どうやってデジタルな体験に変換していくかという、より深い設計が求められるのだと思います。
エージェントに使われるWebへ
もう一つ、これからのWeb制作で無視できないのが、「AIエージェントに優しくあること」です。 人間がWebサイトを見るときは、多少デザインが不親切でも「あ、これがボタンだな」「ここに料金が書いてあるな」と文脈で補完できます。
しかし、AIエージェントにとってはそうはいきません。 意味のないタグで作られたボタンや、ラベルのないフォーム、画像の中にだけ埋め込まれた料金表は、エージェントを迷わせてしまいます。
web.devの解説によると、AIエージェントは画面のスクリーンショットだけでなく、HTMLの「アクセシリティツリー（要素の役割や状態を整理した地図）」を組み合わせてWebを理解しているそうです。つまり、セマンティックなマークアップや適切なラベル、フォームの設計といったアクセシビリティへの配慮は、これからは人間のためだけでなく、AIエージェントのためにも不可欠になります。
人間にとって優しいサイトは、AIにとっても優しい。この当たり前のような事実が、これからの時代、さらに重みを増していくはずです。
WebMCPという、新しい潮流
さらにこの流れを加速させそうなのが、「WebMCP」という考え方です。
最近、Chromeのエンジニアたちが提唱し始めたこのコンセプトは、AIエージェントがWebサイトの機能をより正確に、かつ安全に利用できるようにするための仕組みです。
具体的には、Webサイト側が「このフォームはこういう目的のもので、こういう入力が必要です」という情報をAIが直接叩けるAPIのような形で提供する。これにより、AIが画面を「見て」推測する手間を省き、エラーなく予約や決済などのアクションを代行できるようになります。
いわば、Webサイトが「AIエージェント用のインターフェース」を標準装備し始めるようなものです。情報の提示（Truth）だけでなく、行動の代行（Action）においても、Webの形は劇的に変わろうとしています。
この「WebMCP」という仕組みが、今後どこまで広く普及していくかはまだこれからの話です。ただ、その目指している方向性には、ものすごく強い納得感があります。
現状のAIエージェントは、いわば「人間の代わりに画面を目で見て、どこをクリックすべきか、どこに文字を入力すべきか」を必死に推測しながら動いている状態です。でも、本来であればサイトの側から、「ここで行うのは検索です」「これは予約のためのボタンです」「この入力欄には氏名を入れてください」と、あらかじめ明示してあげた方がスマートなはずですよね。さらに言えば、「この操作は購入確定になるので、必ず人間のユーザーに最終確認を取ってください」といったクリティカルな制御も、サイト側から指定できた方がいい。
そうやって明確な意思疎通ができるようになれば、エージェントは迷うことなく、もっと安全に、正確に、そして圧倒的に速く動けるようになります。
これまで「人間が読むためのページ」だったWebサイトが、これからは同時に「AIエージェントが直接操作するためのインターフェース」という側面も持ち始める。そう考えてみると、これからのWeb制作って、なんだか途方もなく面白い仕事になっていきそうだと思いませんか？
そこで、AIネイティブWeb監査・実装スキルを作りました
こうした一連の考察や仮説を重ねていく中で、私は頭の中のアイデアを実際の制作現場で使える形にするべく、SEO、AIO、LLMO、そしてAgent-ready UXまでをまとめて監査・実装するためのエージェントスキルを開発しました。
名前はシンプルに、「AI Native Web Auditor / Implementer Skill」と名付けています。公開リポジトリとしてGitHubにソースコードをすべてアップしてあります。
公開リポジトリはこちらです。
https://github.com/mocchalera/ai-native-web-auditor-skill
このスキルは、これからのAIネイティブ時代におけるWebサイトの品質を、主に次の6つの多角的な観点から厳しく監査・修正するために作りました。
SEO（検索エンジン最適化）： クロールやインデックスの成否、canonicalやsitemapの整合性、metaタグ、内部リンク構造、そして基本的な構造化データのチェック。
AIO / AI Search（AI検索最適化）： パーソナライズされたAI検索の回答において、自社の公式情報が正しく引用され、適切に要約されるための情報整理。
LLMO（大規模言語モデル最適化）： LLMが裏側で情報を読み込む際、要約、比較、根拠の抽出、情報の更新性、そして固有名詞（エンティティ）を正しく認識できるかどうかの精査。
Agent-ready UX（エージェント対応UX）： セマンティックなHTML構造、AIにとってもアクセシブルなフォーム設計、そして迷うことのない安定した行動導線の確保。
AI crawler governance（AIクローラー・ガバナンス）： robots.txtの適切な設計や、OAI-SearchBotとGPTBotなど、用途の異なるクローラーに対するポリシーの整理。
Performance / Accessibility（パフォーマンスとアクセシリティ）： Core Web Vitalsに代表されるモバイル体験の品質や、誰もが（そしてAIも）等しく情報にアクセスできる品質の担保。
リポジトリのREADMEにも記載した通り、これら複数の領域を包括的にカバーし、どこへでも持ち運んで適用できるポータブルなエージェントスキルとしての完成度を目指しました。
実際に運用中サイトへ使ってみた
この新しいWebのあり方を確信した私は、実験台としてさっそく、私が関わっている株式会社Livelyの公式サイトである「about.lively-talk.com」を、このスキルを使って徹底的に精査してみることにしました。
結果として、かなり面白いことが見えました。
まず、サイトの基礎的な土台そのものは決して悪くありませんでした。
最近リニューアルしたLivelyコーポレートのサイトは、Googleの品質測定ツールである「Lighthouse」のSEOスコアにおいて、「100点満点」を獲得しています。普通のSEO監査という枠組みで見れば、かなり良好な状態だと言えます。
さらに、昨今話題にあがることも多い llms.txt の運用についても先手を打っていました。そこには、Livelyが一体何をしている会社なのかという根本的な定義をはじめ、提供している「LivelyTalk」「聴く仕事ラボ」「Lively Academy」「法人向け研修」といった各サービスをどう区別すべきか、そしてこれらは決して医療行為や診断・治療の類ではないという重要な境界線までが、非常にクリアに整理されていたのです。
もちろん、Google対策の特効薬としてこのファイルを設置しているわけではありません。生成AI検索最適化ガイドでも説明されている通り、Google自身は「生成AI検索に露出するために llms.txt のような特別なAI用ファイルをわざわざ作る必要はない」というスタンスを取っています。
ただ、ブランド側が「AIにどうしても誤解なく渡したい公式情報」を棚卸しし、整理するための場所として捉えるなら、これは非常に優れた仕組みです。 「この会社は何者なのか」「何を提供しているのか」「逆に、何ではないのか」「それぞれのサービスをどう区別すべきか」――。こうした情報が1箇所にまとまっていることは、AI Truth Layer（真実の層）を強固にする上で、間違いなく大きな意味があると感じました。
しかし同時に、人間の目で見ているだけでは、あるいは従来のLighthouseのスコアを眺めているだけでは、決して気づくことのできなかった不備も次々と見つかったのです。
一番大きな衝撃だったのは、canonical（URLの正規化設定）の漏れでした。 サイト内にある131個のURLをすべて確認したところ、正しく rel=canonical が入っていたのは、なんとわずか2URLだけ。残りの129URLでは、設定が丸ごと欠落していたのです。 人間がブラウザでページを閲覧する分には、URLの正規化が漏れていようが何の影響もありません。しかし、検索エンジンやAI検索のクローラー、あるいはLLMが「このページの正しい正本はどのURLなのか」「重複した情報をどう扱うべきか」を厳密に判断しようとする時、この欠落は彼らを激しく迷わせる原因になってしまいます。
もう一つ、浮き彫りになったのが「構造化データ（schema.org）」の網羅性の低さでした。 組織を示す Organization や、サイト全体を示す WebSite は全ページに入っていましたし、お知らせなどの記事には Article や NewsArticle も適切に埋め込まれていました。 しかし、肝心のサービスページに Service の定義がない。FAQページに FAQPage の指定がない。講座案内のページに Course や Event のマークアップがない。そして、サイト内の階層を示すパンくずリストに BreadcrumbList のデータがついていない。 つまり、「人間には親切に読めるサイト」になっていても、AIや検索エンジンに向けて「このページは具体的に何の役割を持っているのか」という種別データを、十分な解像度で手渡せていなかったわけです。
さらに、Agent-ready UX（エージェント対応UX）の観点でも明確な発見がありました。 総合的なお問い合わせフォームについては、label や name、autocomplete といった属性がかなり高いレベルで整えられていたのですが、一方で「講座申し込みフォーム」を見直してみると、一部の入力欄に name 属性が抜けており、フォームの送信先を示す action や送信方法の method もHTML上で明示されていませんでした。 人間は画面の見た目や文脈から「ここに名前を入れて、このボタンを押せばいいんだな」と自然に理解して操作を完了できます。しかし、視覚を持たないAIエージェントにとっては、入力欄が持つ意味、データの送信先、そして送信が成功したのか失敗したのかという「状態」が、コードレベルで100%明確に示されていることこそが、エラーなく自律的に動くための大前提となります。
人間は画面を見ればなんとなく入力できます。
でも、エージェントにとっては、入力欄の意味、送信先、成功・失敗状態が明確であるほど扱いやすい。
この監査を行って何より痛快だったのは、これまでどこか抽象的だった「AI時代のWeb論」という大きな話が、明日からすぐに手を動かせる「具体的な修正リスト」へと見事にブレイクダウンされたことです。
canonicalを全ページに入れる
`WebPage`、`BreadcrumbList`、`Service`、`FAQPage`、`Course`、`Event`をページ種別に応じて追加する
AI検索用のクローラーと、学習利用のクローラーを分けてrobots.txtを設計する
サービスページの冒頭に「何のサービスか」「誰向けか」「対象外は何か」「料金や条件は何か」を明示する
フォームに`name`、`label`、`autocomplete`、`aria-invalid`、送信先、成功・失敗状態を整える
一見すると、どれも地味で泥臭い項目ばかりに見えるかもしれません。しかし、こうした細部を一つずつ丁寧に整えていくことこそが、これからの「AI Native Web」を実装するという行為そのものなのだと強く実感しています。 LighthouseのSEOスコアが100点だからといって、AIネイティブの観点でも満点とは言えない。ここへの気づきこそが、今回の最大の収穫でした。
これからの時代におけるWeb監査は、ただスコアの点数を取って安心するための儀式ではありません。 「人間には見えているけれど、AIには十分に渡っていない情報はどこか」 「人間なら難なく操作できるけれど、エージェントにとっては曖昧な行動導線になっていないか」 「検索結果の引用には出したいけれど、モデルの無断学習には使わせたくない場合、どうやってクローラーの方針を分けるべきか」 こうした、新しい時代の問いに対する答えを一つずつ見つけ出していく作業なのです。自分で作ったスキルを自社サイトに適応させてみて、このアプローチには非常に強い手応えを感じています。
「完璧なSEO対策」ではなく、検証可能な不備を潰す
開発の初期段階では、自分の中でもつい「SEOやAIO、LLMO対策を『完璧』にしたい」という表現を使ってしまいそうになりました。 しかし、厳密に言えば、この世界において「完璧」という言葉を使うのは少し危うく、不誠実であるとも言えます。
検索の順位がどうなるか、GoogleのAI Overviewに掲載されるかどうか、あるいはChatGPTの回答で綺麗に引用されるか、どれだけの流入やコンバージョンが生まれるか――それらを100%保証できる人間など、この世に一人も存在しないからです。そこをさもコントロールできるかのように語るのは、本質的ではありません。
だからこそ、このスキルでは「魔法のような完璧」を目指していません。私たちがやるべきことは、もっと地に足のついた、地味で確実な作業です。
重要なページが、robots.txt の設定ミスで誤ってブロックされていないか。
noindex が意図しないページに紛れ込んでいないか。
canonical の記述が壊れていたり、矛盾していないか。
sitemap.xml に記載されたURLと、実際のURLが綺麗に一致しているか。
構造化データとして裏側で定義している内容と、画面上の本文の記述に嘘や矛盾がないか。
AIが検索結果に引用すべき「正しい公式情報」が、隠されずにしっかりと本文内に存在しているか。
料金、条件、対応地域、実績、そして情報の更新日が、誰の目にも（AIの目にも）明白か。
問い合わせフォームや予約の導線が、AIエージェントにとってもプログラム的に理解しやすいか。
最新のAIクローラーに対する自社の運用方針が、正しくファイルとして整理されているか。
このように、外からは見えにくいけれど、プログラムとしては確実に「検証可能な不備」を一つずつ確実に潰していくこと。それだけが、私たちが取れる最も誠実なアプローチです。
たとえば、OpenAIが公開しているクローラーに関する公式ドキュメントを読んでも、ChatGPT検索のソースとして情報を探しにくる OAI-SearchBot と、大規模言語モデルの次世代学習に使われる GPTBot は、明確に用途が分けられて管理されていることが分かります。つまり、「検索の引用には積極的に載りたいけれど、自社のコンテンツをモデルの学習データとしてタダで吸い上げられるのは拒否したい」というように、運営者が主体性を持って方針を切り分けることが普通にできる時代になっているのです。 こうしたクローラー制御の設計も、これからのWeb運用における「当たり前のマナー」として定着していくはずです。
なぜCodex、Claude、Antigravity、Cursorに対応したのか
今回のスキルを開発するにあたって、私は特定のAIエージェントの環境だけに依存しないように強く意識しました。 これからの制作現場は、一つのAIツールだけに縛られるのではなく、プロジェクトのフェーズやエンジニア個人の好みによって、多種多様なAIエージェントを器用に使い分ける形になっていくと考えたからです。
そのため、思想や監査基準のコアは共通に保ちながらも、現場で使われている主要な開発環境のどれからでも呼び出せるよう、柔軟でポータブルなファイルセットとしてリポジトリを構成しました。具体的には、以下のような複数の設定ファイルやスキル定義を同梱しています。
各種エージェント用の包括的な定義ファイル群（AGENTS.md、CLAUDE.md）
各個別環境のためのスキルプロトコル（.agents/skills/ai-native-web-auditor/SKILL.md、.claude/skills/ai-native-web-auditor/SKILL.md、.agent/skills/ai-native-web-auditor/SKILL.md）
Cursor環境で威力を発揮するコンテキストルール（.cursor/rules/ai-native-web-auditor.mdc）
サイトを自動スキャンするための実行スクリプト（scripts/audit_site.py）
すぐに実装に活かせるテンプレートや具体例の数々（templates/、examples/、docs/）
開発者やデザイナーがどのようなエージェントとペアを組んでいようとも、この基準を持ち込んで即座にサイトを磨き上げられるようにするための、私なりの配慮でもあります。
技術の前に、まずコンテンツがある。言語化しなければ「存在しない」
ここまで、構造化データやフォームのアトリビュート、クローラーの制御といった、かなりテクニカルな部分に着目したスキルのお話をしてきました。しかし、ここで絶対に誤解してはならない、最も大切な前提があります。
それは、どれだけ技術的にAIへ最適化された「器」を作ったとしても、実際にユーザーに価値を届けるために最重要なのは、これまでと何ら変わらず「誰の、どんな悩み（何のため）に、何を届けることで、その課題を解決できるのか」という視点に基づく、コンテンツ作りそのものであるということです。本質的なコンテンツがなければ、どんなに美しいデータ構造も中身のない空っぽの箱に過ぎません。
そしてもう一つ、私たちが肝に銘じておくべき冷徹なファクトがあります。
私たちがどんなに素晴らしい思想や独自のノウハウ、強みを持っていたとしても、それをしっかりと「言語化」してインターネット上に解き放ち、オープンなテキストデータとして配置しない限り、AIはそれを読むことも、理解することも、誰かに推薦することもできません。
厳しい言い方をすれば、「あなたの頭の中だけに留まっている素晴らしい価値は、デジタルなAIネイティブの世界においては『存在しない』のと同じこと」なのです。
情報の受け手が人間からAIへと拡張される時代だからこそ、私たちはこれまで以上に必死に、自分たちの価値を言葉にし、データとして記述し、インターネットへ送り出さなければなりません。「言語化して、配置する」ということの重要性は、これからの時代、私たちの想像をはるかに超える重みを持つようになるはずです
これはツールというより、自分のWeb観のメモでもある
今回、こうして成果物を公開したわけですが、技術的な側面だけで見れば、これはスキル定義や監査項目のチェックリスト、CLIスクリプト、テンプレートの詰め合わせに過ぎません。 しかし自分の中では、このツールは単なる便利プログラムを超えて、「これからのWebを自分はどう見つめていくか」という、現時点での強いWeb観のステートメント（メモ）そのものでもあります。
Webサイトは、もう人間だけが読むものではない。 そして、検索エンジンのアルゴリズムだけに評価されるためのものでもない。
AIに正しく読まれ、美しく要約され、信頼できるソースとして引用・推薦され、時には人間の代わりにエージェントの手によって操作される。 その一方で、直接訪れてくれた生身の人間に対しては、これまで以上に体験的で、感情を揺さぶり、深く記憶に刻まれるための特別な場所になっていく。
だからこそ、これからのWeb制作という仕事は、
人間に、何を感じてもらうか（Human Experience）
AIに、何を真実として渡すか（AI Truth）
エージェントに、どんな行動を許すか（Agent Action）
この一見するとバラバラに見える3つの問いを、同じ1つのキャンバスの上で同時にデザインしていく、極めて知的でクリエイティブな営みになっていくのだと思うのです。
SEOは終わらない。でも、SEOだけでは足りない
「生成AIが普及したら、これまでのSEOは終わるのか」という議論をよく耳にしますが、私は全くそうは思いません。 むしろ、SEOが長年培ってきた基礎体力のようなものは、AIネイティブ時代においてこれまで以上に重要度を増してくるはずです。
検索クローラーが問題なく巡回（クロール）できること。正しくデータベースに登録（インデックス）されること。HTMLのマークアップが仕様通りに美しく書かれていること。他にはない独自の一次情報がそこに眠っていること。構造化データがファクトと完璧に連動していること。そして、訪れたユーザーの課題を解決していること。 これらの土台は、時代の主役が検索エンジンからLLMに変わろうとも、何一つ揺らぐことのない絶対的なベースラインです。
ただ、これからは「その土台の上に、新しい視点がもう数レイヤー乗っかってくる」というだけのことなのです。AIO、LLMO、そしてエージェントに開かれたUX。 私たちがすべきなのは、過去のSEOを古いものとして捨てることではありません。 これまでのSEOの技術を確固たる地盤（ベース）に据えながら、AIに愛され、エージェントに頼られ、最終的には人間の体験として心に残り続けるような、立体のWebへとその可能性を拡張していくことなのだと信じています。
これからやっていきたいこと
今回公開したスキルは、あくまで未来に向けた「最初の第一歩」に過ぎません。 これから先、実際の様々なWebサイトの監査や現場での実装にこの道具を泥臭く投げ込みながら、さらに解像度を上げて育てていきたいと考えています。具体的には、以下のような実践的なテーマをロードマップとして描き、順次アップデートしていく予定です。
WordPress、Shopify、Next.js、Astro といった、主要なCMSやモダンなフロントエンドフレームワークに応じた具体的な実装・組み込み例の拡充
日本語のニュアンスや特有の文脈を考慮した、日本語サイト向けのLLMO（大規模言語モデル最適化）監査項目の精緻化
AIが迷わずデータを吸い上げられるような、構造化データテンプレートのさらなる強化
主要なAIクローラーの最新の挙動に追従した、AIクローラー別 robots.txt テンプレートの最適化
クローラーがどのような挙動でサイト内を動いているかを可視化する、サーバーログ監査機能の追加
Google Search ConsoleやBing Webmaster Tools のデータと連携し、実際のインデックス状況と紐づける手順の確立
エージェントが途中でエラーを起こさずに決済や予約を完了できる、Agent-readyなフォームの実装パターン（ベストプラクティス）の標準化
Chromeチームの動向をはじめとする、WebMCP や UCP といった次世代のAIネイティブなWeb仕様への迅速な追従
これらの一歩一歩を進めていくことを考えると、これからのWeb制作という仕事は、本当に面白くなっていく予感しかありません。
ただ言われた通りにページを量産するだけの仕事は消えていくかもしれません。しかし、そのブランドが持つ固有の「体験」を設計し、AIに手渡す「真実」を紡ぎ、エージェントが軽快に駆け巡る「行動」の動線を美しく組み立てる仕事は、これからが本番です。
その大転換期に向けた、自分なりの最初の小さな旗印として、このスキルを公開しました。Lighthouseで100点を取って満足していた自社サイトに、まだ見ぬフロンティアが広がっていたあの高揚感を、ぜひ多くの制作者仲間と共有できたら嬉しいです。
もしこの試みに興味を持っていただけたなら、ぜひリポジトリを覗いてみてください。
バグの報告はもちろん、「もっとこういう観点が必要ではないか」という未来に向けたIssueや、改善のプルリクエスト（提案）も大歓迎でお待ちしています。新しいWebの形を、ここから一緒に作っていきましょう。
参考にした公式ドキュメントなど
2026年6月時点で、この思想のバックボーンとして（AIが）何度も読み込み、参照した重要な一次ソースたちです。深く学びたい方は、ぜひこちらもあわせてご覧ください。
Google Search Central: Optimizing for generative AI search
https://developers.google.com/search/docs/fundamentals/ai-optimization-guideOpenAI: Overview of OpenAI Crawlers
https://developers.openai.com/api/docs/botsweb.dev: Build agent-friendly websites
https://web.dev/articles/ai-agent-site-uxChrome for Developers: WebMCP
https://developer.chrome.com/docs/ai/webmcpGitHub: AI Native Web Auditor / Implementer Skill
https://github.com/mocchalera/ai-native-web-auditor-skill
