GPI開発日誌 Vol.14|5つのスコアをどう1つにする?「85%を100%にしない」GPI Composite Engine

目次

はじめに

こんにちは。

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

GPI(Gadget Pressure Index/ガジェット価格圧力指数)

を開発しています。

前回のVol.13では、q

USD/JPY:円
DRAM:価格指数
NAND:価格指数
GPU:数量・需給系データ
Freight:輸送価格指数

という、単位も値の大きさも違う市場データを、

0 ~ 100

という共通スケールへ変換する、

Component Scoring

の仕組みを紹介しました。

これによって、

USD/JPY Score
DRAM Score
NAND Score
GPU Score
Freight Score

という5種類のComponent Scoreを作れるようになります。

しかし、GPIの目的は5つの数字を表示することではありません。

最終的には、

ガジェット市場全体の価格上昇圧力を、一つの数字として表す

ことを目指しています。

そこで今回扱うのが、

GPI Composite Engine

です。


5つのスコアを単純平均するわけではない

一番簡単なのは、

5つのScoreを足す
↓
5で割る

という方法です。

例えば、

USD/JPY   60
DRAM      70
NAND      50
GPU       80
Freight   40

なら、

(60 + 70 + 50 + 80 + 40) ÷ 5
= 60

です。

しかしGPIでは、この計算を使いません。

理由は、

それぞれの市場要因が日本のガジェット価格へ与える影響を、同じ20%とは考えていない

からです。


GPIの固定ウェイト

GPIの初期Methodologyでは、5つのComponentに次のウェイトを設定しています。

ComponentWeight
USD/JPY30%
DRAM25%
NAND20%
GPU需給15%
Freight10%
合計100%

この構成は、GPI開発初期から基本設計として維持してきました。

ドル円を30%と比較的大きくしているのは、日本国内のガジェット価格が輸入コストやメーカーの国内価格設定を通じて為替の影響を受けやすいと考えているためです。

一方で、

DRAM
NAND
GPU
Freight

も、それぞれ異なる経路から価格形成へ影響します。

ただし、この30・25・20・15・10という比率が「絶対に正しい」と考えているわけではありません。

ウェイトの妥当性については、Historical BacktestやSensitivity Analysisを使って別途検証していきます。

重要なのは、

運用中に都合よくウェイトを変更しない

ことです。


Composite GPIの基本式

5つのComponentがすべて利用可能だとすると、GPIは概念的には次の式になります。

GPI
=
USD/JPY Score × 0.30
+
DRAM Score × 0.25
+
NAND Score × 0.20
+
GPU Score × 0.15
+
Freight Score × 0.10

非常にシンプルです。

ただし、GPI開発ではこの単純な式の周りに、

Validation
Eligibility
Coverage
Methodology
Governance
Publication Gate

という多くの条件を設けています。

むしろ難しいのは、

足し算そのものではなく、「足してよい数字かどうか」を判断すること

です。


Weighted Contributionとは?

各Component ScoreにWeightを掛けた値を、

Weighted Contribution

と呼びます。

例えば、仮にUSD/JPY Scoreが60だったとします。

Weightは30%なので、

60 × 0.30
=
18

です。

USD/JPYはGPI全体へ、

18ポイント

寄与することになります。

DRAMが70なら、

70 × 0.25
=
17.5

です。

このように、

Component Score
×
固定Weight
=
Weighted Contribution

を計算します。

GSI内部でも、各Componentについて、

configured_weight
score
weighted_contribution
status

を別々に保持する設計になっています。


仮の5Componentで計算してみる

ここでは説明用に、完全な架空データを使います。

現在の実GPIではありません。

仮に、

ComponentScoreWeightContribution
USD/JPY6030%18.0
DRAM7025%17.5
NAND5020%10.0
GPU8015%12.0
Freight4010%4.0

だったとします。

合計すると、

18.0
+17.5
+10.0
+12.0
+4.0

= 61.5

です。

したがって、

Composite GPI
=
61.5

となります。

この61.5も、前回説明したComponent Scoreと同様、

「価格が61.5%上昇する」

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

0〜100の共通スケール上で見た、

ガジェット市場全体の上方向価格圧力

を表します。


50を基準として読む

Component Scoringと同じく、Composite GPIでも50付近が一つの基準になります。

概念的には、

0
強い価格低下方向

25
低下方向の圧力が比較的強い

50
過去の中心付近

75
価格上昇方向の圧力が強い

100
非常に強い価格上昇方向

という読み方です。

ただし、

GPI 70
↓
70%の確率で値上がり

ではありません。

また、

GPI 70
↓
製品価格が70%上昇

でもありません。

GPIはあくまで、

市場圧力指数

です。


Composite Engineで最も重要なのは「計算しない判断」

