SAGの検索・AIアーキテクチャを表すネットワーク図

SAG TECHNOLOGY FRONTIER

技術の流れを追うだけではない。
SAGが次の基準をつくります。

検索・回答・生成AIがブランドを理解する仕組みを設計し、SAGの実際のアーキテクチャと運用原則を技術の言葉で説明します。

SAG / ARCHITECTURE NOTES

現在のSAGを支える5つの技術原則

発見、根拠、データ境界、安定した実行と配信まで、実装に反映した判断を解説します。

14 articles · 1 / 2

01

サイトマップの発見と収集範囲:URL一覧はどのように分析計画になるのか?

サイトマップのアドレス一覧を、承認済みドメインの収集候補に変換するプロセスです。URL一覧は、そのまま分析結果になるわけではありません。言語別の重複、除外ページ、別ホストを整理しなければ、作業量は増えても比較可能な根拠は不足します。

02

URLアイデンティティと重複排除:ハッシュを削除しても同じページになるのか?

元のリンクと比較用のアドレスを区別し、文書の同一性を管理する方法です。フラグメントが異なる引用を毎回新しい出典として数えると、根拠となるページ数が膨らみます。反対に、重要なクエリを削除すると、異なる製品をひとまとめにしてしまいます。

03

クローラーのSSRF対策:顧客が登録したURLをそのままリクエストしてはいけない理由

ユーザー提供のアドレスが、内部サービスや許可されていないネットワークへのリクエストを引き起こさないようにするための制御です。正常に見えるアドレスでも、リダイレクトや名前解決の後に内部アドレスへ到達することがあります。分析の利便性のためにネットワーク境界を開放すると、テナント全体の信頼が揺らぎます。

04

ZIP bombとパストラバーサル:データ収集システムの信頼境界はどこにあるのか?

圧縮入力の許容サイズ、項目数、パスを制限し、処理リソースを予測可能にする設計です。小さなアップロードでも、展開後に大量のメモリを必要とする場合があります。ファイル名をそのままパスとして使うと、分析システム外のファイルに影響を及ぼすおそれもあります。

05

キャプチャ・OCR・DOMの境界:画面からどこまで診断できるのか?

画像とテキスト・DOMを、異なる種類の証拠として管理する方法です。画面に製品の説明が表示されていても、メタタグやcanonicalは確認できません。キャプチャをHTML診断と同じ根拠として扱うと、確認していない技術項目について結論を出してしまいます。

06

ページバージョンの保存:同じURLを再取得することが、なぜ新しい履歴になるのか?

同じURLのコンテンツを、収集時点ごとの記録として保存するデータモデルです。URLが同じでも仕様やポリシーが変わると、以前のレポートの根拠と現在の画面が異なる場合があります。最新の本文だけを保存していると、過去の判断を再現するのは困難です。

07

コンテンツハッシュと変更検知:何が変わったかを先に切り分ける方法

コンテンツの要約ハッシュと構造比較を用いて、同じ資料と変更された資料を区別するパターンです。ページを頻繁に収集するほど、単純な収集回数は増えます。実際には変更のない入力を毎回高価なモデルに送ると、コストが増加し、結果の一貫性が損なわれる可能性があります。

08

HTML正規化:ページをスコアリングより先に比較可能なデータにする方法

異なるHTMLからタイトル、本文、リンク、メタ情報を共通の構造に抽出するプロセスです。メニューやフッターが長いサイトでは、製品説明よりも繰り返しの文章が多く抽出されることがあります。構造を区別しないと、文章数が製品の根拠として十分であるかのように誤って解釈されます。

09

HTML ZIP分析:ソースがあるとき、なぜクロールより先に確認すべきなのか?

WebページのHTML一式を制限された入力経路から読み込み、診断に必要なドキュメントに変換する収集方式です。公開サイトが変更されたり、外部アクセスが制限されたりすると、現在の画面だけでは以前のソースを検証しにくくなります。承認済みのソース一式は、何を分析したのかを明確にする出発点です。

10

増分収集と再分析:毎回サイト全体を読み込む必要があるのか?

変更されたページと影響を受ける質問を中心に、再分析の範囲を絞るパターンです。全件再収集は単純ですが、小さな修正でもすべてのコストが再び発生します。一方、変更の判定範囲を絞りすぎると、関連するFAQや比較表の不整合を見落とす可能性があります。