GPI開発日誌 Vol.7｜BLS半導体プロキシCollectorを実装―DRAMではないデータを、どう安全に使うか

はじめに

こんにちは。

GadgetStreemでは現在、ガジェット価格の上昇圧力を一つの数字で確認できる独自指数、

GPI（Gadget Pressure Index／ガジェット価格圧力指数）

を開発しています。

これまでのGPI開発日誌では、最初の構成要素となるUSD/JPYについて、

• 公式データの取得
• PostgreSQLへの保存
• 重複防止
• 訂正履歴
• 実行履歴
• 鮮度判定
• 継続運用

まで進めてきました。

前回のVol.6では、GPIの二つ目の構成要素であるDRAM価格について調査しました。

その結果、DRAM市場との意味の一致では、TrendForceのDRAM価格が最有力候補となりました。

しかし、現時点では商用ライセンスや自動取得、保存、派生指数での公開に関する条件を満たせないため、正式採用を保留しています。

代わりに、検証用の無料プロキシ候補として選んだのが、米国労働統計局、

BLS（U.S. Bureau of Labor Statistics）

が公開する半導体輸入価格指数です。

今回のVol.7では、このBLSデータを実際に取得し、GadgetStreem Intelligenceへ保存するCollectorを実装します。

ただし、最初に大切なことを明記しておきます。

今回取得するデータは、DRAM価格そのものではありません。

---

使用する系列は「EIUIR21320」

今回のCollectorで取得する系列IDは、

EIUIR21320

です。

BLSの公式系列一覧では、半導体を対象とする輸入価格指数として管理されています。

GadgetStreem Intelligenceでは、このデータを

semiconductor_import_price_proxy

という内部名称で保存します。

あえて、

dram_price

とは呼びません。

対象がDRAMだけではなく、より広い半導体価格だからです。

DRAM価格が上昇していても、他の半導体価格が下落していれば、BLS指数の変化は小さくなる可能性があります。

反対に、DRAMが動いていなくても、別の半導体価格が上昇することで指数が動く可能性もあります。

そのため、この系列の役割は、

DRAM市場を直接表す正式データ

ではなく、

半導体分野全体の輸入価格圧力を観測するベンチマーク

です。

---

BLS Collectorの処理フロー

今回実装したCollectorは、次のように動きます。

BLS公式データ
       ↓
EIUIR21320を取得
       ↓
年・月・数値・脚注を検証
       ↓
月次データへ正規化
       ↓
重複・訂正の有無を確認
       ↓
PostgreSQLへ保存

Collectorでは、次の情報を確認します。

• 取得した系列IDが正しいか
• 年が正しい形式か
• 月がM01〜M12か
• 数値として変換できるか
• 年平均を示すM13ではないか
• 同じ観測月がすでに保存されていないか
• BLS側で過去値が訂正されていないか

市場データの数値は、浮動小数点ではなくDecimalとして処理します。

また、取得したレスポンスにはSHA-256ハッシュを付け、同じ内容だったかを確認できるようにします。

---

最初の設計では一括ダウンロードを使う予定だった

当初の設計では、BLSが公開しているタブ区切りの一括データファイルを取得する予定でした。

この方式であれば、一度の通信で対象系列の履歴をまとめて取得できます。

Collectorの初期実装も、一括ファイルから

series_id
year
period
value
footnote_codes

を読み取る構成として作りました。

しかし、実際にDocker環境から取得を試したところ、

HTTP 403 Forbidden

が返されました。

つまり、ファイルの場所は存在していても、実行環境からの取得が許可されませんでした。実際の実行ログでも、一括ファイルへのアクセスが403で失敗しています。

---

動かない取得経路へ固執しない

ここで、

• User-Agentを偽装する
• ブラウザーの動作を再現する
• アクセス制限を回避する
• 別の非公式サイトから同じデータを取る

といった対応は採用しませんでした。

GPIは、短期間だけ動けばよい実験ではありません。

毎月安定して取得し、過去データを保存し、将来的に公開指数へ使う必要があります。

