【brightonSEO San Diego 2026】エージェント時代のデータ戦略と開発｜Ray Grieselhuber氏

https://speakerdeck.com/player/1b428230180d4ee58304f9008824058c

Ray has published the full deck on Speaker Deck. Slide references below follow it.

スライドはSpeaker Deckで全編公開中。以下、スライドに触れている箇所はこの資料に沿っていますのでご参照ください。

TL;DR
要点まとめ

• Agentic engineering removes SEO’s oldest bottleneck. For decades, SEO work waited on product and engineering teams. Migrations, analytics at terabyte scale, and large-scale content planning that took years can now take months.

・開発チーム待ちの時間がなくなる。サイト移行、テラバイト級のデータ分析、大規模サイトのコンテンツ設計など。数年かかっていた仕事が数か月に

• Vibe coding and AI-driven engineering are different things. Vibe coding is for prototypes and early user feedback. AI-driven engineering is for products, and what separates the two is deployment and ongoing operations.

・「バイブコーディング」と本格的な開発は別物。バイブコーディングは試作と早い段階の反応集め用、本格的な開発は製品用。その分かれ目は公開と運用

• Get “hello world” live before building features. Ray’s Milestone 0 is the simplest possible version running in production, because a product succeeds on how fast it can iterate through automated deployments.

・機能を作るより先に「Hello World」を本番へ。製品の成否は、自動で公開する流れをどれだけ速く回せるかで決まる

• Tests are the most important thing you build. Every bug found should become a regression test, so it never happens again.

・いちばん大事な成果物はテスト。見つけた不具合は必ずテストとして残し、同じ不具合が二度と起きないようにする

• Don’t become “The One.” The people with the vision end up building everything themselves. Spread the knowledge so more than one person can build.

・作れる人が自分だけにならないようにする。構想を持つ人ほど全部自分で作ってしまうので、知識を広げて作れる人を増やす

About the Speaker
登壇者について

Ray Grieselhuber is the founder and CEO of DemandSphere, an SEO and AI search data platform. He comes from an engineering, data science, and machine learning background, with more than 18 years in enterprise and technical search marketing. Before DemandSphere, he built an early enterprise SEO platform at Covario, and in 2015 he co-founded Functionize, an AI-powered test automation platform.

DemandSphere社 創業者兼CEO、Ray Grieselhuber氏。

エンジニアリング、データサイエンス、機械学習が専門。大企業向け・技術寄りのSEOに18年以上従事。

前職のCovarioでは初期の大企業向けSEO基盤を開発。2015年にはテスト自動化のFunctionizeを共同創業。

A year earlier, on the same San Diego stage, he had predicted that 2026 would be the year of agents, and he admitted that even he was surprised by how wild things have turned out.

1年前、同じサンディエゴのbrightonSEOで「2026年はエージェントの年になる」と話していましたが、「ここまでとは自分でも思わなかった」と苦笑していました。

He gave a brief tour of DemandSphere’s own products, which doubled as the working example behind the rest of the talk:

• A workflow automation builder
• Enterprise rank tracking across 200+ markets
• Brand visibility tracking across AI Mode, AI Overviews, ChatGPT, Perplexity, Gemini and Copilot
• Real-time log file analysis with AI crawler tracking
• A search data warehouse queryable with SQL
• APIs over all of it

DemandSphereの製品も紹介されました。後半の説明に出てくる具体例にもなっています。

・作業の流れを自動化する仕組みを組めるツール

・200以上の国と地域における検索順位の計測

・AI Mode、AI Overviews、ChatGPT、Perplexity、Gemini、Copilotの回答に、自社の名前がどれだけ出てくるかを追う機能

・サーバーのアクセスログをリアルタイムで解析する機能。AIのクローラーの動きも追跡可能

・SQLで検索可能なデータの保管庫

・これら全てを外から呼び出せるAPI

How He Framed the Talk
セッションの狙い

He set expectations early: this was a session for building a map, not for following every detail. He said he would move fast, start high level and finish technical.

冒頭で、細かい部分を追う回ではないと断りがありました。

前半は抽象的、後半は技術的になるので、全部分からなくても大丈夫、とのこと。