ここからがGPI Composite Engineの重要な部分です。

例えば、

USD/JPY   READY
DRAM      READY
NAND      READY
GPU       NOT READY
Freight   READY

だったとします。

利用可能なWeightを合計すると、

30%
+25%
+20%
+10%

= 85%

です。

数学的には、この4Componentだけを足すこともできます。

しかしGPIでは、

それを正式なComposite GPIとして扱いません。


現在まさに85%の状態

これは仮の話だけではありません。

直近の確認済みGPI Production状態では、

USD/JPY
INCLUDED

DRAM
INCLUDED

NAND
INCLUDED

Freight
INCLUDED

GPU
HISTORY_ACCUMULATION

です。

Production Coverageは、

85%

です。

必要条件は、

100%

です。

GPUについては現在、

Transformed samples
23 / 36

で、Production Component Qualificationをまだ完了していません。

したがって現在も、

Composite GPI
WITHHELD

です。


同じ「85%」でもVol.12の85%とは意味が違う

ここは過去記事との整合性上、重要なので補足します。

Vol.12でも、

Ready Weight:0.85

という数字が登場しました。

しかし、Vol.12の85%は、

最初のReal Shadow Cycleにおいて、Shadow評価可能だったWeight

でした。(ガジェットストリーム)

現在の、

Production Coverage:85%

は、

Productionへ正式算入済みのComponent Weight

です。

数字は偶然同じ85%ですが、

意味は異なります。

Vol.12
Shadow Ready Weight 85%

現在
Production Included Coverage 85%

です。

この二つを同じものとして扱ってはいけません。


なぜ85%を100%へ換算しないのか

ここが今回の記事で一番重要な部分です。

GPU15%が存在しないなら、

残り85%
↓
100%へ拡大

すれば、数字だけならComposite GPIを作れます。

例えばUSD/JPYは本来30%ですが、

30 ÷ 85
≈ 35.3%

になります。

つまりGPUが欠けただけで、

USD/JPY
30%
↓
約35.3%

へ影響力が勝手に増えます。

DRAMも、

25 ÷ 85
≈ 29.4%

になります。

NANDもFreightも同様です。


それは別の指数になってしまう

最初に、

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

と定義したのに、

GPUが取得できない週だけ、

USD/JPY 約35%
DRAM    約29%
NAND    約24%
Freight 約12%

へ変わったらどうでしょうか。

同じ「GPI」という名前なのに、

中身のWeightが週によって変わる指数

になります。

これでは、

先週のGPI:65
今週のGPI:70

を比較しても、

市場が変化したのか、

Weightが変化したのか、

分からなくなります。

そのためGPIでは、

Missing Weightを他のComponentへ再配分しない

というルールを固定しています。

現在のProduction設計でも、

Renormalization:NO
Weight mutation:NONE

が維持されています。


「計算できない」は失敗ではない

GPIでは、

value = null

になることがあります。

一見すると、

計算エラーなのでは?

と思うかもしれません。

しかしそうではありません。

例えば初期のComposite Engine実装時には、USD/JPYだけProduction Eligibleで、

Coverage:0.30
Value:null
Publishable:false

という結果を正常な状態として保存していました。

つまり、

必要Componentが不足していることを正しく検出して、数字を出さない

こともComposite Engineの正常動作です。


GPIではFail-closedを選ぶ

この設計思想を、

Fail-closed

と呼んでいます。

不足や矛盾があった場合、

とりあえず数字を出す

のではなく、

条件不足
↓
WITHHELD

にします。

例えば、

  • Componentが存在しない
  • Sample数不足
  • Validation失敗
  • Source Rights未承認
  • Governance Block
  • Methodology不一致
  • Production Eligibilityなし

のどれかがあれば、正式なComposite GPIへ進めません。


Componentには状態がある

Composite Engineは単にScoreだけを読みません。

Componentごとに、

INCLUDED
MISSING
NOT_READY
INELIGIBLE
BLOCKED
FAILED

などの状態を確認します。

例えば、

Score:85

という数字が計算できていたとしても、

Eligibility:
benchmark_only

なら、Production Weightを与えません。

GSIでは初期のComposite Engineから、

BenchmarkやSynthetic DataへProduction Weightを割り当てない

というルールを維持しています。


過去記事でNANDやFreightを「割り当てなかった」のに、なぜ今はINCLUDEDなのか

ここも時系列を整理しておきます。

Vol.8ではNANDについて、

SSD価格やStorage価格を、そのままNAND価格とは呼ばない

という問題を扱いました。(ガジェットストリーム)

Vol.10でもBLS Deep Sea Freightについて、

海上運賃にかなり近いが、その時点では10%を割り当てない

という判断をしています。(ガジェットストリーム)

この判断は間違いだったわけではありません。