そのため、取得経路が公式に用意されていても、実際の運用環境で安定して使用できない場合は、別の公式手段へ切り替えます。

今回選んだのが、

BLS Public Data API

です。

BLSのPublic Data APIは、公開済みの時系列データをJSONまたはExcel形式で取得でき、GETとPOSTの両方に対応しています。Version 1は登録不要で公開利用できます。

---

公式Public Data APIへ切り替え

403エラーを受けてCollectorを修正し、BLS Public Data API Version 1からEIUIR21320を取得する方式へ変更しました。

この変更によって、

BLS Public Data API
       ↓
JSONレスポンス
       ↓
EIUIR21320だけを確認
       ↓
月次観測値を解析
       ↓
PostgreSQLへ保存

という流れになりました。

実装上も、当初の一括ファイル方式からPublic Data API方式へ切り替える修正コミットが追加されています。

BLSのVersion 1 APIでは、系列IDを指定して時系列データを取得できます。APIから返されるのは主に観測値と脚注で、詳細な系列メタデータは別途管理する必要があります。

そのためGSIでは、

• 系列名称
• 単位
• 更新頻度
• 利用目的
• DRAMではないという制約
• GPIでの採用状態

を自前のData Source ReviewとADRで管理します。

---

CLIから実行できる

Collectorは、CLIコマンドから実行できます。

処理結果はJSON形式で出力されます。

{
  "status": "success",
  "source": "bls_mxp",
  "indicator": "semiconductor_import_price_proxy",
  "series_id": "EIUIR21320",
  "selected": 24,
  "inserted": 24,
  "revised": 0,
  "unchanged": 0
}

この出力によって、

• 何件を取得対象にしたか
• 新しく何件保存したか
• 何件が訂正されたか
• 何件がすでに登録済みだったか

を確認できます。

---

最初の実行で24か月分を保存

修正後のCollectorを実行したところ、正常に24か月分のデータを取得できました。

最初の実行結果は、

selected：24
inserted：24
revised：0
unchanged：0
status：success

でした。

つまり、選択した24か月分がすべて新規観測値としてPostgreSQLへ保存されています。

データベースを確認した結果も、

total_rows：24
distinct_months：24
max_revision：0

となりました。

同じ月が重複しておらず、最初の保存なのでRevisionも0です。

---

2回目の実行では24件すべて「変更なし」

Collectorを同じ条件でもう一度実行しました。

2回目の結果は、

selected：24
inserted：0
revised：0
unchanged：24
status：success

でした。

つまり、すでに保存済みの24か月分について、新しい行は一つも作られませんでした。

1回目
24件を新規保存

2回目
24件すべて変更なし

という結果です。

これにより、Collectorを繰り返し動かしても同じデータが増殖しない、

冪等性

を実際のBLSデータで確認できました。

---

BLSが値を訂正した場合はRevisionを追加する

BLSの統計データは、後から訂正される可能性があります。

Collectorが以前と異なる値を検出した場合、過去の値を無言で上書きしません。

例えば、

Revision 0：100.2
Revision 1：100.4

という形で、新しいRevisionを追加します。

これにより、

• 最初に取得した値
• 後から訂正された値
• 訂正された時期
• GPI計算への影響

を後から確認できます。

同じ値であればunchanged、値が変わっていればrevisedとして区別します。Collector仕様でも、同じ観測値の再取得では重複を作らず、公式値が変わった場合は旧Revisionを残したまま新しいRevisionを作ることを要求しています。

---

CollectorはGitHubのmainへマージ済み

BLS半導体ベンチマークCollectorは、実装・修正・テストを完了した後、Pull Requestを経てmainへ取り込まれました。

履歴上では、

85915d9
feat: add BLS semiconductor benchmark collector

として記録されています。

つまり、これは単なる設計案やローカル実験ではなく、GadgetStreem Intelligenceの正式なコードベースへ追加済みのCollectorです。

---

過去データを65観測まで拡張

最初の実装確認では24か月分を保存しましたが、その後、過去検証に必要な履歴を追加取得しました。