The goal he stated was not to sell anything:

• Promote more fluency in building repeatable systems with AI
• Help decision makers understand what it takes to support AI-engineered products

何かを売り込むための講演ではない、とした上で、狙いは以下の2点。

・AIで同じ品質のものを繰り返し作れる人を増やすこと

・決裁する側に、AIで作った製品を維持するには何が必要かを知ってもらうこと

The practical reason for it: client teams and decision makers keep asking whether they should build tools internally on top of their data, and in his experience few have the right heuristics to answer that question.

クライアントや決裁するポジションの人から「自社のデータを使って、ツールを社内で作るべきか」とよく聞かれるそうです。

ただ、それを判断する基準を持っている人はほとんどいない、とのこと。

His deck also carries a line he didn’t dwell on out loud: many of the same engineering principles apply in both product and data engineering. That is where the title and the content meet.

口頭ではあまり触れられなかったですが、スライドには

「開発の原則の多くは、製品の開発にもデータ基盤の開発にも同じように当てはまる」
というパートがあり、タイトルの「データ戦略」と、中身の「開発の話」がつながるのはここかと思います。

The stated conclusion: a framework to help you build more reliable products.

結局のところ、壊れにくい製品を作るための考え方が一番だという結論です。

Ray’s Talks Over the Years
Ray氏のこれまでの講演

Ray has spoken at brightonSEO many times, and his talks trace how the industry’s questions have changed.

Ray氏はbrightonSEOに何度も登壇しています。私もいつも楽しみにしている講演ですが、並べてみると、業界の関心がどう移ってきたかが見えてきます。

• 2023 to 2024: measuring the SERP. “Measure the whole SERP at any scale” (San Diego 2023) and “Going beyond ‘what happened?’ in SERP analytics” (Brighton and San Diego 2024) were about tracking the full search results page at scale, and getting past simply reporting what changed.

・2023年〜2024年：検索結果を測る

「Measure the whole SERP at any scale」（サンディエゴ2023）と「Going beyond ‘what happened?’ in SERP analytics」（ブライトンとサンディエゴ2024）。検索結果ページ全体を大きな規模で追うことと、「何が起きたか」を報告するだけで終わらせないことがテーマでした。

• April 2025, Brighton: how AI answers are built. “Exploring relationships between AI answer engines and organic SERPs” explained retrieval-augmented generation (RAG), where AI tools search an index before answering. His data showed about 80% of AI responses relied on Google and Bing indexes, with Perplexity drawing about 55% from Google.

・2025年4月、ブライトン：AIの回答はどう作られるか

「Exploring relationships between AI answer engines and organic SERPs」。AIが答える前に検索して材料を集める仕組み（RAG）の解説です。AIの回答の約80%がGoogleとBingの検索結果に頼っていて、Perplexityは約55%がGoogle由来、というデータが出ていました。

• September 2025, San Diego (repeated in Brighton that October): it’s all AI search. “It’s ALL AI search now: building a unified view for growth” argued that “traditional versus AI search” is a false dichotomy, since Google pioneered much of what we now call AI search. He showed AI tools running 8 to 12 background searches per prompt.

・2025年9月、サンディエゴ（同年10月にブライトンでも）：全てがAI検索の時代

「It’s ALL AI search now: building a unified view for growth」。従来の検索とAI検索を分けるのは誤りで、いまAI検索と呼ばれているものの多くはGoogleが先に作ってきたもの、という主張でした。AIが1つの質問の裏で8〜12回検索している様子も示されています。

• September 2026, San Diego: building with agents. This talk moved from understanding and measuring search to building tools and products on top of that data.

・2026年9月、サンディエゴ：開発トーク

今回は、検索を理解して測ることから、そのデータの上にツールや製品を作ることへ軸が移りました。

The Problem: Product Was Always the Bottleneck
問題：開発チームを待つ時間が長い

Ray opened with why a talk about building software belongs at an SEO conference. In his view, this year has been exceptional for the industry, because agentic engineering lets teams solve problems that have held SEO back for decades.

まず「ソフトを作る話が、なぜSEOのカンファレンスに出てくるのか」からスタート。

