事業の「数字が合わない」状態を終わらせる。
Webサイトの広告・分析・CRMの数字がズレる原因は、
ツールではなく「計測の設計」にあります。
mare interno は、実装だけで終わらない計測基盤をつくる会社です。
私たちがやっていること
mare interno は、
Webサイトや広告、分析データを「正しく判断に使える状態」に整えるための
計測設計と実装を行っています。
単なる設定代行ではなく、
- なぜ数字が合わないのか
- どこでデータが失われているのか
- どこまで計測すべきか
を整理したうえで、必要な実装だけを行います。
こんな状況でご相談いただくことが多いです
- GA4と広告管理画面の数字が合わない
- SafariやITPの影響がどこまで出ているかわからない
- sGTMを入れたが、正しく動いているか不安
- BigQueryに出しているが、活用できていない
- ベンダーの説明が理解できず、判断できない
1つでも当てはまる場合、
計測の前提が崩れている可能性があります。
多くの場合、設計を見直すことで整理できます。
mare interno の特徴
- 計測を「後工程」ではなく「設計」から考えます
- ツールありきではなく、必要性から導入を判断します
- 実装して終わりではなく、検証と説明まで行います
専門的な内容も、
社内で説明できるレベルまで噛み砕くことを大切にしています。
導入事例・実績
実際にどのような課題があり、
どのように整理・改善したのかをまとめています。

