はじめに

こんにちは。

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

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

を開発しています。

前回のVol.15では、

Historical Replay

Market Regime Backtest

Weight Validation

を使って、

GPIの計算式そのものをどう疑うのか

をご紹介しました。公開済みVol.15でも、GPIはProduction Coverage 85%、GPUは23/36、Composite Numeric GPIはWITHHELDという状態を説明しています。(ガジェットストリーム)

そして最後に、次回Vol.16では、

まだGPIの数字を公開できないのに、なぜPublic APIやDashboardを先に作ったのか

をご紹介すると予告しました。

今回は、その話です。

実は現在、

GPI Public Status Preview

はすでにPublicへ出ています。

ただし、最初に非常に重要なことを書いておきます。

GPIそのものを一般公開したわけではありません。

公開したのは、

「GPIが現在どこまで完成しているのか」を確認するStatus画面

です。

---

「数字が完成するまで何も公開しない」では遅い

GPIの最終形を考えると、最終的にはブラウザへアクセスしただけで、

現在のGPI
↓
過去推移
↓
各Component
↓
市場圧力
↓
Methodology

を確認できるサービスを目指しています。

株価チャートや為替チャートのように、

ページを開けば、その時点の最新状態が見える

という形です。

しかし現在は、5つすべてのProduction Componentが揃っていません。

直近の確認済みPublic Statusでは、

Component	状態
USD/JPY	INCLUDED
DRAM	INCLUDED
NAND	INCLUDED
GPU	HISTORY_ACCUMULATION
Freight	INCLUDED

となっています。

Production Coverageは、

85%

必要条件は、

100%

です。

GPUについては、

23 / 36 transformed samples

という履歴蓄積段階にあります。

そして、

Composite GPI
WITHHELD

です。直近のUI技術レビューでも、この85%・GPU 23/36・Composite nullというAuthorityを使って検証しています。

---

では、100%になるまでWeb画面も作らないのか？

私たちはそうしませんでした。

理由は、

数値計算の完成と、Webサービスとしての完成は別だから

です。

仮に明日GPUがProduction Qualificationを通過して、

Coverage
85% → 100%

になったとします。

その瞬間に初めて、

APIを作る。

Dashboardを作る。

スマホ表示を確認する。

エラー画面を作る。

セキュリティを確認する。

WordPressとの接続方法を考える。

となったら、そこからまた長い開発が始まります。

そこでGPIでは、

数字を出せない状態そのものを使って、Public Productを先に検証する

ことにしました。

---

そこで作った「Public Status Preview」

現在公開しているのが、

GPI Public Status Preview

です。

これはGPIの市場数値を見せるDashboardではありません。

現在のProduction準備状況を確認する画面です。

Controlled Public Releaseでは、

Public Status Preview：LIVE

Public Access：ENABLED

Status UI：HTTP 200

Status API：HTTP 200

Production Coverage：85%

Required Coverage：100%

Composite Numeric GPI：
WITHHELD / NULL

Public Numeric Release：
NOT_PUBLISHABLE

Full GPI Production Release：
NO_GO

という状態まで実際に確認しました。

つまり、

WebサービスとしてはPublic

ですが、

GPI Numeric Productとしてはまだ非公開

です。

この2つを意図的に分けています。

---

「GPIを公開しました」とは書かない

この境界は、かなり厳密に管理しています。

Controlled Public Releaseの実行記録にも、

GPI Public Status Preview is live.

と書くことは許可されています。

一方で、

GPI is publicly released.

とは書かないよう明示されています。

これは単なる言葉遊びではありません。

現在一般公開しているのは、

GPIの完成状況

だからです。

GPIそのもののNumeric Releaseではありません。

---

Public APIも「Status専用」

Public Previewから利用するAPIも、

Status-only

です。

現在のPreviewでは、

/api/v1/gpi/status

という専用Endpointから状態を取得します。

返すのは、

Production Coverage
Required Coverage
Production Readiness
Publishability
各ComponentのState
GPUの履歴状態

などです。

一方で、公開対象から明示的に除外している情報があります。

Controlled Public Releaseでは、