今年は業界にとって特別な年だ、という見立てです。AIエージェントを使った開発で、何十年もSEOの足を引っ張ってきた問題が解けるようになったから、とのこと。

His examples:

• Site migrations, including moving to new infrastructure without changing the architecture
• Platform moves, from one CMS or ecommerce platform to another
• Analytics at scale, working with terabytes of data
• Content planning for large ecommerce sites

例

・サイトの移転。構成はそのままで基盤だけ新しくする場合も含む

・土台の変更。CMSやECの仕組みを別のものに変えること

・大規模なデータ分析。テラバイト単位を扱う作業

・コンテンツ設計。大規模なECサイト向けのもの

The common thread is that SEO teams almost always depended on product and engineering, and product was the bottleneck. Not intentionally, but because of how organizations prioritize and how product teams are motivated. That is starting to change.

どれも共通しているのは、SEOチームが開発チームに依存していて、そこで詰まるとそこから先に何も進まなかったことです。

なにか悪い意図があったわけではなく、組織の優先順位と、開発チームが何で評価されるかという問題です。

それが、いま変わり始めています。

Ray’s broader framing: good search marketing is good product management, and vice versa. He described search performance as a leading indicator of how well a company is run, from the executive level down.

もう少し大きな話だと、良いSEOマーケティングは良い製品づくりであり、逆もまた然り。

検索の成果は、経営陣から現場まで、その会社がうまく回っているかを先に示す指標だ、という見方です。

Context: Service as Software
文脈：ソフトを売るのか、仕事を売るのか

Ray spent part of the talk on a business idea that explains why this shift matters beyond SEO.

この変化がSEOの外でも重要な理由として、ビジネスの話にも時間を割いていました。

When he co-founded Functionize, the test automation market looked like a tooling business. But the tool companies topped out at modest revenue, which he put at around $20 to $30 million for some and $80 million for others, while a services company in the same space was doing billions in QA engineering and managed QA. Companies weren’t buying tools; they were buying the job getting done.

Functionizeを共同創業したころ、テスト自動化の市場はツールの販売だと思っていたそうです。

ところがツールの会社は売上が頭打ち。2,000万〜3,000万ドル、大きいところでも8,000万ドルほど。

一方で同じ領域の受託サービス会社は、テスト業務の代行で数十億ドルを動かしていました。

客が買っていたのはツールではなく、仕事をサポートしてくれるサービスだったというわけです。

His conclusion is that SaaS increasingly needs to be thought of as “service as software”: delivering the completed outcome in a programmatic, parameterized way that feels turnkey without being custom-built each time. Processes that used to be human-driven are becoming agent-driven, and that is what makes this model viable.

ここから出てくるのが「サービス・アズ・ソフトウェア」という考え方。ソフトで仕事の完了そのものをサポートするビジネスです。

毎回オーダーメイドで作るのではなく、決まった形に条件を差し込む。それでも客からは自分用に用意されたように見える。人がやっていた工程をAIが担えるようになって、この形が成り立つようになりました。

He also named what he called the dirty little secret in SaaS. VCs dislike consulting revenue, so software companies disguise or outsource it. Salesforce, he pointed out, relies on a huge partner network for delivery. The services were always there.

「SaaSの、ちょっと闇深い話」にも触れていました。

投資家は受託の売上を嫌うので、ソフト会社はそれを隠すか外注する。Salesforceでさえ、実際の導入は巨大なパートナー網に任せている、とのこと。サービスは最初からずっとそこにあったというわけです。

And a side note that got a laugh: whenever you hear “X is dead,” whether SEO or SaaS, remember that founders are coached to use that phrase in fundraising to convince investors the old thing is over and they are the new thing. You don’t have to adopt the language.

会場でウケていた余談では、「○○は死んだ」という言い方を聞いた時は、たとえそれがSEOでもSaaSでも、創業者が資金調達の場で使うよう教わる決まり文句だと思い出してください、と。古いものは終わっていて、次は自分たちだ！！、と投資家に思わせるためのものなので、その言い方に乗る必要はない、とのこと。

