2026年3月27日、東京カルチャーカルチャーで開催された「JADEcon ─ JADE 春のSEO祭り」。連動企画として先週はレポート第一弾として下記の記事をアップしました。
今週も3本のライトニングトークをダイジェストでレポートします。登壇したのは、株式会社Faber Companyの小丸広海さん、シンクムーブ株式会社の豊藏翔太さん、SEO研究チャンネルの平大志朗さんの3名です。
LT1 ｜ AI Overviews 出現させてみた（小丸広海さん・株式会社Faber Company）
SEO歴17年、分析サイト数1,000超。1本目は株式会社Faber companyの小丸広海さんです。開口一番、会場にこんな問いかけをしました。
「AI Overviewsがあまり好きじゃないという方、どれくらいいますか？ ゼロクリックが加速したとか、嘘ばかり出てくるとか。半分ぐらいいらっしゃると思います」
手が挙がったのを確認して、「そんな皆様の気持ちを代弁しまして、今日はAI Overviewsを出現させてみた、という話をします」。
出やすいクエリ、出づらいクエリ
AI Overviews（以下AIOv）には出やすいクエリと出づらいクエリがあります。
「『…とは』『…方法』『…口コミ』『テールクエリ』——こういうものは高確率で出ます。逆に、『唐揚げ レシピ』『東京 新宿 時刻表』『大谷翔平 ニュース』『指名検索』——これらはほとんど出ない。実際に検索してみれば分かると思います」
指名検索もテールになると話が変わります。「ミエルカ単体では出ないけれど、『ミエルカとは』『ミエルカ 特徴』『ミエルカ 料金』では出てくる。このあたりのAIOvって、実はそんなに邪魔にならないんじゃないか。わざわざ説明をしてくれるので」
指名系クエリでAIOvが出たら
ある指名系の「料金」クエリのSearch Consoleデータを見ると、AIOvが出現したタイミングを境に平均順位が少し下がりました。AIOvが上に表示されることで1位・2位のカウントがずれるためです。ところがCTRは下がっていない。むしろ前期比で上昇し、クリック数も増えました。
「こういう特定のクエリにおいては邪魔にならないケースがある。もちろん逆のパターンもありますが」
これはGoogleが公開しているドキュメント「AI Overviews and AI Mode in Search」の記述とも一致します。
「Googleのポジション的な話も含まれていますが、一部事実もあるのかなと思います」
京伴祭の事例——やるべき施策をやったら、AIOvも出た
本題として紹介されたのが、劇伴音楽フェスティバル「京伴祭（KYOTO SOUNDTRACK FESTIVAL）」のSEO支援事例です。『NARUTO』『FAIRY TAIL』の高梨康治さん、『機動戦士ガンダム GQuuuuuuX』『呪術廻戦』の照井順政さん、『犬夜叉』『らんま1/2』の和田薫さん、『ブルーロック』の村山☆潤さん、『ハイキュー!!』『僕のヒーローアカデミア』の林ゆうきさんら著名な劇伴作曲家が集まる京都のイベントです（※上記お名前出ている方はいずれも2025年京伴祭の出演者）。
【京伴祭のHPはこちら】
「ご存知ない方も多いと思いますが、これを見たらすごいイベントだとわかるはずです」
（※ここでYouTubeに公開されている『京伴祭 –KYOTO SOUNDTRACK FESTIVAL– 2023』ダイジェスト映像〔https://youtu.be/VxUdUvu_Z68?si=RR7eThps-wFTNQXv〕の一部を再生）
類似イベントを調べると、「フジロック 出演者」「サマソニ 出演者」ではAIOvが出ていました。でも「京伴祭 出演者」では出ていなかった。「これは出せる、という確信を持ちました」。
やったことはシンプルです。それまでトップページにまとまっていた出演者情報を、アーティストごとの個別ページとして整備しました。翌日にはインデックスされ、「京伴祭 出演者」でAIOvも出現。高梨先生や照井先生、林先生の代表作が織り込まれた概要が検索結果に表示されるようになりました。
「ただ、これAIOvを出すためにやったわけじゃないんです。この施策は、AIOvがあろうとなかろうと提案していました。結果的にAIOvが出そうなところでデータを取っていただけで」
「AIOvから引用リンクを出してクリックを稼ごうという施策——本当に必要ですか？ AIOvがなかったとしてもやりますか？ というのは一度考えていただきたい。AIOvはもう実装されている、定着している。嫌ったところでしょうがないので、うまく付き合っていきましょう」
おまけ：AIOvの誤りはフィードバックで修正できる
発表の後半は「おまけ」として、AIOvの修正事例が紹介されました。「コマルフィシュキン」という小丸さんのSNS上のあだ名を検索すると、AIOvが「Maxim Komar-Myshkinと同一人物」「モザイクをつけられた男」などと出ていたそうです（司会の篠原さんによると「伊東さんが悪ふざけしたのが原因」とのことで、会場で謝罪がありました）。
AIOvのフィードバック機能から「事実と異なる」を選択し、「コマルフィシュキンはSNS上で特定の個人のあだ名であり、Maxim Komar-Myshkinとは無関係。コンテキストを無視してモザイクをつけられた男と紹介するのも不適切」と送信したところ、数十分で誤ったAIOvが消えました。
「間違っている情報が出るなら、どんどんフィードバックしていいと思います。AIOvはあくまでGoogle検索の機能の一部。自分たちでブラッシュアップしていくことはできます。ただし根拠もなく自分たちの都合の良いフィードバックを送るなどの悪用は厳禁ですし意味もないと思います」
LT2 ｜ AI×SEO診断 制作の裏側——あなたの「つい」が出る使い方を暴く！（豊藏翔太さん・シンクムーブ株式会社）
2本目は豊藏翔太さん。エン・ジャパン、ITコンサル、アイオイクスを経て、2024年12月にシンクムーブ株式会社を設立。著書に『AI時代のSEO戦略』。スライドは全編マンガ調のビジュアルで、「コードが書けないマーケター」という肩書きが吹き出しで添えられています。
「今日話す内容がSEOの本筋から飛びすぎてるんですよね」と前置きしつつ、コードが書けない人間がAIを使って診断コンテンツを作った話を始めました。
2つの診断コンテンツ
豊藏さんが作ったのは2本の診断コンテンツです。
ひとつ目は「SEO担当10タイプ診断」。「キーワード脳」「SERP観察民」「商談ファイター」「コンテンツ職人」など10タイプを、質問に答えながら診断できるものです。制作3日、公開2週間で2,500人が利用しました。コンセプトは「笑いながら自分を客観視できる体験」。
ふたつ目は「AI本性診断」。「AIの使い方には、その人の"本性"が出る」「俺たち全員、流派が違うだけ」というコンセプトで、「初手キメ太郎」「思考ラリー中毒」「おまかせ脳」「70点即GOマン」など10タイプに分類します。利用者数は1,000人超。
なぜ診断コンテンツか
「生成AIが出てきて、ノンブランドのクリック率がどんどん下がっています。読むコンテンツは埋もれやすい。でも診断コンテンツは、『これ俺だわ』ってなって拡散する。読むより参加するほうが、人は動きます」
設計の目的は2層でした。バズ狙い（シェア体験の設計）と、ブランディング（シンクムーブ＝「思考設計ができる会社」という認知）。リード獲得フォームはあえてつけませんでした。「ゲートがあるとシェアされない。認知に割り切りました」。
診断コンテンツの設計で特に気をつかったのが、「良い・悪いで分けない」ことです。「AIをどう使うかで、その人が優れているかどうかを判断するようなものにしたくなかった。あなたはこういう傾向があるよね、と言語化するだけ。優劣をつけない設計をかなり意識しました」
3者の役割分担
制作体制は3者の役割分担で成り立っていました。
- 自分（Director）：コンセプト設計・面白さの判断
- Claude（Advisor）：相談相手・要件定義・コード修正
- Antigravity（Executor）：実装・デプロイ
「詰まったら逆のAIに聞く、というのも意識していました」
制作フローはStep1からStep6まで。コンセプト設計（Claude）→ 要件定義（Claude）→ テキスト制作（Claude）→ 実装（Antigravity）→ テスト・修正（両方）→ シェア機能・OGP動的生成（PHP）。
詰まりポイント① 雑に投げたら雑に返ってきた
「最初に『SEO担当向けの診断を作って！』ってそのまま丸投げしたんですよ。そしたら、動くんですけどロジックが曖昧で、粒度もバラバラで、全部やり直しになって」
「AIは『何でも作れる』が、『何を作るか』は知らない。設計の甘さが、そのまま出力に乗ります」
対策は対話で積み上げる要件定義です。「タイプ名は何個にするか、質問文はどうするか、JSONの構造はどうするか——一発で完成させようとせず、Claudeと対話しながら要件定義書を作っていく。対話で積み上げたほうが、精度が高い」
詰まりポイント② WordPressでCSS全崩壊
検証環境では問題なかったスタイルが、WordPressにデプロイした途端に崩れました。テーマのCSSとクラス名が衝突したためです。「解決策はシンプルで、全CSSセレクタを#ai-prompt-diagnosis-appというIDの配下に閉じ込める。スコープを明示的に区切ることで干渉を防ぎました」
詰まりポイント③ シェア設計が一番難しかった
「作るより、シェアさせる方が難しかった」
Xでシェアしたとき、タイプごとに異なる画像が出てほしかったのに、全員に同じデフォルト画像が出てしまいました。「原因は、クローラーがJavaScriptを実行しないので、JSで生成したOGP画像を認識できなかったこと。解決策は、URLパラメーター（?result=type）をPHPでサーバーサイドから読み取り、metaタグを静的に出力する方法です」
Twitter Card Validatorでは「OK」が出ているのに直らない——と焦ったら、キャッシュをクリアし忘れていただけだった、というオチもありました。
世界観が先、実装は後
「俺たち全員、流派が違うだけ」というコンセプト、マンガ・バトル調のビジュアル、「流派」というネーミング——これらは実装より先に確定させました。
画像生成にはNano Bananaを使いましたが、「おしゃれな女性キャラ」とだけ指示すると解釈がバラバラになってしまった。そこでYAMLで詳細に定義しました。
gender: female
archetype: 思考家
vibe: 早口・エネルギッシュ
habits: ノートが付箋だらけ
「こう書いたら、一気に世界観が統一されました。世界観があれば、実装・デザインは自然に決まる。AIは世界観を持てない。人間が持つ必要があります」
締めくくりのメッセージはこうでした。
「誰でも作れます。ただし1つだけ条件があります。『これ面白いか？』を考え抜く根性。雰囲気で作るとボツになる。最後は熱量です。コードが書けないは、今日で終わり」
LT3 ｜ SEO業務にAIを活用する方法（平大志朗さん・SEO研究チャンネル）
3本目は平大志朗さん。ClaudeとMCPを連携してSEOを自動化する話はnoteに書いているのでそちらもぜひ、と前置きしたうえで始まりました。
AIでSEO分析を自動化する方法（Claude × MCP）｜SEO研究チャンネル
「今日お話しするのは、AIを使って今まで工数が足りなくてできていなかったことを、どう実現するか、という話です」
Search Consoleの「区分」問題
皆さんも毎日見るSearch Consoleですが、標準機能でできる区分には限界があります。最近ブランド/非ブランドのフィルターが追加されましたが、「確かに増えたけど、使い勝手や精度がまだ……」というのが正直なところです。
BigQueryを使えばSQLで特定のブランド名を含むクエリは集計できます。でも、こんな区分でサクッと見られたら便利だと思いませんか。
「クエリ単位で予想不可能な区分は、BigQueryのSQLだけでは対応が難しい。ここでLLMを使います」
LLMでクエリにフラグを付ける
フロー全体はシンプルです。
サチコ → BQ → Cloud Engine（LLM） → SQL → Looker Studio / QuickSight
BigQueryからデータを引き出し、Cloud EngineでLLMのAPIを呼び出して各クエリにrevenue_coreやinfoといったセグメントコードを付与。SQLサーバーに格納し直してダッシュボード化します。
「Batch APIを使うと、同期実行よりコストを抑えやすいケースがあります。情報を外に出したくない場合はローカルLLMも使えます」
これにより、「最近流入が落ちていますが、インフォ系クエリは問題ないはずです」というメンバーの報告に対して、「でも収益直結系のクエリは落ちているよね」という指摘をデータで即座にできるようになります。「今まで工数が足りなくてできていなかったことが、LLMと組み合わせることで実現できる。皆さんが普段見ているLooker Studioを、自社に合った区分でもっと意味のあるものにできます」
大量ローデータをLLMに読み込ませない
「コンテキストウィンドウは今すごく広がっています。ClaudeはOpus 4.6とSonnet 4.6向けに1Mコンテキストが一般公開されました。読み込もうと思えば読み込める。でも、やりません」
なぜか。Anthropicのドキュメントにも書かれているとおり、コンテキストウィンドウはモデルの「ワーキングメモリ」として機能します。トークン数が増えるにつれ精度と再現率が低下する——「コンテキスト劣化」と呼ばれる現象です。
「優秀なマーケターに大量のローデータを渡して、ここから何が分かるか考えて、とは言いませんよね。集計後のデータを渡して、経験を踏まえて何が言えるか、と問うのが力の使い方の最大化です。LLMも同じです」
「記憶・計算はBigQueryやSQL、思考はLLM——適材適所に役割を分けることが重要です」
MCPにつなげれば大丈夫、ではない
Search Consoleと接続したMCPサーバーを使えば、LLMからSCデータを扱えるようになります。しかし実験してみると、中規模のデータベース型サイトで「このサイトのSEO改善点を出して」と依頼したところ、LLMはいきなり末端クエリの比較を始め、一般論的な提案を返してきました。
「中規模DB型サイトで、いきなり末端クエリを見る人はいませんよね。DB型サイトなら最初にクロール到達性、インデックスカバレッジを確認する。SEOを長くやっている人には当然の分析順序がありますが、素のLLMには領域特化の経験がない」
MCPでデータへのアクセスは可能になっても、どこからどう見るかという要求設計・要件設計は人間側の仕事です。「だからこそ、データをどの切り口で見るかが超大事。経験則による直感と、正しいドリルダウン——ここは人間が担う必要があります」
熟練者の経験則や分析の指針をProject KnowledgeやSKILL.mdとして言語化してLLMに渡すことで、「人間と同じ分析ができる」状態に近づけられます。SEOに特化したAgent Skillsの構築という展望も示されましたが、「まだ発展途上です。まずは部分的な置き換えから」と締めくくられました。
AIに何を任せ、人間が何を担うか
3本のLTに共通していたのは、「AIに何を任せ、人間が何を担うか」という問いでした。
小丸さんの「AIOvを出すためにやるのではなく、やるべき施策をやった結果AIOvも出た」。豊藏さんの「世界観はAIが持てない、人間が持つ必要がある」。平さんの「要求設計・要件設計は人間の仕事」。
AIが高度になればなるほど、人間に問われるのは「何のためにやるか」「どこを見るか」「何が面白いか」という判断の質、と理解しました。小丸さん、豊藏さん、平さん、素晴らしいLTをありがとうございました！
【第一弾・第三弾のレポートはこちら】