Component Scores：ABSENT
Contributions：ABSENT
Raw Observations：ABSENT
Production DB IDs：ABSENT
Governance Artifacts：ABSENT
Evaluator Output：ABSENT
Control Plane Metadata：ABSENT
Secrets / Credentials：ABSENT

まで検証しました。

---

なぜComponent Scoreすら出さないのか

例えば内部では、

USD/JPY Score
DRAM Score
NAND Score
Freight Score

を計算できる状態があります。

Vol.13でも、過去の内部Scoring Runの実例をご紹介しました。

しかし、

4つだけなら公開してもよいのでは？

とはしません。

なぜなら利用者が、

USD/JPY 35
DRAM 59
NAND 100
Freight 85

のような数字を見れば、

それを実質的なGPIとして解釈する可能性があるからです。

GPU15%が欠けた状態で、4Componentだけを公開すると、

Vol.14で説明した、

85%を100%として扱わない

というMethodology BoundaryをUI側から壊してしまいます。

だから、

Backendで計算できること

と、

Public APIから取得できること

を分けています。

---

APIで隠して、UIでうっかり出すのも禁止

数値漏洩対策はAPIだけではありません。

DashboardのBuild Artifactについても、

85%
23 / 36

のような現在値をSource Codeへ直接Hard-codeしないよう検証しています。

つまり、

Reactのコードに
「85%」と書いておく

のではなく、

Public Status API
↓
現在のAuthority
↓
Dashboardへ表示

という経路です。

UIの技術レビューでも、85%や23/36がImplementation SourceへHard-codeされていないことをGateにしています。

---

なぜHard-codeしてはいけないのか

今後GPUがQualificationを通過した場合、

Production Coverageは変わります。

そのとき、

Backend：100%
UI：85%

となったら、Public Statusとして機能しません。

逆にBackendがFail-closedしているのに、

古いUIだけ85%を表示し続けるのも問題です。

そのため、

表示する現在状態はAPIから取る

ことを基本にしています。

これは将来GPI Numeric Releaseを行うときにも、そのまま重要になります。

---

古い数字をキャッシュで見せない

Public Status APIでは、

Cache-Control: no-store

も使っています。

現在のStatusが変わったのに、

ブラウザや中間Cacheから古い状態が返ってくることを避けるためです。

実際のPublic Release検証でも、

Live Status API anti-stale cache control

をPASS条件にしています。

GPIは将来的に、

ページへアクセスしたら最新状態を見る

というサービスを目指しています。

そのため「最新とは何か」という部分も、UIだけではなくAPI Contractとして扱っています。

---

「WITHHELD」を隠さず画面へ出す

通常のWebサービスなら、

数字がない状態はできるだけ目立たなくしたくなるかもしれません。

GPIでは逆です。

現在は、

Composite GPI: WITHHELD

と表示します。

つまり、

計算・公開条件を満たしていないので、意図的に数字を出していません

という状態を利用者へ見せています。

これはエラーではありません。

GPIにおいては、

Fail-closedが正常に機能している状態

です。

---

「85%完成」とも書かない

GPUには、

23 / 36

という値があります。

しかし、これを、

63.9%完成

とは表示しません。

36サンプルへ到達することは、

Production採用の条件の一つ

にすぎないからです。

36へ到達した後も、

Production Qualification Reviewがあります。

そのためPublic UIの検証では、

percent complete
percentage complete
remaining months
completion date
estimated completion
ETA

のような意味をGPUへ付与しないことまで確認しています。

---

Status画面だからこそ、UI品質も先に検証できる

Public Status Previewを先に作ったことで、

本番GPI数値なしでもWeb UIの品質検証ができます。

例えば現在のDashboardでは、画面幅に応じてComponent CardのColumn数を変えます。

1280px
5 columns

1024px
3 columns

768px
2 columns

390px
1 column

というResponsive Contractを検証しています。

さらに、200%表示時のReflowやStatus表示の衝突も実際に検出し、修正後のBrowser Acceptanceまで行いました。

つまり、

GPIが100%になるまで待たなかったからこそ、UIの問題を先に潰せた

ということです。