The Solution: Know When to Vibe Code and When to Engineer
解決策：雰囲気で作る段階と、きちんと作る段階を分ける

Ray was clear that vibe coding shouldn’t be looked down on. It has a specific purpose.

バイブコーディングを見下すべきではない、役割が異なるだけ。

• Vibe coding is for building prototypes and getting user feedback as early as possible. That feedback is the most important thing you can get.
• AI-driven engineering is for building products. A product is something you have to commit resources to, both people and money, to maintain and operate.

・バイブコーディング（AIに雰囲気で作らせること）は、試作品を作って、できるだけ早く使う人の反応をもらうためのもの。この段階では、ユーザーの反応がいちばん大事です。

・AIを使ったきちんとした開発は、製品を作るためのもの。ここで言う製品とは、人とお金をかけて動かし続けると決めたものを指します。

The dividing line is deployment and operations. When a team tells decision makers “I can build this,” the right answer is to let them, but also to evaluate honestly what ongoing support and operations will require.

分かれ目は公開と運用です。

「これは自分たちで作れます」とチームが言ってきたら、作らせていい。ただし同時に、そのあと保守と運用に何が必要になるかを正直に見積もるべき、とのことでした。

He described the current moment as a Cambrian explosion of new tools and ideas. What survives will be what connects to business goals, and he repeated the point for emphasis: it has to be connected to revenue. The good news is that experimentation, and the cost of getting user feedback, is now far cheaper.

いまは新しい道具と発想が一気に増えているタイミングで、生き残るのは事業の目標につながっているものです。売上につながっていなければならない、と強調していました。

ポジティブなことは、試すコストも、使う人の反応をもらうコストも、以前よりはるかに安くなっていること。

The Workflow: From Prototype to Product
進め方：試作品から製品へ

Ray walked through the process his team uses, step by step.

実際に使っている手順を、順を追って見せてくれました。

Step 0: Build Your Brand Skills
手順0：見た目の土台を先に決める

Before anything else, spend time building your skills for brand, colors and assets, and decide whether the product is public or internal. That decision drives everything downstream.

何より先に、ブランド、配色、素材といった見た目の土台を作る時間を取ります。

そして、その製品が社外に出すものか社内で使うものかを決めます。この判断が、その後のすべてを左右。

He recommended a skill called Impeccable, not to use its output directly, but because, as his slide puts it, it shows you what should be stripped to avoid “Claude-isms”, the tell-tale default styling that makes AI-built interfaces look alike.

薦めていたのはImpeccableというスキルです。

出力をそのまま使うためではなく、AIっぽい見た目（Claude-isms）を避けるために、何を削ればいいかを見せてくれるから、とのこと。

The Vanilla Prototype
シンプルな試作品を作る

Ask an AI tool for a prototype and it will often build something heavy with a complex React setup that is hard to work with. Ray’s advice is to ask for a lightweight, close-to-static version first, then build on top of it. His slide is specific about what that means: HTML, CSS and vanilla JavaScript.

AIに試作品を頼むと、複雑なReactの構成を含む重たいものが返ってきて、あとで扱いに困ることがよくあります。

まずは軽くて、ほぼ静的なものを頼む。その上に積み上げていく。

スライドでは具体的に、HTML、CSS、素のJavaScriptと書かれていました。

Pick Your Runtime and Get Feedback
動かす環境を決めて、反応を見る

Next, build a simple version in the environment you’ll actually run in. DemandSphere is a Rails shop; Next.js is another common choice. The framework matters less than picking one. Then put it in front of users, even if that’s only you and a few others, before spending real time building.

次に、実際に動かすことになる環境で簡単なものを作ります。

DemandSphereはRailsを使っていて、Next.jsもよくある選択ですが、どれを選ぶかより、1つに決めることのほうが大事だそうです。

そのうえで、作り込む前に人に見せます。相手が自分と数人だけでも大丈夫です。

Get the Spec Written While You’re Still in the Browser
ブラウザにいるうちに仕様書を書かせる

Once you have a working version the stakeholders like, have the same web agent write a full product spec with context before you move anywhere. That spec is what the coding agent works from later.

