はじめに

こんにちは。

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

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

を開発しています。

ここ数回の記事では、

Vol.13
市場データ
↓
0〜100へ変換

Vol.14
5つのComponent
↓
固定Weightで統合

Vol.15
Methodology
↓
Historical Backtestで検証

Vol.16
Public Status API
↓
数字を出さずにWebサービスを検証

というところまで進んできました。

そして現在、GPI Public Status Previewでは、

Production Coverage：
85%

Required Coverage：
100%

Composite GPI：
WITHHELD

という状態を表示する設計になっています。

では、残るGPU15%がProductionへ入って、

85%
↓
100%

になった瞬間、

GPIの数字を一般公開できるのでしょうか？

答えは、

できません。

より正確には、

100% Coverageは重要な条件の一つですが、それだけではPublic Numeric Releaseを許可しません。

今回のVol.17では、

GPIの数字を初めて一般へ出すために、何を通過する必要があるのか

をご紹介します。

---

現在もGPIの数字は公開していない

まず現在地を確認します。

直近のGSIで維持されている状態は、

USD/JPY：
INCLUDED

DRAM：
INCLUDED

NAND：
INCLUDED

Freight：
INCLUDED

GPU：
23 / 36
HISTORY / QUALIFICATION継続

Production Coverage：
85%

Composite：
NULL / WITHHELD

Public Numeric Release：
NOT_PUBLISHABLE

です。

つまり、Vol.16で紹介したPublic Status Previewは存在していても、

Composite Numeric GPIそのものはまだ一般へ出していません。

---

「23 / 36」から「36 / 36」になればGPU採用？

これも、

NOです。

現在GPUでは、

23 / 36

というQualification状態を追っています。

では、

36 / 36

になったら自動的に、

GPU Production Activated

となるのでしょうか。

GSIでは、そうしません。

現在のGate Contractでは明確に、

QUALIFICATION COMPLETE
≠
PRODUCTION ACTIVATION

と分離しています。

仮に全36項目がPASSしても、GPUのProduction Activationには別のPM Authorityが必要です。

つまり、

36 / 36
↓
GPU採用

ではなく、

36 / 36
↓
Qualification Complete
↓
Production Activation Review
↓
承認された場合のみActivation

です。

---

GPUがProductionへ入れば即GPI計算？

これも自動ではありません。

GPIでは現在、次のGateを別々に扱っています。

1. Component Qualification

2. Production Inclusion

3. Weight Completeness

4. Production Coverage

5. Composite Calculation Eligibility

6. Composite Publication Eligibility

7. Public Numeric Release

8. Production Release

つまり、

一つ前のGateを通ったから、次も自動的に通る

とはしません。

最新のR3 Qualification Packageにも、

85% Coverage
≠
Composite calculation authorization

Composite calculable
≠
Publication authorization

Publication eligible
≠
Public Numeric Release

36/36 GPU history
≠
GPU Production activation

というNon-equivalenceが明示されています。

---

なぜここまで細かく分けるのか

例えば、

GPUが技術的に問題なく計算できたとします。

しかし、

• Sourceの意味が想定と違う
• Production運用条件が不足している
• Historical Evidenceが不足している
• Methodology上の扱いが未承認
• データ利用条件に問題がある

という可能性があります。

逆に5ComponentすべてがProductionへ入り、

Composite GPIが計算できても、

• Stagingで異常がある
• APIが誤った数字を返す
• WordPress表示で古い値が残る
• Backup / Restoreが未検証
• Rollbackできない
• Methodology Disclosureが不足
• 最終Human Reviewがない

なら、まだ一般公開すべきではありません。

だから、

データのGate

と、

計算のGate

と、

製品公開のGate

を分離しています。

---

100% Coverageの計算自体はすでに「リハーサル」している

実はGSIでは、

5Componentがすべて揃った場合のComposite計算

そのものは、かなり前にリハーサルしています。

Issue #37では、

Full-Coverage Release Candidate