---

エラー時も「前の85%」を残さない

Public Status UIでは、APIへ接続できなくなったときの挙動も重要です。

例えば、

昨日
Production Coverage 85%

今日
API障害

だった場合。

昨日の85%をそのまま画面へ残してしまうと、

利用者はそれを現在値だと思う可能性があります。

そのためGPIのPublic Previewは、

現在状態を確認できないなら、確認できないと表示する

というFail-closed方向で設計しています。

GPIではデータ収集だけでなく、

表示側でも古い正常状態を信用し続けない

ことを重視しています。

---

Publicにしたが、検索結果へ広げる段階ではない

現在のPublic Status Previewは、

Public Accessまで有効化しています。

一方、

noindex

も設定しています。

また、Controlled Public Release時点では、

Custom domain / DNS：
NOT_PERFORMED

でした。

つまり、

誰でもアクセス可能なPublic検証環境

には進めましたが、

GadgetStreemの正式GPIサービスとして大々的に公開

したわけではありません。

ここでも段階を分けています。

---

WordPressはGPIの計算システムにしない

GadgetStreemの本体はWordPressで運営しています。

そこで、

WordPressのPHPからPostgreSQLへ直接つないでGPIを表示すれば簡単では？

とも考えられます。

しかし、GSIのArchitectureではそれを禁止しています。

基本構造は、

Market Data
↓
GSI Backend
↓
PostgreSQL
↓
GPI Engine
↓
Public API
↓
Dashboard
↓
WordPress

です。

System Architectureでも、

DashboardはGSI APIから値を取得する
WordPressはDashboardを埋め込むかAPIを利用する
WordPressからPostgreSQLへ直接接続しない

という境界を定義しています。

---

なぜWordPressからDBへ直接つながないのか

理由は責務を分けるためです。

WordPressは、

記事やページを提供するPresentation / Editorial Layer

です。

一方GSIは、

市場データを取得し、Validationし、計算し、Governanceを適用するシステム

です。

WordPressが直接DBを読めるようになると、

Validationを通していない値

Internal-onlyのScore

Production未承認のCandidate

Raw Observation

などへPresentation Layerから到達できる可能性が出てきます。

APIを境界にすれば、

Publicへ出してよい情報だけをPublic Schemaとして返す

ことができます。

---

WordPress用の埋め込み基盤もすでに作っている

WordPressとの統合自体も、GSI開発のかなり早い段階で実装しています。

専用の、

gsi-gpi-block

というWordPress Integrationを作り、

GPI Dashboardを埋め込めるBlock / Shortcode基盤を用意しました。

実装ではDynamic Block、ServerSideRender、WordPress側Style、Dashboard Embedなどを検証し、WordPress Renderer TestもPASSしています。

Production用には、

https://gadgetstreem.jp
https://www.gadgetstreem.jp

を許可Originとして設定できる設計も用意しています。

ただし、ここでも時系列に注意が必要です。

WordPress Embedの基盤がある

ことと、

現在のPublic Status PreviewをGadgetStreem本番ページへ正式統合済み

ということは同じではありません。

後者については、まだ正式GPI Public Releaseとして扱いません。

---

Public Previewを先に出したことで分かったこと

今回の工程で大きかったのは、

GPIのProduct Layerを、

数値完成後の最後の飾り

として扱わなくなったことです。

現在は、

Backend
↓
Status Authority
↓
Status-only API
↓
Public UI
↓
Responsive
↓
Failure Handling
↓
Security
↓
Release / Rollback
↓
WordPress Boundary

までを、Numeric GPIなしで検証できます。

そしてControlled Public Releaseでは、

Public Accessを有効化するだけでなく、

Security Header、noindex、API/UI整合性、Rollbackまで確認しました。

---

「数字がない画面」に意味はあるのか

あります。

むしろ現在のPublic Status Previewが示しているのは、

あと何が足りないのか

何がProductionへ入っているのか

何をProxyとして使っているのか

なぜCompositeを出していないのか

です。

GPIの開発でこれまで何度も出てきた、

分からないものを、分かったことにしない

という考え方を、

Public UIでもそのまま使っています。