関係者が納得する版ができたら、次の場所に移る前に、同じブラウザ上のAIに前提も含めた製品の仕様書を書かせます。

あとで開発用のAIが読むのは、この仕様書です。

Move It Local and Plan
自分のパソコンに移して、計画を立てる

Put all of those files into a project folder on your development machine, then:

1. git init
2. Create the repository on GitHub
3. Connect the remote repository
4. Run claude init or codex init to generate the context files

これらのファイルを、開発用のパソコンのプロジェクトフォルダにまとめて入れます。

そのうえで、

1. git init
2. GitHubにリポジトリを作る
3. 手元とGitHubをつなぐ
4. claude init または codex init を実行して、AIが読む前提ファイルを作る

Then switch to planning mode and plan the roadmap. Don’t let agents start building without making sure they’re on the right track.

そこから計画モードに切り替えて、ロードマップを作ります。方針が合っているか確かめない状態で、AIに作り始めさせるのは危険です。

On repository organisation, his slide is explicit: product spec and other docs in /docs, prototype files in /prototype, with rules in your context files ensuring neither ever reaches public view.

フォルダの分け方もスライドに明記されていました。仕様書などの文書は /docs、試作品のファイルは /prototype。どちらも外に出ないよう、AIが読む前提ファイルにルールを書いておきます。

Milestone 0: Hello World in Production
最初のステップ：本番環境で「Hello World」

Ray’s Milestone 0 is literally a “hello world” page, live in production. The goal isn’t features; it’s getting deployment working first, because the success of the product will depend on how quickly you can iterate through repeatable, automated deployments.

Ray氏の言う最初のステップは、文字どおり「Hello World」のページが本番環境で表示されている状態のことです。

目的は機能ではなく、先に公開の仕組みを動かすこと。製品の成否は、同じ手順で自動的に公開する流れをどれだけ速く回せるかにかかっているからです。

His recommendation for continuous integration and deployment is blunt: just use GitHub Actions to build these. Then three environments:

1. Development, where you build
2. Staging, which should match production
3. Production, deployed automatically once tests pass on staging

公開の自動化についての推奨は、単にGitHub Actionsで組めばいい、とのこと。

そのうえで、環境は3つ用意します。

1. 開発用。作る場所
2. 確認用（ステージング）。本番と同じ構成にしておく場所
3. 本番用。確認用でテストが通ったら、自動で公開される

Enforce the Testing Policy
テストの方針を、最初に叩き込む

This was the point Ray said he hammers home most. He spends a lot of time at the start of every project making sure the agents understand that tests are the most important part of what they’re building.

ここがいちばん大事だと信じている点です。

新しい案件では、最初に時間をかけて「テストこそがいま作っているもののなかで最も大事だ」とAIに理解させる、とのこと。

He distinguished two kinds of testing that are often confused:

• Exploratory testing means trying to break the product. It’s usually done by humans, although agents are getting better at it. This is where problems are found.
• Regression testing means turning every problem you find into an automated test, so it’s fixed and never happens again.

そして、混同されがちな2種類のテストを分けていました。

・壊しにいくテスト。製品をわざと壊そうとする作業です。ふつうは人がやりますが、AIも上手になってきています。問題が見つかるのはここ

・再発防止のテスト。見つけた問題をすべて自動テストに変えること。直したうえで、二度と起きないようにします

His test suites form a funnel. On a mature project, he described roughly 5,000 to 10,000 unit tests, around 1,000 integration tests, and about 150 to 200 browser tests.

テストは、細かいものほど数が多くなります。成熟した案件だと、細かい単位のテストが5,000〜10,000件、組み合わせのテストが約1,000件、ブラウザを動かすテストが150〜200件ほど。

The reason for all of this is speed. The more iterations you can get through, the faster and more reliably you respond to feedback. In a heavy sprint, his team deploys five to ten times a day.

理由はスピードです。試せる回数が多いほど、反応への対応が速く、確実になります。

開発が立て込む時期は、1日に5〜10回も公開しているそうです。

What He Didn’t Have Time For
今回は触れられなかったこと

Worth knowing before you start, because each of these is a decision the framework assumes you have made. His slide listed them as out of scope:

• Database selection
• Host selection
• Cloud versus bare metal
• Object storage
• Logging
• Security and audits
• Team collaboration
• Context file management
• APIs, MCPs, and the security around them

始める前に知っておくと役に立つ項目です。この手順は、これらがすでに決まっていることが前提になっています。

スライドでは対象外として挙げられていました。

・データベースをどれにするか

・どこで動かすか

・クラウドを借りるか、自前のサーバーを持つか

・画像やファイルの置き場所

・ログの管理

・セキュリティと監査

・チームでの進め方

・AIに読ませる前提ファイルの管理

・APIやMCPと、そのセキュリティ

The New Bottleneck: “The One”
新しい足かせは「作れる人がひとり」

Ray’s closing warning was about people, framed with a nod to Neo in The Matrix. Product used to be the bottleneck. Now, the people with the vision for what to build end up building all of it themselves. He said he couldn’t count how many people have told him they were up until 3 a.m. building something new, and admitted he’s done it too, because they can finally build things they’ve wanted to for years.

締めくくりの警告は、人についてでした。映画『マトリックス』のネオになぞらえていました。

かつては開発チームが詰まりどころ。いまは、何を作るべきか分かっている人が、全部作れてしまいます。

「新しいものを作っていて朝3時まで起きていた」と言ってきた人が何人いたか数えきれない、と話しながら、自分もやっていると認めていました。何年もやりたかったことが、ついにできるようになったからですね。

The risk is that one person becomes “The One,” and the new bottleneck. A company should have more than one, which means spreading this knowledge and training more people to build.

問題は、その一人が新しい詰まりどころになってしまうこと。会社には作れる人が複数いるべきで、そのために知識を広げ、作れる人を育てる必要があります。

His closing slides gave two instructions rather than a prediction:

• Make the investment to own your own compute capabilities
• Learn how to work with open weight models

最後のスライドは、予測ではなく2つの宿題でした。

・自前で計算資源を持つための投資をすること

・公開されている重みのモデル（オープンウェイトモデル）の扱い方を覚えること

DemandSphere runs a free tracker for frontier models, with particular attention to the open-weight ones, and he flagged where those models come from as an important topic to watch.

DemandSphereは最先端モデルを追う無料のツールを公開していて、特にこの種のモデルに注目しているとのこと。そうしたモデルがどこの国から出てきているかも、見ておくべき大きなテーマだと指摘していました。

He closed by inviting anyone interested in Japan to FOUND Conf, DemandSphere’s own search and AI conference.

そして最後に、日本に関心があるなら自社主催のFOUND Confへ、と案内がありました。

東京です！！日本です！！！

FOUND Conf Tokyo runs 18 to 19 February 2027, in the Tokyo Station area, covering search, AI and digital marketing. The announced speakers so far are Aleyda Solis, Amanda King, Christine Ullmann, Jes Scholz, John Shehata, JP Zhang, Krishna Madhavan, Marco Giordano, Rand Fishkin, Sam Torres and Zach Chahalis, with more to be announced.

FOUND Conf Tokyoは2027年2月18〜19日、東京駅近郊で開催予定。テーマは検索、AI、デジタルマーケティング。

現時点で発表されている登壇者は、Aleyda Solis、Amanda King、Christine Ullmann、Jes Scholz、John Shehata、JP Zhang、Krishna Madhavan、Marco Giordano、Rand Fishkin、Sam Torres、Zach Chahalisの各氏ですがまだまだ追加されるとのこと！（筆者の私も行くかもしれません！（日本への航空券とホテルの値段次第・・・！

The Blueprint
実践の手順

This is his own workflow slide, in his order, with the detail he gave around it:

1. Start in Claude.ai, ChatGPT or similar. Build your brand skills first: colors, assets, look and feel, and whether this is internal or public.
2. Create the repo.
3. Build the vanilla prototype. HTML, CSS and vanilla JavaScript, then a simple working version in your target framework. Show it to users before going further.
4. Have the web agent build your md context files, including a full product spec, once stakeholders like what they see.
5. Move to the local filesystem and init. git init, create and connect the GitHub repo, run claude init or codex init. Docs in /docs, prototype in /prototype, with rules keeping both private.
6. Enforce the testing policy. Do this before features, and make sure the agents understand tests are the most important part of what they build.
7. Configure the deployment environment. Dev, staging, production, with staging matching production.
8. Automate deployments. GitHub Actions is enough.
9. Deploy regularly. Milestone 0 is “hello world” live in production. Everything after that is iteration speed.

Ray氏自身がスライドで見せてくれていた手順は以下です。

1. ブラウザのClaudeやChatGPTから始める。まず見た目の土台を作ります。配色、素材、雰囲気、そして社内向けか社外向けか
2. リポジトリを作る
3. シンプルな試作品を作る。HTML、CSS、素のJavaScript。そのあと、実際に使う環境で動く簡単なバージョンを作り、進める前に人に見せます
4. AIに前提ファイルを書かせる。関係者が納得した段階で、製品の仕様書も含めて書かせます
5. 自分のパソコンに移す。git init、GitHubでリポジトリを作って接続、claude init か codex init を実行。文書は /docs、試作品は /prototype に置き、外に出ないルールを設定
6. テストの方針を叩き込む。機能より先にやり、テストがいちばん大事だとAIに理解させる
7. 公開する環境を用意する。開発用、確認用、本番用。確認用は本番と同じ構成に
8. 公開を自動化する。GitHub Actionsで十分です
9. 定期的に公開する。最初の一歩は「Hello World」が本番で動いている状態。そこから先は、どれだけ速く回せるかの勝負です

And alongside it: train other people, so you don’t become the bottleneck.

そしてこれと並行して、他の人を育てること。自分が詰まりどころにならないためです。

What Not to Do
やってはいけないこと

• Don’t dismiss vibe coding. It’s the right tool for prototypes and early feedback.
• Don’t mistake a prototype for a product. Without deployment and operations, it isn’t one.
• Don’t start with the big SaaS idea. Start with something simple.
• Don’t accept a heavy default prototype. Ask for a lightweight version.
• Don’t build features before deployment works.
• Don’t let agents build without a plan.
• Don’t fix a bug without adding a test for it.
• Don’t build anything that isn’t connected to revenue.
• Don’t become the only person who can build.
• Don’t adopt “X is dead” language just because it’s everywhere.

・バイブコーディングを軽く見ない。試作と早い段階の反応集めには、十分正しいツールです。

・試作品を製品と取り違えない。公開して動かし続ける体制がなければ、製品ではない

・大きな構想から始めない。簡単なものから

・AIが返してきた重たい試作品をそのまま受け取らない。軽い版を頼み直す

・公開の仕組みが動く前に、機能を作らない

・計画を立てずにAIに作らせない

・テストを足さずに不具合を直さない

・売上につながらないものを作らない

・作れる人が自分だけ、という状態にしない

・「○○は死んだ」という言い方に、流行っているからと乗らない

Next Steps
次のステップ

1. List three SEO problems that have been stuck waiting on your product or engineering team.
2. Pick the smallest one and build a vanilla prototype.
3. Show it to two or three users before going further.
4. If it earns a next step, set up a GitHub repository, a staging environment, and automated deployment before adding features.
5. Write a testing rule into your agent’s context files and create a regression test for every bug from day one.

1．開発チーム待ちで止まっているSEOの課題を3つ書き出す

2．いちばん小さいものを選んで、シンプルな試作品を作る

3．2〜3人に見せてから、先に進む

4．進める価値があると分かったら、機能を足す前に、GitHubのリポジトリ、確認用の環境、公開の自動化を用意する

5．AIに読ませる前提ファイルにテストのルールを書き、初日からすべての不具合にテストを作る

Personal Takeaways
所感

This was the most engineering-heavy talk of my day, and the one I found most directly useful for my own work.

この日のなかでいちばん技術寄りの内容で、自分の仕事にいちばん直接使える話でした。（私は完全に一人で開発していますが苦笑

What I’m taking away:

印象に残ったのは次の点です。

