はじめに
こんにちは。
GadgetStreemでは現在、ガジェット価格の上昇圧力を一つの数字で確認できる独自指数、
GPI(Gadget Pressure Index/ガジェット価格圧力指数)

を開発しています。
これまで、
- USD/JPY
- DRAM関連の半導体価格ベンチマーク
- NAND関連のストレージ機器価格ベンチマーク
と、一つずつ市場データをGadgetStreem Intelligenceへ取り込んできました。
前回のVol.8では、NAND Wafer価格とSSDなどの完成ストレージ価格は同じではないことを整理し、BLSのストレージ機器価格系列をbenchmark_onlyとして取得するCollectorを実装しました。
今回取り上げるのは、
GSCPI(Global Supply Chain Pressure Index)
です。
日本語にすると、
世界サプライチェーン圧力指数
といった意味になります。
名前だけを見ると、GPIの暫定構成要素である
海上運賃:10%
にかなり近そうに見えます。
しかし、調べるほど重要なことが分かってきました。
GSCPIは、海上運賃指数ではありません。
GSCPIとは?
GSCPIは、Federal Reserve Bank of New York、つまりニューヨーク連邦準備銀行が公開している世界のサプライチェーン状況を測る指標です。
目的は、輸送や製造業など複数の情報を組み合わせ、世界の供給網にどの程度の圧力がかかっているかを一つの指標として捉えることです。
GPIと考え方が少し似ています。
GPIも、
ドル円
DRAM
NAND
GPU需給
海上運賃
↓
一つのGPIへ
と、複数の市場情報をまとめようとしています。
一方GSCPIでは、世界の物流・製造に関する複数の情報から、
世界のサプライチェーン圧力
を一つの数字にしています。
GSCPIの中には海上運賃も入っている
GSCPIがGPIにとって興味深い理由は、輸送コストも構成要素に含まれていることです。
ニューヨーク連銀によると、GSCPIでは輸送費を見るために、
- Baltic Dry Index
- Harpex
- BLSの航空貨物運賃指数
などが利用されています。
つまり、
「海上輸送コストとは無関係」
ではありません。
むしろ海上輸送の状態は、GSCPIを構成する重要な情報の一つです。
しかし、それだけではありません。
製造業の情報も入っている
GSCPIには輸送コストだけでなく、製造業のサプライチェーン関連情報も組み込まれています。
ニューヨーク連銀は、中国、ユーロ圏、日本、韓国、台湾、英国、米国という7つの経済圏について、製造業PMIに関連する供給網データを利用しています。
概念的には、
海上輸送費
+
航空貨物費
+
製造業の納期
+
受注・在庫などの供給制約
↓
GSCPI
という、かなり広い指標です。
だからこそ、
GSCPI
=海上運賃
とはできません。
GPIで欲しい「海上運賃10%」とは違う
GPI Ver.0.1では、海上運賃へ暫定10%を設定しています。
ここで本来測りたいのは、
ガジェットや部品を輸送するときの海上輸送コストが、価格上昇圧力をどの程度高めているか
です。
これに対してGSCPIが測っているのは、
世界のサプライチェーン全体がどの程度逼迫しているか
です。
例えば製造業の納期が大幅に悪化すれば、海上運賃が大きく変わっていなくてもGSCPIが上昇する可能性があります。
逆に、特定航路のコンテナ料金が急騰していても、世界全体の供給網が比較的落ち着いていれば、GSCPIでは変化が小さく見える可能性もあります。
したがってGSIでは、
global_supply_chain_pressure_benchmark
という名前で管理しています。
ocean_freight_priceとは呼びません。
それでもGSCPIを取得する価値はある
海上運賃そのものではないなら、
「GPIには不要なのでは?」
とも考えられます。
しかし、GSCPIには大きな価値があります。
ガジェット価格へ影響するのは船賃だけではありません。
半導体不足や工場稼働、輸送遅延、部材不足などが同時に発生すれば、完成品価格へ強い圧力がかかる可能性があります。
ニューヨーク連銀の研究でも、GSCPIの変動と米国・ユーロ圏の財価格や生産者物価インフレとの関係が分析されています。
そのためGPIでは、
海上運賃の代用品ではなく、供給網全体を見るベンチマーク
として取得することにしました。
GSCPI Collectorを実装
そこでGadgetStreem Intelligenceへ、
gsi collect-gscpi
というCollectorを追加しました。
実装には、
- Collector本体
- データ取得サービス
- CLI
- PostgreSQL Integration Test
- Unit Test
- Data Source Review
- ADR
- Collector Specification
などが追加されています。実際のIssue #8では21ファイル、1,278行規模の初期実装となりました。
データ取得方式も途中で変更した
最初の実装では、ニューヨーク連銀が提供していたExcel形式のデータを前提にCollectorを作成しました。
しかし、実際の提供形態を確認した結果、現在のInteractive Dataに対応するCSV形式を使う方が適切であることが分かりました。
そこで実装を変更し、
Excel
↓
Interactive CSV
へ切り替えました。
古いExcel Fixtureを削除し、新しいCSV Fixture、ADR-0014-use-gscpi-interactive-csvを追加しています。
外部データを利用するシステムでは、
一度決めた取得方法が永遠に続くとは限らない
という、実際の運用らしい問題がここでも発生しました。
最新24か月分の保存に成功
修正後のCollectorを実行すると、
selected:24
inserted:24
revised:0
unchanged:0
status:success
となり、最新24か月分をPostgreSQLへ保存できました。
ここまでは、Vol.7やVol.8で作ったCollectorと同じ流れです。
しかし、GSCPIでは次の実行で興味深い問題が発生しました。
2回目の実行で「20件訂正」と判定された
同じデータをもう一度取得すれば、本来は、
inserted:0
revised:0
unchanged:24
となるはずです。
ところが、実際の結果は、
inserted:0
revised:20
unchanged:4
でした。
DBを見ると、
24か月
↓
44行
最大Revision:1
となっています。
一見すると、
ニューヨーク連銀が20か月分を一気に訂正した
ように見えます。
しかし、調査すると原因は公式データの訂正ではありませんでした。
原因は「小数点以下の精度」
GSCPIの元データには、小数点以下8桁を超える値が含まれていました。
一方、GSIのPostgreSQLでは観測値を、
NUMERIC(24, 8)
として保存しています。
つまり、
取得した値
0.123456789...
DB保存後
0.12345679
のように、保存時に小数第8位へ正規化されます。
ところが再取得時のRevision判定では、
元の高精度値
と、
DBへ保存された8桁値
を比較していました。
そのため、本当は同じデータなのに、
値が変わった
と誤判定していたのです。
Revision判定そのものを修正
これはGSCPIだけの問題ではありません。
将来、
- 為替
- DRAM
- NAND
- GPU
- 海上運賃
などで高精度データを扱った場合にも発生する可能性があります。
そこで、Collectorだけを応急処置するのではなく、
DBへ保存される精度へ正規化してからRevisionを比較する
よう、Observation Repository側を修正しました。
この修正は、
fix: canonicalize observation precision before revision checks
として実装されています。
誤って作られた20Revisionも削除
修正前に作られてしまった20件の偽Revisionについても、そのまま残してはいません。
古い行と、
- 値
- 単位
- Source Record ID
- Quality Status
- License Status
が完全に一致する後続Revisionだけを対象に削除しました。
実際のクリーンアップ結果は、
DELETE 20
でした。
その後、再び同じ24か月分を取得すると、
selected:24
inserted:0
revised:0
unchanged:24
となりました。
DBも、
total_rows:24
distinct_months:24
max_revision:0
へ戻っています。
これで本来の冪等性を確認できました。
小さなバグだけど、指数では重要
これは画面上ではほとんど分からないバグです。
しかしGPIでは、かなり重要です。
もし偽のRevisionを放置すると、
公式データが訂正された
という誤った履歴を残してしまいます。
さらに将来、
「なぜ過去のGPIが変わったのか」
を調査したときに、
本当はプログラム上の丸め誤差なのに、
データ提供元が訂正したから
と誤認する可能性があります。
GPIでは単に現在値を表示するだけでなく、
その数字がどう作られたのか後から説明できること
を重要視しているため、こうした細かなRevision整合性も修正しています。
GSCPI Collectorはmainへマージ済み
実装・CSV対応・精度問題の修正・テストを経て、GSCPI Collectorは正式にmainへ取り込まれました。
後続Issueのベース履歴では、
db82b7b
feat: add New York Fed GSCPI benchmark collector (#10)
として確認できます。
つまりGSCPIは、ローカルで試しているだけのデータではなく、GadgetStreem Intelligenceの正式なCollectorの一つになっています。
24か月から約29年分へ
Collectorの正常動作を確認した後、過去検証に使えるよう履歴を拡張しました。
最終的にGSCPIでは、
最古:1997年9月
最新:2026年6月
Raw observations:346
Scoring samples:120
まで取得できています。
内部のScoring Readiness判定は、
READY
です。
ただし、GPI適格性は、
benchmark_only
のままです。
ここはVol.7、Vol.8と同じく重要な区別です。
READY=GPIへ採用、ではない
GSI内部のREADYは、
必要な過去データがあり、検証用のスコア計算を実行できる
という意味です。
READY
≠
Production Ready
≠
GPIへの正式採用
≠
公開許可
です。
GSCPIは、十分な履歴データを取得でき、内部スコアも計算できます。
しかし、
海上運賃10%の正式データとして意味が一致していない
ため、その10%は割り当てていません。
GSCPIを0〜100へ変換することも可能になった
履歴が十分に揃ったため、GSCPIについても他の構成候補と同じ正規化処理を実行できます。
つまり、
GSCPIの元データ
↓
過去分布と比較
↓
変化を正規化
↓
0〜100の内部スコア
という計算まで、Shadow環境では実行できます。
しかし、その内部スコアは現在、
global_supply_chain_pressure_benchmark
として評価するだけです。
ocean_freight_score
としては公開しません。
GSCPIの更新頻度
GSCPIは月次更新です。
ニューヨーク連銀によると、原則として毎月第4営業日の午前10時(米国東部時間)またはその直後に更新されます。
GPIは週次更新を想定していますが、ここでも月次データを無理やり週次化しません。
新しいGSCPIが公表されるまでは、最新観測値を持ち越し、
前月値
↓
翌週
↓
同じ観測値
として扱います。
2点の間を直線で補間して、存在しない週間変動を作ることはしません。
GSCPIはShadow検証で使う
現在の位置付けを整理すると、
公式データ取得 :OK
Collector :実装済み
PostgreSQL保存 :OK
重複防止 :OK
Revision精度 :修正済み
過去履歴 :346観測
Scoring Readiness :READY
GPI Eligibility :benchmark_only
海上運賃10% :未割り当て
Production Ready :NO
公開GPI :NO_GO
です。
ここまで来ると、
「もう使ってもよいのでは?」
とも思えます。
しかしGSCPIは、最後まで供給網ベンチマークです。
海上運賃そのものではありません。
なぜ海上運賃データを別に探すのか
GPIの海上運賃10%で本当に欲しいのは、
海上輸送サービスの価格変化を、より直接的に捉えるデータ
です。
GSCPIには、
- 海上輸送
- 航空貨物
- 製造業
- 納期
- 供給制約
などが混ざっています。
そこで後続開発では、GSCPIとは別に、
直接的なDeep Sea Freight価格系列
を探しています。
実際の現在のGSI開発では、BLS PPIの
PCU483111483111P
を、無料で取得可能な米国Deep Sea Freight Primary Servicesの月次候補として選定するところまで進んでいます。
ただし、こちらも世界の主要コンテナ航路を週次で測るSpot Rate Indexではないため、海上運賃10%はまだ割り当てていません。
GSCPIと直接運賃候補を分ける
今後は、二つを明確に分離します。
GSCPI
=世界の供給網全体の圧力を見る
「Supply Chain Benchmark」
Deep Sea Freight PPI
=海上輸送サービスの価格を見る
「Freight Price Benchmark」
さらに理想としている、
世界主要航路
+
コンテナ
+
Spot Rate
+
週次
のデータとは、また別です。
この違いを曖昧にしないことが、GPIの信頼性につながると考えています。
「近いデータ」を安易に代入しない
Vol.7では、
BLS半導体指数
≠ DRAM価格
としました。
Vol.8では、
BLSストレージ機器PPI
≠ NAND価格
としました。
そして今回は、
GSCPI
≠ 海上運賃
です。
一見すると、
なかなかGPIに使えるデータが決まらない
ようにも見えるかもしれません。
しかし、これは意図した動作です。
似た数字を見つけて、
これでいいだろう
と20%、10%、25%へ割り当てれば、GPIの数値自体はすぐ作れます。
しかし、それでは表示されているラベルと、中で使っているデータの意味が違う指数になります。
GSIでは、
「計算できる」ことより、「何を計算したのか正しく説明できる」こと
を優先します。
今回できるようになったこと
Vol.9までで、GadgetStreem Intelligenceでは、
Federal Reserve H.10
↓
USD/JPY
BLS
↓
Semiconductor Benchmark
BLS
↓
Storage Device Benchmark
New York Fed
↓
Global Supply Chain Pressure Benchmark
という複数の公式・公的データパイプラインを持つようになりました。
さらに、
- Revision管理
- 冪等性
- 取得形式変更への対応
- Decimal精度の統一
- Historical Backfill
- Scoring Readiness
- BenchmarkとProduction Sourceの分離
という、指数を長期間運用するための仕組みも少しずつ整ってきています。
次のVol.10で紹介すること
次回のGPI開発日誌 Vol.10では、
「GSCPIより直接的な海上運賃データを無料で取得できないか?」
に進みます。
実際のGSI開発では、BLSの
PCU483111483111P
をDeep Sea Freightの候補としてCollectorまで構築し、
- 商用利用条件
- 月次という更新頻度
- 米国Deep Sea Freightという対象範囲
- 世界のコンテナSpot Rateとの違い
- 過去データ
- Revision
- GPIの海上運賃10%へ使えるか
を評価するところまで進んでいます。
現在の結論はまだ、
Freight weight assigned:false
Production ready:false
Effective decision:NO_GO
です。
次回は、「海上運賃にかなり近い無料データ」を見つけても、まだ10%を割り当てなかった理由を紹介します。
まとめ
GPI開発日誌 Vol.9では、ニューヨーク連銀のGSCPIをGadgetStreem Intelligenceへ取り込みました。
GSCPIは、輸送コストと製造業の供給制約などを組み合わせて、世界のサプライチェーン圧力を測る指数です。
開発では、
- GSCPI Collectorを実装
- 現行Interactive CSVへ対応
- 最新24か月をPostgreSQLへ保存
- 2回目取得時の偽Revision問題を発見
- 小数精度の正規化ロジックを修正
- 誤って作成された20Revisionを削除
- 再実行で24件すべて
unchangedを確認 - 1997年までさかのぼり346観測を取得
- Scoring Readinessを
READYまで到達
という段階まで進みました。
しかし、GSCPIは海上運賃そのものではありません。
現在も、
GPI Eligibility:benchmark_only
海上運賃10%:未割り当て
公開判定:NO_GO
です。
GadgetStreem Intelligenceでは、
似ているデータを無理に当てはめるのではなく、そのデータが本当に何を測っているのかを確認する
という方針を続けます。
次回は、GSCPIより一歩「海上運賃」に近いDeep Sea Freight価格データへ進みます。
GPIはまだ公開できる状態ではありません。
しかし、裏側では一つずつ、
「なぜこの数字を使うのか説明できる指数」
へ近づいています。
引き続き、完成までの過程を公開していきます。
※GPIは現在開発中の実験的な市場分析指標です。
GSCPIはニューヨーク連銀が開発した世界サプライチェーン圧力の研究指標であり、海上運賃そのものを表す指数ではありません。
現時点ではGPIの海上運賃構成要素へウェイトを割り当てていません。
また、GPIは個別製品の将来価格や購入利益を保証するものではなく、投資判断を目的とした金融指標でもありません。



コメント