---

Public PreviewはGPIの「約束」を先に実装している

GPI Numeric Releaseが始まったとき、

利用者に必要なのは数字だけではありません。

例えば、

この数字は最新なのか？

5Componentは全部揃っているのか？

Proxyを使っているのか？

データが欠けているのに計算していないか？

という情報も必要です。

現在のStatus Previewは、

その説明部分を先に製品化している

とも言えます。

---

現在地

直近確認できるPublic Status Authorityでは、

Production Coverage：
85%

Required Coverage：
100%

USD/JPY：
INCLUDED

DRAM：
INCLUDED

NAND：
INCLUDED
Storage-device price proxy

GPU：
HISTORY_ACCUMULATION
23 / 36

Freight：
INCLUDED
Deep-sea freight price-pressure proxy

Composite Numeric GPI：
WITHHELD

Public Numeric Release：
NOT_PUBLISHABLE

です。8月28日のUI技術レビューでも同じStatus Contractを使い、Public PreviewのResponsive / Browser Acceptanceを継続しています。

したがって、

「GPI Public Status PreviewはLive」

ですが、

「GPIは公開済み」ではありません。

---

次のVol.17では「いつなら数字を公開していいのか？」

ここまでで、

データを取得する仕組み。

0〜100へ変換する仕組み。

5Componentを合成する仕組み。

過去データでMethodologyを検証する仕組み。

そして、

それを利用者へ安全に見せるPublic Layer

までご紹介しました。

残る大きな問題は、

いつになったらComposite Numeric GPIを公開してよいのか？

です。

GPUが36サンプルへ到達すれば即公開なのか。

Coverage 100%なら公開なのか。

Public Status Previewが動いていれば十分なのか。

答えは、

どれも、それだけでは不十分

です。

次回Vol.17では、

Public Numeric Release Gate

を取り上げます。

100% Coverageになった後に何を確認するのか。

Methodology Acceptanceとは何か。

Production ReleaseとPublic Numeric Releaseはなぜ別なのか。

β版とは何をもってβ版なのか。

そして、

GPIの数字を初めて一般へ出す瞬間に、何を満たしていなければならないのか

を整理します。

---

まとめ

今回のVol.16では、

GPI Public Status Preview

をご紹介しました。

GPIは現在もComposite Numeric Valueを公開していません。

それでもPublic APIとDashboardを先に作ったのは、

数字が完成してからWebサービスを作り始めるのでは遅い

からです。

現在はStatus-only APIから、

Production CoverageやComponent Stateなど、

公開を許可した情報だけを取得します。

Component Score。

Weighted Contribution。

Raw Observation。

Production DB ID。

Governance内部情報。

これらはPublic APIへ出しません。

さらにDashboard側も現在値をHard-codeせず、APIから状態を受け取ります。

古いStatusを残さない。

GPU 23/36を「完成率」と呼ばない。

Compositeを出せないならWITHHELDと表示する。

WordPressからPostgreSQLへ直接接続しない。

という境界も作りました。

そして実際に、

GPI Public Status PreviewはPublicへ到達しました。

ただし、

GPIはまだPublic Numeric Releaseしていません。

この違いが、今回最も重要なポイントです。

GPIが目指しているのは、

数字だけが表示されるページ

ではありません。

その数字が、なぜ今表示できるのか。あるいは、なぜまだ表示できないのかまで説明できるサービス

です。

現在はまだ、

Composite GPI：
WITHHELD

です。

しかし、そのWITHHELDを正しくPublicへ伝えるところまで、GPIは進みました。

次回はいよいよ、

そのWITHHELDを解除するための最終条件

へ進みます。

---

※GPIは現在開発中の実験的な市場分析指標です。現在Publicへ提供しているのはGPI Public Status Previewであり、Composite Numeric GPIのPublic Numeric Releaseではありません。Production Coverage 85%はGPIスコア85を意味するものではありません。また、GPUの23/36は開発進捗率を意味するものでもありません。GPIは個別製品の将来価格、価格上昇確率、購入利益を保証するものではなく、投資判断を目的とした金融指標でもありません。

---