• The vibe coding versus engineering distinction is the right one. I vibe code a lot myself, and it is the fastest way I know to test an idea. What Ray put into words is the point where that stops being enough: once something has real users, deployment, tests and operations are what turn it into a product.

・雰囲気で作る段階と、きちんと作る段階を分ける考え方

私自身かなりバイブコーディングをしていて、アイデアを試すにはいちばん速い方法だと思っています。Ray氏が言葉にしてくれたのは、それだけでは足りなくなる境目。実際に使う人が出てきたら、公開、テスト、運用があってはじめて製品になります。

• “Every bug becomes a regression test” is the rule I most want to adopt. We run our own booking platform on Next.js, and most of the bugs we’ve fixed would have been worth locking in with a test so they can’t come back.

・「不具合はすべてテストにする」

いちばん取り入れたいルールです。うちの予約システムはNext.jsで動かしていますが、これまで直してきた不具合の多くは、再発しないようテストで固めておく価値がありました。

• The staging environment matters more with agents, not less. When changes come faster, a place to check them before they go live becomes more important.

・AIに任せるほど、確認用の環境が大事になる

変更が速く流れてくるほど、本番に出る前に見られる場所の価値は上がりますね。

• Service as software is a useful lens for consultancies. Ray’s argument that customers buy outcomes rather than tools applies directly to agencies and consultancies that are packaging repeatable work with AI.

・「仕事の完了を売る」という見方

客が買っているのはツールではなく成果、という話。AIで同じ業務を繰り返し提供しようとしている代理店やコンサル会社に、そのまま当てはまるかと思います。

• “The One” problem is real for small teams. For founder-led businesses, it’s the default. Writing down processes and context files is part of spreading the knowledge, not just a technical step.

・「作れる人が自分ひとり」問題は、小さなチームほど現実的

創業者がひとりでやっている会社では、むしろそれが初期状態ですね。手順や前提ファイルを書き残すことは、単なる技術的な作業ではなく、知識を他の人に渡す作業でもあるかと思います。

• Ray’s talks show where the industry is heading. Over the past few years he has moved from measuring the SERP, to explaining AI answers, to unifying search data, and now to building. The talk was titled “Data strategy & engineering for agentic workflows,” but most of it was about engineering practice, which says a lot on its own. He’s giving the same talk at brightonSEO Brighton in October 2026.

・Ray氏の講演を並べると、業界の向かう先が見える

ここ数年で、検索結果を測ることから、AIの回答の仕組みを解くこと、検索データをまとめて見ること、そして今回の「作ること」へ。タイトルは「Data strategy & engineering for agentic workflows」でしたが、中身の大半は開発の実践でした。そのこと自体が、いまの業界を物語っているかと思います。

なお同じ講演は、2026年10月のbrightonSEO Brightonでも行われるとのことです。

以上、Ray Grieselhuber氏のセッションレポートでした。

Related Resources
関連リンク

• Talk: Data strategy & engineering for agentic workflows
• Speaker: Ray Grieselhuber
• The full slide deck on Speaker Deck
• Ray’s site, where he links the slides
• My report on Ray’s September 2025 San Diego talk: It’s ALL AI search now
• FOUND Conf Tokyo, 18 to 19 February 2027
• DemandSphere events, including FOUND

・講演ページ：Data strategy & engineering for agentic workflows

・登壇者：Ray Grieselhuber

・Speaker Deckのスライド全文

・Ray氏のサイト（スライドへのリンクあり）

・2025年9月サンディエゴでのRay氏の講演レポート：It’s ALL AI search now

・2025年4月ブライトンでのRay氏の講演レポート

・FOUND Conf Tokyo、2027年2月18〜19日

・DemandSphereのイベント一覧（FOUNDを含む）

Written by Ayaka Uchida
CEO, A-Digital Works

This report covers Ray Grieselhuber’s session “Data strategy & engineering for agentic workflows” at brightonSEO San Diego (16 September 2026).

執筆：打田彩夏（Ayaka Uchida）
A-Digital Works CEO

本レポートは、brightonSEO San Diego（2026年9月16日）で行われたRay Grieselhuber氏のセッション「Data strategy & engineering for agentic workflows」の内容をまとめたものです。