その時点ではProduction Qualificationを通過していなかったため、割り当てなかった

ということです。

その後の開発で、

  • Source Rights
  • Semantic Review
  • Proxy Disclosure
  • Historical Backfill
  • Validation
  • Scoring
  • Methodology Transition
  • Production Qualification
  • Controlled Activation

というGateを順番に進めました。

現在は、

NAND
INCLUDED
Storage-device price proxy / benchmark
※Direct NAND spot / contract priceではない

Freight
INCLUDED
Deep-sea freight price-pressure proxy / benchmark
※Direct freight rateではない

という状態です。

つまり、

「本物のNAND価格・海上スポット運賃を発見した」

から採用したわけではありません。

Proxyであることを明示したMethodologyとして、後続Gateを通過した

という違いです。


GPUだけは現在も15%が空席

一方、Vol.11で扱ったGPUはまだ違います。

Vol.11では、

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

を分けて検証し、

当時は、

GPU Production Ready:false
GPU 15%:未割り当て

としました。(ガジェットストリーム)

その後GPUについてはさらに調査が進み、現在はU.S. Censusの特定GPU関連HS10系列を使った履歴蓄積まで進んでいます。

しかし、

Raw observations:24
Transformed samples:23
Required:36

です。

そして36へ到達しても、

自動的にGPUをProductionへ入れるわけではありません。

現在のGovernance Contractでは、

36 samples
↓
Production Qualification Review

へ進むだけです。

つまり、

36到達
=
GPU採用

ではありません。


100% Coverageになれば即公開できるのか?

これも、

NO

です。

100% Coverageは重要な必要条件ですが、

それだけではPublic Releaseを意味しません。

例えば、

全Componentが揃った
↓
Compositeが計算できた

としても、

さらに、

Methodology
Historical Validation
Governance
Publication Gate

を確認する必要があります。

GSIでは、

CalculationとPublicationを別のGateにする

設計にしています。

これは、

計算できる
=
公開してよい

という誤ったショートカットを防ぐためです。


実際に100%でもNOT_PUBLISHABLEになる

GSIのCategory GPIテストでは、5Componentすべてが揃い、

Coverage:1.0
Value:64.0

と計算できても、

ProfileがまだCandidateであるため、

Publishable:false
Calculation Status:NOT_PUBLISHABLE

になるケースを実装しています。

つまりGSIでは、

数字が存在することと、数字を公開する権限があることを分離している

わけです。


現在のPublic Status Previewも数字を出していない

現在GPIでは、

Public Status Preview

まで公開検証が進んでいます。

しかし表示しているのは、

Production Coverage:85%

Required Coverage:100%

USD/JPY:INCLUDED
DRAM:INCLUDED
NAND:INCLUDED
GPU:HISTORY_ACCUMULATION
Freight:INCLUDED

Composite GPI:
WITHHELD

という状態情報です。

Component Scoreそのものや、

Weighted Contribution
Raw Observation
Robust Z
Internal IDs

はPublic Status APIへ出していません。

直近の運用確認でも、Public Preview UI/APIは正常応答しつつ、Component ScoresとContributionsは外部へ出さない状態が維持されています。


85%はGPIスコアではない

Public Status Previewで、

85%

という数字を見ると、

GPIが85なのでは?

と思うかもしれません。

違います。

Production Coverage 85%

は、

GPIの固定100%ウェイトのうち、現在Productionへ正式算入可能なComponentが85%分ある

という意味です。

市場圧力とは無関係です。

例えば、

Production Coverage:85%

の状態でも、

実際の市場圧力が、

弱い

ことも、

非常に強い

こともあり得ます。

CoverageとGPI Scoreは完全に別の指標です。


では現在の4Componentだけを足せば何点になるのか?

数学的には計算できます。

しかし、

それをGPIとは呼びません。

この点は意図的です。

もし内部に、

USD/JPY Contribution
DRAM Contribution
NAND Contribution
Freight Contribution

が存在しても、

GPU15%が欠けている以上、

その合計を、

暫定GPI
仮GPI
85% GPI

などとしてPublic Releaseしません。

それをやってしまうと、

数か月後にGPUを追加した瞬間、

指数の意味そのものが変わってしまう

からです。


「欠けていること」も情報として公開する

GPIの設計で重視しているのは、

数字を必ず出すこと

ではありません。

むしろ、

現在は85%
GPUは23 / 36
CompositeはWITHHELD

と表示することで、

なぜ数字が出ていないのか

を説明できることを重要視しています。

指数にとって、

「分からないときに分からないと言えること」

は重要だと考えています。


Composite Engineの全体像

ここまでを一枚にすると、

USD/JPY Raw Data
DRAM Raw Data
NAND Raw Data
GPU Raw Data
Freight Raw Data
        ↓
Validation
        ↓
