森野誠一の毎日堂マーケティングラジオ。この番組は、私が平日毎日発行しているニュースレター【毎日堂のトピック】をもとに、SEO、広告、EC、AIなど11ジャンルをその道の専門家の本音で掘り下げる番組です。
今日も現場のリアルな事件をニュースラームの皆さんにお届けしていきます。今回はJadeさんのスタジオをお借りして、現地収録というのは初めてですかね。緊張しておりますけども、Jadeの永山さんです。よろしくお願いします。
いつもZoomでやっているので、緊張するというか、どこに原稿を読んだらいいかわからないですけど、全然ゆるっとやっていきましょう。
永山さんにはマーケティング関連というか、Jadeさんのアメディストというツールが出されているので、その辺についてお聞きしたいと思います。
そもそもですね、アメディストってJadeさんが何で作ろうと思って、どんなことができるツールかというのをまずお聞きしたいんですけども、Jadeさんってツール会社じゃないですもんね。
ツール会社の定義によるかなと思うんですけど。ツール専門ではないですもんね。ツールだけやってるわけではないですね。どんなツールなんですか、そもそもこれ。
そうですね、背景というか経緯みたいなところから話していくと、自分ってもともとGoogleにいて、プラットフォーム側でSEOを別にやってるわけではなかったわけですよね。
なので、SEOっていうのは多分こういうふうにやるんだろうなっていうイメージというか考え方みたいなものは持っていたんですけど、実際にGoogle辞めて、Jadeを立ち上げて、自分がSEOをやる側になった時に、
多分こういうツールが必要だろうなということを考えて、こういうツールあるのかなと思って探したんですけど、何か分かんないけどそういうツール全然ないぞと。
いわゆるSEOツールっていう中に長居の参考資料がなかったと。
具体的にどういうことかというと、SEOって僕の考え方の中では、まずファーストパーティーデータというか、例えば自分のサイトのサーチコンソールであるとか、自分のサイトのGA4であるとか、
あるいはウェブマーケティング全体を捉えると、自分のサイトの広告分野に関するデータであるとか、っていうところをきちんと分析していくところからだろう。
自社にあるデータをきちんと分析していくということですね。
というふうな発想だったんですけど、ちょっと探してみても、そういった発想のツールが全然なくて。
個別のツールはあったり、記事の管理とかそういうキーワードのツールがいっぱいありますけどね。
そうなんですよ。例えば代表的なところで言うと、検索結果をスクレーピングしてきて、
順位チェックとかね。
EJFとかセブンラッシュのように、勝手にサービス側でいろいろ検索結果のスクレーピングをしてきて、
あるいはウェブのクローリングをしてきて、そのデータが見れますみたいなツールであるとか、
あるいはAWRであるとか、今は無き、何でしたっけ、デスクトップであるやつ。
GRC。
自分でキーワードを設定してスクレーピングしてくる、みたいなツールがまずあって、
それ以外で言うと、例えばこういうキーワードを狙うといいですよ、みたいなキーワードボリュームツールとか、
このキーワードに関連するキーワードはこれですね、みたいなキーワードサジェストツールみたいなものが大半で。
そうですね。SEOツールっていったらそういうイメージですね。
そうなんですよ。でも別に自分のサイトの順位なんて知りたかったらサーチコンソール見ればいいじゃん、みたいな。
乗ってますね、キーワードとページで。
もちろんサーチコンソールUIがめちゃめちゃ使いづらいので、それはAPIで何とかするとか、
実は作り始めた時はまだビッグクエリエクスポートがなくて、あくまでAPIで頑張って取れるだけ。
直接取ってきたんですね。
取ってきて、ビッグクエリに保存して、そのビッグクエリを叩くみたいな。
なるほど。
もともとは、アメジスト以前はデータポータルを使っていて、
ルッカースタジオ、データポータル、データスタジオ、ルッカースタジオ、データポータルですね。
現在の正式名称はデータポータル。
当時の正式名称は何だったか覚えてないんですけど。
ビッグクエリにAPIから取ってきたデータを貯めて、それをデータポータルでダッシュボードを作るということをやってました。
あるいはクロール率、インデックス率っていうところですね。
これについてもあんまりまともな。
そうですね。そういうツール見たことない。
そうなんですよ。
でも、これも結局会社を辞めた時に、SEOに関する考え方を教えてくれるフレームワークみたいなのはどういうものがあるのかみたいなものを探してみても全然見つからなかったんで。
自分で作ろうと思って自分で作ったんですけど。
これもSEOに関する考え方のフレームワークを弊社に出している検索インタラクションモデルっていうものを僕が作ったんですけど。
中でURLを発見させてクロールさせてインデックスさせると。
それを行わないと順位がつかないよねっていうところがあるので。
分解していくとどれくらいクロールされてるんですかとか。
あるいはどれくらいインデックスされてるんですか。
単にインデックスされているURLの本数ではなくて、文房をインデックスしてほしいURLにした時にそのうち何パーセントがインデックスされているのか。
あるいはクロールされているのかみたいなことを知りたいわけで。
単純にサーチコンソールだと何本インデックスされてます。
そうですね。インデックスされた数だけですね。
かつその数の具体的な中身は非常に小さな数のサンプルしか見せてくれないみたいな。
あるいはランダムサンプルですらない。
この中で最近インデックスされたやつかなみたいなのが出てくるので。
じゃあちゃんとクロール率インデックス率を計測したいときにどうすればよいのか。
これも当時はまだURLインスペクションAPIがなかったので。
それこそ検索結果をスクレーピングしてきてURLとかでやるしかなかったんですけど。
作ってるうちにURLインスペクションAPIが出てきたので。
じゃあこのURLインスペクションAPIを活用してただ1プロパティあたり1日2000件という上限があるので。
それをフル活用するためにはどのようなシステムが必要かみたいなところをまず考えて。
っていう社内で使うようにまず作ったものだったんですよね。
そもそもそういうツールがなくてどうしようかと思ってじゃあ作ろうってなって。
社内でSUってこういうものだとフレームワークにはめていくとこういうデータがいるねこういうデータがいるねってやっていった結果そうなったということなんですね。
それが売り物になっていったという。
作ってこれなんかいいねと。最初はデータポータルだったんですけど。
毎回新しいクライアントが入るたびに同じダッシュボードを作らないといけないので。
これはもうめんどくせーなっていうことでアプリ化しちゃおうと。
アプリ化するんだったら自分たちでももちろん使うんですけど自分たちが便利に使っているものだからどっか便利に使う人たちもいるであろうと。
ということでツールとして売っちゃいましょうかという感じで売り出したという感じですね。
確かにデータポータルで毎回作るのは大変ですよね。
なので単純に毎回データポータルと向き合わなくてもいいっていうだけでも弊社のコンサルティングの効率化というところには。
読み込みも早くなるし。
そうですね。めちゃめちゃこだわってるんで。
アメージストを作ろうとしたんじゃなくてSEOの状況を分かろうとして作ったものがアメージストになったという感じなんですね。
なるほど分かりました。
その中でアメージスト作業したってビッグケーリとかサーチコンソールがあって今GFOもデータ入りますよね。
あとはMCPでもつながるとか色々どんどん広がっていくんですけども。
そういった人間がデータ見に行ってたじゃないですか管理画面サーチコンソールとかGFOに。
それはもうなくなっていきます?ジードさんの中だと。
我々の中ではもうほぼサーチコンソールとかGFOのUIって見てないです。
それはビッグクエリデータの方が完全なデータだから。
サーチコンソールとかそれこそUIだとトップ2000件しか見れなくて。
しかもディメンションもクエリとURL同時に選択できないみたいな。
そうなんですよね。なぜか分かれてるんですよね。
なぜかディメンションが一個固定みたいな感じ。
なのでUIを使うっていうのは論外で。
かつデータの量も例えば特明化クエリが何パーぐらいあるのかみたいなところがそもそもUIだとわからないですけど
ビッグクエリに吐き出せばほぼ完全なデータが取れるので
特明化されたクエリが何パーかもわかるので
まずビッグクエリ以外をデータソースにするっていうことがまずあり得ない。
GF4もそうでGF4も無料でビッグクエリにエクスポートすることができますけど
例えばUIだと2ページ目の分析というのができない。
昔あったやつ。
ユニバーサルアナリティクスの時代はあったのに
要は1ページ目ここに来た人が2ページ目どこに行ってるのか。
こんな単純な分析なのに。
前のページ後のページってやつないですよね。
なぜかできない。
Amazistではデフォルトでそれができるようにしているので
データの完全性という点でも
要は一定程度になっちゃうとサンプリングかかっちゃったりとか
性格性っていう点でもあるいはこういうディメンションで見たいよねっていうところから
もうあんまりUIを見る理由がもうなくなってきた。
これはクライアントもAmazistを見てクライアントも画面見なくなっちゃったんですかね。
もちろんAmazistは見ていただいてると思う。
それぐらいクライアントさんがサーチコンソール見てないかっていうのは
クライアントさんによるのかなという気がしますけど
見てもデータが食い違っちゃうんで
じゃあどっちなのってなったりするとね。
できるだけ食い違わないようには作ってるんですけど実は
食い違う時もあるっちゃあるってことです。
サーチコンソールとかGFOの画面見ずにやってるってなかなか想像しづらい人いそうですよね。
結構いますよね。
ほぼそうなってますよね。
AIでやる人もいるんでしょうけどね。
そうですね。
AIといってもビッグクエリベースではないAI
GFOのMCPとかですね。
そうですね。API叩くことになるんで結局。
じゃあAPIでこれぐらいのボリュームだとサンプリングかかりますよねみたいな
基地の問題が実はAPIには数多くあって
結局その問題をAIが引き継ぐってことになるので
我々としてはデータソースをビッグクエリ以外にするっていうことが
まず論外というか。
良くないよねっていう感じ。
一回生のデータちゃんと入れましょうってことなんですよね。
そうですね。
確かにそれはそうですよね。
今までなんでなかったんだろうぐらいな感じではありますよね。
よく考えたらね。
そうなんですよ。
自分のデータなのになぜかUIでは見れないみたいな。
確かにそうですね。
あれぐらいでいいだろうと思われてるかもしれないですけどね。
かつAIが例えばビッグクエリにエクスポートしていたとしても
AIが直で例えばGFOのビッグクエリのエクスポートデータを読みに行くのって
意外と大変なんですよ。
それはなぜかというと
GFOのビッグクエリエクスポートのデータって
非常に複雑で癖のあるテーブル構造をしているんですよね。
結構このGFOのビッグクエリエクスポートデータって
実はもう10年ものぐらい。
そんなに経ってるんですね。
要はGFOってもともとファイアベースアナリティクス
アプリ向けに作られたものなので
それがアプリ向けだった時代に作られたエクスポートの構造なんですよ。
もちろん広報互換性の関係で
ドラスティックにそこに手を入れるっていうのが実は難しくて
要は今までエクスポートし続けたところに
新しいのをエクスポートしたら壊れましたみたいになっちゃうと
データの継続性が壊れちゃうので
ドラスティックに変えることっていうのは結構難しくて
新しくデータを増やしましたみたいなことはできるんですけど
今まで存在した構造そのものを変えるっていうのはできないんですよね。
っていう中でかなりユニークというか
昔のテーブルならっていう感じの構造をしているので
AIがこのテーブルSQL拡大ってなると
結構考えないといけないことが多くて
トークンを無駄に消費してしまったりとか
あるいは間違ったSQLに変えちゃったりとかっていうことがあるので
我々はアメジストをMCP対応して
アメジストを呼び出せば
アメジストはもうこのデータを扱うのがめちゃめちゃ得意なシステムなので
わざわざAIが自分のSQLに書かなくても
アメジストが全部やりますっていうシステムを作っている
ビッグクエリに詳しい人がやってくれてる感じがあるという感じですね
一回ビッグクエリでGFのデータ見たことあるんですけど
まあこれめんどくさいなと思いながら
見た瞬間にこれSQLでやってる人すごいなと思いながら
そうなんですよ
それも解消してくれると
解消してくれます
なるほど