はじめに

こんにちは。

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

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

を開発しています。

ここまでの開発では、GPIを構成する5つの領域について、それぞれ実際のデータを調査してきました。

構成要素	暫定ウェイト	これまでの開発
USD/JPY	30%	Federal Reserve H.10
DRAM	25%	BLS等の関連ベンチマークを検証
NAND	20%	BLS Storage関連ベンチマークを検証
GPU需給	15%	SEC・Steam・国内小売を分離して検証
海上運賃	10%	GSCPI・BLS Deep Sea Freightを検証

Vol.11では、その中でも特に難しいGPU需給について、

• SEC EDGAR
• Steam Hardware Survey
• 日本のGPU小売価格
• Availability

を別々のシグナルとして扱う設計を紹介しました。

ここまで来ると、

「候補データはかなり揃ってきた。それなら一度GPIを計算してみればいいのでは？」

と思いますよね。

実際、私たちも次の段階へ進みました。

ただし、

公開はしません。

代わりに始めたのが、

Free-source Shadow Operation

です。

---

Shadow Operationとは？

Shadow Operationを簡単に言うと、

本番と同じようにデータを流して計算・検証するが、その結果を正式なGPIとして公開しない運用

です。

例えば、

公式・利用可能なデータ
        ↓
Collector
        ↓
PostgreSQL
        ↓
Validation
        ↓
Scoring
        ↓
GPI候補計算
        ↓
Shadow Evidence

という処理を実際に動かします。

しかし最後に、

公開

へは進みません。

内部でだけ動かします。

---

なぜ公開せずに動かすのか

理由は単純です。

設計書だけでは分からない問題が、実データを流すと必ず出てくるからです。

これまでの開発でも、

• BLS取得時のHTTP 403
• APIタイムアウト
• GSCPIの小数精度による偽Revision
• 月次データと週次GPIのFrequency差
• GPUデータの意味の違い
• データ利用権

など、実際に動かして初めて見つかった問題がありました。

つまり、

Unit Testが通った
Collectorが動いた
DBへ保存できた

だけでは不十分です。

GPIとして必要なのは、

5つのデータを同時に運用しても破綻しないか

です。

---

Free-source Shadow Profileを作成

そこでGadgetStreem Intelligenceでは、

gpi-free-proxy-shadow-v0.1

という専用プロファイルを作成しました。

このプロファイルは、

無料または利用可能な公的データだけを使って、GPI全体の動作を検証するための非公開構成

です。

実際のIssue #44では、このShadow Profile、実行Engine、Evidence Template、Policy、CI、Runbookなど26ファイル・2,141行規模の機能を追加しました。

---

Shadowで使うデータ

初期Shadow Profileでは、次の構成を採用しました。

USD/JPY

Federal Reserve H.10。

ここはこれまでの開発どおりです。

Federal ReserveはH.10で、米ドルに対する各国通貨の為替レートを公開しています。日本円についても日次観測値が掲載され、通常は前営業週分が米国東部時間の月曜日16時15分に公開されます。

---

DRAM候補

BLSの公的価格系列を、DRAMそのものではなく、

Proxy / Benchmark

として利用します。

BLSは公式Public Data APIを提供しており、HTTPSのGET／POSTを通じて公開済み統計をJSONなどで取得できます。

---

NAND候補

こちらもBLSのStorage Device関連系列を、

NANDそのものではないBenchmark

として利用します。

---

Freight候補

BLS Deep Sea Freight系列を使用します。

ただし、

Global Container Spot Rateそのものではない

という意味上の制約を残します。

---

GPU

GPUだけは少し特殊です。

初期Shadow Operationでは、

• Manual Steam
• 将来のSEC signal

という経路を用意しました。

Steam Hardware Surveyは毎月、Steam利用者のハードウェア構成を調査しており、参加は任意・匿名です。

またSEC EDGARについては、data.sec.govのREST APIから企業提出履歴やXBRL財務データを認証・APIキーなしで取得できます。

ただし、どちらもGPU需給そのものではないため、Production Sourceとしては扱いません。

---

「無料版GPI」を作るわけではない

ここはかなり重要です。

gpi-free-proxy-shadow-v0.1

という名前だけを見ると、

「有料データが使えないから、無料データ版GPIを作った」

ように見えるかもしれません。

そうではありません。

これは、

無料データを正式版へ代用するためのプロファイルではなく、GPIのシステム全体を検証するための実験環境

です。

そのため、DRAMやNANDなどについて、

Proxy
↓
そのままProduction Sourceへ昇格