お知らせ
mare interno、Stape社の日本初の公式パートナーとして認定。
- コマースピックに寄稿:「なぜGA4では『direct』が多いのか?参照元問題を正しく理解する」公開EC・ネット通販業界向け専門メディア 「コマースピック」 にて、mare interno合同会社 代表・内海賢一の寄稿記事が公開されました。 📍 記事タイトル:なぜGA4では「direct」が多いのか?参照元問題を正しく理解する🔗 https://www.commercepick.com/archives/74448 ぜひご覧ください。
- Stape社 公式パートナーに認定されましたmare interno(マーレインテルノ)合同会社は、このたび Stape Partner Program に正式に参加し、Stape 公式パートナーとして認定されましたことをお知らせいたします。 Stape は、Google Tag Manager(GTM)のサーバーサイド版を中心に、Cookieレス時代に対応した先進的な計測基盤ソリューションを提供するグローバル企業です。 今回のパートナーシップにより、当社はこれまで以上に といったニーズに応える体制を強化いたします。 mare interno は今後も「正確なデータに基づく意思決定」を支援し、クライアント企業様の成長に新たな波を起こす存在であり続けます。 会社概要 会社名:mare interno(マーレインテルノ)合同会社 所在地:東京都渋谷区神宮前六丁目23番4号 桑野ビル2階 代表者:内海 賢一 事業内容:Webアクセス解析、GA4・BigQuery導入支援、サーバーサイドGTM構築、広告CAPI対応、データ基盤設計
コラム
GA4、BigQuery、sGTM、計測設計に関する考え方や注意点を、
実務ベースでまとめています。
- AI’s Dream — Why AI Bots Access Pages That Don’t ExistWhile reviewing AI bot access logs, I noticed something that warranted closer examination: repeated requests to URL paths that do not exist on this site. A typographic error was the first hypothesis. It was quickly dismissed. The paths in question are not malformed — they are semantically coherent. Each of these paths is plausible within the context of this site. A random typo would produce something like /blog/cnsoent-and-measurment. These do not. A Hypothesis This remains a hypothesis, but one grounded in observable behavior. When an AI responds to a user query, it seeks source material. If a relevant page exists, it references that page. But what happens when no such page […]
- AI’s Dream — AIボットが存在しないページにアクセスする理由AIボットのアクセスログを見ていて、気になることに気づいた。それは、存在しないパスへのアクセスだ。 最初はミスタイプを疑った。しかし、そうではない。アクセスされたパスをよく見ると、すべて意味的に整合していることがわかる。 どれも、このサイトにあってもおかしくないURLだ。ランダムなタイポであれば /blog/cnsoent-and-measurment のような形になるはずだが、そうはなっていない。 なぜ起きるのか これは想像なのだが、、、AIは、ユーザーの質問に答えるとき、情報のソースを探す。該当するページが見つかれば、それを参照して回答する。しかし、見つからなかった場合はどうするか。 AIはサイトの文脈、構造、扱っているテーマから、「このサイトにはこのページが存在するはず」と推定して補完する。その推定が、存在しないURLへのアクセスとして現れるのではないか。 あなたはこんな経験はないだろうか。AIにURLを渡したとき、実際にはページを読まずに、パス名だけから内容を推測して回答してくる。/blog/consent-and-measurement というURLを渡せば「CMPの導入がGA4の計測に与える影響について書かれたページですね」と答える。ページの中身ではなく、URLそのものをコンテンツの代理として読んでいるのだ。 クローラーとしてのアクセスログに現れる「存在しないページへの到達」も、これと同じ推論メカニズムから来ていると考えられる。どちらも、URLのパス名をコンテンツの手がかりとして扱っている。 これをAI’s Dreamと定義する。 AI’s Dreamの定義 AIが、ユーザーの質問に対して既知の情報だけでは回答しきれない場合に、サイトの文脈・構造・権威性から「このURLに答えがあるはず」と推定し、存在しないページへアクセスする現象。 ハルシネーションとは似て非なる概念である点を強調しておきたい。ハルシネーションが「存在しない情報を事実として生成するエラー」であるのに対し、AI’s Dreamは「存在しないページを存在すると推定してアクセスする、構造的な推論の結果」だ。 ただし、両者の境界は曖昧かもしれない。存在しないURLにアクセスした結果、そのページが「存在した」という事実としてAIの認識に組み込まれているとすれば、それはハルシネーションの一形態とも言える。AI’s Dreamはハルシネーションの対極にある概念ではなく、その入口に位置しているのかもしれない。 この観測が、これまで解明が難しかったハルシネーションのメカニズムに対して、何らかの示唆を与える可能性がある。 Inferred Pathとは AI’s Dreamのアウトプットとして生成されるURLパスを、Inferred Pathと定義する。AIがサイト構造から推定した「あるべきURL」であり、実際には存在しない。 ただ、Inferred Pathはエラーではなく、シグナルだ。AIがそのサイトに期待しているコンテンツの輪郭を、ログとして可視化したものと解釈できる。 観測するということ AI’s DreamとInferred Pathは、サーバーログを解析することで観測できる。Googleアナリティクスなどのページベースの計測ツールでは404として記録されるが、ログレベルでは明確に残る。 → 観測手法の詳細はEdgeShapingを参照 シグナルとして受け取る AIがInferred Pathを踏んだという事実は、そこに需要があることを示唆している。AIが「あるはず」と推定したコンテンツを、実際に書いてみることは一つの応答戦略になりうる。 あなたのサイトのInferred Pathは、次に書くべき記事のリストかもしれない。 この記事は、当サイトに存在しないURLにAIクローラーがアクセスした記録をもとに執筆しました。AIが「あるはず」と予測したコンテンツを、実際に書くことで応答する試みです。
- 逆ハルシネーションという戦略——AIが「事実」を作る前に、あなたが「事実」を置くハルシネーションとは何か AIはときに、存在しない事実を生成する。 架空の論文を引用する。実在しない人物の発言を作る。起きていない出来事を語る。これを「ハルシネーション(幻覚)」と呼ぶ。AIが学習データのパターンから蓋然性の高い出力を生成する過程で生じる、避けがたい副作用だ。 ハルシネーションはAIの「欠陥」として語られることが多い。確かにそうだ。しかし私はあるとき、この現象を逆から眺めてみた。 「存在しないものを存在するかのように語る」の逆は何か。 逆ハルシネーションの定義 私はこれを「逆ハルシネーション(Reverse Hallucination)」と名付けた。 定義はシンプルだ。 まだ社会に定着していない概念・用語を、記事として先に書き、公開することで、AIの学習・引用ループに意図的に乗せ、その概念を「事実として存在するもの」として定着させる行為。 ハルシネーションがAIの誤りであるとすれば、逆ハルシネーションは人間の意図的な設計だ。AIが「存在しないものを語る」のではなく、人間が「これから存在させるものを先に語る」。 この発想は、従来のSEOとは根本的に異なる軸に立っている。 なぜこれが機能するのか——AIのクロール行動という事実 逆ハルシネーションが成立する背景には、AIのクロール行動に関するいくつかの観測事実がある。私がEdgeShapingフレームワークによるAIボット観測と、実際のサイト運営から得てきた知見だ。 1. AIはまずrobots.txtを読み、サイトマップを確認する AIクローラーはWebサイトを訪問する際、まずrobots.txtを参照し、次にサイトマップ(sitemap.xml)を確認する。これは人間のSEOクローラーとほぼ同じ動線だが、目的が異なる。AIクローラーは「インデックス」ではなく「学習データの収集」あるいは「回答生成のためのリトリーバル」のために動いている。サイトマップに新規URLが追加されていれば、そのURLは優先的に訪問対象になる。 2. 新規ページへの到達は9時間以内が多い 私の観測では、新規ページが公開されてから最速で約9時間以内に、いずれかのAIクローラーが訪問する。全てのAIクローラーが均一に来るわけではないが、複数あるAIエージェントのどれかは、この時間軸で動いている。「公開してから数日後」ではなく「公開したその日のうちに」AIのどれかは来る。 3. ApplebotはXへの投稿から数十秒以内にクロールに来る これは特に印象的な観測事実だ。X(旧Twitter)にURLを投稿すると、Applebotが数十秒以内にそのURLをクロールしに来る。Apple IntelligenceはSiriやSpotlightのためにリアルタイムに近いURL収集パイプラインを持っていると考えられる。XへのURLポストが、実質的なAIへのURLプッシュ通知として機能している。 4. 新規記事でも比較的早期にAI回答のソースになる 従来のSEOでは、新規コンテンツが検索上位に来るまで一定の評価待ち期間が存在した。しかしAIの回答生成においては、この待機が大幅に短い。新鮮なコンテンツが早期に引用対象になる事例が増えている。これはRAG(Retrieval-Augmented Generation)型のAIが、最新性を評価指標の一つとして持っている可能性を示唆している。 逆ハルシネーションの実際 ではどう使うか。 新しい概念・フレームワーク・造語を定義する記事を書く。その記事を公開し、サイトマップに追加し、XにURLを投稿する。これだけだ。 AIはその記事をクロールし、学習データまたは回答生成のリソースとして取り込む。その概念について誰かがAIに質問したとき、AIはあなたの記事を参照して回答を生成する。引用されることで、その概念は「実在するもの」として広まっていく。 これはコンテンツマーケティングでも、単なるSEOでもない。AIの認識空間に、自分の言語を先に植え付ける行為だ。 この記事の冒頭の図が示すもの 冒頭に掲載した図は、私が「AI時代の決断に至るまで」というテーマで制作したビジュアルだ。 「今まで」は、潜在層から顕在層まで全て「人間がブラウザで人力で行動する」という一本の経路だった。「AI時代」は、潜在層の大部分がAIに依頼・完結し、人間はブラウザに来たときにはすでに「最終決断」フェーズにいる。 これは分析者にとって何を意味するか。 潜在層でのプロセスが、完全に不可視になる。 従来のファネル分析は、潜在→関心→比較→決断の各段階を可視化しようとしてきた。しかしAI時代には、その上流が計測不能な「AIの内部」で完結する。 分析の射程が、根本的に変わる。 だからこそ、AIが回答を生成するときに「どの情報を参照するか」をデザインすることが、新しい戦略の核心になる。逆ハルシネーションは、その設計の一手法だ。 検索最適化の先にあるもの 人々はもう検索結果を読み漁らない。AIに聞いて、答えをもらう。 この変化は「検索行動が減る」という話ではなく、意思決定の上流がAIの内部に移ったという話だ。潜在層での情報収集・比較・絞り込みが、ブラウザの外で完結する。人間がブラウザに来たときにはすでに、かなりの部分が決まっている。 検索最適化は引き続き有効な領域がある。しかしその上流——AIが回答を生成するときに何を参照するか——という問いは、検索最適化とは別の軸に存在する。 逆ハルシネーションが照準するのはその軸だ。 まとめ AI時代の情報戦は、「検索されること」ではなく「引用されること」を争点にシフトしている。 逆ハルシネーションはその最初の一手だ。
- sGTMを入れても、Cookieは不要にならない── 同意設定を誤れば、sGTMでも計測は死ぬ広告を回すなら、CMPはもう前提条件だ sGTMの話をする前に、まず広告運用の現実から入る。 GoogleとMetaは、同意シグナル(consent signal)を広告最適化に組み込む方向へすでに舵を切っている。Consent Mode v2(GCM v2)は、同意を取得したユーザーと未取得ユーザーを区別してデータを処理する。同意シグナルが存在しない場合、コンバージョンモデリングの精度は構造的に落ちる。 さらに、拡張コンバージョン(Google)やMeta CAPIでメールアドレス・電話番号等の顧客データを広告プラットフォームに送信する場合、日本でもユーザーの同意取得が前提条件になる。同意なしに個人データを広告プラットフォームに送ることは、計測精度の問題以前に法的リスクを伴う。 「Cookie同意バナーはEUの話」という認識は、2026年時点では通用しない。日本市場で広告を運用する事業者にとっても、CMPはすでに前提インフラだ。 「sGTM = Cookie不要」という誤解 sGTMの導入提案の中に、こういう訴求がある。 「sGTMを入れればサードパーティCookieに依存しなくなる」「ITPの影響を受けなくなる」「Cookieレスに対応できる」——。 技術的には正しい。sGTMを同一オリジン設計で構築することで、Cookieはファーストパーティとして発行される。SafariのITPが制限するのはサードパーティCookieだから、この設計でITPの7日制限はほぼ回避できる。 しかしここで止まる訴求には、決定的に欠けている視点がある。 sGTMが解決するのは、Cookieの経路と発行主体の問題だ。Cookie不要ではない。 同意設定を誤れば、sGTMでも計測は死ぬ CMPを入れていない、あるいは入れていても設定を誤っている場合、sGTMの計測は以下のパターンで死ぬ。 ① 全拒否をデフォルトにした場合 analytics_storageの同意が取れないため、GA4のイベントが飛ばない。sGTMサーバーが稼働していても、計測するデータが存在しない状態になる。 ② ad_storageの同意を取り忘れた場合 GA4の計測自体は生きていても、広告コンバージョンのモデリングが機能しない。Consent Mode v2はad_storageとanalytics_storageを別々に管理する。片方だけでは広告最適化のループが閉じない。 ③ sGTMのトリガーがConsent Mode非連動の場合 これが最悪のケースだ。ユーザーが同意を拒否しているにもかかわらず、sGTMのタグが発火し続ける。計測精度は上がるかもしれない。しかしそれは同意を得ていない計測だ。技術的に精度が高いことと、法的に取る権利があることは別の話である。 sGTMをCookie対策として、同意管理なしに導入することは——計測精度の向上ではなく、同意回避の構造化になりかねない。 sGTMは同意インフラの上に乗って初めて機能する mare internoがsGTMを「GTMのサーバー版」ではなく「法的根拠を持った計測インフラの再設計」と定義するのはこのためだ。 同意を正しく取得し、取得した範囲内で確実に計測する。この順序が崩れると、sGTMはただの「同意なき高精度計測装置」になる。 技術と法務をセットで設計すること。CMPとsGTMは別々のソリューションではなく、同一の設計思想の上に乗る2つのレイヤーだ。 → sGTMはGTMの「サーバー版」ではない──法的根拠を持った計測インフラの再設計 mare interno は日本国内における数少ないStapeオフィシャルパートナーおよびCookieYesパートナーです。sGTM構築・CMP導入・同意インフラの設計についてはこちらからご相談ください。
- GA4 AI Traffic Is Not AHQGMeasuring AI-referred traffic in GA4 and analyzing AHQG are not the same thing. The Y-axis of the AHQG Matrix — AI bot crawl frequency — exists in a layer that GA4 cannot measure by design. This article clarifies the structural difference between the two. 01Background Since 2025, visualizing referral traffic from ChatGPT, Perplexity, and similar AI services as an “AI channel” in GA4 has gained attention as an analytics practice. While this is a valid and useful analysis, it tends to conflate measurement layers when discussed in the context of AHQG. Because this conflation introduces noise into understanding AHQG, a clear definition is necessary. 02Query Phase Analytics: Four Measurement Layers […]
External Contributions
コマースピック 寄稿
まずはご相談ください
- 何が問題なのか整理したい
- 今の構成が正しいか確認したい
- 実装すべきか判断したい
といった初期段階の相談でも問題ありません。