という仕組みを作りました。

ここでは、

FX
DRAM
NAND
GPU
Freight

の5Slotをすべて使用し、

Weight Coverage：
1.000000

つまり100%で計算します。

Missing WeightのRenormalizationも禁止です。

さらに、

• 6桁へQuantize
• SHA-256 Candidate Digest
• Deterministic Replay
• Correction Rehearsal
• Audit-chain Digest

まで確認しています。

---

でもそこで使った数字は「本物のGPI」ではない

リハーサルでは例えば、

Original Synthetic Value：
59.200000

Corrected Synthetic Value：
59.700000

というCompositeを作っています。

しかし、これは、

Synthetic Test Fixture

です。

市場観測値ではありません。

そのため結果は、

Full Coverage Calculation：
PASS

Correction Rehearsal：
PASS

Technical Rehearsal：
PASS

Production Eligibility：
false

Methodology Accepted：
false

Effective Decision：
NO_GO

Public Numeric Release：
false

でした。

ここはGPIの設計思想をよく表しています。

100%で計算できることは、Public Releaseの十分条件ではない。

---

なぜ「Correction Rehearsal」まで必要なのか

指数を公開した後に、

元データのRevisionや誤りが判明する可能性があります。

例えば、

公開時
GPI 62.4

だったものが、

後から公式データの訂正によって、

訂正後
GPI 61.9

になるかもしれません。

そのとき、

62.4を消して
61.9に書き換える

だけでは、何が起きたのか分からなくなります。

そこでGSIでは、

Original Candidate
↓
Original Digest

Correction
↓
Corrected Candidate
↓
Corrected Digest

Original
↓
Corrected

Audit Chain

という履歴を残せるようにしています。

つまり、

最初の数字を公開する前に、「間違ったときにどう直すか」まで作っています。

---

次に必要なのがMethodology Acceptance

仮に5ComponentがProduction Readyになり、

100% CoverageでCompositeが計算できても、

まだ一つ大きなGateがあります。

Methodology Acceptance

です。

GSIではNamed Methodology Decisionに必要なEvidenceとして、

• Sanitized Operational Export
• Valid Operational Review
• Historical Thresholds
• 5ComponentすべてのOperational History
• Full-Coverage Rehearsal
• Correction Rehearsal
• Approved Inputs
• 5SlotすべてのSource / Semantic / Weight Decision

などを要求する設計にしています。

つまり、

5つ揃ったからMethodology完成

でもありません。

---

「Methodologyを受理した人」も記録する

さらにGPIでは、

テスト全部PASS
↓
自動でMethodology Accepted

とはしません。

Named Reviewerによる判断を残します。

なぜなら、

「このデータをGPU需給として本当に扱うのか」

「このProxyのDisclosureで十分なのか」

「このWeightをこのVersionで固定してよいのか」

といった判断は、

単純なUnit Testでは決められないからです。

ここには、

Semantic / Governance Judgment

があります。

---

β版なら少しくらい条件を緩くしてもいい？

ここで、

正式版ではなくβ版なら、多少条件が足りなくても公開してよいのでは？

という考え方もあります。

GPIでは、

その考え方を採用していません。

Repositoryにはすでに、

Staging Validation and Public-Beta Release Gate

があります。

このGate自体のBaselineは、

Requested Decision：
NO_GO

Effective Decision：
NO_GO

Public Release Authorized：
false

です。

そしてPublic-Beta Release Policyでは、Blocking Evidenceが不足していればNO_GOを返し、別Review後にCode-owned Policyがpublic_release_authorized=trueになって初めてReleaseへ進める構造です。それ以外はNO_GOです。

---

GPIでいうβ版は「ルールが緩い版」ではない

このためGPIにおけるPublic Betaは、

精度が適当でも数字を出していい版

ではありません。

むしろ、

Methodologyと公開条件を明示したうえで、限定された初期Production運用を開始する段階

に近い位置付けです。

つまりβ版であっても、

