ZIP bombとパストラバーサル：データ収集システムの信頼境界はどこにあるのか？
圧縮入力の許容サイズ、項目数、パスを制限し、処理リソースを予測可能にする設計です。小さなアップロードでも、展開後に大量のメモリを必要とする場合があります。ファイル名をそのままパスとして使うと、分析システム外のファイルに影響を及ぼすおそれもあります。
SAG TECHNOLOGY FRONTIER
技術の流れを追うだけではない。
SAGが次の基準をつくります。
検索・回答・生成AIがブランドを理解する仕組みを設計し、SAGの実際のアーキテクチャと運用原則を技術の言葉で説明します。
SAG / ARCHITECTURE NOTES
現在のSAGを支える5つの技術原則
発見、根拠、データ境界、安定した実行と配信まで、実装に反映した判断を解説します。
80 articles · 2 / 8
Intent・Persona・Product Attribute：購買に関する質問をデータに変える方法
顧客の目的・状況・制約と商品属性を、質問の構造として整理する方法です。同じキーワードでも、予算・環境・判断基準は異なります。単語だけを保存すると、実際の選択条件や必要な商品根拠を見落とします。
サーバー照会の並列化：同じ設定を再度読み込まないための性能設計
独立した照会を並列化し、共通設定を一度読み込んで再利用する方法です。小さなクエリでも往復が繰り返されると遅延が蓄積します。機能が増えるほど、モデルよりも共通設定を再度読み込むコストがボトルネックになることがあります。
観測コホート：異なるエンジンの順位を混ぜないための基準とは？
質問、エンジン・モデル、地域・言語・デバイスの条件が同じ観測をまとめる比較単位です。同じ文でも、モデルや市場が異なれば回答が変わることがあります。条件を削除した平均は計算しやすくても、何が変わったのかを説明するのは困難です。
原文レシート：結果から再現可能な資料へたどる方法
観測条件と元の応答を、確認可能な一つの記録として結び付けるモデルです。表の順位だけを保存しても、検索結果が変わった後では、なぜその数値になったのかを確認しにくくなります。出典へのリンクが有効でも、観測時の回答と同じである保証はありません。
発行月と分析月：10月のレポートが9月を説明すべき理由
レポートの発行時点と評価対象期間を別々に定義する運用構造です。当月の進行中データと前月の確定データを混在させると、前月比や担当作業の効果を解釈しにくくなります。まだ終了していない期間を締め実績として表現すると、さらに大きな誤解が生じます。
GEO研究を顧客成果に置き換えず、運用に適用する方法
研究条件を確認したうえで、顧客の質問やチャネルで別途検証するプロセスです。論文のモデル・市場・指標が異なれば、効果も異なる可能性があります。研究で示された改善率を顧客の予想成果として転用すると、根拠の範囲を超えてしまいます。
キャプチャ・OCR・DOMの境界：画面からどこまで診断できるのか？
画像とテキスト・DOMを、異なる種類の証拠として管理する方法です。画面に製品の説明が表示されていても、メタタグやcanonicalは確認できません。キャプチャをHTML診断と同じ根拠として扱うと、確認していない技術項目について結論を出してしまいます。
公式ソースの判別：ブランド名を含むURLなら公式の根拠になるのか？
登録ブランドのドメインとの関係に基づいて、ソースを公式・外部に分類する方法です。名前の似たサイトや報道での引用を公式仕様と誤認すると、責任の所在が変わります。文字列の類似性はドメインの所有権を意味しません。
外部収集アダプターとフォールバック：代替応答はいつ成功なのか？
外部サービスの入力・エラー・原文を共通の観測データに変換する境界です。APIの失敗をサンプルに置き換えて成功と表示すると、実際に収集したと誤解されます。呼び出しの復旧と結果の代替は別のものです。