とはしません。

---

固定ウェイトは変えない

GPIの初期ウェイトは、

USD/JPY   30%
DRAM      25%
NAND      20%
GPU       15%
Freight   10%

です。

Shadow Operationでも、この構成を維持します。

Issue #44の設計でも、

fixed weightsを維持し、interpolationとrenormalizationを禁止

することを明確にしました。

例えばGPUが使えないからといって、

GPU 15%を削除

残り85%を
100%になるよう再計算

とはしません。

---

なぜ85%を100%にしないのか

例えば、

USD/JPY：30%
DRAM：25%
NAND：20%
GPU：未準備
Freight：10%

なら、利用可能なのは

30 + 25 + 20 + 10
= 85%

です。

ここで、

85点満点を100点満点に換算すればいい

と考えることもできます。

しかし、それを行うと、

本来15%あるはずのGPUが存在しない指数

になります。

例えばUSD/JPYの実質的な影響度は、

30 / 85
≈ 35.3%

へ勝手に増えてしまいます。

それでは、

USD/JPY 30%

という最初のMethodologyと違います。

だから、

不足ウェイトは不足したまま表示する

というルールにしています。

---

月次データを週次へ補間しない

もう一つ禁止しているのが、

存在しない週次値を作ること

です。

DRAM候補、NAND候補、Freight候補には月次データがあります。

例えば、

6月：100
7月：104

だったとしても、

6月第2週：101
6月第3週：102
6月第4週：103

とはしません。

それは実際に観測された市場価格ではないからです。

GSIのMethodology Candidateでも、線形補間、silent substitution、missing-weight renormalization、将来データの利用を禁止しています。

---

過去データを使って実際に流す

Shadow Operationでは、最新データだけではなく、過去の期間も実際に処理します。

Issue #44では最初のHistory Windowを、

2022-01-01
    ↓
2026-07-18

に固定しました。

これは約4年半の期間です。

なぜ過去データが必要なのかというと、

0〜100へ変換するためには「今が過去と比べてどれくらい異常なのか」を知る必要がある

からです。

---

実際のネットワークへ接続して実行

Shadow Operationは、Fixtureだけのテストでは終わらせませんでした。

実際のBatch Cでは、

• New York Fed
• BLS Public Data API

などへネットワークアクセスしています。

実行ログでは、

New York Fed GSCPI
HTTP 200 OK

BLS Public Data API
HTTP 200

を確認しています。

そして実データを使ってShadow InputとShadow Packageを生成しました。

---

最初のReal Shadow Cycleが成功

そして、

最初の実Shadow Cycle

を実行しました。

結果は、

BATCH C PASSED

Historical window:
2022-01-01 ～ 2026-07-18

Decision:
NO_GO

でした。

「PASSEDなのにNO_GO？」

と思うかもしれません。

ここが今回の記事で最も重要なポイントです。

---

PASSEDとGOは違う

BATCH C PASSED

は、

予定していたShadow Operationを正しく実行できた

という意味です。

一方、

NO_GO

は、

公開版GPIとして出してよい条件はまだ満たしていない

という意味です。

つまり、

システムとして正常
＝ PASS

公開準備
＝ NO_GO

は両立します。

むしろ、これが期待した結果です。

---

最初のCycleでは85%が利用可能

実行後、Shadow Cycle #1を正式にレビューしました。

チェックポイントは、

2026-07-18

です。

結果は、

Cycle count：1
必要Cycle数：8

Automated slots fresh：true

Ready weight：0.85

GPU data ready：false

Coverage：
PARTIAL_GPU_PENDING

Lag：
PASS

Revision：
BASELINE_ONLY

Overlap：
INSUFFICIENT_CYCLES

Effective decision：
NO_GO

でした。

かなり意味のある結果です。

---

85%は「GPI＝85点」という意味ではない

ready weight = 0.85

を、

GPIが85点

と読んではいけません。

これは、

固定100%の構成のうち、85%分についてShadow計算に必要なデータ状態が整っていた

という意味です。

このときGPU15%はまだReadyではありませんでした。

したがって、

GPI：85

とは公開しません。

---

なぜGPUだけPendingなのか

GPUについてはVol.11で紹介したとおり、

• SEC EDGAR
• Steam Hardware Survey
• 国内GPU小売

という複数経路を検証しています。

しかし最初のShadow Cycle時点では、

GPUをGPIの15%として扱える状態

には達していませんでした。

そのため、

PARTIAL_GPU_PENDING

と判定しました。

---

8回のCycleを要求

1回成功しただけでは、Methodologyを評価できません。

