TrendForceのDRAM価格は当日値しか取れない、と思ったら個人が毎日スクレイピングしていた

開発financial-data

TrendForceのDRAM価格は当日値しか取れない、と思ったら個人が毎日スクレイピングしていた

自分のサイトのdev限定ページ（メモリ価格の推移）を眺めていて、DRAMスポット価格のグラフがほぼ横一直線に見えることに気づいた。理由はすぐに分かった。取得を始めてまだ数日で、データ点が2つしかない。TrendForceの無料公開ページは当日のスナップショットしか出さない仕様なので、後から過去分を遡って取ることができない。

「これ、誰かがまとめてたりしないですかね」と聞いてみた。厳密な統計データベースだけでなく、個人のブロガーが趣味で追いかけていたりしないか、という角度で調べ直してほしいという意図だった。

まず5方向で並列調査した

Workflowを使い、次の5方向を同時に調べさせた。

  1. Wayback Machine（Internet Archiveの過去スナップショット）
  2. 半導体業界メディアの価格チャート記事
  3. GitHub・個人ブログによる継続的なトラッカー
  4. 中国語圏のTrendForce関連サイト（dramx.com等）
  5. FRED・Statista等の統計データベース

結果、一次情報源（TrendForce自身、DRAMeXchange、中国語版）はどこも同じ壁にぶつかった。当日値は無料、履歴は会員登録の壁の向こう側。Statistaには専用ページまであったが、数値はすべて伏字で月額$199からの有料会員限定。FREDやTrading Economicsには、そもそもDRAM専属の系列自体が存在しなかった。

一方で、GitHub上にTrendForceの公開ページを毎日自動スクレイピングして、無料で公開しているプロジェクトが2件見つかった。

  • SonChangGi/dram-price — 韓国の大学院生が運用する個人ダッシュボード。GitHub Actionsで平日自動実行、ライブダッシュボードも公開している
  • shirley-weg/trendforce_report — TrendForce台湾サイトを毎日取得し、日次のPDFレポートを生成するツール

どちらも前日（2026-07-20）時点まで稼働していることを確認できた。

インポート前に「怪しくないか」を確認した

見つけた直後にそのままインポートを進めさせそうになったが、その前に「内容が怪しくないか一応確認してほしい」と釘を刺した。知らない個人が公開しているコード・データを無条件に自分のサイトに取り込むのは、それ自体がリスクになる。

そこで改めてWorkflowを使い、5つの観点で並列に監査させた。

  1. SonChangGi/dram-price のコード監査（不審な外部通信・難読化コードの有無）
  2. shirley-weg/trendforce_report のコード監査
  3. SonChangGi/dram-price のデータ実在性検証（本物のTrendForce値と一致するか）
  4. shirley-weg/trendforce_report のデータ実在性検証
  5. 両リポジトリの一般的な信頼性（作者アカウントの実在感・コミット履歴の自然さ）

データは両方とも本物だった

決め手になったのは数値の突き合わせだった。ちょうど手元のmemoryPrices.tsに2026-07-20時点のDDR5 16Gb (2Gx8) 4800/5600の実測値（平均$49.767）があったので、これを2つのリポジトリのデータとそれぞれ照合させた。

結果は両方とも小数点まで完全一致。shirley-weg側は変化率のフィールドまで独立に再計算させたところ、記録されている値と機械的に一致した。捏造やAI生成のデータであれば出にくい精度の一致で、本物のスクレイピング結果だと判断できた。

コードにも悪意はなかったが、1つ罠があった

コード監査では、外部への不審な通信・難読化・危険な権限要求はどちらにも見つからなかった。SonChangGi側はpip外部依存がゼロで、GitHub ActionsのサードパーティアクションをすべてフルコミットSHAで固定するなど、サプライチェーン対策まで意識された実装になっていた。

一方、shirley-weg側には見落としやすい罠が1つあった。コード内にメール送信先が作者自身のGmailアドレスとしてハードコードされており、ワークフロー側には自分用の送信先設定が入っていない。つまり、そのままフォークしてSMTP認証情報だけ設定すると、生成された日次レポートが自分のメールではなく作者宛に送信され続ける構造になっていた。データを盗む類の悪意ではなく、単に「自分用に作ったツールを他人がそのまま動かすと起きる」設計上の見落としだった。README自体には送信先が明記されており、隠されていたわけではない。

結論

両リポジトリとも、データの実在性・コードの安全性ともに問題はなく、インポートして良いと判断した。shirley-weg側を使う場合は、メール送信部分は使わずデータ取得ロジックだけを抜き出すのが安全という結論になった。

この後、実際のデータ構造を確認し、自サイトのmemoryPrices.tsに過去分を取り込む作業に進めている。

学びメモ

  • 「無料枠には過去データがない」という一次情報源の制約は事実でも、それを個人が肩代わりして毎日蓄積しているケースがある。ブロガー・個人開発者の継続的な副産物という角度は、統計データベースを一巡した後にこそ効く
  • 見つけたデータをそのまま信じず、手元に実測値がある場合は数値を直接突き合わせるのが一番確実な検証になる。捏造データは細部の整合性（変化率の再計算等）まで一致しないことが多い
  • OSSの個人プロジェクトは「悪意」だけでなく「善意の設計ミス」も見ておく必要がある。今回のメール送信先ハードコードのように、コピーして動かした瞬間に意図しない副作用が起きる構造は、コードレビューで見落としやすい
#TrendForce #DRAM#データ収集 #GitHub#OSS監査