仕組み
何のための道具か、なぜ自分では調べられないのか、そして毎朝どんな形で届くのか。仕組みそのものの説明は、そのあとに置いています。
「ウェブから情報を取ってくる」と言うと簡単に聞こえますが、難しいのは取ることではなく、取れた数字が信用できることです。 順に説明します。
一言でいうと
「この商品、いまどの会社が、いくらで売っているか」を、毎朝、証拠つきでお出しします。
「だいたい12万円です」ではありません。A社が¥118,000、B社が¥134,800、C社が¥109,500、それぞれのページはここ、読んだのは今朝6時、為替はこのレート ―― という形です。
なぜ「だいたい」では困るのか
値段を調べたい、という相談はよくあります。けれど返ってくる答えのほとんどは 「相場」です。
相場は正しい数字です。ただ、それでは何も決められません。
- 仕入れ値を交渉するとき、相手が誰でいくらかが要ります
- 自社の値段を下げるかどうかは、下げないと負ける相手が実在するかで決まります
- 海外に売るかどうかは、現地でいくらで売られているかで決まります
「だいたい12万円」は、この3つのどれにも答えていません。
なぜ自分で見に行けないのか
見に行けます。1回なら。
問題は2つあります。
① 100商品 × 5サイトを毎朝見るのは、人の仕事ではありません
500回ページを開いて、値段を写して、昨日と比べる。1日で終わりません。そして毎日やらないと意味がありません ―― 昨日いくらだったかは、記録していなければ二度と手に入らないからです。
② 自分の国からは、自分の国の値段しか見えません
これが一番伝わりにくいところなので、丁寧に書きます。
同じURLを開いても、どこからアクセスしたかで、ページは違う内容を返します。 値段が違う。通貨が違う。在庫の有無が違う。並び順も、送料も、キャンペーンも違います。
これは何かの仕掛けではなく、ごく普通のことです。 日本から来た人には日本向けの値段を出す ―― お店として当たり前の作りです。
つまり、東京のパソコンから競合のサイトを見ても、その競合がドイツの客に見せている値段は、永久に見えません。
私たちは指定された国のサーバーを経由してページを開きます。同じページを複数の国から同時に読んで、並べてお出しできます。
「ChatGPTに聞けばいいのでは」への答え
よく聞かれます。実際に試したので、その結果をお見せします。
| 対話型AIに聞いた | 「両市場はほぼ同水準です」 |
| 同じ日・同じ商品を実測 | 米国市場は日本より17%上 |
面白いのはここからです。AIが挙げた2つの数字は、どちらも実在する正しい値でした。 片方は買取価格、もう片方は市場指数です。
性質のまったく違う2つを並べて引き算していて、回答のどこにも、その区別は書かれていませんでした。 この違いだけで、差の符号が反転します。
これはAIの出来の問題ではありません。5つとも、聞き方では埋まりません。
- 返ってくるのは「相場」で、「売主」ではない ―― 正しい答えですが、動くための答えではありません
- 自分の国からしか見えない ―― 「サンパウロから見て」と頼めるプロンプトは存在しません
- その数字がどこから来たか言わない ―― だから間違いに気づけません
- 「昨日」を持っていない ―― 誰も保存していないので、後から買うこともできません
- 毎回、違う答えが返る ―― 先週の資料と今週の資料が比較できません
AIへの批判ではなく、AIが何のためのものかという説明です。 特定のページを、特定の国から、特定の時刻に読み、その記録を残す ―― それは別の仕事です。
毎朝、届くもの
1行につき、これだけが付いてきます。
| 販売者 | 掲載ページに出ていた出品者を、そのまま |
| 価格（税抜） | ¥118,000 |
| 前回との差 | −¥4,200 |
| 自社比 | +8.6% |
| 読んだ国 | どの国のサーバーを経由したか |
| 掲載URL | 実際に読み取ったページ |
| 取得時刻 | 2026-08-22T02:20:04.756Z |
| 為替レート | 適用したレートと、そのレート自体の公表日 |
この項目は切り離せません。 別料金でもオプションでもなく、必ず全部付きます。
理由は1つです ―― 出どころの無い価格は、会議で守れないから。 「競合は10万円です」と報告して「どこ情報?」「いつの?」「税込? 税抜?」と聞かれて答えられなければ、その資料は使われません。
届き方は4つあります。画面（今朝の表）、CSV、毎朝のメール、Webhook。
一番地味で、一番効くところ
競合サイトを毎日見に行っているとします。ある朝、そのサイトが改装されて、こちらの読み取りが失敗しました。返ってくるデータは「0件」です。
素朴に作ると、こう報告されます ―― 「競合の在庫が、一晩で全部売れました」。
データの上では、「取得に失敗した」と「全部売れた」は、まったく同じ形をしています。 そしてこれは、実際に人が動いてしまう数字です。
私たちがやっていること:
- その情報源が今日ちゃんと答えたかを、先に確かめます。 答えなかった情報源の掲載は、消滅の判定から外します
- 1回消えただけでは成約と判定しません。 並び順が変わっただけで消えるのは日常です
- 拒否は拒否として記録します。 「アクセスが多すぎます」を「中身が空の成功」にはしません
そして読めなかった情報源は、画面にもCSVにもメールにも、名前が出ます。 黙って落とすと、先週より短いリストが「市場が縮んだ」と読まれるからです。
ここから先は、仕組みの話です
1. どこから見るか
ページは、誰が見に来たかで姿を変えます。
同じ商品ページでも、日本から見れば円建てで在庫あり、米国から見ればドル建てで在庫なし、ということが普通に起こります。検索結果の並び順も、表示される同意バナーも、AIが挙げる企業名も変わります。
だから、その国のアドレスから見に行く必要があります。 リクエストごとに国を指定していただき、そこから読みます。
2. どう読むか ―― 安い段から順に
ページの読み取りは3段階で、安い順に試します。
| 段 | 何をするか | 費用 |
|---|---|---|
css | 指定されたセレクタを読む | なし |
structured_data | サイトが既に公開している JSON-LD / OpenGraph を読む | なし |
llm | ページをモデルに説明させる | トークン |
前の段が取れた項目は、後の段では触りません。そして llm を選ばなければ、モデルは呼ばれません。 商品ページの多くは最初の2段で足ります。
これは費用の話であると同時に、再現性の話でもあります。セレクタと構造化データは、同じページなら同じ結果を返します。
一覧は「行」で返します
一覧ページを読むとき、列ごとに配列を返す設計にはしていません。
1枚のカードに価格が無いだけで、その配列だけが1つ短くなり、以降の組み合わせが全部ずれます。そしてこれはエラーになりません ―― 実在する商品名と実在する価格が並んだ、別々の商品の表ができあがります。後工程では検出できません。
Kansoku は行として返すので、欠けた項目はその行の中の空欄になり、前後はずれません。
3. 何を一緒に返すか
データだけでは、会議で守れません。全ての行に、こう付きます。
seller | 掲載されていた出品者そのまま |
url | 読み取ったページ |
retrieved_at | 読んだ時刻 |
fx_rate / fx_published_on | 適用した為替レートと、そのレート自体の公表日 |
price_ex_tax_jpy | 税抜に揃えた価格 |
level / attempts | どの段が値を出したか、試した全ての段とその結果 |
税抜への変換は取得時に一度だけ行い、比較はその列しか読みません。 税込の日本価格と税別の香港価格を引き算した結果、ある資料は「香港が12.9%安い」と書きました。正しくは4.3%で、一部の商品は相手市場のほうが高いという、符号ごと違う結論でした。
4. 出す前に止める
上のような誤りは、エラーを出しません。それらしい数字を作ります。 だから「人が見れば気づく」という前提を捨てて、実行可能な検査に変えています。
レポートは31項目の検査を通らなければ生成されません。付属品を商品として数えていないか、型番の枝番が落ちていないか、一覧から一度消えただけのものを成約と数えていないか。
検査が正しいデータで落ちたときは、検査のほうを直します。緩めません。
やらないこと
- フィンガープリントの偽装をしない
- CAPTCHA を迂回しない
- ログインを迂回しない
- 宣言された制限を超えない
- 読み取り先から個人情報を収集しない
原則だけでなく、商売の理由もあります。 一度拒否された取得元は二度と読めません。失うのは当社だけでなく、その情報源を必要としているお客様です。利害と倫理が同じ方向を向いています。
取得方針に、何を確認してから読むかを書いています。
最終更新 2026-08-21
最終更新