サイトマップの発見と収集範囲：URL一覧はどのように分析計画になるのか？
サイトマップのアドレス一覧を、承認済みドメインの収集候補に変換するプロセスです。URL一覧は、そのまま分析結果になるわけではありません。言語別の重複、除外ページ、別ホストを整理しなければ、作業量は増えても比較可能な根拠は不足します。
SAG TECHNOLOGY FRONTIER
技術の流れを追うだけではない。
SAGが次の基準をつくります。
検索・回答・生成AIがブランドを理解する仕組みを設計し、SAGの実際のアーキテクチャと運用原則を技術の言葉で説明します。
SAG / ARCHITECTURE NOTES
現在のSAGを支える5つの技術原則
発見、根拠、データ境界、安定した実行と配信まで、実装に反映した判断を解説します。
39 articles · 1 / 4
URLアイデンティティと重複排除：ハッシュを削除しても同じページになるのか？
元のリンクと比較用のアドレスを区別し、文書の同一性を管理する方法です。フラグメントが異なる引用を毎回新しい出典として数えると、根拠となるページ数が膨らみます。反対に、重要なクエリを削除すると、異なる製品をひとまとめにしてしまいます。
クローラーのSSRF対策：顧客が登録したURLをそのままリクエストしてはいけない理由
ユーザー提供のアドレスが、内部サービスや許可されていないネットワークへのリクエストを引き起こさないようにするための制御です。正常に見えるアドレスでも、リダイレクトや名前解決の後に内部アドレスへ到達することがあります。分析の利便性のためにネットワーク境界を開放すると、テナント全体の信頼が揺らぎます。
TELCの準備度が実際のAI露出率ではない理由
信頼性・根拠・位置・接続性を評価する、回答根拠の内部診断です。優れたページが外部AIで常に選ばれるとは限りません。内部の準備度を成果率として示すと、改善作業と市場の反応を混同してしまいます。
JSON分析契約にバージョン管理と検証が必要な理由
JSONの観測・報告データにフィールドの意味とバージョン・検証ルールを定める設計です。新しいエンジンを容易に追加できても、フィールドの意味が変われば過去のデータが歪みます。柔軟な保存は、検証しなくてよいという意味ではありません。
月次データモデル：月の選択をすべてのメニューの基準にする方法
顧客スペースで選択した月を、検索・集計・ページ移動に共通する基準として使うデータ契約です。SEOが9月、GEOが最新データを参照していると、1つのレポートに表示される数値は同じ期間を説明しません。画面の表示が速くても、比較の解釈は崩れます。
検索順位・ブランド言及・推奨はなぜ別の指標なのか？
検索順位、回答への登場、推奨の意味を別々の項目として測定する原則です。末尾での言及と最初の推奨は異なります。これらを検索順位ひとつに換算すると、何を強化すべきか判断しにくくなります。
ZIP bombとパストラバーサル：データ収集システムの信頼境界はどこにあるのか？
圧縮入力の許容サイズ、項目数、パスを制限し、処理リソースを予測可能にする設計です。小さなアップロードでも、展開後に大量のメモリを必要とする場合があります。ファイル名をそのままパスとして使うと、分析システム外のファイルに影響を及ぼすおそれもあります。
Intent・Persona・Product Attribute：購買に関する質問をデータに変える方法
顧客の目的・状況・制約と商品属性を、質問の構造として整理する方法です。同じキーワードでも、予算・環境・判断基準は異なります。単語だけを保存すると、実際の選択条件や必要な商品根拠を見落とします。
サーバー照会の並列化：同じ設定を再度読み込まないための性能設計
独立した照会を並列化し、共通設定を一度読み込んで再利用する方法です。小さなクエリでも往復が繰り返されると遅延が蓄積します。機能が増えるほど、モデルよりも共通設定を再度読み込むコストがボトルネックになることがあります。