履歴バックフィルの実行では、BLS半導体プロキシについて、

保存前：24観測
新規追加：41観測
保存後：65観測
変換後サンプル：53

となり、内部のスコアリング準備判定はREADYとなりました。

ただし、このREADYは、

GPIのDRAM要素として公開準備ができた

という意味ではありません。

あくまで、

履歴データ量が、検証用の計算を実行できる水準へ達した

という意味です。

この系列のGPI適格性は、引き続き

benchmark_only

です。

---

月次データを週次GPIでどう扱うか

GPIは週次で更新する予定ですが、BLSの半導体輸入価格指数は月次データです。

そのため、データが取得できたからといって、毎週新しい変化が発生するわけではありません。

ここで月次の2点を直線で結び、

今週は100.1
翌週は100.2
翌々週は100.3

といった架空の週次値を作ることはしません。

無料プロキシ戦略では、

• 月次観測値を次の公表まで持ち越す
• 直線補間は禁止する
• 75日を超えた場合はStaleとする
• 訂正可能期間を考慮する
• DRAM枠への自動置き換えは禁止する
• 欠けたウェイトを他項目へ再配分しない

というルールを追加しました。

週次表示のために、存在しない市場変動を作らないことを優先しています。

---

「動いた」ことと「採用できる」ことは別

ここが今回の記事で最も重要な部分です。

BLS Collectorは正常に動きました。

• 公式APIから取得できた
• 24か月分を保存できた
• 再実行時の重複を防げた
• 履歴を65観測まで拡張できた
• 検証用の変換処理を実行できた

しかし、それでもBLSプロキシをDRAMの暫定25%へ割り当ててはいません。

現在の状態は次のとおりです。

Collector実装：完了
データ取得：成功
履歴保存：成功
冪等性：確認済み
検証用データ量：READY
DRAMとの意味の一致：未証明
DRAM枠へのウェイト割り当て：なし
正式なMethodology変更：未承認
本番公開：未承認

GSIの無料メモリプロキシ戦略でも、DRAM候補とNAND候補は選定済みですが、両方とも本番準備完了ではなく、公開数値のリリース判定はNO_GOです。

---

その後、Shadow運用へ進んだ

GPIの開発は、今回のCollector実装後も進んでいます。

BLS半導体プロキシは、後続の

gpi-free-proxy-shadow-v0.1

という非公開のShadowプロファイルへ組み込まれました。

Shadow運用とは、正式な公開指数へは使わず、裏側で実際のデータを流して、

• 欠損しないか
• 定期更新できるか
• 他の指標と時点を揃えられるか
• スコアが異常に動かないか
• 過去データで継続計算できるか

を検証する運用です。

このShadowプロファイルでは、

• FX：Federal Reserve H.10
• DRAM候補：BLS半導体プロキシ
• NAND候補：BLSストレージ機器プロキシ
• 海上運賃候補：BLSまたは関連公的系列
• GPU：手動・候補データ

を使いますが、固定ウェイトの再配分や不足データの補間は禁止しています。

実際のShadowサイクルではBLS Public Data APIへの接続がHTTP 200となり、監査用パッケージの生成まで成功しました。

それでも最終結果は、

NO_GO

です。

これは失敗ではありません。

GPU、Methodology、法務、ステージング、公開承認などのゲートが未完了であるため、設計どおり公開を止めている状態です。

---

なぜここまで慎重にするのか

GPIの計算を早く完成させるだけなら、BLSの値へ25%を割り当てることもできます。

しかし、それでは読者から見たとき、

DRAM価格：25%

と表示されているのに、実際には広い半導体輸入価格指数を使っていることになります。

これは、技術的に計算できるかどうかとは別の問題です。

指数の名称と、中で使われているデータの意味が一致しなければ、GPI全体の信頼性を損ないます。

そのため現在は、

BLS半導体輸入価格指数
＝DRAM価格

とは扱いません。

正確には、

BLS半導体輸入価格指数
＝DRAM関連の価格圧力を検証する候補プロキシ