Sourceは未承認だけど使う

Coverageは85%だけど100%換算する

GPUがないからWeightを変更する

Methodology Candidateのまま出す

といったことはしません。

---

100% Coverageの次にはStagingがある

Production Candidateが完成しても、

そのままPublicへは出しません。

次に必要なのが、

Staging

です。

Stagingでは実際のReleaseに近い環境で、

• API
• Dashboard
• WordPress
• Security
• Database / Migration
• Observability
• Backup / Restore
• Rollback

などを確認します。

GSIのOperational Release Reviewでは、少なくとも次の10項目をGoverned Staging Checkとして定義しています。

Candidate Integrity
Repository CI
Secrets / Access
Database / Migrations
API Smoke
Dashboard Smoke
WordPress Smoke
Observability / Alerting
Backup / Restore
Rollback Rehearsal

---

「ページが表示された」だけでは足りない

例えば、

Dashboard
HTTP 200

でも、

バックアップから復元できなければ問題です。

また、

API
HTTP 200

でも、

古いGPIをCacheし続けていたら問題です。

そして、

WordPress
表示成功

でも、

障害発生時にRollbackできなければ本番運用は危険です。

だから、

画面が見える

と、

サービスとして公開できる

を分けています。

---

Legal / NoticeもRelease Gateに含める

Public Numeric GPIを出す場合、

数字だけではなく、

その数字が何なのか

も利用者へ説明する必要があります。

Operational Release Reviewでは、

• License Notice
• Third-party Data Attribution
• Data Use Terms
• Methodology Disclosure
• Privacy Notice
• Trademark Notice
• Public Status / Correction / Incident Channel

という7種類のLegal / Notice Checkも定義しています。

例えばNANDでは、

Storage-device price proxy / benchmark

であること。

Freightでは、

Deep-sea freight price-pressure proxy / benchmark

であること。

こうした情報を、数字だけ出して隠してはいけません。

---

「最終GO」も自動化しない

すべてのTechnical GateがPASSしたとしても、

最後に、

Named Release Review

があります。

Operational Release Reviewでは、

Reviewer
Role
Timestamp
Rationale
Evidence

を記録することを求めています。

つまり、

CI Green
↓
自動Public Release

ではありません。

---

GPIのRelease Gateを一枚にすると

現在の考え方をかなり簡略化すると、

GPU History / Evidence
        ↓
Component Qualification
        ↓
GPU Production Activation Review
        ↓
Production Inclusion
        ↓
5 Component Weight Complete
        ↓
Production Coverage 100%
        ↓
Composite Calculation Eligibility
        ↓
Full-Coverage Candidate
        ↓
Deterministic Replay
        ↓
Correction Rehearsal
        ↓
Historical Evidence
        ↓
Methodology Acceptance
        ↓
Staging Validation
        ↓
API / Dashboard / WordPress
        ↓
Security / Observability
        ↓
Backup / Restore / Rollback
        ↓
Legal / Disclosure Review
        ↓
Human Product Acceptance
        ↓
Named Release Review
        ↓
Public Numeric Release Authority
        ↓
初めて数値公開

となります。

---

ここまでGateを作る必要があるのか

個人開発の指数として考えると、

かなり大げさに見えるかもしれません。

実際、

Excelで計算
↓
WordPressへ手入力

なら、もっと早く公開できます。

しかし、それでは将来、

2026年9月：62.1
2026年10月：68.3
2027年1月：51.7

と数字が蓄積されたとき、

すべて同じMethodologyで計算されたのか？

当時利用可能だったデータだけを使っているのか？

後から数字を書き換えていないか？

何か欠けた週にWeightを変えていないか？

Sourceの利用条件は大丈夫なのか？

を証明できません。

GPIを単発記事ではなく、

長期的な市場指標

にしたいのであれば、この部分が重要になります。

---

そして直近では「Release」ではなくRead-only Qualificationをしている

ここで現在の実作業へ戻ります。

GPI開発は現在、