Component Scoring
        ↓
0~100 Score
        ↓
Eligibility Check
        ↓
┌─────────────────────┐
│GPI Composite Engine │
└─────────────────────┘
        ↓
USD/JPY × 0.30
DRAM    × 0.25
NAND    × 0.20
GPU     × 0.15
Freight × 0.10
        ↓
Coverage Check
        ↓
100% ?
 ├─ NO
 │   ↓
 │ WITHHELD / NULL
 │
 └─ YES
     ↓
 Composite Candidate
     ↓
 Governance / Publication Gate
     ↓
 Public Numeric Release

となります。

現在のGPIは、

Coverage Check
85%
↓
WITHHELD

の位置にいます。


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

指数は、一度公開すると、

先週:58
今週:64
来週:71

のように比較されるものになります。

だから途中で、

実は先週だけGPUを抜いていました

今週からWeightを変更しました

データがなかったので別の指標で埋めました

となると、時系列比較が成立しません。

GPIでは、

同じ名前の指数なら、同じMethodologyで比較できる

状態を守りたいと考えています。

そのため、

数字を出せるか

より、

同じ条件の数字を出し続けられるか

を優先しています。


現在のGPIは「ほぼ完成」なのか?

Engineeringだけを見ると、かなり先まで進みました。

  • Collector
  • PostgreSQL
  • Validation
  • Component Scoring
  • Composite Engine
  • Backtesting
  • Governance
  • Production Activation
  • Status API
  • Public Status Preview
  • Operational Hardening

まで実装されています。

しかし、

Composite Numeric GPIという製品の核心部分については、現在も公開していません。

理由は明確です。

Production Coverage
85%

Required Coverage
100%

GPU
23 / 36

Composite Numeric GPI
WITHHELD

だからです。

「あと15%だからほぼ完成」と100%扱いするのではなく、

15%が欠けているなら15%欠けている

という状態をそのまま維持しています。


次のVol.15では「そもそも30・25・20・15・10でいいのか?」を検証する

今回のVol.14では、

30%
25%
20%
15%
10%

という固定ウェイトを使って5Componentを合成する方法を紹介しました。

しかし、ここで次の疑問が出てきます。

なぜUSD/JPYは30%なのか?

DRAM 25%は高すぎないのか?

GPUは15%で本当にいいのか?

これは非常に重要な問題です。

最初に決めたWeightをそのまま使い続けるだけでは、

科学的な指数とは言えません。

そこで次回の、

GPI開発日誌 Vol.15

では、

Methodology・Weight Validation・Historical Backtest

を取り上げます。

具体的には、

  • なぜ現在のWeightにしたのか
  • Weightをどう検証するのか
  • Historical Replayとは何か
  • Future Information Leakageをどう防ぐか
  • Weight Sensitivity Test
  • Market Regimeによって挙動が変わらないか
  • 一つのComponentがGPIを支配していないか
  • 過去のガジェット価格との関係をどう検証するか
  • 「相関がある」と「予測できる」の違い

まで進みます。


まとめ

前回Vol.13では、単位の異なる市場データを、

0 ~ 100

へ変換するComponent Scoringを紹介しました。

今回のVol.14では、その5つを、

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

という固定ウェイトで統合する、

GPI Composite Engine

を紹介しました。

計算自体は、

Component Score
×
Weight
=
Weighted Contribution

を5つ足すというシンプルなものです。

しかしGPIでは、

一つでも必要なProduction Componentが欠ければ、正式なComposite値を出さない

というFail-closed設計を採用しています。

現在は、

USD/JPY:INCLUDED
DRAM:INCLUDED
NAND:INCLUDED
Freight:INCLUDED
GPU:HISTORY_ACCUMULATION

Coverage:85%
Required:100%

Composite GPI:
WITHHELD

です。

85%を100%へ換算もしません。

GPU15%を他のComponentへ再配分もしません。

現在のMethodologyと違う指数になってしまうからです。

そして100%へ到達しても、

それだけでPublic Releaseされるわけではありません。

CalculationとPublicationは別Gateです。

GPIが目指しているのは、

何があっても数字を出す指数

ではありません。

同じルールで計算でき、足りないときには足りないと説明できる指数

です。

次回は、そのルール自体が本当に妥当なのかを、過去データを使って検証します。


※GPIは現在開発中の実験的な市場分析指標です。本記事中のComposite計算例は仕組みを説明するための架空データであり、現在のGPI値ではありません。GPIの0〜100は価格上昇率や価格上昇確率を表すものではありません。また、現在公開されているのはGPI Public Status Previewであり、Composite Numeric GPI、Component Score、Weighted ContributionのPublic Numeric Releaseは承認されていません。


この記事が気に入ったら
フォローしてね!

コメント

コメントする

目次