です。

---

今後検証すること

今後は、蓄積したBLSデータを使って次の検証を行います。

日本のメモリ小売価格との関係

BLS指数が上昇した後、日本のDDR4・DDR5小売価格も上昇しているかを確認します。

時間差

小売価格へ反映されるまで、

• 数週間
• 1か月
• 2か月
• それ以上

のどの時間差があるかを調べます。

方向性の一致

BLS指数とDRAM市場情報が、上昇・下落の方向でどの程度一致するかを確認します。

変化の感度

DRAM価格が大きく動いたとき、BLS指数にも十分な変化が現れるかを検証します。

DRAM以外の影響

他の半導体価格に引っ張られ、DRAM市場と無関係な動きをしていないか確認します。

これらを通過しなければ、Collectorが正常に動いていてもGPIへは採用しません。

---

今回できるようになったこと

今回の開発によって、GadgetStreem Intelligenceでは次のことが可能になりました。

BLS公式APIへ接続
       ↓
EIUIR21320を取得
       ↓
月次データを検証
       ↓
PostgreSQLへ保存
       ↓
重複と訂正を管理
       ↓
過去履歴を追加取得
       ↓
Shadow環境で継続評価

USD/JPYに続いて、二つ目の公的データCollectorが実際に動き始めました。

ただし、USD/JPYと今回のBLSデータには大きな違いがあります。

USD/JPYは、GPIで使うドル円を直接表します。

BLSの半導体指数は、GPIで使いたいDRAM価格を直接表しません。

そのため、Collectorの実装後にも長い検証が必要です。

---

次のVol.8で紹介すること

次回のGPI開発日誌 Vol.8では、

NAND価格のデータソース選定と、ストレージ機器価格プロキシ

を取り上げます。

DRAMと同じように、NANDにも、

• NAND Wafer Spot Price
• NAND契約価格
• SSDコントローラーを含む完成品価格
• クライアントSSD
• エンタープライズSSD
• USBメモリ
• SDカード

など、複数の市場があります。

さらに、DRAMで採用したBLS半導体プロキシを、そのままNANDにも使うことはできません。

現在の開発では、NANDの正式候補を保留しながら、BLSのストレージ機器価格系列を別名称のベンチマークとして検証しています。

Vol.8では、

NAND価格とストレージ機器価格は、どこまで同じ動きをするのか

を整理します。

---

まとめ

GPI開発日誌 Vol.6では、DRAM専用データの本命候補をTrendForceとして残しつつ、現段階では商用条件を満たせないため保留としました。

今回のVol.7では、無料の検証候補であるBLS半導体輸入価格指数について、

• Collectorの実装
• 403エラーの発生
• 公式Public Data APIへの切り替え
• 最新24か月分の保存
• 再実行時の重複防止
• Revision管理
• 過去65観測への拡張
• Shadow運用への組み込み

まで進めました。

Collectorは正常に動いています。

しかし、

正常に取得できることと、DRAM価格として採用できることは別

です。

BLSデータは今も、

benchmark_only

として管理しています。

DRAMの暫定25%は割り当てておらず、GPIの公開判定も引き続きNO_GOです。

GadgetStreem Intelligenceでは、使える数字を急いで指数へ入れるのではなく、

そのデータが何を意味し、どこまで代わりとして使えるのか

を検証してから採用します。

次回は、NANDとストレージ機器価格の違いを整理し、三つ目の市場データCollectorへ進みます。

引き続き、GPIが実際の公開指数として完成するまでの過程をお伝えしていきます。

ぜひ一緒に見守っていただけるとうれしいです。

---

※GPIは現在開発中の実験的な市場分析指標です。
BLSの半導体輸入価格指数はDRAM価格そのものではなく、検証用のプロキシ候補として扱っています。
現時点でGPIのDRAM構成要素へウェイトは割り当てていません。
個別製品の将来価格、値上げ、値下げ、在庫状況、購入利益を保証するものではなく、投資判断を目的とした金融指標でもありません。