Public Release Gateを開こうとしている

段階ではありません。

直近では、

Home Read-only Current-State Qualification R3

が準備されています。

このR3では、

• 実際のorigin/main確認
• Repository / Remote Identity
• 並行して進むGSRとのAncestry Reconciliation
• UI-1A Regression
• GPU 36-item Authority再確認
• Composite / Public Gateの再確認
• Repository Health
• Evidence生成

をRead-onlyで行う設計です。

---

なぜRelease直前でもGitの状態を確認するのか

GSIではGPIだけでなく、

• GSR
• GSI共通基盤

も同じRepositoryで並行開発しています。

そのため、

昨日確認したmain

が、

今日のmain

とは限りません。

直近のR3ではこの問題を明示的に扱い、

actual origin/main
repository identity
remote identity
candidate ancestry

を確認してから次の工程へ進むようにしています。

現在のR3は、

READY
HOME QUEUED
READ_ONLY

であり、

まだProduction/Public Authorityを消費する処理ではありません。

---

UIもTechnical PASSだけでは閉じない

Vol.16で紹介したPublic Status Previewについても、

Technical側はかなり進んでいます。

現在の状態では、

UI-1A Technical：
PASS

Automated Validation：
PASS

Browser Validation：
PASS

Responsive：
PASS

200% Zoom：
PASS

です。

しかし、

UI-1A Product Acceptance：
OPEN / PENDING_PM_REVIEW

です。

なぜなら、

Technicalに崩れていなくても、

利用者が85%を「GPI 85」と誤解しないか

23/36を「完成率」と誤解しないか

WITHHELDの理由が理解できるか

というProduct Judgmentは別だからです。

---

Public Numeric Release Gateの重要な5つの「≠」

今回のVol.17を一番短くまとめるなら、次の5つです。

36 / 36
≠
GPU Production Activation

GPU Production Activation
≠
自動Public Release

Production Coverage 100%
≠
Public Numeric Release

Composite計算可能
≠
Publication Eligible

β版
≠
品質Gateを省略してよい

これがGPIの現在のRelease設計です。

---

では、β版公開はいつになる？

現時点で、

日付は決めません。

例えば、

GPUあと13項目
↓
13か月
↓
○月公開

のような単純計算もしません。

GPUの23/36は開発進捗率ではありません。

そして36/36になっても、

Production Activation、Composite、Methodology、Release Reviewが残るためです。

Public UIでも、

ETA
Completion Date
Remaining Months

のような表現をGPUへ付けない設計にしています。

---

「公開日」ではなく「公開条件」を決める

現在GPIで決めているのは、

いつ公開するか

ではありません。

何を満たしたら公開してよいか

です。

これは大きな違いです。

例えば、

○月1日公開予定

と決めてしまうと、

期日が近づいたとき、

13項目のうち11個しか終わっていないけど出そう

Coverage 85%を100%換算しよう

このGateだけ後回しにしよう

という圧力が生まれます。

GPIでは、その方向を避けています。

---

数字がないことより、間違った数字を固定する方が怖い

GPIをここまで開発してきて、かなりはっきりしてきたことがあります。

指数にとって怖いのは、

数字を出せない期間があること

ではありません。

本当に怖いのは、

後から説明できない数字を公開し、その数字が履歴として残ること

です。

一度、

GPI 67.4

と一般公開すれば、

SNSへ転載されたり、

記事で引用されたり、

将来の値と比較されたりする可能性があります。

あとから、

GPUが入っていませんでした

Weightが違いました

MethodologyがまだCandidateでした

とは言いたくありません。

---

「WITHHELD」は開発失敗ではない

現在の、

Composite：
WITHHELD

という状態は、

完成していないから仕方なく表示しているものではありません。

むしろ、

Release Gateが正常に機能していることを示す状態

です。

数字を出してはいけない条件なら、

数字を出さない。

これは今後本番運用が始まってからも必要になります。

---

Vol.17時点の現在地