そこでShadow Operationでは、

最低8回のWeekly Cycle

を評価する設計にしました。

初回は、

Cycle 1 / 8

です。

Issue #45では、これを改ざんしにくいAppend-only Ledgerとして記録し、

• Coverage
• Lag
• Revision
• Overlap
• Fixed Weight

などをCycleごとにレビューする仕組みを追加しました。

---

なぜ8週間必要なのか

一度正常に動くだけなら、

たまたま全データが揃った週だった可能性があります。

しかし実運用では、

Cycle 1
正常

Cycle 2
BLS更新なし

Cycle 3
GPU一部欠損

Cycle 4
Revision発生

Cycle 5
Provider遅延

といったことが起きます。

だから、

複数回連続で回したときに、どのように壊れるのか

を見る必要があります。

指数は、

一度計算できることより、継続して計算できること

の方が重要です。

---

Evidenceも残す

Shadow Cycleでは結果だけでなく、

Evidence

も保存します。

実際のCycle #1では、

• Audit ZIP
• Execution Log
• JSON
• SHA-256 Manifest
• Package Digest

を使って、実行結果を後から検証できるようにしました。

レビューでは、ZIP内の6つのJSONすべてについて内部SHA-256 Manifestとの一致を確認し、Cycle Recordを再生成してもコミット済みRecordとbyte-for-byteで一致しました。

つまり、

「そのとき何が起きたのか」

を後から再確認できます。

---

なぜSHA-256まで使うのか

例えば数か月後に、

「2026年7月18日のShadow結果は、本当に当時の結果なのか？」

を確認したくなるかもしれません。

Evidenceを書き換えられる状態では、検証できません。

そこでファイルの内容から、

SHA-256

というDigestを計算します。

一文字でも変われば別のDigestになります。

これにより、

当時レビューしたArtifactと、今見ているArtifactが同じか

を確認できます。

---

生データをそのままGitへ保存しない

一方で、すべてのデータをGitHubへ保存するわけでもありません。

データによっては、

• 再配布条件
• ライセンス
• 個別商品情報
• Provider制約

があります。

そこでShadow Evidenceでは、

Sanitized Metadata

を保存します。

Issue #44でも、

sanitized PostgreSQL metadata export

を採用しています。

つまり、

何を取得したか
いつ取得したか
何件あったか
どのRevisionか
どのDigestか

は残しつつ、

不必要なRaw Dataは残さない設計です。

---

GitHub Actionsでも契約を検証

Free-source Shadow Operationには、専用CIも追加しました。

初期実装時には、

Repository Health：PASS

Ruff format：PASS

Ruff lint：PASS

Shadow Operation Contract：
14 passed

Targeted Shadow + CLI：
48 passed

API tests collected：
412

まで確認しています。

ここでも重要なのは、

テストが通れば自動的に公開されるわけではない

ことです。

---

Shadow OperationからProductionへ直結させない

Shadow環境ではProxyが動いています。

しかし、

Shadowで安定
↓
自動でProductionへ昇格

という仕組みにはしていません。

Productionに進むには、

• Source Rights
• Semantic Fit
• Historical Coverage
• Methodology Review
• Weight Approval
• Legal / Data-use Review
• Release Approval

など、別のGateが必要です。

---

将来、有料データへ移行できる設計を残す

今回のShadow Profileは無料データを使っています。

しかし、将来、

• 正式なDRAM Spot Price
• NAND Wafer Price
• Global Container Spot Rate
• より直接的なGPUデータ

などの商用利用権を取得できる可能性があります。

そこでIssue #44では、

future commercial adapter / parallel-run / Methodology migration path

を残しました。

例えば将来、

Free Proxy
      ＋
Commercial Source

を同時にShadowで走らせ、

方向性
変化率
Lag
異常検出

を比較できます。

いきなりデータソースを切り替える必要はありません。

---

「無料データで妥協する」のではない

GPI開発では、

高額なライセンスが払えないなら完成しないのでは？

という問題に何度も直面しました。

しかし今回のShadow Operationによって、

正式データが揃うまで何もできない

という状態から抜けることができました。

今できることは、

無料・公的データ
↓
Collector
↓
履歴蓄積
↓
Validation
↓
Scoring
↓
Composite Simulation
↓
Shadow Cycle
↓
Evidence

です。

つまり、

Production Dataをまだ採用できなくても、システムとMethodologyの問題は先に潰せます。

---

Shadow CalculationはGO、Public PublicationはNO_GO

この考え方は、現在のGSI Governanceでも明確に分離しています。