今回の記事公開時点で、最新の確認済みAuthorityは次の状態です。

Production Coverage：
85%

GPU：
23 / 36

Composite：
NULL / WITHHELD

Public Numeric Release：
NOT_PUBLISHABLE

UI-1A Technical：
PASS

UI-1A Product Acceptance：
OPEN

GPU Production Activation：
NO

Renormalization：
NO

さらに次に控えているR3は、

HOME QUEUED
READ_ONLY

です。

ProductionやPublic Releaseを実行するAuthorityではありません。

---

つまり、Vol.17でβ版公開ではない

この開発日誌を最初に計画したときは、

Vol.17
β版公開

くらいの想定でした。

実際に開発してみると、

そこまで単純ではありませんでした。

Collectorを作るだけでなく、

• Source Rights
• Proxy Semantics
• Historical Evidence
• Component Scoring
• Composite
• Revision
• Backtest
• Weight Validation
• Public API
• Status Preview
• Staging
• Backup / Restore
• Rollback
• Legal / Disclosure
• Human Review
• Release Authority

まで必要になりました。

だからVol.17は、

「β版を公開しました」

ではなく、

「β版を名乗るために何を通過しなければならないかを固定しました」

という回になりました。

これは当初の予定より時間はかかっていますが、

GPIを長く使える指標にするためには必要な変更だと考えています。

---

次の開発日誌について

ここまでVol.1から続けてきたGPI開発日誌ですが、

Vol.17を一区切りとします。

次の記事を、

Vol.18

としてすぐに決め打ちはしません。

次に大きな節目が来たとき、

例えば、

GPU Qualificationの大きな進展

Production Coverageの変更

Methodology正式Decision

100% Full-Coverage Candidate

Public Numeric Release Eligibility

Public Beta開始

など、

実際のAuthorityが変化したタイミング

で続きを書く方が、合っていると考えています。

---

まとめ

Vol.17では、

Public Numeric Release Gate

についてご紹介しました。

GPIでは、

GPU 36/36

になっても、

自動でGPUをProductionへ入れません。

Production Coverageが、

100%

になっても、

自動でCompositeを一般公開しません。

Compositeが計算できても、

自動でPublic Numeric Releaseしません。

さらに、

β版だからGateを緩くする

こともしません。

GPIの数字を初めて一般へ出すまでには、

Component Qualification
↓
Production Inclusion
↓
100% Coverage
↓
Composite Candidate
↓
Historical / Methodology Review
↓
Correction Rehearsal
↓
Staging
↓
API / Dashboard / WordPress
↓
Security
↓
Backup / Restore / Rollback
↓
Legal / Disclosure
↓
Human Review
↓
Named Release Review
↓
Public Numeric Release Authority

という工程があります。

実際、100% Coverageを使ったSynthetic Release Candidate RehearsalはすでにPASSしています。

それでも、

Public Numeric Release：
false

でした。

計算できたから公開するのではありません。

公開してよいことを確認できたときに、初めて公開します。

現在は、

Production Coverage：85%
GPU：23 / 36
Composite：WITHHELD
Public Numeric Release：NOT_PUBLISHABLE

です。

まだ数字は出しません。

しかし、

どの条件を満たしたら数字を出してよいのか

については、かなり明確になりました。

GPI開発は、

「数字を作る」段階から、

「その数字を社会へ出しても壊れない仕組みを作る」段階

へ進んでいます。

そしてそのGateをすべて通過したとき、

初めてGadgetStreemから、

GPIの数値そのもの

をお見せします。

---

※GPIは現在開発中の実験的な市場分析指標です。現在公開されているGPI Public Status PreviewはComposite Numeric GPIのPublic Releaseではありません。Production Coverage 85%やGPU 23/36はGPIスコア、完成率、公開予定日を示すものではありません。またPublic Beta Releaseについても、現在は承認されていません。GPIは個別製品の将来価格や価格変動確率、投資利益を保証するものではありません。

---