Free Official Source Re-entry Policyでは、

Shadow Calculation：GO

Internal Validation：GO

Public Publication：NO_GO

Paid Data Acquisition：
CLOSED_FOR_INITIAL_PHASE

Fixed weights preserved：true

という状態です。

非常に分かりやすく言えば、

裏側ではどんどん試してよい。表にはまだ出さない。

ということです。

---

開発はこの後もさらに進んでいる

ここで、時系列について補足しておきます。

今回紹介しているのは、

Free-source Shadow Operationを初めて実運用へ移した段階

です。

GadgetStreem Intelligenceの実際の開発は、その後も継続しており、

• 各構成要素のSource再評価
• Production Qualification
• Historical Evidence
• Methodology Candidate
• GPU Shadow Cycle
• SEC EDGAR Reviewed Signal
• Freight Qualification

など、さらに先のGateへ進んでいます。

したがって、本記事中の

ready weight 0.85

や

Cycle 1 / 8

は、

現在のGPI完成度を示す最新値ではなく、最初のReal Shadow Cycleで得られた実績値

です。

この点は誤解のないよう明記しておきます。

---

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

Vol.12までで、

Federal Reserve
BLS
New York Fed
SEC
Steam
国内小売Shadow
        ↓
各Collector / Import
        ↓
PostgreSQL
        ↓
Validation
        ↓
Shadow Scoring
        ↓
固定ウェイト評価
        ↓
Evidence Package
        ↓
Cycle Review

というところまで進みました。

ついに、

GPIの各部品を個別に作る段階から、全体を一緒に動かす段階

へ入ったことになります。

---

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

ここまで何度も、

0〜100へ変換する

という言葉を使ってきました。

しかし、

USD/JPY：162円

BLS Semiconductor：○○

Storage PPI：○○

GSCPI：○○

GPU Retail：○○

という、単位も変動幅も更新頻度も違うデータを、

どうやって同じ

0〜100

へ変換するのでしょうか。

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

異なる市場データを同じ0〜100スケールへ変換する「Component Scoring」

を取り上げます。

• なぜ単純な前週比だけではダメなのか
• Z-scoreとは何か
• なぜRobustな手法を使うのか
• 0と100は何を意味するのか
• 異常値をどう扱うのか
• 月次データをどう週次Checkpointへ合わせるのか
• Scoreが100になったら何を意味するのか

を、できるだけ分かりやすく紹介します。

ここから、いよいよ

「市場データ」が「GPIの数字」へ変わり始めます。

---

まとめ

Vol.11までで、GPIを構成する5つの領域について、実際のデータ取得経路が少しずつ揃ってきました。

今回のVol.12では、それらを個別にテストするだけではなく、

Free-source Shadow Operation

として、実際に一つのPipelineへ流し始めました。

最初のReal Shadow Cycleでは、

Historical Window：
2022-01-01 ～ 2026-07-18

Automated Slots Fresh：
true

Ready Weight：
85%

GPU：
PARTIAL_GPU_PENDING

Cycle：
1 / 8

Decision：
NO_GO

という結果になりました。

85%のデータが使えるからといって、85%を100%へ拡大してGPIを公開することはしません。

不足ウェイトを他の項目へ再配分もしません。

月次データから架空の週次値も作りません。

そして、

BATCH C PASSED

でも、

Public Release = NO_GO

です。

これが今回作ったShadow Operationの役割です。

公開する前に、本物のデータで壊す。

壊れ方を確認し、直し、それでも説明できる状態になってから公開する。

GadgetStreem Intelligenceは、ようやく各Collectorを作る段階から、

「指数全体を実際に運用して検証する段階」

へ進みました。

まだGPIの数字を一般公開する段階ではありません。

しかし裏側では、すでに実データが流れ、複数の市場データを組み合わせる検証が始まっています。

次回はいよいよ、

この異なるデータをどうやって0〜100へ変換するのか

という、GPIの計算部分へ進みます。

---

※GPIは現在開発中の実験的な市場分析指標です。
本記事で紹介したgpi-free-proxy-shadow-v0.1は内部検証用の非公開Shadow Profileであり、無料Proxyを正式なDRAM、NAND、GPU、海上運賃のProduction Sourceとして採用したことを意味しません。
また、初回Shadow Cycleのready weight 0.85はGPIスコア85を意味するものではなく、当該CheckpointでShadow評価可能だった固定ウェイトの割合です。
個別製品の将来価格や購入利益を保証するものではなく、投資判断を目的とした金融指標でもありません。